Ketan Talaulikar has entered the following ballot position for draft-ietf-lisp-rfc6831bis-08: 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: ---------------------------------------------------------------------- Thanks to the authors and the WG for their work on this document. I support the update from experimental to PS for this specification that has implementations and deployment. Note: Most of my review focuses on the changes since RFC6831 but it also goes beyond that a bit given the change from experimental to PS: https://author-tools.ietf.org/iddiff?url1=rfc6831&url2=draft-ietf-lisp-rfc6831bis-06&difftype=--html Thanks for taking care of my discussion points from the original ballot. This is now updated to reflect only the open items. Note: this is not an editorial review but I see that the documents has several nits that the authors should catch and fix. Please find below some comments on this document, starting with those that are document-wide: 1) On BCP 14 key word usage, document-wide: this is an observation about the document as a whole rather than a defect at any one line. The body carries hardly any key words; most importantly none of them in a forwarding-procedure section. Now, lowercase prose is perfectly capable of carrying normative meaning, but several of them have interoperability implications for which BCP14 keywords would be appropriate. I am not going to get into individual cases, so please audit them and replace where there is an interoperability aspect and for things that are in scope of this document's specifications. 175 Therefore, there are only operational (and not protocol) changes for 176 PIM-ASM [RFC7761], Multicast Source Discovery Protocol (MSDP) 177 [RFC3618], Anycast-RP [RFC4610], and PIM-SSM [RFC4607]. BIDIR-PIM 178 [RFC5015], which typically does not run in an inter-domain 179 environment, is not addressed in depth in this document. <minor> Four protocols are cited side by side in this sentence for the same reason -- that they need operational rather than protocol changes -- and they are classified differently. RFC 7761 (PIM-ASM) and RFC 4607 (PIM-SSM) are normative; RFC 3618 (MSDP) is informative; RFC 4610 (Anycast-RP) is normative. There is no principle distinguishing them, and RFC 3618's classification is explained by the question on the RFC 6832 reference at line 1414 rather than by the reference test. Please consider a single pass over each of these, their implication, any change or impact, and then the way they are referenced. <EoRv06> _______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
