Mike Bishop has entered the following ballot position for draft-ietf-lisp-rfc6831bis-14: No Objection
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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6831bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## Comments ### Prior DISCUSS: Security model The changes reduce my DISCUSS to a COMMENT by at least stating the trust model. The updated text claims ACLs "prevent spoofing," but that's slightly overstated; the ACL only filters on the claimed address, it doesn't prove it unless the underlay already does source validation (BCP 38) or the Join is authenticated. #### Section 9.1.1, paragraph 5 I'm unclear how an ITR decides when it should route via an mPETR. Is this clearly stated somewhere in this document or does it depend on RFC6832? ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos ### Section 3, paragraph 15 ``` infrastructure. It is likely a unicast PITR [RFC6832] hereafter referred to as uPITR in this document and an mPETR will be co- ``` This defines a new term inside the definition of a different term. Extract "uPITR" as its own term and definition. ### Grammar/style L180: “choses” should be “chooses”. L217 and L995: “LISP enabled” should be “LISP-enabled”. L471: “specificaiton” should be “specification”. L892: “a underlay distribution tree” should be “an underlay”. L1019 and L1136: “referred as” should be “referred to as”. L1142: “an uPITR” should be “a uPITR”, assuming "uPITR"'s pronunciation starts with "yoo" L1411 and the table of contents: “trade-Offs” should be “Trade-offs”. L1469: “an unicast underlay” should be “a unicast underlay”. New in -14. L1462: a stray period splits the sentence: “...deployed for PIM [RFC7761]. to mitigate risks...” L1470 and L1472: “Joins/ Prunes” and “Joins/ prunes” should be “Join/Prune”. New in -14. (Line numbers from .txt version of draft) ## Notes This review is in the ["IETF Comments" Markdown format][ICMF]. You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool _______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
