Mahesh Jethanandani has entered the following ballot position for draft-ietf-lsr-anycast-flag-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-anycast-flag/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to all the folks who have provided review comments on this document. In particular want to call out OPSDIR review comments from Juergen, and YANG Doctor comments provided by Joe Clarke. Some of these comments builds on the review they have provided. Section 1, paragraph 0 > An IP prefix may be configured as anycast and as such the same value > can be advertised by multiple routers. It is useful for other > routers to know that the advertisement is for an anycast prefix. I agree with Juergen that this section could do more to explain the motivation for the draft, and move all the implementation details to later sections. For example, and as Juergen asks, what are the implications of other routers not knowing about the advertisement? I know that Ran provided the explanation in his response, but it would be even better if that was added here. Section 2, paragraph 0 > An IP prefix may be configured as anycast and it is useful for other > routers to know that the advertisement is for an anycast prefix. I would encourage the authors to add some of the responses Ran gave to the OPSDIR review to be added in this document. In this case, the question asked was, what is prefix and where is it being applied? This might be obvious to "router folks" but it cannot be assumed that everyone knows what it means. Section 4.2, paragraph 0 > The following is the YANG module: Please reference all the RFC from which the module imports data from or refers to. For example, it could say - "This YANG module imports definitions from [RFC8349] and [RFC9129]". Section 6.2, paragraph 3 > There are a number of data nodes defined in this YANG module that are > writable/creatable/deletable (i.e., config true, which is the > default). These data nodes can be considered sensitive or vulnerable > in some network environments. Write operations (e.g., edit-config) > to these data nodes without proper protection can have a negative > effect on network operations. Specifically, the following subtrees > and data nodes have particular sensitivities/vulnerabilities: Is it true that this YANG module defines multiple data nodes? I can see only one. The last statement should also be corrected for its pluarity. Section 6.2, paragraph 3 > As specified in Section 2, the AC-flag and the N-flag MUST NOT both > be set to 1. An attacker or a misconfiguration that violates this > rule creates a configuration anomaly. The handling of such anomalies > is defined in Section 2. Modifications to these data nodes without > proper protection could prevent interpreting the IPv4 prefix as > anycast or node-specific. If the idea is to detect a configuration anomaly, why is that not detected using a "must" statement? Please add one. Otherwise, this hardly belongs in a Security Considerations section. Section 6.2, paragraph 3 > Some of the readable data nodes in this YANG module may be considered > sensitive or vulnerable in some network environments. It is thus > important to control read access (e.g., via get, get-config, or > notification) to these data nodes. Specifically, the following > subtrees and data nodes have particular sensitivities/ > vulnerabilities: Same issue with pluraity in this section. Section 6.2, paragraph 3 > Exposure of the OSPF link state database may be useful in mounting > Denial-of-Service (DoS) attacks. How is lsdb being exposed by this model? If not, please remove. ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. "I", paragraph 2 > OULD be logged as an operational error(subject to rate-limiting). The AC-fla > ^ It appears that a white space is missing. "I", paragraph 9 > eted according to OSPFv2 [RFC7684]. Thus the Flags field of the BGP-LS Prefix > ^^^^ A comma may be missing after the conjunctive/linking adverb "Thus". _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
