[Iana-ipr] Some suggestions from IANAPLAN today

Andrew Sullivan ajs at anvilwalrusden.com
Thu Apr 14 18:24:54 CEST 2016


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 at 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 at nro.net
> >https://www.nro.net/mailman/listinfo/iana-ipr
> >
> 
> 
> _______________________________________________
> Iana-ipr mailing list
> Iana-ipr at nro.net
> https://www.nro.net/mailman/listinfo/iana-ipr

-- 
Andrew Sullivan
ajs at anvilwalrusden.com



More information about the Iana-ipr mailing list