Subject: [nfsv4] minorversion2-08 comments

From: Mike Kupfer <[email-masked]>
Date: Tue, 01 May 2012 12:06:44 -0700

Technical issues:

* Section 14.1.3, page 86: the spec should provide some guidance to
  server implementors about when to put attributes in acca_critical and
  when to put them in acca_info.

Editorial issues:

* Section 2.4.1.2, page 18: "cap_shared_secret" should be
  "cfap_shared_secret", I think.

* Section 13.8.4, page 73: "an applications execution" should be "an
  application's execution".

* Section 13.10.3, page 82: "reurn" should be "return".

* Section 13.10.4: this restates a lot of the information from Section
  18.22.4 of RFC 5661.  Do we really want that duplication?

mike

---

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 1 May 2012 19:26:53 +0000

>  18.22.4 of RFC 5661.  Do we really want that duplication?

I struggle with that as well as the Error section. In that case, to do it
right adds 30 pages. I'm not interested in doing it that way.

But I'd like for people to get a complete table of that information. It
makes it very easy when sitting there with a network trace to ask what are
the valid error returns for this operation?

Thanks for broaching the larger issue.

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

---

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 1 May 2012 19:33:12 +0000

>Thanks for broaching the larger issue.

One proposal is to add separate target modes to the source to produce
these variants. Thus, if you wanted the entire error section, you might
issue:

$ make errors

And get a document that updates Section 15 of 5661 with the NFSv4.2
additions. I almost went down this route last week.

A second proposal would be to generate an IETF document that encapsulated
the error codes and the versions they were applicable. The problem with
this approach is that the document would have to be respun per minor
version.

---

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 1 May 2012 19:55:05 +0000

>  when to put them in acca_info.

I'm afraid this is a case of making a specific use case general. For LNFS,
we wanted to be able to inform the client that the object label of an open
file had changed. The client then MUST query the server for the new value.

Nico pointed out that we should consider a CB variant that informed the
client of any attribute changing. We envisioned mandatory and advisory
notifications.

So at this time, the only guidance we could provide would be the LNFS use
case.

Does this suffice?

The below are fixed and will show up in version 09.

---

From: Mike Kupfer <[email-masked]>
Date: Tue, 01 May 2012 16:14:08 -0700

> So at this time, the only guidance we could provide would be the LNFS use

IIUC, you're suggesting that the LNFS use case be mentioned for
"mandatory", and everything else would be "advisory".  That sounds fine
to me.

mike

---

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 1 May 2012 23:15:46 +0000

>"mandatory", and everything else would be "advisory".  That sounds fine

Yes, and when we develop other use cases down the line, we provide
guidance in that minor version.

---

From: Mike Kupfer <[email-masked]>
Date: Wed, 02 May 2012 11:35:45 -0700

> >"mandatory", and everything else would be "advisory".  That sounds fine
[...]
> guidance in that minor version.

Sounds good.

mike

---

From: Mike Kupfer <[email-masked]>
Date: Wed, 02 May 2012 12:11:10 -0700

> this approach is that the document would have to be respun per minor

Hmm.  The WG already publishes the XDR description as a separate
document.  Would publishing a third document for the complete error
table be a significant burden?

mike

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 2 May 2012 20:11:17 +0000

I would rather not have a separate document for errors.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Kupfer
Sent: Wednesday, May 2, 2012 12:11 PM
To: Haynes, Tom
Cc: [email-masked]
Subject: [nfsv4] maintaining the errors list (was minorversion2-08 comments)

Haynes, Tom wrote:

> A second proposal would be to generate an IETF document that 
> encapsulated the error codes and the versions they were applicable. 
> The problem with this approach is that the document would have to be 
> respun per minor version.

Hmm.  The WG already publishes the XDR description as a separate document.  Would publishing a third document for the complete error table be a significant burden?

mike

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 2 May 2012 20:48:26 +0000

>I would rather not have a separate document for errors.

Mike does raise an interesting alternative, could we roll it into the XDR
document? I.e., this would be the machine generated document.

Or do we want to keep it pristine?

>document.  Would publishing a third document for the complete error table
>be a significant burden?
>
>mike