Subject: [nfsv4] server-side copy offload I-D version -02

From: James Lentini <[email-masked]>
Date: Wed, 15 Apr 2009 11:07:43 -0400 (EDT)

An updated NFS server-side copy offload draft is available at:

 https://datatracker.ietf.org/drafts/draft-lentini-nfsv4-server-side-copy/ 

This update includes an expanded overview with additional diagrams and 
clarifies the security issues discussed on the mailing list last week.

-james

--
James Lentini | NetApp | 781-768-5359 | [email-masked]

---

From: Tom Haynes <[email-masked]>
Date: Wed, 15 Apr 2009 18:25:46 -0500

Glad to see you took out the confusing example for COPY_REVOKE.

----

page 5:

   diagram) that does not include the client.  The protocols allow the
   client to setup the copy between the servers (over network
   10.11.78.0/24 in the diagram) and for the servers to communicate on
   the high speed network if they choose to do so.

You only have 1 protocol:

The protocol allows the

-----------

page 10:

   address.  If the netloc4 is of type NL4_URL, the URL [RFC3986] of
   server appropriate for the server-to-server copy operation is
   specified at a UTF-8 string.  If the netloc4 is of type NL4_NETADDR,

'the URL of server' doesn't read very well. Is something missing?

Also, shouldn't it be 'as a UTF-8 string' ?

And since I'm being picky:

   When netloc4 values are used for an inter-server copy as shown in
   Figure 3 , their values may be evaluated on the source server,

No space after 3.

------------

page 17:

   The COPY operation may fail for the following reasons (this is a
   partial list).  In the event of a failure the state of the
   destination file is implementation dependent.

Either reverse the order of the sentences or put the second sentence 
after the list of
errors.

Or label the list and have a reference to it in the first sentence.

---------

page 22:

   The standard security mechanisms provide by NFSv4 [RFC3530] may be
   used to secure the protocol described in this document.

   NFSv4 clients and servers supporting the the inter-server copy
   operations described in this document are REQUIRED to implement
   [RPCSEC_GSSv3], including the RPCSEC_GSSv3 privileges copy_from_auth
   and copy_to_auth.  If the server-to-server copy protocol is ONC RPC
   based, the servers also REQUIRED to implement RPCSEC_GSSv3 privilege
   copy_confirm_auth.  NFSv4 clients and servers are RECOMMENDED to use
   [RPCSEC_GSSv3] to secure server-side copy operations.

I don't see how the two paragraphs are compatible. The first states that 
you do not need to
use RPCSEC_GSSv3 and the second states that you do need to use it.

---------

page 27:

I'd like to see a couple of sentences that describe how the source 
server is going to
identify the destination server if a COPY_REVOKE arrives.

----------

page 28:

   server fails to verify the privilege, the COPY operation will be
   rejected with NFS4ERR_PARTNER_N_AUTH.  All subsequent ONC RPC

_NO_AUTH

----------

page 29:

   multi-homed source and destination servers.  In a multi-homed
   environment, the destination server may not contact the source server
   from the same network address specified by the client in the

"may not" implies to me that we want to prevent it.

"might not" implies to me that it does not have to.

------

---

From: James Lentini <[email-masked]>
Date: Thu, 16 Apr 2009 09:22:59 -0400 (EDT)

Thank you for the feedback Tom.

Replies below:

> You only have 1 protocol:

Right.

Yes. This should be "the URL of the server".

> Also, shouldn't it be 'as a UTF-8 string' ?

Yes.

>   Figure 3 , their values may be evaluated on the source server,

Right.

> Either reverse the order of the sentences or put the second sentence after the
> list of
> errors.
> 

We'll clarify this by reversing the sentence order.

> I don't see how the two paragraphs are compatible. The first states 
> that you do not need to use RPCSEC_GSSv3 and the second states that 
> you do need to use it.

The text is stating that clients and servers MUST implement 
RPCSEC_GSSv3. They are RECOMMENDED to use RPCSEC_GSSv3, but not 
REQUIRED. This is analogous to the NFSv4.1 spec's RPCSEC_GSS text in 
Section 2.2.1.1. To clarify, I will add a sentence like the one in the 
NFSv4.1 spec:

 This requirement to implement is not a requirement to use.

> ---------
> 
> page 27:
> 
> I'd like to see a couple of sentences that describe how the source server is
> going to

Ok

Right

Yes, that is a good idea.