Subject: RE: [newtrk] Comments on draft-klensin-newtrk-std-repurposing-00.txt

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 17 Aug 2004 11:30:38 -0700

At 9:57 AM -0700 8/17/04, Christian Huitema wrote:
>I like the simplicity. It pretty much matches the industry perception
>anyhow: once a document is published as a standard track RFC, we are
>pretty much expected to implement it, whatever the process says.
>
>But there is a practical problem. In many cases, documents are cleaned
>up a lot during the move from PS to DS. Ambiguities in the spec are
>reworded; arcane options are removed, etc. Can we achieve the same
>result with a single-stage process?

Yes, through the bundle process. A sample timeline:

1) RFCs 4123 and 4124 define the Foo protocol.

2) The IESG creates a bundle for the Foo protocol that has two 
elements, RFC 4123 and RFC 4124.

3) RFC 4567 updates and improves RFC 4123. Nothing is done to RFC 
4124 because it was perfect.

4) The IESG modifies the bundle for the Foo protocol to have two 
elements, RFC 4124 and RFC 4567. That bundle has a text description 
that says "This bundle used to be { 4123 && 4124 }".

As long as the bundle is easily searchable (and probably not be based 
on a single text file):

- A new implementer of Foo will know what to implement

- Someone who already implemented Foo who hears that Foo has been 
updated will have a single definitive source for what they are 
supposed to do now, as well as being able to see a bit of history

- Someone who implemented RFC 4123 without knowing it was part of the 
Foo protocol can find that 4123 has been updated by 4567 by searching 
for RFC 4123 and seeing that it appears in the "has been updated" 
part of the Foo protocol bundle.

--Paul Hoffman, Director
--VPN Consortium
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html