Re: [BEHAVE] Comments on draft-ietf-behave-ftp64-00

[Iljitsch van Beijnum <[e-mail]>]

On 4 jan 2010, at 22:00, Dave Thaler wrote:

> My comments and suggested wording changes on this document are marked
> up in the PDF at 
> http://research.microsoft.com/~dthaler/draft-ietf-behave-ftp64-00.pdf

Thanks for the comments.

> Comment [DT6]: What about adding a reference to RFC 2119 and using 2119 language, especially for the ALG behavior section


I removed this because the document's intended status is now informational.

> Comment [DT8]: Move the URL to the references section.

If someone can point me to an example of the XML required for citing just a URL that would help a lot...

> Comment [DT9]: Can you say why? For example, is it still rejected even in cases where you cannot update clients/servers? Or is it rejected only in specific scenarios? What if you can update clients but not servers, or vice versa?


The feedback I got is that ALGs are evil and the proper way to do all of this is by updating servers and clients. The current document tries to balance that view with the one that ALGs are necessary in some situations and specifying how they work is helpful for interoperation.

Removing one or the other will probably make the document unacceptable for some subset of the IETF participants.

I'm not sure what kind of explanation you're looking for... Many people simply dislike ALGs, even in BEHAVE.

> Comment [DT10]: What evidence do you have that anything will change quickly? Are you saying that suddenly all the FTP servers on the internet might start working better? Or suddenly all the clients that might be accessing your network’s FTP servers might start working better? So far all evidence points to there being stragglers for quite some time, so I would disagree with this assertion.


Yes and yes. If a large vendor of both FTP clients and servers were to update both of these and push out the updates, the situation would radically change in less than a year. Of course this may or may not happen, but my point is that looking at the situation once and then never revisiting that is suboptimal.

> Comment [DT11]: SHOULD or MUST? (“should” is always ambiguous and hence “should” not be used :)


This is now informational, so there is no upper case, and there is no must.

> Comment [DT12]: It has to actually do it, not just be configurable to do it, right?


The ALG has to update sequence numbers when the payload length is different after modifying control channel messages. Is there a better way to say this?

> Comment [DT14]: What’s the alternative if it chooses not to follow this MAY? Just pass it through unmodified? Return an error? Something else?

If the ALG doesn't change all EPSVs into PASVs we still have the issue of servers that don't handle EPSV properly.

> Comment [DT16]: What’s the alternative? Just pass it through unmodified? Return an error? Something else?

I'll add that whenever a certain type of translation isn't implemented, the original commands and responses are forwarded unmodified unless otherwise specified.

> Is there are requirement that the translator and the ALG are on the same machine? If so, this needs to be stated earlier

No requirement. This is an implementation detail. The idea is that the ALG and the translator are different functions so it makes sense to refer to them by different names, even though they interact.

> Comment [DT22]: These need to be split into normative vs informative references

It's informational, there is no normative.

> 1)  In my opinion, the client/server recommendations should be moved 
> to a separate doc that goes through the app area. This document would 
> then be similar to RFCs 5382, 5508, 4787, and 5597. The title and 
> abstract of this document could then be updated to match the convention
> of that series.

I disagree with that. First of all, having two documents rather than one is just a reflection of IETF organization and doesn't help the consumers of our documents at all. It also means a lot of extra work.

More importantly, a new document would be published much later than this one, unless this one is delayed so publication can happen at the same time, which doesn't help our progress. So for some time there would only be ALG text and no server/client text out there, which would be harmful.

> 2) The ALG behavior should be specified using RFC 2119 language.  
> Currently the use of "should" is ambiguous as to whether SHOULD or
> MUST is meant in many places.

My understanding is that RFC 2119 language isn't appropriate in informational documents. Or are you suggesting that we make this standards track?

I would think the absense of an RFC 2119 reference would make the words "must" and "should" revert back to their dictionary meanings.

Iljitsch