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

From: Pekka Savola <[email-masked]>
Date: Mon, 1 Aug 2005 09:24:36 +0300 (EEST)

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Mon, 01 Aug 2005 04:01:28 -0400

--On Monday, August 01, 2005 09:24 +0300 Pekka Savola 
<[email-masked]> wrote:

>...

thanks

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

Obviously, if the community had an opinion on them, the draft 
could (and would) be changed.   But my reasoning and assumption 
was that, today, we have...

   standards track doc  ---> IESG
   info/experimental --> IESG
                     |---> RFC Editor

This draft changes _only_ that first line.  The IESG can still 
authorize publication of WG-produced, or other IETF-relevant, 
docs as informational or experimental, or authors can take such 
documents to the RFC editor (subject to IESG review as specified 
in RFC 3932).

> always clearly found in one person) -- it makes me wonder
> about the whole IETF management structure:

>   * 12?-person IAB for architectural pondering or whatever
> they're doing.

To some extent, where we may disagree is assuming that these are 
"management" roles.  I would normally not think of the IAB today 
as a "management" entity, at least for IETF matters.  And the 
review panel proposed in the draft certainly isn't.  See below...

> this is a bit inflated.

With the qualification about "management" (I have fewer problems 
with "leadership"), what do you think the size of this community 
is, counting not just meeting attendees but everyone who tracks 
mailing lists and might contribute.  3000?  4000?  I'm not 
convinced that one or two percent leadership (management?) is 
excessive.  Indeed, even when you add in all of the WG chairs 
(and that is a management role), probably (i) the management 
load is not excessive and (ii) the marginal increase this 
additional group implies given the number of WG Chairs plus the 
IESG/IAB is pretty small.

> Unless we want certain people to move from one body
> to the next regularly,

That would defeat much of the purpose of this proposal, which is 
to cycle people regularly back into the community.

> it might be worthwhile to consider whether some

Deliberately not discussed in this draft, but I suspect that 
there is a critical mass of skills and knowledge issue that 
would  make the IAB a lot less functional at significantly 
smaller size.

> semi-editorial (nothing big here)

The notion was to get coverage.  That is always hard (one might 
claim that, in some existing IETF areas, the nomcom has 
sometimes not been successful in finding adequate coverage).  If 
you have good text to suggest, I'd welcome it.

> should be much less as I guess the main beef of general AD
> right now is to participate in the document reviews.

Other documents give the IESG the authority to arrange areas and 
assignments of ADs to them as they find necessary.  This 
document deliberately doesn't address that question. 
Personally, I think there are a number of reasons why changing 
it would be unwise.  YMMD.  If so, write a draft.

> guess it would be better to have a self-selected chair.

The main reason for having an IESG-selected chair is that it 
would presumably result in someone whom the IESG could work with 
and vice versa.  The present process doesn't guarantee that and, 
since the nomcom doesn't have good visibility into IESG internal 
workings,... well, we have done lots better than we should 
expect.

> out a final decision seems troublesome.  Couldn't a more
> direct path be used?

That is the present process.  If you think it is broken, write 
text and convince others.

> 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-standar
> d-response.html (sect 2)

Read 2026.  Carefully

>...

Will be dealt with.  Thanks.
    john

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 01 Aug 2005 12:09:24 +0200

John C Klensin wrote:
> Obviously, if the community had an opinion on them, the draft could (and 
> would) be changed.   But my reasoning and assumption was that, today, we 
> have...
> 
> This draft changes _only_ that first line.  The IESG can still authorize 
> publication of WG-produced, or other IETF-relevant, docs as 
> informational or experimental, or authors can take such documents to the 
> RFC editor (subject to IESG review as specified in RFC 3932).

Factoid: about 65% of documents considered recently by the IESG are
standards/BCP track. It's very hard to determine what fraction of
the IESG's time goes on these documents, but there are some indications
that the remaining 35% take a disproportionate amount of time.

Documents sometimes move between standards and info/exptl during
IESG review, so if we want to keep that flexibility, this has to
be covered by the process.

In general, I would like to see an updated version of
https://datatracker.ietf.org/state_diagram.gif
with annotations showing where the IESG would induce a transition
and where the review panel would do so.

    Brian