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

[Juergen Schoenwaelder]

On Tue, Apr 07, 2020 at 10:55:28PM +0200, Carsten Bormann wrote:
> On 2020-04-07, at 21:47, Juergen Schoenwaelder 
>  wrote:
> > 
> > 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.
> 
> Thank you for that feedback.
> 
> So I think we need to be a bit more radical/precise:
> 
> -YANG-CBOR should explain that SIDs are 63-bit unsigned integers and how the 
> delta encoding in the CBOR map keys works.  I.e., define the concept, but not 
> the number space management.
> 
> -sid does the latter.
> 
> The document that defines the media types (comi) gets to bind YANG-CBOR, for 
> these media types, to the specific SID concept defined in -sid.
> 
> -YANG-CBOR can still refer to -sid as a preferred way to manage the number 
> space.
> But you can implement -YANG-CBOR without understanding -sid, so this is not a 
> normative reference.
> Any other document using -YANG-CBOR can refer to -sid as well (or, 
> exceptionally, to something specific for that usage).
>

This makes sense, but I prefer to have the media types defined in
YANG-CBOR. If I use CBOR with RESTCONF, I love to depend on YANG-CBOR
only and not in addition on COMI just for the media type definition.
The serialization format is defined in YANG-CBOR, hence it makes sense
to me to define the corresponding media-type(s) there as well.

Note, I did not manage to review COMI due to a lack of time. So I am
digging into the type definitions now. RESTCONF (RFC 8040) defines:

application/yang-data+json
application/yang-data+xml

COMI defines:

application/yang-data+cbor
application/yang-identifiers+cbor
application/yang-instances+cbor

It seems that yang-data+cbor really is yang-data+cbor+sid and it seems
there is no media type for yang-data+cbor+names (i.e., the CBOR
encoding that uses names instead of SIDs as keys). The other two media
types yang-identifiers+cbor and yang-instances+cbor seem to be COMI
specific. Hence, me preference would be to define something like

application/yang-data+cbor+sid
application/yang-data+cbor+name

in YANG-CBOR and to leave the other two

application/yang-identifiers+cbor
application/yang-instances+cbor

for COMI. There is a certain interest to stream binary encoded YANG
data and having a self-contained YANG-CBOR document would be desirable
to minimize dependencies and maintenance headache down the road.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Tue, Apr 07, 2020 at 11:47:37PM +0200, Carsten Bormann wrote:
> On 2020-04-07, at 15:35, Ivaylo Petrov  wrote:
> > 
> > - If this work gets approved, will other specifications like
> >   draft-ietf-netmod-yang-data-ext-05.txt be expected to cover CBOR
> >   encoding in addition to XML and JSON? This is more a procedural
> >   question.
> > 
> > [IP]: From our discussions, I could say that that is desirable, but not 
> > something these drafts can enforce.  (Also, for drafts that already are 
> > well-advanced, one would expect a companion draft on a later timeline 
> > instead of the original text-based (JSON/XML) draft.)
> 
> Right.  Are we creating any special hardship for 
> draft-ietf-netmod-yang-data-ext?
>

This is a procedural question (i.e., nothing the ID will regulate) and
ideally the WGs involved come to some common understanding how we
handle things in the future. One option is that NETMOD agrees to take
care of CBOR as a third encoding in the future like it does take care
of XML and JSON today. What I like to avoid is that YANG evolves and
the various encodings start to work with different subsets of YANG.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Carsten Bormann]

On 2020-04-07, at 15:35, Ivaylo Petrov  wrote:
> 
> - If this work gets approved, will other specifications like
>   draft-ietf-netmod-yang-data-ext-05.txt be expected to cover CBOR
>   encoding in addition to XML and JSON? This is more a procedural
>   question.
> 
> [IP]: From our discussions, I could say that that is desirable, but not 
> something these drafts can enforce.  (Also, for drafts that already are 
> well-advanced, one would expect a companion draft on a later timeline instead 
> of the original text-based (JSON/XML) draft.)

Right.  Are we creating any special hardship for 
draft-ietf-netmod-yang-data-ext?

Grüße, Carsten

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Carsten Bormann]

On 2020-04-07, at 21:47, Juergen Schoenwaelder 
 wrote:
> 
> 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.

Thank you for that feedback.

So I think we need to be a bit more radical/precise:

-YANG-CBOR should explain that SIDs are 63-bit unsigned integers and how the 
delta encoding in the CBOR map keys works.  I.e., define the concept, but not 
the number space management.

-sid does the latter.

The document that defines the media types (comi) gets to bind YANG-CBOR, for 
these media types, to the specific SID concept defined in -sid.

-YANG-CBOR can still refer to -sid as a preferred way to manage the number 
space.
But you can implement -YANG-CBOR without understanding -sid, so this is not a 
normative reference.
Any other document using -YANG-CBOR can refer to -sid as well (or, 
exceptionally, to something specific for that usage).

Grüße, Carsten

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Ivaylo Petrov]

Hello Juergen,

Thank you for the detailed review and your comments! They truly help us
improve this document. Please find my answers below (prefixed by [IP]). Note
that the diff after handing your comments and those of Esko Dijk can be
found at [1].

Best regards,
Ivaylo

[1]:
https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-yang-cbor&url2=http://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.txt
On Tue, Mar 31, 2020 at 1:03 PM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> Hi,
>
> here is my review of draft-ietf-core-yang-cbor-12. I have not checked
> the examples in detail, I assume (hope?) the authors have used tools
> to generate them or to validate them.
>
> - Nit: There is no need to capitalize Action in the abstract (and
>   elsewhere).
>

[IP]: Fixed

- You should perhaps write 'yang-data extension' instead of 'yang data
>   template' since this is more concrete and less confusing. The use of
>   'template' is a bit unfortunate in RFC 8040 since templates have
>   been used with different meanings elsewhere and I believe people
>   more commonly refer to the yang-data extension. I also checked
>   draft-ietf-netmod-yang-data-ext-05.txt and it does not use the word
>   "template" anymore.
>
>   I see that you use 'YANG data template' later on in several places.
>   This is not strictly incorrect but I find it unfortunate. I would
>   prefer to talk specifically about the yang-data extensions. You
>   actually import both terms, I believe only one is needed (and I
>   prefer yang-data (extension) over YANG data template.
>

[IP]: Fixed following your advice.


> - If this work gets approved, will other specifications like
>   draft-ietf-netmod-yang-data-ext-05.txt be expected to cover CBOR
>   encoding in addition to XML and JSON? This is more a procedural
>   question.
>

[IP]: From our discussions, I could say that that is desirable, but not
something these drafts can enforce.  (Also, for drafts that already are
well-advanced, one would expect a companion draft on a later timeline
instead of the original text-based (JSON/XML) draft.)


> - Wording:
>
>  A new set of encoding rules has been defined to allow the use of the
>  same data models in environments based on the JavaScript Object
>  Notation (JSON) Data Interchange Format [RFC8259].  This is
>  accomplished in the JSON Encoding of Data Modeled with YANG
>  specification [RFC7951].
>
>   What is "environments based on the JavaScript Object Notation (JSON)
>   Data Interchange Format". Perhaps do not even try to speculate about
>   reasons. What about this?
>
>  An additional set of encoding rules has been defined based on the
>  JavaScript Object Notation (JSON) Data Interchange Format
>  [RFC8259].
>

[IP]: Applied and added the reference to RFC7951 as that seems relevant.
Now it reads:

An additional set of encoding rules has been defined in {{RFC7951}} based on
the JavaScript Object Notation (JSON) Data Interchange Format {{RFC8259}}.



> - 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.

- I am not sure I would call a notification or a container a
>   collection. Note that RFC 7950 uses the phrase child node quite a
>   bit in definitions, so this may do the same without using the
>   (overloaded) word collection:
>
>o  child: A schema node defined as a child node of a
>   container, a list, a case, a notification, an RPC input, an RPC
>   output, an action input, an action output.
>
>I searched the text and 'child' only shows up once and I am not
>sure this deserves to define a term at all.
>

[IP]: I modified the definition as you suggested, but I believe we should
keep it as it aims at avoiding confusion over choice and other schema nodes
that do not add any additional payload/information during the encoding.
They are not considered child nodes in the explicit definition as otherwise
we would have had to provide rules for their encoding.

- Is 'parent' the same as an 'interior node' defined in RFC 7950? If
>   so, why not use 'interior node'? Looking at the uses or parent, I am
>   not even convinced this term needs to be defined at all, the context
>   seems to be rather clear of what is me

Re: [netmod] [core] 🔔 WG Last Call of CORECONF drafts: draft-ietf-core-yang-cbor-12, -sid-11, -comi-09, -yang-library-01 / -yang-cbor-12 review

[Ivaylo Petrov]

Hello Esko,

Thank you for your review and your comments! They truly help us improve
this document. Please find my answers below (prefixed with [IP]). Note that
the diff after handing your comments and those of Juergen Schoenwaelder can
be found at [1].

Best regards,
Ivaylo

[1]:
https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-yang-cbor&url2=http://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.txt
On Mon, Mar 30, 2020 at 2:24 PM Esko Dijk 
wrote:

> Hello CoRE,
>
> I did a review of draft-ietf-core-yang-cbor-12 and some comments are
> below. I do support the publication of this document but feel a few updates
> of minor items are still needed! See the items below:
>
> Section 3: "This specification supports two type of CBOR keys" -> two
> types of CBOR keys
>

[IP]: Fixed

Section 3: This root CBOR map is provided only as a typical usage example
> and is
>not part of the present encoding rules.  Only the value within this
> CBOR map is compulsory.
> -> Not fully clear to me, how can an example be compulsory? Other values
> within the CBOR map could also be used, right? Also it wasn't fully clear
> to me how the data structure would otherwise be encoded if not with a root
> CBOR map. Maybe good to give an example of how it would otherwise be
> encoded if not with a root CBOR map!
>

[IP]: This stems from the separation between CoMI and YANG to CBOR - in
CoMI we have complete examples with the complete encoding of elements that
were requested, whereas here we provide only instructions how particular
elements need to be encoded - regardless of the fact that they might be a
part of a bigger payload or part of a protocol that handles the external
wrapping. Where this causes issues is SID deltas for example - without the
wrapping elements, it would not be clear how that would work. Please let us
know if you could think of a better way to express this.


> Section 3.1: Table 1 uses both uppercase and lowercase in the last column
> for the CBOR encoding. Best practice is to use either uppercase or
> lowercase for hexadecimal, but not mixed I think.
>

[IP]: Fixed


> Section 4.5.2: "example-port: example-port-fault" :
> -> space after ':' is to be removed. At least I think a space isn't
> allowed there.
>

[IP]: Fixed


> Section 3.3 / 4.5.1 "as follow"
> -> as follows
>

[IP]: Fixed


> Section 4.6: "data items tagged with one of the tag listed"
> -> the tags listed
>

[IP]: Fixed

Section 4.6: the "anyxml bar" definition should have "# SID 6" comment,
> like for the other YANG definitions that have a "# SID ." comment .
>

[IP]: Fixed


> Section 5.1: "YANG template encoded using SIDs are carried in "
> -> YANG templates ...
>

[IP]: Changed request from Juergen Schoenwaelder made this look like:

The yang-data extensions encoded using SIDs are carried in a CBOR map
containing a single item pair. The key of this item is set to the SID
assigned to the YANG template container, the value is set the CBOR encoding
of this container as defined in {{container}}.



> Section 5.2 similar sentence as 5.1 above
>

[IP]: Fixed similarly to the above one.


> Section 6.6 example:
>   type union {
>  type int32;
>  type enumeration {
>enum "unbounded";
>  }
>}
>
> unclear why "unbounded" is within quotes? The CBOR encoding of this
> example encodes the word 'unbounded' without the quotes, which would look
> like:
>type enumeration {
>enum unbounded;
>  }
> An open question to me is whether RFC 7950 section 9.12.4 has the word
> unbounded in quotes on purpose, or by mistake. None of the other examples
> of enum statements use the quotes! Why would this example suddenly use the
> quotes? In any case if quotes are used then per RFC 7950 definitions the
> quotes must also be encoded as part of the yang-string.
>

[IP]: I believe that was copied indeed from RFC 7950 as it is. I could not
find a reason why it should be with quotes, so I removed them as you
suggested.


> Section 6.6: Tag 44 use - in section 8.1, the table states that the tag
> must mark a data item of type unsigned integer. Which is not the case here,
> it marks a string.
>

[IP]: It should be a "text string" in Section 8.1. This has changed
relatively recently and obviously we overlooked the values in the table.
Fixed now


> Section 6.7: similar to section 6.6, the tag 43 mentions data item "byte
> string" in Section 8.1 while in section 6.7 it is followed by a text string.
> Just to be clear: if a 'bits' type is encoded, it looks like the tag 43 is
> only used if followed by a text string as in 43("under-repair critical") ?
> Or should a tag 43 also be used in case a CBOR byte string follows?
> E.g. 43(h'06') instead of h'06' ? That doesn't seem to be the intention in
> the current text.
>

[IP]: It should be a "text string" in Section 8.1. Fixed now. My reading of
this is that the tag 43 can only be used inside unions.

Section 8.1: could indicate here what the column 'Data Item' means. E.

[netmod] JSON encoding of events in draft-ietf-netconf-https-notif

[Kent Watsen]

Moving to “netconf” (“netmod” in BCC)

K. 




Sent from my iPhone
>> On Apr 7, 2020, at 4:35 AM, Balázs Lengyel 
>>  wrote:
> 
> Hello Mahesh, Kent,
> I was wondering how the JSON encoding of event would look like in your draft. 
> (I intend to propose something similar to 3GPP so I am most interested.)
> The part below push-update or push-change-update is well defined in YANG 
> however the part outside is not. In Restconf 
> (https://trac.tools.ietf.org/html/rfc8040#section-6.4) I see the following 
> example:
>  
> {
> "ietf-restconf:notification" : {
>   "eventTime" : "2013-12-21T00:01:00Z",
>   "example-mod:event" : {
> "event-class" : "fault",
> "reporting-entity" : { "card" : "Ethernet0" },
> "severity" : "major"
>   } } }
>  
> However how would the first 2 lines look here? IMHO keeping restconf as a 
> module name seems wrong.
> So maybe we should define it here in this draft :
> {
>  "json-yang-notification:notification" : {
>   "eventTime" : "2013-12-21T00:01:00Z",
>   "push-change-update" : {
> ...
>   } } }
>  
> How to define this wrapper (the first 2 lines, I am unsure. As far as I know 
> it is not possible to describe this in YANG.  Maybe just some text like:
> The YANG encoding of the notification SHALL be wrapped in a JSON object as 
> illustrated below
>  
> "json-yang-notification:notification" : {
>   "eventTime" : "2013-12-21T00:01:00Z",
>  
>  
> Also I would definitely need an example of a notification sent.
> Regards Balazs
>  
> --
> Balazs LengyelSenior Specialist   
> Ericsson Hungary Ltd.
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] JSON encoding of events in draft-ietf-netconf-https-notif

[Balázs Lengyel]

Hello Mahesh, Kent,

I was wondering how the JSON encoding of event would look like in your
draft. (I intend to propose something similar to 3GPP so I am most
interested.)

The part below push-update or push-change-update is well defined in YANG
however the part outside is not. In Restconf
(https://trac.tools.ietf.org/html/rfc8040#section-6.4) I see the following
example:

 

{

"ietf-restconf:notification" : {

  "eventTime" : "2013-12-21T00:01:00Z",

  "example-mod:event" : {

"event-class" : "fault",

"reporting-entity" : { "card" : "Ethernet0" },

"severity" : "major"

  } } }

 

However how would the first 2 lines look here? IMHO keeping restconf as a
module name seems wrong. 

So maybe we should define it here in this draft :

{

 "json-yang-notification:notification" : {

  "eventTime" : "2013-12-21T00:01:00Z",

  "push-change-update" : {

...

  } } }

 

How to define this wrapper (the first 2 lines, I am unsure. As far as I know
it is not possible to describe this in YANG.  Maybe just some text like:

The YANG encoding of the notification SHALL be wrapped in a JSON object as
illustrated below

 

"json-yang-notification:notification" : {

  "eventTime" : "2013-12-21T00:01:00Z",

 

 

Also I would definitely need an example of a notification sent.

Regards Balazs

 

-- 

Balazs LengyelSenior Specialist
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod