Subject: [nfsv4] discussion about multi-domain FedFS work.

From: "Noveck, David" <[email-masked]>
Date: Thu, 1 Aug 2013 04:00:07 -0400

I had some discussions with people about this work and what, if anything, should happen next with regard to it.

I don't think the lack of discussion proves very much.  In fact, there are a number of documents which have also encountered a lack of discussion.    This does not imply that there is  a lack of interest or that work should cease.  You have to look at the reason for the lack of discussion:

*         With regard to the migration documents there has also been a lack of discussion.  I think this reflects a general belief that we are on the right track  (we no longer get "That'll never work" or "Why are doing that?")  on the part of the working group along with a reluctance on the part of most people to deal with the details of migration issues.  There have been separate off-list discussions with implementers which I take account of as I produce new versions.   The working group can look at the versions and comment on changes but very few people have done so.

Because people are working to produce implementations, the progress of those implementations and not the working group mail flow is the relevant metric of progress.

*         With regard to RFC5664bis, we've had very little group discussion.  The reason for that is that very few people are interested in pNFS objects.

Here the relevant fact is that the job of RFC5664bis is to correctly describe implementations that already exist.  The fact that only a few people care about it is irrelevant as long as the issues that people do raise are addressed.  There is no minimum threshold for working group interest.

*         With regard to the multi-domain stuff, there is no current implementation work so it isn't clear what conclusion to draw from the lack of discussion.

I've talked to Andy and Chuck to see what they think.

Rather than look at the general subject and the two specific documents as a single unit, I've tried to look at the following specific questions.

*         Is there general interest in the subject?

While there is clearly not a lot of interest in the details, I don't think it is the case that people don't want this to be addressed at all.  I think it is best to ask the working group what they think.

*         What should happen to Andy's requirements document?

I'm not sure what the lack of working group discussion means.  If it reflects the fact that nobody has any objections to what Andy has written, then perhaps it means that the document is OK as it is, in which case it should go forward.   It probably makes sense to ask Andy and Chuck how they'd feel about that.

*         What should happen regarding the promised best-practices document.

I think it makes sense to drop this document from the charter, at least for now.  Clearly, until we have a range of implementation practices to choose among, we can't select a set which is best.  It may happen eventually that it will make sense to do this, but right now we can't be sure when or even if it will happen.    We should revisit this periodically as implementation work is done.

---

From: Chuck Lever <[email-masked]>
Date: Sun, 4 Aug 2013 16:01:07 -0400

On Aug 1, 2013, at 4:00 AM, "Noveck, David" <[email-masked]> wrote:

> I don’t think the lack of discussion proves very much.  In fact, there are a number of documents which have also encountered a lack of discussion.    This does not imply that there is  a lack of interest or that work should cease.  You have to look at the reason for the lack of discussion:
>  
> ·         With regard to the migration documents there has also been a lack of discussion.  I think this reflects a general belief that we are on the right track  (we no longer get “That’ll never work” or “Why are doing that?”)  on the part of the working group along with a reluctance on the part of most people to deal with the details of migration issues.  There have been separate off-list discussions with implementers which I take account of as I produce new versions.   The working group can look at the versions and comment on changes but very few people have done so.
>  
> ·         With regard to RFC5664bis, we’ve had very little group discussion.  The reason for that is that very few people are interested in pNFS objects.
>  
> ·         With regard to the multi-domain stuff, there is no current implementation work so it isn’t clear what conclusion to draw from the lack of discussion.
>  
> I’ve talked to Andy and Chuck to see what they think.
>  
> Rather than look at the general subject and the two specific documents as a single unit, I’ve tried to look at the following specific questions.
>  
> ·         Is there general interest in the subject?
>  
> While there is clearly not a lot of interest in the details, I don’t think it is the case that people don’t want this to be addressed at all.  I think it is best to ask the working group what they think.

I'm still coming to an understanding of the scope of Andy's work.  Multi-domain was recently characterized to me as "I'd like to allow a user to provide her Google or Facebook login to authenticate and, if I recognize them, allow access to my shared file system."

I had thought there would be a pre-existing trust relationship between the foreign user's security realm and the realm containing the shared file system.  But it appears there is a broader desire, in the sense that some administrators want to re-use arbitrary well-known authentication authorities to prove who a user is, and then use that proven identity as part of the usual authorization calculus.

IIUC much of this work is being done by other working groups; perhaps we need only monitor their work and provide occasional input?  What part, if any, does the nfsv4 working group need to play, if arbitrary authentication methods can already be used to establish a GSS context which can then be used by RPC?  Or is the nfsv4 WG directly responsible for the GSS parts of the picture?

How much interest is there among the big storage vendors to solve this problem?  It may be interesting to government-funded research projects, but not so much to enterprise customers with high security walls who make up the bulk of our paying customers.  If the focus is mostly on HPC, I think those folks should solve this for themselves (by, for example, participating in the IETF process and providing the resources/energy to make sure it happens).

I think the WG should identify the current stakeholders (which may be different now than when this work was originally chartered); and figure out how much we actually need to be involved.

> ·         What should happen to Andy’s requirements document?
>  
> I’m not sure what the lack of working group discussion means.  If it reflects the fact that nobody has any objections to what Andy has written, then perhaps it means that the document is OK as it is, in which case it should go forward.   It probably makes sense to ask Andy and Chuck how they’d feel about that.

One potential aspect of that work that I would find valuable is an explanation of how the moving parts fit together: idmapping, RPC credentials, ACLs, and so on.

> ·         What should happen regarding the promised best-practices document.
>  
> I think it makes sense to drop this document from the charter, at least for now.  Clearly, until we have a range of implementation practices to choose among, we can’t select a set which is best.  It may happen eventually that it will make sense to do this, but right now we can’t be sure when or even if it will happen.    We should revisit this periodically as implementation work is done.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com