Subject: On NGTRANS, transition mechanisms and consortia

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 19 Nov 2002 18:10:47 -0500

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

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 19 Nov 2002 21:41:41 -0500

> Mechanisms and Industry Transition Consortia".

<mb> part of mail cut</mb>
> 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

I proposed this as a way to revolve/help resolve the transition mechanisms
drop:
- many mechanisms are documented, are implemented and used (to various
levels)
- I agree with the desire to make a short list.
- but it seems to me to soon to conclude that all mechanisms that will not
be in the short list are bad or broken or not useful.
- all this is also based on the assumption that we will agree on the
scenarios and requirements, which is not always the case happening in the
ietf.

on the other hand, there are many implementations, and those who are
developing are using expired drafts. Many mechanisms might be of not short
term use, or more specific use, or might be perceived as not the right
mechanism from some people.

I would propose that we have a track to publish many of those mechanisms as
experimental RFC. After some period of time (might be years), we could
revisit to put them back on the standard track. That way, we will have a
stable document where implementors, users, the community could use, while
keeping the goal of a short list for standard track.

Marc.

<mb> part of mail cut</mb>