Re: [core] removing names from yang-cbor rules

On Thu, Sep 23, 2021 at 8:25 AM Carsten Bormann <cabo@tzi.org> wrote:

> Strings would not be used with constrained devices.
>
> The point of the string-based names is to ensure that there never is a
> reason to use text-based encodings (XML, JSON) with yang.
> It is a completely separate choice.
> (Supported by Accept: in http.)
>

This text in sec 3 implies that text and SID names can be mixed in ad-hoc
fashion.

   This specification supports two types of CBOR keys;
   YANG Schema Item iDentifier (YANG SID) as defined in Section 3.2
<https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor#section-3.2>
and
   names as defined in Section 3.3
<https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor#section-3.3>.
Each of these key types is encoded
   using a specific CBOR type which allows their interpretation during
   the deserialization process.  Protocols or mechanisms implementing
   this specification can mandate the use of a specific key type.

IMO this section should clearly identify the requirements in terms of the
Content-Types defined.
https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor#section-9.1

How about text that says YANG SID keys MUST only be used with
application/yang-data+cbor; id=sid
and name keys MUST only be used with application/yang-data+cbor; id=name.

Andy

> Sent from mobile, sorry for terse
>
> On 23. Sep 2021, at 16:17, Andy Bierman <andy@yumaworks.com> wrote:
>
> 
>
>
> On Wed, Sep 22, 2021 at 9:35 PM Carsten Bormann <cabo@tzi.org> wrote:
>
>> Clearly, SIDs are the major innovation here and they are the normal way
>> to use Yang-cbor.
>>
>> I don’t agree the string variant should be removed. This takes Yang-cbor
>> out of the game for “big-web” applications.
>>
>> Instead, we should make sure to explain that strings are a special option
>> that you chose wholesale when you need it, not something you switch to from
>> SIDs randomly.
>>
>>
> The problem with this approach (no negotiation, either peer sends SID or
> string at any time)
> is that it forces complexity on a constrained device that a giant NETCONF
> router is not
> even expected to support. It also forces a constrained device to store the
> string names.
>
>
> Andy
>
> Sent from mobile, sorry for terse
>>
>> On 23. Sep 2021, at 01:02, Andy Bierman <andy@yumaworks.com> wrote:
>>
>> 
>>
>>
>> On Wed, Sep 22, 2021 at 2:54 PM Michael Richardson <mcr+ietf@sandelman.ca>
>> wrote:
>>
>>>
>>> Murray S. Kucherawy <superuser@gmail.com> wrote:
>>>     > I'm happy to take credit for a keen observation such as this, but
>>> this
>>>     > was actually Eric Vyncke.
>>>
>>> sorry, if I screwed that attribution up when creating the issues.
>>>
>>>     >> I also wonder about this.  I think that the SID concept is
>>> advanced
>>>     >> enough that we can just rely upon it.  Murray's comment is that
>>> if we
>>>     >> support two things, then an encoder needs to pick one, and it's
>>> likely
>>>     >> wrong.  Since this is often data at rest, there is no possible
>>>     >> negotiation either.
>>>     >>
>>>     >> I propose to remove section 4.1.2:
>>>
>>> There are also other parts of the document which refer to names as well.
>>> I have no use for names.
>>>
>>>
>> I agree it is better to remove the string name variant and only support
>> SIDs as names.
>> It will be important for the client to be able to obtain the SID File URL
>> list
>> representing all SIDs used by the server. This is needed before the
>> client can
>> use any data from the server (including the CORECONF YANG library).
>>
>> The client will have to be hard-wired with the SIDs or capable of
>> consuming SID files in JSON format.
>>
>>
>>
>>> --
>>> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT
>>> consulting )
>>>            Sandelman Software Works Inc, Ottawa and Worldwide
>>>
>>>
>>>
>>
>> Andy
>>
>>
>>>
>>>
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>>>
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>>
>>