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

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 5 Mar 2010 21:46:01 +0100

I would like to update the ftp64 draft before monday's deadline, but I haven't had good input as to the direction in which to make changes...

Please see my message from january 29th.

---

From: Dave Thaler <[email-masked]>
Date: Thu, 11 Mar 2010 03:35:47 +0000

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]]
> Sent: Friday, January 29, 2010 3:57 AM
> To: Dave Thaler
> Cc: [email-masked]
> Subject: Re: [BEHAVE] Comments on draft-ietf-behave-ftp64-00
> 
> 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.

It shouldn't be.  As Reinaldo also pointed out, our charter has:
> Jan 2010    Submit to IESG: FTP ALG for IPv6/IPv4 translation (std)  
                                                                 ^^^

That is, our charter milestone is to submit a standards-track specification
for an FTP ALG.

Any text about what an FTP client or an FTP server does or ought to do
would be informational text, but the FTP ALG specification should be
normative per our WG charter.

> 
> > 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...

[Dan answered this one previously]
> 
> > 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.

I was suggesting being explicit in the objection rather than just 
implying someone didn't like it.

Suggest:
OLD: The use of FTP application layer gateways for compatibility with 
OLD: IPv6-to-IPv4 translators is rejected by many within the IETF
OLD: community.

NEW: Many within the IETF community argue that the problem is better
NEW: solved by changing FTP clients and FTP servers rather than
NEW: using a translator.

(I believe the rest of the text reads fine after that.)

> 
> > 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.

I'd suggest:
OLD: However, the situation with regard to FTP servers and -clients, 
OLD: especially in IPv6-heavy deployments, may change fast, so within
OLD: relatively little time it may become feasible to stop running an ALG.

NEW: However, the situation with regard to FTP servers and -clients, 
NEW: especially in IPv6-heavy deployments, may change, at which time
NEW: it may become feasible to stop running an ALG.

I think the rest of the text (e.g. "Operators are encouraged to keep 
revisiting the issue.") then reads fine.

> 
> > 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.

See [DT6] above.  We need a normative specification for an FTP ALG.
(Any text about clients and servers should not use 2119 language but
FTP ALG text should use 2119 language.)

> 
> > 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?

I'd suggest:

OLD: In the second case, an implementation must have the ability to track
OLD: and update TCP sequence numbers when translating packets and break up
OLD: packets into smaller packets after translation

NEW: In the second case, an implementation MUST track TCP sequence numbers
NEW: and when the payload length is different after modifying control
NEW: messages, it MUST update the TCP sequence number in the translated
NEW: packets.

> 
> > 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.

That doesn't answer my question. But I believe your answer to [DT16] 
below does answer the question though.

> 
> > 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.

Great.

> 
> > 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.

If you consider an FTP ALG to have two functions (I'm not sure I get the
difference right now), then please define the two functions in section 2.

> 
> > Comment [DT22]: These need to be split into normative vs informative
> references
> 
> It's informational, there is no normative.

See earlier comments.

> 
> > 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?

The charter already requires us to have a standards track one
(for the FTP ALG behavior).

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

-Dave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 11 Mar 2010 15:40:23 +0100

> normative per our WG charter.

After significant discussion I just about managed to get the people who object against this whole ALG business on board with the argument that we tell people to update their clients and servers and provide ALG as a backup, making the ALG text standards track will almost certainly start a new round of objections.

Would it be possible to change or deviate from the charter in this case?

I'll put the RFC 2119 stuff back in as per Dave's earlier explanation and take care of the other stuff in the next version.

Iljitsch