Subject: RE: [nfsv4] issue 40: pNFS: DS and MDS with different security mechanisms in use

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 12 Jul 2006 14:22:26 -0400

That's one vote for 1.5).  :-)

If you don't have secinfo_no_name then the client has to assume 
that the set of security flavors is the same as on the MDS, and
so the DS has to obey the constraint mentioned in 2).

Everybody's implementation is different but I'm having trouble
imaging a situation in which it simpler to implement a protocol
feature between the MDS and DS so that their security flavors
match for each export, than to implement secinfo_no_name to
tell the client what the flavor list is.

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]] 
Sent: Wednesday, July 12, 2006 10:46 AM
To: Noveck, Dave
Cc: William A.(Andy) Adamson; [email-masked]; [email-masked]
Subject: Re: [nfsv4] issue 40: pNFS: DS and MDS with different security
mechanisms in use

On Wed, Jul 12, 2006 at 10:16:11AM -0400, Noveck, Dave wrote:
> And it doesn't seem that likely that further discussion will get us to

> agreement.
> 
> So it seems we have two options here.  
> 
>     1) Mike's proposal.
> 
>     2) A rule that says that the DS has to accept the security
>        flavors that the MDS accepts and no others, mod some
>        short synchronization delay when the set is changing,
>        and that it is the job of implementations including any 
>        storage management protocol to make it so.
> 
> My opinion is that 1) is clearly superior to 2), but that 2) is 
> workable, if that's where the working group consensus winds up.
> 
> We know where Andy and I stand on this and I presume Mike also favors 
> his own proposal. What about the rest of the working group?

I don't care, but.... Could secinfo_no_name made optional to implement
on the data servers?

Mixed-flavor support is likely to be a low priority, so secinfo will be
unnecessary on most data servers.  OK, so it's not that hard to
implement, but in the interests of keeping data servers as simple as
possible it'd seem best not to require mandatory features of them unless
it's strictly necessary.

--b.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 12 Jul 2006 14:41:10 -0400

> tell the client what the flavor list is.

The two things (implementing the metadata-data server protocol, and
implementing secinfo_no_name on the DS's) seem independent to me.

There's a number of ways you could ensure the security flavors all
agree.  Some of them (like just providing administrative tools that
configure the nodes a certain way) may be more fragile than others (like
writing a protocol that ensures everything stays in sync), but that's up
to the implementation.

--b.

---

From: Mike Eisler <[email-masked]>
Date: Wed, 12 Jul 2006 11:51:48 -0700 (PDT)

> agree.  Some of them (like just providing administrative tools that

If we mandate they all agree, then secinfo_no_name is off the
list operations the DS MUST support. If don't mandate they agree, then
secinfo_no_name is back on the list
of operations the DS MUST support.

Looking at it a different way, if clients MUST NOT send secinfo_no_name
to a DS, then the secinfo for a DS MUST be the same as the MDS.
On the other hand if clients MAY send secinfo_no_name, then
this opens the door to the secinfo for a file being different
on the MDS and DS.

> writing a protocol that ensures everything stays in sync), but that's

I think people who are implementing pNFS outside of a formal cluster
environment and expect to synchronize DS and MDS configuration are
really underestimating the difficulties they are in for.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 12 Jul 2006 15:03:50 -0400

On Wed, Jul 12, 2006 at 11:51:48AM -0700, Mike Eisler wrote:
> to a DS

Why does making secinfo_no_name support on the data server optional mean
that clients can't try to call secinfo_no_name?  I thought that was what
NFS4ERR_NOTSUPP was for.

--b.

---

From: Mike Eisler <[email-masked]>
Date: Wed, 12 Jul 2006 12:12:34 -0700 (PDT)

--- "J. Bruce Fields" <[email-masked]> wrote:

> that clients can't try to call secinfo_no_name?  I thought that was

It doesn't, but why we'd want to have such ambiguity is  beyond my
comphrension. I was taking issue with your assertion that 
secinfo_no_name has nothing to do with Issue 40.
> what