I fixed all the comments you had in the COMMENT section. Dino
> On Sep 27, 2018, at 6:27 AM, Alexey Melnikov <[email protected]> wrote: > > Alexey Melnikov has entered the following ballot position for > draft-ietf-lisp-rfc6833bis-16: 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-rfc6833bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have a list of smaller points that should be relatively easy to address. The > two main ones: > > I believe [I-D.ietf-lisp-sec] needs to be a Normative Reference for this > document. This will address some of the issues raised by Benjamin, but will > also make description of various security bits meaningful. > > Similarly, in Section 5.6: > > I: This is the xTR-ID bit. When this bit is set, what is appended to > the Map-Register is a 128-bit xTR router-ID and then a 64-bit > site-ID. See LISP NAT-Traversal procedures in > [I-D.ermagan-lisp-nat-traversal] for details. > > This description makes [I-D.ermagan-lisp-nat-traversal] a normative reference. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Abstract > > 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 Control-Plane infrastructure, connect directly to LISP-capable > Internet end sites, and comprising the bulk of LISP-speaking devices, > reducing their implementation and operational complexity should also > reduce the overall cost and effort of deploying LISP. > > The last sentence: I've reread it several times and still not sure what it > says. > I suggest rewording, possibly breaking up into shorter sentences. > > In Section 5.1 the acronym SMR is used before it is defined (It is defined on > the next page). > > In 5.2: > > A: This is an authoritative bit, which is set to 0 for UDP-based Map- > Requests sent by an ITR. It is set to 1 when an ITR wants the > destination site to return the Map-Reply rather than the mapping > database system. > > This sentence seems to be missing a word at the end, because you don't return > "the mapping database system". > > In Section 5.6: > > T: This is the use-TTL for timeout bit. When set to 1, the xTR wants > the Map-Server to time out registrations based on the value in the > "Record TTL" field of this message. > > And what happens when it is 0? > > 11.4. LISP Address Type Codes > > Therefore, there is no longer a need for the "LISP Address Type > Codes" registry requested by [RFC6830]. This document requests to > remove it. > > IANA registries are not supposed to be removed, they typically declared closed > when not needed. Can you elaborate of whether this registry was ever used? > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
