To refine the question: If we have a key that the key node's type is currently a leafref, is there any issue to deviate its type to something that isn't a leafref? As a specific example, deviate it to a string or integer?
If there is no issue, I think we're done here. -- Jeff > On May 20, 2026, at 12:59, Mahesh Jethanandani <[email protected]> > wrote: > > Thanks, Andy. > > To the original question, which was, if the key type is changed, whether it > is by deviating the leaf directly (as suggested below) or by deviating the > leafref that the key points to (as suggested by Jeff), what are the > implications? Is there something that implementations should be aware of? > >> On May 19, 2026, at 6:09 PM, Andy Bierman <[email protected]> wrote: >> >> >> >> On Tue, May 19, 2026 at 5:56 PM Mahesh Jethanandani <[email protected] >> <mailto:[email protected]>> wrote: >>> Hi Andy, >>> >>>> On May 19, 2026, at 5:13 PM, Andy Bierman <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> >>>> On Tue, May 19, 2026 at 4:57 PM Jeffrey Haas <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>> For some reason, some of the prior context didn't make it into the thread. >>>>> >>>>> https://github.com/mjethanandani/ietf-bgp-yang/issues/484 >>>>> >>>>> In the current YANG for the neighbor list, the key is the natural key for >>>>> most BGP implementations, "remote-address". This covers the vast >>>>> majority of use cases and is similar to what is done in the RFC 4273 MIB. >>>>> >>>>> The point discussed in prior mails from Maria is that her implementation >>>>> doesn't key BGP peers in that fashion. In our original discussions, we >>>>> were trying to figure out how we might accommodate alternate keys to >>>>> satisfy the use case. >>>>> >>>>> Unfortunately, the key itself as a property of a list can't be deviated. >>>>> So, that option is precluded. >>>>> >>>> >>>> >>>> Where does it say that in RFC 7950? >>>> I think YANG supports this (and I know of some vendors using it) >>>> >>>> deviation /some/path { >>>> deviate replace { >>>> type union { >>>> type inet: ip-address; >>>> type string; >>>> } >>>> } >>>> } >>> >>> It does not. However, when I ask AI to analyze RFC 7950 on the question of >>> whether a key can be deviated, it comes back with this analysis. >>> >>> RFC 7950 doesn't have a single explicit prose sentence saying "a key cannot >>> be deviated." The restriction is derived implicitly from two places in the >>> spec: >>> >>> Section 7.20.3.2 — The table of allowed deviate substatements does not >>> include key: >>> >>> | config | | default | | mandatory | >>> | max-elements | | min-elements | | must | >>> | type | | unique | | units | >>> >>> Since key does not appear here, a deviation cannot add, replace, or delete >>> the key property of a list. >>> >> >> >> I am not suggesting that the key-stmt be changed. >> >> In module example-bgp-dev.yang (for the server implementation) >> >> deviation /path/to/neighbor/remote-address { >> deviate replace { >> type union { >> type inet_ip-address; >> type string; >> } >> } >> >> The type of the leaf is changed, not the key to the list. >> >> Andy >> >> >>>>>>>> list neighbor { >>>>>>>> key "remote-address"; >>>>>>>> description >>>>>>>> "List of BGP neighbors configured on the local system, >>>>>>>> uniquely identified by remote IPv[46] address."; >>>>>>>> >>>>>>>> leaf remote-address { >>>>>>>> type inet:ip-address; >>>>>>>> description >>>>>>>> "The remote IP address of this entry's BGP peer."; >>>>>>>> } >>> >>> >>> >> >> >>> Section 14 (ABNF Grammar) — This is confirmed by the formal grammar, where >>> key-stmt is absent from deviate-add-stmt, deviate-replace-stmt, and >>> deviate-delete-stmt. >>> >>> As a secondary constraint, Section 7.20.3 closes with: >>> >>> "After applying all deviations announced by a server, in any order, the >>> resulting data model MUST still be valid." >>> >>> This means that even targeting a key leaf via deviate not-supported (to >>> suppress it) would be forbidden, since a list missing its key leaf is an >>> invalid data model. >>> >>> For comparison, the only analogous explicit MUST NOT statements about key >>> leaves in the RFC are: >>> >>> Section 7.20.2 (if-feature): "A leaf that is a list key MUST NOT have any >>> 'if-feature' statements." >>> Section 7.21.5 (when): "A leaf that is a list key MUST NOT have a 'when' >>> statement.” >>> >>> There is no equivalent explicit sentence for deviations — it falls out of >>> the grammar and substatement table in §7.20.3.2. >>> >>>> >>>> The interoperability issues should be obvious. >>>> How does the client know what the server accepts (besides ip-address)? >>>> But an old client only sending ip-address should still work, so this is >>>> not a big deal. >>> >>> Thanks for noting the interoperability concerns. >>> >>> Cheers. >>> >>>> >>>> >>>> Andy >>>> >>>>> The discussion, below, explored whether loosening up the type for >>>>> "remote-address" dealt with the situation well enough. While there's >>>>> some flexibility here, it also slightly complicates the semantic of that >>>>> leaf: In config context, it might be whatever is permitted. In >>>>> operational context, it'd return the remote IP address. IETF access >>>>> protocols permit that so it's not out of the question as an answer. But >>>>> to accommodate for it by default in the model, it'd require loosening the >>>>> base type so much in the union that config validation for the common use >>>>> case becomes very weak. >>>>> >>>>> The most recent observation by Maria is perhaps the simplest answer is to >>>>> split the neighor list key from the remote-address node. By default, it >>>>> could be a leafref (see the issue, above) to the remote-address >>>>> preserving the common use case. Implementations that required additional >>>>> flexibility could override the leaf for the key removing the leafref >>>>> property and replacing it with the appropriate restricted type for that >>>>> implementation. >>>>> >>>>> Mahesh had some concerns that the form documented in the issue may have >>>>> implementation issues. It'd be good to get clarity whether the pattern >>>>> in the github issue is a viable option. Similarly, examining options for >>>>> the union below is good to get additional clarity on. >>>>> >>>>> Hopefully the BIRD implementers will help confirm this summary. >>>>> >>>>> -- Jeff >>>>> >>>>> >>>>> >>>>> On 5/19/26 19:36, Mahesh Jethanandani wrote: >>>>>> Hi Acee, >>>>>> >>>>>> I had suggested something similar, with a few more guardrails, if not on >>>>>> this thread, then on one of the other threads, but I was told that that >>>>>> was not acceptable. >>>>>> >>>>>> It was something along these lines: >>>>>> >>>>>>> On Apr 18, 2026, at 11:01 AM, Mahesh Jethanandani >>>>>>> <[email protected]> <mailto:[email protected]> wrote: >>>>>>> >>>>>>> An unrestricted string matches anything, including things that also >>>>>>> match inet:ip-address. Union resolution in YANG is ordered — first >>>>>>> match wins. So: >>>>>>> >>>>>>> If string comes before inet:ip-address in the union, it matches >>>>>>> everything and inet:ip-address becomes unreachable. >>>>>>> >>>>>>> If string comes after inet:ip-address, it becomes a catch-all for >>>>>>> non-IP values — which may actually be the intent (e.g., to allow >>>>>>> hostnames or peer names). >>>>>>> >>>>>>> Consider: is "192.0.2.1" (matched as ipv4-address) the same key as >>>>>>> "192.0.2.1" (matched as string)? The canonical form determines >>>>>>> equality, and this could be implementation-dependent. >>>>>>> >>>>>>> But let us take the case that the goal is to allow hostnames alongside >>>>>>> IP addresses. In that case one would use a pattern-restricted string in >>>>>>> the union to avoid overlap: >>>>>>> >>>>>>> type union { >>>>>>> type inet:ip-address; >>>>>>> type string { >>>>>>> pattern '[a-zA-Z][a-zA-Z0-9\-\.]*'; // hostname pattern, won't >>>>>>> match bare IPs >>>>>>> } >>>>>>> } >>>>>>> >>>>>> >>>>>> The point being, whatever forms part of the union has to be able to >>>>>> produce a key that is not overlapping with any other member of union. >>>>>> >>>>>> Cheers. >>>>>> >>>>>>> On May 19, 2026, at 4:17 PM, Acee Lindem <[email protected]> >>>>>>> <mailto:[email protected]> wrote: >>>>>>> >>>>>>> Mahesh - see better suggestion below. Problem solved... >>>>>>> >>>>>>>> On May 19, 2026, at 6:03 PM, Acee Lindem <[email protected]> >>>>>>>> <mailto:[email protected]> wrote: >>>>>>>> >>>>>>>> Hi Mahesh, >>>>>>>> >>>>>>>>> On May 19, 2026, at 4:23 PM, Mahesh Jethanandani >>>>>>>>> <[email protected]> <mailto:[email protected]> wrote: >>>>>>>>> >>>>>>>>> Directing this email to YANG Doctors and NETMOD. >>>>>>>>> >>>>>>>>> This is regarding an ask from the implementors of BIRD, who are >>>>>>>>> trying to implement the IETF BGP YANG module. >>>>>>>> >>>>>>>> It's great that they'd be so brave. >>>>>>>> >>>>>>>> >>>>>>>>> The question before us is, can a key be deviated? Currently, the >>>>>>>>> module defines the list of neighbors as: >>>>>>>>> >>>>>>>>> list neighbor { >>>>>>>>> key "remote-address"; >>>>>>>>> description >>>>>>>>> "List of BGP neighbors configured on the local system, >>>>>>>>> uniquely identified by remote IPv[46] address."; >>>>>>>>> >>>>>>>>> leaf remote-address { >>>>>>>>> type inet:ip-address; >>>>>>>>> description >>>>>>>>> "The remote IP address of this entry's BGP peer."; >>>>>>>>> } >>>>>>>> >>>>>>>> Would "type union" with "net:ip-address" and "string" as the component >>>>>>>> types meet the requirement? >>>>>>> >>>>>>> Actually, it would be even better to avoid the union of unions by >>>>>>> flattening the remote-address type >>>>>>> with component types "inet:ipv4-address", "inet:ipv6-address", and >>>>>>> "string". I believe the problem >>>>>>> is solved. Or, if you don't need the ever-popular zone specification, >>>>>>> "inet:ipv4-address-no-zone" >>>>>>> and "inet:ipv6-address-no-zone". >>>>>>> >>>>>>> Thanks, >>>>>>> Acee >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Acee >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> … >>>>>>>>> } >>>>>>>>> >>>>>>>>> The key in this case is ‘remote-address’ and is of type ‘ip-address’. >>>>>>>>> Implementations would like to use a different key, one that has a >>>>>>>>> ’type string’, to allow for any string to be used. A couple of >>>>>>>>> questions come to mind. >>>>>>>>> >>>>>>>>> - Does RFC 7950 permit a leafref key whose target leaf is itself >>>>>>>>> deviated to a different type? >>>>>>>>> - Is there a sanctioned pattern for "implementation-specific key" use >>>>>>>>> cases, since this seems like a general need beyond just BGP. >>>>>>>>> >>>>>>>>> Note that this is an interoperability concern — this isn't just a >>>>>>>>> syntactic question but a semantic one about what a BGP neighbor >>>>>>>>> identity means. >>>>>>>>> >>>>>>>>> The response to some of the questions would suggest how we resolve >>>>>>>>> the issue. One suggestion from Jeff has on what to do is below. >>>>>>>>> Essentially, make the key a leafref, such that the leafref can be >>>>>>>>> deviated. Are there conformance or interoperability implications of >>>>>>>>> this approach that the WG should be aware of before adopting it? >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Apr 16, 2026, at 7:53 AM, Jeffrey Haas <[email protected]> >>>>>>>>>> <mailto:[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Apr 11, 2026, at 13:27, Maria Matejka <[email protected]> >>>>>>>>>>> <mailto:[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> We can not deviate the key, at least nobody around Netmod was able >>>>>>>>>>> to tell me how. We would have to deviate the whole neighbor list, >>>>>>>>>>> and consequentially probably everything which leaf-refs that. Or, >>>>>>>>>>> we could have deviated the remote-address, which works but brings >>>>>>>>>>> other problems with the remote-address suddenly not being a >>>>>>>>>>> remote-address, actually. >>>>>>>>>>> What may work tho, is defining the neighbor key as a separate item >>>>>>>>>>> which would by default be only the remote address, and that item >>>>>>>>>>> could then be deviated / augmented much easier. >>>>>>>>>>> container neighbors { >>>>>>>>>>> list neighbor { >>>>>>>>>>> key "neighbor-key"; >>>>>>>>>>> leaf neighbor-key { >>>>>>>>>>> type leafref { >>>>>>>>>>> path "remote-address"; >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> leaf remote-address { >>>>>>>>>>> type inet:ip-address; >>>>>>>>>>> } >>>>>>>>>>> ... >>>>>>>>>>> } >>>>>>>>>>> ... >>>>>>>>>>> } >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> Mahesh Jethanandani >>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> netmod mailing list -- [email protected] <mailto:[email protected]> >>>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>>> <mailto:[email protected]> >>>>>> >>>>>> Mahesh Jethanandani >>>>>> [email protected] <mailto:[email protected]> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> yang-doctors mailing list -- [email protected] >>>>> <mailto:[email protected]> >>>>> To unsubscribe send an email to [email protected] >>>>> <mailto:[email protected]> >>> >>> Mahesh Jethanandani >>> [email protected] <mailto:[email protected]> > > Mahesh Jethanandani > [email protected] > > > > > >
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
