[rfc-i] Comprehensive review of draft-iab-rfc-editor-model-v2-02

John C Klensin john+rfc at jck.com
Sat Jul 9 20:50:35 PDT 2011


I've gone carefully through this document.  I think it needs a
lot of work.  Some of that work is "just" editorial in nature:
there are typographic mistakes, grammatical issues, some
sentences that just don't make sense, and a lot of confusion in
structural sections like Acknowledgments and change logs.  One
can easily deduce the intent in most cases, but not in all of
them.  There are also a number of redundancies and a few
apparent contradictions.

My apologies in advance for the length of this note.  There are
a lot of issues, some quite significant.  I did consider
posting 30+ separate per-issue notes, but decided that would be
even worse and more burdensome.

I have focused particularly on issues that may have
consequences vis-a-vis our ability to recruit an RSE,
especially from among people who will actually analyze the
description rather than knowing the community well enough to
decide what can be ignored in practice.  (As you know, the IAB
has concluded, based on community input, that even levels of
community understanding much lower than needed to make that
determination should not be a requirement for the position.)
If nothing else, some of the issues identified below, even the
more editorial ones, will make it harder to fill the RSE
position because they make us look sloppy and disorganized
(unless we find a potential candidate who sees the RSE role as
a leverage point for "fixing" the IETF, another bad idea).
Worse, it is possible that they might create suspicions that
the documentation issues are hiding, however unintentionally,
additional disconnects about authority and responsibility,
reporting chains and the authority that goes with them, etc.

Note that a few of the issues raised below have been discussed
before and, I thought resolved, but that did not make it into
the text of the current draft of this document.

As with earlier drafts of "version 2" and with "version 1" the
document tries to strike a balance among a variety of
perspectives.  In a number of cases, I don't think that is
succeeding.  Let me give two examples, one (relatively) easily
resolved, the other not.

(A.1) Historically, the Independent Submission Process was an
integral part of the RFC Editor role, so integral that it not
only predates the stream concept that was introduced in RFC
4844 but that it predates the IETF itself (obviously including
the IETF's decision to use the RFC Series to publish its
standards and other outputs).  While RFC 4844 made it just one
"stream" among four, various documents through and including
RFC Editor Model Version 1 treated it as part of the the RFC
Editor Function with a loose reporting relationship to the RSE.
The current draft removes that reporting relationship entirely:
the ISE appears to be responsible to the IAB and the community
directly, not to the RSE or even the RSOC.  That is probably
correct, but it creates a situation in which including the
Independent Stream activities and management as part of this
document adds confusion and provides no value.  

Recommendation: Remove the Independent Stream material from
this document and put it into something separate.  I would
think the "something separate" should be an update or parallel
document for RFC 4846, providing the organizational structure
and arrangements where 4846 provides the document processing
model.  Making that change would significantly shorten this
document, make review and spotting difficulties more feasible,
and enable the ISE to evolve independently of the RSE and the
parts of the RFC Editor function that are more concerned with
final editing and documentation strategies.

Consistent with that recommendation, this review does not
include comments on Sections 2.2 or 3.2.

(A.2) There is language in the document that can be interpreted
in rather different ways by people (who are acting in good
faith) within the community.  A statement like "The IAB and
IAOC maintain their chartered responsibility as defined in
[RFC2850] and [RFC4071]", while certainly true, doesn't
actually provide much information because, as we have seen in
other discussions, the community contains widely different
opinions about how far those responsibilities, and the
authority that is presumed to go with them, extend.  

As one particular example to which I'm personally sensitive,
many of us took the discussions leading up to the IASA as
requiring that the IAOC confine itself narrowly to
administrative and financial issues and that it _never_ make
policy.  At most, it might formulate policy proposals for
review and possible approval by the broader community, but it
was questionable whether it --as compared to, e.g., the IESG--
should even set itself up as a determiner of consensus.  When
one reads RFC 4071 through the lens of that history, the
"chartered responsibility" (and accompanying authority) of the
IAOC is extremely limited.  By contrast, in the last half-dozen
years, a number of people have taken the quite reasonable
position that the IAOC's responsibility for the financial and
administrative welfare of the extended IETF community gives it
sweeping authority, via the "power of the purse", to create and
impose policies and determine styles of doing things.  Neither
of those positions are inherently wrong.  If they need to be
resolved, this document is not the right place to do it.  But,
while using a statement like the one quoted above may make both
those who think the IAB is ultimately in charge of the RFC
Editor and those who think the IAOC must control anything that
costs money (including the RFC Editor Function) happy because
they read it as they prefer, it sets up a future opportunity
for disputes and may scare off potential RSE candidates who
don't want to get into a "too many masters and a dispute
between them about boundaries" situation.

The difficulty with that particular "maintain their chartered
responsibility" statement could be reduced by adding a sentence
to the effect that this document provides authoritative
interpretations of those responsibilities (i.e., that neither
interpretations of the IETF Charter nor of the IASA Structure
documents take precedence over anything this document actually
does specify), but the general problem remains... and you need
to specify whatever is important, not just assume that the
statement provides significant information because it does not.

More specific issues (more or less in the order in which they
appear in the draft):

(B.1) Abstract and Introduction: Experience

This document does not represent only "a year of experience",
certainly not if you are going to say "The RFC Editor model was
first approved in October 1, 2008 and has evolved since".
Either claim almost three years of experience, drop the "one
year" assertion, or explain where that number comes from.  I
contend we learned at least as much from the advice we got from
experience between the October 2008 publication date, including
the process of trying to recruit an RSE during 2009 and early
2010, as we did subsequent to March 2010, much less since July

Note the interaction between the above and the second full
paragraph of the Introduction, where you write "The model set
forth below is the result of those discussions and the
experience gained since, as described immediately below,..."
and "This version of the document also reflects the
discussions, as described below, that have occurred since the
first efforts to clarify that internal organization" because it
isn't clear "since what or when", nor who is responsible for
the conclusions.  You then go on to say "This version of the
model is based on his recommendations and the subsequent
discussion on the rfc-interest list".  That is probably the
most accurate of this group of statements, but it is redundant
at best and contradictory at worst.

Further complicating things, the fourth full paragraph of the
Introduction says "In order to gain experience with 'running
code' a transitional RFC Series Editor was hired who analyzed
the managerial environment and provided recommendations".
First, enough constraints were placed on the TRSE that it is
not clear that "experience with 'running code'" applies --
perhaps the text should say "In order to gain a better
understanding of what was needed, a transitional...".  More
important, if we really have such recommendations from the TRSE
and this version of the document is based on them, then they
need to be published somewhere for community information (or
included as an appendix to this document).  I haven't seen them
in any form coherent enough to base changes to a document on
(and I'm an insider in that regard).  If this draft isn't
dependent on those recommendations, don't claim that it is; if
it is, the community needs to see them.

(B.2) Editorial: Abstract

* "persons" should almost certainly be "people".

(B.3) RFC Editor Model description in the Section 2

The text of this section is inconsistent with the figure.  If
the model consists of the the components as listed, then get
the Streams out of the figure or show them as a "Streams" box,
ideally distinguishable from the other boxes, and say that the
Streams and their relationship to the RFC Editor Function are
described in RFC 4844 and not altered by this document.
Conversely, if you want to include the Streams and their source
and/or approval bodies in the picture, you need to make the
relationship to the text in RFC 4844 very clear (e.g., whether
this changes 4844 in any way).

The potential confusion here is reinforced by a sentence in the
Abstract: The sentence "The Internet Architecture Board (IAB)
oversight by way of delegation to the RFC Series Oversight
Committee (RSOC) is described, as is the relationship between
the IETF Administrative Oversight Committee (IAOC) and the
RSOC." implies that the IAB is involved only via a delegation
to the RSOC.  Maybe that is ok, but the picture shows (I
believe correctly) the ISE as reporting to the IAB, not the
RSOC, and the IAB as a Stream.  Of course, getting the ISE
discussion out of here and the Streams off the picture, as
suggested above, would eliminate that particular problem.  

Independent of the substance, that sentence is very hard to
read for someone who is not immersed in the rest of the
document and its terminology.  Almost by definition, that is
not the audience for an Abstract.

(B.4) Editorial: Section 1 

* 'The definition of the RFC series is described in RFC 4844 
		[RFC4844]. Section 3.1 defines "RFC Editor":'

	A definition isn't described. You are either defining
	something or describing it.  I think, from the text, it is
	the latter, but would be happy to see a definition.  So,

  'The RFC series is described in RFC 4844 [RFC4844]. Its
		Section 3.1 describes "RFC Editor":'

* 'In discussion with the Internet community, the IAB
		considered changes that increase flexibility and
		operational support options, provides for the orderly
		succession of the RFC Editor, and ensures the
		continuity of the RFC series, while maintaining RFC
		quality, maintaining timely processing, ensuring
		document accessibility, reducing costs, and increasing
		cost transparency.'

	At least "provides" should be "provide".  But this is the
	sort of monumental sentence I'm often accused (correctly)
	of writing.  It would be improved by more selective
	punctuation or, better, by breaking into two or three

* 'The RSE, and the IAB, through the RFC oversight committee
		(see Section 3.1), will... and recognizes'

	That would read much more clearly if rewritten to 

	'The RSE and the IAB (through the RFC Oversight Committee;
		 see Section 3.1), will... and recognize'

(B.5) Section 2 - material after the figure

The last sentence of the first paragraph after the figure is
redundant with the first bullet point that follows it.  The two
should be consolidated.  In addition, I think that even some of
us who think we know what "executive management" means are less
clear about "exercise executive management over".  Perhaps you
mean just "oversight" and should be sure the boundary
relationships and mechanisms are described elsewhere?

If you retain "(which can be seen as ...", it should probably
be "(both of which can be seen as..." to prevent an obvious

The third and fourth bullets are either redundant or confusing.
If you meant "design" or "define" rather than "development" in
the fourth one, made that change, and reversed their order,
things would be more clear, but I'm not sure that is what was

In the sixth bullet, the current text implies that the RSOC is
required to approve, which certainly cannot be the intent.  How
about either "...and policy documents.  These documents will
be reviewed by the RSOC and approved by it before final
publication." or "...and policy documents subject to review and
approval by the RSOC", whichever one is actually intended.

The last paragraph of the introductory material to Section 2 is
largely redundant with material discussed in A.2 above.

(B.6) Section 2.1.1, first paragraph

"...which are then provided to the RSOC and the IASA." can be
read as "an then buried or kept secret" and there may be some
history to justify that concern.   The sentence should read
"...which are then provided to the RSOC, the IASA and
to the community.  If the IAOC concludes that it is necessary,
private financial details may be elided from the public
version." or words to that effect

Further comments about vendor selection appear under B.26 below
(comments on Section 4.1), but note that, despite the
cross-reference, there is some redundancy between 2.1.1 and 4.1
that could safely be eliminated.

(B.7) Editorial, Section 2.1.1

* "brought to the IAD" should be "brought to the attention of
	the IAD"

* "for the RFC Series' continuity" should be "for continuity of
	the RFC Series" unless one is going to personify the

* The antecedent for "these functions" in "Vendor selection for
	these functions" is unclear.  Try "Vendor selection for the
	Production and Publisher functions" (Again, see B.26.)

(B.8) Section 2.1.2 "Representation of the RFC Series" and "Representation to the IETF" 

This is confused and needs reorganizing.  There is material in
the "to the IETF" section that is not related to the IETF at
all but to the broader community.  The "community at large" for
the RFC Editor isn't the IETF or even the "IETF community".
There is no "history... of interaction between the RSE and the
IETF" because there has never been a permanent (or otherwise
without qualification as "interim", "transitional", or
"acting") RSE, especially not one appointed under this
procedure.  If the text is intended to mean "RFC Editor", it
should say so.

(B.9) Editorial: Section

* The first sentence does not parse.  In particular,
	"producing individual RFCs (which are worked with the RFC
	Production..." just isn't English.

* In the third paragraph, "certain principles must be
	understood..." would be lots more clear if the description
	of those principles were identified.  I.e., try "certain
	principles, described in the following subsections, must
	be understood..."

* "provides for" not "provides in"

(B.10) Section

The text reads "The Series Editor role relies on volunteer
	participation and needs to support the vitality and
	effectiveness of volunteer participation."

First, relying on volunteer participation to make volunteer
participation effective just doesn't seem to make sense (and it
is a bad sentence in any event).   More important, I think this
is not about just the Series Editor role but the whole RFC
Editor function.

(B.11) "Arbiter of policy"

Section contains the interesting sentence "The IETF
community is the arbiter of policy.".  Since Section is
supposedly entirely about "Representation to the IETF", maybe
it ought to be ok (see B.8, above), but we've long taken the
position that the scope of the RFC Editor Function goes well
beyond the IETF (hence multiple streams, IAB responsibility,
etc.).  A paragraph that implies, in several places (that
sentence is just the most dramatic part) that final decision
authority for policy belongs to the IETF is, at best, confusing
in that context.  It also appears to contradict Section 4.3
unless one engages in hair-splitting about "implementation
decisions' and "functioning of the process" (see B.29 below).
It needs to be rewritten unless the reorganization proposed in
B.8 solves the problem. 

We need to remember that the IAB, IRTF, the Independent
Submission function, and a significant part of the audience for
the RFC Series (and an even larger part over time if current
efforts to make the series more respectable as an academic
reference are successful) are not part of what we formally
describe as the IETF Community.

In this regard, see also Section 2.1.3 (not part of the
"Representation to the IETF" material), which says "...must
also specifically take into account issues raised by the IETF
community, including all the RFC Streams".  Either that is
another piece of the "which community" problem or it should be
reworded to clarify.  For example the text might say, "...must
also specifically take into account issues raised by any of the
RFC Streams, the IETF, or by the broader community", if that is
what was intended.

Incidentally, as one of the clarifications suggested by the
remarks in A.2 above, I note that BCP 101 makes the IASA and
IAOC responsible to the IETF, not that broader community.  To
the extent to which there is an expectation of the IAOC having
any policy influence at all on the RFC Editor (I'd prefer that
be zero, but recognize I may be in the rough), this document
needs to extend that responsibility to consideration of the
broader community.  Since the RFC Editor is special in other
ways, I do not believe that would necessitate updating BCP 101.

(B.12) RSE personally responsible for executing on external

Section says "From time to time, individuals or
organizations external to the IETF need a contact person to
talk to about the RFC Series.  The RSE is that individual".
This is a bad plan -- the RSE should be able to delegate or
reassign that function when appropriate or necessary even while
remaining as the first and default point of contact.

Editorial: s/awareness of the series, and to/awareness of the
series, to/

(B.13) "Internet technical community"

This term is used several times in this document.  It is not
clear what it means.  In contexts outside the IETF, it
definitely includes some parties that most IETF participants
would find surprising.  Informal and sweeping uses such as
those in the Introduction and maybe that in are
probably ok (noting that, if one adopted the WSIS/IGF
definition and some ways of measurement, the statement in about volunteer efforts is probably just plain
false).  But statements that seem to be actionable, such as
"...expected to develop a relationships with the Internet
technical community" in 2.1.4 really need to explain what that
means, if only because it would overlap with the IAB Liaison
Management role.  The "Concretely" material that follows
doesn't really help because it seems to provide a definition of
"Internet technical community" in terms of "broader Internet
technical community" or perhaps "the entire Internet

I think those who are reading the rfc-interest list have
reasonable, and reasonably consistent, intuitions about what
these terms and distinctions mean but, to an outsider or
potential RSE candidate who is trying to understand the
definition of and requirements for the role, it just looks

(B.14) Other issues in Section 2.14 ("Development of the RFC

If "the technical specification series" is intended to identify
a subset, then it would be helpful to be explicit, e.g., "the
portion of the series that consists of technical
specifications".  If that is not the intent, I'm not sure what
is being said and a reader without experience in the community
and with the series is likely to be considerably more confused.

I believe that section should include some mention of
standards-consumers, i.e., people who use parts of the RFC
Series as a basis for procurements, conformance evaluation, and
so on.  While the IETF often skips over it, that has been an
intended, and significant, use of the series for many years
(the introductory material in RFC 1122 and 1123 is illustrative
in that regard).  It is a very different audience from the
audience of implementers.  We often forget that and it would be
unfortunate to build forgetting it into this document.

(B.15)  In 2.1.5, the document says "half of an FTE (approx 20
hours..." and then "over 20 hours..." during start-up.  We
aren't talking about 21 hours as compared to 20 here,
especially if the RSE-appointee is not an active, experienced,
and senior member of the community.  "well over 20 hours" in
the second case would help if you don't want to explain

(B.16) The list in 2.1.6 should be extended to include
"Demonstrated ability to participate in, and manage, activities
by email and teleconferences, not just face to face meetings"
or words to that effect.  Without it, there are some odds of
attracting and recruiting someone (as one organization in the
"Internet technical community" has done) who basically doesn't
like or use the Internet.  This section should be reordered so
that anything "desired" (e.g., #7, Experience as an RFC author)
comes after the requirements.

(B.17) Section 2.1.7, Conflict of Interest, is hard to parse.
Suggested rewrite:

	"The RSE is expected to avoid even the appearance of
	conflicts of interest or judgment with other roles or with
	parties subject to his or her oversight.  In particular,
	the RSE is barred from having any ownership, advisory, or
	other relationship to the vendors executing the
	Publication or Production functions except as specified
	elsewhere in this document.  If necessary, an exception
	can be made after public disclosure of those relationships
	and with the explicit permission of the IAB and IAOC."

If we are really serious about Conflicts of Interest, we should
prohibit the RSE from having an outside-the-IETF-environment
(e.g., "day job") relationship in which money or similar
considerations change hands with any member of the RSOC, IAB,
or IAOC who might be involved in decisions about candidate
selection or compensation.  Relationships in which the RSOC/
IAB/ IAOC member actually reported to, or was a subcontractor
of, the person holding the RSE position are the most
problematic, but the other variations could easily have the
appearance of conflicts of interest as well.

(B.18) Sections 2.3 and 2.4

I haven't done a careful review of these sections.  They seem
stable since version 1 and not in this month's critical path.
I assume that, once an RSE is hired, he or she may review these
sections and suggest tuning, possibly resulting in ...model-v3.
I do suggest that, in the interest of recruitment, that
assumption be made explicit, perhaps by adding ongoing review
of expectations for the Publisher and Production function as an
explicit RSE responsibility.

(B.19) Section 3.1, RSOC, paragraph 1

The sentence that makes up the first paragraph reads: 

	"The IAB is responsible for oversight over the RFC Series
	and acts as a body for appeal and conflict resolution."

"Appeal" has become a loaded term, is a little bit inconsistent
with Section 4.3 of this document and some other things, and
tends to get people thinking about judicial proceedings.
Please consider rewriting this to:

	"...and serves as part of the conflict resolution process
	described in Section 4.3."

If you think it is necessary (I don't think it is) add to that:

	"While not described here, the IAB's other responsibilities
	for handling appeals within the IETF process [RFC2026] may
	also have consequences for particular documents being
	processed by the RFC Editor."

(B.20) Section 3.1, RSOC, paragraph 2

In the second paragraph, "oversight is informed through
subject matter experts" doesn't make obvious sense.  Do you
mean "oversight includes subject matter expertise..."?

(B.21) Section 3.1, RSOC, paragraph 4

In the fourth paragraph, it is not clear what the antecedent of
"In those general cases" is.  The comments about "appeal" above
apply here as well.  It might even be possible to drop the
paragraph entirely as redundant with the first one.

(B.22) Section 3.1, RSOC, paragraph 5

In the fifth paragraph, "For all aspects that affect the RSE
itself..." really grates.  I'd expect such a sentence in an
astrology text, but "aspect" has a different meaning there.
Would it be possible to rewrite it into plain English, ideally
without neutering the RSE?  

The first bullet below that paragraph is ambiguous.  Which of
the following is intended?

	"perform annual reviews of the RSE and report on those
	reviews to the IAB."

	"perform annual reviews of the RSE and provide RSE reports 
	(reports provided by the RSE) to the IAB."

Either is plausible, leaving the ambiguity should not be

In the subsequent bullet, 

	"manage RSE candidate selection and advises the IAB..."

And no comma after "select the RSE".

(B.23) Section 3.1, RSOC, paragraph 6

In the sixth paragraph, "RSOC members are expected...", note
the interaction with the discussion in B.17 above.

(B.24) Section 3.1, RSOC, paragraph 7

   "RSOC will also work with the IASA, proposing a
	budget, and the remuneration and employment agreement of
	the RSE position."

Needs clarification or at least punctuation.  It could be
improved by rewriting it to:

	"RSOC will also work with the IASA, proposing a budget,
	and the remuneration and employment agreement, of the RSE

But that still isn't completely clear and may not be what you
intend.  I suggest:

	"For the actual recruitment and selection of the RSE, RSOC
	will propose a budget for the search process, and work with
	IASA to refine that budget and develop remuneration
	criteria and an employment agreement or contracting plans,
	as appropriate."  

if that is what is actually intended.

(B.24) Section 3.1, RSOC, paragraph 10

Finally for the RSOC, "One of the first responsibilities..."
has already been noted as creating the appearance that
organizing and documenting procedures, presumably untested
ones, is more important than actually getting an RSE appointed
(or can or should block the appointment process).  I suggest
rewriting to something like:

	"The initial RSOC is charged with designing and executing a
	solicitation, search, and selection process for the first
	actual (non-transition or "acting") RSE appointment.  That
	process will inevitably involve iteration on this and
	related documents and evaluation of various strategies and
	options.  The RSOC is expected to describe the process it
	ultimately selects to the community and to involve the
	community in interim considerations when that is likely to
	be of value.  Upon completion of the selection process,
	the RSOC will determine the best way to share information
	learned and experience gained with the community and to 
	determine how to best preserve that information for future

(B.25) Section 4, Administrative Implementation, Figure 2

Consistent with the discussion in A.1 above, I believe this
document would be enhanced if the ISE Function were removed
entirely from it, including from Figure 2.  While its retention
here is less problematic than in Figure 1 and other sections,
the relationship between the IAOC and ISE is quite different
than the other functions because the IAOC has absolutely no
role in appointment of the ISE: the only role is wrt budget for
operating the Independent Submission Process.  By contrast,
because money flows to the RSE and the Production and
Publication functions, the IAOC claims, with some
justification, a need to be involved in the selection process
and is certainly involved in the compensation model.

(B.26) Section 4.1, Vendor Selection

The scope of this section must be restricted to the Production
and Publication functions.   The ISE is not a "vendor" with
regard to that section (see B.25) and treating the RSE as a
vendor leads to recursion.  The list starting "The process to
select and contract..." does make that restriction, but it is
unclear from the title or first two paragraphs.  Changing the
title line to "Vendor Selection for the Production and
Publisher Functions" would solve much of the problem.

I believe that vendor selection should be performed in
conjunction with the RSOC as well as the Streams (and the IAB
separate from its specific Stream role) -or- that the Streams
should not be singled out for special attention in that

Note that there is a risk that involving too many parties in
the vendor selection process (as with any of the other
processes described in, or implied by, this document) could
leave a potential RSE candidate with the impression that there
are too many cooks stirring the proverbial broth and/or a
reporting/ approval process that could make it impossible to
get anything done even while the RSE is held responsible for
doing it.

Probably the second clause of the key sentence in the second
paragraph should be "... and takes input from the stream
managers and the community into account".  That paragraph, with
or without this suggested editorial change, conveys a rather
different impression than "done in cooperation with...", which
could imply that Streams and IAOC must agree to the results.

I am not certain what "establishes the Selection Committee"
means.  It seems to me that the selection process should be
largely under the control of the RSE or RSOC even though the
IAOC has an important voice.  If that is not done, the RSE has
no real control despite nominally chairing the committee.
Indeed, being chair might impose a burden of impartiality and
balance that would prevent the RSE from taking a practical
leadership role.  Similarly, "other members selected by the
RSOC and the IAOC" seems right but leaves the door open for
multiple interpretations of which body is really in charge of
the committee, especially if appointees disagree on selections
or even strategies.  I believe we have "running code" to
demonstrate that is a real risk even when the IAB controls the
appointment model.

(B.27) The organizational location of the RSOC.

Most of the document is insensitive to the difference, but we
have various bits floating around that describe the RSOC as an
"IAB Project" and others, including Section 3.1, that describe
an IAB-established "group" (whatever that is).  Depending in
part on what the IAB does with "Projects", it might make a
difference.  In particular,

   * If I understand the way the IAB intended "Projects", they
	 are really integral to the IAB with added outside members.
	 Remember that, while the capability has not been used in
	 recent years and is not explicit in RFC 2850 (the IAB
	 Charter), the IAB has always been able to include
	 participants not listed in the Charter in its meetings and
	 discussions as long as they are not part of the voting
	 process for formal IAB decisions and actions.  Such
	 Projects are really part of the IAB but, as such, they
	 probably shouldn't have line-item budgets in the IASA
	 process as this document seems to require for the RSOC in
	 the second paragraph of 4.2.  Instead, the RSOC should be
	 budgeted for as part of the IAB budget, just like other
	 IAB Projects, workshops, and other operations.

   * By contrast, if the RSOC is some sort of IAB-established
	 "Group", it is not clear whether, under RFC 2850, the IAB
	 has the ability to delegate as much authority and 
	 responsibility for the RFC Editor function to it as this
	 document contemplates (and the IAB may need a committee or
	 Project to oversee the RSOC).  On the other hand, it would
	 be entirely reasonable for that sort of RSOC to have a
	 separate budget line.  Even then, having the RSOC be
	 considered part of the RFC Editor Function for budgetary
	 purposes (with the RSE preparing the budget) even though
	 the RSOC makes the RSE selection and oversees the RSE
	 might be considered a bit dicey.

(B.28) The RSE, strategy, and the power of the purse

The fourth paragraph of Section 4.2 says, in part, 

   "If product needs change, the RSE is responsible for working
   with the Production Center to determine what the correct
   response should be.  If they agree that a budgetary change
   is needed, that needs to be taken to the IAD and the IAOC."

Let's remember that, in recent history, the most common
"product need" change has been a larger-than-expected volume of
documents entering the production process from the streams.
While the most immediate and obvious effect of such an increase
is on the Production Center, an increased number of RFCs or RFC
pages affects the Publisher function as well.  So the RSE
should be responsible for analyzing the change in "product
needs" and work with whomever he or she needs to work with
(possibly actually including one or more Streams), not just
with the Production Center, to determine a correct response, 

In addition, the "correct response" to some types of changes in
product needs (I'm thinking especially of the list in the
second "vision" paragraph in 2.1.4) may be to rethink how
things are done rather than, e.g., simply adding staff or
budget on an automatic "more of the same" model.  The RSOC
should be integrally involved in helping the RSE sort out
whether a particular change in presumed product needs is merely
the type of financial/contractual issue that appears to be
contemplated by this section or whether it is actually a more
strategic matter.

Textual suggestion: change "...for working with the Production
Center..." to "...for working with the Production
Center and, where appropriate, other RFC Editor component
institutions, relevant Streams, and/or the RSOC...".

(B.29) "Entitles in the model".  The introduction to Section
4.3 indicates that section applies to "implementation
decision[s] made by one of the entities in the model".  It is
not clear who those entities are.  For example, this section
should not apply to ISE decisions because the procedures that
apply to review of ISE decisions are described in RFC 4846,
which this document does not supercede (that particular problem
goes away if the Independent Submission process is removed from
this document as recommended in A.1).  But the IAB, IAOC, RSOC,
and maybe even IANA also appear to be "entitles in the model".
Using these procedures to deal with implementation decisions
made by one of those bodies leads to silly states (or at least
general confusion).  The statement should probably just
enumerate the relevant entities.  Once they are enumerated, it
is not clear whether it is necessary or desirable to try to
distinguish between an "implementation decision" (a term that
is not defined as far as I can tell) and any other sort of

In that same paragraph, something is clearly missing from
"although not is obligated to...".  Perhaps "although he or she
is not obligated to...".   I would recommend making that "the
IAB Chair or RSOC Chair" and letting them sort out who is best

(B.30) Section 4.3, Paragraph 3.  "RSE decisions of this type
are limited to..." is not clear.  Perhaps something like "Final
decisions by the RSE alone are limited to..." or "The RSE may
make final decisions unilaterally only to assure..."

(B.31) Section 4.3, paragraph 2 ("If such a conclusion is not
possible through those informal processes,..." and paragraph 4
("If informal agreements cannot be reached,...") are largely
redundant, but describe slightly different (i.e.,
contradictory) processes.  Let's choose one or the other and
drop the confusion.

(B.32) Section 4.4, Editorial:  The last sentence is awkward.
Perhaps: "...the IAD, as guided by the IAOC, has the
responsibility to resolve these contractual issues consistent
with the procedures specified in BCP 101 and as appropriate
under the relevant contracts."

It would be even better to get as much of this as possible out
of here, leaving a strictly IASA matter to the IASA.  So, IMO,
it would be preferable to replace the entire sentence with
something like: 

	"The IAOC must notify the RSOC and IAB that this action is
	being taken and then proceed to have it resolved according
	to its applicable procedures subject to any special
	provisions in the relevant contracts."

While BCP 101 makes it fairly clear that the IAOC should hand
this off to the IAD, the whole issue is a matter of IASA/IAOC
procedures that should not to be repeated here such that some
future change in those procedure by the IASA create a
contradiction with this document.

(B.32) Section 5, IANA Considerations

In practice, it doesn't make any difference who "facilitate[s]
the establishment of the relationship between the RFC
Production Center and IANA" because that relationship is
working and doesn't need fixing much less "facilitating".  But,
if anything needs to be said here, the coordination of that
relationship should lie with the IAB, since it has formal
responsibility for both the RFC Editor and the IANA.  Were any
conflict to arise between the Production Center and the IANA
that could not be resolved informally, resolving it would
certainly fall to the IAB. By contrast, the IAOC, which is
designated as doing the facilitation in that section of this
document, does not appear to me to have any relationship with
the IANA at all: there are no contracts, no legal arrangements,
and no oversight.  The IETF Trust does have a limited
relationship with IANA, but the Trust is not mentioned in this
document at all.

(B.33) Section 6, Security Considerations

Substantive issue: From the text of the rest of the document,
the primary responsibility for ensuring that an appropriate
strategy for securing and preserving materials, including
determining what is relevant and what is not, lies with the
RSE.  Those "security issues" should not be an IAOC matter
unless contractual problems are identified with what the RSE
decides to do.  Disputes between the Production Center or
Publisher and RSE decisions in those area fall under Section
4.3; procedural, archival, or security decisions that affect
contracts fall under Section 4.4.  It is neither necessary nor
appropriate for the IAOC to be allocated a monitoring role as
part of this Security Considerations section that conflicts
with that RSE role and creates the sort of "who is in charge"
relationship that is likely to make RSE recruitment difficult.

Editorial: either "non-machine-readable originals" or
"originals that are not machine-readable".  The present
construction doesn't work unless it refers to originals that
can be read by non-machines which, while true, is uselsss.

Nit: I am not sure in that context what "failure of the storage
medium" means unless someone contemplates the importance of
chiseling those originals into stone or embossing them onto
gold sheets (after either of which the copies onto new media
wouldn't be originals any more).

(B.34) The Acknowledgments need sorting out.  For example,
whether the "current" listings apply to Version 1 or Version 2,
some IAB members are listed together who were never on the IAB
at the same time (unless one counts the five-day window during
the relevant transition IETF meetings).  Sorting them out by
version would permit listing important contributors and
reviewers to Version 1 who otherwise should not be listed
because their contributions to version 2 occurred in
conjunction with their IAB or Editorial roles. 

(B.35) While it isn't important if the Appendix is going to be
removed on publication unless a historical record is intended,
I think the various subsections of that Appendix are
"versions", not "sections", i.e., "A.1.  Section 00->01" is
just wrong.  Also, some of those subsections clearly address
"model version 1", but the transition clearly occurred before
A.9 (e.g., A.8 describes adding Joel as Editor, but that
clearly did not occur in the Version 1 document).

Recommendation: Either (a) decide this material is too jumbled
to have archival significance and be worth maintaining and just
drop it now or (b) Create "A.1 RFC Editor Model Version 1" and
"A.2 RFC Editor Model Version 2" and sort out subsections into
the next level accordingly, allocating everything done since
RFC 5620 was published in August 2009 to the latter.

Thanks to everyone who has managed to read this far.


More information about the rfc-interest mailing list