Subject: Re: [BEHAVE] review of draft-ietf-behave-ftp64-05

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 3 Nov 2010 19:41:54 +0100

I'm currently working on an update of the draft, I'll finish this tomorrow. Here some responses to earlier remarks in case anyone wants to disagree before then...

On 27 sep 2010, at 23:28, Dan Wing wrote:

>   document describes specifies a middlebox that may solve this
> ............^^^^^^^^^^^^^^^^^^^
>           remove duplicate wording

Check

>   necessary, clients and servers support EPSV successfully, such
> .................................^ 
>                                "to"

Check

> It seems useful to provide an Informational reference to the FTPEXT2 
> document at the end of the first sentence.

I did, and I removed the reference to the older liu draft.

>   go into transparent mode by issuing an AUTH or ALGS commands as
> .......................................^^
>                                 remove "an"

Check.

>      Where these words appear in lower case, they SHOULD NOT be	
> 	interpreted within the context of [RFC2119], but rather, in	
> 	accordance with regular English usage.

> I don't think that escape clause is useful.

Ok I'll remove it, but there are two lower case shoulds left in the document (and one in a reference):

Although these issues can and should be addressed by modifying, where necessary,

Should the IPv6 client issue an EPRT command

> Informational references:
> 
>   [Bernstein]
>              Bernstein, D., "PASV security and PORT security", 2000,
>              <http://cr.yp.to/ftp/security.html>.
> 
> is listed, but isn't referenced.  idnits complained about that.  IESG
> loves to run idnits, so we can't submit to IESG until that is fixed.

I'll see if there is a good place to refer to this or otherwise remove it.

>   that maps to the client's IPv6 address.  The port number must be
> ............................................................^^^^
>   preserved for compatibility with stateless translators.  For

> This should be an uppercase MUST; non-compliance with that sentence
> will break interoperability, right?

Right, made this upper case.

> Notwithstanding the escape clause in Notational Conventions,
> I see Section 12 (Timeouts and translating to NOOP) uses RFC2119
> language twice where it should really be uppercased:

We can have a discussion on whether it's useful to be able to use these terms in the normal non-2119 meaning, but I uppercased them here.

> I poked around a little bit but I couldn't find a citation for those
> recommendations.  They both seem reasonable, but if there is a citation
> that would strengthen them.

I can't think of anything relevant that already exists that I can point to. 30 seconds seems long enough, 4 minutes like for normal TCP in a NAT seems too long. But the actual number isn't all that important, as long as people know what to expect.