Subject: Re: [nfsv4] [FedFS] Meeting Minutes, 3/18/2010

From: Nicolas Williams <[email-masked]>
Date: Fri, 19 Mar 2010 18:57:05 -0500

On Fri, Mar 19, 2010 at 06:14:43PM -0400, Matt W. Benjamin wrote:
> I apologize for asking this dumb question.  Why is it attractive to
> place attributes into the RootDSE?  Coming to this with random LDAP
> application integration experiences, it seems more typical that things
> would be designed to work from any position in the DIT?

That was my initial position as well.  The original proposal had a
hard-coded base DN for the NSDB objects and I objected.  Subsequently
we've had one implementor (us; note though that I don't work on our
implementation) complain that having to store a base DN in junctions
made them too large.  There are ways for that implementor to deal with
that problem, but the bottom line is that it adds significant
complications, and they likely won't be the only implementor so
affected.

Nico
--

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 20 Mar 2010 07:30:25 -0500

Sent from my iPhone

> complications, and they likely won't be the only implementor so

And experience has shown us that things which are difficult for even  
one vendor to deliver, end up not being implemented as a whole.

NFSv4.0  -- Libkey/spkm?
NFSv4.1  -- Ssv?

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

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 21 Mar 2010 14:07:37 -0500

> one vendor to deliver, end up not being implemented as a whole.

SPKM had a number of problems and was simply never going to become
popular.  Kerberos + PKINIT gets you much of what of the way to having a
PKI be usable in NFS, therefore there's little incentive to bother with
SPKM.  I don't see SPKM as a good example.  As for SSV, it's too soon to
tell, no?

Nico
--

---

From: Tom Haynes <[email-masked]>
Date: Sun, 21 Mar 2010 14:07:50 -0700

> SPKM.  I don't see SPKM as a good example.  As for SSV, it's too soon to

Please understand I'm not being critical of SSV as a technology. Your 
observation is key,
i.e., why do we have such a large lead time between the paper protocol 
and either a
prototype or final implementation.

My point is that we have a lot of mandatory to implement features in 
5661 (NFSv4.1). We
don't have any coordination of effort (i.e., a prioritization of 
features) and as such the lack
of activity can be construed as the community voting on whether or not 
they are going
to adopt a feature.

The big problem with this is if it takes a while for a mandatory feature 
to be implemented
by more than one vendor and the draft has finalized, how do we 
incorporate the
actual protocol with the paper protocol?

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 21 Mar 2010 18:02:57 -0500

On Sun, Mar 21, 2010 at 02:07:50PM -0700, Tom Haynes wrote:
> of activity can be construed as the community voting on whether or
> not they are going
> to adopt a feature.
> 
> The big problem with this is if it takes a while for a mandatory
> feature to be implemented

I don't understand how your point relates to this discussion.  Are you
saying that there's something about the NSDB thing we're talking about
that's hard to implement beyond what Rob has mentioned?

---

From: Tom Haynes <[email-masked]>
Date: Mon, 22 Mar 2010 10:27:59 -0700

> that's hard to implement beyond what Rob has mentioned?

No, my point is that we tend to think of RFCs as finalized documents  
and not as being living. As such, we are concerned with getting it  
right the first time. I.e., do not add something that the implementors  
are going to vote with their feet to not implement.

That was the original argument I was making. What is now interesting  
is why  are we in this mindset that RFCs stop when they are published.  
It certainly is not the message I'm getting at IETF and not the  
original intent behind the minor version plan.

You pointed out somewhere last week that you consider NFSv3 and NFSv4  
to be different protocols which happen to share a name.

I'm starting to believe that the same can be said of NFSv4.0 and  
NFSv4.1. They are both huge and NFSv4.1 stands in the way of any  
protocol improvements being made to NFSv4.0.

I.e., to change the size of a stateid in NFSv4.0, I can only do that  
in NFSv4.2 and I *have* to implement 4.1 along the way.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 22 Mar 2010 12:33:26 -0500

On Mon, Mar 22, 2010 at 10:27:59AM -0700, Tom Haynes wrote:
> You pointed out somewhere last week that you consider NFSv3 and
> NFSv4 to be different protocols which happen to share a name.

And port number (and program number).  But they are radically different,
yes.

> protocol improvements being made to NFSv4.0.

NFSv4.0 and v4.1 are NOT radically different in the senses that matter
to the ADMIN protocol (specifically their notions of paths, pseudo-root,
codesets and normalization forms are substantially the same).

Nico
--