>-----Original Message----- >From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of >Fernando Gont >Sent: Tuesday, September 07, 2010 11:07 PM > >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 agree with Fernando, though I can see Keith's point that the blanket designation doesn't make the scope of the update as clear as a set of from/to changes to the specification would be. However, in this particular case, the document content is fairly clear, and I think Keith's point is more general to the process for updating RFCs rather than something to hang up this particular document on. The use of "Updates" here is consistent with other cases, and is the proper way to signal in the database that this document should be read by people implementing 793, though it doesn't obsolete 793. >>>> * 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. This is another problem larger than the document, but I can see that we might want to simply add a sentence in an appropriate place that says flipping the urgent bit in middleboxes by default does not seem to be advisable since some legacy applications may require it in order to use the OOB facility, and these will break, however it may have some security merits that make doing so desirable. I think whether or not a particular middlebox is configured to do this would have to be evaluated on a case-by-case basis as to whether what it breaks is more valuable than what it may save. Since OOB data is not part of the TCP specification, this is really a security BCP issue, and not something that really impacts TCP, so I don't think we would want to make any "requirement" or use 2119 type of language in discussing it here. >>>> 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". Agreed; an application is not properly using the specification if it does anything else. -- Wes Eddy MTI Systems _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf