[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: On NGTRANS, transition mechanisms and consortia
- To: "Harald Tveit Alvestrand" <harald@alvestrand.no>
- Subject: RE: On NGTRANS, transition mechanisms and consortia
- From: "Bound, Jim" <Jim.Bound@hp.com>
- Date: Tue, 19 Nov 2002 18:27:13 -0500
- Cc: <v6ops@ops.ietf.org>
- Delivery-date: Tue, 19 Nov 2002 15:27:37 -0800
- Envelope-to: v6ops-data@psg.com
- Sender: owner-v6ops@ops.ietf.org
- Thread-index: AcKQISyjrPLVciO8SE6hAk0ObGzVagAAIErg
- Thread-topic: On NGTRANS, transition mechanisms and consortia
Harald,
Thank you for this clear response. This is what we needed to hear with
this clarity and the communications. Trust that nothing I do in the
industry will be counter to anything you state below and if a consortia
for mechanisms is required for fast track because of market pressures as
I am involved I assure you it will work very closely with the IETF for
sure. I think we have alternatives and the scenarios are key. One
thing I do ask just for thought. Please ask and request IESG members
not act out on assumptions or read between the lines of work we do. If
they have a concern be forthright and ask directly. I really hate to
see us do a bunch of work in v6ops and be second guessed without clear,
direct, and crystal communications as below. Often the chairs too can be
at the receiving end of such mis-communications and not just us regular
members of a working group.
Thanks Again.
Sincerely,
/jim
[Honor, Commitment, Integrity]
> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no]
> Sent: Tuesday, November 19, 2002 6:11 PM
> To: Bound, Jim
> Cc: v6ops@ops.ietf.org
> Subject: On NGTRANS, transition mechanisms and consortia
>
>
> Jim,
>
> this is in reply to your note of November 14, entitled "IPv6
> Transition
> Mechanisms and Industry Transition Consortia".
>
> I'm attempting to share with you thoughts on three issues:
>
> - The transition between NGTRANS and v6ops
> - The status of transition mechanisms in the IPv6 space
> - The relationship between the IETF and industry consortia
>
> Since these are topics of significant interest to the v6ops
> community, this
> message is being CCed to the v6ops mailing list.
>
> Since our meeting in San Jose, I have attempted to get the
> story of the
> NGTRANS/v6Ops transition straight; while I have not
> completely succeded, I
> beleive I now understand the logic behind the decisions made.
>
> In the June timeframe, some features of the NGTRANS effort
> were becoming
> painfully clear:
> - We had multiple transition mechanisms on the standards
> track. Some of
> these were proving to have significant problems when tried in
> practice.
> - We had multiple additional transition mechanisms being
> worked on, some of
> which overlapped in functionality with existing mechanisms
> (possibly fixing
> problems), some of which added significant new functionality
> - yet there
> was little effort to position those new protocols as updates to or
> replacements for the existing mechanisms.
> - We detected a growing lack of consensus in the community
> about whether
> the burden of supporting specific mechanisms was worth the
> cost of adding
> more of those.
>
> In such a situation, it seemed appropriate to focus the
> efforts of the
> community, if possible, on increasing the understanding of
> what mechanisms
> were required in various scenarios.
> Several possible ideas were being floated, including:
> - Rechartering the NGTRANS working group
> - Establishing a new group with responsibility for "scenario
> modelling" only
> - Establishing a new group with both "scenario modelling" and
> parallel work
> on the transition mechanisms in progress
>
> After discussion between the ADs, the middle alternative was
> chosen; this
> seemed to give the cleanest positioning of the new WG.
> This was not done in a particularly clear or fashion, for which the
> relevant AD must bear responsibility.
>
> This had as a consequence the dropping until further notice
> of WG support
> for development of new transition mechanisms; the logic
> behind this was
> that until one knew the scenarios envisioned, it was hard to
> know what
> requirements existed for the new (and old!) transition mechanisms.
>
> The IETF never required the work on mechanisms to stop; since
> we're an
> organization of volunteers, we weren't even taking resources
> away from the
> documents - even the ngtrans mailing list remained open.
> But a logical inference was that the IESG would be unlikely
> to promote new
> documents to the standards track until the scenarios and resulting
> requirements were defined in v6ops.
>
> There are several ways around this if you want things published:
> - Publish through other mechanisms than the RFC process
> - Publish as Experimental RFC
> - Plead with the ADs to sponsor the mechanisms for standards
> track based on
> their obvious merits (identifying the mechanisms they obsolete)
>
> One last word on industry consortia, transition and the IETF:
> The IETF is quite aware that not all work fits within the
> organization. The exact borders are continuously the subject
> of intense debate - but it
> is clear that the elements that deal directly with business
> issues are
> outside the borders. We are normally happy to leave these
> issues to others.
>
> However, the IETF is also required to take the desire of
> business for an
> Internet that works well; this includes making mechanisms
> available in a
> timely fashion that support a reasonable subset of the
> business models on
> the market.
>
> In some cases, non-IETF consortia have worked very closely
> with the IETF,
> making the IETF standards process part of the work supported by the
> consortium.
>
> In other cases, consortia have taken up work that never
> belonged in the
> IETF (voice over MPLS and HTML are merely two examples).
>
> In the IPv6 transition case, I am sure we will find ways to
> work together,
> if all work towards a common understanding of the problems involved.
>
> With hope for a better understanding in the future,
>
> Harald
>
>
>
>