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

[Lloyd Wood <[e-mail]>]

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


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

And those problems are found with the implementations.
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.

(There's another argument on how the Tao is written for the  
inexperienced
in the IETF, and how citing it in the first place either indicates
inexperience, or that far too much faith is placed in the written word,
which is _so_ not Taoist, as noted above.

And, of course, the Tao is informational, and thus has no bearing on  
standards-
track docs, so a self-respecting standards wonk wouldn't use it in the  
first
place. Much less quote it. Quoting something that recognises that it
can't be encapsulated in words is really missing the point.

And, reflecting on the Tao, one can observe that the above paragraph  
sounds
awfully like the evangelism of Stallman's manifestos. Lots of do-this- 
for-us
imperatives. It's laying out the appropriate puritan work ethic to
be followed, which is certainly not Taoist. The document's a sham!)


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


> The WG needs to decide what we want (consensus - which means my voice
> counts as much as yours or Fernando's),

rough consensus, not vote counting. I think Fernando's voice, and his
experience in working with others to put together this and other  
documents
in the face of consistent opposition from you, speaks far louder than  
either
of our voices. He's far more credible than we are.


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


> In 1999 we had a backbone and decided between deployey* bugs (per  
> 2525)
> and things we wanted to change that weren't deployed (e.g., the TOS  
> bit,
> which was changed in RFC2873). All I'm asking

Constantly using the imperative tense is not asking.


> is that we do the same
> now, not just claim that deployed code is the basis of an appropriate
> position.

Deployed code is, at least, testable science.
A piece of a standard without code implementing that piece as  
specified is
merely religious dogma.
And yet you prefer the latter position?

(RFC2525 didn't touch on the TOS bits. False argument there.)

L.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.surrey.ac.uk/Personal/L.Wood/><[e-mail]>