[netmod] AD review of draft-ietf-netmod-rfc6087bis Part 2

Benoit Claise <bclaise@cisco.com> Wed, 14 February 2018 15:11 UTC

Return-Path: <bclaise@cisco.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 75827128959 for <netmod@ietfa.amsl.com>; Wed, 14 Feb 2018 07:11:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 HAzBUSSZOjgi for <netmod@ietfa.amsl.com>; Wed, 14 Feb 2018 07:11:22 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7EFA126BFD for <netmod@ietf.org>; Wed, 14 Feb 2018 07:11:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8673; q=dns/txt; s=iport; t=1518621082; x=1519830682; h=from:subject:to:cc:message-id:date:mime-version; bh=+a9gg/Pzzva6hHr4zuALYLJCdMvxq8ddS3A8F5y1FtU=; b=VHb854v3Z6T6VlpZ2zxv4D6L3a8EJ+xxzhA8JdKeHnlVR29ND3dSZKom uk0M6Hl7ME20xWXXRzAKH8RYf2AlA9wTHkmwQVIFJdrg7D13C6kJlRsA5 iZTAF3mewbEHSJ+aOQWrF1UDlIag8/PZMfry+vFtZXVCryno/jQSQYYg4 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DUAQC2UIRa/xbLJq1dGQEBAQEBAQEBAQEBAQcBAQEBAYQ4cCiDZYsYjmqBPpBnhXCCAwojhRiDURUBAgEBAQEBAQJrKIVNTwddAl8NCAEBijEQryeCJyaEW4N8ghMBAQEBAQUBAQEBAQEdBYUCg2yBaCkMhigBAQIBgTYFARIBCYMtgmUFkk6RYQmIII1lgh+GKoNzJodjjgKBfogZgTw1I2BwMxoIGxUZgmuEd0A3AQGLJoI+AQEB
X-IronPort-AV: E=Sophos;i="5.46,512,1511827200"; d="scan'208,217";a="2070402"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2018 15:11:19 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w1EFBJLK005450; Wed, 14 Feb 2018 15:11:19 GMT
From: Benoit Claise <bclaise@cisco.com>
To: NETMOD Working Group <netmod@ietf.org>
Message-ID: <f0ab1c65-dcc0-9460-e8b4-7b4ef5ff0874@cisco.com>
Date: Wed, 14 Feb 2018 16:11:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------EFE58642229F355B38A8B34E"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/G_OQtgW7g2V3fgL48lgPcA8pHnQ>
Subject: [netmod] AD review of draft-ietf-netmod-rfc6087bis Part 2
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: Wed, 14 Feb 2018 15:11:24 -0000

Dear all,

Here is the part 2 of the AD review, from section 4.21 on.

Regarding the part 1, thanks Andy for addressing all comments in version 17.

- section 4.22 "Data Correlation.

Not sure what you mean by the section title and "Data can be correlated in various ways"?
Which data? YANG modules, YANG objects, object instances, from different YANG server, etc.
I guess I miss a sentence or two regarding this "correlation" objective and which guidelines this section
is going to provide to "authors and reviewers of Standards Track specifications containing YANG data model modules".
Note: I read that section multiple times.

- section 4.22
    It is sometimes useful to separate configuration data and operational
    state, so that they do not not even share the exact same naming
    characteristics.  The correlation between configuration the
    operational state that is affected by changes in configuration is a
    complex problem.  There may not be a simple 1:1 relationship between
    a configuration data node and an operational state node.  Further
    work is needed in YANG to clarify this relationship.  Protocol work
    may also be needed to allow a client to retrieve this type of
    information from a server.  At this time the best practice is to
    clearly document any relationship to other data structures in the
    "description" statement.

Isn't it clarified with NMDA. It's not inline with 4.23.2, which says:
	
    Designers SHOULD describe and justify any NMDA exceptions in detail,
    such as the use of separate subtrees and/or separate leafs.

... and I guess confusing in light of the real guidelines in 4.23.3
Btw, why is this paragraph in 4.22 and not in 4.23?

- section 4.23

	Operational state is now modeled using YANG according to new NMDA,

Please add a reference to the draft.

- section 4.26 "YANG 1.1 Guidelines"
I'm confused by the title. The entire document is about 1.1, right?
I guess you want to express something such as "YANG 1.1 specific Constructs Guidelines"

- section 4.26.1

      Multiple revisions of the same module can be imported, provided that
      different prefixes are used.

Reading https://tools.ietf.org/html/rfc7950#section-7.1.5. Any contradiction?
Then reading:
    This MAY be done if the authors can
    demonstrate that the "avoided" definitions from the most recent of
    the multiple revisions are somehow broken or harmful to
    interoperability.

"avoided" definitions?
I simply don't understand this sentence.

- section 4.26.4
    The NETCONF Access Control Model (NACM) [RFC6536 <https://tools.ietf.org/html/rfc6536>] does not support
    parameter access control for RPC operations.

Let's use draft-ietf-netconf-rfc6536bis


- Appendix B

    YANG Module Registry: Register the YANG module name, prefix,
          namespace, and RFC number, according to the rules specified
          in [RFC7950 <https://tools.ietf.org/html/rfc7950>].

I guess this is [RFC6020] in this case. Indeed the "YANG Module Names" registry is specified in RFC6020/.
See for example https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-6

- Appendix B
References -- verify that the references are properly divided
       between normative and informative references, thatRFC 2119 <https://tools.ietf.org/html/rfc2119>  is
       included as a normative reference if the terminology defined
       therein is used in the document

Refer to RFC8174

- Appendix B (and maybe some more text somewhere else.
To refer to Tom Petch latest email to NETMOD, we should need a few words about:
   If a YANG module has a Reference or Description clause specifying an
   I-D, and the I-D is listed as an Informative Reference.

Regards, Benoit