Re: [newtrk] new cruft draft due out today or tomorrow

[Tony Hansen <[e-mail]>]

Ok, here's another voice weighing in.

Consider how we move protocol documents FORWARD in the standards track.

   1)	Sometimes we issue new versions of an RFC while moving the
	protocol forward.
   2)	Sometimes we just recategorize an RFC.

However we DON'T publish:

    *	The reasons we think the RFC can be moved forward.
	These are discussed in mailing lists, which are usually archived
	somewhere.

    *	The interopability reports associated with how
	the protocol works between implementations
	These are discussed in mailing lists and sometimes published on
	web sites.

Note, we do NOT require an RFC that simply says "let's move RFC forward 
in status because of such and such."

Now consider the situation of moving a document to obsolete or historic, 
which are just other statuses on the standards track. Obviously there's 
no need to republish the actual RFC that's being downgraded.

Now, think about the why's and wherefor's of WHY the RFC is being 
downgraded.

Do we need to discuss why the action is being done? Absolutely. And this 
should be done in various mailing lists.

Do we need to publish yet another RFC just to say why we're changing the 
status of that RFC? Absolutely NOT.

To summarize, I have a serious problem with publishing any such 
documents as RFCs.

Here's an alternative suggestion for consideration on WHERE to put a 
summary of why an RFC was downgraded. 27 lines is sufficiently small 
that it could actually be stored in rfc-index.xml.

	Tony Hansen
	[e-mail]

Brian E Carpenter wrote:

> Well, I am the cause of a cruft case that will be on Harald's reading
> list soon, having submitted draft-carpenter-obsolete-1888-01.txt
> a few minutes ago.
> 
> There are 27 substantive lines of text explaining why RFC 1888
> is both OBE and broken, and 11 lines saying what the IESG,
> the remaining OSI proponents, and the IANA should do next.
> 
> On the one hand, 38 lines is a bit light for an RFC. On the other
> hand, this information clearly needs to be published somewhere,
> since RFC 1888 is cited surprisingly often. For the moment,
> another RFC is the only tool we have.
> 
>    Brian
> 
> Harald Tveit Alvestrand wrote:
> 
>>
>>
>> --On torsdag, september 16, 2004 09:10:06 +0300 Pekka Savola 
>> <[e-mail]> wrote:
>>
>>>> Only the protocols themselves have (mostly) consistently been recorded
>>>> as  RFCs.
>>>
>>>
>>>
>>> Yes, and now that we want to remove them from the standards track (or
>>> whatever track), it would seem to make sense to document the reason
>>> "why?".  The reason may be obvious, but such reasons are very easy to
>>> write down.
>>
>>
>>
>> Pekka,
>>
>> you and I are in perfect agreement that the reasons must be published, 
>> and the publication of the reasons must be archived.
>>
>> But you keep on insisting that these be published *AS RFCS*. I keep on 
>> insisting that this is not only unnecessary, it is a departure both 
>> from current rules and current practice with comparable decisions.
>>
>> Please make sure you argue against what I disagree with, and not 
>> against what I agree with.
>>
>> But I'd like to hear other voices here too. I think Pekka and I have 
>> made our opinions very, very clear by now...
>>
>>                          Harald
>>
>>
>> .
>> 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
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html