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

[Andy Bierman]

On Wed, Apr 8, 2020 at 3:58 AM Carsten Bormann  wrote:

> On 2020-04-08, at 10:49, Carsten Bormann  wrote:
> >
> > One way to build a content-type from a media-type name is to add a
> parameter:
> >
> > application/yang-data+cbor; id=name
> > application/yang-data+cbor; id=sid
>
> Ha.
>
> Let’s create a registry in yang-cbor for id= values (initially filled with
> id=name).
> -sid can then register id=sid in that.
>
> Look, ma, no normative references!
>
> Grüße, Carsten
>
> PS. If you wonder why I care about normative references: RFC 7252 got
> stuck for a year in 2013 for an ill-advised normative reference.  And have
> a look at
> https://www.rfc-editor.org/current_queue.php#draft-ietf-anima-grasp —
> 140+ weeks of waiting for a (totally unneeded) normative reference…
>
>
draft-ietf-netmod-syslog-model-26 has been in MISREF state for 754 days and
counting.
Talk about ill-advised normative references...

Andy


> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
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

[Andy Bierman]

On Wed, Apr 8, 2020 at 7:41 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Wed, Apr 08, 2020 at 01:55:47PM +0200, Carsten Bormann wrote:
> > >> Ha.
> > >>
> > >> Let’s create a registry in yang-cbor for id= values (initially filled
> with id=name).
> > >> -sid can then register id=sid in that.
> > >
> > > He? yang-cbor defines how to use sids as ids so I see no reason to not
> > > also register the id=sid in yang-cbor. I thought we settled on
> > > yang-cbor defines what sids are and the sid id details how they are
> > > assigned and how the number space is managed. This way, yang-cbor is
> > > the base document and the sid document has a normative reference to
> > > yang-cbor and comi has a normative reference to yang-cbor. Is there
> > > a reason that speaks against this?
> >
> > Hi,
> >
> > The media type could simply say “uses the concept of SIDs” or it could
> say “uses SIDs as allocated in -sid”.
> > I’m not sure the media type needs to say anything at all about this, but
> if it does, for completeness I think it would need to do the latter (so we
> can have other media types that get their SIDs elsewhere).
> > That would mean a normative reference from yang-cbor to -sid.
> > The registry trick turns that around.
> >
>
> I want a bit that tells me how instance naming is done, using names or
> SIDs. I want to use this to send a query and tell the server that I
> want to get CBOR encoded data with SIDS
>
>   GET /restconf/yang-library-version HTTP/1.1
>   Host: example.com
>   Accept: application/yang-data+cbor;id=sid
>
> or with names are keys
>
>   GET /restconf/yang-library-version HTTP/1.1
>   Host: example.com
>   Accept: application/yang-data+cbor;id=name
>
> This bit should be defined in YANG-CBOR since this document goes into
> quite some detail defining both options to name data.
>
>

It would be up to the server vendor whether the protocol supported
multiple variants of CBOR encoding.  The intent for CoMI is that
a server without name string support could be implemented.


The question whether alternate schemes can exist to allocate SIDs is
> less important for me. I hope multiple schemes to assign SIDs will not
> be needed - or only needed in case the scheme defined in the SID
> document turns out to be broken up to the point that it can only be
> replaced.
>
> That said: A real complication may be the YANG versioning work. Once
> publishedd YANG definitions are allowed to change arbitrarily, the
> allocation and management of SIDs may get really interesting.
>
>
The SID assignments cannot change once an RFC is published.
Any NBC changes to published modules would require new SID assignments.

Or is the idea that once we conclude the current SID allocation scheme
> to be broken, we go define a SIDplus allocation scheme and then we
> still use SIDs in YANG-CBOR but the meaning of the numbers is entirely
> different, i.e., we use
>
>   GET /restconf/yang-library-version HTTP/1.1
>   Host: example.com
>   Accept: application/yang-data+cbor;id=sidplus
>
> to make it clear that the SID numbers now mean something different?
>


I do not understand why the SID allocation scheme is broken but if future
requirements make it deficient then a replacement (e.g. sid2, sidplus) could
be introduced.



> This may make sense and then it may make sense to define
>
> application/yang-data+cbor;id=name
>
> in YANG-CBOR and to define
>
> application/yang-data+cbor;id=sid
>
> in the SID document - which means you can't use SIDs with just
> YANG-CBOR but only in the context of another document detailing how
> SIDs are allocated and managed. Perhaps this is what you have in mind?
>
> Whatever we conclude, it would be nice to get things properly
> documented so that we recall the grand plan in N years from now.



>
>
/js
>
>
Andy


> --
> 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
>
___
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 Wed, Apr 08, 2020 at 01:55:47PM +0200, Carsten Bormann wrote:
> >> Ha.
> >> 
> >> Let’s create a registry in yang-cbor for id= values (initially filled with 
> >> id=name).
> >> -sid can then register id=sid in that.
> > 
> > He? yang-cbor defines how to use sids as ids so I see no reason to not
> > also register the id=sid in yang-cbor. I thought we settled on
> > yang-cbor defines what sids are and the sid id details how they are
> > assigned and how the number space is managed. This way, yang-cbor is
> > the base document and the sid document has a normative reference to
> > yang-cbor and comi has a normative reference to yang-cbor. Is there
> > a reason that speaks against this?
> 
> Hi,
> 
> The media type could simply say “uses the concept of SIDs” or it could say 
> “uses SIDs as allocated in -sid”.
> I’m not sure the media type needs to say anything at all about this, but if 
> it does, for completeness I think it would need to do the latter (so we can 
> have other media types that get their SIDs elsewhere).
> That would mean a normative reference from yang-cbor to -sid.
> The registry trick turns that around.
>

I want a bit that tells me how instance naming is done, using names or
SIDs. I want to use this to send a query and tell the server that I
want to get CBOR encoded data with SIDS

  GET /restconf/yang-library-version HTTP/1.1
  Host: example.com
  Accept: application/yang-data+cbor;id=sid

or with names are keys

  GET /restconf/yang-library-version HTTP/1.1
  Host: example.com
  Accept: application/yang-data+cbor;id=name

This bit should be defined in YANG-CBOR since this document goes into
quite some detail defining both options to name data.

The question whether alternate schemes can exist to allocate SIDs is
less important for me. I hope multiple schemes to assign SIDs will not
be needed - or only needed in case the scheme defined in the SID
document turns out to be broken up to the point that it can only be
replaced.

That said: A real complication may be the YANG versioning work. Once
publishedd YANG definitions are allowed to change arbitrarily, the
allocation and management of SIDs may get really interesting.

Or is the idea that once we conclude the current SID allocation scheme
to be broken, we go define a SIDplus allocation scheme and then we
still use SIDs in YANG-CBOR but the meaning of the numbers is entirely
different, i.e., we use

  GET /restconf/yang-library-version HTTP/1.1
  Host: example.com
  Accept: application/yang-data+cbor;id=sidplus

to make it clear that the SID numbers now mean something different?
This may make sense and then it may make sense to define

application/yang-data+cbor;id=name

in YANG-CBOR and to define

application/yang-data+cbor;id=sid

in the SID document - which means you can't use SIDs with just
YANG-CBOR but only in the context of another document detailing how
SIDs are allocated and managed. Perhaps this is what you have in mind?

Whatever we conclude, it would be nice to get things properly
documented so that we recall the grand plan in N years from now.

/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]  admin WG Last Call of CORECONF drafts: draft-ietf-core-yang-yang-library-01

[Ivaylo Petrov]

Hello Tom,

Thank you for your review and your comments! They were indeed very helpful.
I will try to spend some more time making sure we follow the
recommendations from RFC8407, but for now please find my answers below
(prefixed with [IP]). Note that the diff after handing your comments can be
found at [1] for the txt file diff and [2] for the raw Markdown diff.

Best regards,
Ivaylo

[1]:
https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-yang-library=http://core-wg.github.io/yang-cbor/draft-ietf-core-yang-library-latest.txt
[2]:
https://github.com/core-wg/yang-cbor/commit/2aa29f2468c827fd4b58cad6a5decba795d9c767


On Mon, Mar 30, 2020 at 12:11 PM tom petch  wrote:

> There is quite a lot wrong with the admin of the YANG-library I-D when
> compared with RFC8407 IMHO
>
> Security considerations does not conform to boiler plate
>

[IP]: Adding the following text in the beginning of the security
considerations will make it follow the same structure as RFC7895. Would
that be acceptable for you?

The YANG module defined in this memo is designed to be accessed via CORECONF
{{-comi}}, NETCONF {{RFC6241}} or RESTCONF {{RFC8040}}. Depending on the
used
protocol, the security considerations of some or all of those will apply.



> IANA considerations does not register name space
>

[IP]: I added such registration. Please let me know if it looks fine. The
relevant text is:


## YANG Namespace Registration

This document registers the following XML namespace URN in the "IETF XML
Registry", following the format defined in {{RFC3688}}:

URI: please assign urn:ietf:params:xml:ns:yang:ietf-constrained-yang-library

Registrant Contact: The IESG.

XML: N/A, the requested URI is an XML namespace.



> RFC 6991  is imported and so MUST be a Normative reference
>

[IP]: Fixed


> ietf-sid-file is imported and so MUST be a Normative  not Informative
> reference for the I-D
>

[IP]: Fixed

reference ietf-core-sid would be better as RFC  with an RFC Editor note
> asking them to replace  with the number assigned to 'YANG Schema ...
>

[IP]: Fixed


> Organization Netconf WG seems an odd choice and contradicts contact details
>

[IP]: Changed to CoRE WG


> Contact does not normally specify WG Chairs
>
>
[IP]: I removed the chairs and left only the group and the editors. Is that
what you had in mind?

more than one revision clause
>

[IP]: Fixed


> CORECONF not an abbreviation I recognise
>

[IP]: We have received other comments related to this. We will discuss them
during the meeting today and try to clarify this.


> I will look some more as and when these are addressed (or I see IETF Last
> Call:-)
>
> Tom Petch
> 
> From: netmod  on behalf of Carsten Bormann <
> c...@tzi.org>
> Sent: 09 March 2020 13:04
> To: core
> Cc: netmod@ietf.org
> Subject: [netmod]  WG Last Call of CORECONF drafts:
> draft-ietf-core-yang-cbor-12, -sid-11, -comi-09, -yang-library-01
>
> It took us a long time to get the four CORECONF drafts in sync,
> but now we are ready for WGLC.
>
> This starts a working group last call for
> — draft-ietf-core-yang-cbor-12
> — draft-ietf-core-sid-11
> — draft-ietf-core-comi-09
> — draft-ietf-core-yang-library-01
>
> ending on
>
> 24:00 UTC on Tuesday, March 31, 2020.
>
> (This includes some extra time for the IETF week and for cross-WG
> coordination.)
>
> This WGLC is copied to the netmod WG mailing list; please do have a look
> at these drafts as they are slated to become a part of the greater
> YANG/NETCONF/RESTCONF family.  We intend the discussion to be on the
> CoRE mailing list, but if you find a fundamental issue with YANG or
> RESTCONF, feel free to discuss that on netmod instead.
>
> Please start a new email thread for each major issue that will need
> discussion and make sure the subject line includes the draft name and
> some sort of name for the issue.  (Minor issues such as typos can also
> be sent to the authors.)
>
> If you read the draft and think it looks fine, please send a one line
> email to the list or to the chairs letting us know that so we can get
> a feel of how broad the review has been.
>
> (To reviewers and authors:)  If you are aware of any patent claims that
> might apply to systems that implement these drafts, please review BCP 78
> and BCP 79 and make any appropriate IPR declaration before the last-call
> ends. If you are not sure whether you need to make a declaration or not,
> please talk to the chairs and we will help.
>
> Grüße, Carsten
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> ___
> core mailing list
> c...@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Shepherd review on draft-ietf-netmod-yang-instance-file-format-10

[Balázs Lengyel]

Hello Kent,
Thanks for the review. See answers below.
I tried to address all you comments, sorry if I missed something. 
I updated the draft and uploaded a -11 version. Please check/advance it.

One question I could not settle: XML2RFC does not accept

Only

Why ? Please help.
Regards Balazs

-Original Message-
From: netmod  On Behalf Of Kent Watsen
Sent: 2020. március 31., kedd 3:50
To: netmod@ietf.org
Subject: Re: [netmod] Shepherd review on 
draft-ietf-netmod-yang-instance-file-format-10

[UPDATE: I just realized that I prematurely stopped the review after the YANG 
module.  Picking up where I left off…]


Structural Issues:

 - S5 contains an mix of important and unimportant information.   I think that 
the most important thing to state that the module defines an offline format 
that MAY contain security sensitive information, and thus safe handling is 
advised.  Maybe also say something about because the YANG module only defines a 
“structure”,  the Security Considerations doesn’t follow the template specified 
in https://tools.ietf.org/html/rfc8407#section-3.7.1).  For instance: s/is 
designed as a wrapper specifying a format and a metadata header for YANG 
instance data defined by the content-schema/specifies an offline format/
BALAZS: Most of text was required to be put there by earlier reviewers (Mostly 
Juergen and Acee Lindem) and sent to the mailing list.
I added that we do not follow the security template for YANG models.
  - S6.1. the full registration is not inside the .  (How could happen?)
BALAZS: Corrected
  - S8.1: I-D.ietf-netmod-yang-data-ext should be listed last, as the number it 
will be the greater than any other...
BALAZS: The order of references is decided by Xml2Rfc. In the draft-..xml it is 
the last.
  - S8.1: RFC8340 is Informative
BALAZS: OK
  - S8.1: agreed that RFC8525 is Normative, but the only place it it referenced 
is in a non-normative section…please add a ref to it from a normative section.
BALAZS: It is referenced from the YANG module which is normative.
  - S8.2: same comment as before re: floating the I-D refs to the end…
BALAZS: The order of references is decided by Xml2Rfc. In the draft-..xml it is 
the last.
  - Appendix C: remove the unnecessary “C.1” section.
BALAZS: OK

Editorial Issues:

  - Appendix B:
 - s/For instance data/Instance data/
BALAZS: Sorry, that would make the sentence incorrect.
 - “...to avoid are listed.” - listed where?  Section reference?
BALAZS: In the next list in the same chapter. Added "below".
 - In P2, how is the 2nd sentence connected to the 1st?
BALAZS: Separated them into 2 paragraphs. Instance data can be produced 
automatically or by some design activity. I was told by a previous reviewer 
that I should provide these guidelines only for the latter. However the 
guidelines are valid and important as proven by experience.
 - s/may lead to problems/may lead to the following problems:/?
BALAZS: OK
  - Appendix C:
  - Don’t put “Non-Normative” into the Section title (move to 1st sentence 
of section) 
BALAZS: OK, changed (earlier it was requested to have it in the title.)
  - s/We present/This section presents/
  - s/use cases were YANG/use cases where YANG/
  - Actually, this whole sentence is meaningless
BALAZS: removed  

I gave up reviewing Section C at C.1.1, since it’s non-normative.  Honestly, 
I'd remove the entire section but, if you want to keep it, I suggest reviewing 
it for issues…


Kent // shepherd



> On Mar 30, 2020, at 3:22 PM, Kent Watsen  wrote:
> 
> 
> As part of the Shepherd writeup, I read the entire draft and found the 
> following issues, which I’d like to see resolved before progressing the 
> document.  Most of these issues should have been caught be the WG and/or 
> Editors...
> 
> 
> Logical Issues:
> 
>  - S3, P8 defines MUSTs inside a SHOULD, a logical contradiction.
BALAZS: Changed to SHOULD
>  - In S3, P8 (the P beginning w/ "The name of”), text fails to indicate what 
> SHOULD be done if both “revision” and “timestamp” are present?
BALAZS: IMHO the preference depends on the use case, so a general guidance 
cannot be given.
>  - the syntax grammar used in S3, P8 doesn’t make sense - use ABNF?
BALAZS: 
>  - In S3, P8: “the semicolons and the decimal point, if present, shall be 
> replaced by underscores” - why are they not escaped?
BALAZS: This is a file name. Escaping in file names does not always work 
(depending on the filesystem and tools used). This is more simple and 
understandable
>  - Example 1 seems semantically invalid?  e.g., "ietf-netconf-monitoring” is 
> in "content-data" though not in "modules-state”.  Also, "module-set-id” is 
> missing 
BALAZS: OK, added. 
The original example is valid, just illogical. It follows the YANG modules 
defined in the content schema; it is allowed to have partial data sets, so some 
modules may be omitted from modules-state. However you are right this is 
illogical.
module-set-id does not 

[netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-11.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : YANG Instance Data File Format
Authors : Balazs Lengyel
  Benoit Claise
Filename: draft-ietf-netmod-yang-instance-file-format-11.txt
Pages   : 27
Date: 2020-04-08

Abstract:
   There is a need to document data defined in YANG models when a live
   server is unavailable.  Data is often needed at design or
   implementation time or needed when a live running server is
   unavailable.  This document specifies a standard file format for YANG
   instance data, which follows the syntax and semantics of existing
   YANG models, and annotates it with metadata.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-11
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-11


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
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]

>> Ha.
>> 
>> Let’s create a registry in yang-cbor for id= values (initially filled with 
>> id=name).
>> -sid can then register id=sid in that.
> 
> He? yang-cbor defines how to use sids as ids so I see no reason to not
> also register the id=sid in yang-cbor. I thought we settled on
> yang-cbor defines what sids are and the sid id details how they are
> assigned and how the number space is managed. This way, yang-cbor is
> the base document and the sid document has a normative reference to
> yang-cbor and comi has a normative reference to yang-cbor. Is there
> a reason that speaks against this?

Hi,

The media type could simply say “uses the concept of SIDs” or it could say 
“uses SIDs as allocated in -sid”.
I’m not sure the media type needs to say anything at all about this, but if it 
does, for completeness I think it would need to do the latter (so we can have 
other media types that get their SIDs elsewhere).
That would mean a normative reference from yang-cbor to -sid.
The registry trick turns that around.

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]

On Wed, Apr 08, 2020 at 12:58:41PM +0200, Carsten Bormann wrote:
> On 2020-04-08, at 10:49, Carsten Bormann  wrote:
> > 
> > One way to build a content-type from a media-type name is to add a 
> > parameter:
> > 
> > application/yang-data+cbor; id=name
> > application/yang-data+cbor; id=sid
> 
> Ha.
> 
> Let’s create a registry in yang-cbor for id= values (initially filled with 
> id=name).
> -sid can then register id=sid in that.

He? yang-cbor defines how to use sids as ids so I see no reason to not
also register the id=sid in yang-cbor. I thought we settled on
yang-cbor defines what sids are and the sid id details how they are
assigned and how the number space is managed. This way, yang-cbor is
the base document and the sid document has a normative reference to
yang-cbor and comi has a normative reference to yang-cbor. Is there
a reason that speaks against this?

/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,

I like this solution, but I am wondering if it will create a normative
reference in the other direction (sid to yang-cbor) and would we be fine
with that.

Best regards,
Ivaylo


On Wed, Apr 8, 2020 at 12:58 PM Carsten Bormann  wrote:

> On 2020-04-08, at 10:49, Carsten Bormann  wrote:
> >
> > One way to build a content-type from a media-type name is to add a
> parameter:
> >
> > application/yang-data+cbor; id=name
> > application/yang-data+cbor; id=sid
>
> Ha.
>
> Let’s create a registry in yang-cbor for id= values (initially filled with
> id=name).
> -sid can then register id=sid in that.
>
> Look, ma, no normative references!
>
> Grüße, Carsten
>
> PS. If you wonder why I care about normative references: RFC 7252 got
> stuck for a year in 2013 for an ill-advised normative reference.  And have
> a look at
> https://www.rfc-editor.org/current_queue.php#draft-ietf-anima-grasp —
> 140+ weeks of waiting for a (totally unneeded) normative reference…
>
>
___
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-08, at 10:49, Carsten Bormann  wrote:
> 
> One way to build a content-type from a media-type name is to add a parameter:
> 
> application/yang-data+cbor; id=name
> application/yang-data+cbor; id=sid

Ha.

Let’s create a registry in yang-cbor for id= values (initially filled with 
id=name).
-sid can then register id=sid in that.

Look, ma, no normative references!

Grüße, Carsten

PS. If you wonder why I care about normative references: RFC 7252 got stuck for 
a year in 2013 for an ill-advised normative reference.  And have a look at 
https://www.rfc-editor.org/current_queue.php#draft-ietf-anima-grasp — 140+ 
weeks of waiting for a (totally unneeded) normative reference…

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

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

[Alexander Pelov]

Dear all,

I have no additions or remarks on the documents. They are and in my opinion
have been ready for some time - waiting for reviews and input from
other contributors / WGs. Now, I'm even more confident the documents are
ready (once the final remarks are addressed of course).

We've had interop tests several versions ago, and since then I have
followed the development and the diffs of the documents. They are inline
with what we have been discussing and have only improved the technology.

Cheers,
Alexander



On Mon, Mar 30, 2020 at 2:26 PM Laurent Toutain <
laurent.tout...@telecom-bretagne.eu> wrote:

> Hi,
>
> I've uses these drafts, mainly -sid, -cbor, -comi, when I was defining the
> SCHC Data Model to study the impact of CORECONF on the serialization.
> For me, it is a mature work describing CORECONF. Documents are clear with
> examples. I looked at the diff for the latest versions and I don't see
> any significant changes, so for me, these documents are ready.
>
> Laurent
>
> On Mon, Mar 30, 2020 at 1:18 PM Esko Dijk 
> wrote:
>
>> Hello CoRE,
>>
>> I did a quick review of the -sid-11 draft; it looks ready for
>> publication. Some minor issues found :
>>
>> Reference to RFC 7120 early allocation procedure: the allocation policies
>> for the registries are all "Expert review". And the RFC 7120 early
>> allocation procedure is defined, to do early allocations. However RFC 7120
>> mentions that this procedure only applies in case :
>>(Section 2)
>>a. The code points must be from a space designated as "RFC
>>Required", "IETF Review", or "Standards Action".  Additionally,
>>requests for early assignment of code points from a
>>"Specification Required" registry are allowed if the
>>specification will be published as an RFC.
>> So at first sight it looks like the procedure is not applicable, taken
>> strictly. However IANA indicates (
>> https://www.iana.org/help/protocol-registration) that "Expert review" is
>> part of "Specification Required" so it would apply still. But in RFC 8126
>> this is not mentioned in the same manner - so it could confuse some readers
>> about whether it applies or not. Maybe some text could be added to state
>> why RFC 7120 process does apply to the "Expert review" policy, even though
>> "Expert review" is not listed under Section 2 point a. of RFC 7120.  (Note
>> that early allocation by RFC 7120 only applies to "Expert review"
>> allocations for draft documents that aim to become RFC.)
>>
>> Section 6.3.3: table column 1 is very narrow and it breaks the entry
>> point integer number, which is confusing. Why not make this column wider by
>> one character? One of the last 2 columns can be made more narrow if needed.
>>
>> Section 3: "RESCONF" -> RESTCONF
>>
>> Section 3: CoRECONF -> CORECONF
>>
>> Section 3: "For example how this could be achieved, please refer to"
>> -> For examples on how this could be achieved, please refer to
>>
>> Section 3: "For diagram of one"
>> -> For a diagram of one ...
>>
>> Best regards
>>
>> Esko
>>
>> IoTconsultancy.nl  |  Email/Skype: esko.d...@iotconsultancy.nl
>>
>>
>>
>> -Original Message-
>> From: core  On Behalf Of Carsten Bormann
>> Sent: Monday, March 9, 2020 14:05
>> To: core 
>> Cc: netmod@ietf.org
>> Subject: [core]  WG Last Call of CORECONF drafts:
>> draft-ietf-core-yang-cbor-12, -sid-11, -comi-09, -yang-library-01
>>
>> It took us a long time to get the four CORECONF drafts in sync,
>> but now we are ready for WGLC.
>>
>> This starts a working group last call for
>> — draft-ietf-core-yang-cbor-12
>> — draft-ietf-core-sid-11
>> — draft-ietf-core-comi-09
>> — draft-ietf-core-yang-library-01
>>
>> ending on
>>
>> 24:00 UTC on Tuesday, March 31, 2020.
>>
>> (This includes some extra time for the IETF week and for cross-WG
>> coordination.)
>>
>> This WGLC is copied to the netmod WG mailing list; please do have a look
>> at these drafts as they are slated to become a part of the greater
>> YANG/NETCONF/RESTCONF family.  We intend the discussion to be on the
>> CoRE mailing list, but if you find a fundamental issue with YANG or
>> RESTCONF, feel free to discuss that on netmod instead.
>>
>> Please start a new email thread for each major issue that will need
>> discussion and make sure the subject line includes the draft name and
>> some sort of name for the issue.  (Minor issues such as typos can also
>> be sent to the authors.)
>>
>> If you read the draft and think it looks fine, please send a one line
>> email to the list or to the chairs letting us know that so we can get
>> a feel of how broad the review has been.
>>
>> (To reviewers and authors:)  If you are aware of any patent claims that
>> might apply to systems that implement these drafts, please review BCP 78
>> and BCP 79 and make any appropriate IPR declaration before the last-call
>> ends. If you are not sure whether you need to make a declaration or not,
>> please talk to the chairs and we will help.
>>
>> Grüße, 

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

[Carsten Bormann]

Hi Jürgen,

> On 2020-04-08, at 08:57, Juergen Schoenwaelder 
>  wrote:
> 
> 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

(We couldn’t use that syntax for the media type name, as +sid is not a 
structured syntax suffix, but I get the point.)

One way to build a content-type from a media-type name is to add a parameter:

application/yang-data+cbor; id=name
application/yang-data+cbor; id=sid

(In the CoAP content-format those content types would just be two different 
content-format numbers.)

But we could also encode that parameter in the media type name.
We would have to end the media type name with “+cbor”, because that is the 
structured syntax suffix that applies.

> 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

That would put the normative reference to -sid back into YANG-CBOR.
Yes, we could do that.

Grüße, Carsten

PS.: The terminology for media types is a mess^W^W underdeveloped; see the 
expired 
https://tools.ietf.org/html/draft-bormann-core-media-content-type-format-01.txt 
for more info.

> and to leave the other two
> 
> application/yang-identifiers+cbor
> application/yang-instances+cbor
> 
> for COMI.

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

Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

[Balázs Lengyel]

I would like to allow require-instance in derived types (done in errata or
any other way) because we allow other constraints to be changed. Regularity
of YANG is very important for me. Learning YANG is difficult enough without
adding new exception cases.

Also as I consider this undefined, it is better to document whether this is
allowed or not. This is a binary decision, either/or. If setting it as a
YANG language rule is to strict, we still need a guideline at least for RFC
authors, shall we consider it a problem or not? 
Balazs

-Original Message-
From: netmod  On Behalf Of Martin Björklund
Sent: 2020. április 6., hétfő 13:38
To: j.schoenwael...@jacobs-university.de
Cc: netmod@ietf.org; rwilton=40cisco@dmarc.ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Juergen Schoenwaelder  wrote:
> On Mon, Apr 06, 2020 at 08:51:46AM +0200, Radek Krejci wrote:
> > Hi,
> > I just want to emphasis, what are the consequences of the option 1. 
> > This way, the tools are allowed to not accept require-instance in 
> > derived types, so actually schema authors SHOULD NOT use 
> > require-instance this way. Since there is at least 1 YANG model in 
> > RFC (8639 and I would expect more), which has require-instance in 
> > the derive type, errata will be needed in this case(s).
> >
> 
> RFC 7950 says in 9.9.3:
> 
>   If this statement is not present, it defaults to "true".
> 
> This means that require-instance is 'on by default'. Hence, it is 
> necessary to use what RFC 7950 calls a 'restriction' (9.9.1) to 
> effectively _remove_ what seems like a restriction (or constraint).
> (This text apparently has already been in RFC 6020.)

I think the correct fix is to change the text so that "require-instance" is
not classified as a restriction and keep the default.  Also, I think that it
would be easiest (for backwards compatibility w/ existing models) to allow
"require-inetance" to be changed in derived types.

However, this cannot imo be done in an errata.


/martin

> 
> The definition I found in RFC 8639 is this:
> 
> leaf stream {
>   type stream-ref {
> require-instance false;
>   }
>   mandatory true;
>   description
> "Indicates the event stream to be considered for
>  this subscription.";
> }
> 
> This could be changed to:
> 
> leaf stream {
>   type leafref {
>   path "/sn:streams/sn:stream/sn:name";
> require-instance false;
>   }
>   mandatory true;
>   description
> "Indicates the event stream to be considered for
>  this subscription.";
> }
> 
> What bothers me here is that I find the design of the default 
> behaviour backwards. If the default would have been
> 
>   If this statement is not present, it defaults to "false".
> 
> then require-instance could be used to add a constraint in derived 
> types but not to remove it (like the other type restrictions).
> 
> If people were to agree that the default here is wrong, can the 
> problem be fixed?  Likely not since changing the default (even in say 
> YANG 2.0) could have drastic consequences and would essentially 
> require to be always explicit about the require-instance property to 
> be on the safe side.
> 
> /js
> 
> > Regards,
> > Radek
> > 
> > 
> > Dne 03. 04. 20 v 18:55 Juergen Schoenwaelder napsal(a):
> > > I propose option 1) and add an issue on yang-next (if not already 
> > > there yet).
> > >
> > > /js
> > >
> > > On Fri, Apr 03, 2020 at 04:24:35PM +, Rob Wilton (rwilton) wrote:
> > >> For the errata, it looks like there are two choices:
> > >>
> > >> 1) We reject this errata, on the grounds that it is unclear on what
the behaviour was expected to be.  It is left unspecified as to whether
require-instance is allowed in a typedef.  We add an issue on the YANG.Next
issue tracker to sort this out in a future revision of YANG.
> > >>
> > >> 2) We agree on what the expected behaviour should be, in which case
it may be possible that this can be "Hold for document update", although it
still seems questionable whether this really fits as an errata.
> > >>
> > >> Regards,
> > >> Rob
> > >>  
> > >>
> > >>> -Original Message-
> > >>> From: netmod  On Behalf Of Ladislav 
> > >>> Lhotka
> > >>> Sent: 03 April 2020 15:52
> > >>> To: netmod@ietf.org
> > >>> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> > >>>
> > >>> On Fri, 2020-04-03 at 14:01 +, Sterne, Jason (Nokia - 
> > >>> CA/Ottawa)
> > >>> wrote:
> >  Hi Martin,
> > 
> >  I believe you that the technical "value space" doesn't change, 
> >  but that leaf would suddenly accept more values than it did before
right?
> >  I'm wondering if we want to follow the "spirit" here, or stick 
> >  with the
> > >>> "value space" argument.
> > >>>
> > >>> I agree with Martin here. Moreover, if such a derived type is 
> > >>> added, it doesn't change 

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