Subject: Re: [Icar] ICAR draft charter rev 2

From: David Meyer <[email-masked]>
Date: Mon, 12 Jan 2004 14:20:37 -0800

This looks good. Just a few nits:

	(i).	What does "submit drafts" mean? I assume (again)
		that we mean "produce WG document" (which in turn
		means that the document name is of the form
		draft-ietf-icar-xxxx, was adopted by WG
		consensus, and it can be found on  
		ftp://ftp.ietf.org/internet-drafts); this is in
		contrast to "submit draft ... to IESG..." (all of
		this is really a nit an belongs in a discussion
		of how one writes a charter, I suppose),

	(ii).	Can we be more precise about what "earlier" means
		in "It is an explicit goal of the WG to come up
		with mechanisms encouraging earlier review of the
		documents"? My first question when I read this
		was "earlier than what"? 

	(iii).	SEP 2005: Evaluate WG progress and potential;
		close or recharter 

		What does it mean (what is meant) by evaluating
		the WG "potential" (i.e., we could be talking
		about a kind of potential s/a potential energy,
		but I'm pretty sure that isn't what is entended).

	Other than that, the charter defines some reasonable
	goals within a (importantly) constrained scope, and time
	frames. 

	Dave

>> Revision 2 below, please.
>> 
>> -- 
>> Alex
>> 
>>    WG name: improved cross-area review (icar)
>> 
>>    Chairs: <TBD>
>> 
>>    General Area Director(s):
>>     Harald Alvestrand <[email-masked]>
>> 
>>    General Area Advisor:
>>     Harald Alvestrand <[email-masked]>
>>    
>>    Mailing list: [email-masked]
>>    Subscription: [email-masked]
>>    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
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/icar
>> 
>> ===8<===========End of original message text===========

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 12 Jan 2004 17:57:55 -0500

My personal read of "submit drafts" was
     Have one or more I-Ds in the repository which the working group is 
discussing.

These may not at that stage (I would guess will not) reflect working group 
consensus.    In other groups I have seen the use of the naming scheme 
draft-person-icar-xxx used to reflect this stage of the process.

I would not expect the charter to have to get too specific about this, as 
the process of marking the documents as under discussion should be anything 
the WG and chairs are comfortable with, not a chartering issue.

Yours,
Joel

---

From: David Meyer <[email-masked]>
Date: Mon, 12 Jan 2004 15:23:54 -0800

>> draft-person-icar-xxx used to reflect this stage of the process.

	Yep.

>> the WG and chairs are comfortable with, not a chartering issue.

	Agree. As I said, a nit that came to mind as I was
	reading through the charter.

	Dave

---

From: "Michael A. Patton" <[email-masked]>
Date: Tue, 13 Jan 2004 08:26:04 -0500 (EST)

Another one where a comment in another discussion triggered one of my
buttons...

   In other groups I have seen the use of the naming scheme 
   draft-person-icar-xxx used to reflect this stage of the process.

As a potential cross-fertilization reviewer, I find the current naming
standard for drafts as a bit bothersome in this area.  It's often very
hard to distinguish between a set of proposals that are related to an
existing WG, and the sometimes completely random independent offerings
that use the same convention.

Sometimes drafts that would benefit most from early review are when
there are several proposals, which have not yet been decided between.
But, with this convention, these look just like kook submissions and
it's hard for a potential reviewer to pick up on this.  In fact, when
there are several options, it would be nice to see it because review
from outside the WG might notice, for example, that one fits really
well with some other work, while another would interfere with a
protocol nearing WGLC and thus interfere with it later.

I agree that the draft names may not be the best place to encode this,
but right now they're all we have...  I suggest that this is another
area of "ID status" that this WG should think about...

	-MAP