Subject: Re: [tcpm] urgent data draft (draft-gont-tcpm-urgent-data-01.txt)

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 11 Jun 2009 12:58:29 +0200

I supported this in the meeting, and still do.

I think a statement that this not recommended for new applications (3) 
is good, combined with (4).

Best wishes,

Gorry

David Borman wrote:
> I think I forgot to follow up on this, sorry!
>
> So, with my WG co-chair hat on:
>
> The agreement at the San Francisco IETF meeting on the Urgent Pointer 
> definition was:
>
> 1) Adopt this document as a WG item
>
> 2) Change the definition of the Urgent Pointer (defined in RFC 1122) 
> to match the definition on page 17 of RFC 793, which is what most 
> implementations use.
>
> 3) New applications should be discouraged from using the Urgent Pointer
>
> 4) TCP implementations still need to implement the Urgent Pointer for 
> existing applications that use it
>
> 5) All applications that do make use of the Urgent Pointer must use 
> the SO_OOBINLINE socket option to keep all of the data in sequence; 
> applications that don't use SO_OOBINLINE and continue to use the old, 
> broken BSD implementation that actually removes bytes of data from 
> data stream are out of scope for the IETF, since that is not part of 
> the TCP protocol.
>
> Please respond with whether you do or do not support adopting this as 
> a WG item, even if you were at the meeting, so that we have a record 
> on the mailing list.
>
>
> Now with my WG chair hat off:
>
> I support adopting this as a WG item.
>
>             -David Borman, TCPM WG co-chair
>
>
>
> On May 19, 2009, at 10:01 AM, Fernando Gont wrote:
>
>> Hello, folks,
>>
>> I'm planning to work on a revision of the urgent data I-D anytime soon.
>> I was wondering if there are any plans for proceeding with this I-D.
>>
>> There was some discussion on-list about TCP urgent data, and IIRC Dave
>> Borman had suggested (hat off) that this I-D be adopted as a WG item.
>>
>> Thoughts? Plans?
>>
>> Thanks!
>>
>> Kind regards,
>> -- 
>> Fernando Gont
>> e-mail: [email-masked] || [email-masked]
>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 Jun 2009 10:39:14 -0700

I'm wondering about #2. It's worth noting that implementations don't
follow the specs, but I'm getting increasingly concerned about
continuing to publish docs that say "implementations don't follow spec"
without actually either saying "and the spec is hereby changed" or "and
implementations are noncompliant and should be fixed".

While I agree that both #3 and #4 are the most important
recommendations, I propose that the WG should decide how to address whether:

	1) decide whether to update 1122 and clarify 793 (as
	standards track)
	or to reiterate 1122 and indicate existing implementations
	noncompliant

	I don't really care which of these is picked; given
	#3 and #4, it wouldn't really matter much, but I do
	feel strongly that the WG should NOT ignore this aspect.

	2) decide whether the doc is standards track (if changing
	1122) or BCP

	IMO, BCP is required based on #3 and #4 (i.e., it's not
	about whether existing impls. are incorrect, so much
	as advice on how to proceed or the future). If 1122
	is changed, then the doc needs to be standards track,
	which covers the "BCP" advice in 3 and 4 anyway.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 Jun 2009 20:22:43 -0700

Fernando Gont wrote:
> Joe Touch wrote:
> Joe, you had agreed with #2 at the meeting we had in Minneapolis. What
> changed since then?
>
> P.S.: As there is no practical difference between "points to the last
> byte of urgent data" vs. "points to the byte following the last byte of
> urgent data", and since all implementations do the later, it does make
> sense to change the specs. You had agreed with this reasoning at MPLS.
> -- I'm now puzzled.

I didn't see in Gorry's note anything about saying we were changing the
specs. As I said, I don't really care whether we change the specs or
declare the implementation incorrect in general. If we've already agreed
that this will be a standards track update to 1122, that's fine (I just
didn't see it mentioned in Gorry's note).

In general, we should always *try* to take a stand when implementations
differ from the standard. This looks like a case where that's possible,
so I was just noting that we should do so.

Joe

---

From: David Borman <[email-masked]>
Date: Tue, 23 Jun 2009 09:11:46 -0500

Yes, the intention is to  change the definition.  It was my note, and  

> to match the definition on page 17 of RFC 793, which is what most  

So, no ambiguity intended, we change the spec to match the  
implementations.

			-David Borman

On Jun 22, 2009, at 10:22 PM, Joe Touch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Fernando Gont wrote:
>> Joe Touch wrote:
>>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Jun 2009 14:59:40 -0300

Joe Touch wrote:

> specs. 

David Borman had sent a note
(http://www.ietf.org/mail-archive/web/tcpm/current/msg04548.html)
clarifying of each of the points draft-ietf-tcpm-urgent-data was making.
And that of changing the specs to match the implementations was in that
list.

> so I was just noting that we should do so.

I'm still puzzled, Joe. In Minneapolis you had stated exactly the
contrary: that in this particular case, considering that the
implementations differ from the specs, and that there is no real
difference the UP pointing to the "last byte of urgent data" vs "the
byte following the last byte of urgent data", it did make sense to
change the specs to match the implementations.

It gets so hard to agree (or even argue) with you when you change your
opinion so frequently, and in such a radical way.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Jun 2009 19:05:01 -0700

Fernando,

> And that of changing the specs to match the implementations was in that

That email says "2) Change the definition of the Urgent Pointer (defined
in RFC 1122) to match the definition on page 17 of RFC 793, which is
what most implementations use. "

I was clarifying that this would be a standards-track change to the
specs; I didn't recall that language having been used in this discussion.

> change the specs to match the implementations.

Implementations differing from requirements yields three options:

	a) document the difference as Informational, and nothing more

	b) document the implementation as non-compliant

	c) document the implementation as preferred as an
	update to the original requirement (standards track)

I was hoping we could engage the WG in having a discussion on these
three options in general.

> opinion so frequently, and in such a radical way.

I have been - and remain - opposed to preferring an implementation to a
standard primarily on the basis of implementation. There have to be
other considerations, notably the impact to the protocol, impact to
users, etc. That means I prefer (b) in general, of the above.

In this particular case, I don't really care whether it's (b) or (c). If
I agreed to (c), it was only because I would also agree to (c).

In *general*, I think that (b) or (c) should be preferred to (a), but
also believe that most of the time that means (b). This is a case where
all known implementations differ from the standard AND where neither the
standard nor the known implementation methods have a particular benefit.
That's quite different from other cases you've brought to this WG.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Jun 2009 19:05:31 -0700

Thanks, that does clarify things.

Joe

David Borman wrote:
> Yes, the intention is to  change the definition.  It was my note, and I
> thought that's what I said:
> 
> So, no ambiguity intended, we change the spec to match the implementations.
> 
>             -David Borman
> 
>