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

[Aftab Siddiqui]

Thanks David for your points, I'm working on v3 to address some of these
concern.

Regards,

Aftab A. Siddiqui


On Thu, Aug 29, 2019 at 3:22 PM David Farmer  wrote:

> The increased consequences of an APNIC Member failing to pay fees or the
> extremely rare possibility of an error by APNIC Staff should be called out
> as a potential impacts of the proposal in section 7.
>
> Personally, I support the proposal, but it is a matter of informed
> consent, the community needs to consider the fact that this proposal
> increases the consequences if certain events occur.
>
> If these consequences are included in the proposal, when someone forgets
> to pay their bill and their resources get block by most of the Internet,
> then no one can claim it wasn't considered.
>
> Thanks.
>
> On Wed, Aug 28, 2019 at 11:07 PM Owen DeLong  wrote:
>
>>
>>
>> On Aug 28, 2019, at 20:37 , Aftab Siddiqui 
>> wrote:
>>
>>
>> Hi Owen,
>>  cutting some stuff out, just to keep the thread small.
>>
>> Anyone can very quickly put just about anything in RADB if they want to.
>>> It’s also relatively easy to put nearly anything in the current ARIN IRR
>>> (not to be confused with the ARIN RIR database). There are also some other
>>> IRRs that accept almost anything at face value.
>>>
>>
>> Exactly, thats why you have so much garbage in RADB and other IRR db.
>>
>>
>> It’s also why the RIR withdrawing an entry isn’t as likely to cause an
>> unmitigable outage than would occur under this policy.
>>
>>
>>
>>>
>>> Finally, route object based filters tend to get updated rather slowly
>>> and not everyone updates in sync, so it’s a gradually progressing outage
>>> that allows some reaction time before becoming completely catastrophic.
>>>
>>
>> Similarly, not everyone is doing ROV. But for the first time people are
>> worried about consequences of their laziness because RPKI is going to work
>> much better than IRR based filtering.
>>
>>
>> I’m not sure that’s a completely fair characterization of the situation,
>> but for whatever reason, despite its inability to do more than provide a
>> really good cryptographically signed hint at what to forge in your
>> hijacking announcements, RPKI is spreading like an unstoppable cancer and
>> more and more people are beginning to do ROV in a mode which permits
>> unknowns, but rejects known invalids.
>>
>> RIRs implementing AS0 raises the stakes by giving RIRs the power to
>> create “known invalids” where the previous state would be “unknown”.
>>
>>
>>> OTOH, if APNIC accidentally deletes the registration and issues an AS0
 ROA for the entire netback, then you’re (potentially) talking about near
 total catastrophic routing failure for this ISP and all of his customers.

>>>
>>> Let’s assume they accidentally delete the registration for any reason
>>> there are cooling off periods in place which goes up to 60 days or we can
>>> put measures in place through policy to have decent cooking off periods.
>>> Also let’s talk about stats, how many times how many RIRs have deleted
>>> their members by mistake? Do you have any case?
>>>
>>>
>>> Honestly, I have no way to know. Such an event would likely not be made
>>> particularly public. The RIR would consider it confidential to the affected
>>> party and the affected party would have little motivation to announce it to
>>> the world after the fact.
>>>
>>
>> So we are debating a scenario which we are not even aware ever happened.
>> I'm still not saying that it never happened and will not happen but
>> likelihood of such incident is just very small.
>>
>>
>> No… You asked for an example of how an AS0 ROA could get into the wild
>> erroneously and I presented one scenario which you are now arguing is
>> unlikely.
>> I agree that particular scenario may well be unlikely, but I’m not
>> convinced it is the only circumstance in which such an event could occur.
>> Depending on how AS-0 ROAs are generated, I see lots of possible ways for
>> fat-finger incidents at the RIR to result in dangerous issuances.
>>
>>
>>
>>>
>>> So I am not in favor of asking the RIR to create AS0 ROA.
>

 Thats absolutely fine we can agree to disagree but let’s have a clear
 understanding of the policy.


 What makes you think he does not understand the policy?

>>>
>>> Because the policy only addresses the bogon, how an address space
>>> becomes a bogon is APNIC operating procedure. Do you see the problem of
>>> understanding here?
>>>
>>>
>>> Yes, but it’s not his. The policy creates new more severe consequences
>>> for things moving “routable” -> “bogon”. When you increase the consequences
>>> of an action, it’s often a good idea to review the potential causes of that
>>> action and consider what avenues exist for erroneous triggers.
>>>
>>
>> Absolutely, its a good idea to have measures in place to avoid any
>> erroneous triggers and thats why I said APNIC can put operational practices
>> in place for that. Its shouldn't be part of the 

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

[David Farmer]

The increased consequences of an APNIC Member failing to pay fees or the
extremely rare possibility of an error by APNIC Staff should be called out
as a potential impacts of the proposal in section 7.

Personally, I support the proposal, but it is a matter of informed consent,
the community needs to consider the fact that this proposal increases the
consequences if certain events occur.

If these consequences are included in the proposal, when someone forgets to
pay their bill and their resources get block by most of the Internet, then
no one can claim it wasn't considered.

Thanks.

On Wed, Aug 28, 2019 at 11:07 PM Owen DeLong  wrote:

>
>
> On Aug 28, 2019, at 20:37 , Aftab Siddiqui 
> wrote:
>
>
> Hi Owen,
>  cutting some stuff out, just to keep the thread small.
>
> Anyone can very quickly put just about anything in RADB if they want to.
>> It’s also relatively easy to put nearly anything in the current ARIN IRR
>> (not to be confused with the ARIN RIR database). There are also some other
>> IRRs that accept almost anything at face value.
>>
>
> Exactly, thats why you have so much garbage in RADB and other IRR db.
>
>
> It’s also why the RIR withdrawing an entry isn’t as likely to cause an
> unmitigable outage than would occur under this policy.
>
>
>
>>
>> Finally, route object based filters tend to get updated rather slowly and
>> not everyone updates in sync, so it’s a gradually progressing outage that
>> allows some reaction time before becoming completely catastrophic.
>>
>
> Similarly, not everyone is doing ROV. But for the first time people are
> worried about consequences of their laziness because RPKI is going to work
> much better than IRR based filtering.
>
>
> I’m not sure that’s a completely fair characterization of the situation,
> but for whatever reason, despite its inability to do more than provide a
> really good cryptographically signed hint at what to forge in your
> hijacking announcements, RPKI is spreading like an unstoppable cancer and
> more and more people are beginning to do ROV in a mode which permits
> unknowns, but rejects known invalids.
>
> RIRs implementing AS0 raises the stakes by giving RIRs the power to create
> “known invalids” where the previous state would be “unknown”.
>
>
>> OTOH, if APNIC accidentally deletes the registration and issues an AS0
>>> ROA for the entire netback, then you’re (potentially) talking about near
>>> total catastrophic routing failure for this ISP and all of his customers.
>>>
>>
>> Let’s assume they accidentally delete the registration for any reason
>> there are cooling off periods in place which goes up to 60 days or we can
>> put measures in place through policy to have decent cooking off periods.
>> Also let’s talk about stats, how many times how many RIRs have deleted
>> their members by mistake? Do you have any case?
>>
>>
>> Honestly, I have no way to know. Such an event would likely not be made
>> particularly public. The RIR would consider it confidential to the affected
>> party and the affected party would have little motivation to announce it to
>> the world after the fact.
>>
>
> So we are debating a scenario which we are not even aware ever happened.
> I'm still not saying that it never happened and will not happen but
> likelihood of such incident is just very small.
>
>
> No… You asked for an example of how an AS0 ROA could get into the wild
> erroneously and I presented one scenario which you are now arguing is
> unlikely.
> I agree that particular scenario may well be unlikely, but I’m not
> convinced it is the only circumstance in which such an event could occur.
> Depending on how AS-0 ROAs are generated, I see lots of possible ways for
> fat-finger incidents at the RIR to result in dangerous issuances.
>
>
>
>>
>> So I am not in favor of asking the RIR to create AS0 ROA.

>>>
>>> Thats absolutely fine we can agree to disagree but let’s have a clear
>>> understanding of the policy.
>>>
>>>
>>> What makes you think he does not understand the policy?
>>>
>>
>> Because the policy only addresses the bogon, how an address space becomes
>> a bogon is APNIC operating procedure. Do you see the problem of
>> understanding here?
>>
>>
>> Yes, but it’s not his. The policy creates new more severe consequences
>> for things moving “routable” -> “bogon”. When you increase the consequences
>> of an action, it’s often a good idea to review the potential causes of that
>> action and consider what avenues exist for erroneous triggers.
>>
>
> Absolutely, its a good idea to have measures in place to avoid any
> erroneous triggers and thats why I said APNIC can put operational practices
> in place for that. Its shouldn't be part of the policy.
>
>
> I never advocated for making it part of the policy. I advocated for
> reviewing it as part of the considerations BEFORE consenting to
> implementation of the policy.
>
> I never asked for a change to the policy text. I asked for APNIC to
> publish their anticipated operational procedures 

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

[Owen DeLong]

> On Aug 28, 2019, at 20:37 , Aftab Siddiqui  wrote:
> 
> 
> Hi Owen,
>  cutting some stuff out, just to keep the thread small.
> 
> Anyone can very quickly put just about anything in RADB if they want to. It’s 
> also relatively easy to put nearly anything in the current ARIN IRR (not to 
> be confused with the ARIN RIR database). There are also some other IRRs that 
> accept almost anything at face value.
> 
> Exactly, thats why you have so much garbage in RADB and other IRR db. 

It’s also why the RIR withdrawing an entry isn’t as likely to cause an 
unmitigable outage than would occur under this policy.

>  
> 
> Finally, route object based filters tend to get updated rather slowly and not 
> everyone updates in sync, so it’s a gradually progressing outage that allows 
> some reaction time before becoming completely catastrophic.
> 
> Similarly, not everyone is doing ROV. But for the first time people are 
> worried about consequences of their laziness because RPKI is going to work 
> much better than IRR based filtering. 

I’m not sure that’s a completely fair characterization of the situation, but 
for whatever reason, despite its inability to do more than provide a really 
good cryptographically signed hint at what to forge in your hijacking 
announcements, RPKI is spreading like an unstoppable cancer and more and more 
people are beginning to do ROV in a mode which permits unknowns, but rejects 
known invalids.

RIRs implementing AS0 raises the stakes by giving RIRs the power to create 
“known invalids” where the previous state would be “unknown”.

> 
>> OTOH, if APNIC accidentally deletes the registration and issues an AS0 ROA 
>> for the entire netback, then you’re (potentially) talking about near total 
>> catastrophic routing failure for this ISP and all of his customers.
>> 
>> Let’s assume they accidentally delete the registration for any reason there 
>> are cooling off periods in place which goes up to 60 days or we can put 
>> measures in place through policy to have decent cooking off periods. Also 
>> let’s talk about stats, how many times how many RIRs have deleted their 
>> members by mistake? Do you have any case? 
> 
> Honestly, I have no way to know. Such an event would likely not be made 
> particularly public. The RIR would consider it confidential to the affected 
> party and the affected party would have little motivation to announce it to 
> the world after the fact.
> 
> So we are debating a scenario which we are not even aware ever happened. I'm 
> still not saying that it never happened and will not happen but likelihood of 
> such incident is just very small. 

No… You asked for an example of how an AS0 ROA could get into the wild 
erroneously and I presented one scenario which you are now arguing is unlikely.
I agree that particular scenario may well be unlikely, but I’m not convinced it 
is the only circumstance in which such an event could occur.
Depending on how AS-0 ROAs are generated, I see lots of possible ways for 
fat-finger incidents at the RIR to result in dangerous issuances.

>  
> 
>>> So I am not in favor of asking the RIR to create AS0 ROA.
>>> 
>>> Thats absolutely fine we can agree to disagree but let’s have a clear 
>>> understanding of the policy. 
>> 
>> What makes you think he does not understand the policy?
>> 
>> Because the policy only addresses the bogon, how an address space becomes a 
>> bogon is APNIC operating procedure. Do you see the problem of understanding 
>> here? 
> 
> Yes, but it’s not his. The policy creates new more severe consequences for 
> things moving “routable” -> “bogon”. When you increase the consequences of an 
> action, it’s often a good idea to review the potential causes of that action 
> and consider what avenues exist for erroneous triggers.
> 
> Absolutely, its a good idea to have measures in place to avoid any erroneous 
> triggers and thats why I said APNIC can put operational practices in place 
> for that. Its shouldn't be part of the policy.

I never advocated for making it part of the policy. I advocated for reviewing 
it as part of the considerations BEFORE consenting to implementation of the 
policy.

I never asked for a change to the policy text. I asked for APNIC to publish 
their anticipated operational procedures for review so that the community can 
consider them in determining whether or not to come to consensus on this policy 
proposal.

In other words, I agree they shouldn’t be part of the policy, but they MUST be 
part of the policy deliberation, IMHO.

>> Also it’s seems you are fine with people advertising bogons just because 
>> fixing it might make one/two people unhappy. 
> 
> I’m not necessarily fine with people advertising bogons, but I’m also not 
> necessarily convinced that I want the RIRs to become the routing police.
> 
> This proposal literally moves the routing police role from the hands of those 
> who run routers into the hands of the RIRs (well, specifically it moves part 
> of that 

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

[Aftab Siddiqui]

Hi Owen,
 cutting some stuff out, just to keep the thread small.

Anyone can very quickly put just about anything in RADB if they want to.
> It’s also relatively easy to put nearly anything in the current ARIN IRR
> (not to be confused with the ARIN RIR database). There are also some other
> IRRs that accept almost anything at face value.
>

Exactly, thats why you have so much garbage in RADB and other IRR db.


>
> Finally, route object based filters tend to get updated rather slowly and
> not everyone updates in sync, so it’s a gradually progressing outage that
> allows some reaction time before becoming completely catastrophic.
>

Similarly, not everyone is doing ROV. But for the first time people are
worried about consequences of their laziness because RPKI is going to work
much better than IRR based filtering.

>
> OTOH, if APNIC accidentally deletes the registration and issues an AS0 ROA
>> for the entire netback, then you’re (potentially) talking about near total
>> catastrophic routing failure for this ISP and all of his customers.
>>
>
> Let’s assume they accidentally delete the registration for any reason
> there are cooling off periods in place which goes up to 60 days or we can
> put measures in place through policy to have decent cooking off periods.
> Also let’s talk about stats, how many times how many RIRs have deleted
> their members by mistake? Do you have any case?
>
>
> Honestly, I have no way to know. Such an event would likely not be made
> particularly public. The RIR would consider it confidential to the affected
> party and the affected party would have little motivation to announce it to
> the world after the fact.
>

So we are debating a scenario which we are not even aware ever happened.
I'm still not saying that it never happened and will not happen but
likelihood of such incident is just very small.


>
> So I am not in favor of asking the RIR to create AS0 ROA.
>>>
>>
>> Thats absolutely fine we can agree to disagree but let’s have a clear
>> understanding of the policy.
>>
>>
>> What makes you think he does not understand the policy?
>>
>
> Because the policy only addresses the bogon, how an address space becomes
> a bogon is APNIC operating procedure. Do you see the problem of
> understanding here?
>
>
> Yes, but it’s not his. The policy creates new more severe consequences for
> things moving “routable” -> “bogon”. When you increase the consequences of
> an action, it’s often a good idea to review the potential causes of that
> action and consider what avenues exist for erroneous triggers.
>

Absolutely, its a good idea to have measures in place to avoid any
erroneous triggers and thats why I said APNIC can put operational practices
in place for that. Its shouldn't be part of the policy.


>
> Also it’s seems you are fine with people advertising bogons just because
> fixing it might make one/two people unhappy.
>
>
> I’m not necessarily fine with people advertising bogons, but I’m also not
> necessarily convinced that I want the RIRs to become the routing police.
>
> This proposal literally moves the routing police role from the hands of
> those who run routers into the hands of the RIRs (well, specifically it
> moves part of that role in one region into the hands of one RIR).
>

This policy is not doing anything special and giving extra powers to RIR.
It happened when we (the community) agreed to move forward with RPKI. Any
consequences you are relating to AS0 are also true for any other ROA.
Whether its a good thing or bad, we can all have different opinion but its
a reality.
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

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

[Owen DeLong]

> On Aug 28, 2019, at 16:40 , Aftab Siddiqui  wrote:
> 
> 
> 
> On Thu, 29 Aug 2019 at 9:04 am, Owen DeLong  > wrote:
> 
> 
>> On Aug 28, 2019, at 13:44 , Aftab Siddiqui > > wrote:
>> 
>> Hi Javed,
>> 
>> On Thu, 29 Aug 2019 at 6:33 am, Javed Khan > > wrote:
>> We may think we are living in a perfect world but we are not.
>> 
>> of course 
>> 
>> With this proposal I'm more worried about the network downtime as managing 
>> an AS0 ROA by an RIR may be prone to errors as we all do regardless if its a 
>> manual or automated solution.
>> 
>> Would you like to explain how AS0 ROA can create network downtime? 
> 
> One possible way I can think of (I’m sure there are others)…
> 
> ISP Q is issued 2001:db8::/32 by APNIC.
> 
> ISP Q does not participate in RPKI and does not create ROAs.
> 
> APNIC accidentally issues an incorrect AS 0 ROA for 2001:db8:8000::/33, 
> taking down some fraction (up to half) of ISP Q’s customers and possibly 
> their infrastructure.
> 
> Since there is no AS0 ROA today so let’s focus on your later example. 
> 
> 
>> 
>> Operators network downtime doesn't have any effect on APNIC business as they 
>> can simply say we stuffed up and fixing it.
>> 
>> But think about those networks facing the downtime and their business 
>> obligations to their customers, who will bear this liability. Sure these 
>> operators can drag APNIC to the courts but that costs money that they cannot 
>> afford but accept the stuff ups.
>> 
>> Still you don’t understand how AS0 ROA works and what this policy is trying 
>> to address. If a network operator is using a Bogon (unallocated address 
>> space) then trust me mate that network has no chance defending that case in 
>> any court. In fact APNIC should be dragging these network operators to 
>> court. 
> 
> No, he understands (or at least I don’t see anything to say he doesn’t. 
> However, he and I also understand that we don’t live in a perfect world and 
> we’re talking about what happens when something goes wrong.
> 
> Right now, say APNIC accidentally deletes the above registration from the 
> database… Nothing super bad happens. Some possibility that his RDNS stops 
> working, but his packets still get routed. Some of his RDNS continues to 
> function for a while due to caching, so the damage is potentially 
> significant, but not total.
> 
> Many IXes filtering on valid route objects will stop accepting their 
> prefixes. Many upstreams also filtering on route objects will stop accepting 
> the prefix. Total outage. 

In my experience, these are actually relatively few and far between. Also, 
route objects are usually considered valid if they are present in ANY IRR, not 
necessarily the RIR based IRR.

Anyone can very quickly put just about anything in RADB if they want to. It’s 
also relatively easy to put nearly anything in the current ARIN IRR (not to be 
confused with the ARIN RIR database). There are also some other IRRs that 
accept almost anything at face value.

Finally, route object based filters tend to get updated rather slowly and not 
everyone updates in sync, so it’s a gradually progressing outage that allows 
some reaction time before becoming completely catastrophic.

> OTOH, if APNIC accidentally deletes the registration and issues an AS0 ROA 
> for the entire netback, then you’re (potentially) talking about near total 
> catastrophic routing failure for this ISP and all of his customers.
> 
> Let’s assume they accidentally delete the registration for any reason there 
> are cooling off periods in place which goes up to 60 days or we can put 
> measures in place through policy to have decent cooking off periods. Also 
> let’s talk about stats, how many times how many RIRs have deleted their 
> members by mistake? Do you have any case? 

Honestly, I have no way to know. Such an event would likely not be made 
particularly public. The RIR would consider it confidential to the affected 
party and the affected party would have little motivation to announce it to the 
world after the fact.

>> So I am not in favor of asking the RIR to create AS0 ROA.
>> 
>> Thats absolutely fine we can agree to disagree but let’s have a clear 
>> understanding of the policy. 
> 
> What makes you think he does not understand the policy?
> 
> Because the policy only addresses the bogon, how an address space becomes a 
> bogon is APNIC operating procedure. Do you see the problem of understanding 
> here? 

Yes, but it’s not his. The policy creates new more severe consequences for 
things moving “routable” -> “bogon”. When you increase the consequences of an 
action, it’s often a good idea to review the potential causes of that action 
and consider what avenues exist for erroneous triggers.

> Also it’s seems you are fine with people advertising bogons just because 
> fixing it might make one/two people unhappy. 

I’m not necessarily fine with people advertising bogons, 

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

[Aftab Siddiqui]

On Thu, 29 Aug 2019 at 9:04 am, Owen DeLong  wrote:

>
>
> On Aug 28, 2019, at 13:44 , Aftab Siddiqui 
> wrote:
>
> Hi Javed,
>
> On Thu, 29 Aug 2019 at 6:33 am, Javed Khan 
> wrote:
>
>> We may think we are living in a perfect world but we are not.
>>
>
> of course
>
> With this proposal I'm more worried about the network downtime as managing
>> an AS0 ROA by an RIR may be prone to errors as we all do regardless if its
>> a manual or automated solution.
>>
>
> Would you like to explain how AS0 ROA can create network downtime?
>
>
> One possible way I can think of (I’m sure there are others)…
>
> ISP Q is issued 2001:db8::/32 by APNIC.
>
> ISP Q does not participate in RPKI and does not create ROAs.
>
> APNIC accidentally issues an incorrect AS 0 ROA for 2001:db8:8000::/33,
> taking down some fraction (up to half) of ISP Q’s customers and possibly
> their infrastructure.
>

Since there is no AS0 ROA today so let’s focus on your later example.


>
> Operators network downtime doesn't have any effect on APNIC business as
>> they can simply say we stuffed up and fixing it.
>>
>> But think about those networks facing the downtime and their business
>> obligations to their customers, who will bear this liability. Sure these
>> operators can drag APNIC to the courts but that costs money that they
>> cannot afford but accept the stuff ups.
>>
>
> Still you don’t understand how AS0 ROA works and what this policy is
> trying to address. If a network operator is using a Bogon (unallocated
> address space) then trust me mate that network has no chance defending that
> case in any court. In fact APNIC should be dragging these network operators
> to court.
>
>
> No, he understands (or at least I don’t see anything to say he doesn’t.
> However, he and I also understand that we don’t live in a perfect world and
> we’re talking about what happens when something goes wrong.
>
> Right now, say APNIC accidentally deletes the above registration from the
> database… Nothing super bad happens. Some possibility that his RDNS stops
> working, but his packets still get routed. Some of his RDNS continues to
> function for a while due to caching, so the damage is potentially
> significant, but not total.
>

Many IXes filtering on valid route objects will stop accepting their
prefixes. Many upstreams also filtering on route objects will stop
accepting the prefix. Total outage.

>
> OTOH, if APNIC accidentally deletes the registration and issues an AS0 ROA
> for the entire netback, then you’re (potentially) talking about near total
> catastrophic routing failure for this ISP and all of his customers.
>

Let’s assume they accidentally delete the registration for any reason there
are cooling off periods in place which goes up to 60 days or we can put
measures in place through policy to have decent cooking off periods. Also
let’s talk about stats, how many times how many RIRs have deleted their
members by mistake? Do you have any case?


>
>
>> So I am not in favor of asking the RIR to create AS0 ROA.
>>
>
> Thats absolutely fine we can agree to disagree but let’s have a clear
> understanding of the policy.
>
>
> What makes you think he does not understand the policy?
>

Because the policy only addresses the bogon, how an address space becomes a
bogon is APNIC operating procedure. Do you see the problem of understanding
here?

Also it’s seems you are fine with people advertising bogons just because
fixing it might make one/two people unhappy.


> Owen
>
>
>
>> J Khan
>>
>> --
>> *From:* Aftab Siddiqui 
>> *Sent:* Tuesday, 27 August 2019 6:16 PM
>> *To:* Owen DeLong 
>> *Cc:* Javed Khan ; Policy SIG <
>> sig-pol...@apnic.net>; Sumon Ahmed Sabir 
>>
>> *Subject:* Re: [sig-policy] prop-132-v002: AS0 for Bogons
>>
>> Hi Owen,
>>
>>
>> I don’t think you actually addressed his concern…
>>
>>
>> Well, let me try again then :)
>>
>>
>> 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 

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

[Owen DeLong]

> On Aug 28, 2019, at 13:44 , Aftab Siddiqui  wrote:
> 
> Hi Javed,
> 
> On Thu, 29 Aug 2019 at 6:33 am, Javed Khan  > wrote:
> We may think we are living in a perfect world but we are not.
> 
> of course 
> 
> With this proposal I'm more worried about the network downtime as managing an 
> AS0 ROA by an RIR may be prone to errors as we all do regardless if its a 
> manual or automated solution.
> 
> Would you like to explain how AS0 ROA can create network downtime? 

One possible way I can think of (I’m sure there are others)…

ISP Q is issued 2001:db8::/32 by APNIC.

ISP Q does not participate in RPKI and does not create ROAs.

APNIC accidentally issues an incorrect AS 0 ROA for 2001:db8:8000::/33, taking 
down some fraction (up to half) of ISP Q’s customers and possibly their 
infrastructure.

> 
> Operators network downtime doesn't have any effect on APNIC business as they 
> can simply say we stuffed up and fixing it.
> 
> But think about those networks facing the downtime and their business 
> obligations to their customers, who will bear this liability. Sure these 
> operators can drag APNIC to the courts but that costs money that they cannot 
> afford but accept the stuff ups.
> 
> Still you don’t understand how AS0 ROA works and what this policy is trying 
> to address. If a network operator is using a Bogon (unallocated address 
> space) then trust me mate that network has no chance defending that case in 
> any court. In fact APNIC should be dragging these network operators to court. 

No, he understands (or at least I don’t see anything to say he doesn’t. 
However, he and I also understand that we don’t live in a perfect world and 
we’re talking about what happens when something goes wrong.

Right now, say APNIC accidentally deletes the above registration from the 
database… Nothing super bad happens. Some possibility that his RDNS stops 
working, but his packets still get routed. Some of his RDNS continues to 
function for a while due to caching, so the damage is potentially significant, 
but not total.

OTOH, if APNIC accidentally deletes the registration and issues an AS0 ROA for 
the entire netback, then you’re (potentially) talking about near total 
catastrophic routing failure for this ISP and all of his customers.

> 
> 
> So I am not in favor of asking the RIR to create AS0 ROA.
> 
> Thats absolutely fine we can agree to disagree but let’s have a clear 
> understanding of the policy. 

What makes you think he does not understand the policy?

Owen

> 
> 
> J Khan
> 
> From: Aftab Siddiqui  >
> Sent: Tuesday, 27 August 2019 6:16 PM
> To: Owen DeLong mailto:o...@delong.com>>
> Cc: Javed Khan mailto:javedkha...@outlook.com>>; 
> Policy SIG mailto:sig-pol...@apnic.net>>; Sumon Ahmed 
> Sabir mailto:sasa...@gmail.com>>
> 
> Subject: Re: [sig-policy] prop-132-v002: AS0 for Bogons
>  
> Hi Owen,
>  
> I don’t think you actually addressed his concern…
> 
> Well, let me try again then :) 
>  
>> 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.
> 
> There are only few reasons why APNIC would remove a valid ROA from member's 
> account.
> - Due to Non-payment and APNIC reclaiming the resources and closing the 
> account
> - Returned address space by the member for any reason and the space becomes 
> part of free pool. 
> 
> In either case there are some cooling off period as I shared in previous 
> email which goes up to 60 days before APNIC can mark those resources as 
> 

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

[Aftab Siddiqui]

Hi Javed,

On Thu, 29 Aug 2019 at 6:33 am, Javed Khan  wrote:

> We may think we are living in a perfect world but we are not.
>

of course

With this proposal I'm more worried about the network downtime as managing
> an AS0 ROA by an RIR may be prone to errors as we all do regardless if its
> a manual or automated solution.
>

Would you like to explain how AS0 ROA can create network downtime?

Operators network downtime doesn't have any effect on APNIC business as
> they can simply say we stuffed up and fixing it.
>
> But think about those networks facing the downtime and their business
> obligations to their customers, who will bear this liability. Sure these
> operators can drag APNIC to the courts but that costs money that they
> cannot afford but accept the stuff ups.
>

Still you don’t understand how AS0 ROA works and what this policy is trying
to address. If a network operator is using a Bogon (unallocated address
space) then trust me mate that network has no chance defending that case in
any court. In fact APNIC should be dragging these network operators to
court.


> So I am not in favor of asking the RIR to create AS0 ROA.
>

Thats absolutely fine we can agree to disagree but let’s have a clear
understanding of the policy.


> J Khan
>
> --
> *From:* Aftab Siddiqui 
> *Sent:* Tuesday, 27 August 2019 6:16 PM
> *To:* Owen DeLong 
> *Cc:* Javed Khan ; Policy SIG <
> sig-pol...@apnic.net>; Sumon Ahmed Sabir 
>
> *Subject:* Re: [sig-policy] prop-132-v002: AS0 for Bogons
>
> Hi Owen,
>
>
> I don’t think you actually addressed his concern…
>
>
> Well, let me try again then :)
>
>
> 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.
>
>
> There are only few reasons why APNIC would remove a valid ROA from
> member's account.
> - Due to Non-payment and APNIC reclaiming the resources and closing the
> account
> - Returned address space by the member for any reason and the space
> becomes part of free pool.
>
> In either case there are some cooling off period as I shared in previous
> email which goes up to 60 days before APNIC can mark those resources as
> free/available. IMO, there is absolutely no reason to have those ROAs in
> place but again this is an operational issue and this policy is not dealing
> with it. But can you suggest any reason when those ROAs should not be
> removed?
>
> 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 

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

[Javed Khan]

We may think we are living in a perfect world but we are not. With this 
proposal I'm more worried about the network downtime as managing an AS0 ROA by 
an RIR may be prone to errors as we all do regardless if its a manual or 
automated solution. Operators network downtime doesn't have any effect on APNIC 
business as they can simply say we stuffed up and fixing it.

But think about those networks facing the downtime and their business 
obligations to their customers, who will bear this liability. Sure these 
operators can drag APNIC to the courts but that costs money that they cannot 
afford but accept the stuff ups.

So I am not in favor of asking the RIR to create AS0 ROA.

J Khan


From: Aftab Siddiqui 
Sent: Tuesday, 27 August 2019 6:16 PM
To: Owen DeLong 
Cc: Javed Khan ; Policy SIG ; 
Sumon Ahmed Sabir 
Subject: Re: [sig-policy] prop-132-v002: AS0 for Bogons

Hi Owen,

I don’t think you actually addressed his concern…

Well, let me try again then :)

On Aug 26, 2019, at 17:17 , Aftab Siddiqui 
mailto:aftab.siddi...@gmail.com>> 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.

There are only few reasons why APNIC would remove a valid ROA from member's 
account.
- Due to Non-payment and APNIC reclaiming the resources and closing the account
- Returned address space by the member for any reason and the space becomes 
part of free pool.

In either case there are some cooling off period as I shared in previous email 
which goes up to 60 days before APNIC can mark those resources as 
free/available. IMO, there is absolutely no reason to have those ROAs in place 
but again this is an operational issue and this policy is not dealing with it. 
But can you suggest any reason when those ROAs should not be removed?

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 

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

[Javed Khan]

PDP is a community driven consensus process agreed by the community not by 
courts nor legal experts. I am confused with your reference to "courts", 
"ilegal" and "legislation". If the intention here to scare the community then 
its truly not required.

I think under the current PDP the Chairs have the right to make a decision 
within the scope and principles and rules as agreed by the community. If the 
Chairs rejected one of your proposal, I'm sure the Chairs would have given you 
a reason and other options. This is between you and the Chairs. These people 
are elected by the community and we trust their decision.

I strongly oppose for an appeal process. We build the networks without any 
"appeal" process and so we can also work together to discuss the proposals.

J Khan


From: sig-policy-boun...@lists.apnic.net  
on behalf of JORDI PALET MARTINEZ 
Sent: Monday, 26 August 2019 6:05 PM
To: Policy SIG 
Subject: Re: [sig-policy] Version 4 of prop-126 PDP Update


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" 
mailto:sig-policy-boun...@lists.apnic.net> 
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:
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

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

[Javed Khan]

Thanks Srinivas. I understand and may be its premature to ask for legal review 
of this proposal but at least if we can get APNIC proposed implementation that 
might help.

J Khan


From: Srinivas Chendi 
Sent: Tuesday, 27 August 2019 7:25 AM
To: Javed Khan 
Cc: mailman_SIG-policy 
Subject: Re: [sig-policy] prop-132-v002: AS0 for Bogons

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 

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

[Javed Khan]

From: sig-policy-boun...@lists.apnic.net  
on behalf of JORDI PALET MARTINEZ 
Sent: Monday, 26 August 2019 6:19 PM
To: Policy SIG 
Subject: Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments


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.


So is anyone breaking the current policy? can you provide examples?



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.


I clearly understand that and I am not speaking for myself nor my organisation.



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.


If the students are connecting to the university infrastructure to access 
resources, university is not breaking the current policy because the address 
space is still used for their infrastructure and not sub-assigned to students.



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.


Indeed everyone use NAT but the policies are not promoting to use NATs. Its a 
choice that the network providers make.



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.


Employees getting addresses from a company is same as students in the 
university, as above.



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.


Ok but RIR regions are not all same and that's why we have an RIR for each 
region. If its corrected in one RIR doesn't mean that other RIR community has 
to follow that. Each RIR community can have its own discussion. Right?


J Khan



Regards,

Jordi

@jordipalet







El 23/8/19 16:01, "Javed Khan" 
mailto:sig-policy-boun...@lists.apnic.net> 
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 
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

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

[Javed Khan]

Yes but the proposed text is not clear. In with the current policy text, LIRs 
are not allowed to make sub-assignments from their assigned address space 
outside of their infrastructure. So I do not support this change in policy.

J Khan


From: sig-policy-boun...@lists.apnic.net  
on behalf of Owen DeLong 
Sent: Saturday, 24 August 2019 12:45 AM
To: Simon Sohel Baroi / Global Business / 01847102243 / 

Cc: Sumon Ahmed Sabir ; Policy SIG 
Subject: Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments

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 / 
mailto:simon.ba...@fiberathome.net>> 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 
mailto:sasa...@gmail.com>> 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