Hi Dino, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Dino Farinacci [mailto:[email protected]] > Envoyé : vendredi 28 avril 2017 19:53 > À : BOUCADAIR Mohamed IMT/OLN > Cc : [email protected] list > Objet : Re: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-03.txt > > > Hi Dino, > > > > Thank you for replying. > > See responses. I cut out some email where I had no response. > > >>> · At least the first sentence should be reworded to be aligned > >> with RFC8113 (which is the reference for allocating LISP type values). > If > >> you want the bis document to be authoritative for that, the only way > for > >> that is to merge RFC8113 in the bis document. > >> > >> No, not really. RFC6833bis is authoritative for LISP Type values, > > > > [Med] No. For example, the allocation of a new LISP type will require a > standard track document as per RFC8113. Such considertaons are not covered > in the the bis document. > > The type values that are listed are for messages that ARE ALREADY in the > protocol. So please tell me what part of the wording you don’t agree with. > [Med] OK. Your proposed modification says "summarizes for IANA the LISP Type codes assigned by this document". * Assignment are made by IANA not documents. * NEW assignment requests are to be included in a dedicated IANA sub-section. > > RFC8113 > >> is authoriative for Type 15 sub-type values. > > > > [Med] Not only for that, but also for allocating future type values. > > RFC8113 should not be used for future Type values. [Med] I'm afraid there is a misunderstanding here. Please check https://www.iana.org/assignments/lisp-parameters/lisp-parameters.xhtml#lisp-packet-types. The bis should follow RFC8113 for new assignment requests. Only for sub-type > values for Type 15. Beacuse that is what the RFC documents. > > > > > > >> > >>> · I wouldn’t list “Not Assigned 9-14 b'1001'- b'1110'” here > >> because these values can be allocated in the future. I would avoid > >> mismatches with the IANA registry. > >> > >> When they are assigned, this document will change to reflect the new > >> values. We want to be explicit to tell people they are not assigned > versus > >> not being listed at all. > > > > [Med] We have a registry for that. This information will be obsolete > when new assignments show up. I reiterate my comment. > > Yes, and the registry points to an RFC. And it should be RFC6833bis which > is on standards track. [Med] My point Dino is that we need to avoid including stale information in RFCs. We have other tools to better track assignments than RFC. > > > I > >> cannot do it for type 7 since the NAT-traversal is not a working group > >> document (yet). > > > > [Med] then, please remove Info-Request/Reply from this document. > > NAT-traversal is a critical part of the LISP architecture when IPv4 is > used as the underlay. And there are several implementations of NAT- > travesal, so this is a case where the Info-Request/Info-Reply is an > existing mechanism. > [Med] I'm aware of that, Dino. My comments are: * Info-Request/Info-Reply is not defined in this document. * There is no reference where Info-Request/Info-Reply. If you think that Info-Request/Info-Reply is a mechanism that should be in the base spec, then consider including that part of the spec in the bis document. Lacking that, I reiterate my comments. > > > >> > >>> The values in the ranges 5-7 and 9-14 can be assigned via Standards > >>> Action [RFC5226]. Documents that request for a new LISP packet type > >>> may indicate a preferred value in the corresponding IANA sections. > >> > >> I will add this text. Thanks. > >> > >>> · “LISP Map-Referral: 6 b'0110'” is about a temporary > >> assignment not a permanent one. > >> > >> No it is permanent because LISP-DDT is progressing to RFC (standards > >> track). > > > > [Med] the IANA registry says the following: "LISP DDT Map-Referral > (TEMPORARY - registered 2017-04-19, expires 2018-04-19)". I know that > value will be permanent assigned when DDT is in the standard track, but we > are not yet there. > > That is going to change in the coming weeks since LISP-DDT is about to > come to RFC 8111. [Med] The RFC-to-be 8111 can't change that for the following reason: Internet Engineering Task Force (IETF) V. Fuller Request for Comments: 8111 VAF.NET Internet Consulting Category: Experimental D. Lewis ^^^^^^^^^^^^ ISSN: 2070-1721 V. Ermagan Cisco Systems A. Jain Juniper Networks A. Smirnov Cisco Systems April 2017 Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Type assignments require "Standards Action". > > Your subsequent email said you have concerns with my update. So please be > more specific and include your comments in another email. [Med] My pending comments are: * Add a new IANA sub-section for new type assignment requests. This section should include a request for "Map-Notify-Ack" with a preferred value of 5. * Remove "For Future Assignment" entry from the table of Section 4.1 * Remove LISP Info-Request/Reply from Section 4.1. * Consider changing the "Current allocations are" wording as this may not be accurate in the future. > > Thanks, [Med] Thank you. > Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
