Re: [netconf] Capability-fetching mechanisms

[Pierre Francois <[e-mail]>]

Hello Mahesh,

That's what I thought initially. I just followed the suggestion I received
from you to react to this thread when I mentioned the creation of these
pools planned for -04.
All is well then. If the wg agrees I'll add the IANA requests to the next
revision of the draft.

Thanks !
Cheers,

Pierre.




Le sam. 24 juil. 2021 à 22:08, Mahesh Jethanandani <[e-mail]>
a écrit :

> Hi Pierre,
>
> On Jul 23, 2021, at 12:26 AM, Pierre Francois <
> [e-mail]> wrote:
>
> 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?
>
>
> You will notice that the thread starts with Rob’s message in the green,
> where he was specifically asking about capability advertisement. And so
> does my response. So this solution works for capabilities, but will not
> address the question you raise about code points. For that you might have
> to make a IANA registry request.
>
> HTC. Thanks.
>
>
> Regards,
>
> Pierre.
>
>
> Mahesh Jethanandani
> [e-mail]
>
>
>
>
>
>