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

[Qin Wu <[e-mail]>]

Hi, Martin:
Thanks for your clarification, however I still feel there are a few points not clear to me.
See follow up comments inline below.

-----邮件原件-----
发件人: Martin Bjorklund [mailto:[e-mail]] 
发送时间: 2019年10月3日 19:31
收件人: Qin Wu <[e-mail]>
抄送: [e-mail]; [e-mail]
主题: Re: [netmod] WG Last Call: draft-ietf-netmod-yang-data-ext version 4

Hi,

Thank you for your reviewe.  Comments inline.

Qin Wu <[e-mail]> wrote:
> Hi, Auhors:
> I have read the latest version and have the following comments:
> 
> 1.  Try to understand the difference between anydata and YANG data 
> structure extension? Is YANG data structure extension targeted to 
> specify the format which can not be represented by anydata?
> 
> When will we use anydata? When will we use YANG data structure 
> extension, would this be clarified in the introduction section.

The Introduction says:

   There is a need for standard mechanisms to allow the definition of
   abstract data that is not intended to be implemented as configuration
   or operational state.

(Also note that 'anydata' doesn't define what goes into the anydata node; a sx:structure has well-defined content)

[Qin]: This is my understanding as well, why not clarify this in the introduction on relation between any data and sx:structure.

> 2.  Why is YANG data structure extension not part of RFC7950 or 
> RFC7950bis? It seems two top level YANG statements are introduced in 
> this draft.

Well, we can't change history and include it in 7950, and there is no 7950bis being worked on.  If/when that happens, this statement can possibly go into that document.  But we don't want to wait for that to happen.

[Qin]:Understand, I think YANG instance file format draft adds dependency to this work. I want to make sure the proposal in this draft is not transition solution, i.e., when we are working on RFC7950bis, 
we have better solution to replace the proposal defined in this draft.

> 3.  In the introduction section, when we say there is no assumption 
> that a YANG data structure can only be used as a top-level 
> abstraction, instead of nested within some other data structure. I am 
> wondering what other data structure looks like? Is other data 
> structure specified by YANG data structure defined in this draft or 
> data structure defined by anydata?

We don't make any assumptions on how this is done.  The new statement simply defines a structure; how it is used is up to the designer.
[Qin]:You may miss my point, what is not clear to me is other data structure? Do we have other data structure before sx:structure is proposed.
If the answer is yes, we should make text clear about this, e.g., add reference to example in A.5.


> If the example is A.5, please add reference to Appendix A.5 in the 
> introduction section.
> 
> 4.  When we say YANG data structure extension is only valid as a 
> top-level statement, does this conflict with YANG data structure can 
> be nested within some other data structure?

No.  This just refers to how the grammar is done - sx:structure can only appear on the top-level in a module or submodule.

> 5.  Why augment-structure is also only valid as a top-level statement, 
> why augment-structure is not substatement of YANG data structure?

I don't think augment-structure would make any sense within a structure statement.
[Qin]: Thanks for your clarification, I just remember someone proposed something else that will go to YANG Next.
I want to make sure we will have no alternative solution for this.
> Can
> we use augment-structure with other data structure instead of YANG 
> data structure defined in this document?

No, note how the description of augment-structure says:

  This extension is used to specify an augmentation to YANG data
  structure defined with the 'structure' statement.


> 6.  In A.5, how error-code is hooked into rpc-error?

Only by text; there is no formal way to do this:

   The following example defines a data structure with error
   information, that can be included in an <error-info> element in an
   <rpc-error>.

Also note that this is just an example...

[Qin]:I am not sure the name statement is sufficient without path statement as argument in sx:structure,
How do I know error-node is one additional leaf within rpc-error.
Or the answer is the module which define error-node doesn't care the what rpc-error data structure look like?
If the latter is true, I would like to suggest to make semantics clear in sx:structure definition.

> Why not use
> augment-structure in this case?

There is no sx:structure to augment.

[Qin]: See above, I think augment-structure provides path statement as argument which help understand the relationship with parent module.


/martin


> Describe path statement to indicate
> the relationship with rpc error?
> 
> -Qin
> 
> 
> 发件人: netmod [mailto:[e-mail]] 代表 Joel Jaeggli
> 发送时间: 2019年9月27日 13:32
> 收件人: NETMOD Working Group <[e-mail]>
> 主题: [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-netmo
> d-yang-data-ext-04.txt
> 
> Thanks
> Joel
>