Re: draft-klensin-stds-review-panel-00.txt

[Pekka Savola <pekkas at netcore.fi>]

Hi,

(Hijacking the thread to insert my own comments.)

I think this looks, at the high level, a potentially workable method in that
it reduces the AD load and creates a separation of management and review.

I note that the document does not discuss at all (except that the 
panel doesn't deal with them) the AD-sponsored Info/Experimental 
documents which are NOT submitted in conjunction with a standards 
track documents. What would the path for these?

While this would probably increase significantly the chances that folks
could allow being nominated for IESG or ISRP positions -- as load would be
lower, and the skill sets required for each would be different (and not
always clearly found in one person) -- it makes me wonder about the whole
IETF management structure:
 * 13-person IESG for management;
 * 10-person ISRP for review (plus recruited extra reviewers);
 * 12?-person IAB for architectural pondering or whatever they're 
doing.

This makes me wonder whether 35 leadership positions in an organization like
this is a bit inflated.  Unless we want certain people to move from one body
to the next regularly, it might be worthwhile to consider whether some
reductions would be in order; for example, I guess that
maybe IAB could do with 6-8 members.


semi-editorial (nothing big here)
--------------

   The panel will initially consist of ten members, with six chosen to
   reflect the skill set of the current IETF Areas and four chosen to
   reflect general, cross-area, expertise. [...]

==> it might be difficult to identify which area a person belongs.  I'd
guess most folks being considered for one of these panels would have
expertise on multiple areas.  Further, many areas are actually doing very,
very different things (for example, ops & mgt has MIB work and other ops;
internet has LxVPN and lot of other kinds of works entirely).  It's
difficult to believe that it would be possible to capture a representation
of an area in a single person...


   The IESG Chair is chosen by the IESG from their own membership, using
   a method of their choice.  At the discretion of the IESG and after
   consulting with and obtaining the advice of the Nomcom chair, the
   individual chosen as IESG Chair may be relieved of responsibility for
   a technical area and the Nomcom asked to fill the vacancy thereby
   created.

==> did you touch upon the topic of IESG chair as general area AD?  I didn't
see it in any case.  While that might be a non-trivial responsibility, it
should be much less as I guess the main beef of general AD right now 
is to participate in the document reviews.

Note: if nomcom were to select replacements, I guess that would mean
additional nomcom cycles, which would mean delays, etc. -- so practically, I
guess it would be better to have a self-selected chair.

  Appeals on actions of the IESG flow to the relevant ADs, then the
   IESG Chair, then the IETF Chair, then the IESG, and then to the IAB.

==> this kind of appeals chain appears overlong;  appeals already take too
long to process, in different bodies (e.g., a month per body).  Stretching
out a final decision seems troublesome.  Couldn't a more direct path be
used?

 Appeals to the IAB on matters
   of approval or rejection of documents are constrained as they are
   under current procedures: the IAB may instruct the ISRP to reconsider
   an action, but may not itself reverse an ISRP decision.

==> Is this true?  I have at least under the impression that IAB can and has
made binding decisions, or at least made statements which look like 
such -- see e.g. 
http://www.iab.org/appeals/kre-ipng-address-arch-draft-standard-response.html 
(sect 2)






editorial
---------

  document proposes to re-separate the "steering" and "WG management"
   functions that were orginally the IESG's responsibility from the

==> s/orginally/originally/

   Document states referred to in this specification as "tracker states"
   or as "in the tracking system" are defined in [TrackerStates].  For
   the purposes of this specification, "IETF Standards Track documents"
   are considered to include technical specifications and applicability
   statements being processed at any maturity level and BCP documents
   that specify technical, engineering, or operational best practices.

==> "at any maturity level" -- you're probably implying they're still
Standards Track, though...

   community rather than to members of the panel.  Intutitively, that

==> s/Intu/Intui/

   Note that, while the Review Panel may conduct a preliminary review
   before sending out the Last Call announcement, and add its
   preliminary observations, if any, to the Last Call package, all
   documents submitted to it will be sent out for IETF Last Call and
   review or other activities by the Review Panel are not permitted to
   significantly delay that action.

==> I had trouble following the sentence.  I suggest breaking it down e.g.
after "IETF Last Call".

   published and the document to be forward to the RFC Editor.  If it

==> s/forward/forwarded/


--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf