Re: [nfsv4] New version of NFSv4 multi-domain access draft (

"Everhart, Craig" <> Thu, 07 October 2010 16:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9493B3A6FCC for <>; Thu, 7 Oct 2010 09:18:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.256
X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1pFCMBp+Iyvd for <>; Thu, 7 Oct 2010 09:18:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7F5BC3A6F3C for <>; Thu, 7 Oct 2010 09:18:54 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.57,298,1283756400"; d="scan'208";a="464204562"
Received: from ([]) by with ESMTP; 07 Oct 2010 09:19:57 -0700
Received: from ( []) by (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o97GJuqH001581; Thu, 7 Oct 2010 09:19:57 -0700 (PDT)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Oct 2010 09:19:57 -0700
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Oct 2010 12:19:55 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 07 Oct 2010 12:19:54 -0400
Message-ID: <>
In-Reply-To: <>
thread-topic: [nfsv4] New version of NFSv4 multi-domain access draft (
thread-index: ActgxqNVvnv6J826SZGD3Uu2e/LilgFbRGZQ
References: <>
From: "Everhart, Craig" <>
To: "William A. (Andy) Adamson" <>, NFSv4 <>
X-OriginalArrivalTime: 07 Oct 2010 16:19:55.0796 (UTC) FILETIME=[7AB4BD40:01CB663B]
Subject: Re: [nfsv4] New version of NFSv4 multi-domain access draft (
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Oct 2010 16:18:55 -0000

Couple of things I wonder about here.

The draft goes to some lengths to claim that an NFS server's use of
"name@domainname" would be problematic because of difficulties keeping
up with accounts ("a severe constraint"), and that servers "really ought
not" store authz entities in that form.  While I don't agree with either
of these, I don't think that my objections are material to the point of
the draft.

Instead, if I'm reading correctly, this is a presentation about how to
do ID mapping with 32-bit or 64-bit IDs, with name service assistance.
I think that the draft could make the point about the prevalence of such
servers without needing to critique other representations.  Perhaps (but
not _required_) the draft could deal with the interoperability of
servers, some of which use integers for IDs and some which use
name@domainname, in the kind of FedFS scenario you describe.

I eagerly await the 5.4.3 text, or even the plans.  What's a "domain" in
this context?  How does a server tell if it is in one?  Does a client
need to know?  What is a "domain-local ID"? In section 5.2.1, what's the
point to "assigning and publishing a unique ID to each DNS domain"?
Isn't the DNS domain name good enough?

Could we add an example to 6.2?  I can't tell if the first paragraph is
a modest hole or a truck-sized hole.


> -----Original Message-----
> From: William A. (Andy) Adamson []
> Sent: Thursday, September 30, 2010 1:40 PM
> To: NFSv4
> Subject: [nfsv4] New version of NFSv4 multi-domain access draft (
> Hello
> I uploaded a new version of our internet draft "NFSv4 Multi-Domain
> Access"
> Please have a look and give us any feedback.
> There are a number of sections that need text. Here are some issues
> that need discussion.
> 1)  NFSv4 is not the only potential consumer. NFSv3, and SFTP, for
> example. Do we mention these and/or other potential consumers.
> 2) Section 5.4.3.  Resolving Domain Names to Domain IDs
> We need to have a common way to map Domain Names to Domain IDs.
> Currently we have two suggestions
> - Just use SIDs, first asking MSFT to allocate a suitable authority
> for non-Windows domain SIDs.
> - Store 96-bit numeric IDs
>      a) cast those to domain SIDs later.
>      b) define a non-SID large ID format
> 3) Section 6.1.2.  RPCSEC_GSS Authorization Context Credential Data
> Do we want to define a new "PAC" for multi-domain access for those
> implementations that don't provide the Windows PAC, or just insist
> upon the use of the Microsoft PAC.
> 4) General review of section 6.3.  User Group Membership Determination
> - Do we depend upon 2307bis
> - Do we require groups within groups
> 5) Do we need a section on service discovery.  Two potential methods:
> - Use local methods (configuration, DNS SRV RR lookups, ...) to
>   discover local domain's servers, then depend on LDAP referrals for
>   discovering all other domains' s
> - Use DNS SRV RRs much the way AD does.ervers.
> -->Andy
> _______________________________________________
> nfsv4 mailing list