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

Looks good to me.

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
> Jari Arkko
> Sent: Friday, October 15, 2010 5:04 PM
> To: tcpm@ietf.org Extensions
> Cc: David Borman; Fernando Gont; Joe Touch
> Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06
> 
> 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.
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm