Re: call for ideas: tail-heavy IETF process

[Brian E Carpenter <[e-mail]>]

Would people like to see a new version of the SIRS draft?

In addition to the questions John raised below, Francis
and others mentioned: lack of reviewers. Also there is the
question of overlap with Area review teams such as secdir,
and there is accumulated experience from Gen-ART (RFC 6385).

Regards
   Brian

On 03/05/2013 08:29, John Leslie wrote:
> Pete Resnick <[e-mail]> wrote:
>> Note that although we did ask the bigger question, the more central 
>> question relates to what we on the IESG can do all by ourselves (without 
>> making changes to the formal processes) that we can discuss during our 
>> IESG meeting next week. So don't limit your thinking to things that 
>> require process changes; suggested behavior changes on the part of ADs 
>> are also useful.
> 
>    The ADs could do worse than starting from the SIRS draft:
> 
> tools.ietf.org/html/draft-carpenter-icar-sirs-01
> 
> but as I read through it, I find a number of issues which I'd advise
> _not_ trying to resolve. For example:
> 
> - All reviews public: not always a good idea;
> 
> - Normally posted to WG list: often a bad idea -- to easy for them to
>   start a flame-war;
> 
> - Standardized summary message: these may be a very poor choice for
>   early reviews;
> 
> - Selection process: it's far more important that the IESG be comfortable
>   with each member.
> 
>    OTOH it contains items which SHOULD be taken seriously:
> 
> - No change to formal process;
> 
> - Formal process to add SIRS members;
> 
> - Inactive members fall off the SIRS list;
> 
> - WG may request a particular member;
> 
> - WG should request more than one reviewer;
> 
> - Earlier reviews should consider architectural questions;
> 
> - Three review cycle per document should be the minimum.
> 
> ====
> 
>    I also note the overlapping discussion of DNS type SPF...
> From: Doug Barton <[e-mail]>
>> Given that you can be 100% confident that the issue will be raised
>> during IETF LC, wouldn't it be better to hash it out in the WG (as we
>> have attempted to do)? Or is the WG's position, "we have no intention of
>> dealing with this unless we're forced to?"
> 
>    In this case, hashing it out on the WG list at this stage seems a
> _bad_ idea. If we had gotten a SIRS review right at the beginning, it
> could perhaps be discussed on the WG list; but by now it's doubtful
> any discussion would change anyone's mind. (And, of course, if the WG
> had chosen only SIRS reviewers that agreed with their preferred way
> of resolving the issue, the issue _wouldn't_ have been resolved early
> in the process...)
> 
>    This is on it's way to being a poster-child "late surprise". :^(
> 
>> I'm fully sympathetic with your collective desire to move the process
>> forward, and finish your document. The problem is that as it stands the
>> document contains a course of action that is not only bad on its face,
>> but contrary to a basic architectural principle adopted 4 years ago in
>> 5507.
> 
>   BTW, I agree with Doug Barton that deprecating type SPF has some serious
> negatives. The IESG will have to balance WG rough-consensus against
> architectural principles; and I see no resolution that won't invite
> appeals. :^(
> 
>    In a properly designed early-review situation, the issue would have
> surfaced early; and it's possible it could have been resolved before
> too many folks' positions had hardened...
> 
> --
> John Leslie <[e-mail]>  
>