Consultation on Policy Documentation Adam Gosling APNIC 40 Policy SIG 10 September 2015

New Draft Document (apnic-127-v002) Remove redundancy in –Resource license and License renewal sections –Recovery of unused historical resource sections –Simplify definition of Utilization in IPv6 Policy –Confidentiality and request processing procedures Other minor corrections and edits for simplicity Resolve conflicts between various definitions for multihoming Clarification of contacts in IPv6 policy Visit to review or provide input 2

Definitions of multihoming The definition of multihoming depends on which policy you were looking at. Autonomous System number policy IPv4 address policy IPv6 address policy 3

ASN Policy (apnic-094-v007) Definition of multihomed –A multi-homed AS is one which is connected to more than one other AS. –An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.

IPv4 Policy (apnic-124-v002 & apnic-125-v001) Definition –An organization is considered to be multihomed if its network receives fulltime connectivity from more than one ISP and has one or more routing prefixes announced by at least two of its ISPs. 5

IPv6 Policy (apnic-089-v012) Definition –No definition, except as below Eligibility for IPv6 to use in multihoming –An organization is eligible to receive a portable assignment from APNIC if it is currently, or plans to be, multihomed. –An organization is considered to be multihomed if its network receives full-time connectivity from more than one ISP and has one or more routing prefixes announced by at least two of its ISPs. 6

Solution New Definition of Multihoming based on RFC1930 –Multihoming is a way of connecting an organization’s network to the public Internet through more than one AS. 7

Registration of Contact Persons The requirements for registering contact persons depends on which policy you were looking at. IPv4 address policy Autonomous System number policy IPv6 address policy 8

IPv4 Policy (apnic-124-v002 & apnic-125-v001) Administrative and technical contact persons must be registered. The registered administrative contact ("admin-c") must be someone who is physically located at the site of the network, subject to the following exceptions: –For residential networks or users, the IR's technical contact may be registered as the admin-c. –For networks in exceptional circumstances that make it impractical to maintain an on-site administrative contact, an off-site person may be registered as the admin-c. The technical contact ("tech-c") need not be physically located at the site of the network, but must be a person who is responsible for the day-to-day operation of the network. In addition, it is mandatory to register an Incident Response Team (IRT) object for each address block record in the APNIC Whois Database 9

ASN Policy (apnic-094-v007) Administrative and technical contact persons must be registered for each ASN assigned. The registered administrative contact ('admin-c') is the person responsible for the ASN and should generally be someone who is physically located at the site of the AS. The technical contact ('tech-c') need not be physically located at the site of the AS, but must be a person who is responsible for the day-to-day operation of that AS. In addition, it is mandatory to register an Incident Response Team (IRT) object for each AS Number record in the APNIC Whois Database. 10

IPv6 Policy (apnic-089-v012) In addition, it is mandatory to register an Incident Response Team (IRT) object for each allocation and assignment record in the APNIC Whois Database. 11

Solution Tech-c and Admin-c are required for IPv6 address blocks Adjust policy document to reflect community expectations and standard operational practice 12

Editorial Comment Period There are many changes in the new version, this is just a sample. For more information and to review the changes, please visit the APNIC website Please submit any feedback by to Deadline is 10 October

Feedback? 14