Re: [netconf] Capability-fetching mechanisms

[Pierre Francois <[e-mail]>]

Mahesh,

Le jeu. 22 juil. 2021 à 20:05, Mahesh Jethanandani <[e-mail]>
a écrit :

> Hi Pierre,
>
> On Jul 22, 2021, at 4:43 AM, Pierre Francois <
> [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?
>

For expressing capabilities, it seems to work, but the pools I was
referring to and discussing with you offline are for what I will find on
the wire for options and encoding types in the header.
For this to work I'd need the values explicited in the module so that I
know what to put in the code.
If anybody can create their own and decide which value will be on the wire
without a pool, we lose unicity, don't we?

Regards,

Pierre.