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

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