On 6 Apr 2016, at 22:57, Andrew Sullivan ajs@anvilwalrusden.com wrote:
As you may know, the IETF is meeting this week, and we had an IANAPLAN meeting to make sure that we've not done anything inconsistent with the previously-established consensus.
The support was in general positive. There are two items that I think we could consider putting in.
Thanks. The suggestions below seem sensible.
First in the bit about the registration rules for iana.org and friends, the first introduction of "to prohibit updates" or whatever it is, we could add a footnote to make it clear that what we're talking about are status values in the shared registration system -- clientUpdateProhibited, clientDeleteProhibited, and clientTransferProhibited. I think this is just a clarification, and no big deal.
Yes, this point would benefit from clarification. In the same clause C.1.b.v, there is also talk about removal of this setting to permit updates, but there is nothing about reinstating this setting after the update.
A more substantive suggestion came from John Levine, who suggested that we specify that the CCG needs to publish at its first meeting, and then update from time to time, the quorum rules and other decision-making processes they use. A suggestion in the room was that the rules be open to the CCG, except that quorum requires not only a majority but some guarantee that at least one appointee from each of the communities must be present for quorum. I think this is a good principle, because it ensures openness and procedural consistency (no making up rules when a decision is needed). Does anyone object? Does it seem reasonable?
That seems reasonable.
Alan Barrett