Subject: [Ietf-krb-wg] 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
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Sun, 31 Oct 2010 15:20:09 -0400

Here's my $0.02 worth on how best to move forward your draft  and to
involve other people.

1) NFSV4 should drive the effort. Why? You have a real-world constrained
use case.
Having such a driver makes projects complete more rapidly and helps
tie-break questions about scope expansion.

2) You should definitely seek review from abfab both now and as you
approach last call.  It does overlap with things we care about, but it
is not technically in our charter. If for some reason people who are
planning on spending significant time contributing to the work believe
that having it driven by nfsv4 is too narrow, we can discuss whether
adding this to abfab makes sense.  I'll note that even in cases where
people are well-meaning and all want to get some work done, shifting
working groups tends to slow things down.

3) Any specification of a PAC or other Kerberos authorization data
should happen in krb-wg. So, it's fine for this draft to reference a
PAC, or to describe needs for a PAC. However the actual Kerberos work
should happen in krb-wg.

4) LDAP schema specification is more mature than Kerberos. The LDAP
community might well be happy for that part to happen in nfsv4, in
krb-wg, etc. We should check with them.

Anyway, I've briefly examined your draft, and it seems like a good start
on a really critical issue.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg