Roman Danyliw has entered the following ballot position for draft-ietf-lsr-isis-flood-reflection-11: 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-isis-flood-reflection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Rich Salz for the SECDIR review. ** Section 4.1 The Flood Reflection TLV SHOULD NOT appear more than once in an IIH. Why isn’t the guidance here “MUST NOT” appear since any subsequent, duplicate Flood Reflection TLVs are ignored? Same comment on the discovery Sub-TLV in Section 4.2, and Section 4.4 ** Section 4.3 Carries encapsulation type and further attributes necessary for tunnel establishment as defined in [RFC9012]. The Protocol Type sub-TLV as defined in [RFC9012] MAY be included. The first sentence suggests that the semantics of this field are defined by RFC9012. The second sentence suggests that it is optional to support the Protocol Type sub-TLV per Section 3.4.1 of RFC9012. This is confusing to me because RFC9012 supports a number of sub-TLVs to include the Protocol Type one explicitly called out. Is that the only sub-TLV supported for use? Editorial ** Section 1. Typo. s/Maintainance/Maintenance/ ** Section 1. Editorial. Consider using a less colloquial phrase than “Deployment-wise”. ** Section 4.2. Editorial. s/one ore more/one or more/ _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
