On Sep 7, 2010, at 7:29 PM, Fernando Gont wrote: > Hi, Keith, > > Thanks so much for your feedback! Please find my comments inline... > > >> The document revises the specifications for sender and receiver handling >> of TCP urgent data, presumably in order to improve interoperability. > > Actually, it resolves a disconnect between the specifications and > virtually all implementations of the urgent mechanism. Yes, but you're also recommending a change from what the existing specifications say to do. So, in effect, your intent is to revise the TCP specification. >> In >> particular, sections 5 and 6 of this document impose RFC 2119 >> requirements (SHOULD NOT / MUST) on applications. >> >> However, >> >> * No requirements are imposed on TCP implementations. > > The "requirement" on TCP implementations is in Section 4 (page 7). > However, it doesn't use RFC 2119 language as the text that it is > updating (RFC 793, RFC 1122) doesn't use RFC-2119, either. Mumble. I really don't like the term "updating" when referring to existing RFCs because we don't change the text of those RFCs. When we say we're "updating" existing RFCs, what we mean is that we're changing the overall recommendations and/or requirements that were specified in those RFCs, to something different. The point here is that your draft doesn't actually make it very clear that you're revising the TCP specification. I get the impression that you are assuming that there's no actual need to change the specification, because most existing implementations already behave according to your recommendation. I'm just asking you to make it clear that you're revising the TCP specifications, and thus imposing requirements on new TCP implementations, in addition to whatever other requirements you impose on applications or whatever. (In making that clear, there's no need to use RFC 2119 language if you don't find it appropriate to do so. But the only purpose of RFC 2119 language is to specify requirements. So in the current draft, it's really clear that you're imposing requirements on applications, and less clear that you're imposing requirements on TCP stacks.) >> * This document also does not place any constraints on >> intermediaries, even though the document itself acknowledges that >> intermediaries interfere with operation of the TCP urgent facility. > > No TCP specs that I know of accommodate packet scrubbers or firewalls > that simply decide to clear a bit, etc (except for NATs, which are a > completely different issue). When they do (e.g., ECN), it's to > discourage such behavior. Mumble. This is obviously a lot bigger problem than just this one document. But it is a huge problem that IETF has, and (because it's so limited in scope) your document is as good a place as any to start addressing it. IETF nearly always takes a "somebody else's problem" view with respect to intermediaries. IETF will impose requirements on endpoints, or make recommendations for endpoints, to work around harmful behavior of intermediaries. But IETF rarely imposes requirements on intermediaries, or makes recommendations for intermediaries to follow. There are lots of problems with this approach, not the least of which is that IETF is in nowhere nearly as good a position to communicate to application developers, as it is to communicate to vendors of intermediaries. Another reason I believe this approach is unsound, is that it constantly shifts the burden of coping with violations of the Internet Protocol to endpoints - host stacks and applications - to the point that there is very little that endpoints can safely assume about the behavior of the network anymore. IETF documents in general need to make it clear that intermediaries that alter IP packets (other than TTL) are violating the IP protocol - i.e. they are not making a best effort to deliver the packet intact - and this is harmful to the Internet. "Simply deciding to clear a bit" is deliberate data corruption. I can understand temporary ad hoc measures that are employed to address known security vulnerabilities, but they need to be understood - and documented - as just that. There need to be mechanisms for cleaning up these temporary measures, for recommending that they go away when better fixes are in place. Ironically, by not documenting such temporary measures (along with the problems that they address, and the new problems that they cause), there is a tendency for such measures to become even more entrenched than our well-documented and -reviewed protocol standards. Obviously you're not going to be able to address this whole problem in a document about TCP urgent data. But if it's reasonable for your document to impose requirements on applications, it's even more reasonable for your document to impose requirements on intermediaries. >> I also note that section 6 imposes a MUST requirement on applications >> that depends on a non-standard TCP sockets API feature (SO_OOBINLINE) > > I guess this could be rephrased as "applications that still decide to > employ it MUST process the "urgent data" in-line, as intended by the ETF > specifications (e.g., by setting the SO_OOBINLINE socket option)"? Pretty much. Assuming, of course, that the host stack and API used by the application actually have the ability to do that. (maybe you should just make it a SHOULD for that reason) > >> 5. Add a informative section discussing the pros/cons of IP-level >> intermediaries altering the URG bit. >> 6. Add a normative section which states that IP-level intermediaries >> SHOULD NOT alter the URG bit. > > I don't think that tcpm is going to get consensus on "pros" of altering > the URG bit. Perhaps not, but my concerns are addressed to the entire IETF, and hopefully IESG will also give them careful consideration. Keith _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf