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

Martin Bjorklund <mbj@tail-f.com> Thu, 03 October 2019 11:31 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968A3120232 for <netmod@ietfa.amsl.com>; Thu, 3 Oct 2019 04:31:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbVCmxdAjQJx for <netmod@ietfa.amsl.com>; Thu, 3 Oct 2019 04:31:45 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 79D9D120120 for <netmod@ietf.org>; Thu, 3 Oct 2019 04:31:45 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 66F991AE018A; Thu, 3 Oct 2019 13:31:43 +0200 (CEST)
Date: Thu, 03 Oct 2019 13:31:18 +0200 (CEST)
Message-Id: <20191003.133118.1370359961477127550.mbj@tail-f.com>
To: bill.wu@huawei.com
Cc: joelja@bogus.com, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAA933E610@dggeml511-mbx.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABAA933E610@dggeml511-mbx.china.huawei.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/KhXYpcHjn9b6jcmOdkckOa_DNo0>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-yang-data-ext version 4
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Oct 2019 11:31:57 -0000

Hi,

Thank you for your reviewe.  Comments inline.

Qin Wu <bill.wu@huawei.com>; 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)

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

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

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

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

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

There is no sx:structure to augment.




/martin


> Describe path statement to indicate
> the relationship with rpc error?
> 
> -Qin
> 
> 
> 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Joel Jaeggli
> 发送时间: 2019年9月27日 13:32
> 收件人: NETMOD Working Group <netmod@ietf.org>;
> 主题: [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
>