Re: [ftpext] FTP64 LANGuage [was RE: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05]

[Dave Thaler <[e-mail]>]

Question to FTPEXT:

Given that many NAT44's that have FTP ALG don't allow LANG to work correctly,
and we haven't seen any responses from FTPEXT folks arguing that it's
important, should the Behave WG consider LANG support in RFC 2640 to be 
unimportant?  Is it basically dead?

If so, I'm fine with a SHOULD in the FTP64 doc.   And I agree with Iljitsch's
implication that the recommendation for FTP64 ALGs should be the same
as whatever the recommendation for other FTP ALGs (e.g. in NAT44's) is.

-Dave

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[e-mail]]
> Sent: Wednesday, January 05, 2011 6:19 AM
> To: Dan Wing
> Cc: Dave Thaler; [e-mail]; [e-mail];
> 'Behave WG'
> Subject: Re: FTP64 LANGuage [was RE: [BEHAVE] one week WGLC, draft-ietf-
> behave-ftp64-05]
> 
> On 3 jan 2011, at 21:38, Dan Wing wrote:
> 
> > For whatever it's worth, I checked the FTP ALG for NAT44 in Cisco's
> > IOS, and it does nothing special with LANG (it doesn't block the
> > command nor parse the FEAT response).  We have other ALGs in other
> > products (e.g., Linksys, ASA), but I did not check those.  Our bug
> > database (which spans all Cisco-branded products) has no customer
> > complaints about FTP's LANG support.
> 
> Apparently nobody else can muster up the energy to care about this.
> 
> I'm ok with adding a SHOULD for supporting LANG in the ALG so that if a server
> and client negotiate a non-default language the ALG also participates. This
> assumes the ALG supports the negotiated language, but I'm thinking that if the
> server and client support a non-default language, there's a good chance that the
> ALG vendor either added this language too, or allowed sufficient customization
> for the user to do this. The ALG only has 10 or so responses that it can generate,
> after all.
> 
> But for the reasons I outlined earlier, I'm still very reluctant to make this a
> MUST. Seeing as the FTP44 ALG people apparently managed to do without this,
> such a requirement runs a big risk of becoming a dead letter, anyway. There's
> enough of that when it comes to FTP specifications...
> 
> Iljitsch