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

"jmh.direct" <jmh.direct@joelhalpern.com> Fri, 29 June 2018 13:41 UTC

Return-Path: <jmh.direct@joelhalpern.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 F3B45130E91; Fri, 29 Jun 2018 06:41:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 9qvw6leyRU6i; Fri, 29 Jun 2018 06:41:20 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 37FAD130E0E; Fri, 29 Jun 2018 06:41:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1EE932E288F; Fri, 29 Jun 2018 06:41:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1530279680; bh=ZkeseVEo+eAicdK5L69bjP0M1E5/vYUgiXzJlwyKMf4=; h=Date:Subject:In-Reply-To:From:To:Cc:From; b=eDli9HOFsIGCECVrWNNQDyxv1aiuENVzNDeMniDk/KtYHu0z7kKdw9s80APZwfPkm JWtCZ5wXkSRpUwaUzxvo5Q/KZY5e+jwPdc9D7BPmmax4Wkeejpn0b947h1tg1vMgZS 0K4+gfw7KfQnY/6hS1koXKPDtfJcYyltEAUQlQO8=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [172.20.0.26] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 2730A2E2899; Fri, 29 Jun 2018 06:41:18 -0700 (PDT)
SavedFromEmail: jmh.direct@joelhalpern.com
Date: Fri, 29 Jun 2018 09:41:15 -0400
In-Reply-To: <20180629.115326.1242806364236917144.mbj@tail-f.com>
Importance: normal
From: "jmh.direct" <jmh.direct@joelhalpern.com>
To: Martin Bjorklund <mbj@tail-f.com>, jmh@joelhalpern.com
Cc: gen-art@ietf.org, netmod@ietf.org, ietf@ietf.org, draft-ietf-netmod-schema-mount.all@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_7924822475808160"
Message-Id: <20180629134120.37FAD130E0E@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/F6ZR885wLSaIPWH7t8Dyv_rVjzk>
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 13:41:24 -0000

Thank you.  Those changes will do the trick.  I realize they are small.  They fix a lot of confusion.
Yours,Joel
PS:  While I think the absence of information on how the server knows / decides what to mount where is unfortunate, I understand that to be the WG agreement and therefore am not objecting to progressing the document.


Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone
-------- Original message --------From: Martin Bjorklund <mbj@tail-f.com>; Date: 6/29/18  05:53  (GMT-05:00) To: jmh@joelhalpern.com Cc: gen-art@ietf.org, netmod@ietf.org, ietf@ietf.org, draft-ietf-netmod-schema-mount.all@ietf.org Subject: Re: Genart last call review of draft-ietf-netmod-schema-mount-10 
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