Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT)

[<[e-mail]>]

Hi Alvaro, all,

I confirm that the intended status is Experimental. Joel already explained why the WG wanted to create this registry now. 

See more inline.

Cheers,
Med

> -----Message d'origine-----
> De : Joel M. Halpern [mailto:[e-mail]]
> Envoyé : lundi 30 janvier 2017 22:53
> À : Alvaro Retana; The IESG
> Cc : [e-mail]; Luigi Iannone; lisp-
> [e-mail]; [e-mail]
> Objet : Re: Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with
> DISCUSS and COMMENT)
> 
> With regard to status, I think we can work with you.
> But we really want to establish the registry now.
> We already have proposals for code points beyond the experimental RFCs,
> and requests for room to experiment without writing an RFC.
> 
> As far as I can tell, the Working Group intent is that the registry
> allow reservation by experimental and informational RFCs, not just
> standards track RFCs.  We can fix that.
> 
> With regard to the revision to the base documents, to get them on the
> standards track, one of the important fixes is to stop claiming that the
> RFC defines all the values, and just update the registry entries where
> appropriate to reference the new RFC (once we have it.)
> 
> The rush is simply that it is already getting hard to keep track.  We
> should have established a registry in the first place.  So we are doing
> so now.
> 
> On 1/30/17 4:46 PM, Alvaro Retana wrote:
> > Alvaro Retana has entered the following ballot position for
> > draft-ietf-lisp-type-iana-04: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-
> criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-lisp-type-iana/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > I have a couple of points I think we should DISCUSS before moving this
> > document forward: the intended status and the definition of the
> > registry.
> >
> > (1) Intended Status: The Datatracker indicates that the Intended RFC
> > status for this document is Proposed Standard (as does the Shepherd
> > WriteUp and the IETF LC), but the header on the document says
> > Experimental.  I note that the document header was changed after a
> > discussion on the WG list resulting from the RTG Directorate review [1],
> > but that happened after the WGLC.  Which is the right status?
> >
> > (2) LISP Packet Types Registry Definition: It seems very odd to me that
> > the LISP Packet Types Registry uses Standard Action as the registration
> > policy given that the LISP work is currently Experimental -- and that
> the
> > other references in it would in fact be from an Experimental RFC
> > (rfc6380).  I know there's work on rfc6830bis (in the Standards Track),
> > but I think it would be better to have this registry defined in the base
> > specification (rfc6833bis, in this case)...or to wait for the
> publication
> > of that document to progress this one.
> >
> >
> > I think there's nothing procedurally wrong with having an Experimental
> > RFC define a Standard Action Registry and populate part of it with
> > references to Experimental RFC.  However, the solution just doesn't seem
> > clean to me -- so I would like to hear the justification for the rush
> > (and not waiting for rfc6380bis/rfc6388bis).
> >
> > I have no issue with a document making use of the Code Point to describe
> > the new LISP Shared Extension Message Type (without creating the
> > Registry).  But given that the base LISP specification is still
> > Experimental, then this document should be too.  There shouldn't be an
> > issue with changing the Status of this document (in-place) once
> > rfc6380bis/rfc6388bis progress.
> >
> >
> > There's also the issue that RFC6830 (and rfc6833bis) contain the
> > following text: "This section will be the authoritative source for
> > allocating LISP Type values..."   Which means that (if the registry is
> to
> > be defined here), this document should at least Update RFC6830...
> >
> > In summary, I think that the correct Status for this document is
> > Experimental.  I also think that it would be better to wait for
> > rfc6833bis to define the Registry.
> >
> >
> > [1]
> > https://mailarchive.ietf.org/arch/msg/lisp/m1EicCexdX1GI183pba-
> mcHJM7g/?qid=ada479dce3c434bfaf948b0ee8240996
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > a. The Introduction justifies the extension as being used for
> > experiments: "Because of the limited type space [RFC6830] and the need
> to
> > conduct experiments to assess new LISP extensions, this document
> > specifies a shared LISP extension message type".  It seems clear later
> in
> > the text that the intent of the new message type is not just for
> > experimentation, but that in fact the intent is for new functionality to
> > be deployed using it.  Is that correct?  If it is, then please make it
> > clear -- if not, then I would like to see how the authors propose a
> > transition to happen between the experimental space and the production
> > one.

[Med] What about adding this NEW text: 

   Some LISP extensions that make use of the LISP shared extension
   message type may become eligible for an assigned LISP packet type
   (Section 5.1).  Once a LISP packet type is assigned to such LISP
   extension, an implementation SHOULD NOT use the LISP shared
   extension message type.

   To ensure backward compatibility during a transition period, an
   implementation MAY support a configuration parameter to instruct
   whether the LISP extension using the shared extension message is to
   be sent simultaneously with the LISP extension message using the
   assigned LISP packet type.  The default value of that configuration
   parameter is to disable sending both messages.  The use of the two
   message formats increases backward compatibility, but it has some
   implications on the LISP control load.  Such implications are
   expected to be limited in time and are fully under the control of the
   entity operating a LISP domain.

> >
> > b. The IANA Considerations Section says that "The value 15 is reserved
> > for Experimental Use [RFC5226]."  But it is being assigned to the new
> > LISP Shared Extension Message.
> >

[Med] I deleted that sentence.