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

[Alexander Pelov <[e-mail]>]

Dear Andy,

It was my understanding that we have agreed to advance on the YANG-CBOR 
mapping. Having Structured Data Node IDs allows for both YANG hashes and 
deterministic Data Node IDs.

The questions you ask have been answered repeatedly in previous mails. 
Of course, I think that we must be even more thorough in the future 
draft, as to avoid any possibility of confusion.

I propose that we continue on the current collaborative effort (which 
happens on the github and is public to anyone that wants to see the 
progress). Let's keep the detailed discussion on how the full 
deterministic Data Node IDs for the second stage.

Best,
Alexander


Le 08/12/2015 15:51, Andy Bierman a écrit :
> Hi,
>
> It is not clear to me how manual numbering of objects can be practical.
> Automatic numbering really means "write a program that does the manual
> numbering".  YANG allows new nodes to be added anywhere.
> Only the relative order of nodes is maintained across revisions.
> Some nodes, like "augment" are not ordered at all and they
> can change order from 1 revision to the next.  If a grouping in an
> external module is extended, then all "uses" of the grouping will be 
> extended.
> If "import without revision" is used, then the specific external grouping
> is not even knowable and it is impossible to number the expanded 
> "uses" correctly.
> If any module ever has more than 1024 objects, they will be ignored,
> since the numbering has a hard limit on objects per module.
>
> These seem like significant issues that cannot be ignored.
>
>
> Andy
>
>
> On Tue, Dec 8, 2015 at 5:10 AM, Alexander Pelov <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Dear Juergen,
>
>     Thanks for the great remarks! Indeed, we have had lots of lengthy
>     discussions on the way structured data node IDs work, and there
>     are several ways to handle the situations you describe.
>
>     We've reached a consensus to first detail the most demanded and
>     least controversial part - the YANG-CBOR mapping. Having
>     structured data node IDs allows for all existing designs to
>     operate with this.
>
>     I've provided you with the baseline algorithm, which covers one
>     aspect of the data node IDs. Structured data node IDs also allow
>     for private module ID space, and for non-managed modules (e.g. as
>     the example you provide). They also allow for having COMI-style
>     hashes if you need them. The draft which will describe the full
>     operation will come shortly after the YANG-CBOR draft.
>
>     I think that it would be nice if you can contribute, as your
>     remarks can help clear the readability of the document and point
>     on examples that must be provided to cover the full spectrum of
>     YANG use-cases.
>
>     Best,
>     Alexander
>
>
>     Le 08/12/2015 12:53, Juergen Schoenwaelder a écrit :
>
>         On Tue, Dec 08, 2015 at 12:11:00PM +0100, Alexander Pelov wrote:
>
>             Dear Juergen,
>
>             See inline.
>
>                 Le 8 déc. 2015 à 11:55, Juergen Schoenwaelder
>                 <[e-mail]
>                 <mailto:[e-mail]>> a écrit :
>
>                 On Tue, Dec 08, 2015 at 11:16:58AM +0100, Alexander
>                 Pelov wrote:
>
>                     Dear Juergen,
>
>                     The algorithm is straightforward - assign in
>                     increasing order a data
>                     node ID to each element on the schema tree. If you
>                     have a revision of a
>                     module, you do the diff between the old and the
>                     new tree, and add the
>                     new data node IDs at the end of the numbering.
>
>                 So I need access to the complete revision history in
>                 order to determine
>                 data node IDs, correct?
>
>             It is not a must. You can manually indicate the node IDs
>             of the newly added elements. If you want a completely
>             automated allocation of IDs, then yes. The way I think
>             this will work is - the publisher of a module will use the
>             automatic tool to generate the statements, which will then
>             be indicated in the YANG definition.
>
>         I want independently developed systems to interoperate. In
>         general, I
>         can't assume modules have data node IDs (since a YANG module
>         like lets
>         say ietf-interfaces simply does not define them).
>
>                 What about imports without a revision (a nasty
>                 source of ambiguity)?
>
>             There are two points in your question. The first is
>             straightforward - Data node IDs make sense within the
>             scope of a module. Changing a module does not affect the
>             different modules which import it, with the possible
>             exception of groupings, where the classical data node ID
>             algorithm assignment kicks in (or manual ID assignment if
>             the module author prefers so). In any case, I would refer
>             you to RFC 6020, section 5.1.1. where the question of
>             acceptability of imported modules is treated.
>
>         I am talking about imports _into_ a module that may be
>         ambigous from
>         the viewpoint of the importing module. Section 5.1.1 is about
>         import
>         by revision, my question was about what happens if there is an
>         import
>         without revision. We had lengthy discussions in NETMOD what
>         this means
>         for conformance and the outcome roughly is that this requires a
>         runtime lookup to find out which module revisions have been
>         used by a
>         given implementation, that is, your algorithm would not only
>         need the
>         complete revision history but also runtime information in order to
>         calculate unique data node ids.
>
>         There are alternate designs possible in the solution space. I
>         like to
>         understand the trade-offs between them.
>
>         /js
>
>
>     _______________________________________________
>     core mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/core
>
>