Pete Resnick <presnick(_at_)qti(_dot_)qualcomm(_dot_)com> 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 <dougb(_at_)dougbarton(_dot_)us>
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 <john(_at_)jlc(_dot_)net>