sig-policy August 2018

sig-policy@lists.apnic.net

13 participants
11 discussions

prop-126-v001 : PDP Update
by Bertrand Cherrier 11 Sep '18

11 Sep '18

Dear SIG members, The proposal "prop-126-v001: PDP Update" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting at APNIC 46 in Noumea, New Caledonia on Thursday, 13 September 2018. We invite you to review and comment on the proposal on the mailing list before the meeting. The comment period on the mailing list before an APNIC meeting is an important part of the policy development process. 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 available at: http://www.apnic.net/policy/proposals/prop-126 Regards Sumon, Bertrand, Ching-Heng APNIC Policy SIG Chairs https://www.apnic.net/wp-content/uploads/2018/08/prop-126-v001.txt ---------------------------------------------------------------------- prop-126-v001: PDP Update ---------------------------------------------------------------------- Proposer: Jordi Palet Martínez jordi.palet(a)theipv6company.com 1. Problem Statement -------------------- With its requirement of face-to-face participation at the OPM, the current PDP might – at least partially – be the cause of the low levels of community participation in the process by using the policy mailing list. This proposal would allow an increased participation, by considering also the comments in the list for the consensus determination. So, consensus would be determined balancing the mailing list and the forum, and would therefore increase community participation. Further, policy proposals are meant for the community as a whole, and not only APNIC members, so this proposal suggest removing the actual “double” consensus required in both groups. Moreover, requiring 4 weeks in advance to the OPM, seems unnecessary as the consensus determination can be done in two stages (SIG meeting and list), so the proposal looks for just 1 week in advance to the SIG responsible for that proposal. Finally, it completes the PDP by adding a simple mechanism for solving disagreements during an appeals phase and an improved definition of ‘consensus’. 2. Objective of policy change ----------------------------- To allow that consensus is determined also looking at the opinions of community members that are not able to travel to the meetings, adjust the time required before the relevant SIG to submit the proposals, not requiring “double” consensus with the APNIC members and facilitating a simple method for appeals. 3. Situation in other regions ----------------------------- The PDP is different in the different RIRs. This proposal is similar to the RIPE PDP, possibly the region with the broadest participation in its policy proposal discussions, although there are certain differences such as the mandatory use of the mailing list and the meeting, which is more similar to the PDP at ARIN (another region with broad community participation). LACNIC has recently adopted a similar policy proposal with the same aims. 4. Proposed policy solution --------------------------- PDP documnet https://www.apnic.net/about-apnic/corporate-documents/documents/policy-deve… 4. Proposal process A policy proposal must go through the following chronological steps in order to be adopted by APNIC. Actual: Step 1 Discussion before the OPM A formal proposal paper must be submitted to the SIG mailing list and to the SIG Chair four weeks before the start of the OPM. The proposal must be in text which clearly expresses the proposal, with explicit mention of any changes being proposed to existing policies and the reasons for those changes. The APNIC Secretariat will recommend a preferred proposal format. If the four-week deadline is not met, proposals may still be submitted and presented for discussion at the meeting; however, no decision may be made by the meeting regarding the proposal. The proposal will need to be resubmitted in time for the following meeting if the author wishes to pursue the proposal. Proposed: Step 1 Discussion before the OPM A formal proposal paper must be submitted to the SIG mailing list and to the SIG Chair one week before the start of the OPM. The proposal must be in text which clearly expresses the proposal, with explicit mention of any changes being proposed to existing policies and the reasons for those changes. The APNIC Secretariat will recommend a preferred proposal format. If the four-week deadline is not met, proposals may still be submitted and presented for discussion at the meeting; however, no decision may be made by the meeting regarding the proposal. The proposal will need to be resubmitted in time for the following meeting if the author wishes to pursue the proposal. Actual: Step 2 Consensus at the OPM Consensus is defined as “general agreement” as observed by the Chair of the meeting. Consensus must be reached first at the SIG session and afterwards at the Member Meeting for the process to continue. If there is no consensus on a proposal at either of these forums, the SIG (either on the mailing list or at a future OPM) will discuss whether to amend the proposal or to withdraw it. Proposed: Step 2 Consensus at the OPM Consensus is defined as “general agreement” as observed by the Chairs. Consensus is determined in both, the SIG session and the SIG mailing list. If there is no consensus on a proposal, the SIG (either on the mailing list or at a future OPM) will discuss whether to amend the proposal or to withdraw it. Actual: Step 3 Discussion after the OPM Proposals that have reached consensus at the OPM and the AMM will be circulated on the appropriate SIG mailing list for a period. This is known as the “comment period”. The duration of the “comment period” will be not shorter than four weeks and not longer than eight weeks. The decision to extend more than four weeks, including the duration of the extension, will be determined at the sole discretion of the SIG Chair. Proposed: Step 3 Discussion after the OPM Proposals that have reached consensus at the OPM will be circulated on the appropriate SIG mailing list for a period. This is known as the “comment period”. The duration of the “comment period” will be not shorter than four weeks and not longer than eight weeks. The decision to extend more than four weeks, including the duration of the extension, will be determined at the sole discretion of the SIG Chair. Step 4 No change. Actual: Step 5 Endorsement from the EC The EC, in their capacity as representatives of the membership, will be asked to endorse the consensus proposals arising from the OPM and the SIG mailing lists for implementation at the next EC meeting. In reviewing the proposals for implementation, the EC may refer proposals back to the SIG for further discussion with clearly stated reasons. As per the APNIC By-laws, the EC may, at its discretion, refer the endorsement to a formal vote of adoption by the APNIC members. Proposed: Step 5 Endorsement from the EC The EC, in their capacity as representatives of the membership, will be asked to endorse the consensus proposals arising from the OPM and the SIG mailing lists for implementation at the next EC meeting. In reviewing the proposals for implementation, the EC may refer proposals back to the SIG for further discussion with clearly stated reasons. As per the APNIC By-laws, the EC may, at its discretion, refer the endorsement to a formal vote of adoption by the APNIC members. Appeals process In case of disagreement during the process, any member of the community must initially bring the matter to the mailing list for consideration by the Chairs. Alternately, if any member considers that the Chairs have violated the process or erred in their judgement, they may appeal their decision through the EC, which must decide the matter within a period of four weeks. 5. Advantages / Disadvantages ----------------------------- Advantages: Fulfilling the objectives above indicated and making sure that there is no discrimination with community members that aren’t able to travel. Disadvantages: None foreseen. 6. Impact on resource holders ----------------------------- None. 7. References ------------- http://www.lacnic.net/679/2/lacnic/policy-development-process https://www.ripe.net/publications/docs/ripe-642 _________________________________ Sumon, Ching-Heng and Bertrand APNIC Policy SIG Chairs

5 12

prop-125-v001: Validation of "abuse-mailbox" and other IRT emails
by Sumon Ahmed Sabir 11 Sep '18

11 Sep '18

Dear SIG members, The proposal "prop-125-v001: Validation of "abuse-mailbox" and other IRT emails" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting at APNIC 46 in Noumea, New Caledonia on Thursday, 13 September 2018. We invite you to review and comment on the proposal on the mailing list before the meeting. The comment period on the mailing list before an APNIC meeting is an important part of the policy development process. 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 available at: http://www.apnic.net/policy/proposals/prop-125 Regards Sumon, Bertrand, Ching-Heng APNIC Policy SIG Chairs https://www.apnic.net/wp-content/uploads/2018/08/prop-125-v001.txt ---------------------------------------------------------------------- prop-125-v001: Validation of "abuse-mailbox" and other IRT emails ---------------------------------------------------------------------- Proposer: Jordi Palet Martínez - jordi.palet(a)theipv6company.com Aftab Siddiqui - aftab.siddiqui(a)gmail.com 1. Problem Statement -------------------- APNIC implemented mandatory IRT references on 8 November 2010. This means it is mandatory to register an Incident Response Team (IRT) object for each resource record in the APNIC Whois Database. The policy mandates IRT references for each inetnum, inet6num and aut-num objects, however in many cases, those contain out-of-date, inaccurate, non-existent or not actively monitored abuse-mailbox information. In practice, this contact becomes ineffective to report abuses and generally gives rise to security issues and costs for the victims. This proposal aims to solve the problem and ensure the existence of a proper abuse-mailbox contact and the process for its utilization. 2. Objective of policy change ----------------------------- The Internet community is based on collaboration. In many cases, however, this is not enough and we all need to be able to contact those LIRs which may be experiencing a problem in their networks and may not be aware of the situation. This proposal aims to solve this problem by means of a simple, periodic verification of IRT object emails, and establishes the basic rules for performing such verification and thus avoids unnecessary costs to third parties who need to contact the persons responsible for solving the abuses of a specific network. The proposal guarantees that the cost of processing the abuse falls on the LIR whose client is causing the abuse (and from whom they receive financial compensation for the service), instead of falling on the victim, as would be the case if they had to resort to the courts, thus avoiding costs (lawyers, solicitors, etc.) and saving time for both parties. 3. Situation in other regions ----------------------------- A similar proposal is being discussed in LACNIC and being prepared for AfriNIC and RIPE NCC. Currently, ARIN conducts an annual POC (point of contact) validation and RIPE NCC validates the “abuse-mailbox:” attribute annually (ripe-705). 4. Proposed policy solution --------------------------- 1. About the "abuse-mailbox", “email”, “admin-c” and “tech-c” Emails sent to "abuse-mailbox", “email”, “admin-c” and “tech-c” must require manual intervention by the recipient at some time, and may not be filtered, as in certain cases this might prevent the reception of the abuse reports, for example a case of spam, as it would include the spam message itself or URLs or content usually classified as spam. The mailboxes may initially send an automatic reply, for example, assigning a ticket number, applying classification procedures, requesting further information, etc. However, it may not require the use of a form, as this would imply that each company that needs to report cases of abuse (a task that is typically automated) would be forced to develop a specific interface for each case, which is neither feasible nor logical, as it would place the cost of processing the abuse on those who submit the claim and are therefore victims of the abuse, instead of being paid by the those whose client causes the abuse (and from whom they obtain income). By way of information, it is worth noting that it is reasonable for the person reporting the abuse to do so from the start and in that first report, sending the logs, or a copy of the spam message (attaching an example of the spam email or its full headers) or similar evidence proving the abuse. Likewise, it is reasonable to expect that the initial auto-reply email will specify that the claim will not be processed unless such evidence has been submitted, thus allowing the sender the opportunity to repeat the submission and include the pertinent evidence. This allows automatic reporting, for example, via fail2ban, SpamCop or others, keeping costs at a minimum for both parties involved. 2. Objectives of "abuse-mailbox", “email”, “admin-c” and “tech-c” validation The procedure, which is to be developed by APNIC, must meet the following objectives: 1) A simple process that guarantees its functionality and allows the helpdesks that deal with abuse reports to verify that validation requests actually come from APNIC and not from third parties (which might involve security risks), avoiding, for example, a single "direct" URL for validation. 2) Avoid automated processing. 3) Confirm that the person performing the validation ensure that understands the procedure and the policy, that they regularly monitor the "abuse-mailbox", “email”, “admin-c” and “tech-c”, that measures are taken, and that the abuse report receives a response. 4) Validation period no longer than fifteen (15) days. 5) If validation fails, escalate to the LIR and set a new validation period not to exceed the fifteen (15) days. (By way of example, a detailed procedure is included in this policy proposal under "Additional Information") 3. Validation of "abuse-mailbox", “email”, “admin-c” and “tech-c” APNIC will validate compliance with the items above, both when the "abuse-mailbox", “email”, “admin-c” and/or “tech-c” attributes are created or updated, as well as periodically, not less than once every six months, and whenever APNIC sees fit. At the discretion of APNIC, in general or in specific cases (for example, for confirmation in cases of escalation under 4., APNIC may use domains other than apnic.*, and even modify the subject and body of the message, in order to perform said validations more effectively. Lack of compliance will imply a more exhaustive follow-up, in accordance with the relevant APNIC policies, procedures and membership agreement and a temporary lock of myapnic access, until resolved. 4. Escalation to APNIC To avoid fraudulent behavior (for example, an "abuse-mailbox" that only replies to APNIC’s emails, or to messages with a specific subject or content), or failure to comply with the remaining aspects of this policy (incorrect or lack of response to cases of abuse) and, therefore, to guarantee the quality of the services in the region with the resources allocated by APNIC, a mailbox will be available (for example, " escalation-abuse(a)apnic.net"), to escalate such situations, thus allowing for a re-validation (according to section 3. above) and even the intermediation by APNIC and, where appropriate, the application of the relevant policies/procedures, APNIC policies, procedures and membership agreement. i) In case there is no response from all the email addresses associated with the IRT object, then mark that IRT object invalid and block access to myapnic and use other means to contact the member (e.g. via billing contact or corporate contact) ii) if there is no response from some of the email address associated with the IRT object, then mark those attributes invalid and contact the member for the resolution. If the problem is not fixed after fifteen (15) days then block access to myapnic and use other means to contact the member (e.g. via billing contact or corporate contact). 5. Advantages / Disadvantages ----------------------------- Advantages: The purpose of creating IRT object in the APNIC whois database is to provide a more accurate and efficient way for abuse reports to reach the correct network contact. Fulfilling the objectives above indicated and ensuring that a real contact can be approached in case of abuse cases and effectively serve the purpose of creating IRT object. This will improve the quality of the information and help to achieve the goal of handling network abuses. Disadvantages: None foreseen. 6. Impact on resource holders ----------------------------- APNIC members have to verify and update (if required) their IRT objects periodically. 7. References ------------- ADDITIONAL INFORMATION a. Since this proposal is implemented, APNIC will publish the IRT also as abuse-c, in order to facilitate the search in whois, for the same information, regardless if looking for abuse-c or IRT. This is done in order to assimilate the IRT to the majority of the RIRs where it is abuse-c. b. It is recommend that all NIRs implement a similar validation process within their own jurisdictions. c. Example of the validation procedure. 1) APNIC initiates the validation automatically, sending TWO consecutive emails to each of the mailboxes. 2) These emails will be sent containing plain text only. 3) The first email will contain the URL where the validation is to be performed ("validation.apnic.net") and may contain information about the procedure, a brief summary of this policy, etc. 4) The second email will contain a unique alphanumeric validation code. 5) The person in charge of the each of the mailboxes must go to the URL and paste the code received in the second email in the form. 6) This URL must be designed in such a way that it prevents the use of an automated process (for example, "captcha"). In addition, it must contain a text that confirms that the person performing the validation understands the procedure and the policy, that they regularly monitor the mailboxes, that measures are taken to solve reported cases of abuse, and that the abuse report receives a response, with a "checkbox" that must be accepted in order to proceed. 7) The alphanumeric code will only be valid for a maximum of fifteen days. 8) If the code is not entered within that time, the system will mark the IRT as "temporarily invalid” and will send a reminder with another unique code and alert APNIC staff, so they can initiate a personalized follow-up with the LIR. 9) If no reply is received confirming that the situation has been corrected, after an additional period of three business days, the IRT will be permanently marked as "invalid". 10) Once the issue has been resolved, the validation process will be repeated automatically (items 1 to 7 above). If satisfactory, the IRT will be marked as "valid"; otherwise it will be considered in breach of the policy.

3 2

A new version of the proposal "prop-118: No need policy in APNIC region"
by Sumon Ahmed Sabir 11 Sep '18

11 Sep '18

Dear SIG members A new version of the proposal "prop-118: No need policy in APNIC region" has been sent to the Policy SIG for review. Information about earlier versions is available from: https://www.apnic.net/community/policy/proposals/prop-118/ You are encouraged to express your views on the proposal: - Do you support or oppose the proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Please find the text of the proposal below. Kind Regards, Sumon, Bertrand, Ching-Heng APNIC Policy SIG Chairs ---------------------------------------------------------------------- prop-118-v002: No need policy in APNIC region ---------------------------------------------------------------------- Proposer: Heng Lu h.lu(a)laruscloudservice.net 1. Problem Statement -------------------- Whenever a transfer of IPv4 is taking place within the APNIC region, the recipient needs to demonstrate the "need" for the IPv4 space they intend to transfer. Companies transferring IPv4 space to their pool do this in ordcer to enable further growth in their network, since the space is not coming from the free public pool, regular policies that are intended to protect the limited pool of IPv4 space can be removed in transfers. 2. Objective of policy change ----------------------------- Simplify transfer of IPv4 space between resource holders. Ease some administration on APNIC staff, increase database accuracy. 3. Situation in other regions ----------------------------- RIPE region has an all around no need policy in IPv4, even for first allocation, transfers do not require the recipient to demonstrate their intended use of the resources. ARIN, need base for both transfers and resources issued by ARIN. AFRINIC, need based policy on transfers (not active yet) and resource request from AFRINIC based on needs. LACNIC, no transfers, need based request. Out of all these RIR, only ARIN and RIPE NCC have inter-RIR transfer policies, ARIN has made clear in the past that the "no need" policy from the RIPE region would break inter-RIR transfers from ARIN to RIPE region. 4. Proposed policy solution --------------------------- Simply copy the RIPE policy to solve the ARIN transfer incompatibility: - APNIC shall accept all transfers of Internet number resources to its service region, provided that they comply with the policies relating to transfers within its service region. - For transfers from RIR regions that require the receiving region to have needs-based policies, recipients must provide a plan to the APNIC for the use of at least 50% of the transferred resources within 5 years. - When transferring Internet number resources to another RIR, the APNIC will follow the transfer policies that apply within its own service region. The APNIC will also comply with the commitments imposed by the receiving RIR in order to facilitate the transfer. 5. Advantages / Disadvantages ----------------------------- Advantages: - Harmonisation with RIPE region. - Makes transfer simpler and smoother within APNIC and between APNIC and RIPE. - Maintains a compatibility with ARIN. - Removes the uncertainty that a transfer may be rejected based on potentially badly documented needs. - Lowers the overall administrative burden on APNIC staff. Disadvantages: None. 6. Impact on resource holders ----------------------------- None. 7. References -------------

3 2

IANA RC Nominations now open
by Srinivas (Sunny) Chendi 03 Sep '18

03 Sep '18

Dear Community Members, The APNIC Secretariat is now seeking volunteers to serve as a member of the IANA Numbering Services Review Committee (IANA RC). The IANA Numbering Services Review Committee’s function is to advise and assist the Number Resource Organization (NRO EC) in its periodic review of the service level of the IANA Numbering Services provided to the Internet Number Community. The elected member will server a two-year term, starting 1 January 2019. The deadline for nominations is: -------------------------------- 23:59 (UTC +10) Friday, 07 September 2018 Details about the role of the IANA RC are set out at the NRO website, accessible here: https://www.nro.net/iana-numbering-services-review-committee/ Nominations will be accepted only by using the following form: https://www.apnic.net/community/policy/policy-sig/iana-numbering-services-r… The election will be the first agenda item of the APNIC Policy SIG on Thursday, 13 September 2018. Kind regards, _______________________________________________________________________ APNIC Secretariat secretariat(a)apnic.net Asia Pacific Network Information Centre (APNIC) Tel: 61 7 3858 3100 PO Box 3646 South Brisbane, QLD 4101 Australia Fax: 61 7 3858 3199 6 Cordelia Street, South Brisbane, QLD http://www.apnic.net _______________________________________________________________________

1 1

Monthly List Reminder
by noreply＠apnic.net 31 Aug '18

31 Aug '18

Dear Subscriber, This is the monthly reminder of subscription information for the sig-policy list, hosted at APNIC. For subscription information including how to un-subscribe go to http://mailman.apnic.net/mailman/listinfo/sig-policy Thank you for participating in this discussion. Kind Regards, List administrator

1 0

prop-125-v001: Validation of "abuse-mailbox" and other IRT emails
by Bertrand Cherrier 17 Aug '18

17 Aug '18

Dear SIG members, The proposal "prop-125-v001: Validation of "abuse-mailbox" and other IRT emails" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting at APNIC 46 in Noumea, New Caledonia on Thursday, 13 September 2018. We invite you to review and comment on the proposal on the mailing list before the meeting. The comment period on the mailing list before an APNIC meeting is an important part of the policy development process. 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 available at: http://www.apnic.net/policy/proposals/prop-125 Regards Sumon, Bertrand, Ching-Heng APNIC Policy SIG Chairs https://www.apnic.net/wp-content/uploads/2018/08/prop-125-v001.txt ---------------------------------------------------------------------- prop-125-v001: Validation of "abuse-mailbox" and other IRT emails ---------------------------------------------------------------------- Proposer: Jordi Palet Martínez - jordi.palet(a)theipv6company.com Aftab Siddiqui - aftab.siddiqui(a)gmail.com 1. Problem Statement -------------------- APNIC implemented mandatory IRT references on 8 November 2010. This means it is mandatory to register an Incident Response Team (IRT) object for each resource record in the APNIC Whois Database. The policy mandates IRT references for each inetnum, inet6num and aut-num objects, however in many cases, those contain out-of-date, inaccurate, non-existent or not actively monitored abuse-mailbox information. In practice, this contact becomes ineffective to report abuses and generally gives rise to security issues and costs for the victims. This proposal aims to solve the problem and ensure the existence of a proper abuse-mailbox contact and the process for its utilization. 2. Objective of policy change ----------------------------- The Internet community is based on collaboration. In many cases, however, this is not enough and we all need to be able to contact those LIRs which may be experiencing a problem in their networks and may not be aware of the situation. This proposal aims to solve this problem by means of a simple, periodic verification of IRT object emails, and establishes the basic rules for performing such verification and thus avoids unnecessary costs to third parties who need to contact the persons responsible for solving the abuses of a specific network. The proposal guarantees that the cost of processing the abuse falls on the LIR whose client is causing the abuse (and from whom they receive financial compensation for the service), instead of falling on the victim, as would be the case if they had to resort to the courts, thus avoiding costs (lawyers, solicitors, etc.) and saving time for both parties. 3. Situation in other regions ----------------------------- A similar proposal is being discussed in LACNIC and being prepared for AfriNIC and RIPE NCC. Currently, ARIN conducts an annual POC (point of contact) validation and RIPE NCC validates the “abuse-mailbox:” attribute annually (ripe-705). 4. Proposed policy solution --------------------------- 1. About the "abuse-mailbox", “email”, “admin-c” and “tech-c” Emails sent to "abuse-mailbox", “email”, “admin-c” and “tech-c” must require manual intervention by the recipient at some time, and may not be filtered, as in certain cases this might prevent the reception of the abuse reports, for example a case of spam, as it would include the spam message itself or URLs or content usually classified as spam. The mailboxes may initially send an automatic reply, for example, assigning a ticket number, applying classification procedures, requesting further information, etc. However, it may not require the use of a form, as this would imply that each company that needs to report cases of abuse (a task that is typically automated) would be forced to develop a specific interface for each case, which is neither feasible nor logical, as it would place the cost of processing the abuse on those who submit the claim and are therefore victims of the abuse, instead of being paid by the those whose client causes the abuse (and from whom they obtain income). By way of information, it is worth noting that it is reasonable for the person reporting the abuse to do so from the start and in that first report, sending the logs, or a copy of the spam message (attaching an example of the spam email or its full headers) or similar evidence proving the abuse. Likewise, it is reasonable to expect that the initial auto-reply email will specify that the claim will not be processed unless such evidence has been submitted, thus allowing the sender the opportunity to repeat the submission and include the pertinent evidence. This allows automatic reporting, for example, via fail2ban, SpamCop or others, keeping costs at a minimum for both parties involved. 2. Objectives of "abuse-mailbox", “email”, “admin-c” and “tech-c” validation The procedure, which is to be developed by APNIC, must meet the following objectives: 1) A simple process that guarantees its functionality and allows the helpdesks that deal with abuse reports to verify that validation requests actually come from APNIC and not from third parties (which might involve security risks), avoiding, for example, a single "direct" URL for validation. 2) Avoid automated processing. 3) Confirm that the person performing the validation ensure that understands the procedure and the policy, that they regularly monitor the "abuse-mailbox", “email”, “admin-c” and “tech-c”, that measures are taken, and that the abuse report receives a response. 4) Validation period no longer than fifteen (15) days. 5) If validation fails, escalate to the LIR and set a new validation period not to exceed the fifteen (15) days. (By way of example, a detailed procedure is included in this policy proposal under "Additional Information") 3. Validation of "abuse-mailbox", “email”, “admin-c” and “tech-c” APNIC will validate compliance with the items above, both when the "abuse-mailbox", “email”, “admin-c” and/or “tech-c” attributes are created or updated, as well as periodically, not less than once every six months, and whenever APNIC sees fit. At the discretion of APNIC, in general or in specific cases (for example, for confirmation in cases of escalation under 4., APNIC may use domains other than apnic.*, and even modify the subject and body of the message, in order to perform said validations more effectively. Lack of compliance will imply a more exhaustive follow-up, in accordance with the relevant APNIC policies, procedures and membership agreement and a temporary lock of myapnic access, until resolved. 4. Escalation to APNIC To avoid fraudulent behavior (for example, an "abuse-mailbox" that only replies to APNIC’s emails, or to messages with a specific subject or content), or failure to comply with the remaining aspects of this policy (incorrect or lack of response to cases of abuse) and, therefore, to guarantee the quality of the services in the region with the resources allocated by APNIC, a mailbox will be available (for example, "escalation-abuse(a)apnic.net"), to escalate such situations, thus allowing for a re-validation (according to section 3. above) and even the intermediation by APNIC and, where appropriate, the application of the relevant policies/procedures, APNIC policies, procedures and membership agreement. i) In case there is no response from all the email addresses associated with the IRT object, then mark that IRT object invalid and block access to myapnic and use other means to contact the member (e.g. via billing contact or corporate contact) ii) if there is no response from some of the email address associated with the IRT object, then mark those attributes invalid and contact the member for the resolution. If the problem is not fixed after fifteen (15) days then block access to myapnic and use other means to contact the member (e.g. via billing contact or corporate contact). 5. Advantages / Disadvantages ----------------------------- Advantages: The purpose of creating IRT object in the APNIC whois database is to provide a more accurate and efficient way for abuse reports to reach the correct network contact. Fulfilling the objectives above indicated and ensuring that a real contact can be approached in case of abuse cases and effectively serve the purpose of creating IRT object. This will improve the quality of the information and help to achieve the goal of handling network abuses. Disadvantages: None foreseen. 6. Impact on resource holders ----------------------------- APNIC members have to verify and update (if required) their IRT objects periodically. 7. References ------------- ADDITIONAL INFORMATION a. Since this proposal is implemented, APNIC will publish the IRT also as abuse-c, in order to facilitate the search in whois, for the same information, regardless if looking for abuse-c or IRT. This is done in order to assimilate the IRT to the majority of the RIRs where it is abuse-c. b. It is recommend that all NIRs implement a similar validation process within their own jurisdictions. c. Example of the validation procedure. 1) APNIC initiates the validation automatically, sending TWO consecutive emails to each of the mailboxes. 2) These emails will be sent containing plain text only. 3) The first email will contain the URL where the validation is to be performed ("validation.apnic.net") and may contain information about the procedure, a brief summary of this policy, etc. 4) The second email will contain a unique alphanumeric validation code. 5) The person in charge of the each of the mailboxes must go to the URL and paste the code received in the second email in the form. 6) This URL must be designed in such a way that it prevents the use of an automated process (for example, "captcha"). In addition, it must contain a text that confirms that the person performing the validation understands the procedure and the policy, that they regularly monitor the mailboxes, that measures are taken to solve reported cases of abuse, and that the abuse report receives a response, with a "checkbox" that must be accepted in order to proceed. 7) The alphanumeric code will only be valid for a maximum of fifteen days. 8) If the code is not entered within that time, the system will mark the IRT as "temporarily invalid” and will send a reminder with another unique code and alert APNIC staff, so they can initiate a personalized follow-up with the LIR. 9) If no reply is received confirming that the situation has been corrected, after an additional period of three business days, the IRT will be permanently marked as "invalid". 10) Once the issue has been resolved, the validation process will be repeated automatically (items 1 to 7 above). If satisfactory, the IRT will be marked as "valid"; otherwise it will be considered in breach of the policy. Cordialement, ___________________________________________ Bertrand Cherrier Administration Systèmes - R&D Micro Logic Systems b.cherrier(a)micrologic.nc https://www.mls.nc Tél : +687 24 99 24 VoIP : 65 24 99 24 SAV : +687 36 67 76 (58F/min)

1 0

Policy proposals on Whois Point of Contact
by Sumon Ahmed Sabir 10 Aug '18

10 Aug '18

Dear Community members, We have received two Policy proposals on Whois Point of Contact validation. We chairs thought that both proposals can be merged nicely and both the author agreed to it. So we have decided to allow them some time to merge both proposals to one proposal. Soon they come up with the merge proposal we will publish it to mailing list for discussion. Thanks, Sumon, Bertrand and Ching-Heng

1 0

Prop-119 withdraw
by Lu Heng 09 Aug '18

09 Aug '18

hi i like to withdraw prop-119, due to lack of need for such proposal anymore. -- -- Kind regards. Lu

3 2

Autoreply: sig-policy Digest, Vol 171, Issue 5
by eddie＠sum.net 09 Aug '18

09 Aug '18

I will be out of the office until Monday, August 27th. I will be checking email and will try to get back to you as soon as possible. Thanks! Eddie

1 0

A new version of the proposal "prop-124: Clarification on IPv6 Sub-Assignments"
by Sumon Ahmed Sabir 07 Aug '18

07 Aug '18

Dear SIG members A new version of the proposal "prop-124: Clarification on IPv6 Sub-Assignments" has been sent to the Policy SIG for review. Information about earlier versions is available from: https://www.apnic.net/community/policy/proposals/prop-124 You are encouraged to express your views on the proposal: - Do you support or oppose the proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Please find the text of the proposal below. Kind Regards, Sumon, Bertrand, Ching-Heng APNIC Policy SIG Chairs ---------------------------------------------------------------------- prop-124-v003: Clarification on IPv6 Sub-Assignments ---------------------------------------------------------------------- Proposer: Jordi Palet Martínez jordi.palet(a)theipv6company.com 1. Problem Statement -------------------- When the policy was drafted, the concept of assignments/sub-assignments did not consider a practice very common in IPv4 which is replicated and even amplified in IPv6: the use of IP addresses for point-to-point links or VPNs. In the case of IPv6, instead of unique addresses, the use of unique prefixes (/64) is increasingly common. Likewise, the policy failed to consider the use of IP addresses in hotspots, or the use of IP addresses by guests or employees in Bring Your Own Device (BYOD) and many other similar cases. Finally, the IETF has recently approved the use of a unique /64 prefix per interface/host (RFC8273) instead of a unique address. This, for example, allows users to connect to a hotspot, receive a /64 such that they are “isolated” from other users (for reasons of security, regulatory requirements, etc.) and they can also use multiple virtual machines on their devices with a unique address for each one (within the same /64). 2. Objective of policy change ----------------------------- Section 2.2.3. (Definitions/Assigned Address Space), explicitly prohibits such assignments, stating that “Assigned ... may not be sub-assigned”. https://www.apnic.net/community/policy/resources#2.2.3.-Assigned-address-sp… This proposal clarifies this situation in this regard and better define the concept, particularly considering new uses of IPv6 (RFC 8273), by means of a new paragraph. 3. Situation in other regions ----------------------------- This situation, has already been corrected in RIPE, and the policy was updated in a similar way, even if right now there is a small discrepancy between the policy text that reached consensus and the RIPE NCC Impact Analysis. A new policy proposal has been submitted to amend that, and the text is the same as presented by this proposal at APNIC. Same text has also been submitted to AfriNIC, LACNIC and ARIN. 4. Proposed policy solution --------------------------- Add a new paragraph after the existing one in 2.2.3 https://www.apnic.net/community/policy/resources#2.2.3.-Assigned-address-sp… Actual text: 2.2.3. Assigned address space Assigned address space is address space that is delegated to an LIR, or end-user, for specific use within the Internet infrastructure they operate. Assignments must only be made for specific, documented purposes and may not be sub-assigned. New text: 2.2.3. Assigned address space Assigned address space is address space that is delegated to an LIR, or end-user, for specific use within the Internet infrastructure they operate. Assignments must only be made for specific, documented purposes and may not be sub-assigned. The fact that a unique address or even a unique /64 prefix is non-permanently provided to third parties, on a link operated by the original receiver of the assignment, shall not be considered a sub-assignment. This includes, for example, guests or employees (devices or servers), hotspots, and point-to-point links or VPNs. The provision of addressing for permanent connectivity or broadband services is still considered a sub-assignment. Only the addressing of the point-to-point link itself can be permanent. 5. Advantages / Disadvantages ----------------------------- Advantages: Fulfilling the objective above indicated and making sure to match the real situation in the market. Disadvantages: None foreseen. 6. Impact on resource holders ----------------------------- None 7. References -------------

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

sig-policy August 2018