Hi Suressh, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Suresh Krishnan [mailto:[email protected]]
> Envoyé : mercredi 1 février 2017 22:30
> À : The IESG
> Cc : [email protected]; Luigi Iannone; lisp-
> [email protected]; [email protected]; [email protected]
> Objet : Suresh Krishnan's Discuss on draft-ietf-lisp-type-iana-04: (with
> DISCUSS)
> 
> Suresh Krishnan 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:
> ----------------------------------------------------------------------
> 
> * Section 4.1
> 
> "The value 15 is reserved for Experimental Use [RFC5226]"
> 

[Med] As discussed with Alvaro and Ben, that sentence was already removed from 
my local copy.  


> I don't think this document should be reserving value 15 for Experimental
> use based on its stated intentions "a LISP shared message type for
> defining future extensions and conducting experiments".
> 
> RFC3692 defines the experimental values as
> 
> "  Mutually consenting devices could use
>    these numbers for whatever purposes they desire, but under the
>    understanding that they are reserved for generic testing purposes,
>    and other implementations may use the same numbers for different
>    experimental uses."
> 
> which means that devices may use any of the sub-types under 15 for
> experimentation and potentially collide with the "extension" uses.

[Med] ...but this draft says that the sub-type is to be registered with IANA. 
The registration procedure reduces the collision probability. Authors of 
extensions are aware of that risk: they should not squat an already registered 
value, they are invited to register their value, and IANA will notify them if a 
duplicate value is already present in the registry. The use of FCFS is meant to 
facilitate the assignment of codepoints and encourage authors to declare their 
extensions without requiring heavy and procedures. 

We may be tempted to define a range for "Private Use" too, but we didn't done 
that to avoid interop issues that may arise from code that is not intended to 
be tested in environments other than closed one. 

> 
> I would propose that a sub range of the sub-types (e.g. 2048-4095) under
> type 15 be reserved for experimentation and the rest of the range
> (0-2047) for extensions be specified using some other IANA policy (e.g.
> FCFS as specified in the document).
> 
> 
[Med] FWIW, I already agreed with Alvaro to make the following change:
0-1023: Standards Action
1024-4095: FCFS

Wouldn't that be sufficient? 

Thank you.


 

_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to