My thoughts about the problems of the IETF

Bound, Jim Jim.Bound at
Tue Apr 22 13:41:55 CEST 2003

I am seeing there is no way to continue without additional review
efforts across the board for multiple problems.  In your doc I would
suggest that any reviewer must have attended at least 2 IETF meetings in
the past 4 as we don't want people popping in who are not engaged and

Lots of comments about how such reviewers are selected etc... But better
to get proposals on the table first and worry about that next.  What we
don't want is an extended good ole boy network that will cause more
damage than help.


> -----Original Message-----
> From: James Kempf [mailto:kempf at] 
> Sent: Tuesday, April 22, 2003 11:57 AM
> To: jari.arkko at; john.loughney at
> Cc: problem-statement at
> Subject: Re: My thoughts about the problems of the IETF
> > One possible idea is an "approach review" or "architecture review" 
> > earlier in the process. Say, at the time a draft becomes a WG item 
> > there needs to be an "protocol overview" section which outlines the 
> > main technical ideas in the protocol. This section needs to be
> signed
> > off by a review group. This group could be e.g. IESG or a set of at
> least
> > one WG chair from all areas. As a part of the review, the 
> WG could get 
> > useful feedback, such as "Ok, you can go ahead with this, but
> you
> > must add a congestion control mechanism into your protocol". This 
> > would be a more constructive approach than finding a lot of 
> problems 
> > at the end of the process.
> >
> I have a prototype draft proposing an architectural review 
> process on my hard disk waiting for the solution phase to commence.
> The basic idea is to give WG chairs and shepherding AD a 
> semi-formal option of convening an in-person architectural 
> review at a WG meeting. The review would be organized by IAB 
> in consultation with the WG chairs and shepherding AD, but 
> the review board could contain any "outsiders", i.e. those 
> who are technically knowledgable but not directly involved in 
> the WGs efforts. The option would be at the WG chairs' and 
> shepherding AD's discretion, i.e. not required and probably 
> not done very often. The results of the review would be input 
> to the shepherding AD, broader IESG, WG chairs, and WG to 
> guide further development, that is, these groups could 
> dispose of the advice as they see fit. Making it semi-formal, 
> i.e. documented in an RFC, would provide some structure 
> around a process that now is fairly unstructured.
>             jak

More information about the Problem-statement mailing list