[RZERC] RZERC Procedures redline and clean copy docs

[Jim Reid]

> On 1 Jun 2017, at 16:05, Wessels, Duane via RZERC <rzerc at icann.org> wrote:
> 
> I'd like to encourage everyone to take a look at this version and provide feedback soon so that we can iterate on this faster than once per month.

Duane, colleagues, my apologies for not responding sooner. The usual feeble excuses apply: day job got in the way, the dog ate my homework, etc, etc. It also didn’t help that my laptop's audio failed on last month’s call and I was unable to contribute much.

Although the procedures document is in fairly good shape, I think it is too verbose and gets into avoidable detail. That in turn creates unwelcome opportunities for shed painting and rat-holing. It could also make things too rigid and take away RZERC’s ability to be flexible.

For example, we should have exactly one procedure for calling meetings, irrespective of the kind of meeting. As proposed, we have three procedures. Sigh. [I’m not convinced we need to get into so much detail about those different types of meetings either, but let that be.] This procedure could simply say “Meetings will be called with a minimum of TDB days notice and the chairman will be responsible for circulating the agenda and documents. The notice period for a meeting can be reduced in extenuating circumstances provided there is consensus in RZERC for waiving the TDB notice period.”

Listing the elements of the meeting minutes (3.2.1) seems wrong: what if there are no resolutions or action items? I think it’s unnecessary to define what goes into a set of meeting minutes or restrict RZERC’s minutes to just those items.

Sections 3.2.2 and 3.2.3 could/should be merged.

On Section 4, IMO it’s not necessary to say any more than RZERC will work by consensus using the framework defined in RFC7282. We shouldn’t need to cut+paste/list (a subset of) the different flavours of consensus in that RFC. After all, they’re already written there. This also means RZERC wouldn’t need to revisit the procedures document if/when RFC7282 gets updated.

On 5.2, I’d remove "perhaps at its next scheduled regular meeting”. It’s redundant.

On the Disclosure of Interests, I think that too could/should be done by reference. IIUC ICANN already has a standard form for this. If so, we could drop Appendix A altogether and just say RZERC members will complete ICANN’s DoI form (annually or when there is a material change) and that members may be suspended or expelled if they fail to do so.

If ICANN’s already got something for handling proprietary information, our procedures document could simply reference/adopt that too. No need to re-invent the wheel.