Subject: [nfsv4] draft-haynes-nfsv4-versioning-01

From: Tom Haynes <[email-masked]>
Date: Wed, 22 Oct 2014 21:08:44 -0700

So this looks good to go with only two open items for me:

1) Are new operations assigned by IANA or by publishing a draft?

Actually Christoph’s observation, but there seems to be controversy here. :-)

2) With respect to callbacks:

   o  New callbacks will only be sent to clients that have used the new
      features associated with them, allowing existing clients to be
      unaware of their existence.

What if the new feature is only implemented with callbacks?

I.e., clients have to be able to respond with not supported as well.

---

From: Benny Halevy <[email-masked]>
Date: Thu, 23 Oct 2014 09:18:26 +0300

> I.e., clients have to be able to respond with not supported as well.

Why wouldn't they be able to respond with "not supported"?
Even today some callbacks are (feature) optional, e.g. CB_NOTIFY_DEVICEID

Benny

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

---

From: Christoph Hellwig <[email-masked]>
Date: Thu, 23 Oct 2014 09:20:59 +0200

> Even today some callbacks are (feature) optional, e.g. CB_NOTIFY_DEVICEID

But clients needs to ask for it using a bitmasp in the GETDEVICEINFO
arguments.  I suspect if we really get a callback that doesn't have
an operation to request it we just need a attribute that the client
sets to allow it.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 23 Oct 2014 11:29:24 -0400

> Even today some callbacks are (feature) optional, e.g. CB_NOTIFY_DEVICEID

If they implemented only part of a minor version then they may not even
know the callback number is assigned in which case they'll return
NFS4ERR_OP_ILLEGAL.

Not necessarily a problem I guess as long as the server is prepared to
do the same fallback in the ILLEGAL case that it would in the NOTSUPP
case?

Ditto for forechannel operations.

And in the case of attributes INVAL might be returned in cases where we
might expect ATTRNOTSUPP (or just the relevant bits cleared from the
bitmap)?

We may need to go through the various ways of extending the protocol
listed in

	https://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-27#section-2

with an eye towards the case where the extension is something the client
or server doesn't even know the existance of or xdr for.

"adding cases to a switched union" needs some care: e.g. if we added
this to a server reply without some kind of client opt-in then the
client could be left unable to parse the result.  #4 makes it appear
this was intended only for arguments, not replies?

--b.

---

From: David Noveck <[email-masked]>
Date: Thu, 23 Oct 2014 12:38:29 -0400

> So this looks good to go with only two open items for me:

I assume that by "good to go", you mean "ready to convert to a working
group document".

While I think it is desirable to reduce the number of points of
disagreement, I want us to be clear that having no unresolved points of
disagreement is not a requirement for making a document into a working
group document.  That's a more appropriate standard for going into (and
exiting) WGLC.

As far as I'm concerned, for this to become a working group document, we
need rough consensus on two points:

   - Does the working group think a
   document describing versioning across all of NFSv4 a desirable thing to do?
   - is the current draft a reasonable vehicle to do that?  In other words,
   people can still think we got some things wrong, as long as they don't
   think we got things so wrong that we need to start again from scratch.

I haven't heard any disagreement on these points so far, but we might.  If
there is a consensus, we should take note of it, and move
the document forward.

As far as the two open items you mentioned, I'll respond to each item
separately.  We don't want to combine these threads into a tangled mess.

---

From: Tom Haynes <[email-masked]>
Date: Thu, 23 Oct 2014 10:27:27 -0700

On Oct 23, 2014, at 9:38 AM, David Noveck <[email-masked]> wrote:

> I assume that by "good to go", you mean "ready to convert to a working group document”.

Sure

> 
> While I think it is desirable to reduce the number of points of disagreement, I want us to be clear that having no unresolved points of disagreement is not a requirement for making a document into a working group document. 

Agreed and I was trying to suggest that with “open” and not saying “must be resolved”.

> That's a more appropriate standard for going into (and exiting) WGLC.
> 
> As far as I'm concerned, for this to become a working group document, we need rough consensus on two points:
> Does the working group think a document describing versioning across all of NFSv4 a desirable thing to do?
> is the current draft a reasonable vehicle to do that?  In other words, people can still think we got some things wrong, as long as they don't think we got things so wrong that we need to start again from scratch.
> 
> I haven't heard any disagreement on these points so far, but we might.  If there is a consensus, we should take note of it, and move the document forward.
> 
> As far as the two open items you mentioned, I'll respond to each item separately.  We don't want to combine these threads into a tangled mess.
> 
> 
>

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 23 Oct 2014 13:44:12 -0400

> know the callback number is assigned in which case they'll return

(And the draft already discusses that case.  OK, I should read it.
Sorry!)

--b.

---

From: Nico Williams <[email-masked]>
Date: Thu, 23 Oct 2014 13:30:30 -0500

> I.e., clients have to be able to respond with not supported as well.

As long as there's something the client must send first (e.g.,
setclientid) to establish GSS contexts, ...

Nico
--