Hi Acee，Mahesh， Thank you both for the detailed discussion regarding the must statement. Our tests show that if we omit the check for anycast-flag = 'true', the constraint would incorrectly block any configuration where node-flag is true, even if anycast-flag remains at its default false value.
I have attached the diff-document with the previous version, which includes a fix for a sequence issue and addresses a minor YANG validation error. All other parts remain unchanged. Please check it. Many thanks！ BR， Ran Original From: MaheshJethanandani <[email protected]> To: Acee Lindem <[email protected]>; Cc: 陈然00080434;The IESG <[email protected]>;[email protected] <[email protected]>;lsr-chairs <[email protected]>;lsr <[email protected]>; Date: 2026年01月16日 11:49 Subject: [Lsr] Re: Mahesh Jethanandani's No Objection on draft-ietf-lsr-anycast-flag-11: (with COMMENT) _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected] 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. BR, Ran Mahesh Jethanandani [email protected] Mahesh Jethanandani [email protected] 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]
draft-ietf-lsr-anycast-flag-13.diff.html
Description: Binary data
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
