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

From: Tony Przygienda <[email-masked]>
Date: Wed, 05 Feb 2003 01:56:43 +0100

Everyone,

we had "behind the scenes" a pretty good conversion (we kept the group 
initially small to make progress)
on some philosophical issues brought up by IAB concerning the 
'experimental' draft. The consensus
boiled down to multiple points that at this point in time will need an 
open discussion on the list
to make sure the significant participants are happy with the result 
forthcoming:

. we change all references from 'proprietary' to 'experimental' so 
instead of encouraging vendors
   to 'hide' things they will lay them out in the open in an informal 
way so the deploying parties
   have a chance to judge the risks vs. gains. We add a section to the 
draft
   saying something along the lines of
                 "Implementers SHOULD openly document their use of the 
Experimental TLV
       in an Experimental status RFC."

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

. A section that is equivalent to 'proceed at your own risk' will be 
necessary, basically saying
 that interoperability of such an experimental extension is not 
guaranteed to interoperate with
 other implementations and may pose unknown security risks. In
 connection to the security risk, the section will emphasize again that 
without documentation
 for an experimental TLV, the operators have not even the possiblity to 
understand possible problems
 in terms of security and interoperability they are facing when 
deploying an experimental TLV.

            thanks

            -- tony

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 5 Feb 2003 08:50:03 -0500

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

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

Ran
[email-masked]

---

From: Alex Zinin <[email-masked]>
Date: Thu, 6 Feb 2003 10:12:28 -0800

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:

>           as an RFC.  This is normally just an email note.

publish as an Informational RFC...

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

> operators/users are able to make informed decisions about what to deploy

Amen.

Alex