Re: [netmod] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]

Andy Bierman <andy@yumaworks.com> Wed, 27 September 2017 20:56 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 25D9A1350C6 for <netmod@ietfa.amsl.com>; Wed, 27 Sep 2017 13:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 YQ6wuTZd1CBL for <netmod@ietfa.amsl.com>; Wed, 27 Sep 2017 13:56:17 -0700 (PDT)
Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 004411350C8 for <netmod@ietf.org>; Wed, 27 Sep 2017 13:56:12 -0700 (PDT)
Received: by mail-wr0-x230.google.com with SMTP id z39so18630525wrb.8 for <netmod@ietf.org>; Wed, 27 Sep 2017 13:56:12 -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; bh=OWZR5qjtjFNTIo45xrab3n/DBv9CETBGZH2At/Q4Wz8=; b=YmV7o79IkZMQIPvyeQjfMs3fD0a59JChImKSx3RkHi//SnejOOuG8ckztx2GIM22Ax eStWeRMmDXkKPRGW2nc89hLc4BJJs9xX+5E0q0gKF2rIA7TAoQmVpWDLcz5K6dj125Xe E+pz3cqbUkK9ljVR5vKTlJWXNxdZcQrH0UXJ8oDGmeeX4SJ1gQqdA66hac6cb8t7n3iN 1SxE0l8i5vLeOI50ng8+0bttuMkxPb8VEN79KMKhXutZdRWH7Zba/nxCL3mLMhiJAPrK iJz/+l98VgHHaz+ohWzjij3AL9qHQRAYV2/lYTroXV2jYCiVTOmP+SXJCBcGHNrDaj9h Bl7w==
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; bh=OWZR5qjtjFNTIo45xrab3n/DBv9CETBGZH2At/Q4Wz8=; b=R0For9qF5aGTksqQX7/xNLmAKkQ+kyXgW1ASSAjIn92wzWS5am8CeRNXZfCf9TycMA lbwx7wScOd74ZzM78CKqy9ZzDJVtodkjwonxNYJvP91Cea1GdgDpNDJybq+B1tNndamU 3ErDMX0+lP10xp1Y7uyBUeraRoHqSNDv021TfxwAT8sffhUwh5mbUUMzqlUAME9wUvN/ CQxzHpRDwMNYZN1NeLLqhtu2UJMIXxsvtwfJd3YF8IBgr/sNhv1l67pJruPt2d6Q30b2 EdwM0uJT+2UcQgZYBV92EJ/ZpWRV2c4HPl4xCvCoaTEvemHAOBeW+VieDxP+/evsSG3m XgoQ==
X-Gm-Message-State: AHPjjUh1uqXAIhamp/Qe8SnWVm8d9k4OrrVMQpb+bE7WvvOy88M/pPcs 39YgmdRWP2bXqpZgR+d+tSTuXXfpmG27fFBcLXqQOg==
X-Google-Smtp-Source: AOwi7QD4TrLSgaf+Be8S8YaC2OYDVIQHZulzm6QTgDN+NVfDFoyKkG5Og+MEMiMyt2YQthvKoJYMSMczM0oPNqqP+zk=
X-Received: by 10.46.77.157 with SMTP id c29mr1139021ljd.14.1506545771433; Wed, 27 Sep 2017 13:56:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Wed, 27 Sep 2017 13:56:10 -0700 (PDT)
In-Reply-To: <20170927204156.zcm4rpzkcz66avhi@elstar.local>
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <022001d32e14$8d5d4540$4001a8c0@gateway.2wire.net> <20170915123443.kvagu7dut7oaqoo2@elstar.local> <CABCOCHQcSUSUZMvzVGyaXObHadZqksKge89_6YcH9PCbxMCG=g@mail.gmail.com> <20170916072403.xp37556z6g7b42gr@elstar.local> <CABCOCHT8CMCAnqf6Oe1bKMzQ-B_0GjrQiQ8YXgQJvCo-NBOBBA@mail.gmail.com> <07b5a5df-794e-2ba8-6cad-abfcfadfc4cc@cisco.com> <4d345c3b-a28b-a0e0-27cb-306ff4618d0e@labn.net> <20170927204156.zcm4rpzkcz66avhi@elstar.local>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 27 Sep 2017 13:56:10 -0700
Message-ID: <CABCOCHTMjd-Yp37EdBOhZ1H_ehZJPi2M3QwR=qmebeUa-ZkG=w@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Lou Berger <lberger@labn.net>, Robert Wilton <rwilton@cisco.com>, netmod WG <netmod@ietf.org>, NetMod WG Chairs <netmod-chairs@ietf.org>, draft-ietf-netmod-revised-datastores@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1aba688b61ce055a320550"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/fG9-n9aXqX-9j5Q7TWwE7LhjPq4>
Subject: Re: [netmod] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]
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, 27 Sep 2017 20:56:19 -0000

Hi,



On Wed, Sep 27, 2017 at 1:41 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> Lou,
>
> text is normative without RFC 2119 language. There clearly is no such
> 'norm' unless people try to make it a new norm and I am strictly
> opposed to that. If the reason to add RFC 2119 language is to comply
> to a new norm being created, I have to object. If you want such a norm
> to be created, write an I-D and run it through the process.
>
>

It is quite common for Standards Track documents to use RFC 2119 terms.
The only new norm being set here is that the RD draft mixes architecture and
normative YANG/protocol behavior together.

If this was an Informational RFC that just discussed architecture,
then I would agree the RFC 2119 terms are not needed.



> /js
>
>
Andy



> PS: Sorry co-authors I promised to be silent but somehow I can't let
>     this reasoning go without seriously questioning it.
>
> On Wed, Sep 27, 2017 at 01:20:13PM -0400, Lou Berger wrote:
> > I think this goes to if this, or any, draft is a proposed standard or
> > not. In other words, if it specifies any behavior that for which
> > interoperability between independent implementations is the objective.
> > My general view is that in a Proposed Standard RFC, if it impacts
> > interoperability, the text should be normative and an RFC should use
> > 2119 language to identify such normative text.  I accept that this is
> > not strictly required by IETF process, but it has become the norm for PS
> > track RFCs produced today  -- and I see no reason to not follow IETF
> norm.
> >
> > In the context of this draft , as I read it, at least section 5.1 and
> > some portions of 4.
> >
> > Lou
> >
> > On 9/27/2017 12:28 PM, Robert Wilton wrote:
> > >
> > > The authors discussed this, and we will close this issue
> > > (https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does the
> > > NMDA architecture need to use RFC 2119 language?) by adding RFC 2119
> > > text to the document, which will probably be best illustrated with an
> > > updated draft revision.
> > >
> > > For the record, the majority of the authors had the view that RFC 2119
> > > language does not particularly aid readability in this architecture
> > > document.
> > >
> > > Thanks,
> > > Rob
> > >
> > >
> > > On 16/09/2017 10:56, Andy Bierman wrote:
> > >>
> > >>
> > >> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder
> > >> <j.schoenwaelder@jacobs-university.de
> > >> <mailto:j.schoenwaelder@jacobs-university.de>> wrote:
> > >>
> > >>     On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> > >>     > Hi,
> > >>     >
> > >>     > I strongly agree with Tom that the current draft is an update
> > >>     to RFC 7950.
> > >>     > I also strongly disagree with the decision to omit RFC 2119 in
> > >>     a standards
> > >>     > track document. IMO RFC 2119 terms need to be used in normative
> > >>     text,
> > >>     > especially when dealing with XPath and YANG compiler behavior.
> > >>     >
> > >>
> > >>     RFC 8174:
> > >>
> > >>        o  These words can be used as defined here, but using them is
> not
> > >>           required.  Specifically, normative text does not require
> > >>     the use
> > >>           of these key words.  They are used for clarity and
> consistency
> > >>           when that is what's wanted, but a lot of normative text
> > >>     does not
> > >>           use them and is still normative.
> > >>
> > >>
> > >> So what?
> > >> Existing YANG specifications use RFC 2119 terms.
> > >> This draft uses those terms, just with lower-case.
> > >> Either way, the new YANG rules seem half-baked and not ready
> > >> for standardization.
> > >>
> > >>
> > >>
> > >>     /js
> > >>
> > >>
> > >> Andy
> > >>
> > >>
> > >>     --
> > >>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > >>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
> > >>     Germany
> > >>     Fax:   +49 421 200 3103         <http://www.jacobs-university.de/
> > >>     <http://www.jacobs-university.de/>>
> > >>
> > >>
> > >
> > >
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>