Re: [nfsv4] Use of RFC 8174 in RFC-to-be draft-ietf-nfsv4-rfc5661sesqui-msns-04

Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 31 July 2020 12:04 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D678A3A0B49; Fri, 31 Jul 2020 05:04:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 WcD0VZz2MSdL; Fri, 31 Jul 2020 05:03:59 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40089.outbound.protection.outlook.com [40.107.4.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E393C3A1302; Fri, 31 Jul 2020 05:03:58 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=afmUEhIYHt5MNWY3YtKLHOW4QW/nkkQyabtprm8UM7gsDBdbx5U35EishQ4hbFBW3C+Fp9fEIXgUHRCq7nTLbIUd9MCh+W0NoizvcNkD9h2yaXfNhhF61qvqbaLiDHii5jwPLOFF0ySEBBSa6gCbb/ARzk6tDDdAJkGQGs830dv1hAqKxmLt00PiHQV2Thy46xW6r3N4wIyY+GiexS1ZrF2Nrn8h5VzYkq+K9YdZXnZG6399aef0x5to59Yh2LSBrrGnAw08ySRl0/uH4z8MY2/qpVbYKJSP6jcAhMyDJ3j5HUPrpqbt5NqcLuve0qC7wDjROO4jWbBz7sj82XiOCA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C6J3VEsKTyYBAUM8PK0iVlN7oFACzk+eoOIIeyahqeQ=; b=gLsY1NnSvo8kAz0DN6ZoX3hNXKtCnMY+CXWXNJFoTCnMsU8hU5kxajUi45ZYYWwqh3O3Ey2VBGbn6iP6rC+KJ6k6K9Z+rNy5J1JOdlIMlpbvWdpiOIwA2USIB3IyYXvBx8INUvTJpmBBc+j+fRcuCezroNR6fkzA4cXuMP7BKTuvH/LZFlmGm2XrEd1oVuS7J4nixyNySgdSpCO6AqAurjlaTUbWajU4KA1AmjeRB/YT/Ogw8CqefzQssvy/s7xYU+KK5k+lRp6Z5qPWG2Uns10wjmgxXxl7fdtBDBbUysxs9BvmX1ySvGHBpnYbYIalYoXC7WZeav4yk9tkrjsv/Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C6J3VEsKTyYBAUM8PK0iVlN7oFACzk+eoOIIeyahqeQ=; b=oqNarCnBs6fCSk3V3aZFSpcR9wjG8VWNRM4pVRyWyF9lRtVvFOOeYYt3wQS2TF6MOPyUc532qYnNbx/u3jVR4WmVcFvmzeDTOISVO4fqlN264B/Eaa6glz9CJ3+unxZoisb9XZ9cWKHjTg/aAopj8JcxzL0uORBBDLKCYsUO9Pc=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB3451.eurprd07.prod.outlook.com (2603:10a6:7:31::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Fri, 31 Jul 2020 12:03:56 +0000
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::546c:3b3:9193:3351]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::546c:3b3:9193:3351%6]) with mapi id 15.20.3239.019; Fri, 31 Jul 2020 12:03:56 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "davenoveck@gmail.com" <davenoveck@gmail.com>
CC: "draft-ietf-nfsv4-rfc5661sesqui-msns@ietf.org" <draft-ietf-nfsv4-rfc5661sesqui-msns@ietf.org>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Thread-Topic: Use of RFC 8174 in RFC-to-be draft-ietf-nfsv4-rfc5661sesqui-msns-04
Thread-Index: AQHWZyS63QV3GTLuCkugCUGXmcy6TakhjBiAgAAK8oA=
Date: Fri, 31 Jul 2020 12:03:56 +0000
Message-ID: <d625c1400e14154081686dd6c1bedb3459c92cf4.camel@ericsson.com>
References: <22f396397ca072ad39b76555379ecdd4df73fc65.camel@ericsson.com> <CADaq8jf2b2YT0Nr_TYbwcK+JoXrzUsnsQMzi7a5LupEh-cq3Gw@mail.gmail.com>
In-Reply-To: <CADaq8jf2b2YT0Nr_TYbwcK+JoXrzUsnsQMzi7a5LupEh-cq3Gw@mail.gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [98.128.243.14]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 902e4198-7789-47c4-821b-08d83549cd41
x-ms-traffictypediagnostic: HE1PR07MB3451:
x-microsoft-antispam-prvs: <HE1PR07MB3451BB94F5B4AECC623F9A41954E0@HE1PR07MB3451.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: iYZ0OhYhIACGOk2MZNo9MUwOdiZivZdITcTYUlwl9pOB052nRaUSVpHM6zsYm9j19jgSyVJmHKsYQjae5j8JcMn64PQO2GvHcOdpzPH6ORqBTf1fc/Pv+uI9YKNxKkzkx5mJPF5VzcFpnlU2umqLFxws8KKTN8mc0ETYg6+j+XI6eX3pcLkmcXIsXt7zWW03RUyXJtOwLkaGx7CXTnppbRdF482ZHzniJKKf+M8awClKUEeYvVhIVlFV0NjW17b7vGNT7iNzHK9iBmSTb7FUjFrshCadtO4Dfi8325MHz/ftEK4YgeyNw4Y9xVoFRkqc3Ad4SWPt/iKv+jN4n/en/W+XfCaOlg4kKQ/NEIZGtsTytSsqtLNtOcSQ3tkPmpO+usdKoR7W4tQkWpUVeLJQJUwE3awfBUCbNdCeYPGcXryCMUYFFV61GCcQ9sUrDN5FDIi6+QlfPyWrzAWhwskCew==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(376002)(366004)(346002)(396003)(71200400001)(6916009)(66946007)(54906003)(6512007)(4326008)(6486002)(8936002)(76116006)(2906002)(2616005)(316002)(83380400001)(86362001)(478600001)(66446008)(64756008)(26005)(44832011)(66476007)(66556008)(8676002)(5660300002)(6506007)(36756003)(186003)(99106002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: F3hDNzW02Ov7qq2RCCq76tJp9c2sbKc8gz6svJYYUc7Ah4wHyTYCPm0KeWkPhuaFOC2iwxTyDajH1eNKN8nwDb1aqkqGHyg07GPHMAhzFGVphH2qxM2MhAkabGVRfx7KGtzDgpgqvUyd50/p6ihNmmdod3iw0zUYcxGAgNYElJE4TD45go72gk2Z4J0vEtp6jp/5Yvu4/YBs3jwbCKu5zWLIpN2JhaBQpN+ITNV6ueellHI+RalfKYF85AYUFI0YxzxpOZPEw77Uviw5PnRRT8XyFyvqE9uaYkp3gWfeio80gaZElv2NiO20qmZUgX8EpTjK9XGUdMkI6cv+5/aZYzXh+eBiMh3RA03swhUDQrgAduaVh0GrVwZjovdifcE3EjgPB7rETskeCBxM607bx9Bsz6kMVE87cVahuuNSj2S8PzLVg0z5UkVZulELhesTPMEc11EeM7PPGahSnpK7HhVyBZjI51pIK+LARBxfZxoGFboVTN3+8QS+FFYjiEzBQ2pNeJaVI/6jS8tgsjh/JupbEnBQF8+gbPxQrH1uFEHGx+mZxLMnWz6EYSBwwzYLfvojx8rL9Ry8yKbWnQSljgRYwajQSWwb4lvzjNsqSA0rSaYSSmMt4FNY+nIKgqkWo05SEB0VQ4HMO87Jr/ZHaA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <244DACB109B08F42BB5F2F0EAEB4F25B@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 902e4198-7789-47c4-821b-08d83549cd41
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2020 12:03:56.4482 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8gENnm93NXw40dn6fEGMWn2+KxPk1aRT5RvsgL8K8QizRdldtfAhYOFHa0h/XzRfaAzFCwauxgcJ7OLYZFB4rfA5H/oqLHZxt0/9Uuf3LME=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3451
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/ADM6G--aDEeBzW0SH-7JI9oNUVk>
Subject: Re: [nfsv4] Use of RFC 8174 in RFC-to-be draft-ietf-nfsv4-rfc5661sesqui-msns-04
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jul 2020 12:04:02 -0000

Hi,

Please see inline. WG please provide input.


On Fri, 2020-07-31 at 07:24 -0400, David Noveck wrote:
> 
> 
> On Fri, Jul 31, 2020, 6:24 AM Magnus Westerlund <
> magnus.westerlund@ericsson.com> wrote:
> > WG and Authors,
> > 
> > The RFC-editor asked in the AUTH48 of draft-ietf-nfsv4-rfc5661sesqui-msns-04 
> > if
> > the use of RFC 2119 language template should be updated to the one that
> > includes
> > RFC 8174 (https://datatracker.ietf.org/doc/rfc8174/). In other words
> > changing
> > Section 1.3 from:
> > 
> >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> >    document are to be interpreted as described in RFC 2119 [1].
> > 
> > To:
> > 
> >       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
> >       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
> >       "MAY", and "OPTIONAL" in this document are to be interpreted as
> >       described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
> >       appear in all capitals, as shown here.
> > 
> > David and I have opposite views here. So attached are a file with all lines
> > from
> > -04 that contains a lower case RFC 2119 term. There are 1493 occurrences in
> > the
> > file.
> > 
> > My current position is that this should not be changed. My main reason is
> > that
> > the document using the RFC 2119 terms and definition was how it went through
> > the
> > consensus and approval process.
> 
> That's true but the authors did not treat "must" and "MUST" as synonymous.

Understood, but the larger community may have. And I having seen this discussion
maybe more than some in this WG have and are thus cautious about making any
assumption and have worked with co-authors to actually eliminate lower case
usage to avoid the issue. 

> 
> 
> > Based on the large number of occurrences of the
> > terms that needs to be determined if any of these really should be
> > capatilized
> > if the RFC 8174 definition is applied. 
> > 
> > I will provide what I think is a strong example of why such investigation
> > would
> > need to be done and considered. 
> > 
> > 
> >  If the client requests
> >    OPEN4_SHARE_ACCESS_WANT_WRITE_DELEG without
> >    OPEN4_SHARE_ACCESS_WANT_READ_DELEG on an object with one of the
> >    aforementioned file types, the server must set
> >    wdr_resok4.od_whynone.ond_why to WND4_WRITE_DELEG_NOT_SUPP_FTYPE.
> > 
> > 
> > I think that matches the 2119 definition of MUST:
> > 
> > 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
> >    definition is an absolute requirement of the specification.
> 
> It also matches the definition of the English word "must".
> 
> > Lets also review Section 6 of RFC 2119:
> > 
> >    Imperatives of the type defined in this memo must be used with care
> >    and sparingly.  In particular, they MUST
> > only be used where it is
> >    actually required for interoperation or to limit behavior which has
> >    potential for causing harm (e.g., limiting retransmisssions)  For
> >    example, they must not be used to try to impose a particular method
> >    on implementors where the method is not required for
> >    Interoperability.
> 
> This paragraph is explaining where such term should not be used. It should not
> be read as implying that they need to be used in any particular case.
> 
> > What would happen if one did not follow the MUST in the above sentence? I
> > assume
> > interoperability issues or protocol failures. I just picked a sentence that
> > appeared to have potentially implications if they are not followed for the
> > protocol operation. 
> 
> Exactly, but I have heard IESG members object to the use of "MUST" in
> situations like this saying "that's just explaining how the protocol works".

So I picked one example and I have to confes that I don't understand what would
occurr in this specific example if you didn't follow it and if there are
options. So if this "must" can be replaced by a "needs" or a "MUST" is not
obvious and would require me to dig significantly into the specification.

> 
> > The point I am trying to make is that if we go with RFC8174 the WG would be
> > forced to review all these 1493 occurrences and decided if they really all
> > are
> > lower case or if actually some of them should be promoted to upper case. 
> 
> 
> That would be a drag.

Yes, it does take some work.

> 
> > Then we have the next issue, which is me as responsible AD having to judge
> > if
> > the result of this change still represent what was approved by the IESG and
> > has
> > IETF consensus for publication. Currently I do significantly struggle with
> > making such a determination, or if I think the document would need to go
> > back
> > and redo the WG, and IETF last call. The document as it stands using RFC
> > 2119
> > have established consensus. So I argue for the path of least resistance by
> > not
> > changing here to get these updates published.
> 
> Ok. I surrender.   Although I think adding a reference to RFC 8174 would make
> things clearer, I am prepared, if the wg concurs, to ask the rfc editor to
> leave that out.

Yes, and I think it is definitely a change to do for the proper bis.  I do agree
it clarifies. But, changing it at this point have impact that I want to avoid.

WG, please provide any views on this. 

> 
> > Updating to RFC 8174 is definitely the proper bis version should do. But by
> > doing that early as all the other changes are folded in the WG will have
> > time to
> > consider the usage and maybe also use a writing style that avoids using the
> > lower case version of the RFC2119 terms.
> 
> I don't think we want to rewrite all this text or eliminate these English
> words which have an established meaning.

Fine, and with RFC8174 that need may be significantly reduced. It has been a way
to avoid the confusion. 

> 
> > 
> > This is my view and you should not jump in on this until David have had a
> > chance
> > to provide his view, but although I understand his high level reasoning, he
> > hasn't seen my arguments for my position either. 

Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------