On Sep 7, 2010, at 7:29 PM, Fernando Gont wrote:
Hi, Keith,
Thanks so much for your feedback! Please find my comments inline...
The document revises the specifications for sender and receiver handling
of TCP urgent data, presumably in order to improve interoperability.
Actually, it resolves a disconnect between the specifications and
virtually all implementations of the urgent mechanism.
Yes, but you're also recommending a change from what the existing
specifications say to do. So, in effect, your intent is to revise the TCP
specification.
In
particular, sections 5 and 6 of this document impose RFC 2119
requirements (SHOULD NOT / MUST) on applications.
However,
* 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. When we say we're
"updating" existing RFCs, what we mean is that we're changing the overall
recommendations and/or requirements that were specified in those RFCs, to
something different.
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'm
just asking you to make it clear that you're revising the TCP specifications,
and thus imposing requirements on new TCP implementations, in addition to
whatever other requirements you impose on applications or whatever.
(In making that clear, there's no need to use RFC 2119 language if you don't
find it appropriate to do so. But the only purpose of RFC 2119 language is to
specify requirements. So in the current draft, it's really clear that you're
imposing requirements on applications, and less clear that you're imposing
requirements 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.
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.
IETF documents in general need to make it clear that intermediaries that alter
IP packets (other than TTL) are violating the IP protocol - i.e. they are not
making a best effort to deliver the packet intact - and this is harmful to the
Internet. "Simply deciding to clear a bit" is deliberate data corruption.
I can understand temporary ad hoc measures that are employed to address known
security vulnerabilities, but they need to be understood - and documented - as
just that. There need to be mechanisms for cleaning up these temporary
measures, for recommending that they go away when better fixes are in place.
Ironically, by not documenting such temporary measures (along with the problems
that they address, and the new problems that they cause), there is a tendency
for such measures to become even more entrenched than our well-documented and
-reviewed protocol standards.
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 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)
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.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf