Re: [netmod] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-07

Martin Bjorklund <mbj@tail-f.com> Tue, 19 December 2017 20: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 A5CEB12D837; Tue, 19 Dec 2017 12:31:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 X9q84_ow3ATv; Tue, 19 Dec 2017 12:31:02 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DD0EC1277BB; Tue, 19 Dec 2017 12:31:01 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id 257331AE0351; Tue, 19 Dec 2017 21:31:01 +0100 (CET)
Date: Tue, 19 Dec 2017 21:31:01 +0100 (CET)
Message-Id: <20171219.213101.692193824403742919.mbj@tail-f.com>
To: lberger@labn.net
Cc: draft-ietf-netmod-revised-datastores@ietf.org, netmod@ietf.org, netmod-chairs@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <198a88e4-9b8b-945b-09a1-49fa9f57cbb0@labn.net>
References: <80a900b3-716a-b11f-3472-7cae57662ba4@labn.net> <198a88e4-9b8b-945b-09a1-49fa9f57cbb0@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/3awqSZpGCEbtCTBPL17PChRq8sw>
Subject: Re: [netmod] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-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: Tue, 19 Dec 2017 20:31:04 -0000

Hi Lou,

Lou Berger <lberger@labn.net> wrote:
> Hi,
> 	These comments are based on my Shepherd review of this document and
> should be addressed as part of addressing any LC comments:
> 
> 1) Considering the recent discussion on Library made me consider the
> general case of a module that is composed entirely of operational state.
>  I think this case is subject to interpretation and therefore needs to
> be explicitly covered.  For example section 5.3 states:
> 
>    The datastore schema for <operational> MUST be a superset of the
>    combined datastore schema used in all configuration datastores except
>    that YANG nodes supported in a configuration datastore MAY be omitted
>    from <operational> if a server is not able to accurately report them.
> 
> This could be read that a module that an operational state MUST be
> present (but presumably empty>?) in some other DS to be present in
> operational.  I don't believe this is your intent, but it should be
> explicitly covered for the benefit of future readers.

Ok.  How about we add to the paragraph above a sentence:

    If a module does not contain any configuration data then it MAY be
    omitted from the schema for the configuration datastores.

> I suspect that
> this also should translate to an explicit case in section 6.1 as well.

I don't understand why that would be neeed.

> 2) The abstract needs to mention that it updates RFC7950 (per idnits)

Ok.

> 3) A minor point, the document uses the terms boot and reboot.  I
> suspect that these terms are intended to cover any full or partial,
> e.g., protocol, restart operation supported on a system - which may not
> include a full boot.  I think the document needs to be clear on this
> point.  Perhaps just add a definition, or note that full and partial
> restart operations are included when the document refers to boot and reboot.

RFC 6241 uses the same terms, so using them is at least consistent
with that document.  I'm not sure I think they need to be defined in
this document.


/martin




> 
> Thank you,
> Lou
> (As Shepherd)
> 
> On 12/04/2017 09:35 AM, Lou Berger wrote:
> > All,
> > 
> > This starts a second working group last call on
> > draft-ietf-netmod-revised-datastores.
> > 
> > As this is a 2nd LC that is focused on changes since the last LC, it closes in *one* week. The working group last call ends on December 11. Please send your comments to the netmod mailing list.
> > 
> > At this point, we're most interested in verifying that previous comments are addressed since the last call on the -04 rev of the draft was held.
> > 
> > A summary of changes can be found at 
> > https://mailarchive.ietf.org/arch/msg/netmod/DWtD12bGkBZabEygRfiwZfcnUU4
> > 
> > A diff can be found at 
> > https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-netmod-revised-datastores-04.txt&url2=draft-ietf-netmod-revised-datastores-07.txt
> > 
> > Comments along the of: I have reviewed this version of the document and it addresses my previous comments would be particularly helpful.
> > 
> > Thank you,
> > Netmod Chairs
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
>