Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments

[Owen DeLong]

I think the current text isn’t really a problem because reasonable people apply 
a reasonable interpretation of intent rather than the literal meaning. 

The proposal brings literal meaning more in line with well understood intent. 

While I don’t believe there is an actual problem to solve here, I do think the 
proposal provides greater clarity in the language and therefore support it. 

Owen


> On Aug 23, 2019, at 01:11, Simon Sohel Baroi / Global Business / 01847102243 
> /  wrote:
> 
> Dear Sir,
> 
> Also, Requesting to the Author to represent the Proposal with Example and 
> Graphical Representation.
> The example should have comparison with Present situation and the Propose 
> Solution of the problem.
> 
> 
> - with regards
> 
> SIMON.
> 
>> On Sat, Aug 10, 2019 at 8:33 PM Sumon Ahmed Sabir  wrote:
>> Dear SIG members
>> 
>> A new version of the proposal "prop-124: Clarification on Sub-Assignments"
>> has been sent to the Policy SIG for review.
>> 
>> It will be presented at the Open Policy Meeting at APNIC 48 in
>> Chiang Mai, Thailand on Thursday, 12 September 2019.
>> 
>> 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-v006: Clarification on Sub-Assignments
>> 
>> --
>> 
>> Proposer: Jordi Palet Martínez
>>jordi.pa...@theipv6company.com
>> 
>> 
>> 1. Problem Statement
>> 
>> 
>> Note that this proposal is ONLY relevant when end-users obtain direct 
>> assignments
>> from APNIC, or when a LIR obtains, also from APNIC, and assignment for 
>> exclusive
>> use within its infrastructure. Consequently this is NOT relevant in case 
>> of LIR
>> allocations.
>> 
>> 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 IPv4, typically, this is not a problem if NAT is being used, because 
>> the assigned
>> addresses are only for the WAN link, which is part of the infrastructure 
>> or interconnection.
>> 
>> 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 hotspots
>> (when is not an ISP, for example, associations or community networks), 
>> 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”.
>> 
>> It also clarifies that the usage of sub-assignments in ISPs, data 
>> centers and similar cases
>> is not allowed, according to the existing practices of APNIC.
>> 
>> 
>> 3. Situation in other regions
>> -
>> 
>> This situation, has already been corrected in AFRINIC, ARIN, LACNIC and 
>> RIPE.
>> 
>> 
>> 4. Proposed policy solution
>> ---
>> 
>> Current 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 

Re: [sig-policy] prop-132-v002: AS0 for Bogons

[Javed Khan]

For now, I'm neither for or against this proposal. I think the intention of the 
author is good but the implementation is not as easy as is explained in the 
proposal. QoS is very crucial for ISPs to sustain the fierce market competition 
and if APNIC fails to timely update the AS0 ROAs, this will effect the service 
delivery and/or network downtime.

I request APNIC to provide a detailed review of this proposal from a service 
and legal perspective so the community can better understand the 
implementation, if this proposal reaches consensus.


Kind regards
Javed Khan
MSCE and CCSP



From: sig-policy-boun...@lists.apnic.net  
on behalf of David Farmer 
Sent: Friday, 23 August 2019 10:48 AM
To: Aftab Siddiqui 
Cc: Sumon Ahmed Sabir ; Policy SIG 
Subject: Re: [sig-policy] prop-132-v002: AS0 for Bogons



On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui 
mailto:aftab.siddi...@gmail.com>> wrote:
Hi David,


On Fri, Aug 23, 2019 at 6:36 AM David Farmer 
mailto:far...@umn.edu>> wrote:
The problem statement says;

Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") is a packet
with an IP source address in an address block not yet allocated by IANA
or the Regional Internet Registries (ARIN, RIPE NCC, APNIC, AFRINIC and
LACNIC)...

So that raises a question, what about resources that are deregisterd because 
they are returned, revoked, or otherwise reclaimed, for any of a myriad of 
reasons, including non-payment of fees? Do they become Bogons with AS0 ROAs the 
moment they are deregistered? Later, if so when? What if there is a ROA for 
them in the system? Are the ROAs removed, if so when?

I also had some concerns about revoked and/or reclaimed space and closed 
account due to non payment so I asked Secretariat in advance and here is the 
response.
===
APNIC membership account is classified as closed when its status is flagged as 
‘closed’ in APNIC’s internal system.

30 days - payment period upon issuance of invoice, if no payment is received 
within this period member receives expiry notice and the account status becomes 
'suspended'
After 15 days – member receives email notification for closure giving them 
another 15 days to pay
After 15 days – the status of the account becomes 'closed' and all delegated 
resources under the account are reclaimed

All in all members have 60 days period to pay before the status of the account 
becomes ‘closed’.
===

As long as the account is suspended APNIC doesn't consider those resources as 
free/available/reclaimed and because they are not part of unallocated pool 
thats why no need to create AS0 ROAs for such resources. AS0 ROAs will be 
created once APNIC mark those resources available and remove them from their 
delegation record. Now, the second issue is if there is a ROA for them in the 
system. Because AS 0 ROA has a lower relative preference than any other ROA 
that has a routable AS then APNIC has to somehow delete the existing ROA from 
the system. Its easy if the member account is closed and all resources are 
reclaimed. But I leave this to APNIC to decide how they are going to make that 
happen.

Currently, when the account is closed nothing actively makes the resources 
unusable, accept for if you were also changing providers during this timeframe, 
then when the new provider checks the resources they will be unregistered. But 
most providers don't recheck the registration of resources very often, if ever, 
other than at the time of setup of service.

With this proposal at some point, the resource will effectively become unusable 
with nonpayment, when the AS0 ROA is created, and any ROAs are removed, I'm 
fine with this, but it should be called out as a consequence of the proposal, 
so no one can say they didn't realize that is a consequence of the proposal.

This proposal changes the consequences for nonpayment, that should be made 
clear in the proposal one way or another.

Also as Owen noted the RIRs frequently have a hold period after the account is 
closed, resource are usually held for some period after account closure and 
before they are reissued to a new user.

Personally I think they should be deregistered for some amount of time before 
the becoming Bogons and have an AS0 ROA created them, also for the AS0 ROA to 
be effective any ROAs for these deregistered resources need to be removed as 
well.

I would propose something like the following;

  1.  Upon de-reregistration any existing ROAs are removed from RPKI
  2.  30 days after de-registraion, AS0 ROAs are created except for non-payment 
fees
  3.  90 days after de-registraion, AS0 ROAs are created in the case of 
non-payment fees

Thanks.

Thanks for these suggestions but do you think the existing waiting period as 
outlined above in APNIC's response is good enough to mark them as 
free/unallocated? or you think additional cooling-off window should be added 
after the account is closed? How about 30 days after de-registration whether it 
was closed 

Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments

[Simon Sohel Baroi / Global Business / 01847102243 /]

Dear Sir,

Also, Requesting to the Author to represent the Proposal with Example and
Graphical Representation.
The example should have comparison with Present situation and the Propose
Solution of the problem.


- with regards

SIMON.

On Sat, Aug 10, 2019 at 8:33 PM Sumon Ahmed Sabir  wrote:

> Dear SIG members
>
> A new version of the proposal "prop-124: Clarification on Sub-Assignments"
> has been sent to the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 48 in
> Chiang Mai, Thailand on Thursday, 12 September 2019.
>
> 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-v006: Clarification on Sub-Assignments
>
> --
>
> Proposer: Jordi Palet Martínez
>jordi.pa...@theipv6company.com
>
>
> 1. Problem Statement
> 
>
> Note that this proposal is ONLY relevant when end-users obtain direct
> assignments
> from APNIC, or when a LIR obtains, also from APNIC, and assignment for
> exclusive
> use within its infrastructure. Consequently this is NOT relevant in case
> of LIR
> allocations.
>
> 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 IPv4, typically, this is not a problem if NAT is being used, because
> the assigned
> addresses are only for the WAN link, which is part of the infrastructure
> or interconnection.
>
> 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 hotspots
> (when is not an ISP, for example, associations or community networks),
> 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”.
>
> It also clarifies that the usage of sub-assignments in ISPs, data
> centers and similar cases
> is not allowed, according to the existing practices of APNIC.
>
>
> 3. Situation in other regions
> -
>
> This situation, has already been corrected in AFRINIC, ARIN, LACNIC and
> RIPE.
>
>
> 4. Proposed policy solution
> ---
>
> Current 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 exclusive use within the infrastructure they operate, as well as for
> interconnection
> purposes.
>
> The assigned address space must only be used by the original recipient
> of the assignment,
> as well as for third party devices provided they are operating within
> said infrastructure.
>
> Therefore, sub-assignments to third parties outside said infrastructure
> (for example
> using sub-assignments for ISP customers), and providing addressing space
> to third
> parties in data-centers (or similar cases), are not allowed.
>
>
> 5. 

Re: [sig-policy] prop-131-v001: Editorial changes in IPv6 Policy

[Simon Sohel Baroi / Global Business / 01847102243 /]

Dear Sir,

Requesting to the Author to represent the Proposal with Example and
Graphical Representation.
The example should have comparison with Present situation and the Propose
Solution of the problem.


- with regards

SIMON.

On Fri, Aug 9, 2019 at 3:59 PM Sumon Ahmed Sabir  wrote:

>
> Dear SIG members,
>
> The proposal "prop-131-v001: Editorial changes in IPv6 Policy" has been
> sent to
> the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 48 in
> Chiang Mai, Thailand on Thursday, 12 September 2019.
>
> 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-131
>
> Regards
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
>
>
> --
>
> prop-131-v001: Editorial changes in IPv6 Policy
>
> --
>
> Proposer: Jordi Palet Martínez
>jordi.pa...@theipv6company.com
>
>
> 1. Problem Statement
> 
>
> This proposal suggests multiple (mainly) editorial changes in the IPv6
> Policy.
> The intent is to remove non-necessary text, and simplify the policy.
>
> Section 5.2.4.2. is reworded to mention a RIPE BCOP, and 5.2.4.4. is
> removed,
> as it is something obvious that operators need to assign some space for
> different
> parts of their own infrastructure.
>
> Section 5.2.4.3. explicitly states that it was drafted at a time when
> there was no
> experience with IPv6 deployment, which is this is longer the case, it
> does not make
> sense to have NIR/RIR to evaluate each instance where an LIR has an End
> User whose
> end site(s) requires a shorter prefix than a /48.
>
> Finally, section 10.1.4.1. is reworded, taking advantage of some of the
> editorial
> changes in the precedent sections, so to avoid duplicating text.
>
>
>
> 2. Objective of policy change
> -
>
> Fulfil the above indicated edits.
>
>
> 3. Situation in other regions
> -
>
> A similar proposal has been submitted to RIPE.
>
>
> 4. Proposed policy solution
> ---
>
> Current Text
> 5.2.4.2. Assignment address space size
>
> ...
>
> End-users are assigned an end site assignment from their LIR or ISP. The
> exact size of
> the assignment is a local decision for the LIR or ISP to make, using a
> minimum value of
> a /64 (when only one subnet is anticipated for the end site) up to the
> normal maximum of
> /48, except in cases of extra large end sites where a larger assignment
> can be justified.
>
> ...
>
>
> New Text
> 5.2.4.2. Assignment address space size
>
> ...
>
> End Users are assigned an end site assignment from their LIR or ISP. The
> size of the
> assignment is a local decision for the LIR or ISP to make, using a value
> of "n" x /64.
> BCOP RIPE690 Section 4.2, provides guidelines about this.
>
> ...
>
> ==
>
> Current Text
> 5.2.4.3. Assignment of multiple /48s to a single end site
>
> When a single end site requires an additional /48 address block, it must
> request the
> assignment with documentation or materials that justify the request.
> Requests for multiple
> or additional /48s will be processed and reviewed (i.e., evaluation of
> justification) at
> the RIR/NIR level.
>
> Note: There is no experience at the present time with the assignment of
> multiple /48s to
> the same end site. Having the RIR review all such assignments is
> intended to be a temporary
> measure until some experience has been gained and some common policies
> can be developed.
> In addition, additional work at defining policies in this space will
> likely be carried out
> in the near future.
>
>
> New Text
> 5.2.4.3. Assignment of multiple /48s to a single end site
>
> Assignment larger than /48 (shorter prefix) or additional assignments
> exceeding a total of
> /48 must be made based on address usage, or because different routing
> requirements exist
> for additional assignments.
>
> In case of a review or when making a request for a subsequent
> allocation, the LIR must
> be able to present documentation justifying the need for assignments
> shorter than a
> /48 to a single End-Site.
>
> 
>
> Current Text
> 

Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments

[Javed Khan]

I do not support this proposal. Intention is good but no one is really 
concerned nor can verify this in practice. I think the current policy text is 
good.

Kind regards
Javed Khan
MSCE and CCSP


From: sig-policy-boun...@lists.apnic.net  
on behalf of Sumon Ahmed Sabir 
Sent: Saturday, 10 August 2019 10:33 PM
To: Policy SIG 
Subject: [sig-policy] prop-124-v006: Clarification on Sub-Assignments

Dear SIG members

A new version of the proposal "prop-124: Clarification on Sub-Assignments"
has been sent to the Policy SIG for review.

It will be presented at the Open Policy Meeting at APNIC 48 in
Chiang Mai, Thailand on Thursday, 12 September 2019.

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

--

Proposer: Jordi Palet Martínez
   jordi.pa...@theipv6company.com


1. Problem Statement


Note that this proposal is ONLY relevant when end-users obtain direct
assignments
from APNIC, or when a LIR obtains, also from APNIC, and assignment for
exclusive
use within its infrastructure. Consequently this is NOT relevant in case
of LIR
allocations.

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 IPv4, typically, this is not a problem if NAT is being used, because
the assigned
addresses are only for the WAN link, which is part of the infrastructure
or interconnection.

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 hotspots
(when is not an ISP, for example, associations or community networks),
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”.

It also clarifies that the usage of sub-assignments in ISPs, data
centers and similar cases
is not allowed, according to the existing practices of APNIC.


3. Situation in other regions
-

This situation, has already been corrected in AFRINIC, ARIN, LACNIC and
RIPE.


4. Proposed policy solution
---

Current 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 exclusive use within the infrastructure they operate, as well as for
interconnection
purposes.

The assigned address space must only be used by the original recipient
of the assignment,
as well as for third party devices provided they are operating within
said infrastructure.

Therefore, sub-assignments to third parties outside said infrastructure
(for example
using sub-assignments for ISP customers), and providing addressing space
to third
parties in data-centers (or similar cases), are not allowed.


5. Advantages / Disadvantages
-

Advantages:

Re: [sig-policy] prop-131-v001: Editorial changes in IPv6 Policy

[Javed Khan]

I support this proposal. Thanks to Jordi for continuously working to simplify 
the policy text.

Kind regards
Javed Khan
MSCE and CCSP



From: sig-policy-boun...@lists.apnic.net  
on behalf of Sumon Ahmed Sabir 
Sent: Friday, 9 August 2019 5:59 PM
To: Policy SIG 
Subject: [sig-policy] prop-131-v001: Editorial changes in IPv6 Policy


Dear SIG members,

The proposal "prop-131-v001: Editorial changes in IPv6 Policy" has been
sent to
the Policy SIG for review.

It will be presented at the Open Policy Meeting at APNIC 48 in
Chiang Mai, Thailand on Thursday, 12 September 2019.

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

Regards

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs


--

prop-131-v001: Editorial changes in IPv6 Policy

--

Proposer: Jordi Palet Martínez
   jordi.pa...@theipv6company.com


1. Problem Statement


This proposal suggests multiple (mainly) editorial changes in the IPv6
Policy.
The intent is to remove non-necessary text, and simplify the policy.

Section 5.2.4.2. is reworded to mention a RIPE BCOP, and 5.2.4.4. is
removed,
as it is something obvious that operators need to assign some space for
different
parts of their own infrastructure.

Section 5.2.4.3. explicitly states that it was drafted at a time when
there was no
experience with IPv6 deployment, which is this is longer the case, it
does not make
sense to have NIR/RIR to evaluate each instance where an LIR has an End
User whose
end site(s) requires a shorter prefix than a /48.

Finally, section 10.1.4.1. is reworded, taking advantage of some of the
editorial
changes in the precedent sections, so to avoid duplicating text.



2. Objective of policy change
-

Fulfil the above indicated edits.


3. Situation in other regions
-

A similar proposal has been submitted to RIPE.


4. Proposed policy solution
---

Current Text
5.2.4.2. Assignment address space size

...

End-users are assigned an end site assignment from their LIR or ISP. The
exact size of
the assignment is a local decision for the LIR or ISP to make, using a
minimum value of
a /64 (when only one subnet is anticipated for the end site) up to the
normal maximum of
/48, except in cases of extra large end sites where a larger assignment
can be justified.

...


New Text
5.2.4.2. Assignment address space size

...

End Users are assigned an end site assignment from their LIR or ISP. The
size of the
assignment is a local decision for the LIR or ISP to make, using a value
of "n" x /64.
BCOP RIPE690 Section 4.2, provides guidelines about this.

...

==

Current Text
5.2.4.3. Assignment of multiple /48s to a single end site

When a single end site requires an additional /48 address block, it must
request the
assignment with documentation or materials that justify the request.
Requests for multiple
or additional /48s will be processed and reviewed (i.e., evaluation of
justification) at
the RIR/NIR level.

Note: There is no experience at the present time with the assignment of
multiple /48s to
the same end site. Having the RIR review all such assignments is
intended to be a temporary
measure until some experience has been gained and some common policies
can be developed.
In addition, additional work at defining policies in this space will
likely be carried out
in the near future.


New Text
5.2.4.3. Assignment of multiple /48s to a single end site

Assignment larger than /48 (shorter prefix) or additional assignments
exceeding a total of
/48 must be made based on address usage, or because different routing
requirements exist
for additional assignments.

In case of a review or when making a request for a subsequent
allocation, the LIR must
be able to present documentation justifying the need for assignments
shorter than a
/48 to a single End-Site.



Current Text
5.2.4.4. Assignment to operator's infrastructure

An organization (ISP/LIR) may assign a /48 per PoP as the service
infrastructure of an
IPv6 service 

Re: [sig-policy] Version 4 of prop-126 PDP Update

[Javed Khan]

I do not support this proposal as I have complete trust in the current APNIC 
PDP and this community.

Kind regards
Javed Khan
MSCE and CCSP


From: sig-policy-boun...@lists.apnic.net  
on behalf of Sumon Ahmed Sabir 
Sent: Friday, 9 August 2019 2:13 AM
To: Policy SIG 
Subject: [sig-policy] Version 4 of prop-126 PDP Update


Dear SIG members

A new version of the proposal "prop-126: PDP Update" has been sent to
the Policy SIG for review.

It will be presented at the Open Policy Meeting at APNIC 48 in
Chiang Mai, Thailand on Thursday, 12 September 2019.

Information about earlier versions is available from:
https://www.apnic.net/community/policy/proposals/prop-126/

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-126-v004: 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 explicitly
considering
  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.

Even if this is actually done by the chairs, it is not part of the
actual PDP,
and thus constitutes a very clear and explicit violation of the PDP and
the risk
is that anyone from the community could appeal any decision based on that.

Finally, it completes the PDP by adding a simple mechanism for solving
disagreements
during an appeals phase and an improved definition of ‘consensus’, as
well as a
complete definition of the “consensus” and “last-call”.


2. Objective of policy change
-

To allow that consensus is determined formally looking at the opinions
of community
members that are not able to travel to the meetings 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
---

Current Text
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.

New Text
Step 2: Consensus Determination
Consensus is defined as “rough consensus” as observed by the Chairs.

Consensus is determined first considering the SIG mailing list, other
electronic means,
and the SIG session, and afterwards at the Member Meeting.

If there is no consensus on a proposal, the authors can decide to
withdraw it.

Otherwise, the proposal will expire in six months, unless a new version
is provided,
restarting the discussions with the community.

==

Current Text
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.


New Text
Step 3: Last-Call
Proposals that have reached consensus at the OPM and the AMM will be
circulated on the
appropriate SIG mailing during four weeks.

The purpose of the “last-call” is to provide the community with a brief
and final opportunity
to comment on the proposal, especially those who didn’t earlier.

Consequently, during this period editorial comments may be submitted
and, exceptionally,
objections if any aspect is