Hi Acee, > On Jan 15, 2026, at 6:58 PM, Acee Lindem <[email protected]> wrote: > > 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?
The question is when is the must statement evaluated. I believe it is evaluated before the value is set. Therefore, since the default for ‘anycast-flag' is ‘false’ the must (not(../anycast-flag = ’true’)) part of the mst statement will evaluate to must(not(0)), which is true, making that part of the statement redundant. Does that make sense? Cheers. > > 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] >> >> >> >> >> >> > Mahesh Jethanandani [email protected]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
