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

[Russ Housley <[e-mail]>]

Robert:

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

Russ