Subject: [nfsv4] draft-adamson-nfsv4-multi-domain-access - which IETF working group?

From: "William A. (Andy) Adamson" <[email-masked]>
Date: Fri, 29 Oct 2010 15:20:12 -0400

The initial focus of draft-adamson-nfsv4-multi-domain-access was to
address the name resolution issues presented by a multi domain NFSv4
file name space; describing methods by which NFSv4 clients and servers
can handle principals, users, groups from multiple administrative
domains.  This work is driven by  the federated file system drafts
coming to completion in the NFSv4 WG and a desire for a way forward
for multi domain federated name spaces.

As the work progressed, it has become clear that this work applies to
a broader set of protocols - SMB and WebFS to name a few.  It might also
apply to the federations and use cases that ABFAB WG services, and
has some significant cross over with the general PAC work from
Simo Sorce, draft-sorce-krbwg-general-pac.00.txt.
At the end of the day, we want to ensure that this draft not only is
not in conflict with any ABFAB or other drafts, but that the drafts
are usable together even if each piece can also be used independently
of the other.

The question is: which working group is best to move this draft
forward, and how do we ensure (no matter which working group takes on
the task) that all the work each WG does complements each other.

I note that the federated file system drafts that the NFSv4 working
group has successfully moved to completion have a similar issue in
that the technology also applies to non-NFS protocols.

If the NFSv4 working group is willing, I vote for
draft-adamson-nfsv4-multi-domain-access to be an NFSv4 WG item.

draft-sorce-krbwg-general-pac-00.txt describes a general PAC for
Kerberos which includes global identities applicable to cross-realm.
There have been discussions on the krb-wg list concerning the two
drafts.

draft-adamson-nfsv4-multi-domain-access-03.txt talks about PACs but
does not specify one, and is independent of the authorization mechanisms.
Our draft describes name and authorization context resolution in a federated
environment.

The ABFAB charter initial focus is on describing a federated identity
(GSS-API) mechanism that will include resolution of federated
attributes, but (correct me if I'm wrong) no name resolution.

I am giving a very high-level 10min talk on
draft-adamson-nfsv4-multi-domain-access-03.txt in Beijing at the
NFSv4 WG  morning session Tuesday November 9th, and I invite your participation.
Unfortunately KITTEN meets at the same time as NFSv4.  Perhaps we could
schedule a few minutes at either ABFAB or KRB-WG? Or find another time to talk?

-->Andy

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 31 Oct 2010 23:45:05 -0500

On Sun, Oct 31, 2010 at 03:20:09PM -0400, Sam Hartman wrote:
> Here's my $0.02 worth on how best to move forward your draft  and to
> involve other people.

Thank you Sam, I agree completely with all that you've said.

I was wondering if the ABFAB community would find the focus on LDAP to
be objectionable.  You would have said stated such an objection if you'd
had it, but others might still...  Should that happen I suppose we could
generalize the document to include the use of SAML for name services as
an option, just as we hear that we need to allow for certain options
(e.g., non-standard base DN forms).

We still need to hear from others, but it's looking like the next step
is to make sure that this work falls in the NFSv4 WG charter, either
by interpreting the current charter as encompassing it, or, more likely,
by seeking to amend the NFSv4 WG charter.

Thanks again,

Nico
--