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]
