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

From: Fernando Gont <[email-masked]>
Date: Sat, 27 Jun 2009 20:10:14 -0100

FYI. It seems this one didn't make it to the list.

-------- Original Message --------
Subject: Re: [tcpm] urgent data draft (draft-gont-tcpm-urgent-data-01.txt)
Date: Wed, 24 Jun 2009 05:44:07 -0100
From: Fernando Gont <[email-masked]>
To: Joe Touch <[email-masked]>
CC: [email-masked], David Borman <[email-masked]>, 
[email-masked]
References: <[email-masked]> 
<[email-masked]> 
<[email-masked]>	<[email-masked]> 
<[email-masked]> <[email-masked]> 
<[email-masked]> <[email-masked]>

Joe Touch wrote:

> 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.

The abstract of the I-D itself says:

"This document updates the relevant specifications such that
    they accommodate current practice in processing TCP urgent
    indications...."

> 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.

We had already agreed to do "c". For instance, the document has been
adopted as a wg item, and is heading for std track.

>> It gets so hard to agree (or even argue) with you when you change your
>> 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, "c" is the safest thing to do. If you tried to
push "b" forward, you'd basically break the urgent mechanism (in those
scenarios in which it still works).

> 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.

Exactly. That's my point: this is an easy one... that's why I don't
understand why we don't focus on reviewing and improving the doc, so
that it doesn't take us years to ship it.

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1