Hi Mahesh, > On Jan 15, 2026, at 10:49 PM, Mahesh Jethanandani <[email protected]> > wrote: > > 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?
I believe the evaluation of the "must" constraint is deferred until the changes are committed using the final value. At least this is the case with confD. Thanks, Acee > > 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. >>>> >>>> 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]
