Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..
I would like to share key feedback in our community for prop-136, based on a meeting we organised on 25th Aug to discuss these proposals. Many supporsing opinions were expressed about this proposal. (comment details) - This is a revision that will make the policy document very clear. Regards, Satoru Tsurumaki / JPOPF Steering Team 2021年8月13日(金) 8:52 Bertrand Cherrier <b.cherr...@micrologic.nc>: > Dear SIG members, > > The proposal "prop-136-v001: Registration Requirements" has been > sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting (OPM) at APNIC 52 > on Thursday, 16 September 2021. > > https://conference.apnic.net/52/program/schedule/#/day/4 > > We invite you to review and comment on the proposal on the mailing > list before the OPM. > > The comment period on the mailing list before the OPM is an important > part of the Policy Development Process (PDP). We encourage you to > express your views on the proposal: > > - Do you support or oppose this proposal? > - Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. > - Do you see any disadvantages in this proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more effective? > > Information about this proposal is appended below and also available at: > > http://www.apnic.net/policy/proposals/prop-136 > > Regards, > Bertrand and Ching-Heng > APNIC Policy SIG Chairs > > ------------------------------------------------------- > > prop-136-v001: Registration Requirements > > ------------------------------------------------------- > > Proposer: Simon Sohel Baroi (sba...@gmail.com) > Amrita Choudhury (amritachoudh...@ccaoi.in) > > > 1. Problem statement > -------------------- > The registration requirements under Section 5.3 of APNIC Internet Number > Resource Policies document is again broken down into three subsections > (section 5.3.1, 5.3.2 and 5.3.3) based on each resource type. > > > 2. Objective of policy change > ----------------------------- > The objective of the policy change is to make the Section of the policy > more simpler, concise and easier for the community to understand and > adopt and remove duplication if any. > > > 3. Situation in other regions > ----------------------------- > In most of the RIRs like Afrinic, LACNIC and Ripe NCC the registration > requirements have been listed separately for ipv4, ipv6 and ASN under > different clauses. > > > 4. Proposed policy solution > --------------------------- > To avoid repetition of similar requirements for each protocol, the > proposed solution is to incorporate the registration requirements for > ASN and addresses in Section 5.3.1 and updating registration details in > 5.3.2. > > Presently the Section and the sub-sections are as follows : > > 5.3. Registration requirements > > 5.3.1. Requirements for IPv4 addresses > > IRs are responsible for promptly and accurately registering their > address space use with APNIC as follows: > - All delegations from APNIC to the IR must be registered. > - All delegations to downstream IRs must be registered. > - Delegations made to networks greater than a /30 must be registered. > - Delegations made to networks of a /30 or less may be registered, at > the discretion of the IR and the network administrator. > - Delegations to hosts may be registered, at the discretion of the IR > and the end-user. > > IRs can choose whether or not to designate this information "public". > Customer registration details that are not designated "public" will not > be generally available via the APNIC Whois Database. The database record > will instead direct specific whois enquiries to the IR concerned. > > 5.3.1.1. Updating registration details > > IRs must update their registration records when any of the registration > information changes. This is the responsibility of the IR concerned. > However, this responsibility may be formally assigned to the end-user as > a condition of the original delegation. > > 5.3.2. Registration requirements for IPv6 addresses > > When an organisation holding an IPv6 address allocation makes IPv6 > address assignments, it must register assignment information in a > database, accessible by RIRs as appropriate (information registered by > an RIR/NIR may be replaced by a distributed database for registering > address management information in future). > > Information is registered in units of assigned /48 networks. When more > than a /48 is assigned to an organisation, the assigning organisation is > responsible for ensuring that the address space is registered in an > RIR/NIR database. > > RIR/NIRs will use registered data to calculate the HD-Ratio at the time > of application for subsequent allocation and to check for changes in > assignments over time. > > IRs shall maintain systems and practices that protect the security of > personal and commercial information that is used in request evaluation, > but which is not required for public registration. > > Organisations that receive an allocation from APNIC can choose whether > or not their customer assignment registrations should be publicly > available. If the organisation does not indicate a choice, or it chooses > to hide its customer assignment registrations, then those records will > not be visible in the public whois database. Whois queries on these > records will return details of the allocation. > > 5.3.3. Registration requirements for AS Numbers > > All ASNs assigned must be publicly registered in the APNIC, or relevant > NIR, Whois database. APNIC, or the relevant NIR, will create the aut-num > object. > > All attributes of the aut-num object must be properly registered in > accordance with the APNIC or NIR whois database documentation. Without > limiting these general requirements, Section 5.3.3.1 and Section > 5.3.3.2. describe particular requirements for ASN registration. > > 5.3.3.1. Registering routing policy > APNIC recommends that the routing policy of the AS is registered for > each ASN assigned. > > 5.3.3.2. Updating registration details > Organizations responsible for ASNs should update the aut-num object in > the appropriate database if any of the registration information changes. > > What we propose is: > > 5.3. Registration requirements > > 5.3.1. Requirements for Autonomous System Numbers (ASNs) and Addresses > > IRs are responsible for promptly and accurately registering their ASN > and address space use with APNIC as follows: > > ·All ASNs assigned must be publicly registered in the APNIC, or relevant > NIR, Whois database, for which APNIC or NIR will create the aut-num object. > ·All the attributes of the aut-num object, must be registered in > accordance with APNIC or NIR whois database documentation. > ·All delegations from APNIC to the IR must be registered. > ·All delegations to downstream IRs must be registered. > ·Delegations made to networks greater than a /30 for IPv4 and /48 for > IPv6 must be registered. > ·Delegations made to networks of a /30 for IPv4 and /48 for IPv6 or less > may be registered, at the discretion of the IR and the network > administrator. > ·Delegations to hosts may be registered, at the discretion of the IR and > the end-user. > > IRs can choose whether or not to designate this information "public". > Customer registration details that are not designated "public" will not > be generally available via the APNIC Whois Database. The database record > will instead direct specific whois enquiries to the IR concerned. > > 5.3.2. Updating registration details > > IRs must update their registration records and relevant objects when any > of the registration information changes. This is the responsibility of > the IR concerned. However, this responsibility may be formally assigned > to the end-user as a condition of the original delegation. > > Further, APNIC recommends that the routing policy of the AS is > registered for each ASN assigned. > > > 5. Advantages / Disadvantages > ----------------------------- > Advantages: > It makes the policy for registration requirements simpler, concise and > easy to understand, removing duplication of similar requirements. > > Disadvantages: > There are no disadvantages. > > > 6. Impact on resource holders > ----------------------------- > None. It just makes the policy of registering requirements precise, > easier to understand and concise removing duplication. > > > 7. References > ------------- > [1] > > https://www.apnic.net/community/policy/resources#5.3.-Registration-requirements > > > [2] https://afrinic.net/policy/manual > > [3] https://www.ripe.net/publications/docs/ripe-738 > > [4] https://www.lacnic.net/682/2/lacnic/2-ipv4-addresses > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > sig-policy@lists.apnic.net > https://mailman.apnic.net/mailman/listinfo/sig-policy -- -- Satoru Tsurumaki BBIX, Inc
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net https://mailman.apnic.net/mailman/listinfo/sig-policy
