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

On Oct 11, 2010, at 9:49 PM, Joe Touch wrote:

> Hi, all,
> 
> I can't speak for the IESG, but I can explain my reasoning:
> 
> The doc presents two pieces of info:
> 
> - update the spec
> - change use to SHOULD NOT
> 
> Given we don't have apps breaking all over the place, the second one seems to be more dramatic in its impact to the community. The document presents the second one in an almost ancillary way.
> 
> IMO, if this doc is really about updating the spec, and we don't really have issue with new uses of the feature, then the SHOULD NOT should be dropped.

From my viewpoint, the issue is to 1) make application developers aware of the problems cause by the potential of OS's having different definitions of the urgent pointer, and 2) tell them NOT to use the broken bsd socket() OOB mechanism, by setting SO_OOBINLINE.  The goal isn't to say that applications can't use the Urgent pointer, but to warn of the potential issues in a generic environment.

As you said, we don't have applications breaking all over the place.  Also, the goal of this document isn't to change all the current Urgent pointer implementations, but to match the spec to the majority of implementations.

The WG did not put forth this document to deprecate the Urgent pointer, but to clarify it and warn of the interoperability issues.

So perhaps the "SHOULD NOT" should be changed to a "MAY", meaning you can still use it, but be aware of the issues and make sure you design around them.  It is entirely possible to reliably make use of the urgent pointer in an application, even with different OS definitions.  The application can the test urgent pointer at the beginning of the connection by sending a known piece of data and observing how it gets delivered to the receiver, the application can then adjust accordingly and use it reliably.

Perhaps combine section 5 & 6 into a single section like:

5.  Advice on using and implementing the TCP urgent mechanism

  As a result of the issues discussed in Section 3.2 and Section 3.4,
  using the TCP urgent mechanism has the potential to be unreliable.
  New applications MAY use the TCP urgent mechanism, but should be
  robust against these issues.  In addition, applications MUST set
  the SO_OOBINLINE socket option, such that "urgent data" is delivered
  inline, as intended by the IETF specifications.

  TCP implementations MUST include support for the urgent mechanism
  such that existing applications can still use it.

			-David Borman

> 
> If the SHOULD NOT is kept, I can't see how it's not more prominent (and thus warrants doc restructuring as suggested).
> 
> Joe
> 
> On 10/11/2010 5:24 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
>> For what it's worth, I also agree with the position that David presented.  I don't think it's necessarily worth spending a lot of time and energy to debate, though.
>> 
>> ________________________________________
>> From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Lars Eggert [lars.eggert@nokia.com]
>> Sent: Monday, October 11, 2010 11:51 AM
>> To: Fernando Gont
>> Cc: draft-ietf-tcpm-urgent-data.all@tools.ietf.org; tcpm@ietf.org Extensions
>> Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06
>> 
>> ...
>> 
>>> (FWIW, me, I agree with David's position... but for obvious reasons I
>>> might be biased... hence my request for advice on how to proceed).
>> 
>> I'm mostly agreeing with David as well, but a significant fraction of the IESG does not.
>> 
>> Lars
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm