Éric Vyncke has entered the following ballot position for draft-ietf-lsr-multi-tlv-13: 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-lsr-multi-tlv/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-lsr-multi-tlv-13 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks (and congratulations) to Yingzhen Qu for the shepherd's detailed write-up including the WG consensus (and the history) *and* the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS (non-blocking) ### Abstract s/New technologies are adding new information/New specifications and IS-IS extensions are adding new information/ ### Section 1 Unsure whether IS-IS is used over the public Internet in `The continued growth of the Internet` :-) In the first paragraph, it is unclear whether the 255 applies per TLV or for the whole set of TLV (even if the reader can have a guess, let's be clear). s/Any future *document* *which* proposes/Any future *IETF specification* *that* proposes/ ? Should there be an exhaustive list rather than `Some examples of this are` ? Please introduce "LSP" before first use. Strongly suggest to indicate that the MP-TLV capability is negotiated (as I had big ??? in mind until section 7). ### Section 4 Bear with my lack of IS-IS expertise, but can a IIH message be fragmented in several layer-2 packets ? If so, how can a node differentiate between recent and old TLV in "MP-TLV" bundle (i.e., are these TLV parts of a unique bundle or separates ones) ? `Breaking of a single sub-TLV or other data unit across TLVs MUST NOT be done` what is the expected behavior when receiving such a TLV ? ### Section 5 Does the basis IS-IS specification cover the case when several TLV having the same Type have conflicting values ? Should there be text about this corner case ? ### Section 6 Be more assertive and use "MUST" in `Therefore any new codepoints defined by future protocol extensions will explicitly indicate the applicability of MP-TLV procedures to the new codepoints` ### Section 7 I find this section under-specified , e.g., isn't the following wishful thinking `It is presumed that if such support is provided that it applies to all relevant codepoints`? Why not a "MUST" in `SHOULD include this sub-TLV in a Router Capability TLV` ? ### Section 8 s/presence of routers *which* do not correctly/presence of routers *that* do not correctly/ Please explain the consequences (or when it can be bypassed) of the 2 "SHOULD". ### Section 9.1 Suggest adding informative references to the IANA registries URIs. ### Section 9.2 Should there be guidance for the designated experts ? ## NITS (non-blocking / cosmetic) ### Section 1 `PDU` acronym is never used, so do not introduce it ;) _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
