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

[Owen DeLong]

> On Aug 26, 2019, at 03:05 , JORDI PALET MARTINEZ  
> wrote:
> 
> Hi Javed,
>  
> I don’t agree, let me explain why.
>  
> The current process only talks about the meeting and the chairs have clearly 
> indicated that they take in consideration the list and the confer. Anyone 
> from the community that dislikes a consensus/non-consensus decision, could 
> create a trouble even in courts, because we are accepting consensus from 
> sources not documented in the PDP. Rewording it resolves the problem.
>  
> Furthermore, the current process has not an “in-process” appeal procces. This 
> will be ilegal in may legislations (may be only the AU applies, but 
> considering that the community is “the entire Internet”, may be this may be 
> declared illegal in another country where a member decides to claim for). The 
> only way (actually) to appeal, will be going to the courts. We should not aim 
> to that. We should have an internal way.

While there is no appeal process, there are sufficient iterations of approval 
and ratification in the current process that I am not convinced an appeal 
process is necessary.

Calling out the (remote) possibility that some jurisdiction might have a 
problem with it is a red herring and absent actual legal doctrine within the 
APNIC service region, I think it’s a bit far fetched to put that argument 
forward.
 
> This is now even more relevant to be resolved, because by chance, the chairs 
> have denied to accept one of the policy proposal that I’ve submited. They 
> consider it out-of-scope, and my reading is that is in-scope (it has also 
> been submitted and in-scope to RIPE, LACNIC and AFRINIC). I think their 
> decision is wrong and this has many implications that we need to work out. 
> The best avenue is having an “in-house” appeal process, of course.

You’ve been wrong about what should be in-scope before. I won’t cite the 
specifics unless you insist, but you are more than welcome to discuss your 
concerns about it with Paul and/or the EC and I’m certain you will get an 
appropriate response. While it’s not a formal appeal process, I’m certain that 
if they agree with you that the co-chairs erred, they will discuss the 
situation with the co-chairs and come to an appropriate resolution.
 
> Note that I didn’t knew, when I submitted the PDP update (which is a new 
> version from a the previous year proposal), that one of my proposals will be 
> considered by the chairs as out-of-scope. Clarification just so nobody 
> believes that it is related to that rejection! Chairs can confirm that.

I don’t think anyone is questioning your motives, Jordi. We all know that your 
heart is generally in the right place, even if we don’t agree with you about 
your desired actions.

We all know that you like how things work in the RIPE region. I will say that 
I’m not as fond of the RIPE process as you are. I will also point out that 
general apathy is not necessarily a bad thing. It depends on the reasons for 
the apathy. If the apathy is because nothing bad enough to motivate people to 
action is happening, then apathy is not the worst possible outcome. If the 
apathy is because people feel disenfranchised and unable to make a difference, 
then the cause of the apathy must desperately be addressed with all due haste. 
I do not believe that people are disenfranchised in the APNIC region or that 
anything horrible is happening in the APNIC policy arena.

I’m far less active on the APNIC list(s) than ARIN and AfriNIC. I’m more active 
in the ARIN region because it is my home region and because I (currently) have 
a leadership role there. I’m more active in AfriNIC because I believe there are 
more problems there and policy development there needs all the help it can get. 
I participate in APNIC when I feel I have something useful to contribute to the 
discussion. Otherwise, I mostly lurk. I’d probably watch LACNIC if I spoke 
better spanish. I’ve never actually subscribed to the RIPE PDP list. RIPE seems 
to be doing what RIPE does well enough without my contribution.

Owen

>  
> Regards,
> Jordi
> 
> @jordipalet
> 
>  
> 
>  
>  
> El 23/8/19 15:48, "Javed Khan"   en nombre de 
> javedkha...@outlook.com > escribió:
>  
> 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:
> 

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

[Owen DeLong]

> On Aug 26, 2019, at 03:19 , JORDI PALET MARTINEZ  
> wrote:
> 
> Hi Javed,
>  
> I think you’re getting something wrong.
>  
> Policies aren’t there so APNIC can verify “everything” to “every” member. 
> This will be impossible.
>  
> Policies are there so everybody know the rules, and try their best to avoid 
> breaking them.
>  
> Policies are there to avoid bad-intentions from bad-Internet actors, in order 
> to protect the majority (the good ones).
>  
> If we only accept policies when they can be verified, then we will have an 
> empty policy book :-)
>  
> If APNIC does a verification, for whatever reason (any suspicius, a claim 
> from another member, etc.), and a rule is broken, APNIC should take measures 
> if the member doesn’t correct it. In some cases those measures may mean 
> member closure, resource recovery, etc. This is a completely different 
> discussion which has policy and service agreement implications.
>  
> Please, note before continue reading that this only affects end-user direct 
> assignments by APNIC or the NIRs. Not clarifiying this caused some confusion 
> in the discussion of the last meeting. So if you’re an ISP (I’m not sure if 
> that’s your case), this proposal doesn’t affect you.
>  
> It only affect you, if you are getting a direct assignment from APNIC or any 
> of the NIRs.
>  
> The fact here is that if, for example, an university, which got a direct 
> assignment from APNIC, is providing the students public addresses (IPv4) or 
> global addresses (IPv6), it is against the policy.

No, this does not violate current policy. The students are part of the 
University every bit as much as employees of a company are entitled to receive 
valid public addresses for their BYO smart phones/whatever in the office.

That’s not sub assignment or reassignment, that’s just utilization within the 
Universities own network.
 
> In the case of IPv4, the solution is easy, use NAT and private addresses (but 
> not all the universities do that). However in IPv6 this is not the solution, 
> we don’t have NAT.

NAT is not required by current policy. The policy text as it stands does not 
prohibit the (temporary) use of public addresses on LAN or WLAN segments 
controlled by the entity holding the prefix even if the device(s) are not 
owned/directly controlled by the University. Especially in the case where the 
devices are in the possession/control of employees/students of the institution 
in question.

If you think that is the case, then you have misunderstood the current policy.

Owen
 
> I can put many other similar examples (remember again, this is only the case 
> when the addresses are directly assigned to the end-user by APNIC or the NIR, 
> not by an ISP): a point to point link from the university to another network, 
> an employee getting addresses from a company, thir party companies offering 
> services to that company or university, a municipality offering WiFi to 
> citizens, etc.
>  
> The proposal solves both cases, the IPv4 and the IPv6 one.
>  
> Note that this has been already corrected in all the other RIRs (ARIN, 
> AFRINIC, LACNIC and RIPE). All them had the same problem in their policy text.
>  
> Regards,
> Jordi
> 
> @jordipalet
> 
>  
> 
>  
>  
> El 23/8/19 16:01, "Javed Khan"   en nombre de 
> javedkha...@outlook.com > escribió:
>  
> 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 
> mailto:sasa...@gmail.com>>
> Sent: Saturday, 10 August 2019 10:33 PM
> To: Policy SIG mailto:sig-pol...@apnic.net>>
> 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
> 
> 

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

[Owen DeLong]

Aftab,

I don’t think you actually addressed his concern…


> On Aug 26, 2019, at 17:17 , Aftab Siddiqui  wrote:
> 
> Hi Javed,
> I understand your concern, let me try to explain.
> 
> AS-0 ROA is an attestation by the holder of a prefix that the prefix 
> described in the ROA, and any more specific prefix, should not be used in a 
> routing context. The route validation consider a "valid" outcome if "ANY" ROA 
> matches the address prefix and origin AS, even if other valid ROAs would 
> provide an "invalid" validation outcome if used in isolation.  Since, its not 
> possible to generate a prefix with AS-0 there fore it is not possible that 
> valid ROA will impact the routing of a prefix even if there is an AS-0 ROA 
> for that prefix. Also, AS 0 ROA has a lower relative preference than any 
> other ROA that has a routable AS.  

Presumably, APNIC would withdraw/invalidate any other ROA for the prefix (or 
its subordinates) at or before the time when they would issue an AS-0 ROA.

Revoking the previously valid ROAs moves the prefix from VALIDATED/GOOD to 
UNVALIDATED/UNKNOWN status in any route validator. This would not affect the 
routing table in most cases since there won’t be a validated route (in this 
instance) to supersede the UNVALIDATED/UNKNOWN route which was previously 
VALIDATED/GOOD.

Issuing the AS-0 ROA would subsequently move the prefix from VALIDATED/GOOD or 
UNVALIDATED/UNKNOWN status to INVALID/KNOWN status, thus causing most 
validating routers to discard the route.



> 
> For Example,
> - APNIC creates AS-0 ROA for 103.8.194.0/24  (This is 
> an unallocated prefix announced AS135754, a bogon).
> - If I'm doing ROV then this prefix (103.8.194.0/24 ) 
> will become invalid for me because it doesn't have a valid ROA. Anyone not 
> doing ROV or any other form of bogon filtering will still accept this prefix 
> and keep on treating it as normal.
> - Now, APNIC delegates this prefix to someone else after some time (remember 
> the AS-0 ROA still exist). That someone is AS139038 (myself).
> - Because this prefix is now under my administration I can create ROA with my 
> own ASN i.e. AS139038
> - Before delegating the prefix to me APNIC should have delete that AS-0 ROA 
> but lets assume they forgot to do so or some technical glitch happened and 
> the AS-0 ROA still exist for this prefix even after delegating it to me
> - Since I have created a ROA with my ASN i.e. AS139038 then the validators 
> will mark the prefix originating from my ASN as valid even though there is an 
> AS-0 ROA for that prefix. 

Different example:

APNIC issues 2001:db8:feed::/48 to XYZ Corp. who creates a ROA for AS65551.
If you’re doing ROV, then this prefix 2001:db8:feed::/48 is validated assuming 
you receive the route with an AS PATh that matches "* 65551 $”.
Subsequently, XYZ Corp forgets to pay their APNIC invoice and APNIC revokes the 
space.
Under current policy, APNIC Simply deletes the ROA and anyone doing ROV no 
longer sees 2001:db8:feed::/48 as valid, but they don’t see it as invalid. It 
moves to unknown.
In the current (and foreseeable future) world, and unknown route is 
probably still going to be accepted by the vast majority of peers, so this has 
little effect on routing.
Under the proposed policy, at some point, APNIC issues a new ROA for 
2001:db8:feed::/48 tied to AS0.
This has two effects that are not present in the current situation:
1.  The route with origin AS6551 is no tagged as “Invalid” — There 
is no matching VALID ROA since they were all revoked by the RIR.
2.  Most peers doing ROV will likely drop the prefix. While unknown 
prefixes are not likely dropped, known invalid prefixes are a different matter 
and
even though some ROV operators will not drop them 
today, more and more will sooner rather than later.

This means that the RIR now has much greater direct power over influencing 
routing decisions than in the pre-RPKI/ROV days. I’m not saying
whether this is good or bad (who am I to judge at this point), but I am saying 
it’s a valid concern and a huge potential operational consequence
of this proposed policy.

> You can also check prefix 103.114.191.0/24  via any 
> validator you are running which has both AS-0 ROA (created by them) and also 
> a ROA with their routable ASN (AS397702). Many operators have created AS-0 
> ROAs along side the ROA with their own routable ASN. 

Yes, but this doesn’t cover the case Javed expressed concern about.

> I hope this helps answer you concern. Please let me know if you still have 
> any question.

Even if Javed is somehow satisfied with your answer, I think that we need a 
detailed explanation from staff how this policy would be implemented and
what measures would be taken to avoid the erroneous (and potentially 
disastrous) combination of revocation of all previous ROAs and issuance of
an AS-0 ROA. Also, a clear 

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

[Aftab Siddiqui]

Hi Javed,
I understand your concern, let me try to explain.

AS-0 ROA is an attestation by the holder of a prefix that the prefix
described in the ROA, and any more specific prefix, should not be used in a
routing context. The route validation consider a "valid" outcome if "ANY"
ROA matches the address prefix and origin AS, even if other valid ROAs
would provide an "invalid" validation outcome if used in isolation.  Since,
its not possible to generate a prefix with AS-0 there fore it is not
possible that valid ROA will impact the routing of a prefix even if there
is an AS-0 ROA for that prefix. Also, AS 0 ROA has a lower relative
preference than any other ROA that has a routable AS.

For Example,
- APNIC creates AS-0 ROA for 103.8.194.0/24 (This is an unallocated prefix
announced AS135754, a bogon).
- If I'm doing ROV then this prefix (103.8.194.0/24) will become invalid
for me because it doesn't have a valid ROA. Anyone not doing ROV or any
other form of bogon filtering will still accept this prefix and keep on
treating it as normal.
- Now, APNIC delegates this prefix to someone else after some time
(remember the AS-0 ROA still exist). That someone is AS139038 (myself).
- Because this prefix is now under my administration I can create ROA with
my own ASN i.e. AS139038
- Before delegating the prefix to me APNIC should have delete that AS-0 ROA
but lets assume they forgot to do so or some technical glitch happened and
the AS-0 ROA still exist for this prefix even after delegating it to me
- Since I have created a ROA with my ASN i.e. AS139038 then the validators
will mark the prefix originating from my ASN as valid even though there is
an AS-0 ROA for that prefix.

You can also check prefix 103.114.191.0/24 via any validator you are
running which has both AS-0 ROA (created by them) and also a ROA with their
routable ASN (AS397702). Many operators have created AS-0 ROAs along side
the ROA with their own routable ASN.

I hope this helps answer you concern. Please let me know if you still have
any question.

Regards,

Aftab A. Siddiqui


On Sat, Aug 24, 2019 at 12:29 AM Javed Khan  wrote:

> 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 <
> sig-policy-boun...@lists.apnic.net> on behalf of David Farmer <
> far...@umn.edu>
> *Sent:* Friday, 23 August 2019 10:48 AM
> *To:* Aftab Siddiqui 
> *Cc:* Sumon Ahmed Sabir ; Policy SIG <
> sig-pol...@apnic.net>
> *Subject:* Re: [sig-policy] prop-132-v002: AS0 for Bogons
>
>
>
> On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui 
> wrote:
>
> Hi David,
>
>
> On Fri, Aug 23, 2019 at 6:36 AM David Farmer  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
> 

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

[Srinivas Chendi]

Hi Javed,

Thanks for your email and for your participation in the policy 
development process.

We're consulting our experts to provide a response to your query soon. 
Please allow us sometime.

Regards
Sunny

On 24/08/2019 12:28 am, Javed Khan wrote:
> 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  > wrote:
> 
> Hi David,
> 
> 
> On Fri, Aug 23, 2019 at 6:36 AM David Farmer  > 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 

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

[JORDI PALET MARTINEZ]

Hi Javed,

 

I think you’re getting something wrong.

 

Policies aren’t there so APNIC can verify “everything” to “every” member. This 
will be impossible.

 

Policies are there so everybody know the rules, and try their best to avoid 
breaking them.

 

Policies are there to avoid bad-intentions from bad-Internet actors, in order 
to protect the majority (the good ones).

 

If we only accept policies when they can be verified, then we will have an 
empty policy book :-)

 

If APNIC does a verification, for whatever reason (any suspicius, a claim from 
another member, etc.), and a rule is broken, APNIC should take measures if the 
member doesn’t correct it. In some cases those measures may mean member 
closure, resource recovery, etc. This is a completely different discussion 
which has policy and service agreement implications.

 

Please, note before continue reading that this only affects end-user direct 
assignments by APNIC or the NIRs. Not clarifiying this caused some confusion in 
the discussion of the last meeting. So if you’re an ISP (I’m not sure if that’s 
your case), this proposal doesn’t affect you.

 

It only affect you, if you are getting a direct assignment from APNIC or any of 
the NIRs.

 

The fact here is that if, for example, an university, which got a direct 
assignment from APNIC, is providing the students public addresses (IPv4) or 
global addresses (IPv6), it is against the policy.

 

In the case of IPv4, the solution is easy, use NAT and private addresses (but 
not all the universities do that). However in IPv6 this is not the solution, we 
don’t have NAT.

 

I can put many other similar examples (remember again, this is only the case 
when the addresses are directly assigned to the end-user by APNIC or the NIR, 
not by an ISP): a point to point link from the university to another network, 
an employee getting addresses from a company, thir party companies offering 
services to that company or university, a municipality offering WiFi to 
citizens, etc.

 

The proposal solves both cases, the IPv4 and the IPv6 one.

 

Note that this has been already corrected in all the other RIRs (ARIN, AFRINIC, 
LACNIC and RIPE). All them had the same problem in their policy text.

 

Regards,

Jordi

@jordipalet

 

 

 

El 23/8/19 16:01, "Javed Khan"  escribió:

 

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,

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

[JORDI PALET MARTINEZ]

Hi Javed,

 

I don’t agree, let me explain why.

 

The current process only talks about the meeting and the chairs have clearly 
indicated that they take in consideration the list and the confer. Anyone from 
the community that dislikes a consensus/non-consensus decision, could create a 
trouble even in courts, because we are accepting consensus from sources not 
documented in the PDP. Rewording it resolves the problem.

 

Furthermore, the current process has not an “in-process” appeal procces. This 
will be ilegal in may legislations (may be only the AU applies, but considering 
that the community is “the entire Internet”, may be this may be declared 
illegal in another country where a member decides to claim for). The only way 
(actually) to appeal, will be going to the courts. We should not aim to that. 
We should have an internal way.

 

This is now even more relevant to be resolved, because by chance, the chairs 
have denied to accept one of the policy proposal that I’ve submited. They 
consider it out-of-scope, and my reading is that is in-scope (it has also been 
submitted and in-scope to RIPE, LACNIC and AFRINIC). I think their decision is 
wrong and this has many implications that we need to work out. The best avenue 
is having an “in-house” appeal process, of course.

 

Note that I didn’t knew, when I submitted the PDP update (which is a new 
version from a the previous year proposal), that one of my proposals will be 
considered by the chairs as out-of-scope. Clarification just so nobody believes 
that it is related to that rejection! Chairs can confirm that.

 

Regards,

Jordi

@jordipalet

 

 

 

El 23/8/19 15:48, "Javed Khan"  escribió:

 

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