Re: [tcpm] poll for adopting draft-gont-tcp-security

[Joe Touch <[e-mail]>]

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



Lloyd Wood wrote:
> On 4 Jul 2009, at 22:01, Joe Touch wrote:
>> Lloyd Wood wrote:
>>> On 4 Jul 2009, at 20:27, Joe Touch wrote:
>>>>
>>>>>> If you care that much about the implementations,
>>>>>> then change them. It'd be more productive than simply documenting
>>>>>> what
>>>>>> has been implemented instead.
>>>>>
>>>>> Implementation experience is an important input to developing and
>>>>> refining an IETF standard.
>>>>>
>>>>> The IETF standard can't be defined wholly on paper theoretically de
>>>>> jure, or wholly in implementations de facto. There's a meeting in the
>>>>> middle - hence
>>>>> consensus and code.
>>>>
>>>> Please review sec 9.1 of the TAO of the IETF.
>>>
>>> You might want to reread that. From section 9.1 of the Tao of the IETF:
>>>
>>> 'One of the oft-quoted tenets of the IETF is "running code wins"'
>>
>> You need to quote the entire passage:
> 
> Quoting it at all rather misses the philosophical point that Tao can never
> be adequately expressed in words, what? [section A.1 barely touches
> on this paradox.]

So you complain when I quote it in its entirety, but respond by further
quoting it out of context?

>> Implement -- Write programs that use the current Internet standards. The
>> standards aren't worth much unless they are available to Internet users.
>> Implement even the "minor" standards, since they will become less minor
>> if they appear in more software. Report any problems you find with the
>> standards to the appropriate Working Group so that the standard can be
>> clarified in later revisions. One of the oft-quoted tenets of the IETF
>> is "running code wins", so you can help support the standards you want
>> to become more widespread by creating more running code.
>>
>> I.e., to support the standards, make running code. Notice it doesn't say
>> doing things the other way around.
> 
> It does: "Report any problems you find with the standards to the
> appropriate
> Working Group so that the standard can be clarified in later revisions."

Clarifying a standard is what happens when the standard has an
ambiguity. Problems you find can be found in many ways.

None of that says "change the standards to match implementations". None
of that says that "code wins over standards".

> And those problems are found with the implementations.

That's one of many ways problems have been found.

> The standard is not immutable. The standard is not set in stone.
> The standard can be revised. (Much as the Tao of the IETF is
> revised.) There's a feedback loop. And, in that loop,
> running code wins.

Please re-read the paragraph above. It says to write code to support the
standards you want to become more widespread, not to write code to
support changes to the standard that you want to them justify as
evidence that the standard should be changed.

...
>>> (If TCPM doesn't take on this work, then TCPM is irrelevant, and the
>>> IETF likely abdicates any authority it had on TCP. Still, there's
>>> always adding new stuff to SCTP, eh?)
>>
>> You're basically claiming that RFC2525 was a waste of time.
> 
> I claimed no such thing. (And in 1999, when RFC2525 was published, the IETF
> was reaching its peak meeting attendance, indicating that it was more
> relevant as an organisation And TCPM didn't yet exist.)
> 
>> I disagree.
> 
> You're disagreeing with a strawman position that you invented for me.
> 
> RFC2525 is informational, which is an approach that draft-gont could take.

2525 doesn't need to be more than informational; it didn't change the
standards (it reiterated them, essentially). Straying from the standard
means either standards track (to change the standard) or BCP (to explain
ways to apply SHOULDs/alternates in the standard to an environment). And
2525 talks about how implementations vary from the standard, not
implementation issues that a standard never addresses (nor should it).

> The difference here is that we're documenting problems with the written
> documentation, not with the implementations - i.e. the inverse of 2525.
> The feedback loop also goes the other way. The aim is to keep documents
> and code close together. Either can be changed. In this case, changing
> the documentation to match widespread practice in a mature
> protocol makes a lot of sense.

...
>> and decide what position we
>> should take. No, I don't think TCPM's charter is to run around trying to
>> standardize or, worse, document without taking a stand, every place
>> where implementation differs from standard.
> 
> Surprised you didn't quote the charter here.

I'll wait for you to show me where in the charter it explains that we're
here to document and standardize implementations, rather than to decide
what's better for the future of TCP.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpRhjcACgkQE5f5cImnZrug7QCgjNhvaPZECGACEhgJH4xvpFkK
T0MAoJ5U++FcYym1sE9gvRwJ2bGAK/0z
=/yHf
-----END PGP SIGNATURE-----