RE: [Icar] ICAR draft charter rev 2

I like this much better.

I am assuming that "structured review" will include some work on 
the review process itself, including perhaps
things like the addressing of problems identified by the review, a
formal
response to the reviewers, solicitation of both "yes this is perfect"
and
"no this needs the following change" responses, etc.

Is that correct?  Should we make it explicit?

Bob

> -----Original Message-----
> From: Alex Zinin [mailto:zinin@psg.com]
> Sent: Thursday, January 08, 2004 5:17 PM
> To: icar@ietf.org
> Subject: [Icar] ICAR draft charter rev 2
> 
> 
> 
> Revision 2 below, please.
> 
> -- 
> Alex
> 
>    WG name: improved cross-area review (icar)
> 
>    Chairs: <TBD>
> 
>    General Area Director(s):
>     Harald Alvestrand <harald@alvestrand.no>
> 
>    General Area Advisor:
>     Harald Alvestrand <harald@alvestrand.no>
>    
>    Mailing list: icar@ietf.org
>    Subscription: icar-request@ietf.org
>    Archives : 
> https://www1.ietf.org/mail-archive/working-groups/icar/current
> /maillist.html
> 
>    WG Description:
> 
>      The WG will work out mechanisms for improved cross-functional
>      review within the IETF, addressing the issues identified by the
>      PROBLEM WG. This includes a better community review, as well as
>      more structured pre-IESG review that may be used to improve
>      scalability of the IESG review function.
> 
>      Definitions:
> 
>       o Cross-functional review: document review covering different
>       aspects of Internet technology, including those represented by
>       WGs within different IETF areas.
> 
>       o Community review: document review performed by individual IETF
>       participants and not caused by their responsibilities within
>       the IETF management structure.
> 
>       o Structured review: more formal and role-based document review
>       performed by individuals assuming certain responsibilities (such
>       as by WG chairs, directorate and IESG members.)
> 
>      It is an explicit goal of the WG to come up with mechanisms
>      encouraging earlier review of the documents. An early review is
>      best for catching architectural problems while they're still
>      relatively easy to solve. In particular, many cross-functional
>      interactions can be spotted and dealt with, thus avoiding many
>      "late surprises". A final review (currently done by the IESG) can
>      catch remaining cross-functional interactions, as well as deal
>      with overall quality issues.
>      
>      The WG will cooperate with others in starting and evaluating
>      experiments with early community and structured reviews. The
>      evaluation of such experiments may be published as Informational
>      RFCs if the group so desires.
> 
>      The WG will also coordinate with other WGs involved in the IETF
>      reform process on proposed changes to the IETF Working Group
>      operations and Standards process if those are considered
>      necessary.
> 
>    WG milestones:
> 
>      FEB 2004: Submit drafts on improved community and 
> structured reviews
>      SEP 2004: Submit draft on improved community review to
>                the IESG for publication as BCP
>      SEP 2004: Submit draft on improved structured community review to
>                the IESG for publication as BCP
>      SEP 2005: Evaluate WG progress and potential; close or recharter
> 
> 
> _______________________________________________
> Icar mailing list
> Icar@ietf.org
> https://www1.ietf.org/mailman/listinfo/icar
> 
> 

_______________________________________________
Icar mailing list
Icar@ietf.org
https://www1.ietf.org/mailman/listinfo/icar