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

I agree with Andy’s conclusion, my comments are mostly questions for clarification.
What is strange to me is I can not open the quoted link any more:
https://mailarchive.ietf.org/arch/msg/netmod/QRWFS4fnd-jJ8Ajhxpr3pG0nuvY

-Qin
发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Joel Jaeggli
发送时间: 2019年10月13日 23:33
收件人: Andy Bierman <andy@yumaworks.com>
抄送: NETMOD Working Group <netmod@ietf.org>
主题: Re: [netmod] Conclusion WG Last Call: draft-ietf-netmod-yang-data-ext version 4

On Oct 13, 2019, at 08:28, Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>> wrote:

On Sat, Oct 12, 2019 at 12:08 PM Joel Jaeggli <joelja@bogus.com<mailto:joelja@bogus.com>> wrote:
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

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 sounds like closure to me.

Thank you.

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.

Thanks
Joel

Andy

On Sep 26, 2019, at 22:32, Joel Jaeggli <joelja@bogus.com<mailto:joelja@bogus.com>> wrote:

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

_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod