Hi Mahesh, > On Jan 15, 2026, at 8:08 PM, Mahesh Jethanandani <[email protected]> > wrote: > > Hi Ran, > > Thanks for addressing my comments. > > Just as a note, in the must statement, the check for “../anycast-flag = > ’true’” is redundant or may lead to inaccurate output. The whole idea of the > must statement is to check the condition stated by the must statement > *before* allowing you to set the value of the flag (to true). Since the flag > is set to ‘false’ by default, your must statement will always fail the check. > I would suggest you remove the first part of the must statement that checks > for ‘anycast-flag’ and just check for the ’node-flag’ to be set to ’true’.
This seems correct as written independent of the default since the must constraint is negated. Am I missing something? One could also remove the “not()” and check for ’false’ with a logical or. Thanks, Acee > > Cheers. > >> On Jan 15, 2026, at 4:34 PM, <[email protected]> <[email protected]> >> wrote: >> >> Hi Acee，Mahesh， >> >> >> Thank you for your feedback and the insightful suggestion. >> I have updated the draft accordingly. You can review the changes via the >> diff link below: >> <https://author-tools.ietf.org/iddiff?url1=draft-ietf-lsr-anycast-flag-11&url2=draft-ietf-lsr-anycast-flag-12&difftype=--html>https://author-tools.ietf.org/iddiff?url1=draft-ietf-lsr-anycast-flag-11&url2=draft-ietf-lsr-anycast-flag-12&difftype=--html. >> >> BR, >> Ran >> Original >> From: AceeLindem <[email protected]> >> To: Mahesh Jethanandani <[email protected]>; >> Cc: The IESG <[email protected]>;[email protected] >> <[email protected]>;lsr-chairs <[email protected]>;lsr >> <[email protected]>; >> Date: 2026年01月12日 06:36 >> Subject: [Lsr] Re: Mahesh Jethanandani's No Objection on >> draft-ietf-lsr-anycast-flag-11: (with COMMENT) >> Hi Mahesh, >> >> > On Jan 7, 2026, at 6:09 PM, Mahesh Jethanandani <[email protected]> >> > wrote: >> > >> > 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)' >> > >> >> Yes - the co-authors could add this constraint to the read-write node. I'll >> leave it to them. >> >> >> > >> > 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? >> >> This identity could be returned in the flag container in the >> extended-prefix-opaque container. >> >> >> Thanks, >> Acee >> >> >> >> >> > >> > 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] >> >> > > > Mahesh Jethanandani > [email protected] > > > > > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
