Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-yang-data-ext version 4

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 1 Oct 2019 15:01:04 +0000

Hi,

I've reviewed this document, and other than 2 minor nits, I believe that it is ready for publication.

Two minor comments:

  1.  Section 1.1.1 NMDA.  There should be a comma before "and are not redefined here".
  2.  I wonder whether it would be useful to have a sentence in the "Definitions" section that defines how a structure is encoded.  Although I appreciate that this is specified in the YANG module itself.  An alternative could be a forward reference from the Definitions section to the YANG module.  This could also cover the Xpath behaviour as well.

Thanks,
Rob

From: netmod <[email-masked]> On Behalf Of Joel Jaeggli
Sent: 27 September 2019 06:32
To: NETMOD Working Group <[email-masked]>
Subject: [netmod] WG Last Call: draft-ietf-netmod-yang-data-ext version 4

All,

This starts a two week working group last call for  draft-ietf-netmod-yang-data-ext-04

The working group last call ends on  Friday October 11th 2019.  Please send your comments to the working group mailing list.

Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome!  This is useful and important, even from authors.

https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-04

The diff from 03, produced prior to IETF 105 is available here:

https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-netmod-yang-data-ext-04.txt

Thanks
Joel

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 03 Oct 2019 13:15:52 +0200 (CEST)

Hi,

Thank you for the review.  Comments inline.

>   1.  Section 1.1.1 NMDA.  There should be a comma before "and are

Fixed.

>   2.  I wonder whether it would be useful to have a sentence in the
>   "Definitions" section that defines how a structure is encoded.
>   Although I appreciate that this is specified in the YANG module
>   itself.  An alternative could be a forward reference from the
>   Definitions section to the YANG module.  This could also cover the
>   Xpath behaviour as well.

This is probably a good idea.  Perhaps also add a small example:

   A YANG data structure is encoded in the same way as an "anydata"
   node.  This means that the name of the structure is encoded as a
   "container", with the instantiated children encoded as child nodes to
   this node.  For example, this structure:

     module example-errors {
       ...

       sx:structure my-error {
         leaf error-number {
           type int;
         }
       }
     }

   can be encoded in JSON as:

     "example-module:my-error": {
       "error-number": 131
     }

/martin

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 3 Oct 2019 11:57:05 +0000

Looks good to me.

Thanks,
Rob

> -----Original Message-----
> From: Martin Bjorklund <[email-masked]>
> Sent: 03 October 2019 12:16
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-yang-data-ext
> version 4
> 
> Hi,
> 
> > The working group last call ends on  Friday October 11th 2019.  Please
> send your comments to the working group mailing list.
> >
> > Positive comments, e.g., "I've reviewed this document and believe it is
> ready for publication", are welcome!  This is useful and important, even
> from authors.
> >
> >

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 12 Oct 2019 12:07:57 -0700

This concludes the netmod WG last call for 

draft-ietf-netmod-yang-data-ext version 4...

There was a modest amount of commentary generally positive, during the last call period with some requests for clarification (Qin wu) and some minor nits (Robert Wilton). 

It might be good to have closure on the last email in that cycle.

https://mailarchive.ietf.org/arch/msg/netmod/QRWFS4fnd-jJ8Ajhxpr3pG0nuvY <https://mailarchive.ietf.org/arch/msg/netmod/QRWFS4fnd-jJ8Ajhxpr3pG0nuvY>

but it looks like the document is ready to advance based on this and prior wg discussion.

Thanks
Joel

> On Sep 26, 2019, at 22:32, Joel Jaeggli <[email-masked]> wrote:
> 
> All,
> 
> https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-04 <https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-04>
> 
> https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-netmod-yang-data-ext-04.txt <https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-netmod-yang-data-ext-04.txt>
> 
> Thanks
> Joel
>

---

From: Andy Bierman <[email-masked]>
Date: Sun, 13 Oct 2019 08:28:10 -0700

On Sat, Oct 12, 2019 at 12:08 PM Joel Jaeggli <[email-masked]> wrote:

> There was a modest amount of commentary generally positive, during the
> last call period with some requests for clarification (Qin wu) and some
> minor nits (Robert Wilton).
>
> https://mailarchive.ietf.org/arch/msg/netmod/QRWFS4fnd-jJ8Ajhxpr3pG0nuvY
>
>

It is not clear which issues remain open from this review.
The main issues seem to be:

   1) Put this functionality in yang-next instead of this document
    * The WG decided several times to go forward with this document

   2) When there is a yang-next, these extensions will not change or go away
    * This issue was not discussed as part of this draft. The WG should make
       these decisions if and when yang-next is a work item

   3) There needs to be machine-readable statements to define where a
structure can be used
    * The WG decided to just use description-stmt for this purpose

I do not know if this list is complete or correct.
That is for the WG Chairs to decide.

The 'structure' extension is basically a copy of container-stmt with some
stuff removed.
It is not a data node, rpc, or notification. Its use is
implementation-dependent.
A container-stmt is tightly coupled to protocols and datastores.  A
structure is
not coupled to anything.  There can be notifications and actions defined
nested within
a structure's data-def-stmts. (Who knows what this means - it is
implementation-specific.)

but it looks like the document is ready to advance based on this and prior
> wg discussion.

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 13 Oct 2019 08:32:53 -0700

> On Oct 13, 2019, at 08:28, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Sat, Oct 12, 2019 at 12:08 PM Joel Jaeggli <[email-masked] <mailto:[email-masked]>> wrote:
>    3) There needs to be machine-readable statements to define where a structure can be used

That sounds like closure to me.

Thank you.

> The 'structure' extension is basically a copy of container-stmt with some stuff removed.
> It is not a data node, rpc, or notification. Its use is implementation-dependent.
> A container-stmt is tightly coupled to protocols and datastores.  A structure is
> not coupled to anything.  There can be notifications and actions defined nested within
> a structure's data-def-stmts. (Who knows what this means - it is implementation-specific.)
> 
> 
> 
>> On Sep 26, 2019, at 22:32, Joel Jaeggli <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> All,
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>