Subject: RE: Unlimited length opaques (was Re: Spec-related discussions at the Bake-off)

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 3 Nov 2000 07:57:08 -0800

> On Thu, Noveck, Dave wrote:
>
> > > > Asking customers to tune various variables when they get 
> > > > XDR errors, is job security for somebody, but it doesn't
> > > > really make sense.
> > > 
> > > So, what do NFS/TCP implementations do today when presented with a
> > > record marking header that is say, one gigabyte? Surely they break the
> > > connection?
> > 
> > Exactly.  The value is wrong.  What you do not do is adjust some
> > value to make this valid.  I have no objection in giving errors to those
> > who generate invalid requests (and disconecting those when the nature
> > of things make resyncing impossible).  What I object is to create a
> > class of requests that may or may not be valid depending on somebody's
> > setting of an option.  We should agree on appropriate limits.  If we
> > can't have those in the spec, then they should be in the implementation
> > RFC.
> 
> Interesting discussion.  It is hard for me to guess about what the
> appropriate limits would be for some of the opaque<> or <> types in
> the protocol.  For example, what is the appropriate limit for the
> "data" field of WRITE4args?  What will it be 5 or 10 years from now?
> How about "attrlist4"?  If it contains an "fattr4_acl" attribute, what
> is the limit on the number of "nfsace4" entries for that attribute.

It's a good thing you don't have to guess what it will be 5 or 10 years
from now.  We have minor versioning, I am happy to say.

For write, there is a mechanism (maxwrite) for the client to find out 
the limit and use it.  I think that is fine.  Given the maxwrite
attribute, every server can pick his own limit.

For ACL's, I think a good case can be made that no limit should be
imposed (other than those implied by the underlying transport).
If that is the case however, then that should be what people 
implement.  In response to some unlimited values, people were
saying that the server can just arbitrarily pick a limit and
give you an XDR error.  This would not be good.  If you decide
that something is unlimited then clients can depend on it being
unlimited and if they do, servers should not go back on that.

In our bakeoff discussions we were thinking about thing like
the client opaque string and the lockowner.  Nobody needs these
to be 32K. It seems that peoeple are going to limit these somehow.  
Hunningbird might choose a limti of 256, UMich might choose 512,
I might choose 1K, Sun might choose 2K.  These are all fine limits
and arguments could be made for each of them.  The problem is that
they are *different* and the client writer has know way of knowing
what he should generate.  If every server picks the same value
and we then tell the clients what it is, things are lots simpler. 

> I agree that we should make suggestions in the implementation RFC but
> to dictate some of these in the protocol specification seems short
> sighted.

If there are values there and everybody uses those limits then I don't 
really care about exactly what modal auxilaries are used.  

> If there is a denial of service concern, NFSv4 does provide for
> authentication so that the source can be identified and actually
> denied access to the server's resources if it continues to be a
> problem.

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 3 Nov 2000 14:45:33 -0600

> from now.  We have minor versioning, I am happy to say.

The ground rules for minor versioning precludes changing the structure
of existing arguments and results.  Therefore, if there is a
definition in the protocol that limiting, then another operation will
need to be added to change that limit.

> attribute, every server can pick his own limit.

That's fine.

> imposed (other than those implied by the underlying transport).

or those imposed by the operating environment.

> unlimited and if they do, servers should not go back on that.

We have unlimited lengths for pathname4 and component4 and operating
environments will have specific limits.  Of course, in these cases,
the server will hopefully return an error of NFS4ERR_NAMETOOLONG.

> and we then tell the clients what it is, things are lots simpler. 

Liberal in what you accept but conservative in what you send.
The implementation RFC should strongly suggest that the client
not overuse the various opaque<>s.

> really care about exactly what modal auxilaries are used.  

The implementation RFC can make suggestions but will not and can
not impose hard limits because it will be an informational RFC.

I will put this on the list of things for the implementation RFC.

-- 

- Spencer -