Re: [secdir] SecDir Review of draft-ietf-nfsv4-multi-domain-fs-reqs-09

"Adamson, Andy" <> Mon, 29 August 2016 19:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FA7012D859; Mon, 29 Aug 2016 12:51:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.469
X-Spam-Status: No, score=-7.469 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8C1CRwgxqa1l; Mon, 29 Aug 2016 12:51:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B01812D862; Mon, 29 Aug 2016 12:51:07 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.30,252,1470726000"; d="scan'208";a="140393077"
Received: from ([]) by with ESMTP; 29 Aug 2016 12:50:21 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 29 Aug 2016 12:50:20 -0700
Received: from ([::1]) by ([fe80::a009:cb7a:e519:7347%21]) with mapi id 15.00.1210.000; Mon, 29 Aug 2016 12:50:19 -0700
From: "Adamson, Andy" <>
To: Russ Housley <>
Thread-Topic: SecDir Review of draft-ietf-nfsv4-multi-domain-fs-reqs-09
Thread-Index: AQHR/uEAScqWPrR74UmjQi/JRyLWv6Bg1LqA
Date: Mon, 29 Aug 2016 19:50:18 +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: "" <>, IESG <>, IETF SecDir <>
Subject: Re: [secdir] SecDir Review of draft-ietf-nfsv4-multi-domain-fs-reqs-09
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Aug 2016 19:51:11 -0000

> On Aug 25, 2016, at 10:57 AM, Russ Housley <> wrote:
> I reviewed this document as part of the Security Directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the Security Area
> Directors.  Document authors, document editors, and WG chairs should
> treat these comments just like any other IETF Last Call comments.
> Version reviewed: draft-ietf-nfsv4-multi-domain-fs-reqs-09
> Summary: Ready
> Thank you for rewriting the Abstract and Introduction.  They are much
> improved.
> Major Concerns:  None.
> Minor Concerns:
> The first paragraph in Section 3 includes: "The issues with multi-domain
> deployments described in this document apply ...".  I do not think that
> "issues" is the right word.  To be consistent with the title of the
> document, it should be talking about guidance or deployment
> alternatives.

Hi Russ

Thanks for your review.

This latest round of comments - including the Gen-ART review from Brian Carpenter shows that there is still an impedance mis-match between the title/abstract and the intended status of Standards Track versus an Informational draft or best practices.

I feel that the use of "Guidelines" in the title, and "guidance" in the abstract point to an Informational draft rather than a Standards track.

This draft is a Proposed Standard (not an Informational or BCP) because the MUST and REQUIRED noted in section 6 of the doc are absolute requirements for an NFSv4 multi-domain file name space to work. These can not be BCP as an NFSv4 multi-domain file name space will _not_ work without these requirements.

I have completed a draft-ietf-nfsv4-multi-domain-fs-reqs-10 with the following changes:

1) The title to be changed from

"Multiple NFSv4 Domain Namespace Deployment Guidelines"


"Multiple NFSv4 Domain Namespace Deployment Requirements"

2) The first sentence in the abstract (and in the introduction) to be changed from

   This document provides guidance on the deployment of the NFSv4
   protocols for the construction of an NFSv4 file name space in
   environments with multiple NFSv4 Domains.

   This document presents requirements on the deployment of the NFSv4
   protocols for the construction of an NFSv4 file name space in
   environments with multiple NFSv4 Domains. 

Another common area of comment concerned the “Stand-alone Examples" examples section 5 and "Stand-alone Examples and Multiple NFSv4 Domain Namespaces” section 8. These section describe "alternatives and differing scenarios” to highlight the need for the requirements described in section 6.

I addressed the example sections comments by adding clarifying text to each of these sections as well as moving the second section from 8 to section 7.

I have also addressed the remaining comments from Brian, Russ, Alexey Melnikov, and Kathleen Moriarty.

I’ll upload the new draft soon.


> In Section 6.2.1, it says:
>   Multiple security services per NFSv4 Domain is allowed, and brings
>   the issue of mapping multiple Kerberos 5 principal@REALMs to the same
>   local ID.  Methods of achieving this are beyond the scope of this
>   document.
> I think it would be better to use "need" instead of "issue".
> Nits:
> Please change "internet" to "Internet" throughout the document.
> In Section 2, "Stringified UID or GID" definition:  Please add "of" to
> the last sentence, so that it reads: "See Section 5.9 of [RFC5661]."