[rfc-i] My comments on http://www.ietf.org/id/draft-kowack-rfc-editor-model-v2-00.txt

[Leslie Daigle]

Hi,

Written form of my comments on the draft, covering my Monday night 
plenary comments and subsequent discussions.

Metapoints

0/ My closing remark on Monday was about clarity of whether the document 
(or any part of it) is addressing the right problem, or if it is 
addressing the problem right.  I think there is a bit of both going on.

1/ The top-level practical issue from Monday is the fact that this 
document is not positioned as a discussion document.  We (for any value 
of we != Glenn ;-) ) don't have enough context to evaluate the merit of 
the proposals, or the tradeoffs.  (Figuring out if we agree it is 
addressing the problem right).

Again -- I am not asking for a replay of Glenn's thought processes, nor 
am I expecting us all to be RFC Editor experts.  However, there are many 
places in this document where it is difficult to distinguish between 
steps needed for _any_ RSE to be able to get the work done, versus 
Glenn's Good Ideas (GGI-tm).

(No offense meant to Glenn -- I'm sure they are good ideas; and I'm sure 
the RSE will have good ideas; and so on and so forth.  But for the 
community to get behind them, we have to understand why they are good 
ideas for all RSEs).



2/ Recognizing that the target is to have a document that allows the 
kickoff of the process for finding the RFC Series Editor 
(non-transitional), I strongly suggest that the base document focus only 
on areas needed to make that happen.
	. clarity about executive authority is cited as a requirment
	. plans to have the RSE travel to NANOGs etc -- probably not so much

I.e., let's make sure we are discussing _only_ the parts that are the 
"right problem" for now.  There are many things that are included in the 
document that seem to be getting ahead of the immediate problem -- I'll 
note some, below.  At any rate, this should not be



3/ It is not clear to me that the TRSE has to be the editor of that 
discussion document:  expertise in writing a discussion document is 
what's needed here, and the TRSE expertise is _input_ to that document.




4/ In general, I do not believe this document, or the issues that need 
to be addressed in this discussion, represent v2 of the RFC Editor 
model.   Perhaps v1.5.   At any rate -- it would be helpful to identify 
areas of change from the proposed v1 RFC Editor Model, as opposed to 
simply supplanting it with a text that is just different.




5/ I also commented at the mic on Monday that this document and the 
proposed structure is either too big or too small.

By that I mean:  I think it alludes to an RSE activity that is much 
bigger than the role envisioned as the key piece to allow the RFC Series 
to continue in the light of the new RFC Editor model.  (It's too big).


At the same time, I don't think this has enough consideration of all the 
ramifications and implications of the suggestions, nor does it give the 
RSE (or the other components of the RFC Editor model) enough of a basis 
to fully realize those directions over time.  (It's too small).



Particulars:

6/ IMO, the proposed RFC Editor stream is not actually critical to the 
overall proposal and should be pulled out as a separate discussion.  And 
it should be a discussion, to ensure that it is perceived as necessary 
and that the stream is set up in ways that the community actually supports.



7/ Section 4.1 executive-level management

This details the rights of the RSE as an executive, bringing in the 
particular nature of the Intenret technical community, which is quite 
useful given that it was cited as a major impediment to understanding 
the intended RSE role in the first RFP round.

However, IMO it does not adequately highlight the RESPONSIBILITIES.

I have trouble with this:
          "As the RSE and RFC Editor staff apply their specialized 
knowledge,
    they will develop unique perspectives and insights.  They must be
    free, and encouraged, to shape those insights into their own unique
    vision for the RFC Series. "

It's one thing to bring them to the table, it's another to cause the 
community to read it in the news.  In my opinion:  the RSE needs 
executive authority to carry out the work, but this does not extend to 
unilateral authority to change the series.

4.1.1 addresses this somewhat but:
         Doesn't identify that the community can bring up issues
         Seeks only acceptance from community, not input

And this discussion, right now, is the first instantiation of the 
problem with that.

4.1.5 seems to write the community out of the function of contracting. 
Which may be okay, but probably a surprise to some.


8/ This strikes me as being in the category of "idea to consider", but 
it is not adequately motivated in the document, and definitely takes the 
RFC series/editor to new areas:

     4.2.4.  Represent and promote the RFC Series to the outside world

The document notes that this could be expensive in time and resources 
(yes!).  IMO, it might be brought in to the realm of the germane if it 
was reframed in terms of expected IMPACTs, instead of citing the rather 
open possibilities of ACTIVITIES.  I.e., what is the target outcome of 
any such activity?  I'm thinking -- the RSE is expected to raise and 
maintain visibility of the RFC Series in the broader community than the 
IETF.  Period.  Implementation details left to the RSE.


9/ I believe this must be doable, for contractual sanity:

     The IAOC cannot on its own remove the RSE from office.  If there is a
    persistent concern about RSE contractual performance, it must be
    reviewed by the IAB.  The IAB must in turn consult with the RSAG.

I think that is in danger of solving the RSE executive authority 
question by devoicing the IAOC.  The IAOC holds the contract, and if 
there are contractual reasons to remove the RSE, they have to be able to 
act.


10/  This is another area where it might be helpful to capture the 
intended outcome, not the specific mechanical activities:

"4.3.1.  General Planning, Prioritization, and Reporting

    Many of the responsibilities and tasks in this document are open-
    ended.  The RSE cannot accomplish all these tasks at the same time
    with any reasonable level of resources.  The RSE must manage the
    extent of tasks, and their prioritization and execution.  The RSE
    must clearly communicate plans and expectations to the community and
    other entities.

    1.  Within 6 months of the RSE's appointment, or a date agreed with
        the IAB, the RSE will publish an initial work plan and road map.
        The RSE will indicate which initiatives and activities will be
        focused on over the remainder of the first calendar year,
        including their own activities and those of other RFC Editor
        Components.  These plans will distinguish between ongoing
        operational duties and focused initiatives.  In developing this
        initial plan, the RSE will have had the assistance of the RSAG.

    2.  By 5 December each year thereafter, the RSE will publish a plan
        and road map for the upcoming calendar year.

    3.  By 1 February each year, the RSE will publish an Annual Report of
        the RFC Editor.  This will include a review against the preceding
        year's plans and highlight lessons learned that are reflected in
        the new calendar year plan and road map.  Summary statistics will
        be included.  The RSE may ask RFC Editor components to produce
        relevant reports on request.  The RSAG will review and comment on
        the RSE's draft before the final annual report is published.

    The RSE will issue a monthly report for delivery to the IAB and
    publication to the community."

My reaction on reading this was -- "what would be in such a plan?".  Is 
this detailed operational, or high level strategic?  The answer to that 
question has a direct impact on the type of person that would be 
appropriate for this role, so I think it's important to nail.


11/  IMO, this insulates the RSE -- in a bad way: "In this way, the RSAG 
ensures the RSE is aware of community opinion and requirements."   It 
needs to be balanced by ensuring the RSE talks with the community.


12/  "   Unless explicitly indicated otherwise, only full RSAG members 
will  provide direct counsel to the IAB or IAOC."

This will happen.  Howevever, I don't believe it should be spelled out 
as a right/requirement/expectation:  otherwise, you have N different 
opinions impacting the IAB and no way for the IAB to collate or rank 
them.    In terms of specified structure, the document should say that 
the committee advises the IAB (if it does).   All individuals should be 
free to share their opinions with the IAB.





Thanks,
Leslie.




-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
leslie at thinkingcat.com
-------------------------------------------------------------------