Subject: [nfsv4] minorversion2-13 - server-side copy comments

From: <[email-masked]>
Date: Wed, 1 Aug 2012 17:28:49 -0400

Section 2.4.1.3 contains some text that I originally suggested to Tom
about how to make the URLs for the non-RPCSEC_GSSv3 case difficult to
guess:

   The name component after _COPY is 24 characters of base 64, more than
   enough to encode a 128 bit random number.

It would be a good idea to provide some guidance on how many bit of
randomness to use.  128 bits is not an unreasonable default - I was
thinking about whether to recommend something smaller, and that doesn't
seem like a good idea, so:

   The name component after _COPY is 24 characters of base 64, more than
   enough to encode a 128 bit random number, and at least 128 bits of
   randomness SHOULD be used.

I would also add some guidance about removing the validity of these URLs,
so at the end of the section, please add:

   Access via the URLs specified in this section SHOULD NOT be allowed
   for an arbitrary period of time.  If the destination server does not
   contact the source server within a reasonable period
   of time to begin the copy (e.g., 30 minutes), access via the URLs
   created for that copy operation SHOULD be permanently withdrawn. 
   A similar timeout SHOULD also be used to detect the completion of
   the copy or abandonment of a partially complete copy and withdraw
   access via the URLs for that copy.

The latter sentence could use some discussion - I'm favoring a timeout
approach over functional detection of copy completion (e.g., every block
read in order) in order to provide some robustness to a destination server
crashing at the wrong point in time (e.g., reads everything, but crashes
before all the data hits stable storage, but-but saved the URLs and
can complete the copy after it restarts/reboots).   

Nit: Remove the use of capitalized "MUST" and "MUST NOT" in section
2.4.1.1 - those terms are for implementation requirements, not the
design requirements given in this section.

Thanks,
--David

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 1 Aug 2012 23:13:28 +0000

>   randomness SHOULD be used.

"is" implies "MUST" to me. The text should come across as a suggestion and not a mandate.

>   created for that copy operation SHOULD be permanently withdrawn. 

This is something the client can detect via COPY_STATUS and have the source fence off the file. As a matter of fact, the client and source together can detect a destination server other than the intended one.

>   access via the URLs for that copy.

I really dislike the addition of new timeout values. As sure as we add this as a suggestion, someone will take 30 minutes to be a hard number that must be used by all servers.

I also really dislike adding pseudo-security measures as hacks. If you want security, avoid AUTH_SYS.

In any event, I do think we need to add some discussion on the lifetime of the URLs. I had been thinking the client could remove them from the namespace once it detected the start of the copy (non-NFSv4.x copies would not access them again). It isn't clear that the destination is expected to remember a COPY operation was in progress.

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

---

From: <[email-masked]>
Date: Thu, 2 Aug 2012 11:54:30 -0400

> "is" implies "MUST" to me. The text should come across as a suggestion and not

That is how I wrote the text - that "is" describes the example.  Here's a
slightly clarified version:

   The name component after _COPY in the above URLs is 24 characters of
   base 64, more than enough to encode a 128 bit random number.  At least
   128 bits of randomness SHOULD be used in URLs for server side copy.

> This is something the client can detect via COPY_STATUS and have the source
> fence off the file. As a matter of fact, the client and source together can
> detect a destination server other than the intended one.

I disagree with placing this responsibility solely on the client.  The
server should close down access if it's clear that nothing useful is going
on.

> I really dislike the addition of new timeout values. As sure as we add this as
> a suggestion, someone will take 30 minutes to be a hard number that must be
> used by all servers.
> 
> In any event, I do think we need to add some discussion on the lifetime of the
> URLs. I had been thinking the client could remove them from the namespace once
> it detected the start of the copy (non-NFSv4.x copies would not access them
> again). It isn't clear that the destination is expected to remember a COPY
> operation was in progress.

I'll look at that text when it appears.  OTOH, a failure that causes the copy
not to start does need to be timed out, although I'm not strongly attached to
30 minutes as a typical timeout value.

Thanks,
--David

> -----Original Message-----
> From: Haynes, Tom [mailto:[email-masked]]
> Sent: Wednesday, August 01, 2012 7:13 PM
> To: Black, David
> Cc: <[email-masked]>
> Subject: Re: [nfsv4] minorversion2-13 - server-side copy comments
> 
> 
> This is something the client can detect via COPY_STATUS and have the source
> fence off the file. As a matter of fact, the client and source together can
> detect a destination server other than the intended one.
> 
> 
> I really dislike the addition of new timeout values. As sure as we add this as
> a suggestion, someone will take 30 minutes to be a hard number that must be
> used by all servers.
> 
> In any event, I do think we need to add some discussion on the lifetime of the
> URLs. I had been thinking the client could remove them from the namespace once
> it detected the start of the copy (non-NFSv4.x copies would not access them
> again). It isn't clear that the destination is expected to remember a COPY
> operation was in progress.
> 
> 
>