Subject: [nfsv4] Draft 32 of NFSv4.2

From: Thomas Haynes <[email-masked]>
Date: Wed, 4 Mar 2015 23:34:12 -0800

Hi,

I’ve updated the drafts with the copy stateid discussion and also updated that OPEN with CLAIM_FH can be used instead of the URL.

Spencer, I’m now caught up with all of the discussion. Can we please push this document and RPCSEC_GSSv3 forward to the IESG as planned?

Thanks,
Tom

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 5 Mar 2015 14:58:39 +0000

Thanks, Tom.  Any objections in moving this into our AD's queue on the way to IESG review and IETF last call?

Spencer

> -----Original Message-----
> From: nfsv4 [mailto:[email-masked]] On Behalf Of Thomas Haynes
> Sent: Wednesday, March 4, 2015 11:34 PM
> To: NFSv4
> Subject: [nfsv4] Draft 32 of NFSv4.2
> 
> Hi,
> 
> I’ve updated the drafts with the copy stateid discussion and also updated
> that OPEN with CLAIM_FH can be used instead of the URL.
> 
> Spencer, I’m now caught up with all of the discussion. Can we please push
> this document and RPCSEC_GSSv3 forward to the IESG as planned?
> 
> Thanks,
> Tom
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Adamson, Andy" <[email-masked]>
Date: Thu, 5 Mar 2015 15:09:08 +0000

> On Mar 5, 2015, at 9:58 AM, Spencer Shepler <[email-masked]> wrote:
>
>

I still don’t know why OPEN is called in the COMPOUND in section 4.10.1.2.  Inter-Server Copy via ONC RPC without RPCSEC_GSS. I can resolve this today with a call to Tom.  Otherwise it is OK with me.

—>Andy

>> this document and RPCSEC_GSSv3 forward to the IESG as planned?

The information contained in this message and in any attachments is privileged and confidential, and may contain personal data. It is intended only for the use of the addressee. You should not read, copy, use, or disclose this information without authorisation. If you are not the intended recipient of this message, please e-mail the sender immediately and delete this message. Any unauthorised dissemination, disclosure, copying or use of the contents of this message is strictly prohibited and may result in legal action, including civil or criminal proceedings.

NetApp-Disclaimer-v1.1

---

From: Chuck Lever <[email-masked]>
Date: Thu, 5 Mar 2015 10:24:04 -0500

> Thanks, Tom.  Any objections in moving this into our AD's queue on the way to IESG review and IETF last call?

What about the issue of how URLs are used?

“nfs://“ is an NFS URI. You can’t call that a COPY URL and ascribe
alternate semantics to it, IMO. Likewise, the use of the “ftp://“
URL seems non-standard.

I think that section needs some work before it is suitable for
publication.

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

---

From: Tom Haynes <[email-masked]>
Date: Thu, 5 Mar 2015 09:00:45 -0800

> On Mar 5, 2015, at 7:24 AM, Chuck Lever <[email-masked]> wrote:
> 
> 
> On Mar 5, 2015, at 9:58 AM, Spencer Shepler <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> 
> “nfs://“ <nfs://xn--hvg> is an NFS URI. You can’t call that a COPY URL and ascribe
> alternate semantics to it, IMO. Likewise, the use of the “ftp://“ <ftp://xn--hvg>
> URL seems non-standard.

These are not generic URLs, the context of being in COPY modifies
the meaning. I.e.,

   On port 9999 there would be a special
   instance of the FTP service that understands how to convert NFS
   filehandles to an open file descriptor (in many operating systems,
   this would require a new system call, one which is the inverse of the
   makefh() function that the pre-NFSv4 MOUNT service needs).

The key here is that the destination and source servers are running
specialized services (hack, hack) that understand the format and
understand there is a NFS FH being used.

A normal NFS client might not be able to use the given URL to
successfully open the file.

>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>
> 
> --
> Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Thu, 5 Mar 2015 12:24:04 -0500

> understand there is a NFS FH being used.

My reading of RFC 3986 is that this “hack” will not be acceptable
for a standard because you are re-using existing URI scheme names
that already have well-specified semantics for path components.

Andy’s argument about implementors wanting to reuse code that
constructs and parses URIs (or state IDs) is also relevant.

But, why not let this doc move forward and see what the IESG says
about it? If they don’t have a problem with it, then I don’t either.

> successfully open the file.

You can fix this by using standard URIs but insisting that the
source server prepare a pseudo filesystem exported only to the
destination server. The pseudofs namespace would contain the
special FH-based path you have invented for COPY URLs. That
preserves the semantics of existing URI schemes while allowing
you to use the special COPY URL form described in the document.

Alternately, a new “copy://“ URI scheme could be invented where the
destination server can specify the transport, nonce, client IP, and
FH using URI query components (RFC 3986 section 3.4).

---

From: Tom Haynes <[email-masked]>
Date: Thu, 5 Mar 2015 12:16:54 -0800

Andy and I got together and hammered out the new copy stateid.

It was also time to take out the NFS URL processing as the protocol had enough to
do it without using them.

I took Olga’s enum change and Jorge’s COPY result change.

Enjoy!