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

Re: Request to Publish ISATAP



Hi Fred,

Let me first say, it should be clear to all that I am struggling
with process details. But, how can *anyone* be expected to get
things exactly right when the NGTRANS closing has come upon us
so quickly and the closing procedures have been so nebulous?
I can certainly understand your frustration, and I think we're
all struggling with some of the process details here.  Very
few of us have been through the shutdown of a WG before, so
we are learning the process as we do it.

The new charter seems restrictive to the point of requiring
authors to leap high buildings just to get their documents
recognized - even though some (like ISATAP) have been out in
the public discussion for over *two years* now.
I hope it is clear that the restrictiveness of the current
v6ops charter is intentional.  We are not chartered to publish
any new standards track transition mechanisms until we understand
the most likely deployment scenarios, and have completed the
analysis to determine what transition mechanisms are actually
needed.  The analysis is well underway for the 3GPP and
Unmanaged areas, and the Enterprise and ISP areas are making
progress on scenarios.

The chairs have asked for transition scenario documents, and
one has been written, presented and revised for ISATAP. I am
certain that ISATAP can provide useful benefit to some of the
other operational areas as well, and additional scenario documents
could be written.
If I recall correctly, these documents were requested by the
ngtrans chairs.  I think that the ISATAP document, in particular,
will provide useful input to the Enterprise design team.  If
you think that ISATAP is applicable to the scenarios raised in
the 3GPP, Unmanaged or ISP documents, you may want to discuss
that on the v6ops list or with the authors of those documents.

But again, how high does an author need to jump
to get on your radar screen??
ISATAP is already on the radar screen.  We're just not ready to
publish any new mechanisms until their applicability is demonstrated
by the scenario/analysis work.

If this document can't go standards
track right now, let's at least get it through as experimental
so we can prove to the community in due course that further
progression is warranted.
It is outside the scope of the v6ops WG to publish ISATAP as an
experimental RFC.  However, if you would like to do an individual
submission for publication as an experimental RFC, you should
first publish your final document, preferably with fixes to address
Itojun's issues, as an Internet-Draft.

Before you publish it, you should also make sure that it meets the
RFC editorial policies, found at:

http://www.rfc-editor.org/policy.html

Then, send mail to the RFC editor (rfc-editor@rfc-editor.org)
requesting that the RFC editor publish your individual submission
as an experimental RFC.

As part of their usual review process, the RFC editor will ask
the IESG if your document represents an end-run around any IETF
WGs and/or has any technical issues that should block its
publication.  At that point, our AD, Randy Bush, will probably come
to the v6ops WG chairs and ask us if we have any procedural or
technical objections to publishing the document as experimental.

At that point, Itojun and I will discuss this amongst ourselves
and with the WG, and we will return an answer to the IESG.

Let me know if you have any questions about this process.

In the meantime, the question on the table is whether ISATAP
should be published as a standards track document that
obsoletes part of RFC 2893, which we believe it should not.

Margaret