Re: [Icar] Progress?

[Dave Crocker <[e-mail]>]

Brian,

>> This deferral to the wg is based on the view that the proposal should
>> provide a mechanism that is available to the working group, but that
>> the wg chooses whether to use it, rather than having the proposal
>> impose anything on the wg.
BEC> But at the end of the process, the IESG will impose cross-area review
BEC> on the WG; that's what the IESG does. So if we want to ease the perception
BEC> that the IESG is a bottleneck, we need to *encourage* WGs to solicit (and
BEC> react to) cross-area review.

Definitely correct.

The significant point, however, is that having this become a de facto
requirement is not part of defining or using the review process
itself.  Making it effectively mandatory is outside of the critical
path for initiating the review capability.

Rather, it develops as a requirement later, as the utility of early,
wg-initiated reviews becomes evident. Hence it is the usefulness of
the reviews that prompts working groups to get them done, rather than
the imposition of an externally imposed and externally managed rule.

I should comment that we need to be careful about thinking that the
only important reviews are cross-area and that cross-area reviews are
always required.  An algorithm change to BGP does not need a review by
Apps and well might not need a review by anyone outside of the Routing
area.  Definition of an RFC2822 header might not need review outside
of Apps.  It all depends on the nature of the thing being specified.

(But, yes, we currently do not do nearly enough cross-area review.)


>> If we view proposals as offering services to working groups, rather
>> than imposing requirements to them, then the the question of review
>> process and content detail become a matter of quality and style,
>> rather than formal requirement. More detail is usually better, but not
>> always.
BEC> For some strange reason I think the level of guidelines for the content
BEC> of a review in the SIRs draft is about right. Note, they are guidelines,
BEC> not requirements.

yeah, pretty remarkable.  equally astonishing is that i agree with
you...



d/
--
 Dave Crocker <mailto:[e-mail]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:[phone]>, <fax:[phone]>


_______________________________________________
Icar mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/icar