Hi Mahesh, > On Jan 6, 2026, at 7:31 PM, Mahesh Jethanandani via Datatracker > <[email protected]> wrote: > > 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.
No - we already went down a rat hole with this in the WG and Ketan suggested to remove it. Please discuss with him. > > 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. As you well know, this is the boiler plate from draft-ietf-netmod-rfc8407bis. Perhaps this should be corrected there with "(s)"s rather than "s"s. > > 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. We don't normally validate read-only data, i.e., operational state. Rather, it is rendered as is so that anomalies can be detected. > > 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. The new flag is part of an LSA encoding which is in the Link State Database (LSDB). Acee > > ------------------------------------------------------------------------------- > 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]
