Subject: [nfsv4] DN contribution to IETF87 meta-discussion

From: "Noveck, David" <[email-masked]>
Date: Tue, 7 May 2013 15:52:38 -0400

As to agenda items I might present/lead:

*         I'd like to give a talk about our versioning model and our options for changing it (in a positive way I hope).   This will touch on the issues that have previously been discussed under the 'microversioning' rubric, but the focus will be different.   Instead of only focusing on better ways to patch our mistakes , I'd like us to look at options to specify experimental versions to enable us to have working code earlier in the process, so finding problems earlier and avoiding work specifying features that never get significant implementation experience.
If there is someone of the microversioning persuasion that wants to participate, perhaps we can collaborate on a joint presentation.

*         I'm willing to talk about the migration stuff but I think the priority of that for meeting time is low.  I can spend a few minutes exhorting people to carefully read the document draft, but I think we need people doing implementations, to really find and document problems.  As that happens, we can discuss the issues found as part of the getting-to-working-code process.  My feeling is that discussion on the working group list is the right forum for that.

As to the ones I want to hear, assuming someone is willing to present, the following is in decreasing order of my level of interest but everything on it is something I want us to be able to talk about.

*         I'd like to hear a discussion of the end-to-end integrity work that moves forward the process of defining the work to be done.

*         I'd like to hear something about the son-of-pNFS-object work we've been promised, repeatedly

*         I'd  like to discuss the metadata layout stuff with a view to deciding what level of working group effort is appropriate.    My preference would be to see this as part of consideration of how metadata locking and distribution should be working.  For example, we have directory delegations defined but not implemented very much.  I'd hate to see us looking at all these things as separate "features" without architectural coherence.

I think all of these are areas where face-to-face discussion time is of value.  Given that we have got lots of stuff done and headed IESG-ward, I think of all of these things as part of a  "what's next for NFSv4?"  investigation that I'd hope would  stimulate discussion outside of the formal meeting.

---

From: Chuck Lever <[email-masked]>
Date: Tue, 7 May 2013 20:54:38 -0400

On May 7, 2013, at 3:52 PM, "Noveck, David" <[email-masked]> wrote:

> ·         I’d like to give a talk about our versioning model and our options for changing it (in a positive way I hope).   This will touch on the issues that have previously been discussed under the ‘microversioning’ rubric, but the focus will be different.   Instead of only focusing on better ways to patch our mistakes , I’d like us to look at options to specify experimental versions to enable us to have working code earlier in the process, so finding problems earlier and avoiding work specifying features that never get significant implementation experience.
> ·         I’m willing to talk about the migration stuff but I think the priority of that for meeting time is low.  I can spend a few minutes exhorting people to carefully read the document draft, but I think we need people doing implementations, to really find and document problems.  As that happens, we can discuss the issues found as part of the getting-to-working-code process.  My feeling is that discussion on the working group list is the right forum for that.
>  
> ·         I’d like to hear a discussion of the end-to-end integrity work that moves forward the process of defining the work to be done.

I am prepared to help lead the end-to-end data integrity discussion.  I can also discuss ongoing FedFS document work, including possibly a bug fix release for the ADMIN protocol.

> ·         I’d like to hear something about the son-of-pNFS-object work we’ve been promised, repeatedly
> ·         I’d  like to discuss the metadata layout stuff with a view to deciding what level of working group effort is appropriate.    My preference would be to see this as part of consideration of how metadata locking and distribution should be working.  For example, we have directory delegations defined but not implemented very much.  I’d hate to see us looking at all these things as separate “features” without architectural coherence.   
>  
> I think all of these are areas where face-to-face discussion time is of value.  Given that we have got lots of stuff done and headed IESG-ward, I think of all of these things as part of a  ”what’s next for NFSv4?”  investigation that I’d hope would  stimulate discussion outside of the formal meeting.
>  
>  
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 8 May 2013 05:17:01 +0000

On May 7, 2013, at 12:52 PM, "Noveck, David" <[email-masked]<mailto:[email-masked]>> wrote:

As to agenda items I might present/lead:
•         I’d like to give a talk about our versioning model and our options for changing it (in a positive way I hope).   This will touch on the issues that have previously been discussed under the ‘microversioning’ rubric, but the focus will be different.   Instead of only focusing on better ways to patch our mistakes , I’d like us to look at options to specify experimental versions to enable us to have working code earlier in the process, so finding problems earlier and avoiding work specifying features that never get significant implementation experience.

I'd like to have that discussion as well.

I'd specifically like to hear more on your ideas of experimental versions.

Of course, I might just be happy with stating that odd number releases are experimental and even number ones are stable. I think I've heard of a OS or two which take this approach.

In any event, this is the first I've heard of the idea of experimental versions, can we hash it out here first?

If there is someone of the microversioning persuasion that wants to participate, perhaps we can collaborate on a joint presentation.
•         I’m willing to talk about the migration stuff but I think the priority of that for meeting time is low.  I can spend a few minutes exhorting people to carefully read the document draft, but I think we need people doing implementations, to really find and document problems.  As that happens, we can discuss the issues found as part of the getting-to-working-code process.  My feeling is that discussion on the working group list is the right forum for that.

As to the ones I want to hear, assuming someone is willing to present, the following is in decreasing order of my level of interest but everything on it is something I want us to be able to talk about.
•         I’d like to hear a discussion of the end-to-end integrity work that moves forward the process of defining the work to be done.
•         I’d like to hear something about the son-of-pNFS-object work we’ve been promised, repeatedly

And I'd like to hear something about it as well. And as Europe should be an easier venue for the author, that should be a consideration.

•         I’d  like to discuss the metadata layout stuff with a view to deciding what level of working group effort is appropriate.    My preference would be to see this as part of consideration of how metadata locking and distribution should be working.  For example, we have directory delegations defined but not implemented very much.  I’d hate to see us looking at all these things as separate “features” without architectural coherence.

I'd also like to see the WG decide to really tackle RPCSEC_GSSv3. But that needs to happen on the WG alias and not in person. Unless we are all prepared to sit down for 3 hours every morning and churn through it in Berlin.

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 May 2013 02:04:57 -0500

On Tue, May 7, 2013 at 2:52 PM, Noveck, David <[email-masked]> wrote:
> ·         I’d like to give a talk about our versioning model and our options
> for changing it (in a positive way I hope).   This will touch on the issues
> that have previously been discussed under the ‘microversioning’ rubric, but
> the focus will be different.   Instead of only focusing on better ways to
> patch our mistakes , I’d like us to look at options to specify experimental
> versions to enable us to have working code earlier in the process, so
> finding problems earlier and avoiding work specifying features that never
> get significant implementation experience.
>
> If there is someone of the microversioning persuasion that wants to
> participate, perhaps we can collaborate on a joint presentation.

What is microversioning?  A la carte negotiation?  Or literally
major.minor.micro version numbering?

The latter can't work any better than minor versioning has worked to
date.  It's not worth it.

Your only choices are long, slow trains, or a la carte negotiation of
extensions.  If I missed some third choice I'm all ears.

Remind me: why not use a la carte negotiation?  It's pretty much what
we do for just about all other Internet protocols.  I know it's been
sort of anathema here, but, why?  I've never understood it.  I'm not
sure it's ever been explained to me.  Not having a la carte extensions
negotiation smells.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 May 2013 02:16:38 -0500

I should add that experimental versions don't work, especially not if
deployed instances of experimental versions must not meet deployed
instances of the standard version.  The only thing that works is a la
carte negotiation.

We've had horror stories with version negotiation in other protocols,
and, really, the only thing that's worked is...  You know the deal.

TLS?  Each minor version change is a PITA and takes on the order of a
decade to deploy.  New TLS ciphers?  A dime a dozen.  That's an
existence proof right there that a la carte works better than minor
versioning.

NFS has only done major and minor versioning; each has taken on the
order of... a decade.  An existence proof that minor versioning..
takes forever.

SSH has done major and minor versioning, and a la carte versioning.
No new versions have been needed since 2.0, but plenty of extensions
have been added since.  That's an existence proof right there that a
la carte works better than minor versioning.

Of course, what's the goal?  If the goal is feature cycles between 5
and 10 years, well, stick to minor versioning.

Nico
--

---

From: Benny Halevy <[email-masked]>
Date: Wed, 08 May 2013 13:17:14 +0300

On 2013-05-08 08:17, Haynes, Tom wrote:
> 
> On May 7, 2013, at 12:52 PM, "Noveck, David" <[email-masked] <mailto:[email-masked]>> wrote:
> 

True.  Please sign me up on this one.

Benny

---

From: "Matt W. Benjamin" <[email-masked]>
Date: Wed, 8 May 2013 10:40:47 -0400 (EDT)

Hi,

----- "Tom Haynes" <[email-masked]> wrote:
> 
> I'd also like to see the WG decide to really tackle RPCSEC_GSSv3. But
> that needs to happen on the WG alias and not in person. Unless we are
> all prepared to sit down for 3 hours every morning and churn through
> it in Berlin.

Very much so.  If 3h sessions are what it's going to take, and folks are going to
be present, then maybe that should happen.

-- 
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel.  734-761-4689 
fax.  734-769-8938 
cel.  734-216-5309

---

From: Chuck Lever <[email-masked]>
Date: Wed, 8 May 2013 10:54:48 -0400

> and 10 years, well, stick to minor versioning.

One goal is to provide an avenue for fixing protocol issues in minor version n that require XDR modifications, where minor version n+1 already exists.  In other words, issues that cannot be successfully addressed by changes in convention or implementation.

Another goal is to provide an avenue for vendors to extend NFS with proprietary features without compromising interoperation with implementations that do not have the feature (a la carte would be one way to accomplish this, but more detail would need to be fleshed out).

There are already RFCs on protocol extensibility that cover the pitfalls well:  RFC 4775 and 6709 are two that come immediately to mind, and neither is impossibly long.

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 May 2013 10:03:18 -0500

> One goal is to provide an avenue for fixing protocol issues in minor version n that require XDR modifications, where minor version n+1 already exists.  In other words, issues that cannot be success…

A la carte nego works for this.

> Another goal is to provide an avenue for vendors to extend NFS with proprietary features without compromising interoperation with implementations that do not have the feature (a la carte would be o…

Ditto.

Nico
--

---

From: "Erasani, Pranoop" <[email-masked]>
Date: Wed, 8 May 2013 15:52:37 +0000

Well said. I'm not even sure what problem experimental versions solve. There is an inherent assumption that experimental versions have enough life to give an idea of all the problems with the spec and thus we'd have enough time to resolve in non-experimental versions.

Also, Let's first state the specific advantages, before we think a la carte is a better option. Both come with a huge PITA for the qualification (hypervisors, database clients etc.) process. To qualify a new feature for such client, as it stands today, we'd have to qualify a new minor version that has it and also old versions for legacy reasons, if they are not deprecated. A la carte (like SAN) will have the same problem, just that we'd qualify a set of features together. Since we have more sub-features than minor versions, we are staring down the same path.

If we are tackling these, let's reset the conversation to address the following: 

1. Do we have consensus that minor versioning is working?
2. Are we happy with the song and dance we did with NFSv4.0 and NFSv4.1 and now that we have NFSv4.2 coming, what overhead it adds to vendor's qualification businesses?
3. Does everyone have a good understanding of minor version deprecation rules?

If we don't reset conversations around these questions, and keep talking about introducing another layer of versioning (experimental vs non-experimental) and potentially unleash more versions on vendor's, this topic is a non-starter. I don't think I'd fund a trip to Berlin to talk about this topic.

My ask: First, let's agree on what we'd like to solve, before we need a face to face meeting.

___
Pranoop Erasani | Technical Director, NFS | NetApp | W: 408-822-3282 | C: 408-306-2928

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Nico Williams
> Sent: Wednesday, May 08, 2013 12:17 AM
> To: Noveck, David
> Cc: nfsv4 list ([email-masked])
> Subject: Re: [nfsv4] DN contribution to IETF87 meta-discussion
> 
> instances of the standard version.  The only thing that works is a la carte
> negotiation.
> 
> We've had horror stories with version negotiation in other protocols, and,
> really, the only thing that's worked is...  You know the deal.
> 
> TLS?  Each minor version change is a PITA and takes on the order of a decade
> to deploy.  New TLS ciphers?  A dime a dozen.  That's an existence proof
> right there that a la carte works better than minor versioning.
> 
> NFS has only done major and minor versioning; each has taken on the order
> of... a decade.  An existence proof that minor versioning..
> takes forever.
> 
> No new versions have been needed since 2.0, but plenty of extensions have
> been added since.  That's an existence proof right there that a la carte works
> better than minor versioning.
> 
> Of course, what's the goal?  If the goal is feature cycles between 5 and 10
> years, well, stick to minor versioning.
> 
> Nico
> --

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 8 May 2013 12:12:51 -0400

> sure it's ever been explained to me.  Not having a la carte extensions

No opposition from me personally, but I also don't understand exactly
what it is you're asking for when you ask for "a la carte extensions":

	- new protocol operations to do negotiation?
	- different minor version rules?
	- different protocol process for specifying new features?

The first looks like a solved problem--between attribute bitmasks, op
numbers, etc., we don't seem to have needed anything new for a 4.2 spec
that allows implementation of any subset of a half-dozen new
all-optional features.

So I guess you want something in the last two categories: allow adding
new optional features to an existing minor version?  Require each new
feature to get a separate rfc?  Something else?

--b.

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 8 May 2013 16:26:57 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Matt W. Benjamin
Sent: Wednesday, May 8, 2013 7:41 AM
To: Tom Haynes
Cc: nfsv4 list ([email-masked])
Subject: Re: [nfsv4] DN contribution to IETF87 meta-discussion

Hi,

> all prepared to sit down for 3 hours every morning and churn through 

Very much so.  If 3h sessions are what it's going to take, and folks are going to be present, then maybe that should happen.

[Spencer] The other alternative is to set up a series of conference calls to work through the discussion.  That would help use the face-to-face time on the issues that have yet to be resolved in the conference calls.

Spencer

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 May 2013 11:30:29 -0500

>         - different protocol process for specifying new features?

Each of the two parties (for a simple client-server protocol) speak a
set of sub-protocols.  One or both parties send the other a list of
sub-protocols they implement.  The agreed-upon set of sub-protocols to
be spoken will be the intersection of the two sets.

Sub-protocols can be: features or versioned features.  They can have
IANA-assigned/allocated names or URNs, or domain-based names, or
whatever is desired/appropriate for the protocol in question.  (For
example, SSHv2 uses e-mail address-like strings to name non-standard
extensions, all other names being assigned by the IANA.)

> that allows implementation of any subset of a half-dozen new

Bitmasks generally imply a small namespace.  Sure, we could have a
variable length bit string to carry the bit masks and so have no
constraint on how many bits we can have.  But I fear in practice bit
masks == 64 bits max, and then you need to reserve one bit for
negotiating the addition of a new bitmask.  And it's all error prone.
There's no need to space-optimize infrequent negotiations.
Conversely, frequent negotiations should probably be space (;latency)
optimized.

> feature to get a separate rfc?  Something else?

My answers:  yes to the first; not necessarily, but probably to the
second; no to the third.

Nico
--

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 8 May 2013 16:30:53 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chuck Lever
Sent: Wednesday, May 8, 2013 7:55 AM
To: Nico Williams
Cc: nfsv4 list ([email-masked])
Subject: Re: [nfsv4] DN contribution to IETF87 meta-discussion

[Spencer] Do you have a sketch of what this might look like?  Maybe we could pick a hypothetical change for NFSv4.1 and walk through what the mechanism would look like to introduce the change?  Making it concrete might help focus the discussion.

Spencer

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 May 2013 11:57:20 -0500

> [Spencer] Do you have a sketch of what this might look like?  Maybe we could pick a hypothetical change for NFSv4.1 and walk through what the mechanism would look like to introduce the change?  Mak…

There's a lot of low-level detail options.  You could negotiate one
last new minor version that then does the a la carte negotiation
(e.g., in an extended SETCLIENTID).  You could use attributes on the
ROOTFH.  You could add a new operation (if unsupported ops fail
reliably).

Going up a level we have these choices:

 - the client asks what the server supports and then limits itself to
speaking those sub-protocols
 - the client tells the server what sub-protocols it speaks and then
the server tells it the result of the intersection with its set
 - the client and server both tell each other what they support and
then proceed to intersect the two sets independently, obtaining the
same result, necessarily, if we have enough integrity protection on
the wire

All three choices work equally well from my point of view, but I
suspect that the first fits NFSv4's world-view best.  The last seems
unnecessarily redundant, but it's nice for observability, so I tend to
prefer it.

Nico
--

---

From: Chuck Lever <[email-masked]>
Date: Wed, 8 May 2013 16:08:48 -0400

> feature to get a separate rfc?  Something else?

"Allow the addition of new optional features to an existing minor version."  Large scale protocol extension should continue to happen within the bounds of our minor versioning rules.

Sometimes we do need to change a particular existing minor version to address issues that were unforeseen when the protocol was originally specified.  This is especially a problem because of the lag between when a protocol specification is ratified and when all of its features are fully prototyped by interested parties.  (*)

An RFC process could exist for introducing these small extensions.  The WG's main interest here would be to have a way to address problems in old (but still supported by charter mandate) protocol versions, and public review is well-suited to this task.

However vendors sometimes want to incorporate additional features in an existing minor version, for various reasons, without depending on a lengthy public review.  This kind of change would reside architecturally in the same realm as protocol fixes, but a vendor might have reasons for keeping such a feature proprietary (even temporarily), which necessarily excludes a public RFC process in some cases.

The point of standardizing a mechanism for proprietary extensions is to preserve interoperability even when private extensions are present in an implementation.  If your implementation doesn't support an extension that it doesn't recognize, it should be able to ignore it without consequence (much like OPTIONAL works today).

The use of a particular private extension would have no interoperability guarantees unless it passes through the RFC process.

(*) I think Tom has done yeoman's duty with NFSv4.2 to limit the prototyping and qualification burden for this minor version by keeping its scope narrow and by making every new feature OPTIONAL.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 8 May 2013 16:19:34 -0400

On Wed, May 08, 2013 at 11:30:29AM -0500, Nico Williams wrote:
> negotiating the addition of a new bitmask.

FWIW, attribute bitmaps are already variable-length, and NFSv4.1 already
uses more than 64.

--b.

> And it's all error prone.

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 May 2013 15:48:53 -0500

On Wed, May 8, 2013 at 3:08 PM, Chuck Lever <[email-masked]> wrote:

Unless there's major work on the scale of pNFS to justify monopolizing
the attention of participants to the exclusion of other extensions,
then I don't see how this can be justified.  If there are participants
who want to work on some extension, and there's enough interest
(reviewers, editors, ...), there's no architectural objection (the
sort that might lead the IESG to request non-publication), ..., then
the IETF standards process should not be used to keep them out.

A minor versioning model involving a multi-year "train" is not really
acceptable to me, except under exceptional circumstances (see above).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 May 2013 15:59:01 -0500

Also, I've said this before, and I'll say it again: this WG cannot do
more than pretend to set down rules for versioning.  In particular, no
WG that isn't chartered to update RFC2026 and friends, and even then,
can really stop the IETF from breaking whatever NFSv4 minor versioning
rules you would prefer.  It's like legislatures passing laws that bind
themselves in the future: it's universally acknowledged that they lack
such power.

Nico
--

---

From: "Myklebust, Trond" <[email-masked]>
Date: Wed, 8 May 2013 21:07:02 +0000

> Sent: Wednesday, May 08, 2013 4:59 PM
> To: nfsv4 list ([email-masked])
> Also, I've said this before, and I'll say it again: this WG cannot do more than
> pretend to set down rules for versioning.  In particular, no WG that isn't
> chartered to update RFC2026 and friends, and even then, can really stop the
> IETF from breaking whatever NFSv4 minor versioning rules you would prefer.
> It's like legislatures passing laws that bind themselves in the future: it's
> universally acknowledged that they lack such power.

Sure, but as long as there is rough consensus for those rules, then we're bound by them. It's up to the people who so desperately want this a-la carte stuff to convince the rest of us that this is a good thing.
Considering that there are no fully complete implementation of NFSv4.1 out there, I'm rather surprised that people are so gung-ho about wanting to speed development up...

Trond

---

From: Spencer <[email-masked]>
Date: Wed, 8 May 2013 23:10:05 -0700

The working group has demonstrated the ability to adapt.

For NFSv4.1, the minor versioning rules of 4.0 where not strictly followed.

Instead of speaking in the abstract, I would prefer that we evaluate an approach based on the review and feedback of a specific proposal.

If there is a need today, then a proposal should either be sent directly to the working group alias or submitted as an Internet Draft.

Spencer

---

From: Spencer <[email-masked]>
Date: Wed, 8 May 2013 23:12:46 -0700

> acceptable to me, except under exceptional circumstances (see above).

From my perspective there is no exclusion with the exception of the resoures it takes to draft, edit, and publish a document.

I have always held that the time elapsed for the completion of an internet draft is proportional to the resources put into it.

---

From: Spencer <[email-masked]>
Date: Wed, 8 May 2013 23:17:59 -0700

> However vendors sometimes want to incorporate additional features in an existing minor version, for various reasons, without depending on a lengthy public review.  This kind of change would reside…

This can be done with the use of an alternate RPC program number on 2049 or on an alternate port.  This has been demonstrated many times in the past.
Given that the unpublished behavior would be needed in both the client and server this seems like a reasonable approach.

> The point of standardizing a mechanism for proprietary extensions is to preserve interoperability even when private extensions are present in an implementation.  If your implementation doesn't supp…

Is the proprietary extension being used to work around the time to deliver or the mechanism to deliver a feature in the form of an RFC? If so, then it would seem prudent to adapt the behaviors of the working group and the resources placed upon such an effort to provide for well-documented behaviors.  In the abstract, I can not see a reason not to document the needed protocol changes such that it is open to implement.

Spencer

---

From: Spencer <[email-masked]>
Date: Wed, 8 May 2013 23:25:34 -0700

> If there is someone of the microversioning persuasion that wants to participate, perhaps we can collaborate on a joint presentation.

I count eleven weeks between now and the IETF meeting.  Given the discussion in the latter half of this thread about timely, responsive updates to the protocol, might I suggest that discussion on the working group alias about the problem(s) being solved and specific proposals may be prudent.  Having something concrete to discuss would help focus the discussion and make any face-to-face time fruitful.

> ·         I’d  like to discuss the metadata layout stuff with a view to deciding what level of working group effort is appropriate.    My preference would be to see this as part of consideration of…

Again, eleven weeks of productive discussion and review can occur on any of these or other topics that I have mentioned before.  Or the discussion can wait until the working group meeting as time allows for everyone's schedule.

Spencer

---

From: Spencer <[email-masked]>
Date: Wed, 8 May 2013 23:27:06 -0700

> There are already RFCs on protocol extensibility that cover the pitfalls well:  RFC 4775 and 6709 are two that come immediately to mind, and neither is impossibly long.

Do you envision this mechanism being applied to NFSv4.0/NFSv4.1?

Should this be added to NFSv4.2 to allow for the modifications of the future without a full minor revision?

Spencer

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 9 May 2013 08:56:35 -0400

On Wed, May 08, 2013 at 11:12:46PM -0700, Spencer wrote:
> > Unless there's major work on the scale of pNFS to justify
> > monopolizing the attention of participants to the exclusion of other
> > extensions, then I don't see how this can be justified.  If there
> > are participants who want to work on some extension, and there's
> > enough interest (reviewers, editors, ...), there's no architectural
> > objection (the sort that might lead the IESG to request
> > non-publication), ..., then the IETF standards process should not be
> > used to keep them out.
> > 
> > A minor versioning model involving a multi-year "train" is not
> > really acceptable to me, except under exceptional circumstances (see
> > above).
> 
> From my perspective there is no exclusion with the exception of the
> resoures it takes to draft, edit, and publish a document.
> 
> I have always held that the time elapsed for the completion of an
> internet draft is proportional to the resources put into it.

So if we half our effort, we can half the elapsed time?

Excellent!

--b.

---

From: Chuck Lever <[email-masked]>
Date: Thu, 9 May 2013 09:50:58 -0400

> Do you envision this mechanism being applied to NFSv4.0/NFSv4.1?

As a matter of practicality, given the age of the spec and the level of deployment, an NFSv4.0 mechanism may be a different mechanism than the one we adopt for later minor versions which have yet to be specified.

To remedy issues in NFSv4.0, we would hope to have mechanisms that are less awkward, for example, than the changes we have done for Transparent State Migration.  UCS solves the problem within the constraints of what can be addressed without XDR changes.  But for existing implementations, it creates difficulties that might have been eased if we had more flexibility.

The point being that, yes, we were able to address NFSv4.0 migration issues with changes in convention and specification while avoiding XDR changes, this time.  But such changes are not always optimal.

> Should this be added to NFSv4.2 to allow for the modifications of the future without a full minor revision?

Ideally, it should, but I personally do not want to hold up NFSv4.2 for something that is still in the hand waving stage.

> Is the proprietary extension being used to work around the time to deliver or the mechanism to deliver a feature in the form of an RFC? If so, then it would seem prudent to adapt the behaviors of t…

The amount of review required for an RFC is months or longer.  Generally, customers need a bug fix within a day or two.  I don't think the WG has much control over IETF process, and anyway it serves us well in the long run.

So we may consider improving our local process, but we can't shave out a lot, IMO.  This is not a "speed up development" proposal, in my view, nor is it a "circumvent broken process" proposal.  In the real world, vendors must fix bugs.  We should enable them to do that.

But on the development side: the current mechanisms for prototyping new features are adequate for lab studies, but are not adequate for innovating (in the sense of bringing new features in front of customers as part of a reliable solution, in order to assess questions of scale-out and customer interest).

In other words, how do we get more deep experience with a feature _before_ it is documented in a protocol specification?  One approach is to enable private extensions that can eventually become part of the standard protocol.

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 9 May 2013 14:27:27 +0000

Chuck,

I am not against what you describe but am trying to understand the scenarios.  So far, your scenarios seem to be describing the ability to deliver undocumented modifications to the NFSv4 protocols and have a standard method of delivering these vendor specific extensions.  These scenarios are either one-off bug fixes or larger, complete implementations of new features that would enjoy large deployment.  

I am trying to tease apart those scenarios from the ability of the working group to define small, point fixes to protocol definitions in a way that does not incur a new minor version.  In these cases, the changes are documented and can be implemented in an interoperable, open way.

Both of those scenarios seem valid.  For the first, I am having difficulty understanding why the current mechanism of a new RPC program number doesn't solve the issue?  As I mentioned in other email, the implementation would need to be delivered at both the client and server and in this case, having a separate RPC program accomplishes this nicely.  It can ride on port 2049, etc.  The NFS ACL protocol is a prime example of this.

Spencer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chuck Lever
Sent: Thursday, May 9, 2013 6:51 AM
To: Spencer
Cc: Nico Williams; nfsv4 list ([email-masked])
Subject: Re: [nfsv4] DN contribution to IETF87 meta-discussion

On May 9, 2013, at 2:27 AM, Spencer <[email-masked]> wrote:

>>> I should add that experimental versions don't work, especially not 
>>> if deployed instances of experimental versions must not meet 
>>> deployed instances of the standard version.  The only thing that 
>>> works is a la carte negotiation.
>>> 
>>> We've had horror stories with version negotiation in other 
>>> protocols, and, really, the only thing that's worked is...  You know the deal.
>>> 
>>> TLS?  Each minor version change is a PITA and takes on the order of 
>>> a decade to deploy.  New TLS ciphers?  A dime a dozen.  That's an

---

From: "Myklebust, Trond" <[email-masked]>
Date: Thu, 9 May 2013 14:30:38 +0000

> In other words, how do we get more deep experience with a feature _before_ it is documented in a protocol specification?  One approach is to enable private extensions that can eventually become par…

This is precisely what happened with pNFS, copy offload etc. People went
off, developed private versions usually by means of side-band RPC
protocols (although in the case of some of the pNFS flavours, it was
much more drastic than just a side-band protocol) and then came to the
IETF with proposals.
IOW: we already have the freedom to do this.

Now if, on the other hand, you mean that people should be free to
develop stuff directly inside the NFSv4 protocol, ship it and then come
the IETF for rubber-stamping, then that seems wrong. It would be rife
for abuse...

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Chuck Lever <[email-masked]>
Date: Thu, 9 May 2013 10:45:41 -0400

> I am trying to tease apart those scenarios from the ability of the working group to define small, point fixes to protocol definitions in a way that does not incur a new minor version.  In these cas…

Yes, and we absolutely should preserve that open process.

> Both of those scenarios seem valid.  For the first, I am having difficulty understanding why the current mechanism of a new RPC program number doesn't solve the issue?

Excellent question.  In some cases, a separate RPC program is adequate.  In others, an in-band solution is required.

Could we have used a separate RPC program to resolve issues with Transparent State Migration?

In NFSv4.0 there is a well-known race between an OPEN reply and a delegation recall.  That was resolved by convention in 3530bis, but it amounts to an in-band solution.

> As I mentioned in other email, the implementation would need to be delivered at both the client and server and in this case, having a separate RPC program accomplishes this nicely.  It can ride on port 2049, etc.  The NFS ACL protocol is a prime example of this.

And additionally it should not interfere with other spec-compliant implementations.

---

From: Chuck Lever <[email-masked]>
Date: Thu, 9 May 2013 11:02:49 -0400

> IOW: we already have the freedom to do this.

If we have mechanisms or best practices where vendors can deliver in-band NFS features to market without creating fresh interoperability problems for compliant implementations, then we should document those as recommended practices to avoid people re-inventing this wheel (and getting it wrong on occasion).

"Here's what you do if..." and "Here's what you don't do" are both valid.  RFCs 4775 and 6709 are good examples that are not specific to NFS or RPC.

> the IETF for rubber-stamping, then that seems wrong. It would be rife

That seems wrong to me too.  I'm not suggesting we make any change to the process of bringing feature proposals to the WG, nor how open or flexible or authoritative would be the process of constructing and standardizing the final version of said features.

---

From: "Myklebust, Trond" <[email-masked]>
Date: Thu, 9 May 2013 15:17:31 +0000

> "Here's what you do if..." and "Here's what you don't do" are both valid.  RFCs 4775 and 6709 are good examples that are not specific to NFS or RPC.

What do you mean by "in-band"? Are you talking about "in-band" in the
sense that the Oracle POSIX ACL protocol is "in-band"? i.e. shares the
same connection and port with the NFSv3 protocol.

If not, I'm not sure that I understand your point. We already have
plenty of documentation for the ONC/RPC protocol itself; anyone can read
those RFCs and figure out how to write a private protocol.

NetApp

---

From: Chuck Lever <[email-masked]>
Date: Thu, 9 May 2013 11:23:50 -0400

> those RFCs and figure out how to write a private protocol.

In-band means a change is necessary to the NFS protocol itself.  See my e-mail to Spencer for examples of why this might be needed to address protocol issues.

There are cases where a secondary protocol does not help.  If you want to avoid additional round trips in performance critical paths, or you want to efficiently avoid NFS requests racing with the secondary protocol, then changing NFS is preferred.

---

From: "Myklebust, Trond" <[email-masked]>
Date: Thu, 9 May 2013 15:47:48 +0000

> In-band means a change is necessary to the NFS protocol itself.  See my e-mail to Spencer for examples of why this might be needed to address protocol issues.

Are we talking about adding new features, or are we talking about fixing
existing features? To me, those are 2 different problems and my
impression was that you were talking about the former above, and the
latter in the other thread with Spencer.

> There are cases where a secondary protocol does not help.  If you want to avoid additional round trips in performance critical paths, or you want to efficiently avoid NFS requests racing with the s…

What performance-sensitive features are you looking to implement?

NetApp

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 9 May 2013 11:56:04 -0400

> Considering that there are no fully complete implementation of NFSv4.1 out there, I'm rather surprised that people are so gung-ho about wanting to speed development up...

Oh, I thought the idea was to do less rather than more.

The idea being that we haven't been saying "no" to enough features, so
as a way to make it easier to say "no" we let people go off in their
corner and implement experimental things without holding up the rest of
us if they turn out not to happen.

Honestly I don't know if there's any real technical or procedural
solution there, but maybe someone can explain one to me.

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 9 May 2013 12:04:31 -0400

> Should this be added to NFSv4.2 to allow for the modifications of the future without a full minor revision?

Please, no.  Can we instead call that future work?

We've got a labeled NFS implementation that I hope will get turned on in
production some day in the not-too-distant future, and I don't want 4.2
to be held up by some argument over minor versioning rules.

--b.

---

From: "Noveck, David" <[email-masked]>
Date: Thu, 9 May 2013 15:17:38 -0400

> I count eleven weeks between now and the IETF meeting.  

Have I missed something?  The last I heard was to not assume we would be meeting at IETF87.  If we are not meeting in Berlin, the count would be more like 27 weeks.

What I understand us to be doing now is getting together an agenda for a potential  IETF87 working group meeting for the working group to say "yea" or "nay" to.  

While I can produce something more specific/concrete, there's no time for an individual draft to be ready by the three-week limit for IETF87.    At least there won't be, given that this is not a full-time endeavor for me.  I understand Spencer thinks it would be helpful, but what I really want to know is if the working group considers it a sine qua non, necessary for even having the IETF87 discussion of this area.

-----Original Message-----
From: Spencer [mailto:[email-masked]] 
Sent: Thursday, May 09, 2013 2:26 AM
To: Noveck, David
Cc: nfsv4 list ([email-masked])
Subject: Re: [nfsv4] DN contribution to IETF87 meta-discussion

Spencer

---

From: "Noveck, David" <[email-masked]>
Date: Thu, 9 May 2013 15:20:58 -0400

From: Noveck, David
Sent: Thursday, May 09, 2013 2:34 PM
To: 'Haynes, Tom'
Subject: RE: [nfsv4] DN contribution to IETF87 meta-discussion

> I'd like to have that discussion as well.

Sounds like a consensus to me :)  I wonder if Spencer agrees.

> I'd specifically like to hear more on your ideas of experimental versions.

Actually, I should have said experimental features.

The problem we have is that we have plenty of experimental features, but we are
not prepared to acknowledge the fact.  The fact is since we put them into a non-experimental
minor version without much implementation, they are all experimental, although I have to
say most of these experiments are indeed "noble in purpose".

> Of course, I might just be happy with stating that odd number releases are experimental and even number ones are stable. I think I've heard of a OS or two which take this approach.

That doesn't solve the big problem we have which is what to do about problems that need
XDR changes in v4.0.  The problem is that there is no integer between 0 and 1.  If we had called
V4.1, v4.2, we would have left space for a v4.1 bug fix version.  So, unless you have a time
machine, we are stuck.

If you do have a time machine to allow us to solve this problem, I'd love to see the IPR
statement :)

It might make sense for the future, to make even versions feature versions and odd versions bug fix
versions.

> In any event, this is the first I've heard of the idea of experimental versions, can we hash it out here first?

Sure we can make a hash of it here.  I'll look at the discussion so far and try to summarize

> And I'd like to hear something about it as well.

Another emerging consensus.

>And as Europe should be an easier venue for the author, that should be a consideration.

I'd like to hear the author chime in about that.

> I'd also like to see the WG decide to really tackle RPCSEC_GSSv3. But that needs to happen on the WG alias and not in person. Unless we are all prepared to sit down for 3 hours every morning and ch…

It depends on what the "that" in "that needs to happen" is.  I think the decision to really tackle RPCSEC_GSSv3 should happen in Berlin, along probably with some agreement bout how.  The work to implement that decision should not happen in Berlin.

From: Haynes, Tom [mailto:[email-masked]]
Sent: Wednesday, May 08, 2013 1:17 AM
To: Noveck, David
Cc: nfsv4 list ([email-masked]<mailto:[email-masked]>)
Subject: Re: [nfsv4] DN contribution to IETF87 meta-discussion

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 9 May 2013 19:30:59 +0000

I will, again, take the opportunity to note that there is a normative reference in NFSv4.2 on this:

[5]   Haynes, T. and N. Williams, "Remote Procedure Call (RPC)
         Security Version 3", draft-williams-rpcsecgssv3 (work in
         progress), 2011.

If there is a desire to see NFSv4.2 move ahead to a published RFC, then either this dependency needs to be removed or it needs to move forward with NFSv4.2.

Spencer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of J. Bruce Fields
Sent: Thursday, May 9, 2013 9:05 AM
To: Spencer
Cc: Nico Williams; nfsv4 list ([email-masked])
Subject: Re: [nfsv4] DN contribution to IETF87 meta-discussion

We've got a labeled NFS implementation that I hope will get turned on in production some day in the not-too-distant future, and I don't want 4.2 to be held up by some argument over minor versioning rules.

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 9 May 2013 15:56:24 -0400

> If there is a desire to see NFSv4.2 move ahead to a published RFC, then either this dependency needs to be removed or it needs to move forward with NFSv4.2.

As far as I know, the rpcsecgssv3 draft isn't ready, and there's no one
working on implementation.  If that's accurate, I think we should remove
the dependency.

I'd be delighted to be corrected on either point.

--b.

---

From: "Noveck, David" <[email-masked]>
Date: Thu, 9 May 2013 16:09:00 -0400

> Please, no.  Can we instead call that future work?

I agree that if this is to be done, it should not be done before v4.3.

I think the same considerations would apply in v4.3.  If you start down that minor version path, as you assemble tour train, adding a new feature for a new versioning approach will never be worth it.  For whatever v4.x this is done in, it should be the only thing in that v4.x.   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of J. Bruce Fields
Sent: Thursday, May 09, 2013 12:05 PM
To: Spencer
Cc: Nico Williams; nfsv4 list ([email-masked])
Subject: Re: [nfsv4] DN contribution to IETF87 meta-discussion

--b.

---

From: Nico Williams <[email-masked]>
Date: Thu, 9 May 2013 15:35:18 -0500

> Sure, but as long as there is rough consensus for those rules, then we're bound by them. It's up to the people who so desperately want this a-la carte stuff to convince the rest of us that this is…

That's fine.  What's not fine is for an RFC to mandate a different
process than the IETF process for an Internet protocol (if there's
issues w.r.t. liasing with other SDOs, sure, but that's not what's
happening here).  It is fine for the WG to have consensus on all sorts
of things, as long as that consensus is allowed to change.

That is, if an implementor brings a new feature to the WG, the WG can
reject it for all sorts of reasons (technical, architectural), but "it
says in some RFC you can't have it till we're done with the current
minor version on the board" is not appropriate.  Whereas "you can't
have it for now because not enough participants are willing to help
you with reviews, editorship", or "sorry, no one here is interested"
are OK, as long as these decisions are made on a case-by-case basis.

It'd help to be able to add sub-protocols independently of one another
and/or minor versions, but I don't think that's a requirement and I
won't insist on it.  I insist only on the above.

> Considering that there are no fully complete implementation of NFSv4.1 out there, I'm rather surprised that people are so gung-ho about wanting to speed development up...

Completeness of implementations of NFSv4.1 is not really relevant to
whether some other feature should be adopted or rejected (or even
denied the individual submission track).  Consider that to go from
Proposed Standard to Draf Standard, and then to Standard status,
requires *removing* all those features for which interoperable
implementation pairs cannot be found.

Nico
--

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 9 May 2013 21:10:41 +0000

Let me rephrase based on your comments.

There is time between now and a face-to-face meeting to allow for a "presentation like" email to be sent to the working group to foster discussion.  No reason to wait until we see each other.

The discussion on versioning has been very helpful.

Spencer

-----Original Message-----
From: Spencer [mailto:[email-masked]] 
Sent: Thursday, May 09, 2013 2:26 AM
To: Noveck, David
Cc: nfsv4 list ([email-masked])
Subject: Re: [nfsv4] DN contribution to IETF87 meta-discussion

Spencer

---

From: "Noveck, David" <[email-masked]>
Date: Thu, 9 May 2013 18:09:19 -0400

-----Original Message-----
From: Noveck, David 
Sent: Thursday, May 09, 2013 6:05 PM
To: 'Spencer Shepler'
Subject: RE: [nfsv4] DN contribution to IETF87 meta-discussion

There is a reason to wait until there is a point in doing this.

I'll commit to producing something presentation-like by about three weeks after we have the agenda for the IETF87 discussion out, and there is a working-group consensus that we want this discussion.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]] 
Sent: Thursday, May 09, 2013 5:11 PM
To: Noveck, David; Spencer
Cc: nfsv4 list ([email-masked])
Subject: RE: [nfsv4] DN contribution to IETF87 meta-discussion

Spencer

-----Original Message-----
From: Spencer [mailto:[email-masked]] 
Sent: Thursday, May 09, 2013 2:26 AM
To: Noveck, David
Cc: nfsv4 list ([email-masked])
Subject: Re: [nfsv4] DN contribution to IETF87 meta-discussion

Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 10 May 2013 01:29:17 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Noveck, David
Sent: Thursday, May 9, 2013 3:09 PM
To: nfsv4 list ([email-masked])
Subject: [nfsv4] FW: DN contribution to IETF87 meta-discussion

-----Original Message-----
From: Noveck, David 
Sent: Thursday, May 09, 2013 6:05 PM
To: 'Spencer Shepler'
Subject: RE: [nfsv4] DN contribution to IETF87 meta-discussion

[Spencer] The point I have trying to make throughout the various threads is that there is no reason to wait for the working group meeting.  If there is a topic of interest (even to one person) posting to the working group alias or writing an Internet Draft is perfectly reasonable thing to do and can be timely.  We have seen this in the thread about versioning features into the protocol.  You can derive the criteria you want to follow for participation/contribution but I don't want others to feel like they have to have a working group agenda item or rough consensus about a topic to even discuss it.  Not required.  Never has been.  Certainly not encouraged by me.

Have a topic?  Post it to the list, get the discussion going. 

Spencer

---

From: "Noveck, David" <[email-masked]>
Date: Fri, 10 May 2013 14:32:36 -0400

> [Spencer] The point I have trying to make throughout the various threads is that there is no 
> reason to wait for the working group meeting.

You keep making that point, even when it is not appropriate to the matter at hand.

In my particular case, I was responding to your request that I present  to the group
a preview of a presentation that I planned to give at IETF87, if it is the working group
consensus that we should discuss the matter in Berlin.  In that context, it is not very 
helpful to say that, in your view, such working group meetings  are not necessary.  
The working group will decide whether one is necessary, of course taking your view 
(or perhaps I should say Weltanschauung :-) into account.

In the past, the working group has found face-to-face meetings helpful, even if one
might argue that they are not, strictly speaking, necessary.  I don't expect that approach
to change, but that is a matter for the working group to address and decide.

I'm feeling as if we have some very simple matters to decide but the working group's 
decision is being held up by your intense determination to present your point of view 
about working group meetings, at every opportunity.    The working group knows your 
point of view by now and repetition is not contributing anything.  Can we just get a 
proposed agenda for the IETF87 meeting together and let the working group decide 
whether it is appropriate to meet face-to-face and discuss the matters listed?

Sent: Thursday, May 09, 2013 9:29 PM
To: Noveck, David; nfsv4 list ([email-masked])
Subject: RE: [nfsv4] FW: DN contribution to IETF87 meta-discussion

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Noveck, David
Sent: Thursday, May 9, 2013 3:09 PM
To: nfsv4 list ([email-masked])
Subject: [nfsv4] FW: DN contribution to IETF87 meta-discussion

-----Original Message-----
From: Noveck, David 
Sent: Thursday, May 09, 2013 6:05 PM
To: 'Spencer Shepler'
Subject: RE: [nfsv4] DN contribution to IETF87 meta-discussion

Spencer

---

From: David Quigley <[email-masked]>
Date: Fri, 10 May 2013 20:26:23 -0400

> be present, then maybe that should happen.

I know that I won't be present for it and I'm not sure if Nico will be 
either. If anyone wants to point people in my direction I can give them 
what was once working code (I guess it still technically is if you have 
the right versions) and we can work on implementing a second prototype 
of RPCSEC_GSSv3 so we can start encountering any interoperability issues 
and fixing them in the spec.

Dave

---

From: David Quigley <[email-masked]>
Date: Fri, 10 May 2013 20:37:28 -0400

On 05/09/2013 15:56, J. Bruce Fields wrote:
>> If there is a desire to see NFSv4.2 move ahead to a published RFC, 
>> then either this dependency needs to be removed or it needs to move 
>> forward with NFSv4.2.
>

That no one is working on it is only partly true. The guys in singapore 
who were helping me with rebasing the LNFS patches for Linux before 
Steve Dickson took over were tasked with figuring out the RPCSEC_GSSv3 
patches that I gave them. If anyone wants to spend time on those patches 
I'm glad to hand them over and have them work on them. They are against 
an older kernel and Linux userspace library and deamon but the ideas are 
probably still sound.

For the initial implementation we have for Linux RPCSEC_GSSv3 isn't 
necessary. However I'm not sure what changes need to be made to the 
NFSv4.2 to say that process label transport will be handled later in a 
future RFC.

Dave

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 May 2013 19:59:14 -0500

On Fri, May 10, 2013 at 7:26 PM, David Quigley <[email-masked]> wrote:
> either. If anyone wants to point people in my direction I can give them what
> was once working code (I guess it still technically is if you have the right
> versions) and we can work on implementing a second prototype of RPCSEC_GSSv3
> so we can start encountering any interoperability issues and fixing them in
> the spec.

If I'm in Berlin at that time it won't be for IETF but for vacation,
though I'd be able to spare time for it.  Anyways, I've not yet
planned this.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 14 May 2013 12:31:36 -0400

On Fri, May 10, 2013 at 08:37:28PM -0400, David Quigley wrote:
> >>If there is a desire to see NFSv4.2 move ahead to a published
> >>RFC, then either this dependency needs to be removed or it needs
> >>to move forward with NFSv4.2.
> >
> That no one is working on it is only partly true. The guys in
> singapore who were helping me with rebasing the LNFS patches for
> Linux before Steve Dickson took over were tasked with figuring out
> the RPCSEC_GSSv3 patches that I gave them. If anyone wants to spend
> time on those patches I'm glad to hand them over and have them work
> on them.

I can't volunteer for the development effort, but I'd like to take a
quick look, thanks.

> They are against an older kernel and Linux userspace
> library and deamon but the ideas are probably still sound.
> 
> NFSv4.2 to say that process label transport will be handled later in
> a future RFC.

I think we just say process labels are future work.  I don't think
removing references to RPCSEC_GSSv3 would be a big job.

Server-to-server looks harder; I guess we'd either:

	a) Give up for now on some of the requirements in the
	"Requirements for Secure inter-Server Copy" section.
	Specifically, "The specification MUST provide guidance for using
	NFSv4.x as a copy protocol", and "The specification MUST NOT
	mandate a trust relationship between the source and destination
	server."  Which leaves us having to tell the servers how to
	authenticate to each other.

	b) Specify only intra-server copy, leave inter-server for 4.3.

	c) Leave all of server-to-server copy for 4.3.

--b.

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 14 May 2013 16:53:25 +0000

On the option of removing the reference/use of RPCSEC_GSSv3, my opinion is that b) is the reasonable path.  Server-to-server is useful but not fully realized and avoids the security issues.

Having said that, I am hopeful that we can find a document editor and interest/time to get the I-D moved forward.

Spencer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of J. Bruce Fields
Sent: Tuesday, May 14, 2013 9:32 AM
To: David Quigley
Cc: [email-masked]
Subject: Re: [nfsv4] DN contribution to IETF87 meta-discussion

On Fri, May 10, 2013 at 08:37:28PM -0400, David Quigley wrote:
> >As far as I know, the rpcsecgssv3 draft isn't ready, and there's no 
> >one working on implementation.  If that's accurate, I think we should 
> >remove the dependency.
> >
> singapore who were helping me with rebasing the LNFS patches for Linux 
> before Steve Dickson took over were tasked with figuring out the 
> RPCSEC_GSSv3 patches that I gave them. If anyone wants to spend time 
> on those patches I'm glad to hand them over and have them work on 
> them.

I can't volunteer for the development effort, but I'd like to take a quick look, thanks.

> They are against an older kernel and Linux userspace library and 
> deamon but the ideas are probably still sound.
> 

I think we just say process labels are future work.  I don't think removing references to RPCSEC_GSSv3 would be a big job.

--b.

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 14 May 2013 18:59:30 +0000

Thanks for your feedback, David.

Obviously I feel my comments and feedback are relevant.

Repeating my earlier points, face-to-face meetings can be made more valuable by prefacing them with published I-Ds, working group email discussion, conference calls, and other forms of communication.  We all know that and my attempts were to remind us of the value of those forms of communication.   Generally, there is no requirement of the use of these with the exception that rough consensus must be obtain via the working group alias or a review of I-Ds and the acknowledgement of those I-D reviews on the working group alias.

Note, I have solicited working group agenda items via another thread.  Let me know of contributions.

Spencer

-----Original Message-----
From: Noveck, David [mailto:[email-masked]] 
Sent: Friday, May 10, 2013 11:33 AM
To: Spencer Shepler; nfsv4 list ([email-masked])
Subject: RE: [nfsv4] FW: DN contribution to IETF87 meta-discussion

> [Spencer] The point I have trying to make throughout the various 
> threads is that there is no reason to wait for the working group meeting.

In my particular case, I was responding to your request that I present  to the group a preview of a presentation that I planned to give at IETF87, if it is the working group consensus that we should discuss the matter in Berlin.  In that context, it is not very helpful to say that, in your view, such working group meetings  are not necessary.  
The working group will decide whether one is necessary, of course taking your view (or perhaps I should say Weltanschauung :-) into account.

In the past, the working group has found face-to-face meetings helpful, even if one might argue that they are not, strictly speaking, necessary.  I don't expect that approach to change, but that is a matter for the working group to address and decide.

I'm feeling as if we have some very simple matters to decide but the working group's decision is being held up by your intense determination to present your point of view 
about working group meetings, at every opportunity.    The working group knows your 
point of view by now and repetition is not contributing anything.  Can we just get a proposed agenda for the IETF87 meeting together and let the working group decide whether it is appropriate to meet face-to-face and discuss the matters listed?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Noveck, David
Sent: Thursday, May 9, 2013 3:09 PM
To: nfsv4 list ([email-masked])
Subject: [nfsv4] FW: DN contribution to IETF87 meta-discussion

-----Original Message-----
From: Noveck, David
Sent: Thursday, May 09, 2013 6:05 PM
To: 'Spencer Shepler'
Subject: RE: [nfsv4] DN contribution to IETF87 meta-discussion

Spencer

---

From: "Noveck, David" <[email-masked]>
Date: Tue, 14 May 2013 21:36:26 -0400

I note that options b) and c) make reference to v4.3.

While we have been loosely talking about v4.3 for a while, we have never really had a discussion about the shape of v4.3.   In particular, will it be one big package of features decided on early and published as a single spec, or will it have a more modular construction, with smaller specs on individual features?  Since we have agreed that no switch in versioning model will happen in the v4.2 time frame, a discussion of the shape of v4.3 is appropriate for IETF87.  I know there are a number of people proposing specific content for v4.x where x=3 seems a likely choice and I'd like to hear those (as well as discussions of new pNFS mapping types) but deciding on the basic shape ofv4.3 is the most important thing that we need to discuss in Berlin, besides the v4.2 completion issues, of course.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Shepler
Sent: Tuesday, May 14, 2013 12:53 PM
To: J. Bruce Fields; David Quigley
Cc: [email-masked]
Subject: Re: [nfsv4] DN contribution to IETF87 meta-discussion

Spencer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of J. Bruce Fields
Sent: Tuesday, May 14, 2013 9:32 AM
To: David Quigley
Cc: [email-masked]
Subject: Re: [nfsv4] DN contribution to IETF87 meta-discussion

--b.

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 15 May 2013 05:25:25 +0000

<removing my working group chair hat>

I am experiencing a certain amount of cognitive dissonance with this last email.  Quickly moving from an attempt to identify working group consensus on the removal of a feature of NFSV4.2 onto a discussion of what can be pushed into the NFSv4.3 list.

Can we finish the first discussion before we jump to the next? IMO the working group should determine what should be done with this NFSv4.2 feature (server-to-server copy offload) and RPCSECGSS_v3 first?

I am having a hard time convincing myself the working group has enough energy at this point for new work when the current work can not be finished.  

I will give everyone the benefit of the doubt and assume that the topic got buried under an inappropriate subject and repost the discussion under something more relevant. 

Spencer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Shepler
Sent: Tuesday, May 14, 2013 12:53 PM
To: J. Bruce Fields; David Quigley
Cc: [email-masked]
Subject: Re: [nfsv4] DN contribution to IETF87 meta-discussion

Spencer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of J. Bruce Fields
Sent: Tuesday, May 14, 2013 9:32 AM
To: David Quigley
Cc: [email-masked]
Subject: Re: [nfsv4] DN contribution to IETF87 meta-discussion

--b.

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 15 May 2013 17:02:30 +0000

> While we have been loosely talking about v4.3 for a while, we have never really had a discussion about the shape of v4.3.   In particular, will it be one big package of features decided on early an…

I would prefer we finish up NFSv4.2 before we even discuss a framework for NFSv4.3.

We had that discussion at the interim meeting a couple of years ago and I don't want to
rehash it.

We can't proceed on NFSv4.2 until we clear the log jam of 3530bis and the issue
on RPCSEC_GSSv3.

---

From: "Noveck, David" <[email-masked]>
Date: Wed, 15 May 2013 15:17:16 -0400

> We can't proceed on NFSv4.2 until we clear the log jam of 3530bis and the issue on RPCSEC_GSSv3.

I didn't even know there was  log jam regarding 3530bis.  I knew there were some annoying comments 
that you have been dealing with, and I'm grateful for your work on that.

If the issue of 3530bis has reached the state where it can be called  a logjam, perhaps we need
to discuss what to do about clearing it, and also,  preventing it from happening again, if that 
doesn't sound too future-oriented for you.

-----Original Message-----
From: Haynes, Tom [mailto:[email-masked]] 
Sent: Wednesday, May 15, 2013 1:03 PM
To: Noveck, David
Cc: Spencer Shepler; J. Bruce Fields; David Quigley; [email-masked]
Subject: Re: [nfsv4] DN contribution to IETF87 meta-discussion

We had that discussion at the interim meeting a couple of years ago and I don't want to rehash it.

We can't proceed on NFSv4.2 until we clear the log jam of 3530bis and the issue on RPCSEC_GSSv3.

---

From: Nico Williams <[email-masked]>
Date: Wed, 15 May 2013 16:03:57 -0500

I'm willing to take vacation (i.e.,self-fund) to help finish the
RPCSEC_GSSv3 spec.  I might even attend Berlin.  What I would need in
rewritten is a commitment from reviewers, existing implementors (even if
they've only done a partial implementation only) and my co-author.  And i'd
need to put a cap on hours I'd dedicate to this.

However, it sounds like the problem isn't merely finishing the spec but
making sure there will be implementations.  What's the point of a normative
reference to something no one will ever implement?  Of course client
implementors have strong incentives to implement RPCSEC_GSSv3, particularly
the compound authentication aspect (otherwise the client is vulnerable to
cache poisoning by local users if the client doesn't maintain a per-user
cache).  As someone focused on security I find it hard to do anything other
than beg/cajole/demand that we fix that cache poisoning problem (and since
i don't expect clients to isolate per-user caches...), but we've lived this
long with this problem -decadds-...  what's a few more decades?

So i think i have to conclude that unless we get implementor commitment
then we should drop RPCSEC_GSSv3 altogether, instead biting the problems
that result from not having it.

Nico
--

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 16 May 2013 00:50:44 +0000

There is no strict dependency between rfc3530bis and NFSv4.2.
The FedFS documents are being held by normative reference to rfc3530bis.

NFSv4.2 has a normative reference to RPCSECGSSv3 and I am holding the NFSv4.2 as shepherd until we sort out what we would like to do with the RPCSECGSS work.  I don't have an opinion one way or the other but the working group needs to resolve the issue and either have a plan to move RPCSECGSS forward or remove the dependency in the NFSV4.2 document and update it.  If we have a plan for RPCSECGSS, then we will move the NFSv4.2 I-D forward with our area director.

Spencer

-----Original Message-----
From: Noveck, David [mailto:[email-masked]] 
Sent: Wednesday, May 15, 2013 12:17 PM
To: Haynes, Tom
Cc: Spencer Shepler; J. Bruce Fields; David Quigley; [email-masked]
Subject: RE: [nfsv4] DN contribution to IETF87 meta-discussion

> We can't proceed on NFSv4.2 until we clear the log jam of 3530bis and the issue on RPCSEC_GSSv3.

I didn't even know there was  log jam regarding 3530bis.  I knew there were some annoying comments that you have been dealing with, and I'm grateful for your work on that.

If the issue of 3530bis has reached the state where it can be called  a logjam, perhaps we need to discuss what to do about clearing it, and also,  preventing it from happening again, if that doesn't sound too future-oriented for you.