Re: [core] CBOR Encoding of Data Modeled with YANG

[Michel Veillette <[e-mail]>]

Hi Juergen

My "smart" quote are now disabled.
Thanks to motivate me to turn off this nonsense.

About the format/assignment of the numeric data node IDs, the consensus is to keep them out of the YANG to CBOR mapping draft in order to make progress. 

Peoples agree that names encoded as string represents too much overhead to address the needs of constrained devices and constrained networks as defined by RFC 7228. However, there are lots of discussions about how those names can be associated with small IDs encoded as integers and how small those integers need to be.

The CoOL draft proposes structured IDs based on the following concept:

   Only IDs  associated with module names are registered, IDs associated to data node identifiers are automatically generated.

   e.g. draft-ietf-netmod-yang-json-06 page 5
   for the member-name "foomod:top"
   the ID associated with the name of the module "foomod" is registered,
   the ID associated with the data node identifier "top" is auto-generated.

To simplify scaling of the registered module names, different approaches have been proposed:
- Possibility to allocation ranges of IDs (bundle) to developers and SDOs for distributed assignment.
- Possibility to define a range of private IDs (IDs locally assigned and used, not globally unique, same concept as IPv4 10.x.x.x)
- Possible to define disjoint registries, implemented using a different resource type & default URI path

Regards,
Michel

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[e-mail]] 
Sent: December-07-15 2:42 PM
To: Michel Veillette <[e-mail]>
Cc: Core <[e-mail]>
Subject: Re: [core] CBOR Encoding of Data Modeled with YANG

Hi,

can you configure you mail client to produce traditional quotings?

Concerning your questions, I suggest you use the terminology of RFC 6020bis wherever possible. Concerning the data node ids, I am clueless how those numeric IDs will be managed since this has been left out. YANG provides names. Additional numeric assignments do not scale. Anyway, the way things are named should be part of the document since otherwise things are incomplete.

/js

On Mon, Dec 07, 2015 at 04:40:52PM +0000, Michel Veillette wrote:
> Hi Juergen and thanks for your comments.
> 
> See [MV] inline.
> 
> Michel Veillette
> System Architecture Director
> Trilliant Inc.
> 
> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[e-mail]]
> Sent: December-07-15 4:11 AM
> To: Michel Veillette <[e-mail]>
> Cc: Core <[e-mail]>
> Subject: Re: [core] CBOR Encoding of Data Modeled with YANG
> 
> A few notes:
> 
> - The document talks about a 'node ID' in several places but never
>   defines this concept nor does it explain how these node IDs are
>   created.
> 
> [MV] To give you some context, the current document 
> (https://core-wg.github.io/yang-cbor/)
> [MV] is an extract of section 4 and 5 of 
> (https://datatracker.ietf.org/doc/draft-veillette-core-cool/)
> [MV] some works are still require to make it a standalone document.
> [MV]
> [MV] About the 'node ID', the terminology used in the current document is in fact 'data node ID'.
> [MV] This is the equivalent to the 'member-name' used in 'draft-ietf-netmod-yang-json-06'.
> [MV] In the context of CoMI and CoOL, data node IDs are always encoded as unsigned integer.
> [MV] If we want to make this mapping also compatible with RESTCONG, we need to support 'member-name' encoded as string.
> [MV]
> [MV] My questions to you are:
> [MV] - Which terminology we should use (tag, data node identifier, ...)?
> [MV] - Should we support both data node ID (encoded as unsigned integer) and object name (encoded as string)?
> 
> - Your ID should normatively depend on YANG 1.1 and cover all the YANG
>   1.1 constructs, that is, include anydata.
> 
> [MV] The current version is based on YANG 1.0 but I agree we now need to extend it to support YANG 1.1.
> 
> - I am not sure I understand the anyxml encoding.
> 
> [MV] The proposed encoding of anyxml allows the encoding of any valid CBOR objects.
> [MV] In the context of YANG 1.1, this definition should be moved to anydata.
> [MV] The anyxml should be defined as a string carrying any valid xml content.
> [MV] Make sense?
> 
> - I guess I am having an issue with yet another ad-hoc namespace
>   notation invention in 3.1.7. YANG type: identityref. Why not use the
>   <module>:<identifier> notation used by the JSON encoding?
> 
> [MV] The intent was to adopt a more compact encoding but the proposed solution don't really archive this goal.
> [MV] Unless we find something more compact, I agree that the JSON encoding should be used.
> 
> - The document confuses YANG types and YANG data node definition
>   statements. I suggest to follow the structure of
>   draft-ietf-netmod-yang-json-06.txt.
> 
> [MV] Make sense, I'll adjust the table of content to be aligned with 'draft-ietf-netmod-yang-json-06'
> 
> /js
> 
> On Wed, Dec 02, 2015 at 08:08:49PM +0000, Michel Veillette wrote:
> > For those interested to the development of the "CBOR Encoding of Data Modeled with YANG" draft. 
> > 
> > The current document is available at:
> > https://core-wg.github.io/yang-cbor/
> > 
> > Proposed changes to the Reference, Introduction and Security Considerations sections are available at:
> > https://github.com/core-wg/yang-cbor/pull/2/files
> > 
> > Michel Veillette
> > System Architecture Director
> > Trilliant Inc.
> > Tel: [phone] ext. 237
> > 
> > _______________________________________________
> > core mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/core
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>