> It is unusual for an RFC to refer to itself as authoritative. It is also not > particularly helpful to use those words.
Then please provide direction and more importantly words. > In particular, values from the range 9 - 14 may be assigned by other > standards action without updating 6833bis. So should we keep it? > (side-note, there is an long ongoing discussion on the IETF and rfc-interest > list as to when documents should be marked as updating other documents. I am > refering here to actual updates, rather than to any question of marking the > metadata.) Please advise what to do. Or more to theh point, can you respond to each of Mohamed’s comments providing your opinion? Dino > > Yours, > Joel > > On 4/27/17 1:51 PM, Dino Farinacci wrote: >>> Hi Dino, all, >>> >>> Thank you for sharing this update. >>> >>> I have some comments about the following text: >>> >>> == >>> This section will be the authoritative source for allocating LISP >>> Type values and for defining LISP control message formats. For >>> Shared Extension types, see [RFC8113]. Current allocations are: >>> >>> Reserved: 0 b'0000' >>> LISP Map-Request: 1 b'0001' >>> LISP Map-Reply: 2 b'0010' >>> LISP Map-Register: 3 b'0011' >>> LISP Map-Notify: 4 b'0100' >>> LISP Map-Notify-Ack: 5 b'0101' >>> LISP Map-Referral: 6 b'0110' >>> LISP Info-Request/Reply: 7 b'0111' >>> LISP Encapsulated Control Message: 8 b'1000' >>> Not Assigned 9-14 b'1001'- b'1110' >>> LISP Shared Extension Message: 15 b'1111' [RFC8113] >>> == >>> >>> · 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, RFC8113 is >> authoriative for Type 15 sub-type values. >> >>> · An IANA section is to be added to the bis document. >> >> Yes, I can do that since the packet formats moved from RFC6830 to RFC6833bis. >> >>> · 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. >> >>> · “LISP Map-Notify-Ack: 5 b'0101'” and “LISP >>> Info-Request/Reply: 7 b'0111'” are not assigned yet by IANA. >>> The document should include requests in the new IANA section; these values >>> can be indicated as preferred values according to RFC8113: >> >> I will do that for Map-Notify-Ack since it is part of standard protocol. I >> cannot do it for type 7 since the NAT-traversal is not a working group >> document (yet). >> >>> 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). >> >>> · The document may include a discussion about the exhaustion of >>> type values. That discussion can remind the reader that an extended space >>> is provisioned for that purpose : “15.subtype(0-1023)”. >> >> It may but should it? Why don’t we cross that bridge when we come to it? >> >>> · The document should IMO include some text to encourage designers >>> to use the “15.subtype(1024-4095)” in early stages of extension >>> specifications. The WG will decide whether a type code will be assigned in >>> the standard track ranges. >> >> I will add that. Thanks. >> >> Dino >> >>> >>> Thank you. >>> >>> Cheers, >>> Med >>> >>> De : lisp [mailto:[email protected]] De la part de Dino Farinacci >>> Envoyé : vendredi 14 avril 2017 20:34 >>> À : [email protected] list >>> Objet : [lisp] Fwd: I-D Action: draft-ietf-lisp-rfc6833bis-03.txt >>> >>> Folks, since RFC8113 was recently published, I made this small change to >>> draft-ietf-lisp-rfc6833bis-03: >>> >>> <image002.png> >>> >>> Thanks, >>> Dino >>> >>> >>> Begin forwarded message: >>> >>> From: [email protected] >>> Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-03.txt >>> Date: April 14, 2017 at 11:32:14 AM PDT >>> To: <[email protected]> >>> Cc: [email protected] >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Locator/ID Separation Protocol of the IETF. >>> >>> Title : Locator/ID Separation Protocol (LISP) Control-Plane >>> Authors : Vince Fuller >>> Dino Farinacci >>> Albert Cabellos >>> Filename : draft-ietf-lisp-rfc6833bis-03.txt >>> Pages : 38 >>> Date : 2017-04-14 >>> >>> Abstract: >>> This document describes the Control-Plane and Mapping Service for the >>> Locator/ID Separation Protocol (LISP), implemented by two new types >>> of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server >>> -- that provides a simplified "front end" for one or more Endpoint ID >>> to Routing Locator mapping databases. >>> >>> By using this control-plane service interface and communicating with >>> Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and >>> Egress Tunnel Routers (ETRs) are not dependent on the details of >>> mapping database systems, which facilitates modularity with different >>> database designs. Since these devices implement the "edge" of the >>> LISP infrastructure, connect directly to LISP-capable Internet end >>> sites, and comprise the bulk of LISP-speaking devices, reducing their >>> implementation and operational complexity should also reduce the >>> overall cost and effort of deploying LISP. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-03 >>> https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6833bis-03 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6833bis-03 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> lisp mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lisp >> >> _______________________________________________ >> lisp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp >> _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
