> 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. > > 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. 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. > 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. > >> >>> 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. Your subsequent email said you have concerns with my update. So please be more specific and include your comments in another email. Thanks, Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
