Subject: Re: [nfsv4] Layout Structures Improvement

From: "Anatoly Pinchuk" <[email-masked]>
Date: Tue, 4 Mar 2008 09:57:17 -0800

As you proposed I posted a new thread -
http://www.ietf.org/mail-archive/web/nfsv4/current/msg05511.html.
I have provided reasons for the protocol change, diff against dot-x
file, and link to the original solution of the client file offset
translation problem.

In the follow-up discussion I have addressed all questions and concerns
reviewers had. The discussion confirmed that the change is an
improvement. So far no downsides were found.

Could you clarify on the decision making process? In particular
- What is a deadline for deciding if the improvement will be
incorporated into the protocol?
- Who is going to make that decision?

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

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 04 Mar 2008 19:15:17 -0600

> - Who is going to make that decision?

I have not seen a demonstration of rough consensus for
making the changes -- at this point, the NFSv4.1 I-D will
remain as is.

Spencer

---

From: "Anatoly Pinchuk" <[email-masked]>
Date: Wed, 5 Mar 2008 10:36:01 -0800

What is the definition of "demonstration of rough consensus for making
changes"?
Is such demonstration required for all proposed changes or only this
particular one?

- Anatoly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, March 04, 2008 5:15 PM
To: Anatoly Pinchuk
Cc: [email-masked]
Subject: Re: [nfsv4] Layout Structures Improvement

Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 06 Mar 2008 09:48:54 -0600

> Is such demonstration required for all proposed changes or only this

All changes.

Spencer

---

From: "Anatoly Pinchuk" <[email-masked]>
Date: Fri, 7 Mar 2008 10:47:54 -0800

Since demonstration of rough consensus makes the difference between
being a proposed protocol improvement and an accepted one, it is
important to define such demonstration so that everybody knows it. In
particular, such knowledge would make the decision making process easier
and more transparent.

So, what is the definition of "demonstration of rough consensus for
making changes"?

- Anatoly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 06, 2008 7:49 AM
To: Anatoly Pinchuk
Cc: [email-masked]
Subject: Re: [nfsv4] Layout Structures Improvement

All changes.

Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 07 Mar 2008 12:53:07 -0600

> So, what is the definition of "demonstration of rough consensus for

The definition found here:
http://en.wikipedia.org/wiki/Rough_consensus

is appropriate.

Spencer

---

From: Mike Eisler <[email-masked]>
Date: Fri, 7 Mar 2008 12:07:14 -0800 (PST)

> So, what is the definition of "demonstration of rough consensus for

http://www.ietf.org/tao.html does not define rough consensus but
says:

``The general rule on disputed topics is that the Working Group has to
come to "rough consensus", meaning that a very large majority of those
who care must agree. [...] It is up to the chair to decide when the
Working Group has reached rough consensus.''

In the case of this thread, I have not yet seen a single additional
proponent for making a change.

On the other have, in the callback referring lists thread, until today
I saw a rough consensus for making a protocol change as was
preparing myself for the ugly and risky task of changing the
XDR description of CB_SEQUENCE. Now I see a rough consensus for making
word smithing changes, but leaving the protocol
as is.

---

From: "Anatoly Pinchuk" <[email-masked]>
Date: Mon, 10 Mar 2008 12:08:14 -0700

According to the definition "It is up to the Chair to determine if rough
consensus has been reached". Does our WG have a policy regarding
confirming or denying that rough consensus has been demonstrated? And if
so, what is the policy?

In particular, does a person providing a negative reply to a proposal,
have to justify his/her reason for such reply or a general statement of
disapproval is enough to be considered in the decision making process?
By justification I mean at least one point from the following list
- Proposal does not bring promised features into the protocol
- It is not an improvement
- There are downsides missed in the proposal description
An example of a general statement of disapproval is something like
- There is nothing wrong with a proposal; it is really the protocol
improvement. But it is not good enough.

- Anatoly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, March 07, 2008 10:53 AM
To: Anatoly Pinchuk
Cc: [email-masked]
Subject: Re: [nfsv4] Layout Structures Improvement

is appropriate.

Spencer

---

From: "Anatoly Pinchuk" <[email-masked]>
Date: Mon, 10 Mar 2008 13:55:03 -0700

http://www.ietf.org/tao.html defines many principles to follow. One of
them states

"P23. 
Technical quality and correctness are the primary criteria for reaching
consensus about documents."

So, it is unclear why the validated correct proposal which obviously
brings quality into the protocol can not be incorporated into it.

As for examples of demonstration of rough consensus, I can add one too.
Unless I missed a reply supporting the change, rough consensus on my
proposal
http://www.ietf.org/mail-archive/web/nfsv4/current/msg05507.html has
been demonstrated without single additional proponent for making the
change.

- Anatoly

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 10 Mar 2008 18:31:38 -0500

> brings quality into the protocol can not be incorporated into it.

As you know, it is always seems possible to improve upon
the work we do as engineers.  However, there are tradeoffs with
any change.  A bug fix that appears to be correct, when integrated,
introduces another problem.  What appears to be a well understood
change, upon further use and inspection creates a problem that later
has to be corrected.

It may be that working group members are considering the above
when making a choice about changes to the existing NFSv4.1 I-D.
They may have other motivations but to be honest, I am unaware
of them exactly.  What I do know is there has been no other
demonstrated support for your proposal.  You are at this point
the single proponent.

As working group co-chair, I must therefore conclude that the rough
consensus for the proposal is to not accept the change as you
have presented it.

Spencer

---

From: "Anatoly Pinchuk" <[email-masked]>
Date: Tue, 11 Mar 2008 15:58:36 -0700

> change, upon further use and inspection creates a problem that later
The above justifies not making changes at all, not only one we discuss.
Nevertheless, we do incorporate changes into the protocol. Establishing
and following a policy on making the changes (demonstration of rough
consensus) might make the process transparent and help to understand why
one of them is accepted and another denied.

> demonstrated support for your proposal.  You are at this point
I have already provided an example of the proposal which has been
incorporated into the protocol without demonstrated support. So, lack of
the demonstrated support generally does not prevent us from accepting a
proposal.

- Anatoly

> Sent: Monday, March 10, 2008 4:32 PM
> To: Anatoly Pinchuk
> Cc: NFSv4

---

From: "Mike Eisler" <[email-masked]>
Date: Tue, 11 Mar 2008 17:14:42 -0700 (PDT)

> been demonstrated without single additional proponent for making the

http://www.ietf.org/mail-archive/web/nfsv4/current/msg05507.html is
reproduced below after the bar containing equal (=) signs.
I  believe you are refering to threse snippets of conversation on the
[email-masked] list which are in the message you reference.

Anatoly Pinchuk (AP):

    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."

Mike Eisler (ME):

     One thing I'm not sure of is what error the server should reject
     the request with.

AP:

     The sentence should be removed from the protocol at all,
     since it justifies a server implementation rejecting
     LAYOUTGET which could be processed.

----------------------------------------------

So you are stating that because sentence apparently no
longer appears in the specification without anyone
(apparently) agreeing with you, this is
an example of a decision being made without
a rough consensus.

It turns out that while that sentence is gone from that part
of a text for good reason, because another place in draft-20 the
spec said:

  The loga_minlength field specifies the minimum length of layout the
  server MUST return. If this requirement cannot be met, no layout
  must be returned; the error NFS4ERR_BADLAYOUT will be returned.

So this text both addressed your issue, and it also addressed my issue
which was what error should be returned. However it was in conflict
with the sentence you said should be deleted.

A second however was that the above text was worded very badly, and
a third was that it did not handle the situation of EOF (as pointed out by
Jason Glasgow in
http://www.ietf.org/mail-archive/web/nfsv4/current/msg05548.html ).

In that thread I also noted that it didn't deal with the case of a range
that overlapped multiple striping patterns.

What we ended up with can be seen in the diffs that were posted to
that thread, or look at:

"The loga_minlength field specifies the minimum length of layout the
 server MUST return with two exceptions:

1. The argument loga_iomode was set to LAYOUTIOMODE_READ, and
   loga_offset plus loga_minlength goes
   past the end of the file.

2. The range from loga_offset through loga_offset + loga_minlength -
   1 overlaps two or more striping patterns. In which case,
   logr_layout will contain two or more elements, and the sum of the
   lo_length fields of each element MUST be at least loga_minlength
   unless the first exception also applies.

If this requirement cannot be met, the server MUST NOT return a
layout and the error NFS4ERR_BADLAYOUT MUST be returned.

''

As an editor and document author, I often have to propose text
to address things at least one other person finds (for example,
I wrote the RPCSEC_GSS version 2 i-d based on the proposal of
a single person, and was authorized by the co-chairs to
publish it as a work item of this WG). If it is just
one other person, and I agree with the core of what person finds, then
I see a consensus that I am member of, and I make those changes.
(If the WG chairs want me to act differently, they can tell me.)

But in the case you are claiming as a counter example, three
people, you, Jason, and me, agreed that what was there was wrong,
and so it was changed. So an even wider consensus was reached.

The bar for an over the network change, which is what you've
been demanding for months, during a WG last call,
is much higher though. Every time we've changed the
files layout structures, new errors have been introduced. I
don't want to take that risk right now, so I'm unwilling to state I agree
with your proposal.

And no one else is has so far been willing
to state agreement to your proposal.
So no change.

=========================================================

To: <nfsv4 at ietf.org>
Subject: Re: [nfsv4] File Layout change proposal
From: "Anatoly Pinchuk" <apinchuk at bluearc.com>
Date: Thu, 14 Feb 2008 13:19:34 -0800

--------------------------------------------------------------------------------
The sentence should be removed from the protocol at all, since it
justifies a server implementation rejecting LAYOUTGET which could be
processed.

- Anatoly

To: nfsv4 at ietf.org
Subject: Re: [nfsv4] File Layout change proposal
From: Mike Eisler <email2mre-ietf at yahoo.com>
Date: Thu, 14 Feb 2008 12:03:44 -0800 (PST)

--- Anatoly Pinchuk <apinchuk at bluearc.com> 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.
>
> "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."

One thing I'm not sure of is what error the server should reject
the request with.

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 11 Mar 2008 21:21:22 -0400

> The above justifies not making changes at all, not only one 

It might be so used, but as you note below, we have made changes to the
protocol.  What Spencer is indicating is that you have to use judgment
about what changes are to be made.  We don't use a single person's
judgment but use the rough consensus model.

I know it is hard, but sometimes the consensus will differ from what you
are sure is the better choice.  In that situation, after trying to
convince people that you right, you can sometimes find yourself not
making any headway.  Unless you have some new argument, I don't see that
changing.

I think you just have to accept the fact that you haven't convinced
anyone of your position, let alone even approaching a rouch consensus in
your favor.  

-----Original Message-----
From: Anatoly Pinchuk [mailto:[email-masked]] 
Sent: Tuesday, March 11, 2008 6:59 PM
To: [email-masked]
Cc: NFSv4
Subject: Re: [nfsv4] Layout Structures Improvement

> As you know, it is always seems possible to improve upon the work we 
> do as engineers.  However, there are tradeoffs with any change.  A bug

> fix that appears to be correct, when integrated, introduces another 
> problem.  What appears to be a well understood change, upon further 
> use and inspection creates a problem that later has to be corrected.

> It may be that working group members are considering the above when 
> making a choice about changes to the existing NFSv4.1 I-D.
> They may have other motivations but to be honest, I am unaware of them

> exactly.  What I do know is there has been no other demonstrated 
> support for your proposal.  You are at this point the single 
> proponent.

- Anatoly

> > Technical quality and correctness are the primary criteria for 
> > reaching consensus about documents."
> >

> As you know, it is always seems possible to improve upon the work we 
> do as engineers.  However, there are tradeoffs with any change.  A bug

> fix that appears to be correct, when integrated, introduces another 
> problem.  What appears to be a well understood change, upon further 
> use and inspection creates a problem that later has to be corrected.
> 
> It may be that working group members are considering the above when 
> making a choice about changes to the existing NFSv4.1 I-D.
> They may have other motivations but to be honest, I am unaware of them

> exactly.  What I do know is there has been no other demonstrated 
> support for your proposal.  You are at this point the single 
> proponent.
> 
> consensus for the proposal is to not accept the change as you have 
> presented it.
> 
> Spencer
>

---

From: "Anatoly Pinchuk" <[email-masked]>
Date: Wed, 12 Mar 2008 16:49:02 -0700

> making any headway.  Unless you have some new argument, I don't see
that
Taking into consideration the complexity of the protocol and task
(simplifying client file offset translation solution on behalf of people
met in Vancouver), I did not expect the process to be easy. On the other
hand, it is probably more difficult to debate a proposal which brings
quantifiable improvements into the protocol. I already wrote that it is
up to you to agree or disagree with the proposal. My job is to find a
problem, figure out the solution, bring it to the WG attention and
follow-up on the discussion. In particular, that includes debating
justifications for not accepting the proposal I found incorrect. I think
there is obvious progress in that direction. Unless you have new
concerns, I have addressed all ones you had.

> anyone of your position, let alone even approaching a rouch consensus
in
The fact is that I have not convinced several people which stated it
clearly. As for anyone, it is an opinion.

- Anatoly

> From: Noveck, Dave [mailto:[email-masked]]
> Sent: Tuesday, March 11, 2008 6:21 PM
> Subject: RE: [nfsv4] Layout Structures Improvement
> 
> > > http://www.ietf.org/tao.html defines many principles to follow.
One
> of