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]
