[rfc-i] Comparatively minor questions on the motivations

Dave CROCKER dhc at dcrocker.net
Wed Dec 22 13:12:06 PST 2010


Sandy,

On 12/21/2010 3:47 PM, Sandy Ginoza wrote:
> It's true that issues that sometimes appear to be simple turn out to be
> larger issues that require community discussion, but there are a number of
> instances in which the issues that appear to be simple really are simple, and
> a decision can be made without much external discussion. Imo, an individual
> with enough RFC- and IETF-specific knowledge can identify the complex and
> simple issues more easily,

I do not understand how your observation alters the point that Glenn was making, 
namely that there are complex and challenging issues that
arise and that need a range of experience and skills that go beyond what is
needed for solving simple problems.  Having specific background about RFCs and
the IETF is, of course, helpful.  But the underlying concern is for skillsets
that go beyond this.

Familiarity with an environment does not ensure that one is skilled as solving
particular and serious problems that can arise in that environment.  (I am the
most "familiar" with my car, but I am most certainly not qualified to replace 
its transmission...)



> "The Style Manual as it stands is insufficient to direct substitute editors
> in case of an unexpected break in service.
...
> "As previously identified, the Procedures Manual, along with the Style
> Manual, is the core device for ensuring quick guidance of alternate editors
> in case of an unexpected interruption in service."
>
> I agree that the style and procedures manuals can provide quick guidance, but
> I do not believe editors can learn to edit and publish RFCs strictly by
> reading the manuals.

In their current form, of course not, but that's exactly the issue.  (And it's 
not a criticism of anyone, other than our group failure to make it a requirement.)

These are routinized operations activities, subject to formal rules, policies 
and the like.  It therefore is possible to document them quite extensively and 
certainly far more than has been done.  In fact, it is a matter of standard, 
competent operations management to ensure that such complete documentation exists.

That's far more than "quick guidance".

It should be possible to take a brand new editor, hand them these documents, and
have them learn enough to start doing the job.  As I understand the current 
state of documents, they are very far from that level of completeness.


> * ** "5.6 Consider Supporting RFC Clusters and Enhanced RFC Annotation
...
> Please do not redefine "cluster" as this word is already defined on the RFC
> Editor pages; please see http://www.rfc-editor.org/cluster_def.html.
> Overloading this term is cause for confusion, especially for newcomers.

Well, this is interesting.

I wonder how many people know that the RFC Editor has reserved and defined this 
term?  I also wonder how someone is supposed to have found out about it?  A 
google of "rfc cluster ietf" discloses the page you cite only far down a page of 
pointers.  It's probably possible to make the existing definition page harder to 
find, but not much...

Also, does this mean that RFC 6027's title was erroneously allowed?

FWIW, Glenn got the term from me, for a project I've been working on for some 
months and that will eventually feed into the IETF.  I've been discussing it 
with various highly experienced IETF folk, none of whom appear to be aware that 
the word is reserved.

And also FWIW, the way I (and Glenn) use the term is actually similar to the way 
it is defined.  The difference is document status, while retaining the issue of 
document relationship.

d/
--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


More information about the rfc-interest mailing list