Re: [Netconf] RtgDir review: draft-ietf-netconf-nmda-netconf-06

Lou Berger <lberger@labn.net> Mon, 30 July 2018 19:42 UTC

Return-Path: <lberger@labn.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F37713116D for <netconf@ietfa.amsl.com>; Mon, 30 Jul 2018 12:42:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 pKkpx483VpOx for <netconf@ietfa.amsl.com>; Mon, 30 Jul 2018 12:42:34 -0700 (PDT)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E1C13117F for <netconf@ietf.org>; Mon, 30 Jul 2018 12:42:34 -0700 (PDT)
Received: from cmgw14.unifiedlayer.com (unknown [10.9.0.14]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 9E9F1216569 for <netconf@ietf.org>; Mon, 30 Jul 2018 13:13:53 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id kDc9fALbzvdTukDc9fJC4N; Mon, 30 Jul 2018 13:13:53 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=+NzPCq2MqKv14z1gbc60WpeQfoXvnvR5w4tQgWkDi8s=; b=CbgxuEQDeiOIjvDlbPAzd1SFjR IMgYxh45nZtUGv2Kl16cqWVmDn1wXA9zPzg70Lfx5JibOn5/cWGrnsO3NEVuBeO2T3iTqx4EnMTZy Gg0RfWHy7fPTr/W6lMlKAxI+3;
Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:48152 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <lberger@labn.net>) id 1fkDc9-0045kK-85; Mon, 30 Jul 2018 13:13:53 -0600
To: Kent Watsen <kwatsen@juniper.net>, "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>
Cc: "draft-ietf-netconf-nmda-netconf.all@ietf.org" <draft-ietf-netconf-nmda-netconf.all@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, NetConf WG <netconf@ietf.org>
References: <7872c72c-cb9a-efcd-578b-fca5beb8ffd6@labn.net> <97D5F408-3318-4843-B14C-B9C38DB8B218@juniper.net>
From: Lou Berger <lberger@labn.net>
Message-ID: <627d816b-9469-0e60-4627-335fc2f53782@labn.net>
Date: Mon, 30 Jul 2018 15:13:52 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <97D5F408-3318-4843-B14C-B9C38DB8B218@juniper.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.106.211
X-Source-L: No
X-Exim-ID: 1fkDc9-0045kK-85
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:48152
X-Source-Auth: lberger@labn.net
X-Email-Count: 5
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Uxu4sPPVgPb6UVLdRfwQZ0yE7HI>
Subject: Re: [Netconf] RtgDir review: draft-ietf-netconf-nmda-netconf-06
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jul 2018 19:42:44 -0000

Hi Kent,

Thanks for the quick response.  I think there's just one open point left 
after your response...


On 7/30/2018 2:44 PM, Kent Watsen wrote:
> Hi Lou,
>
> Thanks for your review!
>
>> Summary:
>>
>> I have some minor concerns about this document that I think should be
>> resolved before publication.
>>
>> Comments:
>>
>> The document is is generally well written and easy to read.  There are
>> several places where I'm sure the authors know exactly what they intend,
>> but the text could be revised to help along those less familiar with the
>> work.  There is also one miss-marked RFC Update reference.
> Just to be sure, all these issues are discussed below, right?
>
Yes, the ones I felt really needed to be addressed are listed.

>> Major Issues:
>>
>> <none>
>>
>> Minor Issues:
>>
>> - Cover/Abstract
>>     Updates: 7950
>>
>>     The update to
>>     RFC 7950 requires the usage of I-D.ietf-netconf-rfc7895bis by NETCONF
>>     servers implementing the Network Management Datastore Architecture.
>>
>> If I read this and the referenced document correctly, this is saying
>> that I-D.ietf-netconf-rfc7895bis updates which version of YANG library
>> is supported by implementations RFC7950 that support NMDA.  If this is
>> the correct reading, this document doesn't update RFC7950, but rather
>> I-D.ietf-netconf-rfc7895bis updates 7950. (this omission was noted in a
>> separate message.)
> The last paragraph in Section 2 says this:
>
>     This document updates [RFC7950], Section 5.6.4, to allow servers to
>     advertise the capability :yang-library:1.1 instead of :yang-
>     library:1.0, and to implement the subtree "/yang-library"
>     [I-D.ietf-netconf-rfc7895bis] instead of "/modules-state".
>
> Note that RFC 7950, Section 5.6.4 says:
>
>     A NETCONF server MUST announce the modules it implements (see
>     Section 5.6.5) by implementing the YANG module "ietf-yang-library"
>     defined in [RFC7895] and listing all implemented modules in the
>     "/modules-state/module" list.
>
> Which is what this document changes.
well doesn't I-D.ietf-netconf-rfc7895bis already say this and as the 
document that has the actual modification, it seems that that is the 
right document to list the 'update'  and this document need only 
reference I-D.ietf-netconf-rfc7895bis without any duplication of 
requirements.
Note that I-D.ietf-netconf-rfc7895bis says:

    All NETCONF servers supporting YANG 1.1 [RFC7950] are required to
    support YANG Library (see Section 5.6.4 of RFC 7950).  NETCONF
    servers implementing the NETCONF extensions to support the NMDA
    [I-D.ietf-netconf-nmda-netconf] MUST implement at least the version
    of the YANG library defined in this document.  Similarly, all
    RESTCONF servers are required to support YANG Library (see Section 10
    of RFC 8040).  RESTCONF servers implementing the RESTCONF extensions
    to support the NMDA [I-D.ietf-netconf-nmda-restconf] MUST implement
    at least the version of the YANG library defined in this document.

isn't that sufficient?

>
>> - section 3.1.1.
>>
>>     The "config-filter" parameter can be used to retrieve only "config
>>     true" or "config false" nodes.
>>
>>     also
>>           leaf config-filter {
>>             type boolean;
>>             description
>>               "Filter for nodes with the given value for their
>>                'config' property.";
>>           }
>>
>> So this means:
>>      absent = provide all
>>      true = provide only true
>>      false = provide only false
>>
>> Right? Either way, I think this could be clarified a bit.  At least say
>> what behavior is expected when the leaf is omitted.
> OLD:
>               "Filter for nodes with the given value for their
>                'config' property.";
> NEW:
>               "Filter for nodes with the given value for their
>                'config' property.  For example, when set to
>                'true', only 'config true' nodes are returned.
>                When unset, all nodes are returned.";
>
> Okay?
Yes. Thanks.

>
>> Nits:
>>
>> - the orders of sections 3.1.1.1. and 3.1.1.2. should be reversed to
>> match the module ordering.
> ...or change the order in the module, which I think might be preferred.
>
WFM - I didn't want to suggest a technical change to address an 
editorial comment.

>> - Section 3.1.2:
>>
>>      The "default-operation" parameter is a copy of the
>>      "default-operation" parameter of the <edit-config> operation.
>>
>>      The "edit-content" choice mirrors the "edit-content" choice of the
>>      <edit-config> operation.  Note, however, that the "config" element in
>>      the "edit-content" choice of <edit-data> uses "anydata" (introduced
>>      in YANG 1.1) while the "config" element in the "edit-content" choice
>>      of <edit-config> used "anyxml".
>>
>> It's fine to say that these nodes mirror <edit-config> nodes, but this
>> document should at least summarize the function of each, e.g.,
>>       The "default-operation" parameter selects the default operation
>>       for this request. It is a copy....
> NEW
>       The "default-operation" parameter selects the default operation to
>       use.  It is a copy of the "default-operation" parameter of the
>       <edit-config> operation.
>
>       The "edit-content" parameter specifies the content for the edit
>       operation.  It mirrors the "edit-content" choice of the
>       <edit-config> operation.  Note, however, that the "config" element in
>       the "edit-content" choice of <edit-data> uses "anydata" (introduced
>       in YANG 1.1) while the "config" element in the "edit-content" choice
>       of <edit-config> used "anyxml".
>
>
> Okay?
Yes.

Thanks!
Lou

>
> Thanks,
> Kent // co-author
>
>
>
>