[NRO-IANAXFER] changes to gPDP - out of scope
Hans Petter Holen
hph at oslo.net
Sun Jan 4 11:16:30 CET 2015
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.
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
A better time, in my opinion, would be any other time.
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.
> > 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.
> 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.
> > 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
> > 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 <mailto:hph at oslo.net> |
> > _______________________________________________
> > ianaxfer mailing list
> > ianaxfer at nro.net <mailto: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...
More information about the ianaxfer