NRO Comments on Consultation on the Source of Policies & User Instructions for Internet Number Resource Requests
HI On behalf of the NRO please find in attach the comments to the consultation Consultation on the Source of Policies & User Instructions for Internet Number Resource Requests Regards German Valdez NRO Executive Secretary ==== Consultation on the Source of Policies & User Instructions for Internet Number Resource Requests Consultation Questions 1. Is it clear and easy to understand how to request additional Internet Number Resources? It is clear which email addresses to use for most Internet Number Resource Requests. However, for AS Number Allocation there are two email addresses mentioned: Under bullet 1, ³an RIR requesting additional AS Numbers because it has assigned/allocated over 80% of its last block of AS Numbers needs to provide a summary of assignments/allocations it has made², the email address listed is: asn-request@xxxxxxxxx Under bullet 2, ³An RIR requesting additional AS Numbers because the number of free AS Numbers it holds is less than two months needed², the email address listed is: iana@xxxxxxxx 2. Are the descriptions of the information required for resource requests clearly documented? The descriptions are not clear and contradicting at times. It could be useful to have a spreadsheet template for each request specifying what type of information is needed. · IPv4 Allocation It is unclear what documentation (and in what format) the RIR needs to provide when it notifies ICANN that it has less than half a /8 in its inventory. · IPv6 Allocation - We understand we should provide a simple excel file containing: - Total amount allocated (in total prefix size) - Total amount reserved (in total prefix size) - Total amount fragmentation - The user instructions should specify that the RIR can choose its own allocation and reservation strategies, as defined in ³Internet Assigned Numbers Authority (IANA) Policy For Allocation of IPv6 Blocks to Regional Internet Registries². - The user instructions should specify what is defined as fragmentation, as the definition is slightly different in this policy than usual: ³the total amount of available blocks smaller than the RIR's minimum allocation size within the RIR's currently available stock.² It is not entirely clear how the RIR should show the level of fragmentation. · AS Number Allocation - The user instructions seem to indicate that the RIR can specify how many ASN blocks it is requesting. This is contradicting with the global policy. The user instructions say: ³If the RIR is requesting more than one block of AS Numbers². The global policy says: ³An RIR will be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months, based on their average assignment/allocation rate over the previous six months, unless the RIR specifically requests fewer blocks than it qualifies for.² - Depending on the number of blocks the RIR is requesting, different information is requested. For one block the RIR needs to provide a summary of assignments/allocations it has made. For multiple blocks, the RIR needs to provide a usage summary for the past six months. This is confusing, as according to the global policy the RIR does not specify the number of blocks requested. In order to be able to submit a complete request, the RIR should make the calculation in advance. - We understand that a summary of assignments/allocations means the RIR will include how much percent is in use of the last AS-block it has received. We understand that a usage summary for the past six months means we will provide a list of how many ASN were assigned/allocated per month. · Change in Named Registrant This section needs to be further clarified. - The acronym INR should be fully spelled out. The title is not clear. - It is unclear what change requests this section applies to: - inter-RIR transfers where the majority RIR may shift to another RIR? - transfers of legacy number resources between RIRs? - direct allocations made by ICANN? - It is not clear what information needs to be provided and in which format. - Which party can make these change requests? - Will ICANN respond directly to requests from registrants? - How and by which party will the requests be verified to ensure they are authorized. 3. Do you have any other input on the draft user instructions? A standard Service Level Agreement should be incorporated into this document that specifies when an RIR should expect an initial acknowledgment of the request, as well as expected response times to all back and forth correspondence. 4. In which formats would you like the user instructions published on ICANN¹s IANA website? We suggest the instructions be published in HTML plus a downloadable PDF version. Attachment:
RSMcoord-response-Consultation on the Source of Policies-EC REVIEWED.docx |