Thanks Med! Alvaro.
On 1/31/17, 9:54 AM, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> wrote: About the text you proposed below… The LISP Packet Type Registry (4.1, not 5.1) has only 15 possible values, 7 of which are assigned/reserved by this document, rfc6833bis assigns 3 more values, and this document mentions 5 potential extensions (“new message types are proposed in [I-D.ietf-lisp-ddt], [I-D.zhao-lisp-mn-extension], [I-D.boucadair-lisp-bulk], [I-D.ermagan-lisp-nat-traversal], or [I-D.boucadair-lisp-subscribe]” [*])…bringing the total up to 15. Even if not all these new drafts make it, the LISP Packet Type Registry will soon have no more values to assign. The result will be that the Sub-Types (in the LISP Shared Extension Message Type) will be used for production [1]. [Med] Agree. IOW, I don’t think you need a transition mechanism. Instead, I think you need to recognize that the Sub-Types will be used for production deployments. Suggestion: consider changing the registration policy from FCFS to something where part of the space requires Standards Action, or maybe RFC Required or even Expert Review. The result of FCFS is that anyone can request a value and get it: “There is no substantive review of the request, other than to ensure that it is well-formed and doesn't duplicate an existing assignment.” [rfc5226] [Med] The motivation for using FCFS is to avoid imposing heavy constraints on designers to register their extensions. Also, given that we have 4096 sub-type values, the full range cannot be consumed completely even with a FCFS policy. That’s said, I agree with you it might be more safe to secure a range for assignments via Standards Action (e.g., 0-1023) and leave the 1024-4095 for FCFS. I can make such change.
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
