Re: [netmod] upcoming adoptions

Andy Bierman <andy@yumaworks.com> Fri, 08 September 2017 17:00 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 957D2132D51 for <netmod@ietfa.amsl.com>; Fri, 8 Sep 2017 10:00:19 -0700 (PDT)
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 yKGv5f0tNTHs for <netmod@ietfa.amsl.com>; Fri, 8 Sep 2017 10:00:17 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 BBDF3132710 for <netmod@ietf.org>; Fri, 8 Sep 2017 10:00:17 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id j141so6934130ioj.4 for <netmod@ietf.org>; Fri, 08 Sep 2017 10:00:17 -0700 (PDT)
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=KwPxhciKv9SrW+udXcevl8HbCFekDvF0yywvwv+QpZU=; b=BAUQOlohCwAtnL3KcjaeVGFVFbQCltRYYWJGK9W9l2WymjQtlS2ugj8ZeHcPhm/4nL mmA9Aa3EC9otdt6t/usv9qTzbqaYSTbi8r7KTdNYVjAhnnXutNSZ/0KUww8KVO3NxKZV EbS2YfY0WMXQOCS2X+eDJcGSprlTITFg3ceEVQyDB5F/5mFOk1v6sXEvgjfyAzuow/oz nR5S6M3+PKwNn/w8fy6TdEYFcnBl6eWmEiK9Zui1DlcLBzPcvtMJg0w/stsk9ixOuBxF 2YkwsnBy5ZdgOAQtME+7IGFn29g474i8X6e50PAnRVx4sIyn86IpUIYZCQLxNA1sM7wk PwMw==
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=KwPxhciKv9SrW+udXcevl8HbCFekDvF0yywvwv+QpZU=; b=qIchMuTSmoBpDZNKLGGbeyIRwbtdgIx5EhcgZB82VUtUDhXkK6EKR/ncw8nROslkFe ETXT+ueJZYHcjf0ZGQazLvw/+lyKMbATq+FUnDRt7k60jDqH2YYFfK10Uj2pfecFZIkw PaDQpsvW+r3yNgW941f1kZg4d87yvUAvpNSsimFIGkoFjjn6UAG7SJL9PzbBp5WTDTPA KLp/aB1u/+NLegtpTSvjUluAHmD3M+/h0jwrn2QN4ku1q7qDhkJUfTAzLuw/0TREZ8hR GH3ocIuUJ8O2x4sQFTGiynUvz9daEbY7Bt3nj/PfZrhdzpBEYUGb6IMeAtC0LauIlzHX ca+g==
X-Gm-Message-State: AHPjjUgdWqzDoqgG+5hxxtCBwg1XzJ68k5ze92VYHFV83ZFU40C7S6Q/ mdnpWCKkVv9vgT/OcZJXX7reifmbeqR+
X-Google-Smtp-Source: AOwi7QAxf6+lB1Dhk5dcW3B2/dYq9TWGLvzb0IwrWa1PkigrShRR0byXqyohHCmNK0BhqcJ4wt6QLgRnVO3wqRcu4eg=
X-Received: by 10.107.104.25 with SMTP id d25mr3978418ioc.90.1504890017055; Fri, 08 Sep 2017 10:00:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.6.206 with HTTP; Fri, 8 Sep 2017 10:00:16 -0700 (PDT)
In-Reply-To: <2b11208e-a11e-c3ec-dca1-d686bc417a52@cisco.com>
References: <20170908105648.ur5ihv3gvypd7d7f@elstar.local> <c5a6cbed-34d7-a49f-127c-82f0c20f0061@cisco.com> <20170908123853.4jmy24gvbe2agiif@elstar.local> <2b11208e-a11e-c3ec-dca1-d686bc417a52@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 8 Sep 2017 10:00:16 -0700
Message-ID: <CABCOCHRJABcvbTLX2kmQrHrh7B1KjVBd5xwDt+xm-N3BQk2Acw@mail.gmail.com>
To: Robert Wilton <rwilton@cisco.com>
Cc: Martin Bjorklund <mbj@tail-f.com>, NETCONF Working Group <netconf-chairs@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="089e08260100e4b9520558b082b2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/CmhU1jv8ECobYmZIZ8fI7oBpxSg>
Subject: Re: [netmod] upcoming adoptions
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: Fri, 08 Sep 2017 17:00:19 -0000

Hi,

There are many YANG guidelines that are for promoting a consistent structure
for all IETF modules.  YANG is just more source code.  Each organization
can have
different coding guidelines, yet they can all use the same compiler.

I should explain the use-case for identifying NMDA vs. NMDA-transition
modules.
I do not want to present both types (for a given module) to the user.
So the tools need to know in "NMDA mode" which modules are duplicates
for NMDA-transition purpose only, so those modules can be hidden from the
user.
In "legacy mode" the NMDA modules would be hidden and the transition modules
would be exposed to the user instead.

Guessing which is which will only cause unhappy customers so we will force
vendors to tag the modules with our own YANG extensions to tell them apart.

Andy


On Fri, Sep 8, 2017 at 6:41 AM, Robert Wilton <rwilton@cisco.com> wrote:

>
>
> On 08/09/2017 13:38, Juergen Schoenwaelder wrote:
>
> On Fri, Sep 08, 2017 at 01:19:03PM +0100, Robert Wilton wrote:
>
> In the same vane, I think that you could regard RFC 6087 and 6087bis as one
> long list of CLRs ...
>
>
> No. There are guidelines that have a clear technical reason. An example:
>
>    The 'preceding-sibling' and 'following-sibling' axes SHOULD NOT used.
>    A server is only required to maintain the relative XML document order
>    of all instances of a particular user-ordered list or leaf-list.
>
> Yes, but even this rule has problems.  Does this mean an implementation
> does not need to support "preceding-sibling and following-sibling"?  Given
> this is only a "SHOULD NOT", it means that there might be some modules may
> still use them.  Likewise for the rest of the XPath "SHOULD NOT" rules.
> Will YANG implementations fragment on which subsets of Xpath they regard as
> sane and choose to implement?
>
> [As an aside: I actually think that it would be better to restrict the
> usage of Xpath to a much smaller subset that makes sense, but that should
> be done in 7950bis rather than 6087bis.]
>
> Besides, 6087bis has many softer rules as well, a few examples give below
> (I'm not even sure why the last one is a rule).  There don't obviously
> appear to be any technical reasons for any of these, but I don't object to
> any of these since they are provide sensible guidance, or try to encourage
> consistent modelling conventions in IETF YANG models.
>
> Ex1:
>
>  Identifiers SHOULD follow a consistent naming pattern throughout the
>    module.  Only lower-case letters, numbers, and dashes SHOULD be used
>    in identifier names.
>
>
> Ex2:
>
>  Definitions for future use SHOULD NOT be specified in a module.
>
>
> Ex3:
>
>    The signed numeric data types (i.e., 'int8', 'int16', 'int32', and
>    'int64') SHOULD NOT be used unless negative values are allowed for
>    the desired semantics.
>
>
>
>
> This is very different from guidelines how things should be named that
> do not have a real technical reason. In SMIv2 land, we had this weird
> rule that names of counters should end with a plural 's' and tools
> started to implement this and to complain if there was no plural s.
> (Actually, tools checked whether the last character is an s, which of
> course does not mean there is a plural form.) And of course, there are
> irregular nouns in English wrt. plural forms.
>
> As per ex1 above, perhaps YANG tools will start to assume that identifiers
> cannot contain uppercase characters.
>
> It might be better if a lot of the guidance in 6087bis is changed to avoid
> using RFC 2119 language precisely so that it can't be subsequently
> interpreted as a formal rule.
>
> But I still see guidance on how to consistently name counters and list
> elements is good way of helping achieve consistency, and make the models
> read better.  This doesn't mean that tools should interpret these as rules.
>
>
>
> I do not want rules that say '-state' should not be used. There may
> be valid reasons to use '-state'.
>
> Yes there might, but most likely when someone uses "-state" in the name of
> a container they will be doing the wrong thing, and it may cause them
> problems down the line.  Warning them of the potential problems now so that
> they make an informed decision seems generally helpful to humanity.  This
> does not mean that it needs to be a rule, or is even allowed to be
> interpreted as such.
>
> Thanks,
> Rob
>
>
> /js
>
>
>
>