Subject: RE: [newtrk] Erata in ISDs problematic

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 10 May 2005 08:55:40 -0700

Sam, 

	I strongly agree, but the only way to realistically fix this is
to move to some form of document automation.

	Imagine for a moment that we decide to replace the IETF with a
Wiki for the protocol document. OK we quickly realize the limits of the
Wiki ideology (imagine MARID being run on those lines) but imagine for a
moment that we have some moderation process in place and some form of
version identification.

	The documents become living documents that reflect the protocol
being used.

	To make the scheme work however I think you need to go a long
way down the document automation route and you have to change the way
that standards are written to make the process a lot more formalized.
Adopting formal design methods, requiring state machine models to
acompany the spec etc.

		Phill

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sam Hartman
> Sent: Tuesday, May 10, 2005 11:08 AM
> To: [email-masked]
> Subject: [newtrk] Erata in ISDs problematic
> 
> 
> 
> 
> Hi.  I have some personal comments beyond what the IESG came 
> to consensus on.  There may be some people on the IESG who 
> disagree with me on these comments; there are certainly 
> people who agree.  The discussion at the retreat focused on 
> other issues we all felt were more important and so we did 
> not fully explore our position on these issues.
> 
> 
> I think including erata to published RFCs in ISDs is very 
> problematic and strongly oppose doing so.  I am even more 
> opposed to using ISDs as a mechanism for removing features 
> from standards that have not been widely implemented.
> 
> As an implementer of IETF standards documents and someone who 
> has engaged in interoperability testing, I find that as the 
> number of documents involved increases, the clarity of 
> implementers' understanding decreases.
> 
> I don't find implementers are generally in the habit of 
> checking RFC erata.  I don't think ISDs will tend to be 
> consulted more often.
> 
> Also, the approval process required for an ISD will be 
> approximately the same for a new RFC.  If the problems have 
> been identified and sufficient text written and we're going 
> through a full approval process then just publish a new 
> document.  If RFC publication is too slow, work on that 
> problem not on creating new infrastructure.
> 
> 
> My concern is also based on hundreds of years of experience 
> with a similar system: acts of legislative bodiies.  AT least 
> in the United States, legislatures tend to pass diffs rather 
> than passing new laws. This is easy for the legislatures but 
> is difficult for those trying to use the law.  It's 
> sufficiently difficult that an entire office in the US 
> federal government has been developed to apply these diffs to 
> the US Code and produce a current
> (presumed-authoritative-until-evidenc-presented) set of laws.
> 
> I think all the pressures that make amendments problematic 
> for the legislative system would apply to ISDs for all the 
> same reasons.  I hope we'll be approving a lot fewer ISDs 
> than the US government approves laws.  Even so I think the 
> same problems would apply to us. Without a similar mechanism 
> to keep patched copies of RFCs around I believe the proposal 
> of erata in ISDs is unacceptable.
> 
> --Sam
> 
> .
> 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