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

"Adamson, Andy" <> Mon, 11 July 2016 14:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3AEEE12D519; Mon, 11 Jul 2016 07:52:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.188
X-Spam-Status: No, score=-8.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JLc4Eh4QyvOL; Mon, 11 Jul 2016 07:52:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 291ED12D1D8; Mon, 11 Jul 2016 07:52:09 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.28,346,1464678000"; d="scan'208";a="126302445"
Received: from ([]) by with ESMTP; 11 Jul 2016 07:47:03 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1156.6; Mon, 11 Jul 2016 07:47:03 -0700
Received: from ([::1]) by ([fe80::bc9d:c26a:65b2:409%21]) with mapi id 15.00.1156.000; Mon, 11 Jul 2016 07:47:03 -0700
From: "Adamson, Andy" <>
To: Brian E Carpenter <>
Thread-Topic: Gen-ART Last Call review of draft-ietf-nfsv4-multi-domain-fs-reqs-09
Thread-Index: AQHR1tWTQhRc4kgf1kSYCFw7vlvfcaATzdmA
Date: Mon, 11 Jul 2016 14:47:02 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3112)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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 14:52:11 -0000

> 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.


> 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.