Some suggestions from IANAPLAN today
Hi,
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.
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.
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?
Best regards,
A
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
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
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
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
participants (4)
-
Alan Barrett -
Andrew Sullivan -
Greg Shatan -
Izumi Okutani