[NRO-IANAXFER] changes to gPDP - out of scope

Seun Ojedeji seun.ojedeji at gmail.com
Sun Jan 4 15:07:31 CET 2015

sent from Google nexus 4
kindly excuse brevity and typos.
On 4 Jan 2015 11:16, "Hans Petter Holen" <hph at oslo.net> wrote:
> Hi Seun,
> On 03.01.15 19.17, Seun Ojedeji wrote:
>> >
>> > On 03.01.15 07.47, Seun Ojedeji wrote:
>> >>
>> >> - I made a suggestion on minor changes on the gPDP, may I also know
what the crisp has determined about that?
>> >
>> > First, as I read the charter for the CRISP, reviewing the Global
Policy Development Process is outside the charter.
>> >
>> Could you refer me to a section that indicated that in the charter? If
that is indeed the case then there is no need to further on this discussion
except that I will say gPDP is one of the existing accountability measure
and looking to strengthen existing accountability measure should be the
main goal of this transition.
> It was simply my interpretation is from reading the charter and the RFP.
> I can see that if you argue that if the gPDP needs to be changed because
the NTIA steps out, that it would be within scope, but as far as I have
been able to etablish in the past the NTIA has no role in number policy.
My point is that NTIA's role as perceived is largely to keep ICANN
accountable (which also includes referencing the gPDP as a source of
accountability guideline) and if NTIA is going, isn't it just normal to
review the existing sources like the gPDP to determine if it's sufficient
and needs to be improved upon (which is part of the intent of RFP 2 and 3).

> Hence my interpretation.
>> > I also think it is unwise to open up the Global Policy Development
Process at the same time as we are discussing the implementation.
>> >
>> I am not sure I get your point, do you care to explain further? why is
discussing gPDP unwise, I mean could you tell me a better time to discuss
it; is there any existing formal process to discuss gPDP update?
> My experience has been that for any change, it is easier to get the
change done, and archive consensus for what is needed, if the scope is
sufficiently narrow.
Isn't that what we are doing in this process; trying to achieve consensus
for a particular change. The suggested section to be updated is in relation
to the accountability of IANA operator which is the subject of this
process. How further narrow can the scope be?

> A better time, in my opinion, would be any other time.
Well I agree gPDP may be updated anytime, however I disagree on the
exclusion of "this period" as I think it's a better time (both in resource
maximization and process utilization ).

> As for formal process I am not sure. Some will suggest to use the gPDP to
change the gPDP - but I do not think that has been specified. Formaly it is
in the MOU between ICANN and the RIRs so it would have to be an update to
the MOU.
Section 9 of the MOU is clear on how update can be done. One could then
suggest that the gPDP (as a reference from the MOU) can be updated in
manner described in section 9.

>> > So my strong opinion is that changes to the Global Policy Development
Process and the ASO MOU, should in my opinion be handled separately from
the NTIA transition.
>> >
Well I don't understand the clear distinction you are making here; the NTIA
refers to those documents and those scripts are what the operator use in
implementation so why is it separate.

>> Isn't one of the numbers accountability source referred to by NTIA in
it's contract the gPDP? So why would you say reviewing the existing
mechanism with the possibility of improving on it out of this NTIA
transition scope. Personally I would even say adding SLA as attachment C to
the ICANN/NRO MOU and including a few lines in the agreement to reflect the
transition changes would have been a neater way to reflect this transition
in the first place.
> Adding the SLA to the MOU in my mind ties the role of ICANN as final
policy endorser and ICANN as IANA operator togehter.  I belive the two
should be separate.
Sorry again, I don't get the distinction you are making here? Isn't ICANN
already performing those 2 roles at global level?

Overall, the minor changes suggested is not to imply weakness in current
gPDP but to strengthen it to reflect present situation. I think it is just
logical that 1 RIR out of 5 agreeing with ICANN board and thereby stalling
the position of other 4 is not a consensus close to "rough". Even though we
may never exercise that part of the gPDP, I think it's something worth
updating and I am of the opinion that this is an appropriate time.


>> > So to your proposal:
>> >
>> > I had a look trough the archives and assume you refer to:
>> >
>> > On 19.12.14 07.20, Seun Ojedeji wrote:
>> >>
>> >> Finally on a related note, i suggest a minor update of section 10 of
the gPDP as follow:
>> >>
>> >> In case Step 9 (c), should at least two of the RIRs agree that
changes need to be made
>> >
>> > If I get this right you are suggesting that two, rather than one, RIRs
has to agree with a simple majority of the ICANN boards request to make
changes to a policy proposal, for the proposal to be sent back to step 1 in
the policy development process. In the event that the ICANN board.
>> >
>> yes.... in the event that ICANN board disagree with the policy proposal,
it should require at least 2 RIR in agreement to take us back to step 1. My
rationale for this is that while a number of 1 out of 4 RIR may be fine as
at the time the agreement was signed. However now that we have 5 RIRs,
ensuring the view of the majority wins is important hence my reason for
suggesting the minor update.
> So this is really related to #RIRs increasing from 4 to 5 rather than the
NTIA transition.
>> > Personally I would rather see ICANN giving input much earlier in the
process rather than having this power at the very end of the process, so I
think this proposal requires more detailed discussion in all regions to
archive consensus on changes to the Global PDP.
>> >
>> Could you clarify your statement above. Kindly note that I am referring
to global policy proposals that have achieved entire RIR community
consensus and then awaits ICANN board approval.
> In the RIPE Policy development process, and I believe it is the same in
the other regions, there is a point in time, where the RIPE NCC publishes
an Impact analysis of the proposal so this can be part of the discussion by
the community.
> I think it would be better if the IANA operator/ICANN would give its
input at this stage for Global policy proposals.
> When the proposal is past the ASO AC - it is - in my opinion - past
changes - it should only be possible to send it back if process has not
been followed - and in my opinion that should be done by the ASO AC
> Hans Petter
>> Regards
>> >
>> > Context for reference:
>> >
>> > Refering to the ASO MOU attachment A,
>> > http://archive.icann.org/en/aso/aso-mou-attachmentA-29oct04.htm
>> >
>> > 9. Within 60 days of receipt of the proposed policy, including such
consultation as may occur in Step 8, the ICANN Board may either:
>> >
>> > accept the proposal by a simple majority vote; or
>> > reject the proposed policy by a supermajority (2/3) vote; or
>> > by a simple majority vote request changes to the proposed policy; or
>> > take no action.
>> > 10. If the ICANN Board takes no action (that is, fails to take actions
(a), (b) or (c) in Step 9) within the 60-day window, the proposed policy is
deemed to be accepted by the ICANN Board and it becomes global policy.
>> >
>> > In case Step 9 (c), should at least one of the RIRs agree that changes
need to be made, the status of the proposed policy reverts to Step 1.
>> >
>> > If none of the RIRs accept the case for changes, then the proposed
policy continues to Step 11.
>> >
>> >
>> >
>> > --
>> > Hans Petter Holen
>> > Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net
>> >
>> >
>> > _______________________________________________
>> > ianaxfer mailing list
>> > ianaxfer at nro.net
>> > https://www.nro.net/mailman/listinfo/ianaxfer
>> >
> --
> Hans Petter Holen
> Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.nro.net/pipermail/ianaxfer/attachments/20150104/b32bed35/attachment.html>

More information about the ianaxfer mailing list