Re: General Comments draft-ietf-behave-ftp64-00

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:iljitsch <at> muada.com] 
> Sent: Tuesday, May 11, 2010 12:31 AM
> To: Dan Wing
> Cc: 'IETF BEHAVE WG'
> Subject: Re: [BEHAVE] General Comments draft-ietf-behave-ftp64-00
> 
> On 7 mei 2010, at 17:33, Dan Wing wrote:
> 
> >> However, an ALG MAY be configured to forego EPSV to PASV 
> >> translation for certain servers.
> > .................................^
> >                          or certain clients.
> 
> Right.
> 
> > (for example, an FTP client might do all of this EPSV/PASV 
> magic, or might
> > send PASV if it knows it is talking through a NAT64 translator
> > [draft-wing-behave-learn-prefix].  I do wish there was a 
> way for an IPv6 FTP
> > client to declare it is "Smarter Than Your Average IPv6 FTP 
> client".)
> 
> What about repeating a command that has no side effects? Such 
> as issuing FEAT or NOOP twice immediately after logging in?

Might be worth considering.  Or a "NOOP DISABLE_FTP_ALG", with
some sort of positive response (from the ALG) if it agrees
to step out of the way.  Seems to be more hacky, though, but
something along these lines might be worth considering.  (special
uppercase/lowercase of the two NOOP commands that you suggested?)

> >> Also, an ALG MAY attempt to 
> >> determine whether a server can support EPSV file transfers 
> >> successfully. In this case, any failures to set up the data 
> >> channel TCP session or complete the transfer successfully 
> >> MUST result in using EPSV to PASV translation for that server 
> >> for a period of at least 7 days, and foregoing additional 
> >> attempts to use EPSV towards servers that are not know to 
> >> support EPSV for at least one hour. This one hour period MAY 
> >> be applied on a per-client basis.
> 
> > I feel that is too prescriptive.  FTP server could fail a 
> > transfer because of per-client bandwidth limits, per-client
> > connection limit, etc. -- and because of IP address sharing,
> > this could create a false positive about the FTP server's
> > support of EPSV.  I suggest removing the text starting with
> > "In this case" and just leave that "MAY attempt to determine"
> > as an implementation detail.
> 
> What I'm worried about is that an ALG may use simplistic 
> logic to do this and consistently fail, so the user doesn't 
> get anywhere. I can write some text that is less prescriptive 
> and just explains the problem, though.

Thanks.
-d