Re: [Netconf] Last Call: <draft-ietf-netconf-rfc7895bis-06.txt> (YANG Library) to Proposed Standard

Lou Berger <lberger@labn.net> Thu, 02 August 2018 13:21 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 E4A8B130E39 for <netconf@ietfa.amsl.com>; Thu, 2 Aug 2018 06:21:20 -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 cWC4saTQYbHr for <netconf@ietfa.amsl.com>; Thu, 2 Aug 2018 06:21:18 -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 574A0129AB8 for <netconf@ietf.org>; Thu, 2 Aug 2018 06:21:18 -0700 (PDT)
Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id E8BF421833D for <netconf@ietf.org>; Thu, 2 Aug 2018 07:12:58 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id lDPWfOYQGj0solDPWfnO6I; Thu, 02 Aug 2018 07:12:58 -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:To:Subject:Sender:Reply-To:Cc: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=wTPM2evHZnmUQhEF+ZWYJceGnxBZa9/ZGkOrNCUeEpE=; b=vnHVWS/NglHgd1ij4CquV/Fhnm n4dWp00Iwov3tXw1FFYWHDady5lQL3z30iPUEBicxebXG8AzDXcs8zjP1z4e4M0TwNqGD38gz51e0 YnEQO3BN6Gkquap3+D8Tc2CTd;
Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:55474 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 1flDPW-003tsA-HX; Thu, 02 Aug 2018 07:12:58 -0600
To: Mahesh Jethanandani <mjethanandani@gmail.com>, Ignas Bagdonas <ibagdona@gmail.com>, netconf@ietf.org, draft-ietf-netconf-rfc7895bis@ietf.org, ietf@ietf.org, netconf-chairs@ietf.org
References: <152899335818.26447.7759890925422555917.idtracker@ietfa.amsl.com> <9ad91163-ca97-5db1-1f6d-e365f819db10@labn.net> <5363EB75-95BC-4407-9BFA-3D97EAC440D3@gmail.com> <114e3335-a976-4a84-58e0-8817a06324c1@labn.net> <20180802091348.5j3zpf45nzulszva@anna.jacobs.jacobs-university.de>
From: Lou Berger <lberger@labn.net>
Message-ID: <69b94407-c6cb-b53b-fe9b-e24503ae2f35@labn.net>
Date: Thu, 2 Aug 2018 09:12:53 -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: <20180802091348.5j3zpf45nzulszva@anna.jacobs.jacobs-university.de>
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: 1flDPW-003tsA-HX
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]:55474
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ODrCCPRXZhBuZpUEZPHb8nIi5uE>
Subject: Re: [Netconf] Last Call: <draft-ietf-netconf-rfc7895bis-06.txt> (YANG Library) to Proposed Standard
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: Thu, 02 Aug 2018 13:21:21 -0000

Sorry about the top post, but in writing the response I realized it 
would be good to shift the discussion (and my position) a little.

I think the core of this/my issue is having duplication of requirements, 
i.e.:

in ietf-netconf-rfc7895bis

    Updates: <empty>

    All NETCONF servers supporting YANG 1.1 [RFC7950 <https://tools.ietf.org/html/rfc7950>] are required to
    support YANG Library (seeSection 5.6.4 of RFC 7950 
<https://tools.ietf.org/html/rfc7950#section-5.6.4>).  NETCONF
    servers implementing the NETCONF extensions to support the NMDA
    [I-D.ietf-netconf-nmda-netconf 
<https://tools.ietf.org/html/draft-ietf-netconf-rfc7895bis-06#ref-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 (seeSection 10 of RFC 8040 <https://tools.ietf.org/html/rfc8040#section-10>).  RESTCONF servers implementing the RESTCONF extensions
    to support the NMDA [I-D.ietf-netconf-nmda-restconf 
<https://tools.ietf.org/html/draft-ietf-netconf-rfc7895bis-06#ref-I-D.ietf-netconf-nmda-restconf>] MUST implement
    at least the version of the YANG library defined in this document.


in ietf-netconf-nmda-netconf, related to the first part:

     Updates: 6241, 7950

    This document also updates [RFC7950] in order to enable NETCONF
    clients to both discover which datastores are supported by the
    NETCONF server, as well as determine which modules are supported in
    each datastore.  The update requires NETCONF servers implementing the
    NMDA to support [I-D.ietf-netconf-rfc7895bis].

in ietf-netconf-nmda-restconf, related to the second part of rfc7895bis

     Updates: 8040

    This document updates [RFC8040] in order to enable RESTCONF clients
    to discover which datastores are supported by the RESTCONF server, as
    well as determine which modules are supported in each datastore and,
    finally, to interact with all the datastores supported by the NMDA.
    Specifically, the update introduces new datastore resources, adds a
    new query parameter, and requires the usage of
    [I-D.ietf-netconf-rfc7895bis] by RESTCONF servers implementing the
    NMDA.

So the above is problematic in a few ways.

1.  The same requirement is basically spread across multiple documents, 
one or the other should contain the requirement, not both.

2. The position reflected by the current ietf-netconf-nmda-netconf text 
is that it is the authoritative origination of the 7950 impacting text, 
yet this text uses "require" not "REQUIRES".  So this lead me to the 
conclusion that rfc7895bis is the authoritative source of the update -- 
and my comment.

3. (not previously noted) ietf-netconf-nmda-restconf has basically the 
same comment WRT 8040.  It says its the source of the authoritative 8040 
impacting text yet the conformance language is in is rfc7895bis

I think there are two ways to address this:

a) Keep the conformance language in rfc7895bis and note that it Updates 
7950 *and* 8040.  nmda-netconf and nmda-restconf would also be modified 
to remove the update notation and related text.

b) move the quoted language from rfc7895bis to nmda-netconf and 
nmda-restconf, and leave the updates as is

I think either work. While not what I originally suggested, I think 
option 2 is a bit cleaner as it keeps the protocol related text in a 
protocol document vs in a module definition document.

See below for some specific responses below.

On 8/2/2018 5:13 AM, Juergen Schoenwaelder wrote:
> On Mon, Jul 30, 2018 at 04:19:41PM -0400, Lou Berger wrote:
>
>> All this means is that  draft-ietf-netconf-rfc7895bis should note it updates
>> RFC 7950 in the header and abstract...
> I think there are different interpretations what the Updates: header
> means. And in this case, the "update" is even conditional, i.e., you
> have to implement rfc7895bis if you do implement NMDA - but if you
> don't, then rfc7895 still works just fine.
The point of the updates field is to allow someone implementing a spec 
to know about other specs that impact implementation.  Optional or 
otherwise.  It lets the implementor make an informed choice without 
knowing the whole history or context of an RFC's writing.  I think the 
update notation belongs with the conformance language that impacts the 
implementation is in this document this is where the updates belong -- 
wherever that ends up.

FWIW Getting these update/obsolete fields wrong really hurts those new 
to the technology.

>> Your read of the update to RFC7950 is that it should now reference
>> rfc7895bis in Section 5.6.4. Is that correct? How is that different
>> from 7895bis obsoleting 7895, and thus all references to 7895 should
>> now be to 7895bis?
> It is conditional to the implementation of NMDA.

I don't follow you here. but I suspect it's covered by my top post.

Lou
> /js
>