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

[Joe Touch <[e-mail]>]

Hi, all,

FWIW, this skirts the key questions:

1) should this doc include any particular 2119 language on the urgent 
option?

	- IMO, it should not repeat or restate existing requirements
	- based on the note from Jari, I can't tell whether the
	doc is recommending SHOULD NOT for new apps or not

	if it is, then the doc should definitely be revised to
	lead with that issue; if not, then such revision isn't needed

2) how should this doc address the in/out of band issue?
Right now, it explains it solely by reference to the implementation of a 
Unix API. That doesn't seem sufficient, as per the note I already posted.

It'd be useful to understand what the note below says to these two points.

Joe

On 10/15/2010 2:41 PM, David Borman wrote:
> Jari,
> This seems to be a reasonable compromise for the differing points of view, and a way to get past this issue.  Thanks.
> 			-David
>
> On Oct 15, 2010, at 4: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 feat
ure.
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>