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

Robert Sparks <> Fri, 11 November 2011 09:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B90221F8783 for <>; Fri, 11 Nov 2011 01:33:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zS4e+XjAcGfQ for <>; Fri, 11 Nov 2011 01:33:50 -0800 (PST)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id 9115321F8770 for <>; Fri, 11 Nov 2011 01:33:47 -0800 (PST)
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id pAB9XT0S056726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Nov 2011 03:33:40 -0600 (CST) (envelope-from
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Robert Sparks <>
In-Reply-To: <>
Date: Fri, 11 Nov 2011 17:33:27 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Russ Housley <>
X-Mailer: Apple Mail (2.1084)
Received-SPF: pass ( is authenticated by a trusted mechanism)
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 09:33:51 -0000

Trimming to only those places I've responded.

On Nov 11, 2011, at 4:35 PM, Russ Housley wrote:

>> .) 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.

>> 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.

>> 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).

>> 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.