Hi Acee, > On Jan 6, 2026, at 5:03 PM, Acee Lindem <[email protected]> wrote: > > 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.
Ok. I will wait for him to respond. > > >> >> 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. Yes, it is boilerplate, but nothings says it cannot be modified. > >> >> 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. I do not understand. The YANG module is defining a RW leaf for ‘anycast-flag’. A must statement there could check if the N-flag is set or not before allowing the flag to be set to true. No? Something like must ‘not(/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/node-flag)' And I just noticed that the 'identity ac-flag’ is not used in the module. Is it being used somewhere else? If not, do we need it? An example would really help here. > > > >> >> 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). Sure. But the module that is defining the LSDB or access to it should be the place where this statement would make sense. Thanks. > > 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". Mahesh Jethanandani [email protected]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
