Re: [netmod] [core] js review of draft-ietf-core-yang-cbor-12

[Juergen Schoenwaelder <[e-mail]>]

Dear Ivaylo,

thanks for your item-by-item response. I will cut things down to the
few items I felt I still want to comment on (everything else I
consider resolved).

On Tue, Apr 07, 2020 at 03:35:37PM +0200, Ivaylo Petrov wrote:
 
> > - Is there a reason why SID terminology is not imported from the SID
> >   specification? Is the reason to avoid a dependency? But then, can
> >   this dependency really be avoided? I reviewed the SID document first
> >   because I thought knowing what SIDs are is essential to understand
> >   this document...
> >
> 
> [IP]: This decision has been made before my personal involvement with this
> document. I will let the other authors correct me if I am mistaken, but my
> understanding is that while it is a good candidate, we did not necessarily
> want to mandate the use of the SID draft in order to use the yang-cbor
> draft. If the implementers want to have another way of deriving meaning for
> the SIDs, that is fine. I will have to verify if the interoperability in
> this case was a concern and how it was supposed to be handled.

For me, the question is whether this ID defines SIDs and the other ID
details how they are managed or this ID imports the definition of SIDs
from the other document, which also details how they are managed.
Right now, it seem something in between, i.e., it is not clear what
the dependencies between these specifications is.
 
> > - To summarize the last few comments, I propose to import 'item' and
> >   'SID' from the SID document, to not define 'child' and 'parent'
> >   (following RFC 7950), and so the only term to defined here is
> >   'delta'. But see above concerning the relationship to the SID
> >   document; it is not clear to me what the goals and intentions are in
> >   terms of intended document dependencies.
> >
> 
> [IP]: I believe that my previous points provide the relevant answers, but do
> not hesitate to let us know if you have more concerns about any of your
> remarks.

Your solution kind of works for me. Note that here is one usage of
'collection' left in section 4.4.
 
> - I do not understand this statement:
> >
> >    Application payloads carrying a value serialized using the rules
> >    defined by this specification (e.g.  CoAP Content-Format) SHOULD
> >    include the identifier (e.g.  SID, namespace qualified name,
> >    instance-identifier) of this value.
> >
> >   What is "the identifier of this value"? I am not getting what
> >   is being conveyed here.
> 
> 
> [IP]: I rewrote this as
> 
> When schema node are serialized using the rules defined by this
> specification as part of an application payload, the payload SHOULD include
> information that would allow a stateless way to identify each node, such as
> the SID number associated with each node, SID delta from another SID in the
> application payload, the namespace qualified name or the
> instance-identifier.
> 
> Please let us know if that is more clear.

This is better, but I am still not sure what exactly this SHOULD is
about. The SIDs in the payload are assumed to be unique and so are
names and paths. So what is the requirement for an 'application
payload' that uses this serialization format?

(nit: first noun should be plural)
 
> - SIDs other than [I-D.ietf-core-sid]?
> >
> >      [...] If SIDs are to be used, the present specification is
> >      used in conjunction with a specification defining this management.
> >      One example for such a specification is [I-D.ietf-core-sid].
> >
> >   This seems to indicate that there can be other kinds of SIDs or SIDs
> >   managed differently. Why is this? The SID I-D claims the entire
> >   number space, so how would a different 'specification defining the
> >   management of SIDs' ever work? Why not be specific that the usage of
> >   SIDs depends on [I-D.ietf-core-sid]? See my earlier comments about
> >   the unclear dependency relationship between this specification and
> >   the SID specification.
> >
> 
> [IP]: My understanding is that indeed there is the presumption that other
> implementations that map YANG item identifiers to unsigned numbers could
> exist in the future. If this is the case, I am not aware how one could
> interoperate (I would guess based on the content format), but I will let my
> coauthors comment on that.

Such a different mapping would most likely have to use separate SID
allocations, i.e., a part of the number space may be managed
differently but the resulting number is still a SID. (Of course, the
whole idea sounds pretty scary in terms of interoperability.)

/js

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