Re: [sig-policy] Prop124 version 4

[JORDI PALET MARTINEZ]

Hi Owen, all,

 

In previous versions I tried to make a shorter text and didn’t worked.

 

Let me try to explain each part:

 
“Providing addressing space to third party devices including addresses for 
point-to-point links”

 

This covers the case of a subcontractor with devices siting on the holders 
network may be for several years, and in this case they are “permanently” 
connected (during the duration of the contract), explained in my problem 
statement as:

 

One more case is when an end-user contracts a third-party to do some services 
in their own network and they need to deploy their own devices, even servers, 
network equipment, etc. For example, security surveillance services may require 
that the contractor provides their own cameras, recording system, even their 
own firewall and/or router for a dedicated VPN, etc. Of course, in many cases, 
this surveillance system may need to use the addressing space of the end-user.

 

Of course, the 2nd part of the sentence is for the point-to-point links, I 
think that’s very obvious.

 
“and/or non-permanently providing addressing space to third Parties”
 

This covers the other cases, BYOD (employee or guest of a corporation, student 
of a university, visitor in a hot-spot, etc.), which are more commonly for some 
hours or minutes, even days.

 
“The provision of addressing space for permanent or semi-permanent 
connectivity, 
such as broadband services, is still considered a sub-assignment.”

 

We want to make sure that ISPs, typically offering broadband services, aren’t 
end-users, as they should be LIRs.


Regards,

Jordi

 

 

 

De: Owen DeLong 
Fecha: martes, 11 de septiembre de 2018, 15:29
Para: JORDI PALET MARTINEZ 
CC: Satoru Tsurumaki , SIG policy 

Asunto: Re: [sig-policy] Prop124 version 4

 

Aside from the question of examples or not examples, I offer the following 
suggestion… The wording is quite awkward and difficult to parse. So much so, I 
am not 100% certain of the intent.

 

I offer the following suggestion for a rewrite hoping that I have captured the 
intent accurately:

 

===

 

Providing IP number resources to third party devices, including addresses for 
point-to-point links or addresses provided on an impermanent basis, for use on 
a network managed and operated by the assignment holder shall not be considered 
a sub-assignment.

 

Providing IP number resources for permanent or semi-permanent connectivity, 
such as broadband services is still considered a sub-assignment.

 

===

 

Owen

 



On Sep 10, 2018, at 20:55 , JORDI PALET MARTINEZ  
wrote:

 

Hi Satoru,

 

Thanks for commenting on this.

 

The current proposal text has not examples, I think it is quite neutral in this 
aspect:

 

Providing addressing space to third party devices including addresses for 

point-to-point links and/or non-permanently providing addressing space to third 

parties, for use on a network managed and operated by the assignment holder, 

shall not be considered a sub-assignment.

 

The provision of addressing space for permanent or semi-permanent connectivity, 

such as broadband services, is still considered a sub-assignment.

 

I think having the examples in the “objective” of the policy proposal is needed 
to clarify the reason for it. You don’t think so?


Regards,

Jordi

 

 

 

De:  en nombre de Satoru Tsurumaki 

Fecha: martes, 11 de septiembre de 2018, 14:02
Para: SIG policy 
Asunto: Re: [sig-policy] Prop124 version 4

 

Dear Colleagues,

 

I am Satoru Tsurumaki from Japan Open Policy Forum.

 

I would like to share key feedback in our community for prop-124,

based on a meeting we organised on 22nd Aug to discuss these proposals.

 

Many supporting opinions were expressed on this proposal.

However, also many concerning comment was expressed to explain the specific 
examples.

For this matter, the same opinion was given also at JPOPM34.

 

  - It is better to stop specific examples because they tend to fall into 
discussion of adding / not applying / not applicable.

  - I think that specific examples should be stated in the guidelines rather 
than policies.


Regards,

Satoru Tsurumaki

 

 

2018-09-09 18:37 GMT+11:00 Bertrand Cherrier :

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-v004: Clarification on IPv6 Sub-Assignments

Proposer: Jordi Palet Martínez
jordi.pa...@theipv6company.com
1. Problem Statement
When the policy was drafted, the conc

Re: [sig-policy] Prop124 version 4

[Owen DeLong]

Aside from the question of examples or not examples, I offer the following 
suggestion… The wording is quite awkward and difficult to parse. So much so, I 
am not 100% certain of the intent.

I offer the following suggestion for a rewrite hoping that I have captured the 
intent accurately:

===

Providing IP number resources to third party devices, including addresses for 
point-to-point links or addresses provided on an impermanent basis, for use on 
a network managed and operated by the assignment holder shall not be considered 
a sub-assignment.

Providing IP number resources for permanent or semi-permanent connectivity, 
such as broadband services is still considered a sub-assignment.

===

Owen


> On Sep 10, 2018, at 20:55 , JORDI PALET MARTINEZ  
> wrote:
> 
> Hi Satoru,
>  
> Thanks for commenting on this.
>  
> The current proposal text has not examples, I think it is quite neutral in 
> this aspect:
>  
> Providing addressing space to third party devices including addresses for 
> point-to-point links and/or non-permanently providing addressing space to 
> third 
> parties, for use on a network managed and operated by the assignment holder, 
> shall not be considered a sub-assignment.
>  
> The provision of addressing space for permanent or semi-permanent 
> connectivity, 
> such as broadband services, is still considered a sub-assignment.
>  
> I think having the examples in the “objective” of the policy proposal is 
> needed to clarify the reason for it. You don’t think so?
> 
> Regards,
> Jordi
> 
>  
> 
>  
>  
> De:  en nombre de Satoru Tsurumaki 
> 
> Fecha: martes, 11 de septiembre de 2018, 14:02
> Para: SIG policy 
> Asunto: Re: [sig-policy] Prop124 version 4
>  
> Dear Colleagues,
>  
> I am Satoru Tsurumaki from Japan Open Policy Forum.
>  
> I would like to share key feedback in our community for prop-124,
> based on a meeting we organised on 22nd Aug to discuss these proposals.
>  
> Many supporting opinions were expressed on this proposal.
> However, also many concerning comment was expressed to explain the specific 
> examples.
> For this matter, the same opinion was given also at JPOPM34.
>  
>   - It is better to stop specific examples because they tend to fall into 
> discussion of adding / not applying / not applicable.
>   - I think that specific examples should be stated in the guidelines rather 
> than policies.
> 
> Regards,
> Satoru Tsurumaki
>  
>  
> 2018-09-09 18:37 GMT+11:00 Bertrand Cherrier  >:
>> 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-v004: Clarification on IPv6 Sub-Assignments
>> 
>> Proposer: Jordi Palet Martínez
>> jordi.pa...@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.
>> 
>> One more case is when an end-user contracts a third-party to do some services
>> in their own network and they need to deploy their own devices, even servers,
>> network equipment, etc. For example, security surveillance services may 
>> require
>> that the contractor provides their own cameras, recording system, even their
>> own firewall and/or router for a dedicated VPN, etc. Of course, in many 
>> cases,
>> this surveillance system may need to use the addressing space of the 
>> end-user.
>> 
>> 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
>> 
>> Secti

Re: [sig-policy] prop-126-v001 : PDP Update

[JORDI PALET MARTINEZ]

Hi again Satoru, all,

 

Answers below, in-line, and thank again for your contribution.


Regards,

Jordi

 

 

 

De:  en nombre de Satoru Tsurumaki 

Fecha: martes, 11 de septiembre de 2018, 14:04
Para: SIG policy 
Asunto: Re: [sig-policy] prop-126-v001 : PDP Update

 

Dear Colleagues,

 

I am Satoru Tsurumaki from Japan Open Policy Forum.

 

I would like to share key feedback in our community for prop-126,

based on a meeting we organised on 22nd Aug to discuss these proposals.

 

Many supporting opinions were expressed about the point of confirming consensus 
on ML.

 

A question of doubt and concern was expressed, in that it discontinues AMM 
consensus and changes the proposal's deadline.

 

(Consensus on ML)

 - I support to take a consensus confirmation with ML instead of AMM.

 - I support on the point of view that this proposal will expand  the 
opportunities to the remote participant to discussing about proposal.

 - For consensus confirmation in ML, only proposal which reached consensus in 
OPM are eligible and the proposal which not reached consensus are not eligible. 
it is not good to lose the opportunity to state a opinion at the ML about the 
proposal which not reach consensus.

 

Let me clarify this. I’m not suggesting a ML confirmation of the consensus. 
What I suggest is that it is discriminatory to look for consensus ONLY in the 
SIG, because there is many people not able to come to meetings and they are 
part of the community. So, what I’m suggesting is that the consensus should be 
measured in both, the SIG and the ML.

 

(Consensus at AMM)

 - The meaning of taking consensus in AMM is for members to clarify the pros 
and cons about APNIC’s implementation. This is not a simple substitution from 
AMM to ML.

 - In addition to the past, how about added a confirmation of consensus in ML ?

 

Clarification in the AMM is good to have, but not “mandating” the consensus on 
the AMM. If we accept that the consensus can be reached in the SIG and the ML, 
then the AMM members that disagree with the proposal, are able to express their 
concerns in the ML.

 

(Change of deadline of proposal)

 - For the purpose of this proposal, it is better to have a longer online 
discussion period. Why shorten the deadline by proposal? The proposer should 
clarify the intention of wanting to move the deadline.

 

I don’t think it makes sense to have a requirement of a proposal to be send to 
the ML 4 weeks before the meeting, if we are opting for looking for consensus 
also in the list. Only a very small percentage of the community is present in 
the meetings, so the “weight” of the ML over those present in the meeting must 
be higher. I will be ok to ask for a “longer” period for discussion/comments in 
the ML if that’s what the community believe, but keeping just one week for 
submission deadline.

 

(Other)

 - It is better to be able to measure the effect after change

 

Not sure to understand this point.


Regards,

Satoru Tsurumaki

 

 

2018-08-10 12:42 GMT+11:00 Bertrand Cherrier :

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.pa...@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 do

Re: [sig-policy] prop-125-v001: Validation of "abuse-mailbox" and other IRT emails

[JORDI PALET MARTINEZ]

Hi Satoru, all,

 

Thanks again for your contribution.

 

There are many ways to protect a whois “email” from spam. For example, you can 
request a manual intervention to actually “see” the email.

 

I think this is an operational issue outside of the scope of the PDP, and 
should be sorted out by the staff.

 

Also, this concern is the same for any email published in the whois, not just 
our policy proposal, right?


Regards,

Jordi

 

 

 

De:  en nombre de Satoru Tsurumaki 

Fecha: martes, 11 de septiembre de 2018, 14:04
Para: SIG policy 
Asunto: Re: [sig-policy] prop-125-v001: Validation of "abuse-mailbox" and other 
IRT emails

 

Dear Colleagues,

 

I am Satoru Tsurumaki from Japan Open Policy Forum.

 

I would like to share key feedback in our community for prop-125,

based on a meeting we organised on 22nd Aug to discuss these proposals.

 

Many supporting opinions were expressed on this proposal.

 

  - Agree, you should.

  - When mail address is posted in whois DB, a lot of SPAM is sent. We should 
take some measures.


Regards,

Satoru Tusrumaki

 

 

2018-08-17 14:52 GMT+11:00 Sumon Ahmed Sabir :

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.pa...@theipv6company.com
  Aftab Siddiqui - aftab.siddi...@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 o

Re: [sig-policy] Prop124 version 4

[JORDI PALET MARTINEZ]

Hi Satoru,

 

Thanks for commenting on this.

 

The current proposal text has not examples, I think it is quite neutral in this 
aspect:

 

Providing addressing space to third party devices including addresses for 

point-to-point links and/or non-permanently providing addressing space to third 

parties, for use on a network managed and operated by the assignment holder, 

shall not be considered a sub-assignment.

 

The provision of addressing space for permanent or semi-permanent connectivity, 

such as broadband services, is still considered a sub-assignment.

 

I think having the examples in the “objective” of the policy proposal is needed 
to clarify the reason for it. You don’t think so?


Regards,

Jordi

 

 

 

De:  en nombre de Satoru Tsurumaki 

Fecha: martes, 11 de septiembre de 2018, 14:02
Para: SIG policy 
Asunto: Re: [sig-policy] Prop124 version 4

 

Dear Colleagues,

 

I am Satoru Tsurumaki from Japan Open Policy Forum.

 

I would like to share key feedback in our community for prop-124,

based on a meeting we organised on 22nd Aug to discuss these proposals.

 

Many supporting opinions were expressed on this proposal.

However, also many concerning comment was expressed to explain the specific 
examples.

For this matter, the same opinion was given also at JPOPM34.

 

  - It is better to stop specific examples because they tend to fall into 
discussion of adding / not applying / not applicable.

  - I think that specific examples should be stated in the guidelines rather 
than policies.


Regards,

Satoru Tsurumaki

 

 

2018-09-09 18:37 GMT+11:00 Bertrand Cherrier :

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-v004: Clarification on IPv6 Sub-Assignments

Proposer: Jordi Palet Martínez
jordi.pa...@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.

One more case is when an end-user contracts a third-party to do some services
in their own network and they need to deploy their own devices, even servers,
network equipment, etc. For example, security surveillance services may require
that the contractor provides their own cameras, recording system, even their
own firewall and/or router for a dedicated VPN, etc. Of course, in many cases,
this surveillance system may need to use the addressing space of the end-user.

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-space

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-space

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 operat

Re: [sig-policy] prop-126-v001 : PDP Update

[Satoru Tsurumaki]

*Dear Colleagues,I am Satoru Tsurumaki from Japan Open Policy Forum.I would
like to share key feedback in our community for prop-126,based on a meeting
we organised on 22nd Aug to discuss these proposals.*






*Many supporting opinions were expressed about the point of confirming
consensus on ML.A question of doubt and concern was expressed, in that it
discontinues AMM consensus and changes the proposal's deadline.(Consensus
on ML)  - I support to take a consensus confirmation with ML instead of
AMM.  - I support on the point of view that this proposal will expand  the
opportunities to the remote participant to discussing about proposal.  -
For consensus confirmation in ML, only proposal which reached consensus in
OPM are eligible and the proposal which not reached consensus are not
eligible. it is not good to lose the opportunity to state a opinion at the
ML about the proposal which not reach consensus.(Consensus at AMM)  - The
meaning of taking consensus in AMM is for members to clarify the pros and
cons about APNIC’s implementation. This is not a simple substitution from
AMM to ML.  - In addition to the past, how about added a confirmation of
consensus in ML ?(Change of deadline of proposal)  - For the purpose of
this proposal, it is better to have a longer online discussion period. Why
shorten the deadline by proposal? The proposer should clarify the intention
of wanting to move the deadline.(Other)  - It is better to be able to
measure the effect after change*
Regards,
Satoru Tsurumaki



2018-08-10 12:42 GMT+11:00 Bertrand Cherrier :

> 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.pa...@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/docume
> nts/policy-development/development-proce

Re: [sig-policy] prop-125-v001: Validation of "abuse-mailbox" and other IRT emails

[Satoru Tsurumaki]

*Dear Colleagues,I am Satoru Tsurumaki from Japan Open Policy Forum.I would
like to share key feedback in our community for prop-125,based on a meeting
we organised on 22nd Aug to discuss these proposals.Many supporting
opinions were expressed on this proposal.   - Agree, you should.   - When
mail address is posted in whois DB, a lot of SPAM is sent. We should take
some measures.*
Regards,
Satoru Tusrumaki


2018-08-17 14:52 GMT+11:00 Sumon Ahmed Sabir :

> 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.pa...@theipv6company.com
>   Aftab Siddiqui - aftab.siddi...@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 abus

Re: [sig-policy] Prop124 version 4

[Satoru Tsurumaki]

*Dear Colleagues,I am Satoru Tsurumaki from Japan Open Policy Forum.I would
like to share key feedback in our community for prop-124,based on a meeting
we organised on 22nd Aug to discuss these proposals.Many supporting
opinions were expressed on this proposal.However, also many concerning
comment was expressed to explain the specific examples.For this matter, the
same opinion was given also at JPOPM34.   - It is better to stop specific
examples because they tend to fall into discussion of adding / not applying
/ not applicable.   - I think that specific examples should be stated in
the guidelines rather than policies.*
Regards,
Satoru Tsurumaki


2018-09-09 18:37 GMT+11:00 Bertrand Cherrier :

> 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-v004: Clarification on IPv6 Sub-Assignments
> --
>
> Proposer: Jordi Palet Martínez
> jordi.pa...@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.
>
> One more case is when an end-user contracts a third-party to do some
> services
> in their own network and they need to deploy their own devices, even
> servers,
> network equipment, etc. For example, security surveillance services may
> require
> that the contractor provides their own cameras, recording system, even
> their
> own firewall and/or router for a dedicated VPN, etc. Of course, in many
> cases,
> this surveillance system may need to use the addressing space of the
> end-user.
>
> 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-space
>
> 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-space
>
> 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.
>
> Providing addressing space to third party devices including addresses for
> point-to-point links and/or non-permanently providing addressing space to
> third
> parties, for use on a network managed and operated by the assignment
> holder,
> shall not be considered a sub-a

Re: [sig-policy] A new version of the proposal "prop-118: No need policy in APNIC region"

[Satoru Tsurumaki]

*Dear Colleagues,I am Satoru Tsurumaki from Japan Open Policy Forum.I would
like to share key feedback in our community for prop-118,based on a meeting
we organised on 22nd Aug to discuss these proposals.Many supporting
opinions were expressed on this proposal.However, many comments were
expressed that proposer should feedback for the discussion which we
discussed in past OPM. Below are details of opinions expressed.  - Demand
for 5 years: It is difficult to clarify a demand of address needs for both
APNIC and LIR.  - The policy should be looser. it will increase a
possibilities of address transfer if time frame are expand from 2 years to
5 years.  - The reason why APNIC clarify the request of transfer is for
tranferring from ARIN. So inter-APNIC case, it not need originally and
there is no reason to make a a clarification strictly.I agree with the
purpose of the proposal.  - Nevertheless, proposer should respond to the
past comments.  - I'd like to request to proposer to explain the intention
of copying the implementation contents of RIPE NCC as it is.  - The content
of the previous discussion has not been reflected and it is not refined.
Although the position of the proposal is not in an opposite position, the
proponent should explain more. Please answer the discussion at APNIC 44.*

Regards,

Satoru Tsurumaki


2018-08-08 4:44 GMT+11:00 Sumon Ahmed Sabir :

> 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...@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: