The "late surprise" problem

Dave Crocker dhc at dcrocker.net
Sat Mar 22 15:29:54 CET 2003


Basavaraj,

Thanks for the thoughtful comments.

Saturday, March 22, 2003, 7:15:30 AM, you wrote:
BPnc> 1. Additional process overhead - Is this really warranted?
BPnc> 3. Documents go through many revs - Would the review committee be
BPnc>    expected to look at these docs every time? This will cause
BPnc>    scalability problems.

This gets to the key reason I immediately liked Brian's idea:  It
formalizes what is, in fact, already required to be successful.

Let's acknowledge reality: An IETF specification that has not had any
assistance from participants who are savvy about the IETF is traveling
a very risky path. From a strictly pragmatic standpoint, a working
group needs to have participation from people who already have an
successful IETF track-record.

As of now, we do not encourage enough such underpinning to a working
group's effort.  We hope for it, but we do not require it.

So the nice part about the proposed formality is that it "only"
specifies the end point (the signoffs) but leads to a pretty clear
implication that a working group should have SIRs involved much
earlier.

The answer to the specific question you ask -- whether they need to
read iterations of drafts -- depends upon the types of changes being
done, the amount of energy being put into them, and the amount of time
it takes to produce them. If the working group does not mind doing its
work without receiving "senior" feedback, taking the risk of being
unable to obtain the necessary SIR support at the end, then fine.

So, as a "sign off" requirement, yes this sounds onerous. However
taken as a means of ensuring actual IETF-knowledgeable participation,
I think it is pretty mild.

And it nicely partitions the effort:

   * The senior IETF community chooses its "experts".

   * The working group decides which ones to use as reviewers.


BPnc> 4. Does not address the problem of ensuring that people attending
BPnc>    a WG meeting have read the drafts.

There are many things this proposal does not address.  And does not
need to.  The questions are whether it addressing key issues and
whether it addresses them productively.


BPnc> 5. Will result in even less people in the IETF motivated to read
BPnc>    drafts since there exists the SIR group to do this work

I don't see that implication, but I also suspect it is not essential
that we agree on it.


BPnc> On the +ve side:
BPnc> 1. The document(s) quality will improve and IESG burden is decreased

indeed.


BPnc> A suggestion to the proposal:
BPnc> Instead of having an IETF wide SIR group, WGs should be more empowered
BPnc> to do this. WG chairs should set up review groups for each document that
BPnc> exists in their area.

This suggestion highlights the nature of the proposal: It is, in fact,
essential that the pool of SIRs be defined by a *different* (or at
least larger) group than the working group. The entire point behind
the SIR proposal is to ensure the presence of IETF technical expertise
in a working group. This is not accomplished if the working group
defines the pool from which it must draw.


BPnc>  This review group should be open and anyone should
BPnc> be able to add their name as a volunteer as long as they are willing to
BPnc> commit some time.

My wife is extremely knowledgeable about many topics, but none of them
involves Internet protocol specification. So, she would not make a
competent reviewer of an IETF specification. Your proposal would
permit her to be one.

d/
--
 Dave Crocker <mailto:dcrocker at brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>



More information about the Problem-statement mailing list