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

Martin Bjorklund <mbj@tail-f.com> Tue, 07 August 2018 10:06 UTC

Return-Path: <mbj@tail-f.com>
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 3664C126F72; Tue, 7 Aug 2018 03:06:41 -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_PASS=-0.001, 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 dOBCBZMFKrUV; Tue, 7 Aug 2018 03:06:38 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B360B130DC8; Tue, 7 Aug 2018 03:06:38 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 9665C1AE0144; Tue, 7 Aug 2018 12:06:36 +0200 (CEST)
Date: Tue, 07 Aug 2018 12:06:35 +0200
Message-Id: <20180807.120635.1075983444617909744.mbj@tail-f.com>
To: lberger@labn.net
Cc: mjethanandani@gmail.com, ibagdona@gmail.com, netconf@ietf.org, draft-ietf-netconf-rfc7895bis@ietf.org, ietf@ietf.org, netconf-chairs@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <69b94407-c6cb-b53b-fe9b-e24503ae2f35@labn.net>
References: <114e3335-a976-4a84-58e0-8817a06324c1@labn.net> <20180802091348.5j3zpf45nzulszva@anna.jacobs.jacobs-university.de> <69b94407-c6cb-b53b-fe9b-e24503ae2f35@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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Hd0UyWfKx4qVv4a4xCn_IYiiUqo>
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: Tue, 07 Aug 2018 10:06:41 -0000

Hi Lou,

Lou Berger <lberger@labn.net> wrote:
> 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.

I fully agree.


> 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 prefer this option, since I think that this was actually the
intention; i.e., the conformance language for NETCONF and RESTCONF
should not be in the generic YANG library document, but in the
protocol docs.

Specifically, I suggest we remove the paragraph below from 7895bis:

   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.


As for your comment (2) above, note that
draft-ietf-netconf-nmda-netconf says:

   An NMDA-compliant NETCONF server MUST support the operational state
   datastore and it MUST implement at least revision 201X-XX-XX of the
   "ietf-yang-library" module defined in [I-D.ietf-netconf-rfc7895bis].

So this document already has the conformance language.

(ditto for draft-ietf-netconf-nmda-restconf).


/martin


> 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
> >
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf