Roman Danyliw has entered the following ballot position for draft-ietf-lsr-isis-area-proxy-10: Discuss
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-area-proxy/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ** Section 4.3. Do all the candidates need the Area Proxy System Identifier TLVs need the same system identifier? -- Section 4.2 says “For consistency, all Area Leader candidates SHOULD be configured with the same Proxy System ID, Proxy Hostname, and any other information that may be inserted into the Proxy LSP.” -- Section 4.3.1 says: “All candidates advertising the Area Proxy System Identifier TLV MUST be advertising the same system identifier.” The first statement suggests that consistency might not always be required, but the second statement is clear that it always must be the same identifier. ** Section 8. The following statement doesn’t appear to be accurate. 8. Security Considerations This document introduces no new security issues. Security of routing within a domain is already addressed as part of the routing protocols themselves. This document proposes no changes to those security architectures. -- Aren’t a few the filtering activities described in Section 5.2 security-related? -- What are the relevant pointers to IS-IS security considerations? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Alexey Melnikov for the SECDIR review. ** Section 4.3.1 However, before withdrawing the Area Proxy System Identifier, an implementation SHOULD protect against unnecessary churn from transients by delaying the withdrawal. The amount of delay is implementation-dependent. Are there any guidelines on how the delay period should be computed? ** Section 4.4.4. An entry for a neighbor in both the IS Neighbors TLV and the Extended IS Neighbors would be functionally redundant, so the Area Leader SHOULD NOT do this. Under what circumstances would this advice be ignored (i.e., why not a MUST)? ** Section 4.4.5 and 4.4.6 describe various behavior where fields “SHOULD” be copied. What governs the choice of not copying these fields? Would operators be impacted in troubleshooting or even operations if different implementations applied this advice differently? Would it be up to local configuration? Later sections in 4.4.* also have “SHOULD” behavior as well where the reason for not following the behavior is not clear. _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
