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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fernando,

Fernando Gont wrote:
> Joe Touch wrote:
> 
>>> 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. 
> 
> 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.

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.

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

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.

> 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, 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpBic0ACgkQE5f5cImnZrv8LwCeN3sTndvEvMZEgerb4C68W5dq
VVcAn2N0zTdmhF1OWN8TXs9wwvGy9KGB
=8yG1
-----END PGP SIGNATURE-----