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]> > 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]> wrote: > > Mahesh - see better suggestion below. Problem solved... > >> On May 19, 2026, at 6:03 PM, Acee Lindem <[email protected]> wrote: >> >> Hi Mahesh, >> >>> On May 19, 2026, at 4:23 PM, Mahesh Jethanandani <[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]> wrote: >>>> >>>> >>>>> On Apr 11, 2026, at 13:27, Maria Matejka <[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]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
