Pete Resnick <presnick@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> > > 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@xxxxxxx>