[rfc-i] Comparatively minor questions on the motivations
Glenn at RiverOnce.com
Wed Dec 22 21:37:36 PST 2010
On Dec 21, 2010, at 6:47 PM, Sandy Ginoza wrote:
> Below are a few quick (personal) comments about the motivations document.
> - From Section 3.3.1
> "The I* has grown sufficiently large and complex that issues which appear to be simple
> are often very subtle, and their resolution may have far-reaching conclusions sensitive to
> the particulars of the decision. For the RFC Editor, someone has to own that effort. The
> point person must vet it past experts, bring it to the community, anticipate the
> consequences of the different options, and be insightful at finding a suitable outcome
> when the right choice may be far from obvious."
> 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, which is partly why I advocate for an RSE that is familiar with the RFC series and the networking community.
There will be simple cases now and then. And when the issues are simple, even a new RSE will be able to get quick "Just go ahead and do X" guidance from the REOC with little fuss. Within a small number of months, a new RSE would begin to get the simple cases on their own, even if they were from outside the community. So, this doesn't appear to be a very strong case for requiring in 'insider' as RSE - although prior knowledge will always be a plus.
However, as with most planning exercises, plans have to take into account the harder or problematic cases. This is what I have focused on. And for that, greater expertise is required. However, prior familiarity with the RFC Series and the networking community is not really required; there are so many folks around (often including RCP staff, plus the RSAG and incoming REOC) that that knowledge will always be easily found. This has been resoundingly confirmed by my experience as TRSE.
> - From Sections 5.1 and 5.2
> "The Style Manual as it stands is insufficient to direct substitute editors in case of an
> unexpected break in service. The Manual should be reorganized, consolidated, and
> updated as necessary. This should include a part-by-part review for currency and
> "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.
I completely agree and argue exactly that point in my recommendations: the RSE must be knowledgeable enough to support additional editing resources in understanding the Style and Procedures Manuals. Both are required - a savvy RSE and up to date, complete documents. Still, one wants the documents to stand on their own as much as reasonably possible, within the limits of time and money.
From V2 Overviesw, the 2nd to last sentence is key:
220.127.116.11. Operational Continuity
Operational continuity means consistent, uninterrupted RFC
production. The RFC Series Procedures Manual is the primary document
for maintaining operational continuity.
If editorial services are disrupted, the RFC Series Editor, with the
support of the IAOC, is responsible for promptly acquiring and
directing new resources to maintain RFC output. Service from new
teams of editors or additional contractors may be acquired. The RSE
must keep the RFC Editor Procedures Manual and Style Manual up to
date to provide sufficient direction to alternate editors. The
Series Editor must maintain sound understanding of those processes in
order to direct new resources when required. Maintaining editorial
output during a disruption is referred to as "exceptional continuity".
> - From Section 5.6
> "5.6 Consider Supporting RFC Clusters and Enhanced RFC Annotation
> At present, if one wishes to know the relationships between various RFCs, one has to
> read the metadata and ‘walk’ from RFC to RFC. Also, despite the enormous body of
> knowledge in the community, there is no commonly available facility that describes:
> clusters of RFCs and their relationships (a ‘cluster’ is any collection of RFC that
> are of interest to someone who has collected information on them),"
> 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.
I am sympathetic to your point. I recommend that, if and when the Editor goes ahead with this idea, the then-RSE and REOC should review if another term is in order. I chose this (see earlier mail on this list) because one of the folks working in this area was already using it. Maybe a leading noun is in order to distinguish each.
I hope these answers were useful to you.
> On Dec 21, 2010, at 12:52 PM, Dave Thaler wrote:
>> I just finished reading the motivations document, and have some additional
>> clarifying questions, which are minor compared to the questions Olaf and Ted
>> 1) A half-time appointment would presumably lead to the RSE having something
>> else for the other half-time. However, Section 2 states "This person must
>> have no other interests." Can you clarify to reconcile these two statements?
>> 2) I still find it confusing as to what "consent" of the REOC really means in
>> practice, in this proposed model. What happens if they don't consent, or
>> if they have no consensus on whether they consent? (This is actually more
>> a comment on the model than on the motivations, but the motivations
>> discusses it and doesn't answer it for me.)
>> 3) I found Sections 4.2.1 and 4.2.5 (and to some extend 3.2.1) to be confusing,
>> arguably contradictory, with respect to whose job it would be, in your
>> recommendations, to lead various review meetings.
>> BTW, I found the motivations draft far more clear than the model draft
>> on what your recommendation is for the RSAG. This at least answered
>> my confusion on that point.
>> rfc-interest mailing list
>> rfc-interest at rfc-editor.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rfc-interest