Subject: [nfsv4] draft-ietf-nfsv4-rfc3530-migration-update-xx

From: "Noveck, David" <[email-masked]>
Date: Mon, 4 Feb 2013 10:46:56 -0500

It is about ten weeks since I posted draft-ietf-nfsv4-rfc3530-migration-update-00.  Since there have been no issues with it reported, one could argue that I'm entitled to conclude that it is just about perfect :).

Seriously, I realize that presuming perfection in the absence of evidence is not the right course.  Since this has now made the initial transition to a standards-track document, I'd like people's help in pointing out issues and potential issues with the document.  Please send mail to the group if you think something is wrong, dubious, or insufficiently clear.  If you've read it, and think it is OK as is, saying so is worthwhile as well.

I'm going to produce a draft-ietf-nfsv4-rfc3530-migration-update-01 in time for Orlando (i.e. by 2/25)

The following will definitely be in -01:

1.       Update to point to the latest draft of rfc3530bis.

2.       Standardization on "filesystem" as opposed to "file system" and "fs"

3.       Making the clientid-related stuff its own subsection within "migration and state"

4.       Adding a new  subsection in "migration and state" addressing migration of owner-related information (such as sequence numbers and sequence-associated reply information) for both openowners and lockowners.

I'd also like to address the following in  -01, if we can have a discussion of the issue on the list in time:

5.       In the existing document, particularly in the discussion of CLID_INUSE, our use of the term "flavor" is not so clear and I'm not sure what we want to do:

a.       Decide that everywhere we say "flavor" we mean "flavor or pseudo-flavor".

b.      Decide that everywhere we say "flavor" we mean exactly that and want to exclude pseudo-flavors as a possibility.

c.       Decide that a certain subset of the "flavor" references should be "flavor or pseudo-flavor".
I recall that someone (Bruce, I think) posted some stuff on the Linux nfs list that seemed relevant to this issue.  I'd like to be sure that what is in the document addresses any known security issues in this area, whether in the context of Linux or otherwise.

I can also incorporate additional minor changes in -01, but it's still worth starting the discussion of other issues now, so that we have the basis for a good -02 as soon as we can.

---

From: Saul Tamari <[email-masked]>
Date: Thu, 28 Feb 2013 13:56:21 -0800

Hi,

There is a case that I would like to see if we can address in your document.
Lets assume an NFSv4.0 server keeps its state information in stable
storage and there could be some error cases where access to this
state-storage temporarily fails.
The current RFC3530 wording doesn't provide a way for an NFSv4.0
server to temporarily postpone an OPEN op without having to advance
the owner's seqid.

A possible fix for this limitation would be to permit servers to
return NFS4ERR_DELAY for cfh-setting operations such as PUTFH which
must precede an OPEN in the COMPOUND request.
This way the client will know that the OPEN wasn't processed at all by
the server.

Would it be possible to add these error-code changes into your document?
Maybe its possible to add this to the bis or is it too late for that?

Thanks,
Saul

On Mon, Feb 4, 2013 at 7:46 AM, Noveck, David <[email-masked]> wrote:
> It is about ten weeks since I posted
> draft-ietf-nfsv4-rfc3530-migration-update-00.  Since there have been no
> issues with it reported, one could argue that I’m entitled to conclude that
> it is just about perfect J.
>
>
>
> Seriously, I realize that presuming perfection in the absence of evidence is
> not the right course.  Since this has now made the initial transition to a
> standards-track document, I’d like people’s help in pointing out issues and
> potential issues with the document.  Please send mail to the group if you
> think something is wrong, dubious, or insufficiently clear.  If you’ve read
> it, and think it is OK as is, saying so is worthwhile as well.
>
>
>
> I’m going to produce a draft-ietf-nfsv4-rfc3530-migration-update-01 in time
> for Orlando (i.e. by 2/25)
>
>
>
> 2.       Standardization on “filesystem” as opposed to “file system” and
> “fs”
>
> 3.       Making the clientid-related stuff its own subsection within
> “migration and state”
>
> 4.       Adding a new  subsection in “migration and state” addressing
> migration of owner-related information (such as sequence numbers and
> sequence-associated reply information) for both openowners and lockowners.
>
>
>
> I’d also like to address the following in  -01, if we can have a discussion
> of the issue on the list in time:
>
> 5.       In the existing document, particularly in the discussion of
> CLID_INUSE, our use of the term “flavor” is not so clear and I’m not sure
> what we want to do:
>
> a.       Decide that everywhere we say “flavor” we mean “flavor or
> pseudo-flavor”.
>
> b.      Decide that everywhere we say “flavor” we mean exactly that and want
> to exclude pseudo-flavors as a possibility.
>
> c.       Decide that a certain subset of the “flavor” references should be
> “flavor or pseudo-flavor”.
>
> I recall that someone (Bruce, I think) posted some stuff on the Linux nfs
> list that seemed relevant to this issue.  I’d like to be sure that what is
> in the document addresses any known security issues in this area, whether in
> the context of Linux or otherwise.
>
>
>
> I can also incorporate additional minor changes in -01, but it’s still worth
> starting the discussion of other issues now, so that we have the basis for a
> good -02 as soon as we can.
>
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Saul Tamari <[email-masked]>
Date: Thu, 28 Feb 2013 18:29:12 -0500

Hi again,

I checked bis25 and I see that in section 13.2 it lists NFS4ERR_DELAY
as a valid error for LOOKUP, PUTFH, PUTROOTFH and PUTPUBFH.
So I understand that we don't need a further change to the RFC, unless
this use case needs to be explained.

Thanks,
Saul