Re: [tcpm] draft-ietf-tcpm-urgent-data-06

[Peter Saint-Andre <[e-mail]>]

+1 -- that seems to be an accurate summary of what folks think this
document is saying or should be saying.

On 10/15/10 3:04 PM, Jari Arkko wrote:
> All,
> 
> We discussed this yesterday in the IESG conference call. I would like to
> summarize my thinking about it and suggest a way forward. (There are a
> few other ADs who have similar but perhaps not exactly the same
> thoughts, but I'm the one who representing these thoughts with the
> Discuss.)
> 
> The main concern is that at least in my view, urgent data seems pretty
> badly broken. It has potential interop problems if out of band mode is
> used, mismatch of recommendations wrt real world implementations that
> mostly use out of band mode as the default, etc. As far as I understand,
> when out of band mode is used the two end points have to agree about the
> semantics of the urgent pointer. It is reassuring that most
> implementations that you tested actually use the same semantics, but we
> an implementation that we do not know about or a middlebox could disrupt
> an application's understanding of the correct order and place of TCP
> data from the other end. With this background, I felt that the document
> stopped short of making clear enough recommendations about the use of
> this feature. In the IESG we talked about what the right level of
> "health warning" should be, and there were different opinions ranging
> from text at the beginning of the document to formal deprecation of the
> feature.
> 
> I have a proposal below that takes the warning text approach. Note that
> I'm not really changing anything substantive from what the document was
> already saying, but if we publish a new RFC on urgent indications, it
> seems reasonable to make it very clear that there are issues. If these
> changes were made to the document I would be happy to clear my Discuss,
> though I do know that Ron would probably would like to see an even more
> drastic action. What does the working group think?
> 
> Jari
> 
> Change Abstract:
> 
> OLD:
>   This document analyzes how current TCP implementations process TCP
>   urgent indications, and how the behavior of some widely-deployed
>   middle-boxes affect how urgent indications are processed by end
>   systems.  This document updates the relevant specifications such that
>   they accommodate current practice in processing TCP urgent
>   indications, provides advice to applications that make use of the
>   urgent mechanism, and raises awareness about the reliability of TCP
>   urgent indications in the current Internet.
> NEW:
>   This document analyzes how current TCP implementations process TCP
>   urgent indications, and how the behavior of some widely-deployed
>   middle-boxes affect how urgent indications are processed by end
>   systems. This document updates the relevant specifications such that
>   they accommodate current practice in processing TCP urgent
>   indications, raises awareness about the reliability of TCP
>   urgent indications in the Internet and recommends against the use of the
>   urgent indications (but provides advice to applications in case that
> they do).
> 
> Change Introduction:
> 
> OLD:
>   This document analyzes how some current TCP implementations process
>   TCP urgent indications, and how the behavior of some widely-deployed
>   middle-boxes affect the processing of urgent indications by hosts.
>   This document updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC
>   1122 [RFC1122] such that they accommodate current practice in
>   processing TCP urgent indications, provides advice to applications
>   using the urgent mechanism, and raises awareness about the
>   reliability of TCP urgent indications in the current Internet.
> NEW:
>   This document analyzes how some current TCP implementations process
>   TCP urgent indications, and how the behavior of some widely-deployed
>   middle-boxes affect the processing of urgent indications by hosts.
>   This document updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC
>   1122 [RFC1122] such that they accommodate current practice in
>   processing TCP urgent indications, provides advice to applications
>   using the urgent mechanism, and raises awareness about the
>   reliability of TCP urgent indications in the current Internet.
> 
>   Given the above issues and potential interoperability issues with
> respect to the
>   currently common default mode operation, it is strongly recommended that
>   applications do not employ urgent indications. Nevertheless, urgent
> indications
>   are still retained as a mandatory part of the TCP protocol to support the
>   few legacy applications that employ them. However, it is expected that
> even
>   these applications will have difficulties in environments with
> middle-boxes.