Subject: RE: [newtrk] A slightly different form of radical suggestion

From: "Robert Snively" <[email-masked]>
Date: Thu, 4 Aug 2005 09:22:33 -0700

Reading Avri's note below helped me clarify some of my
concerns about the 1 step vs multi step approach.

Let's suppose I am an implementor and am building to an
RFC.  I create that device and then test for interoperability.
The interoperability report is written, but, because other
implementations chose a different subset of the RFC, the
proposed standard leaves out some features that I thought
important, but another organization did not.  In addition,
the interoperability test may identify some required changes
to the document.  Now I have a proposed standard with which
I am not compliant.  Worse yet, in its promotion to 
internet standard, additional drift from my implementation
may take place.  Because the RFC is deprecated by the 
creation of the standard, my product is no longer compliant with
any recognized document.

If I had instead worked within a 1 step approach environment,
I would have been compliant with Revision 1 of the standard,
which has now gone through two other revisions.  However,
because I am compliant with revision 1, other organizations have
an authorized document to implement interoperability with
my devices and I have a smooth specification path to the
creation of interoperability with later revisions.  Not only
that, but I also have smooth specification paths to further
revisions if they later need to be created, instead of having
to start promoting a new set of RFCs to modify the standard.

To summarize, a one-step standards path leaves great flexibility
to bring in improvements and corrections without breaking back
compatibility.  A multi-step standards path creates obstacles
to creating a standard in the first place, then creates even
greater obstacles to evolution and correction of that document.

Robert Snively
+1 408 333 8135
[email-masked] 

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of avri doria
> Sent: Wednesday, August 03, 2005 10:18 AM
> To: [email-masked]
> Subject: [newtrk] A slightly different form of radical suggestion
> 
> 
> Hi,
> 
> In reading through all the ideas for change in the number of 
> steps that 
> RFCs take to go through the standardization process i have 
> come to the 
> personal conclusion that we should leave the overall process 
> as it is.  
> Now, this is rather radical for me, since i seem to be 
> recommending the 
> status quo - a position that is not so very normal for me.
> 
> But instead of a radical change in the process, I would like 
> to suggest 
> that what we need is a radical change in our behavior.  We should 
> follow the process we have and should perhaps make some policy 
> adjustments to enable the us to follow the process we have.
> 
> There have been lots of arguments about why it makes sense to have a 
> step that is easy to reach, a step that indicates experience and 
> maturity and one that indicates wide deployment and 
> stability.  I find 
> that i strongly value the 3 step process, at least in theoretical 
> terms.
> 
> The current process sort of calls for reviews.  I am not one 
> generally 
> in favor of demoting documents, but i do think there is value in 
> reviews, and some documents may deserve demotion to 
> historical. Reviews 
> might also be good for identifying problems impeding progress or 
> identify RFCs that should be  progressed, e.g. some documents 
> may have 
> the wrong status because they have reached maturity and should be 
> promoted along the track. I don't know if the IESG has the bandwidth 
> for this sort of work on an ongoing basis, but I expect that 
> they could 
> delegate the responsibility for analysis and for making 
> recommendations.
> 
> I also think there is a lot of merit in the argument that 
> when WGs are 
> closed on having achieved PS, it does not enable progressing the rest 
> of the way through the track.
> 
> So, if after another round of discussion about 1 step 2 step 
> we cannot 
> settle on a consensus change, perhaps then we can look at ways at 
> enabling the community to actually make the current process work.
> 
> a.
> 
> .
> 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: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 09 Aug 2005 11:09:12 +0200

--On torsdag, august 04, 2005 09:22:33 -0700 Robert Snively 
<[email-masked]> wrote:

> to the document.

That's a feature, not a bug.
It's an article of faith here that fixing bugs in the spec is a Good Thing.

> Now I have a proposed standard with which

Sure - it's compliant with the original RFC (unless you had to work around 
bugs). It's you who do the recognition.

> creation of interoperability with later revisions.

In both 1step and multistep, the later specifications obsolete the earlier 
specifications, methinks. And the original RFC remains published.
I don't see a difference.

>  Not only

I don't see the difference. A revised spec is a revised spec, and whether 
it's backwards compatible or not depends entirely on the nature of the 
revision.

> greater obstacles to evolution and correction of that document.

You may be right, but I don't see it from the arguments you make.

.