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

[olaf at NLnetLabs.nl (Olaf Kolkman)]

On Jul 10, 2011, at 5:50 AM, John C Klensin wrote:

> IAB,
> 
> 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.

I finally had the time to do the comprehensive review of the review.

In this reply I ignore (or just briefly acknowledge) all the matters that are editorial. In some cases I chime in with 'non-conentious' of 'friendly amendment', which basically means I think adding would be a good idea, but otherwise I do not have a strong opinion.

My reply is from the perspective of a participant in this discussion with a co-editing responsibility, so also trying to propose some wording where I think that is relevant. Joel currently holds the pen and I leave it to him to sort out what he wants to do with the words.

Also for reference I tried to add numbers from the IAB tracker for the issues under discussions. If any of you readers respond to particular sub items it would be nice if the trac number would be maintained.

All suggestions are what they are suggestions to get us forward, I am not attached to their phrasing, which can probably be improved by native speakers.


[Ticket #61] http://wiki.tools.ietf.org/group/iab/trac/ticket/61
> (A.1) [...]
 
> Recommendation: Remove the Independent Stream material from
> this document and put it into something separate.

Personally I think this recommendation makes sense. 

However I do think that the document should make clear that what is now under the Independent stream used to be a function of the RFC Editor, and that removal from this document does not mean that the IAB and IAOC do not continue to support the ISE.

Perhaps adding a section like below is sufficient:

<suggestion>
The Independent Stream Editor.

The Independent Stream Editor (ISE) was an integral part of version 1 of this model. This version of the model concentrates on the organization of the RSE, the Production Center, and the Publication House.

The ISE function has evolved since the publication of model version 1 and deserves its own description outside of the scope of the RFC Editor model. Note however that this version of the model does not change the appointment and funding structure (by the IAB and IAOC respectively) of the ISE function. 
</suggestion>

---------------------------

[No ticket]


> (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.
> 

John, as you know I share this sentiment to a large degree. But I have read your text above several times and I am not sure how to turn it actionable. That is I do not know how to improve the document beyond the suggestion that you make in the last paragraph.

That suggestion is probably not going to help very much as long as the tussle exists.

Having thought about this a lot over the last few weeks I am starting to come to the conclusion that no-matter what the words say the tussles that we have experienced will probably continue to remain and we have to sort them out in practice. Being precise and describing the principles will help, but solutions only come from shared mindsets, wisdom and cooperation. I am not sure, except for the various concrete suggestions elsewhere, how to improve the document so that there are no misunderstandings in the future. I think that is to ambitious.

In other words, I believe that this comment serves as a warning, but is hard to make actionable.


---------------------------

> (B.1) Abstract and Introduction: Experience
> 
[ticket #56]



> This document does not represent only "a year of experience",

replace by something like:
"represents the experience since model version 1 was implemented"
would do the trick.

[...]

>  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.

Difficult. I see what you mean. 

I would suggest use something like "was inspired by the work of the TRSE and discussion on the rfc-interest list" and add a link to: http://www.rfc-editor.org/rse/TRSE.html or to 
http://tools.ietf.org/html/draft-kowack-rfc-editor-model-v2-00
http://tools.ietf.org/html/draft-kowack-rfc-editor-model-v2-motivations-00 and
http://tools.ietf.org/html/draft-kowack-rfc-editor-model-v2-overview-00
explicitly.

(Being an ARSE for a moment: A recent edit of the http://www.rfc-editor.org/rse/index.html page removed some of those links from the pages. I will make sure that they show up on the TRSE page. Is on my TODO).


> 
> (B.2) Editorial: Abstract
> 
> * "persons" should almost certainly be "people".
> 
ack

---------------------------

> (B.3) RFC Editor Model description in the Section 2
[ticket #59] http://wiki.tools.ietf.org/group/iab/trac/ticket/59
[ticket #64] http://wiki.tools.ietf.org/group/iab/trac/ticket/64


> introduction.
[...]

I believe that this is the most practical solution without a document overhaul:
> 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).
(it does not)


> 
> 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.

I leave this one for a native speaker :-) 


-----------------------------------------------
[skipping issues I find non-contentious and editorial]


-----------------------------------------------

> 
> (B.6) Section 2.1.1, first paragraph
[ticket #64] http://wiki.tools.ietf.org/group/iab/trac/ticket/64

> 
> "...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

I agree with this transparency requirement

-----------------------------------------------

> 
> (B.7) Editorial, Section 2.1.1
> 
ack


-----------------------------------------------
> 
> 
> (B.8) Section 2.1.2 "Representation of the RFC Series" and
> 2.1.2.1 "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.

I see this as non-contraversial. I have no suggestions on specific wording.


---------------------------------------------

> 
> (B.9) Editorial: Section 2.1.2.1
> 
ack


---------------------------------------------



> 
> (B.10) Section 2.1.2.1.1
[Ticket 68] http://wiki.tools.ietf.org/group/iab/trac/ticket/68
> 
> 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.


<suggestion>
The successful furthering of the RFC Series relies on volunteer participation. The RSE needs to support the vitality and effectiveness of volunteer participation.
</suggestion>


---------------------------------------------
> 
> (B.11) "Arbiter of policy"



>  "The IETF community is the arbiter of policy.".
[...]
>  but we've long taken the
> position that the scope of the RFC Editor Function goes well
> beyond the IETF 


There has been a lot of discussion on the IETF vs Internet community wording already. See the thread with subject
[rfc-i] draft-iab-rfc-editor-model-v2-02 - policy authority

I think that the sections can fairly easily be fixed by replacing IETF with the "community", in a few cases with a specifying adjective.


e.g:
   The RSE is the primary point of contact to the stream communities on matters other
   than the practicalities of producing individual RFCs (which are
   worked with the RFC Production Center staff.)

However in:
   Due to the history and nature of the interaction between the RSE and
   the IETF, certain principles [...]
I believe the IETF is specifically ment.


All in all I think it is most important that we all agree that the RSE serves a larger community. 


---------------------------------------------
> 
> (B.12) RSE personally responsible for executing on external
> representation.
> 
> Section 2.1.2.2 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.
> 

<suggestion>
The RSE is responsible for that representation
</suggestion>



-----------------------------------------------------------
> 
> (B.13) "Internet technical community"
> 
> This term is used several times in this document.  It is not
> clear what it means. 


In another thread (Subject: draft-iab-rfc-editor-model-v2-02 - policy authority) we are converging to something like:

<other thread>
Decisions must be made in the overall interest of the broader Internet community.  The RSE must identify materially concerned interest groups within the Internet community and reach out to them.  Example interest groups include the IETF community, the IRTF community, the network research community, and the network operations community. Other interest groups might also be materially interested.


The RSE must consult with the community on policy issues.  The RSE works with the community to achieve policy that meets the overall quality, continuity, and evolution goals the RSE is charged with meeting.  As described below in Section 3.1 the RSE reports the results of such interactions, to the RSOC, including a description of the outreach efforts and the specific recommendations on policy.  This enables the RSOC to provide the oversight the IAB is required to apply, as well as to confirm that the Internet community has been properly consulted and considered in making policy.
</other thread>


That is, the RSE determines where the boundaries are, and its part of the IAB review to judge wether those boundaries are set accordingly. 



> 
> 
> (B.14) Other issues in Section 2.14 ("Development of the RFC
> Series")
> 
> 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.
> 

I treat this as a friendly amendment.


> 
> (B.15)  

-----------------------------------------------


[Ticket 68] http://wiki.tools.ietf.org/group/iab/trac/ticket/68

> 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
> further.

FWM

> 
> 

-----------------------------------------------

> (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.


This boat was missed as far as the job description on paper goes. But it is certainly a question the selection committee should keep in the back of the head. Also a friendly amendment as far as I am concerned.


-----------------------------------------------

> 
> 

[I skip a lot remarks, mostly because I believe they are fairly non contentious and the propose fixes work for me. However, some of the RSOC discussion takes place on another thread]



> 
> (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.

I believe the above to be a correct representation of the intent of the IAOC-ISE relationship.

I have no specific recommendations.

---------------

> 
> (B.26) Section 4.1, Vendor Selection
> 
http://wiki.tools.ietf.org/group/iab/trac/ticket/66

> 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.

That seems like a reasonable change to me.

> 
> 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
> process.
> 
> 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.


I believe this to be a controversial and substantive.

The question I ask myself reading this is "Who is responsible when the selection process fails". Personally I believe the answer to that question should be: The RSE. That is not the answer I get when reading the current text.

Personally I believe the Selection Committee an over specification. The RSE should own the selection process, with as boundary condition IAOC controlled contracting and the stream and community needs as input.

I would suggest:

<suggestion>

The process to select and contract for an RFC Production Center, RFC
Publisher, and other RFC-related services, is as follows:

   o  The IAOC, in collaboration with the RSE, establishes the contract process, 
      including the steps necessary to issue an RFP when necessary, the timing, and the
      contracting procedures.

   o  The RSE collaborates with the IAD on vendor selection. The RSE will take into
      account the needs of the streams and the community and may organize the search
      through a selection committee.

(or should organize, I'm ambivalent on that)

   o  The RSE, again in collaboration with the IAD, selects the vendor, subject to the
      successful negotiation of a contract approved by the IAOC.  In the
      event that a contract cannot be reached, the matter shall be
      referred to the RSE for further action.

   o  The RSE may select an RFC Publisher either through
      the IASA RFP process, or select the IETF Secretariat
      to provide RFC Publisher services,
      subject to negotiations in accordance with the IASA procedures.

</suggestion>




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

I think of the location as being: 
>   * [...] 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.
> 



---------------------------------------
> 
> (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."

[...]

>   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, 
> 
I agree. And I think this is important. 

It makes the RSE responsible for trade-offs and optimization, and that is where I think the responsibility should be.


[...]
> 
> 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...".
> 


That works for me.


---------------------------------------------

> 
> (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
> decision.

Hmmm, but with the enumeration you might exclude parties that could be part of a conflict.

What if the ISE would require that some editorial issue should be enforced that has no technical but only stylistic foundation. Isn't that when the above applies?

This is a situation where I would say perfect is the enemy of the good. On the other hand one should be aware of the terror of literal interpretation. Maybe restrict the activities for which the RSE needs to step up:

"If during the execution of their activities for the RFC Series, a disagreement ....."


[skip]

> 
> 
> (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.

This is text straight out of RFC5620

But yeah, you have a point about the coordination. I think that the intention of the 'facilitation by the IAOC' wording is that the IAOC should make sure the interactions are codified in SLAs and such. (The IAOC does have a SLA).


> 
> 
> (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).
> 

Having a fresh look at this text (which also has been here since RFC5620) I believe this section is trying to specify requirements on the Series through the model. Micromanagement

The section should probably just say:
The same security considerations as those in RFC 4844 apply.




> 
> (B.34) The Acknowledgments need sorting out

ACK

> 
> (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.

Wow that is an error I made long time ago and found itself replicated through cut-n-paste often.

Anyway, no objections if this all gets removed.







> 
> 
> Thanks to everyone who has managed to read this far.


Hmmm yeah. And I know that you type faster than I read. 


--Olaf