[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: A personal take on WG's priorities..



But I don't agree we should not work on new emerging transition mechanisms that in fact are being deployed as we talk here.
/jim 

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter
> Sent: Thursday, November 04, 2004 11:21 AM
> To: jordi.palet@consulintel.es
> Cc: v6ops@ops.ietf.org
> Subject: Re: A personal take on WG's priorities..
> 
> Jordi,
> 
> It's Management 101. I don't think any WG with so many 
> diverse topics has a chance of making good progress. We need 
> to divide and conquer, IMHO.
> 
>     Brian
> 
> JORDI PALET MARTINEZ wrote:
> > Hi Brian,
> > 
> > May be I'm wrong, but if the objective to outsource some of 
> the work 
> > is to "evacuate" it faster, I think is not the right way.
> > 
> > I mean, if they are within the charter, they are 
> operational issues, 
> > pushing it outside, will mean some of the people that is 
> doing effort 
> > here, will divide his time following up to WGs (at least), 
> attending 2 meetings, etc.
> > At the end, some times this can be rather more time consuming that 
> > proceeding here. I've this experience in projects, when you 
> divide the 
> > work in several WGs and then becomes fragmented, and the 
> people, who 
> > is limited in number and resources, availability, etc., 
> tend to keep 
> > only with part of the work, very concentrated and missing 
> the overall picture.
> > 
> > Consequently, I will agree with this only in case we have extra 
> > effort, which is not the case, but in general in IETF on 
> the contrary. 
> > Less people less effort with the time ..., unfortunately.
> > 
> > I will agree that if we have something that is clearly 
> specific to an 
> > existing WG, then it should be forwarded there. Similarly, 
> if there is 
> > some work that requires a very focused effort, then we 
> should try to 
> > create a new WG, probably.
> > 
> > Regards,
> > Jordi
> > 
> > 
> > 
> >>De: Brian E Carpenter <brc@zurich.ibm.com>
> >>Organización: IBM
> >>Responder a: owner-v6ops@ops.ietf.org
> >>Fecha: Thu, 04 Nov 2004 09:09:44 +0100
> >>Para: Pekka Savola <pekkas@netcore.fi>
> >>CC: v6ops@ops.ietf.org
> >>Asunto: Re: A personal take on WG's priorities..
> >>
> >>Pekka,
> >>
> >>Loosely speaking, this list seems OK to me personally.
> >>
> >>Quite obviously, it would be outrageous to attempt all this 
> in one WG. 
> >>IMHO, we need to either out-source work to other WGs or 
> create several 
> >>new WGs with focussed charters.
> >>Especially, we need to separate "getting known stuff fully 
> >>operational" from "doing new stuff."
> >>
> >>  Brian
> >>
> >>Pekka Savola wrote:
> >>
> >>>Hi,
> >>>
> >>>Based on the discussion on what the WG should be doing, I 
> cooked up 
> >>>my
> >>>**personal** list of what I consider to be priorities, in 
> some rough 
> >>>categories.  As you see, there's a *LOT* that falls under the WG 
> >>>charter, and there is no way we could work on even 1/3 or 1/4 of 
> >>>these at the same time.  So, there must be some priorization.
> >>>
> >>>I welcome comments especially if you think I've badly 
> misprioritized 
> >>>document/work that relates to the v6ops charter.
> >>>
> >>>======
> >>>
> >>>The most important work
> >>> - finish enterprise analysis
> >>> - finish requirement(s) for tunneling
> >>>    * to be able to decide whether existing solution(s) 
> are sufficient
> >>>      and if not, get started on specifying new ones
> >>> - get started on mechanisms (somewhere else?) if needed/necessary
> >>>
> >>>Pretty darn important work
> >>> - the last spin at 3GPP analysis doc, updated IMS scenario
> >>> - better document the ISP's broadband transition scenarios
> >>>    * draft-asadullah-v6ops-bb-deployment-scenarios-01
> >>> - finish draft-ietf-v6ops-mech-v2
> >>>    * waiting for feedback from the IESG telechat..
> >>> - adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
> >>>    * IESG requirement for draft-ietf-v6ops-mech-v2
> >>> - figure what to do about the NAT-PT deprecation/analysis
> >>>   *  draft-aoun-v6ops-natpt-deprecate
> >>> - (techno-political) document for v4 NAT users
> >>>   * draft-vandevelde-v6ops-nap
> >>> - IPv6-on-by-default work, fixes need to be integrated in 
> the IETF work
> >>>   * draft-ietf-v6ops-onlinkassumption
> >>>   * draft-ietf-v6ops-v6onbydefault
> >>>   * etc.
> >>>
> >>>Important work
> >>> - draft-ietf-v6ops-renumbering-procedure
> >>>   * needs revision to address IESG comments
> >>> - draft-palet-v6ops-tun-auto-disc
> >>> - draft-chown-v6ops-vlan-usage
> >>> - figuring out how to deal with Mobile IP transition issues
> >>> - security overview of IPv6
> >>>    * draft-savola-v6ops-security-overview
> >>>
> >>>Useful work
> >>> - revising 6to4 spec to be clearer, etc.
> >>> - draft-palet-v6ops-solution-tun-auto-disc
> >>> - draft-chown-v6ops-renumber-thinkabout-00
> >>> - draft-chown-v6ops-port-scanning-implications
> >>>
> >>>Difficult to say whether it has gained sufficient 
> momentum, and/or  
> >>>whether this is the right place to do this
> >>> - draft-palet-v6ops-auto-trans
> >>> - draft-palet-v6ops-ipv6security
> >>> - draft-vives-v6ops-ipv6-security-ps
> >>> - draft-kondo-quarantine-overview-01.txt
> >>>
> >>>Not sure whether it should be published as RFC, or is sufficiently 
> >>>relevant
> >>> - draft-chown-v6ops-campus-transition
> >>> - draft-morelli-v6ops-ipv6-ix
> >>>
> >>
> >>
> > 
> > 
> > 
> > **********************************
> > Madrid 2003 Global IPv6 Summit
> > Presentations and videos on line at:
> > http://www.ipv6-es.com
> > 
> > This electronic message contains information which may be 
> privileged or confidential. The information is intended to be 
> for the use of the individual(s) named above. If you are not 
> the intended recipient be aware that any disclosure, copying, 
> distribution or use of the contents of this information, 
> including attached files, is prohibited.
> > 
> > 
> > 
> > 
> > 
> 
>