ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-tcpm-urgent-data-06.txt> (On the implementation of the TCP urgent mechanism) to Proposed Standard

2010-09-07 22:12:58
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(_at_)gont(_dot_)com(_dot_)ar || fgont(_at_)acm(_dot_)org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf