On Fri, May 22, 2026 at 7:47 AM Jeffrey Haas <[email protected]> wrote:
> 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 you deviate the leaf type to something with a different base type (e.g. changing string to integer), then the client is expected to know what integer to send, as none of the standard ip-address values are accepted. This is extremely bad practice. The current example (extending the accepted values) is a better practice for deviations. > If there is no issue, I think we're done here. > > -- Jeff > > > Andy > 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]> wrote: > >> Hi Andy, >> >> On May 19, 2026, at 5:13 PM, Andy Bierman <[email protected]> wrote: >> >> >> >> On Tue, May 19, 2026 at 4:57 PM Jeffrey Haas <[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]> <[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]> >>> <[email protected]> wrote: >>> >>> Mahesh - see better suggestion below. Problem solved... >>> >>> On May 19, 2026, at 6:03 PM, Acee Lindem <[email protected]> >>> <[email protected]> wrote: >>> >>> Hi Mahesh, >>> >>> On May 19, 2026, at 4:23 PM, Mahesh Jethanandani >>> <[email protected]> <[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]> >>> <[email protected]> wrote: >>> >>> >>> On Apr 11, 2026, at 13:27, Maria Matejka <[email protected]> >>> <[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] >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>> >>> >>> Mahesh Jethanandani >>> [email protected] >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> yang-doctors mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >> >> >> >> Mahesh Jethanandani >> [email protected] >> > > > Mahesh Jethanandani > [email protected] > > > > > > > >
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
