Re: [netmod] Genart last call review of draft-ietf-netmod-schema-mount-10

Martin Bjorklund <mbj@tail-f.com> Fri, 29 June 2018 09:53 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 7640A1277D2; Fri, 29 Jun 2018 02:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 sgWaa_hZ8cES; Fri, 29 Jun 2018 02:53:29 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6FF130E67; Fri, 29 Jun 2018 02:53:29 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id ABC971AE02F0; Fri, 29 Jun 2018 11:53:26 +0200 (CEST)
Date: Fri, 29 Jun 2018 11:53:26 +0200
Message-Id: <20180629.115326.1242806364236917144.mbj@tail-f.com>
To: jmh@joelhalpern.com
Cc: gen-art@ietf.org, netmod@ietf.org, ietf@ietf.org, draft-ietf-netmod-schema-mount.all@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <153021337301.18655.5723836004030560167@ietfa.amsl.com>
References: <153021337301.18655.5723836004030560167@ietfa.amsl.com>
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/8vCisKULOmkga7v34bwZQNooWPM>
Subject: Re: [netmod] Genart last call review of draft-ietf-netmod-schema-mount-10
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 29 Jun 2018 09:53:43 -0000

Hi,

Thank you for your review!  Comments inline.


Joel Halpern <jmh@joelhalpern.com> wrote:
> Reviewer: Joel Halpern
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-netmod-schema-mount-10
> Reviewer: Joel Halpern
> Review Date: 2018-06-28
> IETF LC End Date: 2018-06-29
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This document is almost ready for publication as a Proposed Standards.
>     I believe that the working group has gotten too close to the work, and
>     failed to notice that important explanations that they understand do not
>     actually appear in the document.
> 
> Major issues:
>      There is no explanation in the document as to who controls mounting and
>      how it is specified.  From this, I infer that the intention is that the
>      server knows what is to be mounted at specific mount points, and does so. 
>       The Client does not tell the server to mount specific schemas in specific
>      places.  Ok.  Say so.  And explain that the server knows this by means
>      external to the YANG modules.  The text explicitly states that the case
>      where the mount point definition selects the data model to be mounted is
>      NOT supported by this document.

The document has the following text, which was supposed to cover this
case:

   Schema mount applies to the data model, and specifically does not
   assume anything about the source of instance data for the mounted
   schemas.  It may be implemented using the same instrumentation as the
   rest of the system, or it may be implemented by querying some other
   system.  Future specifications may define mechanisms to control or
   monitor the implementation of specific mount points.

But howabout we add a new paragraph after this:

   How and when specific mount points are instantiated by the server
   is out of scope for this document.  Such mechanisms may be defined
   in future specifications.

>     There is some ambiguity, quite possibly only in this reader, as to what a
>     client finds when it does a NETCONF Get at or below the mount point.  I had
>     assumed originally that it would find structure defined by the schema that
>     is mounted there, as defined by the schema-mount container.

This is correct.

>     However, the
>     Schema-mount definition itself states that what is found at the mount point
>     is an instance of YANG library.

Hmm, do you mean the text in the YANG module:

               "This node indicates that the server has mounted
                'ietf-yang-library' at the mount point, and its
                instantiation provides the information about the mounted
                schema.

If so, maybe we can clarify by saying

               "This node indicates that the server has mounted
                at least the module 'ietf-yang-library' at the mount
                point, and its
                instantiation provides the information about the mounted
                schema.


> Given that this lefft me completely
>     confused, please add some explanatory text?
> 
> Minor issues:
>     N/A
> 
> Nits/editorial comments:
>     The introduction, in its third paragraph refers to the "source or target
>     YANG module" seeming to use both the term source and the term target to
>     refer to the module with the uses or augments statement.  Even if other
>     YANG documents use both terms, this is a confusing construction.

How about:

OLD:

   With both mechanisms, the source or target YANG module explicitly
   defines the exact location in the schema tree where the new nodes are
   placed.

NEW:

   With both mechanisms, the YANG module with the "uses" or "augemnt"
   statement explicitly defines the exact location in the schema tree
   where the new nodes are placed.


/martin