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

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 11 July 2016 15:26 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D623112B047; Mon, 11 Jul 2016 08:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8PgWNDf3pT-Q; Mon, 11 Jul 2016 08:26:40 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 7ECFA12D54D; Mon, 11 Jul 2016 08:26:40 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id f65so67891507wmi.0; Mon, 11 Jul 2016 08:26:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.28.224.5 with SMTP id x5mr14592148wmg.11.1468250798442; Mon, 11 Jul 2016 08:26:38 -0700 (PDT)
Received: from [10.0.1.29] (cpc66883-mort6-2-0-cust696.19-2.cable.virginm.net. [92.233.126.185]) by smtp.gmail.com with ESMTPSA id pa8sm352828wjb.13.2016.07.11.08.26.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jul 2016 08:26:37 -0700 (PDT)
To: "Adamson, Andy" <William.Adamson@netapp.com>
References: <5b1bf6c3-67a7-9565-f504-7be87720b6a1@gmail.com> <B453D35D-4FA3-4DD5-B90E-BAC35F2299B2@netapp.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <46eba96e-d837-9fc9-0f6b-d5bad97cfb2d@gmail.com>
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: <B453D35D-4FA3-4DD5-B90E-BAC35F2299B2@netapp.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/-cNJBN-EJYkm6KDmPD-us8zIFMY>
Cc: "draft-ietf-nfsv4-multi-domain-fs-reqs.all@ietf.org" <draft-ietf-nfsv4-multi-domain-fs-reqs.all@ietf.org>, General Area Review Team <gen-art@ietf.org>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-nfsv4-multi-domain-fs-reqs-09
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jul 2016 15:26:43 -0000

Hi,

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?

Regards
    Brian




Regards
   Brian Carpenter
   http://orcid.org/0000-0001-7924-6182



On 12/07/2016 02:47, Adamson, Andy wrote:
> 
>> On Jul 5, 2016, at 11:54 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> 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
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> 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 https://datatracker.ietf.org/doc/minutes-93-nfsv4/
> 
> -- 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.
>