Re: [ietf-sow] Fwd: Agenda Development RFP SOW for Community Input

Russ Housley <> Fri, 11 November 2011 22:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1091611E8094 for <>; Fri, 11 Nov 2011 14:53:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p5wEmEVp5jRK for <>; Fri, 11 Nov 2011 14:53:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6461D11E8083 for <>; Fri, 11 Nov 2011 14:53:23 -0800 (PST)
Received: from localhost (unknown []) by (Postfix) with ESMTP id 800829A473E; Fri, 11 Nov 2011 17:53:42 -0500 (EST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 92tfe-D9Aj-a; Fri, 11 Nov 2011 17:53:12 -0500 (EST)
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTP id 0AF9B9A473B; Fri, 11 Nov 2011 17:53:40 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Russ Housley <>
In-Reply-To: <>
Date: Fri, 11 Nov 2011 17:53:19 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Robert Sparks <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [ietf-sow] Fwd: Agenda Development RFP SOW for Community Input
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SOW Feedback List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Nov 2011 22:53:24 -0000


>>> .) The document proposes changes to existing policy and practice.
>>> (Such as not allowing a group to request a 3rd session until _after_ the
>>> initial schedule has been prepared, and limiting 1st tier conflicts to 10 
>>> groups, and requiring justificaiton for a second slot request.). Why? 
>> This is actually current policy, I believe, even if some ADs are approving a third slot for very busy WGs.
> I wasn't aware of it.
> Is it really current policy to restrict the 1st tier conflicts to 10 groups?
> That won't work for area meetings or for groups like DISPATCH.

I think you can say all of RAI and 10 others.

>>> It seems odd that the document requires a requester to justify a 2nd slot
>>> request (it shouldn't) but not justify a "Please do not schedule on" request
>>> (which it should).
>> I do not understand this comment.  Robert, please try again.
> The document calls out the "Do not schedule on <a particular day, like Friday>" in
> several places, including making sure the secretariat takes those requests into account
> at 3.1 step f, and having the option to ignore them in section 4.3.
> What's missing is a requirement to collect any justification when this constraint is added
> to a meeting request in the first place.

This is usually done to accommodate travel restrictions of WG chairs.  I recall one time that a WG chair had to be at a wedding, so they left on Thursday at Noon.

>>> Under special requests, the document notes "There will be a statement
>>> here noting that cost may apply for some items." Please provide additional
>>> detail. Do you want this to appear when working group chairs are making
>>> a normal working group session request, or was the intent for this to only
>>> apply to breakout or side-meetings (such as corporate or affiliate meetings)?
>> I think this is about side-meetings, not breakout rooms.
> It's currently in section 3.1 h) which is about working group meetings.
> Should it be moved to 3.2? (That section already notes that fees may apply for the room, but not necessarily for stuff in the room).

We should let the Secretariat tell us what they need.

>>> Under the agenda manipulation sections - why don't we allow users (of whatever
>>> level) to save proposed agendas and refer to them by name (preferably with a URL 
>>> that goes back to them). This would allow several people to propose conflict
>>> resolutions. It would be even better if the tool provided a way to easily 
>>> visualize the difference between any two saved agendas. This saving motif
>>> could be leveraged to simplify some of the requirements around identifying
>>> what the current draft or "final" agenda are.
>> I'm not sure.  This could lead to a very significant amount of storage.  Also, it will not be useful after a few days.
> I don't think each save would be that large, and we could cause it to have a finite lifetime.
> But if I'm wrong about size, we could alternatively look at making it something that could 
> be returned to the user as a blob instead of storing it in the database.

That is a good thought.