Re: [Isis-wg] new version of the proprietary/experimental draft ...

I'd like to support suggested change to the document.

A bit of clarification to what Ran described below to
make sure we have a complete picture:

Wednesday, February 5, 2003, 5:50:03 AM, RJ Atkinson wrote:
> On Tuesday, Feb 4, 2003, at 19:56 America/Montreal, Tony Przygienda
> wrote:
>> . given that we have RFC 2026, a nice track exists where the 
>> publication of the experimental
>> TLV is not even bound by having made it into the workgroup. The 
>> authors can and should send
>> the experimental TLV description directly to the IETF editor so
>> the hurdle to document the work is absolutely minimal. That will merit 
>> a section in the document
>> as well.

> s/IETF Editor/RFC Editor/

> The process is basically this:

>         - One writes up one's experimental TLV in an Internet-Draft.  That
>           Internet-Draft does not need to give the IETF rights to create any
>           derivative works or give away any IPR.  The I-D should say that it is
>           describing an "experimental protocol extension to IS-IS" (or similar 
> words)
>           in order to avoid creating confusion about whether it is an IETF
>           standards-track spec.
>         - One submits the I-D as draft-<lastname>-<title>-00.txt
>         - Then the author of the I-D asks the RFC Editor to publish the I-D
>           as an RFC.  This is normally just an email note.

publish as an Informational RFC...

>         - The RFC-Editor will pass the I-D to the IESG for a review (which
>           MUST be completed by IESG in a defined period of time) where the IESG
>           is supposed to ONLY ensure that the document is NOT an "end-run"
>           around active standards-track work already ongoing inside IS-IS WG.

not only standards-track work, any work inside the WG.
Also, we usually do the end-run check by referring the document
to the WG, i.e., sending a note to the WG asking to check.

>         - If no problem arises, then the RFC-Editor will publish as an RFC.

> So this lets folks define implementation-specific extensions and get 
> non-conflicting
> TLV space for those extensions, but does so in a way that lets the 
> operators/users
> have a decent chance of understanding what the extension is doing so the
> operators/users are able to make informed decisions about what to deploy
> in their networks.

Amen.

Alex

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg