Re: "why I quit writing internet standards"

[Miles Fidelman <[e-mail]>]

Thomas Clausen wrote:
> On 16 Apr 2014, at 16:01, Wesley Eddy <[e-mail]> wrote:
>
>> On 4/16/2014 9:31 AM, Thomas Clausen wrote:
>>> FWIW, my personal belief is that "running code" should be a
>>> requirement for anything going std. track -- and that a (mandatory)
>>> period as Experimental prior to go std. track would yield the stable
>>> spec against which to reasonably build code, and run
>>> (interoperability) tests, fix bugs, etc. If after (pulling a number
>>> out my hat here) a year as Experimental there's no running code, then
>>> that's probably a good indicator, also, as to if this is something
>>> the IETF should bother doing....
>>>
>>
>> If there's no running code, or pretty concrete plans and commitments
>> to get there, then there's really no need for an Experimental RFC that
>> will get a number and last forever.  An I-D that expires in direct
>> conjunction with the interest and energy in it is just fine.
>>
>> Experimental RFCs are for things that we're encouraging folks to get
>> out and play with in multiple implementations,
> Isn't that *exactly* what we want to see happen before we propose things as standards?
>
> I think that Spencer's thesis was that it didn't happen because "implementing towards something that isn't stable and which expires" (and I-D) wasn't attractive, and the bar for std.track was too high, so "something with a lower bar, which is stable and archival, but which isn't a PS" would be helpful?
>
> That "something" could conveniently be Experimental.
>
> Experimental exists already, and the experiment targeted (at least, the RTG ADs insist on Exp RFCs carrying an explicit section describing that) would simply be "to build a few implementations and see if they interoperate". (Of course, things with "sharp edges" or "things to figure out" would have a different "The Experiment" section ... )
>
> The only required "process change" would be, that ADs treat "Experimental" as "Experimental" in their evaluation, and not at std. track (which they, currently, do).
>
>> perhaps on the real
>> Internet or under some specific conditions, but which may have sharp
>> edges or explode on impact, and need a bit more work to figure out
>> if we can seriously recommend the world to depend on them as Standards.
> Fair enough, but almost orthogonal to the point I am trying to make: going std. track without running code (it has happened, and it is happening) makes even less sense than going experimental without running code.
>

With DMARC as a really clear-and-present example of the dangers of not 
being more explicit about the process.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra