Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07

Robert Wilton <rwilton@cisco.com> Thu, 02 November 2017 17:07 UTC

Return-Path: <rwilton@cisco.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 081E213F7A2 for <netmod@ietfa.amsl.com>; Thu, 2 Nov 2017 10:07:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 t0ATbi0mdRgG for <netmod@ietfa.amsl.com>; Thu, 2 Nov 2017 10:06:57 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DF3D13F7AE for <netmod@ietf.org>; Thu, 2 Nov 2017 10:06:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3530; q=dns/txt; s=iport; t=1509642417; x=1510852017; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=/kJZR3iJbHVbXopdyS+cUWh1pbDi4WbiCO3DvH0vOK4=; b=A3Xbdr07LEskCdq+o7bNDtK16fA4LwnQZrGWHkXet3vc90GkYZokio0/ /ufyG/zFOlUS5E0Stt2Yej7L/ZH3EYKcAJnwrrzfGkIQ0FhiBIFBnN3cH 7etObIdMYtwbSgNpo5EnPKT1E6zpg27RNEZVTuGXf9SXY9tZKScABHNYm 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0COAABrUPtZ/xbLJq1cGQEBAQEBAQEBAQEBBwEBAQEBhBhuJ4N9ih90kCKWRRCCAQoYC4RJTwKFDxgBAQEBAQEBAQFrKIUeAQEEAQEhDwEFNgsQCxgCAiYCAicwBgEMBgIBAYofEKkZgieLEwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+CH4NagWkpgwGEXgESAQmDK4JiBZFekC+UfIIVhgODYCSHFo4ph22BOR84QkFpNCEIHRVJgmSEX0E2iw6CNQEBAQ
X-IronPort-AV: E=Sophos;i="5.44,335,1505779200"; d="scan'208";a="17740"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2017 17:06:34 +0000
Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vA2H6YuV009780; Thu, 2 Nov 2017 17:06:34 GMT
To: "netmod@ietf.org" <netmod@ietf.org>, Martin Bjorklund <mbj@tail-f.com>, Ladislav Lhotka <lhotka@nic.cz>
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <68c6a4d5-fd3e-efdb-9c34-f69f241d6a31@cisco.com>
Date: Thu, 02 Nov 2017 17:06:34 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/TJr6ymVYx8M-KgCJBOo9-JEbmHg>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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, 02 Nov 2017 17:07:03 -0000

Hi,

I have read this document and think that is almost ready for publication.

I have one general comment regarding the YANG module library (at the 
end), and a few nits, but otherwise the draft looks good.

1. Sec 1. Introduction paragraph 2, "internal node".  It wasn't 
absolutely clear to me what an internal node is, so I wonder whether 
this would be more clear as  "internal (i.e. non root) node".

2. Sec 1. Introduction, page 4, paragraph starting "2. 
Implementation-time ...".  This section states that it is a stable as 
YANG library, and hence cannot change due to a server reboot. However, 
YANG library doesn't appear to have that restriction, and hence this 
doesn't seem to align with RFC 7895, introduction paragraph 2.

3. Sec 2.1 Glossary of New Terms:  "Schema" isn't actually defined 
anywhere (RFC 7950 doesn't define this).  Should it be defined here?  
The NMDA datastores draft had a similar issue and we choose to define 
"datastore schema" instead.

4. Sec 3.2. paragraph 1.  Same comment as 2 above also applies here.  
The text "same management session" might be more clear as "same client 
management protocol session".

5. Sec 3.2. paragraph 2, last sentence: "are possible and such needs" => 
"are possible, and as such, needs"

6. Sec 3.2 paragraph 5.  Would it useful to state that even though the 
schema is the same, the data is different and not necessarily related.

7. Sec 3.3 last paragraph.  "On the other hand, " => "In addition, "

8.  Sec 6 Implementation Notes.  Would this section be better named 
"Implementation Considerations"?

9. Structure of ietf-yang-schema-mount module:
   - Should "uri" under namespace be marked as "mandatory" so that it 
doesn't appear to be optional in the tree diagram.
   - Should the "module" name be included under the namespace.  It seems 
that lots of other "module bindings" are done via the module name rather 
than the namespace?

10. Example A.3.  This contains some features that are enabled. Possibly 
it would be useful in the description to point this out, and state that 
unless the features are listed they wouldn't be enabled.

My last general comment relates generally to the structure of the 
Iietf-yang-schema-mount.  As Lada has pointed out previously, this 
module and YANG library bis could be more closely aligned (e.g. along 
the lines of reusing module-sets for the "schema" list).  It would have 
been nice if this module could augment YANG library (so that you can 
easily get the modules and schema mount information in a single simple 
request), however that would put an undesired dependency delaying 
publishing this draft until YANG library bis is completed.

Thanks,
Rob


On 20/10/2017 22:37, Kent Watsen wrote:
> All,
>
> This starts a two-week working group last call on
> draft-ietf-netmod-schema-mount-07.
>
> The working group last call ends on November 3.
> Please send your comments to the netmod 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.
>
> Could the authors, explicitly CC-ed on this email,
> please also confirm one more time that they are
> unaware of any IPR related to this draft.
>
> Thank you,
> Netmod Chairs
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>