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". > 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 don't follow. The fact that this document updates the specs is even stated in the very Abstract of the document. I'll wait for others to comment on this issue.... >>> * 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. > 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. > 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'll let others weigh in... >>> 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". >>> 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. Fair enough. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf