Re: [Gen-art] Gen-ART Last Call review of draft-ietf-nfsv4-multi-domain-fs-reqs-09

Brian E Carpenter <> Mon, 11 July 2016 15:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D623112B047; Mon, 11 Jul 2016 08:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8PgWNDf3pT-Q; Mon, 11 Jul 2016 08:26:40 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7ECFA12D54D; Mon, 11 Jul 2016 08:26:40 -0700 (PDT)
Received: by with SMTP id f65so67891507wmi.0; Mon, 11 Jul 2016 08:26:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=psYKSYsNE3Wh6V+lnsjJhOBtsh9IpFbFnZv4pi5Cwwg=; b=xJIrxfhgwD4FhmFg03/GohaA5nqKJUeGOySLiWURs1feyF76IwUrs7TxnbmSolopui yemKUV4v3Oy7sbv6prIoUTjf05ZNaIjMLYsObooDPoXk4DhNGUdxoeXDQ97TOMYbavPU vlyHMUmPW4iyAP/Dsmnpv/hpGlFUnfeUiOuzGfXsKUqvAZ9+WaIKW/hm7pMr+nk2mDD9 yYE5VXeKKoDCQvxbe4pa00BRVlwp/H51sAtTBjV2WN1lnIwsyckDVzQk7k+suLvOZHOq ti/+tfnGOl3DX0WiP0UOOjJMhYLcvPHoTDPsrRr3urSaNNSEvSuKokr+NuF45JDqZXlA OGqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=psYKSYsNE3Wh6V+lnsjJhOBtsh9IpFbFnZv4pi5Cwwg=; b=RQqEx7e75dJfd27oe53ngDLLiLQ7dnPRyulRCcAHfJP3wrByAxKtyUo+ZIynCAncJa ykACuCH2ua49LGtFJLLFqLbvUNOTk+48dnbP8+/smqjojQ+KZ7VAXl3WK+pboGGJd41R XPp4WC6CoRrTUwXcIuzHGYQxMEVk4+R3TAi8ggf1koi+Az8nBYCdx6pXtwAoyKhDnfOA Lw+tm63DHuPVEpYBWlX5xH+6L9tndky78+kU1cdLgcI97NFGbskU1Z/47s3kjxXDWWDE 3HiXYn7mlsOkLSvt/7OmUDk4pdVR9Nqw+TMDVTljgHKYwTrSFtxPE9HANvcUktqOtv1g JqMA==
X-Gm-Message-State: ALyK8tIAIf/QTS01oMFs+Hie4ScndDWCjnTAbzNAFW8zkGj9u1Q7M7dt4hKhysbzoQxh+g==
X-Received: by with SMTP id x5mr14592148wmg.11.1468250798442; Mon, 11 Jul 2016 08:26:38 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id pa8sm352828wjb.13.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jul 2016 08:26:37 -0700 (PDT)
To: "Adamson, Andy" <>
References: <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Tue, 12 Jul 2016 03:26:37 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>, General Area Review Team <>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-nfsv4-multi-domain-fs-reqs-09
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Jul 2016 15:26:43 -0000


So we have this in the minutes:

> Get status - is it in WG last call. Should it be informational
> or standards draft. Draft clarifies how make all this work.

...i.e. it describes best practice, not protocol details.

> 2119 MUSTs, SHOULDs and MAYs can be used in an informational draft
> says David Black. 

They can, but they are a clear signal to think carefully.

> Martin thinks its wise to put on standards track.

In the end it's a judgment call, of course, but "make this all work"
is surely the goal of most BCPs?


   Brian Carpenter

On 12/07/2016 02:47, Adamson, Andy wrote:
>> On Jul 5, 2016, at 11:54 AM, Brian E Carpenter <> wrote:
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>> For more information, please see the FAQ at
>> <>.
>> Document: draft-ietf-nfsv4-multi-domain-fs-reqs-09.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2016-07-05
>> IETF LC End Date: 2016-07-06
>> IESG Telechat date:
>> Summary: Ready with issues
>> --------
>> Comment: I was asked to review -08 but found -09 has been posted, with
>> -------- considerable changes, during Last Call.
>> Minor issues:
>> -------------
>> "This document provides guidance on the deployment of..."
>> Sounds more like a BCP than a Proposed Standard to me.
> Hi Brian
> The “Informational vrs Standards” track issue was discussed at IETF93. From the minutes at
> -- Multidomain draft (Adamson)
> No slides.
> Similar to layout types. Clarifying issues in NFS V4.0 and 4.1,
> especially with FedFS.
> Get status - is it in WG last call. Should it be informational
> or standards draft. Draft clarifies how make all this work.
> 2119 MUSTs, SHOULDs and MAYs can be used in an informational draft
> says David Black. Martin thinks its wise to put on standards track.
> No errata to speak of - just additional information.
> ----------------
>>  As I read through the
>> document, it describes alternatives and differing scenarios. That also seems
>> like BCP to me. One example:
>>> 7.  Resolving Multi-domain Authorization Information
>>>  When an RPCSEC_GSS principal is seeking access to files on an NFSv4
>>>  server, after authenticating the principal, the server must obtain in
>>>  a secure manner the principal's authorization context information
>>>  from an authoritative source such as the name service in the
>>>  principal's NFSv4 Domain.
>> That's underspecified for a standard but perfect for a description of
>> best practice.
> I propose to change the above ‘must’ to a ’SHOULD’. The above actually applies to an NFSv4 server using RPCSEC_GSS in any environment as it does no good (e.g. it is insecure) to establish the authentication of a principal in a secure manner, and to then map that principal to local file system representation authorization info for file access determination in an insecure manner.
> I thought this was specified in previous standards - but I can’t find mention of any requirement for security in gathering  authorization information on an RPCSEC_GSS authenticated principal anywhere in RFC7530, RFC5661 nor in the FedFS RFC’s. Section 5.9 of RFC 7530 discusses the translation of security principals into " a common format, generally that used by local storage, to serve as a means of identifying the users corresponding to these security principals.”  but makes no mention of requiring a secure translation method.
> The only mention I find is in the Security Considerations section of draft-cel-nfsv4-federated-fs-security-addendum-05 which states:
> "When deploying FedFS, the use of security mechanisms that maintain
>    the confidentiality of all network communications is recommended."
>> The choices between lower-case and upper-case "must" seem fairly arbitrary.
>> There are only 5 instances of "MUST" and one "REQUIRED". Maybe this document just
>> doesn't need RFC2119 keywords?
> The doc definitely needs RFC2119 keywords - as the MUST and REQUIRED noted in the doc are absolute requirements for an NFSv4 multi-domain file name space to work.
>>  ** Downref: Normative reference to an Informational RFC: RFC 1813
>> This reference was added in the -09 version. I believe it should be
>> Informative instead of Normative.
> It is an informative reference. I’ll fix it.
> —>Andy
>> If not, a new Last Call mentioning
>> the downref is necessary.
>>  ** Obsolete normative reference: RFC 1831 (Obsoleted by RFC 5531)
>> This needs to be fixed.