Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
Dear All,
Amrita and myself are proposing the following draft proposal for section 5.3.1, 5.3.2 and 5.3.3. Requesting your comment by 4th Aug, 2021.
*Secretariat Observation :*
*• Registration requirements (section 5.3) for each resource type (section 5.31, 5.3.2, and 5.3.3) – Are the registration requirements for the three resource types so different from each other? – Could make it be better by unifying the policies *
*Title of proposal* * Registration Requirements
*Problem statement: *
The registration requirements under Section 5.3 is again broken down into three subsections (section 5.3.1, 5.3.2 and 5.3.3) based on each resource type.
*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.
*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.
*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 organization 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 organization, the assigning organization 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.
Organizations that receive an allocation from APNIC can choose whether or not their customer assignment registrations should be publicly available. If the organization 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 https://www.apnic.net/community/policy/resources#5.3.3.1.%20Registering%20routing%20policy and Section 5.3.3.2. https://www.apnic.net/community/policy/resources#5.3.3.2.%20Updating%20registration%20details 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.
As per APNIC: https://www.apnic.net/community/policy/resources#5.3.-Registration-requireme...
*What we propose is:* 5.3. Registration requirements 5.3.1. Requirements for ASN and addresses IRs are responsible for promptly and accurately registering their AS number 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
*Explain the advantages of the proposal:*
It makes the policy for registration requirements simpler, concise and easy to understand, removing duplication of similar requirements.
*Explain the disadvantages of the proposal: *
There are no disadvantages.
*Impact on resource holders:*
None. It just makes the policy of registering requirements precise, easier to understand and concise removing duplication.
References(if any)
Dear Simon,
Thank you so much for your proposal.
A few comments:
5.3.1. Requirements for ASN and addresses
ASN -> AS Numbers (ASNs)
Section title of current version is 'AS Numbers', and it will be better to write what is 'ASN'.
· Delegations to hosts may be registered, at the discretion of the IR and the end-user.
I'm afraid if it is possible to register IPv6 hosts (/128), since current version do not mention about IPv6 host registration.
Yours Sincerely, --- Tomohiro Fujisaki
2021?8?2?(?) 1:58 Simon Sohel Baroi sbaroi@gmail.com:
Dear All,
Amrita and myself are proposing the following draft proposal for section 5.3.1, 5.3.2 and 5.3.3. Requesting your comment by 4th Aug, 2021.
Secretariat Observation :
• Registration requirements (section 5.3) for each resource type (section 5.31, 5.3.2, and 5.3.3) – Are the registration requirements for the three resource types so different from each other? – Could make it be better by unifying the policies
Title of proposal * Registration Requirements
Problem statement:
The registration requirements under Section 5.3 is again broken down into three subsections (section 5.3.1, 5.3.2 and 5.3.3) based on each resource type.
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.
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.
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 organization 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 organization, the assigning organization 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.
Organizations that receive an allocation from APNIC can choose whether or not their customer assignment registrations should be publicly available. If the organization 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.
As per APNIC: https://www.apnic.net/community/policy/resources#5.3.-Registration-requireme...
What we propose is:
5.3. Registration requirements
5.3.1. Requirements for ASN and addresses
IRs are responsible for promptly and accurately registering their AS number 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
Explain the advantages of the proposal:
It makes the policy for registration requirements simpler, concise and easy to understand, removing duplication of similar requirements.
Explain the disadvantages of the proposal:
There are no disadvantages.
Impact on resource holders:
None. It just makes the policy of registering requirements precise, easier to understand and concise removing duplication.
References(if any)
[wg-pdr] Policy Document Review Working Group mailing list -- wg-pdr@apnic.net To unsubscribe send an email to wg-pdr-leave@apnic.net
Hi Simon,
I fully support this proposal
Best Regards,
Le 02/08/2021 à 03:57, Simon Sohel Baroi a écrit :
Dear All,
Amrita and myself are proposing the following draft proposal for section 5.3.1, 5.3.2 and 5.3.3. Requesting your comment by 4th Aug, 2021.
_Secretariat Observation :___
/• Registration requirements (section 5.3) for each resource type (section 5.31, 5.3.2, and 5.3.3) – Are the registration requirements for the three resource types so different from each other? – Could make it be better by unifying the policies /
*Title of proposal** Registration Requirements
*Problem statement: *
The registration requirements under Section 5.3 is again broken down into three subsections (section 5.3.1, 5.3.2 and 5.3.3) based on each resource type.
*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.
*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.
*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 addressesIRs 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 detailsIRs 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 addressesWhen an organization 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 organization, the assigning organization 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.
Organizations that receive an allocation from APNIC can choose whether or not their customer assignment registrations should be publicly available. If the organization 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 NumbersAll 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 https://www.apnic.net/community/policy/resources#5.3.3.1.%20Registering%20routing%20policyand Section 5.3.3.2. https://www.apnic.net/community/policy/resources#5.3.3.2.%20Updating%20registration%20detailsdescribe particular requirements for ASN registration.
5.3.3.1. Registering routing policyAPNIC recommends that the routing policy of the AS is registered for each ASN assigned.
5.3.3.2. Updating registration detailsOrganizations responsible for ASNs should update the aut-num object in the appropriate database if any of the registration information changes.
As per APNIC: https://www.apnic.net/community/policy/resources#5.3.-Registration-requireme... https://www.apnic.net/community/policy/resources#5.3.-Registration-requirements
**
*What we propose is:*
5.3. Registration requirements 5.3.1. Requirements for ASN and addresses IRs are responsible for promptly and accurately registering their AS number 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*Explain the advantages of the proposal:*
It makes the policy for registration requirements simpler, concise and easy to understand, removing duplication of similar requirements.
*Explain the disadvantages of the proposal: *
There are no disadvantages.
*Impact on resource holders:*
None. It just makes the policy of registering requirements precise, easier to understand and concise removing duplication.
References(if any)
[wg-pdr] Policy Document Review Working Group mailing list -- wg-pdr@apnic.net To unsubscribe send an email to wg-pdr-leave@apnic.net
Hi Simon, all,
Yes, this is very close to what I proposed in my document I think it was back in March or April, so I agree with it.
One minor point I will suggest to make it simpler:
Instead of: 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.
Use:
Smaller delegations may be registered, at the discretion of the IR and the network administrator.
The sentence before this one, already sets the “size” (>/30 and >/48), so just saying “smaller” sait it without chances for missinterpretation.
Regards,
Jordi
@jordipalet
Dear All,
Amrita and myself are proposing the following draft proposal for section 5.3.1, 5.3.2 and 5.3.3. Requesting your comment by 4th Aug, 2021.
Secretariat Observation :
• Registration requirements (section 5.3) for each resource type (section 5.31, 5.3.2, and 5.3.3) – Are the registration requirements for the three resource types so different from each other? – Could make it be better by unifying the policies
Title of proposal * Registration Requirements
Problem statement:
The registration requirements under Section 5.3 is again broken down into three subsections (section 5.3.1, 5.3.2 and 5.3.3) based on each resource type.
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.
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.
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 organization 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 organization, the assigning organization 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.
Organizations that receive an allocation from APNIC can choose whether or not their customer assignment registrations should be publicly available. If the organization 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.
As per APNIC: https://www.apnic.net/community/policy/resources#5.3.-Registration-requireme...
What we propose is:
5.3. Registration requirements
5.3.1. Requirements for ASN and addresses
IRs are responsible for promptly and accurately registering their AS number 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
Explain the advantages of the proposal:
It makes the policy for registration requirements simpler, concise and easy to understand, removing duplication of similar requirements.
Explain the disadvantages of the proposal:
There are no disadvantages.
Impact on resource holders:
None. It just makes the policy of registering requirements precise, easier to understand and concise removing duplication.
References(if any)
_______________________________________________ [wg-pdr] Policy Document Review Working Group mailing list -- wg-pdr@apnic.net To unsubscribe send an email to wg-pdr-leave@apnic.net
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Activity Summary
- 672 days inactive
- 672 days old
- wg-pdr@apnic.net
- 4 participants
- 3 comments