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

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.

		Craig

> -----Original Message-----
> From: William A. (Andy) Adamson [mailto:androsadamson@gmail.com]
> 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"
> 
> http://www.ietf.org/id/draft-adamson-nfsv4-multi-domain-access-03.txt
> 
> 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
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4