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

[Nicolas Williams <[e-mail]>]

On Thu, Sep 30, 2010 at 01:40:23PM -0400, William A. (Andy) Adamson wrote:
> 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.

IMO: yes, mention the other potential consumers.  The list is open-
ended.  I'd include WebDAV and even local access in remote SSHv2
sessions in the list.

The risk: making people wonder why this is an NFSv4 WG work item.
  Answer: it goes hand in hand with the federated namespace work items,
          which is also not that specific to NFSv4.

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

Yes, let's do that.

> - Store 96-bit numeric IDs
>      a) cast those to domain SIDs later.
>      b) define a non-SID large ID format

(a) is fine.  (b) is a fine fallback should MSFT be unwilling to assign
authority numbers for this purpose.  See below.

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

IMO:

 - we must have a mode of operation that does not require a PAC at all;

 - we must have a mode of operation that works with the Windows PAC only;

 - we should consider an I-D defining either a new PAC or an extension
   to the Windows one to include information that servers might need but
   which is not delivered by the existing Windows PAC (but first we must
   identify such information).

Re-usign the Windows PAC implies using SIDs.  If we can't get an
authority number from MSFT, then we can't re-use the PAC.  Unless we
simply use authority #5 in the same way that Windows domains do (this is
certainly an option to consider).

> 4) General review of section 6.3.  User Group Membership Determination
> - Do we depend upon 2307bis
> - Do we require groups within groups

IMO:

 - provide a[n obviously limited] mode of operation that depends only on
   RFC2307 and therefore does not support group nesting;

 - provide a more full-fledged mode of operation that depends RFC2307bis;

 - provide a more full-fledged mode of operation that depends AD's schema.

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

I would prefer that we have one REQUIRED to implement service discovery
mechanism as follows: a) specify local DS discovery using DNS SRV RR
lookups much like AD does (i.e., have a label to indicate the purpose of
the LDAP service, not just _ldap), b) use LDAP referrals (and DNS
resolution of the host parts of the referrals) to discover DSes of other
domains.

The main benefit of this mechanism is that we can leave the work of
finding topologically-close caches and/or authoritative servers to the
clients' local DSes, thus avoiding the need to deal directly with
topology in our spec.

I would also like to make (a) general enough that clients could discover
DSes of remote domains on their own.  

Nico
--