Re: [netmod] Comments on draft-ietf-netmod-schema-mount-09

Martin Bjorklund <mbj@tail-f.com> Tue, 03 April 2018 10:57 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 85E9012E89A for <netmod@ietfa.amsl.com>; Tue, 3 Apr 2018 03:57:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 yXCg1vXXwVnA for <netmod@ietfa.amsl.com>; Tue, 3 Apr 2018 03:57:28 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0CD12E899 for <netmod@ietf.org>; Tue, 3 Apr 2018 03:57:28 -0700 (PDT)
Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id AC4371AE0312; Tue, 3 Apr 2018 12:57:26 +0200 (CEST)
Date: Tue, 03 Apr 2018 12:57:25 +0200
Message-Id: <20180403.125725.1554298520008064611.mbj@tail-f.com>
To: otilibil@eurecom.fr
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20180326131751.28bgdvrf8kokc4k4@webmail.eurecom.fr>
References: <20180326131751.28bgdvrf8kokc4k4@webmail.eurecom.fr>
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/4EIkzQbFGcocF1qeiMYLdsaIcHE>
Subject: Re: [netmod] Comments on draft-ietf-netmod-schema-mount-09
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 03 Apr 2018 10:57:30 -0000

Hi,

Thank you for your review.  Comments inline.

otilibil@eurecom.fr wrote:
> Hi members,
> 
> I comment on that draft:
> 
> * Instead of "it is often necessary that an existing module (or a set of modules) is added to the data model starting at a non-root location", this would read better: "it is often necessary that an existing module (or a set of modules) be added to the data model at locations other than the root." (Section 1)

Ok, fixed.

> * 'The "mount-point" statement MUST NOT be used in a YANG version 1 module' Why this documents keeps YANG 1 off from its scope? (Section 3.1)

The reason for this is that otherwise it is not possible to invoke
mounted RPC operations, and receive mounted notifications.  I have
clarified this in the text.

> * 'Specifically, a server that doesn?t support the NMDA, MAY implement revision 2016-06-21 of "ietf-yang-library" [RFC7950] under a mount point' [RFC7895] defines "ietf-yang-library", not [RFC7950] (Section 6)

Fixed.

> * Why not "Tree Diagram" instead of "Data Model"? The wording has become a Best Practice (Section 8)

I don't think I have seen "Tree Diagram" as the title of such a
section.  See e.g. RFC 8344.

> * Idem, "This document...has the following diagram" captures better the Best Practice than "This document...has the following structure" (Section 8)

The full text is:

  This document defines the YANG 1.1 module [RFC7950]
  "ietf-yang-schema-mount", which has the following structure:

it says that the *module* has a structure.

> * Same remark on restricting to YANG 1.1: "The ?mount-point? statement MUST NOT be used in a YANG version 1 module, neither explicitly nor via a ?uses? statement (description of the extension "mount-point")

See above.

> * Should this sentence refers only to [RFC6020]? "This document registers a YANG module in the YANG Module Names registry [RFC6020]" (Section 10)

This is correct.

> * The document cites /schema-mounts as "The schema defined by this state data provides detailed information about a server implementation may help an attacker identify the server capabilities and server implementations with known bugs" I think this section should warn also on:
>    ** Section 2.1.2 and 4 of [RFC7895] (the list 'module' contains the leaf 'schema': from which anyone may retrieve a YANG module)
>    ** Section 3 of [RFC6022] (it defines the RPC 'get-schema'; with which anyone may get a YANG module)
>    ** and Section 5 of [RFC8341] (reminding administrators to set user rights accordingly, and giving their defaults values).

There is an ongoing discussion about adding text re. mounted modules
and how NACM is used to protect them.  I think this needs to be
handled in a generic way, rather than listing some mounted modules.


/martin



> 
> Regards,
> Ariel
> 
> [RFC6020] https://tools.ietf.org/html/rfc6020
> [RFC7895] https://tools.ietf.org/html/rfc7895
> [RFC7950] https://tools.ietf.org/html/rfc7950
> [RFC8341] https://tools.ietf.org/html/rfc8341
> 
> 
> -------------------------------------------------------------------------------
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>