Re: More labels for RFCs (was: what is the problem bis)

It kind of seems like we're thinking of this in a 20th-century,  
politburo sort of way.  "We, the illumnati, will decide whether this  
document is awesome."  Could we not just use RFC as a basic threshold  
of quality, then let the community provide open and ongoing feedback?   
Like, with voting buttons at the top of the HTML-formatted RFCs, or  
maybe a comment section at the bottom?
--Richard



On Oct 29, 2010, at 12:20 PM, Hadriel Kaplan wrote:

> On Oct 27, 2010, at 9:57 PM, Keith Moore wrote:
>
> > That's why I think we need a different set of labels, e.g.
> >
> > Protocol-Quality.  We need a statement about the perceived quality  
> > of the protocol described in the document.   (Is this protocol well- 
> > designed for the anticipated use cases, or does it have significant  
> > flaws (including security flaws)?)
> > Applicability.  We need a statement about the current applicability  
> > of the protocol described in the document.  (Is this protocol  
> > recommended for general use, not recommended except in specific  
> > corner cases, not recommended at all, or strongly discouraged?)
> > Document-Quality.  We need a statement about the perceived quality  
> > of the document itself and whether the protocol description seems  
> > to be sufficiently precise to permit implementations to  
> > interoperate.   (along with a pointer to errata.)
> > Maturity.  We need a statement about the amount of actual  
> > implementation and deployment experience that the protocol enjoys.
> > Completeness.  We need a statement about how accurately the  
> > document reflects what is currently believed to be good practice  
> > for implementation/use of that protocol, or whether effective  
> > implementation requires information not included or referenced in  
> > the document.  (e.g. effective implementation of SMTP generally  
> > requires some expertise in dealing with heavy loads caused by spam,  
> > looping, and denial-of-service attacks which aren't really dealt  
> > with in any of the relevant RFCs).
> > Last-Review-Date.  Date of the last review of these labels for this  
> > document.
> > These would go alongside the existing Updates and Obsoletes  
> > labels.  An Applicability-Statement could also be included.
> The problem with a labeling scheme like this is it's subjective.   
> "Updates" and "Obsoletes" are not subjective, and to determine  
> whether to apply those two labels is fairly easy.  Labels of the  
> form *-Quality would cause massive debate and need a WG-wide or  
> larger consensus agreement process, if you mean them to be formal  
> labels.
> For some of what you describe above, people already produce RFCs to  
> document - RFCs which deprecate a previous RFC, or enumerate issues  
> found, or BCPs, etc.  And obviously errata are already captured by  
> the RFC editor.
> What's missing I think is some way to remind/force readers of an RFC  
> to check for errata and updating/obsoleting RFCs, and how.  Since  
> it's a static document when published, I think the most natural way  
> would be to add to the boilerplate a sentence reminding the reader  
> to check for updates, obsoletes, and errata at "http://datatracker.ietf.org/doc/rfcXXXX 
> " where XXXX is filled in by the RFC Editor upon RFC publication.
> Or if you want to be really fancy, you could have the IETF auto- 
> create a Wiki type page for each RFC, that allows open community  
> wiki-input about quality and implementation/deployment experience  
> and such, with a big banner indicating the wiki content is not an  
> official IETF position.
> -hadriel
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf