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

Andy Bierman <andy@yumaworks.com> Wed, 21 February 2018 04:52 UTC

Return-Path: <andy@yumaworks.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 05B16129C6D for <netmod@ietfa.amsl.com>; Tue, 20 Feb 2018 20:52:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 sBS2GVeyPnpd for <netmod@ietfa.amsl.com>; Tue, 20 Feb 2018 20:52:00 -0800 (PST)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DAE012AF83 for <netmod@ietf.org>; Tue, 20 Feb 2018 20:51:59 -0800 (PST)
Received: by mail-lf0-x234.google.com with SMTP id g72so546526lfg.5 for <netmod@ietf.org>; Tue, 20 Feb 2018 20:51:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=evbYqBCjF2/Zgs3luYdqjQQL+2ww9WhzXmbXoc9vQdI=; b=FniJM8RK3xnbfwIlWpY1ze6a4eOfCWPulqDYWhnN9uERSgvKErRszgi4NZK7JTPQIO u/JIcA3Wn7TwtqGUG2eNDquie8e/1O989s/vFxk/UJ/hhfy30FZBgcefsLjbEUozEGar 06prcxswEk4fkurtb8qjnVg7vBj62WVZwr/Y7SXEDZOKZMXeDb3ReXFVk/2aXwpd7Vub o129VuxfphsRjhAhjgF4t0cp+BrD8Kxzrw+VktxfU+6J7LnmwU5PWCn8spAbJ0DoafI8 ihR1FOX33vnkPg9880ymvMC3n+HEwFm9T4FkAqrEV4Ni9AS0JWz7DRA+qlk1pJHGGsIa HkuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=evbYqBCjF2/Zgs3luYdqjQQL+2ww9WhzXmbXoc9vQdI=; b=PxFLgS8PausizvKnpSTcK2n523YoLBa4mfPu4SkDngYVr3TY7oyf0O1XDbm4+3DVA9 V/XKebOvrRf+K8bI+44cSvIEdYYJ9GQl4yTtO6PnhMcLMCT9SHhQbT4KOoUVMLGlEIo9 QutqUYlSEYpsODVRMaLs/dm34rWC1MH4xHcmnsDIeqEYbWKA8y4VjBivafuCvvqELxYZ 55SMqmNC0WFCi/sEMntxAoz+48fuPDHFvbxlm31iikidNK9+OBoQtFjSyRfiB+oZtfTC 8XY7dB3Gaeh/DibpQtH2ZVFgQhtK7dFMFVL4pevODznSwtZViCk1cvhxmFh5hqjfMwCN AkEQ==
X-Gm-Message-State: APf1xPAMW+Kb0oiD8PWDBa5gA5tWEd24GRrMpFvjcHXXus9pnsJpHQ7w JEFPMvu5yU5V9ZebHg5wWvzDjxjQNe+BxjhpqOT10g==
X-Google-Smtp-Source: AH8x226Z/cHI9eODYYGFeDkrtGhP3hzx9NkXhewKQYjPfE+HrsmgAJdQ3MXccLWn9Ym8+umRRYDwbioCQwCfsxgVjcI=
X-Received: by 10.46.69.85 with SMTP id s82mr1367953lja.6.1519188717656; Tue, 20 Feb 2018 20:51:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.21.210 with HTTP; Tue, 20 Feb 2018 20:51:56 -0800 (PST)
In-Reply-To: <f0ab1c65-dcc0-9460-e8b4-7b4ef5ff0874@cisco.com>
References: <f0ab1c65-dcc0-9460-e8b4-7b4ef5ff0874@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 20 Feb 2018 20:51:56 -0800
Message-ID: <CABCOCHQaMfC-2XyKY_LOYgF9Z4UAxzkkDiV5--BbuuqRaG_7eQ@mail.gmail.com>
To: Benoit Claise <bclaise@cisco.com>
Cc: NETMOD Working Group <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="001a114b0fcedcf0f00565b1af6c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/E6xH6M6V6rcniRxAIGacVTYmwO4>
Subject: Re: [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, 21 Feb 2018 04:52:02 -0000

Hi,

I think draft-18 addresses all these issues.
A guideline about key leaf order has also been added.

Andy


On Wed, Feb 14, 2018 at 7:11 AM, Benoit Claise <bclaise@cisco.com> wrote:

> 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, that RFC 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
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>