[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.
> >
> >
> >
> >
> >
>
>