On Sep 7, 2010, at 11:06 PM, Fernando Gont wrote: Hi, Keith, * 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.
RFC's that update other RFCs explicitly indicate so in the front page. So I don't see there's a conflict with the use of the term "Updates".
I wouldn't call it a conflict. More like a lack of clarity. To me, the document reads as if you're imposing more of a burden on applications than you are 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.
I guess the rationale is that any intermediary that clears e.g. the URG bit is violating the specs. So the advice would be "don't violate the specs". An I really doubt it that even if you had RFCs that explicitly required intermediaries to not do these things (e.g. clear bits in the TCP header), they wouldn't mind.
Well, something's wrong, because we keep writing documents that describe how to work around problems caused by intermediaries, but mostly not trying to fix the actual problems. 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.
I agree. But the world is... what it is. Once those boxes are there (deployed), you cannot assume the mechanism is reliable. Cisco Pix, a widely deployed device, clears the URG bit. Hence I don't think you can assume that the urgent mechanism is reliable anymore.
Serious question: What can an application assume is reliable any more?
Firewalls second-guess apps, and apps second-guess firewalls. Maybe the right thing for everybody to do is not try to second-guess what kind of brain damage Cisco or anyone else is going to put into their products, and just expect the Internet to work as it was intended. That way, when such products break things, it will be very clear that it's those vendors' responsibility to fix it, and not the apps developers.
Granted, there's a lot worse breakage out there than clearing the URG bit, because not many applications use TCP urgent data.
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)
Applications that are processing "urgent data" as "out of band" data area already violating the specs -- hence the "MUST".
Ah, I think see what you mean. But aren't you essentially requiring the application developer to work around a bug which might or might not be present in his network stack, using an API feature that might or might not be present? What bugs me about that it's sort of out of the control of the application developer.
Keith
|