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
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
