Benjamin Kaduk has entered the following ballot position for draft-ietf-lsr-isis-invalid-tlv-02: Yes
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-lsr-isis-invalid-tlv/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The shepherd writeup is a bit unclear as to why Proposed Standard is the right document status (vs., e.g., Informational). I guess it's desired to have the Updates: relationship to the indicated documents, which essentially forces it to be standards-track. On the other hand, perhaps the sense that ignoring a TLV that is specifically disallowed (as opposed to "merely" unrecognized) is itself a newly specified requirement, in which case the status as Proposed Standard makes sense for that reason. It might be worth a little more clarity on which (if either) of these scenarios are intended. Section 1 A corollary to ignoring unknown TLVs is having the validation of PDUs be independent from the validation of the TLVs contained in the PDU. nit: this doesn't exactly seem like a "corollary" specifically, but rather a choice that [ISO10589] made (and which keeps some overall sense of consistency between PDU and TLV handling). Section 3.1 [ISO10589] defines the behavior required when a PDU is received containing a TLV which is "not recognised". It states (see Sections 9.3 - 9.13): This is Sections 9.5 (not 9.3) to 9.13 in the copy I have. Section 3.2 Similarly, the extensions defined by [RFC6233] are not compatible with the behavior defined in [RFC5304], therefore can only be safely enabled when all nodes support the extensions. nit: I'd argue that technically the extensions are *defined* by 6232, even though 6233 is what makes their nature (as "allowed in purge") easily discoverable. It is RECOMMENDED that implementations provide controls for the enablement of behaviors that are not backward compatible. We also specifically want the ability to generate but not process/require at least some of them, right? Is that worth calling out in addition to just "controls for the enablement"? Section 3.3 a given sub-TLV is allowed. Section 2 of [RFC5305] is updated by the following sentence: "As with TLVs, it is required that sub-TLVs which are disallowed MUST be ignored on receipt.". Do we want to say where this logical insertion occurs? Section 3.4 The correct setting for "LSP" is "n". This document updates [RFC6232] by correcting that error. It's slightly interesting that there doesn't seem to be a corresponding Errata Report (but may not be worth doing anything about given that this update is about to be approved). Section 8.1 It's not entirely clear that RFC 7356 is referenced in a normative manner. _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
