Subject: Re: [newtrk] Re: BCP 61, advancing to draft

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Mar 2006 15:05:14 +0100

C. M. Heard wrote:
> On Sun, 19 Feb 2006, Brian E Carpenter wrote:
> 
>>Well, I politely disagree, because there is also the twostep proposal
>>around, which I am hoping will shortly reappear with a new editor.
>>
>>My belief is that twostep is closer to the consensus that prevailed
>>at the newtrk BOF, i.e. it keeps the "running code" notion alive
>>but without creating unrealistic expectations.
>>
>>However, I'd certainly like to see a real debate between these
>>two approaches, which we've never had.
> 
> 
> Two points:
> 
> 1.) What we do today, most of the time, to put stuff to PS and leave
> it there.  Ergo, one-size-fits-all is closer to prevailing practice
> that twostep.

There are in fact a number of standards promoted to DS per year.
I can't quote numbers but I assure you it is more than none.

On balance I think that the interoperability report requirement
in draft-loughney-newtrk-one-size-fits-all-00 is too weak.
A two-step process provides at least some incentive to prove
interoperability.

But personally I'd rather document either one or two steps
than leave the present system festering.

> 2.) We still have the ludicrous situation of stuff like IANA procedures
> sometimes being put up for PS, when it should be BCP, since it cannot
> in principle enjoy multiple implementations.  I pointed out an example
> recently on this list.  one-size-fits-all cures this problem neatly.

Yes, by the same token as it reduces the incentive to respect the
'running code' motto. But I did read the relevant part of 2026 recently,
and it perfectly well allows data formats to be on the standards track.
What it doesn't say is that it's OK to stay at PS indefinitely.
(BTW, I've recently thought that we should rename PS to stand for
"Preliminary Standard.")

> 3.) I recently pointed out some examples in the MIB area where the
> multistep process resulted in fractured specs or needed work not
> getting done.  one-size-fits-all cures this problem, too

Indeed. Promoting MIBs does have downsides.

> 
> The "running code" notion sounds good, but we don't really practice
> it most of the time, have a hard time figuring out how in certain
> cases, and in other cases shoot ourselves (or the community) in the
> foot when we try.  We have a model of what we _can_ do.  That's
> one-size-fits-all.  Let's put it down on paper and get back to work.

But then we have to throw away the T-shirts. More seriously, we throw
away one of the reasons the IETF is different. I think we can fix the
problem without doing so.

     Brian (speaking for myself only)
> 
> //cmh
> 
> 
>>Spencer Dawkins wrote:
>>
>>>[C. M. Heard wrote:]
>>>
>>>>There is exactly one proposal on the table that would simplify the
>>>>process and make it more like what we really do, and that proposal
>>>>is draft-loughney-newtrk-one-size-fits-all.  I think the WG should
>>>>either adopt that proposal and send it out for IETF last call or
>>>>else admit defeat and close up shop.
>>>
>>>
>>>Hi, John,
>>>
>>>To be perfectly correct at this time, our draft would be a proposal 
>>>UNDER the table, since it expired in January.
>>>
>>>Do you still have the XML around for a respin? I'm not finding my own 
>>>copy (sorry!).
>>>
>>>Spencer
>>>
>>
> 
> 
> .
> newtrk resources:_____________________________________________________
> web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
> mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html
> 

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Mar 2006 11:26:52 -0500

--On Wednesday, 01 March, 2006 15:05 +0100 Brian E Carpenter
<[email-masked]> wrote:

>...
>> Two points:
>> 
>> 1.) What we do today, most of the time, to put stuff to PS
>> and leave it there.  Ergo, one-size-fits-all is closer to
>> prevailing practice that twostep.
> 

It not only provides that incentive, but provides a formal
statement by the IETF about the difference between something
that may have been approved without implementation or testing
and something that is considered implementable, tested, and
relatively solid.  As you indicated later in the note, without
that distinction, the IETF loses most of its justification for a
separate existence and ways of doing things.

> than leave the present system festering.

I think "fester" is a little bit strong.  While I think the
discontinuity between what 2026 says and what we are doing is an
embarrassment, I am not aware of any convincing demonstration
that the present situation is causing any objectively-measurable
harm.

That said, please note that the "promotion" proposal was
carefully designed to permit fast-tracking documents from either
Proposed or Draft to Internet Standard.  If we eliminated Draft,
the promotion proposal would not change in any important way.
In particular, it would still be useful to have a procedure for
unsticking protocols for which there was wide deployment and
experience but whose documents were stuck at Proposed.

> (BTW, I've recently thought that we should rename PS to stand
> for "Preliminary Standard.")

I think that would be a considerable improvement, FWIW.

>...

.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 01 Mar 2006 17:57:39 +0100

> I can't quote numbers but I assure you it is more than none.
By RFC, not by STD (obviously):

Status	1999	2000	2001	2002	2003	2004	2005
-------------------------------------------------------------
PS	102	119	71	105	103	131	169
DRAFT	6	6	2	4	7	7	3
STD	3(*)	2	0	8*	3	0	1

(*) 3 in 1999 were SMIv2 6 in 2002 were SNMP

These are rough based on 10 minutes of scripting.  I could not go
back further because dates for 1998 and earlier seem to be blown
in the index I just rsync'd.

Eliot
.

---

From: Larry Masinter <[email-masked]>
Date: Mon, 06 Mar 2006 14:41:34 -0800

We're talking on the HTTP mailing list about what it would take
to bring HTTP to 'Standard'. So this is a current topic. For
Draft Standard, we tried to make sure that every feature had
two independent interoperable implementations FOR EACH ROLE
(i.e., two clients, two proxies, two servers). Although it was
possible to "Frankenstein" the protocol; certainly no implementation
did all of the features.

To get the full Standard, though, seems like it ought to
be a bigger hurdle. Certainly HTTP is widely deployed. However,
do the features in the spec match what is actually deployed?

The current 2026 isn't explicit on this matter. At some point,
if you want to know what people REALLY do with HTTP, well, you
get implementations of various HTTP servers, look at their
documentation, etc. Should full Standard documents only contain
features that are widely deployed?

Larry
-- 
http://larry.masinter.net

.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Mar 2006 15:27:07 +0100

> features that are widely deployed?

That doesn't seem to be an issue about a possible new standards
track, but since you ask here, my personal view is that the
words in 2026 can be taken literally - there is no stated requirement
for all features to be widespread.

A simpler solution to your problem would be for this WG to reach
consensus to abolish the third step :-)

     Brian

.