RE: On NGTRANS, transition mechanisms and consortia

["Bound, Jim" <Jim.Bound@hp.com>]

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