Overall, this seems sensible.  On CCG procedures, we may want to have a "charter" for the group, although there may be other ways to ensure that rules are in place.  As such, how we put those rules in place should be kept general (i.e., not so specific as 'publish at its first meeting').  The point on quorum is one where we might want to be specific now -- this echoes discussions we've been having about quorum and decisions making in the CSC oversight group for IANA functions.  I think a majority with at least one rep from each community is a pretty reasonable "floor" for quorum requirements and one I have no trouble supporting at this point.  Of course, this and many other details will get resolved when we move from this "term sheet" stage to "definitive documentation."  What's most important now is to keep moving toward that stage.

Greg

On Thu, Apr 14, 2016 at 12:24 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,

I'll take the responses to mean that I should incorporate those bits.
Any additional remarks from the other communities?  We said about now
was when we were going to send this off to lawyers.

It turns out to be critical that we get this moving.

A

On Sat, Apr 09, 2016 at 01:46:33AM +0900, Izumi Okutani wrote:
> Thank you Andrew for the update and helpful to hear feedback from IANAPLAN.
> I agree with Alan, both of the two suggestions discussed in IANAPLAN are reasonable. I agree to incorporate them.
>
> I find the suggestion from John Levine to be a good principle and support addressing it as Andrew says, to ensure openness, procedural consistency. It is a good way to clarify that we don't make decisions when one of the Operational Communities are missing - this is important and we have been doing so in practice.
>
> Izumi
>
> On 2016/04/07 16:15, Alan Barrett wrote:
> >
> >>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
> >_______________________________________________
> >Iana-ipr mailing list
> >Iana-ipr@nro.net
> >https://www.nro.net/mailman/listinfo/iana-ipr
> >
>
>
> _______________________________________________
> Iana-ipr mailing list
> Iana-ipr@nro.net
> https://www.nro.net/mailman/listinfo/iana-ipr

--
Andrew Sullivan
ajs@anvilwalrusden.com

_______________________________________________
Iana-ipr mailing list
Iana-ipr@nro.net
https://www.nro.net/mailman/listinfo/iana-ipr