Murray Kucherawy 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: ---------------------------------------------------------------------- Thanks for the work put into this. I just have some minor editorial things to consider. Section 4.1 contains this text: The Flood Reflection TLV SHOULD NOT appear more than once in an IIH. A router receiving one or more Flood Reflection TLVs in the same IIH MUST use the values in the first TLV and it SHOULD log such violations subject to rate limiting. There are several other instances of this pattern in later sections. In each case I'm wondering why an implementer might choose to disregard the SHOULD NOT. Is there ever a legitimate reason to do so? If so, could we include an example? If not, should this simply be a MUST? Several of the other SHOULDs leave me wondering the same thing. Thanks for a good IANA Considerations section. Section 2 defines "Tunnel Endpoint" and "Hot-Potato Routing", but those terms don't appear anywhere in the document. _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
