Subject: Re: [nfsv4] File Layout change proposal

From: "Anatoly Pinchuk" <[email-masked]>
Date: Thu, 14 Feb 2008 11:40:25 -0800

The posting I did is part of a review process to guarantee high quality
of the protocol. Its purpose is to bring to the working group attention
that there are many inconsistencies in common and file layout
definitions which complicate the protocol. It looks like we all agree on
that. Another part of it is to remind that we have simple solution of
the problem proposed back in December.

A conclusion on if the layout inconsistencies we have are significant
and broke the protocol features is subjective. I think that current
layout definitions breaks (common layout) - (particular layout) layering
and unnecessary complicates the protocol/implementation. Since there is
simple solution, the definitions should be changed. Apparently, it is up
to the editors to decide if there is enough time to fix the problem. I
consider my part of the job is done.

Also it is not obvious if a protocol feature is broken or burdens an
implementation significantly. Let us take an example from section
18.43.3.

"The lo_length field in each element of logr_layout SHOULD be at least
as long as loga_minlength or the server SHOULD reject the request."

Because it says SHOULD the server can just ignore the above. On the
other hand it sounds like recommendation and some server implementations
may actually follow it. That will result in rejection of the requests
which could be successfully processed (if the loga_minlength is greater
than length of a sub-layout element of logr_layout). One can decide if
such protocol definition breaks a feature or burdens an implementation
significantly. But it definitely brings down quality of the protocol and
complicates the implementation. Other layouts inconsistencies are
similar in nature.

I feel that a congregation of industry leaders and experts should not
produce work that obviously compromises on quality.

- Anatoly

On Feb 14, 2008, at 2:29 AM, Anatoly Pinchuk wrote:

> The solution solves the problem we had - inability to translate the 

> client offset in case of FILE LAYOUT. It resolves the problem without 

> affecting different type of layouts and other complications I pointed 

> out. As for the downside you mentioned, the draft defines striping 

> only for file layouts. So far, the striping does not belong to common 

> layout.

> If you want to define striping for all possible layout types, it 

> should be reflected in the draft.

> The solution brings clarity into common and file layouts. It is simple

> (one page to describe) and removes unnecessary repetitions. All of the

> above makes the protocol easier to understand/implement and shorten 

> result of LAYOUTGET. Therefore, the solution provides a step towards 

> the optimal spec stabilization.

Nothing in what you have mentioned above or elsewhere (to my knowledge)
states that the current definition is flawed in a way that can not be
implemented or burdens an implementation significantly.

As with all things engineering related, there is almost always a better
way to accomplish a task.  However, as was stated quite some time ago,
unless a protocol feature is demonstrably broken, we will not be
changing it at this point.  We have 560+ pages of protocol specification
to ensure are of reasonable quality.

Let's focus on getting the whole reviewed and corrected.

Spencer

 

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

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 14 Feb 2008 13:55:26 -0600

On Feb 14, 2008, at 1:40 PM, Anatoly Pinchuk wrote:

> The posting I did is part of a review process to guarantee high  
> quality of the protocol. Its purpose is to bring to the working  
> group attention that there are many inconsistencies in common and  
> file layout definitions which complicate the protocol. It looks  
> like we all agree on that. Another part of it is to remind that we  
> have simple solution of the problem proposed back in December.

2.5 months in relation to how much has changed in this
specific area is a very long time.  I had assumed that
given your silence on this issue to this point was
an indication of consensus on the discussions and email
that occurred in December and the contents of draft-18.
That is now clearly not the case.

> A conclusion on if the layout inconsistencies we have are  
> significant and broke the protocol features is subjective. I think  
> that current layout definitions breaks (common layout) –  
> (particular layout) layering and unnecessary complicates the  
> protocol/implementation. Since there is simple solution, the  
> definitions should be changed. Apparently, it is up to the editors  
> to decide if there is enough time to fix the problem. I consider my  
> part of the job is done.

With my editor hat on for a moment, our job is to
work the internet draft to closure without overly
burdening the feedback and comments unduly.  If
rough consensus existed for modifications then it
would be considered appropriately.  At this point,
I have seen but one advocate (you) for the need
for change.  If you feel that the something is broken
then it is your burden to convince others within
the working group of your position and the need
for change.  All I have seen is a reference to a
posting from December without any discussion.

>  Also it is not obvious if a protocol feature is broken or burdens  
> an implementation significantly. Let us take an example from  
> section 18.43.3.
> “The lo_length field in each element of logr_layout SHOULD be at  
> least as long as loga_minlength or the server SHOULD reject the  
> request.”
> other hand it sounds like recommendation and some server  
> implementations may actually follow it. That will result in  
> rejection of the requests which could be successfully processed (if  
> the loga_minlength is greater than length of a sub-layout element  
> of logr_layout).

If you have suggestions for changes to the wording that
will lead to a better protocol definition and higher
probability of interoperability, then please make them.

In this particular case, the definition of SHOULD requires
the server to behave in the way stated unless it is a
significant burden on the server not to do so.  If you can
make a case for a change to MUST, then again, please do so.

> One can decide if such protocol definition breaks a feature or  
> burdens an implementation significantly. But it definitely brings  
> down quality of the protocol and complicates the implementation.  
> Other layouts inconsistencies are similar in nature.
>
> I feel that a congregation of industry leaders and experts should  
> not produce work that obviously compromises on quality.

As mentioned above, if you feel this way then it is your burden
to convince enough of the working group to become vocal in
support of your position such that it demonstrates
rough consensus for a change.  At this point, we have
rough consensus for the I-D the way it is.

Spencer

> Nothing in what you have mentioned above or elsewhere (to my  
> knowledge) states that the current definition is flawed in a way  
> that can not be implemented or burdens an implementation  
> significantly.
>
> As with all things engineering related, there is almost always a  
> better way to accomplish a task.  However, as was stated quite some  
> time ago, unless a protocol feature is demonstrably broken, we will  
> not be changing it at this point.  We have 560+ pages of protocol  
> specification to ensure are of reasonable quality.
>

---

From: Mike Eisler <[email-masked]>
Date: Thu, 14 Feb 2008 12:03:44 -0800 (PST)

--- Anatoly Pinchuk <[email-masked]> wrote:

>  Apparently, it is
> up
> to the editors to decide if there is enough time to fix the problem.

It's up to the working group to decide if there is problem, if so, is
it
worth fixing, and if so, what we should do.

I haven't seen any other contributor to this working group support
your proposal.

> Let us take an example from section
> 18.43.3.
> 

One thing I'm not sure of is what error the server should reject
the request with.
_______________________________________________
nfsv4 mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/nfsv4