Re: [netconf] Capability-fetching mechanisms

["Rob Wilton (rwilton)" <[e-mail]>]

Hi All,

Actually, my proposal was slightly different.

There is an IANA registry for AFIs and SAFIs, that is defined here Address Family Numbers (iana.org)<https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml> and here: Subsequent Address Family Identifiers (SAFI) Parameters (iana.org)<https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml>

There is also an IANA maintained YANG module registry (iana-routing-types YANG Module<https://www.iana.org/assignments/iana-routing-types/iana-routing-types.xhtml>) that defines enums values for these two above registries that is automatically maintained by IANA.  I.e., whenever either of the AFI or SAFI registries are updated then a new revision of the iana-routing-types.yang module is created to reflect those changes.  The instructions to IANA on how to create and maintain the iana-routing-types registry is defined in section 5.1 of RFC 8294.

This makes these values easily available to code that understands YANG, but that table of AFI/SAFI code points are also available to other protocols.

Another example is the IANA if-types registry that I believe is handled somewhat similarly (perhaps because the values are shared between SNMP and YANG).

But I agree with Kent/Mahesh that you don’t need to have IANA maintain these, and it could just be done using YANG modules defining new identities.  There are several choices here with different pros and cons (including the one that is currently documented).

Regards,
Rob


From: netconf <[e-mail]> On Behalf Of Mahesh Jethanandani
Sent: 22 July 2021 19:05
To: Pierre Francois <[e-mail]>
Cc: [e-mail]
Subject: Re: [netconf] Capability-fetching mechanisms

Hi Pierre,


On Jul 22, 2021, at 4:43 AM, Pierre Francois <[e-mail]<mailto:[e-mail]>> wrote:

Kent,

(ii)                I wasn’t sure why you used inet:uri’s for the capabilities rather than YANG identities.  I guess that this would be a bit more work because it would require both an IANA maintained registry of capabilities and also a derived IANA registry of YANG identities that would be automatically updated by IANA whenever a new capability is added to the registry.  E.g., following the approach for say for iana-routing-types YANG Module<https://www.iana.org/assignments/iana-routing-types/iana-routing-types.xhtml>

I’m unsure if the use of identities was ever discussed.  It seems reasonable and, if not mistaken, would NOT require an IANA registry of any sort…as the identities (on the wire) would be scoped by their modules.   The only “downside” is the “overhead” introduce for custom (non-standard) capabilities, but it doesn’t seem meaningful relative to getting IANA out of having to maintain a registry of any kind.


Transposing this discussion to our udp-notif, for the sake of consistency, is the WG considering not to create IANA pools for the protocol code points defining options and encoding types?
Are we saying NETCONF no longer uses IANA to organize their protocol code points? I have no strong opinion on this, as our goal as developers is to have the IETF tell us which values to use for these codes,
but this seems like a radical change of approach compared to what I've been used to, so I'd like to make sure I understand this is what is going on ;)

The proposal, as I understand from Rob is to use identities to define capabilities. For example, a new module called “iana-notif-transport-capabilities” would define a base identity called:

  identity transport-capabilities {
    description
      "Base identity from which identities describing transport
       capabilities are derived.";
  }

Other capabilities would then derive of this base identity to define new capabilities. See attached module for a more complete example.

This module will be a IANA maintained module. However, the difference is that while the module will be registered with IANA, you do not need a registry to maintain the capabilities. Instead, anybody can create a new module, import the base identity from this IANA module, and define a new capability.

Makes sense?



Regards,

Pierre.





_______________________________________________
netconf mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
[e-mail]<mailto:[e-mail]>