Subject: RE: setclientid

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 16 Jul 2002 06:59:20 -0700

> > > I have a general feeling of that SETCLIENTID is more broken than it has to
> > > be. 
> > 
> > Not clear here if you mean the definition in the spec or the UMich 
> > implementation (or both).
> 
> The implementation, primarily. 

> > The basic idea of SETCLIENTID is that the client somehow picks a 
> > unique value of what the spec calls an nfs_client_id4 (and what I
> > think should be called client_name but is normally referred to as
> > that-client-id-that-the-client-specifies-not-the-64-bit-thing-but-
> > the-other-one).  When the values are unique everything works fine,
> > but there has to be provision for detecting misconfiguration when
> > they are not.  In normal environments if clients are implemented
> > to throw lots of uniquifying stuff into the client-name, then this
> > won't happen, but it is conceivable that it will.  
> > 
> > I don't see that an ideal solution to this problem is possible.  You
> > have to ultimately depend on the clients getting this one thing right.
> 
> Yes, you are right. 

> > > Doesn't this mean that if the client is changing IP and then
> > > does a new SETCLIENTID, then the server will respond with
> > > NFS4ERR_CLID_INUSE?
> > 
> > Yes it does mean that.  The question is whether that is a requirement.
> > I think we need to decide if it is.

> I would prefer that this is not a requirement.

I meant whether changing the IP address on a running server was a requirement,
but I think you interpreted it as the reverse, so I'll assume that I can 
invert your answer.

> If it is, how are you supposed to be able to change IP at all on your 
> client? Is the client supposed to wait for the server release of clientid 
> (described in section 8.1.2)? This may, as I understand it, take a long 
> time or not happen at all. 

If a server checked for the same IP address, it would just about have to
give you some administrative command to allow a client to be cleared out
manually, to allow this to happen.

> Btw, is it a good idea to use the FQDN hostname as nfs_client_id.id?

I think that's reasonable, although I'd probably add something like
the machine serial number for added protection against errors.

> > > Is it really necessary for the server to store the client adress as a part 
> > > of the client information? Too me, it seems sufficient that the server 
> > > stores nfs_client_id and principal. CLID_INUSE could be reserved only for 
> > > the case where the principal does not match. Or have I forgotten 
> > > something?
> > 
> > I think your solution doesn't account for the case of auth-sys, which
> > while deprecated, will continue to exist in some environments.  In those
> > environments, there won't be any real principal to match and so there 
> > is a choice of having no check for misconfiguration (multiple clients
> > with the same client id), if you don't check on IP address.

> Would it be possible to use the machinename from auth-sys? This seems like 
> a better strategi than the transport IP, since it would at least allow 
> changing IP. 

I think that's a reasonable approach.

> Anyway, this is maybe 4.1 stuff.

I don't think so.  I think of these things as implementation choices so
maybe they would be addressed in an implementation guide, if that idea
ever gets resurrected. 

> > > Btw, if the client sends a CLIENTID with the same nfs_client_id but a 
> > > different cb_client4, should the server then update the callback 
> > > information? I suppose this will be necessary if the client wants to 
> > > change IP without having to release all state. 
> > 
> > This is Issue 175 on the issues list. 
> > 
> > There are a number of inter-related (in some cases potentially inter-
> > related) issues that relate to SETCLIENTID.  I'm going through the issues
> > list now as a kind of triage (although I have more than three categories)
> > as part helping along the process of getting to a completed spec by early 
> > August.  One of the categories is items that require some discussion within
> > the group to determine the proper constraints on the spec choices.  The
> > SETCLIENTID stuff seems to fall (or you have just pushed it) into that
> > category.
>
> Ok. I also think that getting the spec out is top prio.

Getting the spec out "is not the most important thing, it's the *only* 
thing". :-)

> Btw, is anyone maintaining a 4.1 TODO/wishlist? I can do that, otherwise. 

Not that I know of.

> I have some things to put on the list already :-)

After going through our issues list, I have two suggestions for your new
list:

     Each item have an associated paragraph that explains what the item
     really is and why it is worth doing.  Even if it is obvious now, it
     might not be when we get around to actually planning a v4.1.

     If the list ever gets more than 25 items, we have a process to kick
     things off to make room for new items.  It can go onto some other list
     but if something doesn't have enough support to stay among the top 
     25 ideas for v4.1, there's just no point in it taking up space on 
     the list, and making it (i.e. the list) to unwieldly to actually
     use.

---

From: Peter Astrand <[email-masked]>
Date: Fri, 19 Jul 2002 00:24:00 +0200 (CEST)

>      the list, and making it (i.e. the list) to unwieldly to actually

My suggestion is to use Bugzilla. It provides an easy way to add comments 
and information. It is also easy to use priorities, so if the list gets 
longer than 25 items, we can just lower the priority for some "bugs". 

Any objections to use Bugzilla? Otherwise, I will create an "NFS v4.1 
wishlist project", using Bugzilla. 

-- 
/Peter Åstrand <[email-masked]>