Hi Acee, My comment is non-blocking and it is not a hill I am willing to die on.
I will let you decide what you want to do with it. Cheers. Mahesh Jethanandani [email protected] > On Jan 17, 2026, at 12:43 PM, Acee Lindem <[email protected]> wrote: > > Hi Mahesh, > >> On Jan 17, 2026, at 1:18 PM, Mahesh Jethanandani <[email protected]> >> wrote: >> >> Hi Ran/Acee, >> >>> >>>> On Jan 16, 2026, at 2:09 AM, [email protected] wrote: >>> >>> 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. >> >> When a node has a default value, the must statement validates that default >> value against the rest of the configuration just as strictly as it would >> validate a value explicitly entered by a user. > > Ran and I don't disagree. So the default for both the flags is 'false'. So, > the part of the expression inside the parentheses will be 'false' with > defaults. > > must "not(../anycast-flag = 'true' and " > + "/rt:routing/rt:control-plane-protocols/" > + "rt:control-plane-protocol/ospf:ospf/" > + "ospf:areas/ospf:area/ospf:interfaces/" > + "ospf:interface/ospf:node-flag = 'true')" { > error-message "The anycast-flag and the node-flag MUST " > + "NOT both be set to 1 (true)."; > description > "Ensures architectural consistency by preventing a prefix > from being marked as both anycast and node-specific."; > } > > not('false' and 'false') = 'true'. > > So, with the defaults, the statement will evaluate as true and there will be > no error. > > > Thanks, > Acee > > >> >> A great example of this is the Tag Protocol Identifier (TPID) in the >> openconfig-vlan (and openconfig-interfaces) modules. >> >> Example: VLAN TPID with a Default Value >> >> When configuring a VLAN on an interface, the TPID (which identifies the >> frame as a 802.1Q tag) almost always defaults to 0x8100. However, this value >> is only valid if the interface is of a type that actually supports VLAN >> tagging (like an Ethernet port). In your example, the anycast-flag should be >> set only if the node-flag is not set. Note, there is no check for the >> current value of the node. >> >> The YANG Snippet >> >> leaf tpid { >> type identityref { >> base oc-vlan-types:TPID_TYPES; >> } >> default oc-vlan-types:TPID_0X8100; >> >> must "derived-from-or-self(../../config/type, 'oc-ift:ETHERNET_CSMACD') or >> " + >> "derived-from-or-self(../../config/type, 'oc-ift:IF_AGGREGATE')" { >> error-message "TPID can only be configured on Ethernet or Aggregate >> interfaces"; >> } >> description >> "Optionally set the tag protocol identifier of the VLAN header."; >> } >> >> How the Interaction Works >> >> This creates a specific logical flow for the NETCONF server: >> >> * The Default Kicks In: If the user creates the VLAN container but does not >> specify a tpid, the YANG engine automatically assigns the value TPID_0X8100. >> * The Cross-Tree Check: The must statement then "looks" at the parent >> interface's type flag (located at ../../config/type). >> * The Conflict: * If the interface is a Loopback, the must statement >> evaluates to false. >> * Even though the user didn't explicitly set the TPID (they just accepted >> the default), the server rejects the configuration. >> * The error message will trigger: "TPID can only be configured on Ethernet >> or Aggregate interfaces". >> >> Cheers >> >> Mahesh Jethanandani >> [email protected] >>> >>> >>> >>> 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> > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
