[sig-policy] Re: APNIC EC Endorses Proposal from APNIC 56

[Aftab Siddiqui]

Dear EC.
Since you will be meeting soon in person with the members, I want to raise
this topic again as an APNIC member and also a member of the APNIC
community . While I understand the EC's authority in determining fee
structures without mandatory community input, the community support for a
reduction in IPv6-only assignment fees in response to prop-155 should have
been given some weight while making such decisions.

The choice to limit the concession period to a single year appears to
diverge significantly from the community's preference for a more extended
(read forever) fee reduction. This anticipated measure aimed not only to
boost the broader adoption of IPv6 but also to reflect APNIC’s dedication
to supporting this transition in a way that resonates with the community's
needs and expectations.

Additionally, I am keen to understand the financial modeling that resulted
in the EC's decision, particularly concerning the perceived impact on
APNIC’s revenue. The general consensus within the community was that a fee
reduction for IPv6 assignments would have a minimal effect on the
organization's overall financial health because it was not expected that
000s of members would opt for this option anyway but those who would will
be incentivised, while on the other hand APNIC fee is going to increase
significantly for its member with both address family resources, giving a
boost to the revenue. This belief prompts me to request detailed insights
into the analysis that predicted a revenue-hurting outcome from extending
the concession period. Understanding the specific impacts foreseen on
annual revenue against the benefits of increased IPv6 adoption, (which
remains one of APNIC’s core missions) would be invaluable.

Getting clarity on these points would greatly contribute to a more informed
and constructive discussion during the upcoming Annual General Meeting
(AGM).

I sincerely request that this information be shared with the community and
members specifically ahead of the AGM to facilitate a productive dialogue.
It is important for the members to understand the rationale behind
decisions that are contradicting their consensus based opinion, when such
decisions could influence the pace of IPv6 adoption across our region.

Regards,

Aftab A. Siddiqui


On Wed, 13 Dec 2023 at 11:28, Aftab Siddiqui 
wrote:

> I urge the EC to revisit the decision on the fee waiver. The policy's
> intent was to promote the uptake of PI IPv6 by balancing incentivization
> with the recovery of costs for services provided to resource holders. A
> 12-month fee waiver, unfortunately fails horribly to meet this purpose and
> contradicts APNIC's fundamental goal of accelerating IPv6 adoption. To
> truly drive the shift towards IPv6, we must stop valuing it as if it were
> IPv4 - "a costly asset" - and instead, support its adoption through more
> favorable policies. The policy which the community overwhelmingly supported
> but EC didn't get the essence of it.
>
> Regards,
>
> Aftab A. Siddiqui
>
>
> On Wed, 13 Dec 2023 at 10:29, Srinivas (Sunny) Chendi 
> wrote:
>
>> Dear colleagues
>>
>> The APNIC Executive Council endorsed the proposal, prop-155: IPv6 PI
>> Assignment for Associate Members, at its meeting on 26-28 November 2023.
>>
>> https://www.apnic.net/community/policy/proposals/prop-155/
>>
>> The EC has also decided to waive the fees on IPv6 PI assignments under
>> this policy for a period of 12 months from the date of delegation. After
>> the 12 month period expires, the resources will become chargeable.
>>
>> Next steps
>> --
>> The Secretariat will begin the implementation process and inform the
>> community as soon as it is completed.
>>
>> Regards,
>> Sunny
>>
>> ___
>>
>> Srinivas (Sunny) Chendi (he/him)
>> Senior Advisor - Policy and Community Development
>>
>> Asia Pacific Network Information Centre (APNIC) |  Tel: +61 7 3858 3100
>> PO Box 3646 South Brisbane, QLD 4101 Australia  |  Fax: +61 7 3858 3199
>> 6 Cordelia Street, South Brisbane, QLD  |  http://www.apnic.net
>> ___
>>
>> NOTICE: This email message is for the sole use of the intended
>> recipient(s)
>> and may contain confidential and privileged information. Any unauthorized
>> review, use, disclosure or distribution is prohibited. If you are not the
>> intended recipient, please contact the sender by reply email and destroy
>> all
>> copies of the original message.
>>
>> ___
>> SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
>> To unsubscribe send an email to sig-policy-le...@lists.apnic.net
>>
>
___
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: APNIC EC Endorses Proposal from APNIC 56

[Aftab Siddiqui]

I urge the EC to revisit the decision on the fee waiver. The policy's
intent was to promote the uptake of PI IPv6 by balancing incentivization
with the recovery of costs for services provided to resource holders. A
12-month fee waiver, unfortunately fails horribly to meet this purpose and
contradicts APNIC's fundamental goal of accelerating IPv6 adoption. To
truly drive the shift towards IPv6, we must stop valuing it as if it were
IPv4 - "a costly asset" - and instead, support its adoption through more
favorable policies. The policy which the community overwhelmingly supported
but EC didn't get the essence of it.

Regards,

Aftab A. Siddiqui


On Wed, 13 Dec 2023 at 10:29, Srinivas (Sunny) Chendi 
wrote:

> Dear colleagues
>
> The APNIC Executive Council endorsed the proposal, prop-155: IPv6 PI
> Assignment for Associate Members, at its meeting on 26-28 November 2023.
>
> https://www.apnic.net/community/policy/proposals/prop-155/
>
> The EC has also decided to waive the fees on IPv6 PI assignments under
> this policy for a period of 12 months from the date of delegation. After
> the 12 month period expires, the resources will become chargeable.
>
> Next steps
> --
> The Secretariat will begin the implementation process and inform the
> community as soon as it is completed.
>
> Regards,
> Sunny
>
> ___
>
> Srinivas (Sunny) Chendi (he/him)
> Senior Advisor - Policy and Community Development
>
> Asia Pacific Network Information Centre (APNIC) |  Tel: +61 7 3858 3100
> PO Box 3646 South Brisbane, QLD 4101 Australia  |  Fax: +61 7 3858 3199
> 6 Cordelia Street, South Brisbane, QLD  |  http://www.apnic.net
> ___
>
> NOTICE: This email message is for the sole use of the intended recipient(s)
> and may contain confidential and privileged information. Any unauthorized
> review, use, disclosure or distribution is prohibited. If you are not the
> intended recipient, please contact the sender by reply email and destroy
> all
> copies of the original message.
>
> ___
> SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
> To unsubscribe send an email to sig-policy-le...@lists.apnic.net
>
___
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: New version: prop-154: Resizing of IPv4 assignment for the IXPs

[Aftab Siddiqui]

Hi Sanjeev,

On Sat, 9 Sept 2023 at 22:23, Sanjeev Gupta  wrote:

>
> On Sat, Sep 9, 2023 at 7:07 AM Shaila Sharmin <
> shaila.sharmin@gmail.com> wrote:
>
>
>
>> Any resources assigned under this policy will not be announced in the
>> global routing table (mistakes are exempted) and must be used for IXP
>> peering only, in case otherwise the resources will be revoked by APNIC.
>>
>> Global routability of the delegation outside this policy is left to the
>> discretion of the IXP and its participants.
>>
>
> I am unclear what the two paragraphs above mean, together.
>
> My new IX (BEST!!!-IX) receives a /26.
>
> The first paragraph says I MUST NOT announce this outside the IX LAN.  Or
> else
>
> The second says it is left to my discretion.
>
> What am I missing?
>

You receive a /26 for a new site as per this new policy, you already have a
/24 assigned to your account which is out of the scope of this policy and
can be globally advertised if you want to, you can't advertise anything you
receive under this policy.

First statement says, you can not announce any resource you receive under
this policy

Second statement says, any resource you have received outside this policy
whether its directly from APNIC or through transfer then it is not
restricted to be announced.

I hope that clarifies.
___
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs

[Aftab Siddiqui]

Hi Alamgir,

Just for the sake of clarity, ISPAB-NIX already has a /23 IPv4 address
block and if this IX wants to expand then prop-154 is actually providing a
way to receive up to /22 i.e. 1024 IP addresses. Secondly, BD has 1811 ASN
Delegations to-date so I'm not sure from where you got the 2500 plus
number. Anyways, I still would like to hear your reasoning for opposing
this policy

Regards,

Aftab A. Siddiqui


On Mon, 14 Aug 2023 at 15:01, Md Alamgir Kabir  wrote:

>
> Dear Concern ;
>
> Assalamu Alaikum
> Greetings from NIX-BD !!!
> I'm not really suggesting it. PeeringDB had a nice talk about the stats,
> showing 51 peers not all logged into peering db. Hope everyone will enter
> the peering DB. Bangladesh internet service provider internet company 2500
> plus and more ASN in Bangladesh.I hope you understand. Please feel free
> to contact us for any further information in this regard.
>
> *With Kinds Regards*
> *--*
> *NIX KABIR*
>
> *Mobile Number # +880-1711435267*
> *Skype# kabirrana5*
>
>
>
>
>
> On Mon, Aug 14, 2023 at 5:59 AM Aftab Siddiqui 
> wrote:
>
>> Hi Alamgir,
>>
>> I'm not sure what you are suggesting here, firstly we are not discussing
>> the IXP sustainability though it's a nice topic but of course out of the
>> scope of policy discussion and certainly the proposed policy. The policy
>> does actually provide provision to have up to /22 allocation if an IXP
>> reaches 80% utilization which lets say is 400 Peers. Right now ISPAB-NIX
>> (Bangladesh Internet Service Provider Internet Exchange Trust) has a /23 (
>> 103.161.216./23) IPv4 and /32 (2407:840::/32) IPv6 allocation, from the
>> peeringdb stats it shows there are only 51 peers even the record is not up
>> to date and giving benefit of doubt lets say there are 100 peers, but still
>> there is no way to have more than 400 peers in the near future and even if
>> that happens then you can still get /22 with the new policy.
>>
>> Would you like to elaborate further the reservations you have?
>>
>> Regards,
>>
>> Aftab A. Siddiqui
>>
>>
>> On Fri, 11 Aug 2023 at 16:34, Md Alamgir Kabir 
>> wrote:
>>
>>>
>>> Dear concern;
>>>
>>> Assalamu Alaikum
>>> Greetings from ISPAB-NIX !!!
>>> All IXPs in the world need an experienced representation of how they
>>> operate.
>>> Then the idea of IPv4 can be found in IXP. IXP started in Bangladesh in
>>> 2004. In terms of development, we need to have a plan on what kind of IXP
>>> sustainability should be in our country. Along with that, we should think
>>> about expanding content delivery network (CDN)   to IXPs in our country.
>>> Expanding thinking /23, /22 is not enough.  IXPAB-NIX is planning on
>>> that. IPV4 growth needs to be corrected.Please feel free to contact us for
>>> any further information in this regard.
>>>
>>> *With Kinds Regards*
>>> *--*
>>> *NIX-KABIR*
>>> *Mobile Number # +880-1711435267*
>>> *Skype# kabirrana5*
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Aug 10, 2023 at 9:51 PM Simon Sohel Baroi 
>>> wrote:
>>>
>>>> Alamgir Vai,
>>>>
>>>> Thanks for your valuable inputs and comments.
>>>>
>>>>
>>>>
>>>> *IXP is a small field but its vision works on a much larger scale. In
>>>> terms of PoP-expansion of IXPs depends on market dynamics factors such as
>>>> availability of ISPs, CDNs and Telcos. such as in marginal areas where new
>>>> IXPs will be planned and set up.-> *IXP plays a crucial role in
>>>> Internet architecture.But among the 56 economies, not all markets are the
>>>> same. Some small and some are big. A new IX has the potential to grow
>>>> quickly and handle heavy traffic. IXPAB-NIX (NIX-BD) is an excellent
>>>> instance. We made an effort to provide a step-up approach so that IXPs may
>>>> expand quickly. Additionally, new IXPs should not waste unused IPv4
>>>> Resources.
>>>> Today, obtaining IPV4 resources is fairly simple;however, tomorrow may
>>>> be different.
>>>>
>>>> *The proposal does not in any way promote or assist in the expansion of
>>>> IXP. The default size of IP assignments cannot be /23 to /26 by any means. 
>>>> *
>>>>
>>>>
>>>> *-> *The proposal allows the IXPs to grow bigger and get upto /22,
>>>> where the present policy i

[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs

[Aftab Siddiqui]

n Policy Meeting (OPM) at APNIC 56 on 
>>>> Thursday,
>>>> 14 September 2023.
>>>>
>>>>  https://conference.apnic.net/56/program/program/#/day/8/
>>>>
>>>> We invite you to review and comment on the proposal on the mailing list
>>>>  before the OPM.
>>>>
>>>> The comment period on the mailing list before the OPM is an important part
>>>> of the Policy Development Process (PDP).
>>>> We encourage you to express your views on the proposal:
>>>>
>>>>- Do you support or oppose this proposal?
>>>>- Does this proposal solve a problem you are experiencing? If so,
>>>>  tell the community about your situation.
>>>>- Do you see any disadvantages in this proposal?
>>>>- Is there anything in the proposal that is not clear?
>>>>- What changes could be made to this proposal to make it more
>>>> effective?
>>>>
>>>> Information about this proposal is appended below as well as available
>>>> at:
>>>>
>>>>  http://www.apnic.net/policy/proposals/prop-154
>>>>
>>>> Regards,
>>>> Bertrand, Shaila, and Anupam
>>>> APNIC Policy SIG Chairs
>>>>
>>>>
>>>> ---
>>>>
>>>> prop-154-v001: Resizing of IPv4 assignment for the IXPs
>>>>
>>>> 
>>>>
>>>> Proposer: Simon Sohel Baroi (sba...@gmail.com)
>>>>Aftab Siddiqui
>>>>
>>>>
>>>> 1. Problem statement
>>>> 
>>>> According to APNIC Internet Number Resource Policies ( Ref – APNIC-127,
>>>> Dated: 22 DEC, 2022 ),
>>>> an Internet Exchange Point ( IXP ) is eligible to receive a maximum /23
>>>> of IPv4 and /48 of IPv6
>>>> resources. Usually APNIC assign one /24 to start a new IXP. But from
>>>> analysis through PeeringDB,
>>>> we found most of the places the resources have been under-utilised and
>>>> new
>>>> IXPs are wasting a large
>>>> amount of valuable IPv4 spaces. On the other side there are large IXP,
>>>> who can’t grow due to
>>>> lack of IP resources, where /23 is not enough as the membership number
>>>> is big. The size of the
>>>> minimum and maximum range of IP delegation to new or existing IXPs is
>>>> the main problem in the
>>>> current policy.
>>>>
>>>> Present IXP Status in APAC region from PeeringDB [5] :
>>>>
>>>> +---+---++---+--
>>>> -+
>>>> |  IX Names | Peers | Vs | Peers |  IX
>>>> Names |
>>>> +---+---+ +---+---+
>>>> | BBIX Tokyo|  299  ||   17  |
>>>> BBIX-Thailand |
>>>> +---+---+ +---+---+
>>>> | JPIX TOKYO|  257  ||   3   |
>>>> MekongIX  |
>>>> +---+---+ +---+---+
>>>> | Equinix Tokyo |  131  ||   2   | Equinix
>>>> Mumbai|
>>>> +---+---+ +---+---+
>>>> | JPNAP Tokyo   |  211  ||   13  | npIX
>>>> JWL  |
>>>> +---+---+ +---+---+
>>>> | HKIX  |  296  ||   3   | Vanuatu Internet
>>>> Exchange |
>>>> +---+---+ +---+---+
>>>> | Equinix Hong Kong |  216  ||   4   |
>>>> MyNAP |
>>>> +---+---+ +---+---+
>>>> | Equinix Singapore |  422  ||   25  | DE-CIX Kuala
>>>> Lumpur   |
>>>> +---+---+ +---+---+
>>>> | IIX-Jakarta   |  449  ||   13  |
>>>> IIX-Lampung   |
>>>> +---+---+ +---+---+
>>>> | DECIX-Mumbai  |  446  ||   14  | Decix
>>>> Kolkata   

[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs

[Aftab Siddiqui]

Hi Chris, thanks for your feedback.

On Sun, 13 Aug 2023 at 09:33, Christopher H  wrote:

> Hello Team,
>
> I support parts of this proposal, while I oppose others.
>
> In some economies (to use Australia as an example), there are significant
> numbers of network operators. If an IXP were to start out and then have a
> requirement to re-number and expand, the bigger the IX becomes the harder
> it becomes to renumber. Let's look at MegaIX Sydney, and hypothesise that
> this policy was in place when they were reaching 80% utilisation (204 IP
> addresses) of a /24 subnet. It would be a significant challenge for all 204
> peers, plus the route servers, to renumber and re-establish their peering
> sessions. The more peers you have, the harder it becomes.
>

If I'm setting up an IX in Sydney today justifying a /23 is not a problem
at all but as per the current text it says up to /24 for new allocations "*IXPs
can seek an assignment of up to a /24*". But this can be updated to "*IXPs
can seek an assignment of up to a /23 or current highest allocation size
provided they can provide justification*". This change will address your
concern


>
> Let's look at other economies such as Vanuatu, where they have such a
> small IX. I feel that in circumstances like this, it's not justifiable to
> allocate an entire /24 to an IX which has less than 5 peers. Given the size
> of the economy, it's unlikely (for the foreseeable future) that they will
> see requirements for anything greater than a /26 subnet.
>
> Having said the above, we cannot discriminate economies based on the
> number of participants in delegating assignments. It may be better suited
> to restrict delegations to a /24 then if the need arises to renumber to a
> /23 they are given a 6-month window to return the former holding, and if
> they need to go from a /22 they are given 12 months. Whilst they hold these
> resources during the transition, they are responsible for any membership
> fees.
>

I don't see it as a discrimination, an economy of less than half a million
people can't have more than 15-20 ISPs or enterprises with their own
networks, giving them the right amount of resources to establish and run
the IXP is more important. While we are on the edge of IPv4 running out
from the registry pool it's better to utilize them diligently and make sure
everyone who needs it has some portion of it.

Second change I can propose is to "*reserve /20 for small IXP allocations*"
so we can guarantee a fair allocation to smaller economies in the coming
future.


>
> Regards,
> Christopher H.
>

Regards,

Aftab A. Siddiqui
___
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs

[Aftab Siddiqui]

Hi Owen,


> When we run out, IXPs can move to v6only.
>

"When we run out" - we still have a couple of million IPv4 address space.
When some RIRs ran out, it created an open market. Transfers and M are
still happening and continue to happen, let's wisely use and allocate the
resources.


> The providers on the exchange points can still exchange IPv4 NLRI via IPv6
> peering sessions and forward IPv4 data grams to the correct MAC next-hop
> learned via IPv6 ND.
>
> This is already in widespread use. It’s a bit hacking, but it works and
> doesn’t require additional IPv4 addresses.
>

Can you give me an example of IXP where the peering lan is IPv6 only?


>
> Owen
>
>
Regards,

Aftab A. Siddiqui
___
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs

[Aftab Siddiqui]

Hi Sanjeev bhai :) always good to hear from you.

On Wed, 9 Aug 2023 at 13:48, Sanjeev Gupta  wrote:

> Shaila,
>
> I oppose this, but not because of its details.
>
> We (Operators) cannot have it both ways.  We have been screaming that IPv4
> is over, since at least 2011.  Slicing it finer extends the pain, as well
> as demonstrates to everyone that IPv4 is still a valuable, and required,
> commodity.
>

You know that I absolutely don't disagree with this point, as someone who
started the IPv6 Task Force PK 15yrs still very much enthusiastic about the
"IPv6 only" world but the reality is that it's not going to happen most
likely in my lifetime.  Whether we like it or not, IPv4 is still required
and we just have to make best use of the remaining resources. As you are
very much aware of the situation in this region, most likely ten or so IXPs
in the next decade will use /26 or /25 allocations under this policy but
probably another 10 or so will take the benefit of /22 allocations for
expansion. For the later, the only way for them to expand is to
get/purchase resources from the open market. This policy is actually giving
away IPv4 addresses to those who needs it and get over with it.


>
> Issue what we have. Then stop.  Let us not micromanage this.
>

A little bit more micro-management for a few more years and we will be over
with the last /8. Last time I did the forecast it was around 2025/26 when
we were running out of it, this policy will not change that.



>
>
> --
> Sanjeev Gupta
> +65 98551208   http://sg.linkedin.com/in/ghane
>

Regards,

Aftab A. Siddiqui
___
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs

[Aftab Siddiqui]

Hi Abhishek,


> I oppose this proposal. Expansion of IXPs in terms of Membership and PoPs
> depend upon  factors of market dynamics like availability of ISPs, CDNs and
> Telcos at a particular region where new IXP is to be planned and set up.
> The proposal in no way  promote or help in IXP expansion.
>

You are right, the membership of an IXP depends upon the availability of
ISPs, CDNs and Telcos in that economy. There are 56 economies in the APINC
service region, out of those 33 economies have less than 50 ASNs delegated
to them, even if you add handful of CDNs and/or foreign networks who wants
to peer in that IX, you are still pretty much covered with a single IPv4
/26.


> Further there are IXPs which still operate in L3 architecture and require
> bigger chunk of IP subnets for their operations.
>

First of all, no IXP should operate in L3 architecture. Secondly, the
proposal is not stopping any IXP to operate with a bigger IPv4 allocation
if they can justify it. APNIC still requires you to provide justification
of use even today.


> Restricting the default size of IP assignments from /23 to /26 will
> further delay and hamper the operations.
>

How? Can you please provide some examples?


> Almost all the IXPs  are dual stack (IPv4 and IPv6) and run  BGP
> configurations of v6 as well . So this proposal is irrelevant for IXPs.
>

Dual stack means IPv4 and IPv6, you still need v4 to make it "Dual" stack.
I'm still struggling to understand what is the correlation? If you are
making the point which Sanjeev and Owen made then I totally agree but they
are not talking about dual stack.


>
> Regards.
> Abhishek Gautam
> +919703728000
>
>
>
___
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: New version: prop-150: ROA/whois object with Private,,Reserved and Unallocated (reserved/available) Origin ASN

[Aftab Siddiqui]

Hi Joseph and Vivek,
SLURM was designed for specifically this kind of use case (and others as
well). A ROA with Private ASN has significance for the upstream of that
particular operator and no one else. If I see a ROA with 65530 as origin
but can't see that origin in the routing table then it has no value to me
and will be marked as "not found", whereas if that operator created a ROA
with AS4637 as origin then I can verify that route because AS65530 will be
stripped once announced to other peers by AS4637, since AS4637 has the
direct relation with their downstream customer they should use the SLURM
file.

Please refer to RFC8416 [1]
some ISPs might like to use BGP and the RPKI with private address space
(see [RFC1918], [RFC4193], and [RFC6598]) or private AS numbers (see
[RFC1930] and [RFC6996]).  Local use of private address space and/or AS
numbers is consistent with the RFCs cited above, but such use cannot be
verified by the global RPKI.  This motivates creation of mechanisms that
enable a network operator to publish, at its discretion, an exception to
the RPKI in the form of filters and additions (for its own use and that of
its customers).  Additionally, a network operator might wish to make use of
a local override capability to protect routes from adverse actions
[RFC8211], until the results of such actions have been addressed.  The
mechanisms developed to provide this capability to network operators are
hereby called "Simplified Local Internet Number Resource Management with
the RPKI (SLURM)".

[1] - RFC 8416: Simplified Local Internet Number Resource Management with
the RPKI (SLURM) (rfc-editor.org) <https://www.rfc-editor.org/rfc/rfc8416>

Regards,

Aftab A. Siddiqui


On Thu, 23 Feb 2023 at 13:08, Arino, Joseph 
wrote:

> Hi Aftar and all,
>
>
>
> I am interested on this topic coz we have similar cases where our customer
> (using Private ASN) who advertised their own IP block to us (AS4637) via
> eBGP.
>
>
>
> Thank you.
>
>
>
>
>
> *Joseph Kenneth Arino*
>
> IP Engineering, Telstra (AS4637)
>
>
>
> *From:* Aftab Siddiqui 
> *Sent:* Wednesday, February 22, 2023 6:36 PM
> *To:* Satoru Tsurumaki 
> *Cc:* sig-policy 
> *Subject:* [sig-policy] Re: New version: prop-150: ROA/whois object with
> Private,,Reserved and Unallocated (reserved/available) Origin ASN
>
>
>
> You don't often get email from aftab.siddi...@gmail.com. Learn why this
> is important <https://aka.ms/LearnAboutSenderIdentification>
>
>
>
> [External Email] This email was sent from outside the organisation – be
> cautious, particularly with links and attachments.
>
> Thanks to George I saw the recording of policy webinar,
>
>
>
> Hi vivek, can you share more details about the incident where an operator
> gave a reason to create a ROA with private ASN?
>
>
>
> RFC1930 - Guidelines for creation of an AS - Section 10
> Reserved AS Numbers
> The Internet Assigned Numbers Authority (IANA) has reserved the following
> block of AS numbers for private use (not to be advertised on the global
> Internet):
>
> RFC6996 -  Autonomous System (AS) Reservation for Private Use - Section 4.
>
> Operational Considerations
>
> If Private Use ASNs are used and prefixes originate from these
> ASNs, Private Use ASNs MUST be removed from AS path attributes
> (including AS4_PATH if utilizing a four-octet AS number space) before
> being advertised to the global Internet.
>
>
>
>
>
>
>
> Regards,
>
> Aftab A. Siddiqui
>
>
>
>
>
> On Tue, 21 Feb 2023 at 22:43, Satoru Tsurumaki  wrote:
>
> Dear Colleagues,
>
> I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.
>
> I would like to share key feedback in our community for prop-150,
> based on a meeting we organised on 15th Feb to discuss these proposals.
>
> The Various opinions were expressed about this proposal.
>
>
> (comment details)
>  - I support this proposal if it not cause the increasing APNIC's load.
>
>  - I beleive that ROA and whois should be discussed separately,
>since what is required for RoA and whois is different
>in terms of accuracy, etc.
>
>  - Essentially, APNIC should not allow such strange registrations.
>
>
> Regards,
>
> Satoru Tsurumaki / JPOPF Steering Team
>
> 2023年1月30日(月) 9:55 Bertrand Cherrier :
>
> >
> > Dear SIG members,
> >
> > A new version of the proposal "prop-150: ROA/whois object with Private,
> > Reserved and Unallocated (reserved/available) Origin ASN" has been sent
> to
> > the Policy SIG for review.
> >
> > It will be presented at the Open Policy Meeting (OPM) at APNIC 55 on
> > Wednesday, 1 March 2023.
> >
> > https://conference.a

[sig-policy] Re: prop-151-v001: Restricting non hierarchical as-set

[Aftab Siddiqui]

Hi Vivek and Anupam b,
On the point that why the policy will not be enforced on the existing
non-hierarchical AS-SET as mentioned in the impact section.

6. Impact on resource holders
-
APNIC has to request members to update their non hierarchical as-set
as a new recommended policy. No changes will be enforced to existing
non hierarchical as-set.

The purpose of this policy is to make sure that no APNIC member
intentionally or unintentionally create an unauthenticated AS-SET, while
the existing non-hierarchical AS-SET pose security issue for AS-SET holder
but it doesn't create any problem for any other resource holders. Thats why
it should be informed to all resource holders that their AS-SETs are
vulnerable to name collision attacks from other non-authenticated IRR
databases but APNIC shouldn't delete them.

Regards,

Aftab A. Siddiqui


On Wed, 22 Feb 2023 at 10:13, Aftab Siddiqui 
wrote:

> Hi Satoru san,
> I appreciate the feedback from the JP community. I do understand some of
> the points you have raised, I will be doing a detailed technical
> presentation during the Routing Security SIG to discuss most of the issues
> you have raised here. I would request you and other friends from the
> community to attend the routing security SIG.
>
> Regards,
>
> Aftab A. Siddiqui
>
>
> On Tue, 21 Feb 2023 at 22:43, Satoru Tsurumaki  wrote:
>
>> Dear Colleagues,
>>
>> I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..
>>
>> I would like to share key feedback in our community for prop-151,
>> based on a meeting we organised on 15th Feb to discuss these proposals.
>>
>> Many participants support the intent of this proposal, but do not believe
>> it should be discussed in Policy SIG.
>>
>> (comment details)
>> - I agree with the purpose of the proposal, but I wonder if it is not
>>   something that should be discussed in the sig policy.
>>
>> - I think the problem is how to determine which AS number to permit.
>>
>> - I do not oppose this proposal, but I do not think we should have
>>   excessive expectations of IRR.
>>
>>  - This proposal should be discussed globally by MANRS or others,
>>not by APNIC Policy SIG.
>>
>> Regards,
>>
>> Satoru Tsurumaki / JPOPF Steering Team
>>
>> 2023年1月20日(金) 9:25 Bertrand Cherrier :
>>
>>
>> >
>> > Dear SIG members,
>> >
>> > The proposal "prop-151: Restricting non hierarchical as-set" has been
>> > sent to
>> > the Policy SIG for review.
>> >
>> > It will be presented at the Open Policy Meeting (OPM) at APNIC 55 on
>> > Wednesday, 1 March 2023.
>> >
>> > https://conference.apnic.net/55/program/schedule/#/day/10
>> >
>> > We invite you to review and comment on the proposal on the mailing list
>> > before the OPM.
>> >
>> > The comment period on the mailing list before the OPM is an important
>> > part of the Policy Development Process (PDP). We encourage you to
>> > express your views on the proposal:
>> >
>> >- Do you support or oppose this proposal?
>> >- Does this proposal solve a problem you are experiencing? If so,
>> >  tell the community about your situation.
>> >- Do you see any disadvantages in this proposal?
>> >- Is there anything in the proposal that is not clear?
>> >- What changes could be made to this proposal to make it more
>> effective?
>> >
>> > Information about this proposal is appended below as well as available
>> at:
>> >
>> > http://www.apnic.net/policy/proposals/prop-151
>> >
>> > Regards,
>> > Bertrand, Shaila, and Anupam
>> > APNIC Policy SIG Chairs
>> >
>> >
>> > 
>> >
>> > prop-151-v001: Restricting non hierarchical as-set
>> >
>> > 
>> >
>> > Proposer: Aftab Siddiqui (aftab.siddi...@gmail.com)
>> >
>> >
>> > 1. Problem statement
>> > 
>> > An as-set (RFC 2622 Section 5.1) provides a way to document the
>> > relationship between ASes which can then be publicly verified. RFC2622
>> > further defines 2 categories for as-set which can be Hierarchical or Non
>> > Hierarchical. A hierarchical set name is a sequence of set names and AS
>> > numbers separated by colons ‘:’ e.g. AS4826:AS-VOCUS
>> >
>> > Non hierarchical as-s

[sig-policy] Re: New version: prop-150: ROA/whois object with Private,,Reserved and Unallocated (reserved/available) Origin ASN

[Aftab Siddiqui]

Thanks to George I saw the recording of policy webinar,

Hi vivek, can you share more details about the incident where an operator
gave a reason to create a ROA with private ASN?

RFC1930 - Guidelines for creation of an AS - Section 10
Reserved AS Numbers
The Internet Assigned Numbers Authority (IANA) has reserved the following
block of AS numbers for private use (not to be advertised on the global
Internet):

RFC6996 -  Autonomous System (AS) Reservation for Private Use - Section 4.
Operational Considerations
If Private Use ASNs are used and prefixes originate from these
ASNs, Private Use ASNs MUST be removed from AS path attributes
(including AS4_PATH if utilizing a four-octet AS number space) before
being advertised to the global Internet.




Regards,

Aftab A. Siddiqui


On Tue, 21 Feb 2023 at 22:43, Satoru Tsurumaki  wrote:

> Dear Colleagues,
>
> I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.
>
> I would like to share key feedback in our community for prop-150,
> based on a meeting we organised on 15th Feb to discuss these proposals.
>
> The Various opinions were expressed about this proposal.
>
>
> (comment details)
>  - I support this proposal if it not cause the increasing APNIC's load.
>
>  - I beleive that ROA and whois should be discussed separately,
>since what is required for RoA and whois is different
>in terms of accuracy, etc.
>
>  - Essentially, APNIC should not allow such strange registrations.
>
>
> Regards,
>
> Satoru Tsurumaki / JPOPF Steering Team
>
> 2023年1月30日(月) 9:55 Bertrand Cherrier :
>
> >
> > Dear SIG members,
> >
> > A new version of the proposal "prop-150: ROA/whois object with Private,
> > Reserved and Unallocated (reserved/available) Origin ASN" has been sent
> to
> > the Policy SIG for review.
> >
> > It will be presented at the Open Policy Meeting (OPM) at APNIC 55 on
> > Wednesday, 1 March 2023.
> >
> > https://conference.apnic.net/55/program/schedule/#/day/10
> >
> > We invite you to review and comment on the proposal on the mailing list
> > before the OPM.
> >
> > The comment period on the mailing list before the OPM is an important
> > part of the Policy Development Process (PDP). We encourage you to
> > express your views on the proposal:
> >
> >- Do you support or oppose this proposal?
> >- Does this proposal solve a problem you are experiencing? If so,
> >  tell the community about your situation.
> >- Do you see any disadvantages in this proposal?
> >- Is there anything in the proposal that is not clear?
> >- What changes could be made to this proposal to make it more
> effective?
> >
> > Information about this proposal is appended below as well as available
> at:
> >
> > http://www.apnic.net/policy/proposals/prop-150
> >
> > Regards,
> > Bertrand, Shaila, and Anupam
> > Chairing the best SIG of all : The APNIC Policy SIG
> >
> >
> >
> ------
> >
> >
> > prop-150-v002: ROA/whois object with Private, Reserved and Unallocated
> > (reserved/available) Origin ASN
> >
> >
> --
> >
> >
> > Proposer: Aftab Siddiqui (aftab.siddi...@gmail.com)
> >
> >
> > 1. Problem statement
> > 
> > Prop-138v2 was converted into a guideline with the understanding that it
> > will help members to understand not to create ROA with Private, Reserved
> > and unallocated ASN range. Unfortunately, there are still ROAs with
> > specified ranges.
> >
> > Additionally, if a member creates a ROA with someone else's ASN as
> > Origin and if APNIC reclaims that ASN due to any policy reason
> > (non-payment, account closure etc) then this leaves a security issue for
> > the member.
> >
> >
> > 2. Objective of policy change
> > -
> > Restrict APNIC members to create ROAs with private, reserved or
> > unallocated ASN. Also, notify members if the Origin ASN in their ROA has
> > been unallocated (reserved/available) and don't automatically renew
> > those ROAs with unallocated (reserved/available) ASN.
> >
> >
> > 3. Situation in other regions
> > -
> > ROAs containing Private and Reserved ASN are visible from APNIC, LACNIC
> > and RIPE NCC region.
> >
> >
> > 4. Proposed policy solution
> > ---
> &g

[sig-policy] Re: prop-151-v001: Restricting non hierarchical as-set

[Aftab Siddiqui]

Hi Satoru san,
I appreciate the feedback from the JP community. I do understand some of
the points you have raised, I will be doing a detailed technical
presentation during the Routing Security SIG to discuss most of the issues
you have raised here. I would request you and other friends from the
community to attend the routing security SIG.

Regards,

Aftab A. Siddiqui


On Tue, 21 Feb 2023 at 22:43, Satoru Tsurumaki  wrote:

> Dear Colleagues,
>
> I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..
>
> I would like to share key feedback in our community for prop-151,
> based on a meeting we organised on 15th Feb to discuss these proposals.
>
> Many participants support the intent of this proposal, but do not believe
> it should be discussed in Policy SIG.
>
> (comment details)
> - I agree with the purpose of the proposal, but I wonder if it is not
>   something that should be discussed in the sig policy.
>
> - I think the problem is how to determine which AS number to permit.
>
> - I do not oppose this proposal, but I do not think we should have
>   excessive expectations of IRR.
>
>  - This proposal should be discussed globally by MANRS or others,
>not by APNIC Policy SIG.
>
> Regards,
>
> Satoru Tsurumaki / JPOPF Steering Team
>
> 2023年1月20日(金) 9:25 Bertrand Cherrier :
>
>
> >
> > Dear SIG members,
> >
> > The proposal "prop-151: Restricting non hierarchical as-set" has been
> > sent to
> > the Policy SIG for review.
> >
> > It will be presented at the Open Policy Meeting (OPM) at APNIC 55 on
> > Wednesday, 1 March 2023.
> >
> > https://conference.apnic.net/55/program/schedule/#/day/10
> >
> > We invite you to review and comment on the proposal on the mailing list
> > before the OPM.
> >
> > The comment period on the mailing list before the OPM is an important
> > part of the Policy Development Process (PDP). We encourage you to
> > express your views on the proposal:
> >
> >- Do you support or oppose this proposal?
> >- Does this proposal solve a problem you are experiencing? If so,
> >  tell the community about your situation.
> >- Do you see any disadvantages in this proposal?
> >- Is there anything in the proposal that is not clear?
> >- What changes could be made to this proposal to make it more
> effective?
> >
> > Information about this proposal is appended below as well as available
> at:
> >
> > http://www.apnic.net/policy/proposals/prop-151
> >
> > Regards,
> > Bertrand, Shaila, and Anupam
> > APNIC Policy SIG Chairs
> >
> >
> > 
> >
> > prop-151-v001: Restricting non hierarchical as-set
> >
> > 
> >
> > Proposer: Aftab Siddiqui (aftab.siddi...@gmail.com)
> >
> >
> > 1. Problem statement
> > 
> > An as-set (RFC 2622 Section 5.1) provides a way to document the
> > relationship between ASes which can then be publicly verified. RFC2622
> > further defines 2 categories for as-set which can be Hierarchical or Non
> > Hierarchical. A hierarchical set name is a sequence of set names and AS
> > numbers separated by colons ‘:’ e.g. AS4826:AS-VOCUS
> >
> > Non hierarchical as-set pose a security issue where any one can create
> > an as-set without any authentication or authorisation e.g. any member
> > can create AS-FACEBOOK (if available) without authorisation from
> > Facebook. Since many peering filters are based on as-set, creating a
> > blank as-set or as-set with wrong members can cause automated filters to
> > apply empty prefix-filters to BGP session.
> >
> >
> > 2. Objective of policy change
> > -
> > Restrict APNIC members to create non hierarchical as-set and notify all
> > members who already have non hierarchical as-set that it is recommended
> > to move them to hierarchical as-set.
> >
> >
> > 3. Situation in other regions
> > -
> > - RIPE NCC has recently implemented restriction of non hierarchical
> as-set
> > - LACNIC IRR supports only hierarchical as-set
> >
> >
> > 4. Proposed policy solution
> > ---
> > APNIC members are only allowed to create hierarchical as-set. As defined
> > in the RFC2622 Section 5 "A hierarchical set name is a sequence of set
> > names and AS numbers separated by colons ":". At least one component of
> > such a name must be an ac

[sig-policy] Re: Join the APNIC 55 Policy Proposals Webinar

[Aftab Siddiqui]

Accept my apologies, I won't be joining the webinar due to other prior
commitments. If anyone would like to understand more about prop-150
 and prop-151
 proposals
please let me know via mailing list or you can send an email to me for any
questions/concerns you have.

prop-150: ROA/whois object with Private, Reserved and Unallocated
(reserved/available) Origin ASN
prop-151: Restricting non-hierarchical as-set

Regards,

Aftab A. Siddiqui


On Sat, 11 Feb 2023 at 14:36, Bertrand Cherrier  wrote:

> Dear Colleagues,
>
>
>
> Policy SIG is organizing an open webinar for the authors of the policy
>
> proposals to be discussed at the APNIC 55 Open Policy Meeting (OPM).
>
>
>
> The purpose of the webinar is to provide an opportunity for the authors
>
> to share their policy proposals with the community and for the community
>
> to provide feedback to the authors, if any.
>
>
>
> We invite you to join this webinar on:
>
>
>
>  Date: Thursday, 16 February 2023
>
>  Time: 14:00 (UTC +10)
>
>  Duration: 1 hour
>
>
>
> The webinar is open to anyone who wishes to participate. If you are
>
> interested, please register here to join.
>
>  https://apnic.zoom.us/webinar/register/WN_9P4bLuskRhOUvdxN132CEw
>
> After registering, you will receive a confirmation email containing
>
> information about joining the session.
>
>
>
> Useful links for reference:
>
>
>
> - APNIC 55 Policy Proposals
>
>   https://conference.apnic.net/55/policy/proposals/
>
>  - APNIC Policy SIG
>
>   https://www.apnic.net/community/policy/policy-sig/
>
> We look forward to seeing you online.
>
>
>
> Regards,
>
> Bertrand, Shaila, and Anupam
> APNIC Policy SIG Chairs
> ___
> sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
> To unsubscribe send an email to sig-policy-le...@lists.apnic.net
___
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: prop-149-v001: Change of maximum delegation for less than /21 total IPv4 holdings

[Aftab Siddiqui]

Thanks Sanjaya/Secretariat for the quick response.

So it's a bad idea.

Regards,

Aftab A. Siddiqui


On Wed, 25 Jan 2023 at 17:55, Sanjaya Sanjaya  wrote:

> Dear all,
>
>
>
> The spreadsheet attached uses data from the delegated extended stats file
> Aftab mentioned below.
>
>
>
> There are 19,365 IPv4 custodians that hold smaller than a /21. These
> include APNIC Members & Non-members, NIR Members, and historical holders.
> Assuming that all of them are eligible and submitted a valid additional /23
> request, then APNIC will need 9,914,880 IPv4 addresses in its pool.
>
>
>
> If we want to limit the eligibility to those who received allocation, say,
> after 28 February 2019 (the date we implemented prop-127 that limits
> delegation size to a /23), then the number of potential claimers goes down
> to 8,537 (= 4,370,944 IPv4 addresses)
>
>
>
> Please note that the spreadsheet does not include IPv6/ASN only custodians
> that holds zero IPv4. If they are eligible, the potential claimer will
> increase by 882.
>
>
>
> I hope this information helps in this policy proposal discussion.
>
>
>
> Regards,
>
> Sanjaya
>
>
>
> *From:* Aftab Siddiqui 
> *Sent:* Wednesday, 25 January 2023 10:04 AM
> *To:* Shubham Agarwal 
> *Cc:* sig-policy@lists.apnic.net
> *Subject:* [sig-policy] Re: prop-149-v001: Change of maximum delegation
> for less than /21 total IPv4 holdings
>
>
>
> Hi Shubham, thanks for providing this data. though it doesn't answer my
> question.
>
>
>
> As per your proposal, please list.
>
> 1. How many existing members will be eligible for extra IPv4 allocation?
>
> 2. How far back to go in the past to start allocating the extra IPv4
> addresses to members who received less than /21?
>
> 3. Assuming everyone opted for a new allocation size, how long will these
> existing IPv4 addresses last?
>
>
>
> You can use the extended delegation file to get the above answers.
> https://ftp.apnic.net/stats/apnic/delegated-apnic-extended-20230125
>
>
>
> Regards,
>
> Aftab A. Siddiqui
>
>
>
>
>
> On Wed, 25 Jan 2023 at 09:48, Shubham Agarwal 
> wrote:
>
> As on date, total number of 24,75,008 IPv4 addresses (9668 number of /24
> blocks) are available and 14,32,832 number of IPv4 addresses (5597 number
> of /24 blocks) are reserved as per stats available here -
> https://ftp.apnic.net/stats/apnic/delegated-apnic-20230124 .
> In last 4 years, the following number of /24 IP blocks were allotted —
>
> 1.  2019 —  10,86,464 (4244 IPv4 pools)
> 2.  2020 —  8,79,872 (3437 IPv4 pools)
> 3.  2021 —  11,52,256 (4501 IPv4 pools)
> 4.  2022 —  12,31,616 (4811 IPv4 pools)
>
> On an average, 4248 number of /24 segments has been allotted by the APNIC
> in last 4 years. And with the current available and reserved pool, APNIC
> can easily allot the IP numbers with the current pace for next ~ 4 years
> (this doesn’t include the pools marked as historical ones).
> The proposed policy will help the smaller organizations (having allocation
> smaller than /21) to get more IP numbers from APNIC, whereas for members
> who already have chunk bigger than /21, have the option to go for the open
> market, if required.
>
> This policy will not lead to hoarding and re-selling as existing APNIC
> policy doesn’t allow transfer/sale of new allocations for next years.
> ___
> sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
> To unsubscribe send an email to sig-policy-le...@lists.apnic.net
>
>
___
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: prop-149-v001: Change of maximum delegation for less than /21 total IPv4 holdings

[Aftab Siddiqui]

Hi Shubham, thanks for providing this data. though it doesn't answer my
question.

As per your proposal, please list.
1. How many existing members will be eligible for extra IPv4 allocation?
2. How far back to go in the past to start allocating the extra IPv4
addresses to members who received less than /21?
3. Assuming everyone opted for a new allocation size, how long will these
existing IPv4 addresses last?

You can use the extended delegation file to get the above answers.
https://ftp.apnic.net/stats/apnic/delegated-apnic-extended-20230125

Regards,

Aftab A. Siddiqui


On Wed, 25 Jan 2023 at 09:48, Shubham Agarwal 
wrote:

> As on date, total number of 24,75,008 IPv4 addresses (9668 number of /24
> blocks) are available and 14,32,832 number of IPv4 addresses (5597 number
> of /24 blocks) are reserved as per stats available here -
> https://ftp.apnic.net/stats/apnic/delegated-apnic-20230124 .
> In last 4 years, the following number of /24 IP blocks were allotted —
>
> 1.  2019 —  10,86,464 (4244 IPv4 pools)
> 2.  2020 —  8,79,872 (3437 IPv4 pools)
> 3.  2021 —  11,52,256 (4501 IPv4 pools)
> 4.  2022 —  12,31,616 (4811 IPv4 pools)
>
> On an average, 4248 number of /24 segments has been allotted by the APNIC
> in last 4 years. And with the current available and reserved pool, APNIC
> can easily allot the IP numbers with the current pace for next ~ 4 years
> (this doesn’t include the pools marked as historical ones).
> The proposed policy will help the smaller organizations (having allocation
> smaller than /21) to get more IP numbers from APNIC, whereas for members
> who already have chunk bigger than /21, have the option to go for the open
> market, if required.
>
> This policy will not lead to hoarding and re-selling as existing APNIC
> policy doesn’t allow transfer/sale of new allocations for next years.
> ___
> sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
> To unsubscribe send an email to sig-policy-le...@lists.apnic.net
___
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: prop-149-v001: Change of maximum delegation for less than /21 total IPv4 holdings

[Aftab Siddiqui]

I would request authors to share the modeling/expected growth chart for /21
delegation for "ALL" members with less than 2048 v4 addresses and when will
we run out of v4?

Regards,

Aftab A. Siddiqui


On Fri, 20 Jan 2023 at 11:23, Bertrand Cherrier  wrote:

> Dear SIG members,
>
> The proposal "prop-149: Change of maximum delegation for less than /21
> total
> IPv4 holdings" has been sent to the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting (OPM) at APNIC 55 on
> Wednesday, 1 March 2023.
>
> https://conference.apnic.net/55/program/schedule/#/day/10
>
> We invite you to review and comment on the proposal on the mailing list
> before the OPM.
>
> The comment period on the mailing list before the OPM is an important
> part of the Policy Development Process (PDP). We encourage you to
> express your views on the proposal:
>
>- Do you support or oppose this proposal?
>- Does this proposal solve a problem you are experiencing? If so,
>  tell the community about your situation.
>- Do you see any disadvantages in this proposal?
>- Is there anything in the proposal that is not clear?
>- What changes could be made to this proposal to make it more effective?
>
> Information about this proposal is appended below as well as available at:
>
> http://www.apnic.net/policy/proposals/prop-149
>
> Regards,
> Bertrand, Shaila, and Anupam
> APNIC Policy SIG Chairs
>
>
> -
>
>
>
> prop-149-v001: Change of maximum delegation for less than /21 total IPv4
> holdings
>
> -
>
>
>
> Proposer: Shubham Agarwal (shubham8a...@gmail.com)
>Gaurav Kansal gaurav.kan...@nic.in
>
>
> 1. Problem statement
> 
> Over the last three years, no more than 8,00,000 IPv4 addresses have
> been reassigned in a single year.
>
> Status of IPv4 Allocation by APNIC in 2022:
>
> Available Pool: 2,593,792 IPv4 Address | about 5,066 Of /23
> Reserved Pool: 1,702,144 IPv4 Address | about 3,300 Of /23
>
> A sizable portion of the IPv4 pool is 'available+reserved' at APNIC. If
> APNIC continues to delegate /23
> IPv4 at its current rate of 145 x /23 delegations per month, the pool
> will be depleted by the end of 2027.
>
> This implies that a significant portion of the IPv4 address space will
> remain available or unallocated
> for an extended period of time, and that a sizable community may
> continue to face resource shortages.
>
> This is a proposal to give APNIC account holders with fewer than /21
> delegated IPv4 resources (i.e. fewer
> than 2,048 IPs) access to an additional /23 IPv4 address block.
>
>
> 2. Objective of policy change
> -
> According to the current IPv4 allocation policy, APNIC account holders
> are only qualified to receive IPv4
> address delegations totaling a maximum of 512 (/23) from the APNIC 103/8
> IPv4 address pool. The current
> minimum delegation size for IPv4 is 256 (/24) addresses. It is as per
> APNIC defined current minimum and
> maximum IPv4 delegation policy.
>
> Thus, this proposal permits account holders to use an additional /23 if
> their total number of delegated
> IPv4 addresses is fewer than 2,048 (less than /21).
>
> Due to the increase in the maximum IPv4 delegation size from 512 (/23)
> to 1024 (/23 + /23) address pool,
> the number of IPv4 address resources will increase for new and existing
> APNIC account holders with a
> total number of delegated IPv4 addresses less than 2,048 (less than /21).
>
>
> 3. Situation in other regions
> -
> Other RIR regions do not have a similar policy in place.
>
>
> 4. Proposed policy solution
> ---
> Current Policy text:
>
> Since Thursday, 28 February 2019, each APNIC account holder is only
> eligible to receive IPv4 address
> delegations totaling a maximum /23 from the APNIC 103/8 IPv4 address pool.
>
> Proposed Policy text:
>
> New APNIC account holders are eligible to receive a maximum 1024 (/22)
> from the APNIC available IPv4 address pool.
> Current APNIC account holders with less than /21 total IPv4 resources,
> are eligible to recieve an additional /23 IPv4 delegation and must be
> requested.
> Account holders with total IPv4 resources equal to and more than /21 are
> not eligible for further IPv4 delegations.
>
> This policy will be in effect till APNIC runs out of all IPv4 addresses.
>
>
> 5. Advantages / Disadvantages
> -
> Advantages:
> - This proposal allows for more IPv4 addresses to be received.
> - This proposal increases the total number of IPv4 addresses that can be
> made available to networks, developing
> nations, small and medium-sized businesses (SMBs), etc.
>
> Disadvantages:
> - No disadvantages are foreseen.
>
>
> 6. Impact on resource holders
> -
> It increases the maximum size of a 

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[Aftab Siddiqui]

Yesterday, Kohli played an amazing inning, even some of his biggest critics
couldn't resist praising his efforts. 122 with a strike rate of 200 against
a quality attack is remarkable, a true King. Let's not even talk about what
happened a night before with back to back sixes. On the other side of the
world Zampa proved himself to be the right contender as the top leggy.

doesn't make any sense? wondering what I'm talking about and what is the
connection? don't worry, I have the same feeling after reading this email.

Have a nice weekend.

Regards,

Aftab A. Siddiqui


On Fri, 9 Sept 2022 at 18:13, Lu Heng  wrote:

> Aftab:
>
> Any of APNIC document can not be outside scope of law.
>
> Or you suggesting that clause will except APNIC from rule of law?
>
> On Fri, 9 Sept 2022 at 16:01, Aftab Siddiqui 
> wrote:
>
>> Hi Lu,
>>
>> On Fri, 9 Sept 2022 at 16:35, Lu Heng  wrote:
>>
>>> Hi Andrew:
>>>
>>> No, I did not say the registrar has no power to enforce its own contract.
>>>
>>> I am saying the power in such a contract is very limited.
>>>
>>> And policies being made here can not dump out of legal limitation of a
>>> contract.
>>>
>>
>> IANAL, but just for your information.
>>
>> Membership Agreement
>> The Member must:
>> 3.2 (d) Comply with this agreement and all APNIC Documents.
>>
>> All policies once approved and implemented become part of the APNIC
>> documents and that's why they become part of the membership agreement.
>>
>> Anyways, we were discussing the merit of the policy on technical and
>> operational grounds not on political grounds or business interest.
>>
>>
>> Regards,
>>
>> Aftab A. Siddiqui
>>
>>
>
> --
> --
> Kind regards.
> Lu
>
>
___
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[Aftab Siddiqui]

Hi Lu,

On Fri, 9 Sept 2022 at 16:35, Lu Heng  wrote:

> Hi Andrew:
>
> No, I did not say the registrar has no power to enforce its own contract.
>
> I am saying the power in such a contract is very limited.
>
> And policies being made here can not dump out of legal limitation of a
> contract.
>

IANAL, but just for your information.

Membership Agreement
The Member must:
3.2 (d) Comply with this agreement and all APNIC Documents.

All policies once approved and implemented become part of the APNIC
documents and that's why they become part of the membership agreement.

Anyways, we were discussing the merit of the policy on technical and
operational grounds not on political grounds or business interest.


Regards,

Aftab A. Siddiqui
___
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[Aftab Siddiqui]

skipping the other bits..

If there is not a direct link from an LIR to a customer, then is not a
> direct connectivity. So, in that case is not tied to a connectivity service.
>
>
>

I have a simple question, is this an example of leasing or not?
103.93.157.0/25 allocated to an entity with 2 ASNs (AS149847 and AS136594)
but it is announced by AS32787. The original entite ASNs are not in the
path at all.

103.93.157.0/24* and 103.114.130.0/24*
apnic|AU|ipv4|103.93.156.0|512|20170523|allocated|A91A0031
apnic|AU|ipv4|103.114.130.0|512|20180427|assigned|A91A0031
apnic|AU|asn|149847|1|20220526|allocated|A91A0031
apnic|AU|asn|136594|1|20170523|allocated|A91A0031

N*> 103.93.157.0/24  169.254.169.25450  0 64515 65534
20473 *32787* i
N*> 103.114.130.0/24 169.254.169.25450  0 64515 65534
20473 *32787* i

Answer to this question is important because you are mixing business and
operational practices.
___
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[Aftab Siddiqui]

Hi Jordi,

On Thu, 8 Sept 2022 at 20:44, JORDI PALET MARTINEZ via sig-policy <
sig-policy@lists.apnic.net> wrote:

> Hi Aftab,
>
>
>
> It is not a matter of who announces them, but if they are connected to the
> original resource holder, so then the addresses are part of the
> connectivity service.
>

I gave you 3 clear cases where the custodians of resources have no direct
connection as per the routing entries, there is no "connectivity service"
here and who will define what is connectivity service?. This is what Andrew
and Bret have highlighted several times in this discussion which you have
failed to respond to.

Regards,

Aftab A. Siddiqui


>
>
>
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 8/9/22, 3:22, "Aftab Siddiqui"  escribió:
>
>
>
> Hey Jordi,
>
>
>
> On Wed, 7 Sept 2022 at 23:45, JORDI PALET MARTINEZ via sig-policy <
> sig-policy@lists.apnic.net> wrote:
>
> Looking into English dictionaries and trying to make something specific to
> our case. Maybe:
>
>
>
> Providing Internet Number Resources for a price (paid in any form) or even
> for free, when not tied to a direct connectivity service.
>
>
>
>
>
> So do you want to reclaim the following resources from their respective
> custodians as it is announced by an unrelated entity?
>
>
>
> 103.93.157.0/24* and 103.114.130.0/24*
> apnic|AU|ipv4|103.93.156.0|512|20170523|allocated|A91A0031
> apnic|AU|ipv4|103.114.130.0|512|20180427|assigned|A91A0031
> apnic|AU|asn|149847|1|20220526|allocated|A91A0031
> apnic|AU|asn|136594|1|20170523|allocated|A91A0031
>
> N*> 103.93.157.0/24  169.254.169.25450  0 64515 65534
> 20473 *32787* i
> N*> 103.114.130.0/24 169.254.169.25450  0 64515 65534
> 20473 *32787* i
>
>
> 103.81.228.0/24 *
> apnic|SG|ipv4|103.81.228.0|256|20161219|assigned|A91E3136
>
> N*> 103.81.228.0/24  169.254.169.25450  0 64515 65534
> 20473 *13335* i
>
> 1.1.1.0/24 and 1.0.0.0/24 *
> apnic|AU|ipv4|1.1.1.0|256|20110811|assigned|A91872ED
> apnic|AU|ipv4|1.0.0.0|256|20110811|assigned|A91872ED
> apnic|AU|asn|9838|1|20100203|allocated|A91872ED
> apnic|AU|asn|24021|1|20080326|allocated|A91872ED
> apnic|JP|asn|38610|1|20070716|allocated|A91872ED
> apnic|AU|asn|131072|1|20070117|allocated|A91872ED
> apnic|AU|asn|131074|1|20070115|allocated|A91872ED
>
> V*  1.1.1.0/24   103.126.52.155 0 141384 4826
> *13335* i
>
>
>
> *APNIC delegate file
> <http://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-extended-latest>
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 7/9/22, 15:35, "Mike Burns"  escribió:
>
>
>
> Hello,
>
>
>
> If we don't have a definition of Leasing we can't fully consider the
> issues of enforcement, among other items.
>
>
>
> As with many things the devil is in the details.
>
>
>
> Regards,
>
>
>
> Mike
>
>
>
>
>
>
>
>
>
>
>
>
>
> Sent from my T-Mobile 4G LTE Device
>
>
>
>
>
>  Original message 
>
> From: JORDI PALET MARTINEZ via sig-policy 
>
> Date: 9/7/22 8:54 AM (GMT-05:00)
>
> To: sig-policy 
>
> Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing
> of Resources is not Acceptable
>
>
>
> Hi Brett,
>
>
>
> I’m not saying that I reject a definition, what I’m saying is that I don’t
> think is needed, despite that I’m happy to include it if we agree on that,
> as can’t be other way, as this is the way we write proposals: understanding
> what the community want (not just the authors).
>
>
>
> I’ve not been able to see the video of the discussion. Is it available?
> Maybe the staff can provide it, so I can better understand all the points?
>
>
>
> Could you suggest a wording of leasing according to you view, to see if we
> can make it happen?
>
>
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 7/9/22, 14:41, "Brett O'Hara"  escribió:
>
>
>
> Hi Jordi,
>
>
>
> You have stated that you do need a definition because "any form of leasing
> is unacceptable", and yet I was verbally assured at the APNIC 54 Policy 
> Proposals
> Webinar on the 25th of August, that several examples of leasing were
> acceptable, but not documented in the proposal.  My request for a
> definition in the proposal was positively received by the SIG and we left
> the issue to the authors.  If the response from the 

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[Aftab Siddiqui]

Hey Jordi,

On Wed, 7 Sept 2022 at 23:45, JORDI PALET MARTINEZ via sig-policy <
sig-policy@lists.apnic.net> wrote:

> Looking into English dictionaries and trying to make something specific to
> our case. Maybe:
>
>
>
> Providing Internet Number Resources for a price (paid in any form) or even
> for free, when not tied to a direct connectivity service.
>
>
>

So do you want to reclaim the following resources from their respective
custodians as it is announced by an unrelated entity?

103.93.157.0/24* and 103.114.130.0/24*
apnic|AU|ipv4|103.93.156.0|512|20170523|allocated|A91A0031
apnic|AU|ipv4|103.114.130.0|512|20180427|assigned|A91A0031
apnic|AU|asn|149847|1|20220526|allocated|A91A0031
apnic|AU|asn|136594|1|20170523|allocated|A91A0031

N*> 103.93.157.0/24  169.254.169.25450  0 64515 65534
20473 *32787* i
N*> 103.114.130.0/24 169.254.169.25450  0 64515 65534
20473 *32787* i


103.81.228.0/24 *
apnic|SG|ipv4|103.81.228.0|256|20161219|assigned|A91E3136

N*> 103.81.228.0/24  169.254.169.25450  0 64515 65534
20473 *13335* i

1.1.1.0/24 and 1.0.0.0/24 *
apnic|AU|ipv4|1.1.1.0|256|20110811|assigned|A91872ED
apnic|AU|ipv4|1.0.0.0|256|20110811|assigned|A91872ED
apnic|AU|asn|9838|1|20100203|allocated|A91872ED
apnic|AU|asn|24021|1|20080326|allocated|A91872ED
apnic|JP|asn|38610|1|20070716|allocated|A91872ED
apnic|AU|asn|131072|1|20070117|allocated|A91872ED
apnic|AU|asn|131074|1|20070115|allocated|A91872ED

V*  1.1.1.0/24   103.126.52.155 0 141384 4826
*13335* i

*APNIC delegate file



> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 7/9/22, 15:35, "Mike Burns"  escribió:
>
>
>
> Hello,
>
>
>
> If we don't have a definition of Leasing we can't fully consider the
> issues of enforcement, among other items.
>
>
>
> As with many things the devil is in the details.
>
>
>
> Regards,
>
>
>
> Mike
>
>
>
>
>
>
>
>
>
>
>
>
>
> Sent from my T-Mobile 4G LTE Device
>
>
>
>
>
>  Original message 
>
> From: JORDI PALET MARTINEZ via sig-policy 
>
> Date: 9/7/22 8:54 AM (GMT-05:00)
>
> To: sig-policy 
>
> Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing
> of Resources is not Acceptable
>
>
>
> Hi Brett,
>
>
>
> I’m not saying that I reject a definition, what I’m saying is that I don’t
> think is needed, despite that I’m happy to include it if we agree on that,
> as can’t be other way, as this is the way we write proposals: understanding
> what the community want (not just the authors).
>
>
>
> I’ve not been able to see the video of the discussion. Is it available?
> Maybe the staff can provide it, so I can better understand all the points?
>
>
>
> Could you suggest a wording of leasing according to you view, to see if we
> can make it happen?
>
>
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 7/9/22, 14:41, "Brett O'Hara"  escribió:
>
>
>
> Hi Jordi,
>
>
>
> You have stated that you do need a definition because "any form of leasing
> is unacceptable", and yet I was verbally assured at the APNIC 54 Policy 
> Proposals
> Webinar on the 25th of August, that several examples of leasing were
> acceptable, but not documented in the proposal.  My request for a
> definition in the proposal was positively received by the SIG and we left
> the issue to the authors.  If the response from the authors is that the
> definition is not necessary, I can't see how we can endorse the proposal.
>
>
>
> Regards,
>
> Brett
>
>
>
> On Wed, Sep 7, 2022 at 8:30 PM JORDI PALET MARTINEZ via sig-policy <
> sig-policy@lists.apnic.net> wrote:
>
> Hi Satoru, all,
>
> We haven't defined leasing, because it is common English term, not
> something specific to "addresses".  I can understand that in other
> languages, it may not be the same, but because the policies are bound to
> the English language, we didn't feel the need to define it.
>
> In fact, we had a similar discussion about that in LACNIC 6 months ago,
> and we decided to make a new version, which is the same as we published in
> APNIC. The point was to stress that "any form of leasing" is unacceptable.
> If you read that in the context of the policy, it starts, as you already
> mention "own infrastructure or directly connected customers". So, anything
> beyond that will be a form of leasing (never mind if you pay a fee for the
> addresses or they are free of charge, or you pay before you use them or
> afterwards, etc., basically "anything not linked to connectivity").
>
> I don't think the implementation is a problem. We know that many proposals
> come with some challenges, however, the community, anyone, can and should
> help on that. Anyone knowing or getting a leasing offer should communicate
> about that. And by the way, I think will not be so dificult to create an
> automated way of detecting it, just by ensuring that the users of any APNIC
> block is directly connected to the 

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[Aftab Siddiqui]

Hi Jordi,

Have you done any analysis to check how big a problem it is in the APNIC
service region? for example check all (or may be a subset of) the
allocations and assignments by the APNIC along with their allocated ASN(s)
and see if those resources are originating from these ASN(s).

Regards,

Aftab A. Siddiqui


On Wed, 7 Sept 2022 at 20:37, JORDI PALET MARTINEZ via sig-policy <
sig-policy@lists.apnic.net> wrote:

> Yes, I definitively agree with that: The most honorable thing will be to
> return resources that you don’t use for your directly connected customers.
>
>
>
> However, not allowing that when the community accepted it long time ago,
> would have been a failure, because many organizations just look for their
> own interest instead of the global community one.
>
>
>
> In the case of leasing is already not covered by policies, we just want to
> make sure that it is sufficiently clear.
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 2/9/22, 9:23, "Gaurav Kansal"  escribió:
>
>
>
> Hello everyone,
>
>
>
> In my opinion, even Trading of IPs (leave apart the lease for making
> dollars) in the name of transfers must be stopped.
>
> If organisation doesn’t need IPs , then those must be returned back so
> that smaller organisations can get it from the RIR.
>
>
>
> Currently, only the one which have millions of dollars can think of
> getting IPs. In today’s scenario, no one can start the Data Centre, ISP
> business without investing millions in IPs. Even education and research org
> doesn’t have an option to get IPs from RIR.
>
>
>
> This is like horse trading and isn’t a good practice for the community as
> a whole.
>
>
>
> Regards,
>
> Gaurav Kansal
>
>
>
>
>
> On 02-Sep-2022, at 12:20, raj...@smartlinkindia.com wrote:
>
>
>
> Dear Team,
>
>
>
> As Mr. Satoru, mentioned there are changes, but if carefully implemented
> in phased manner, unauthorised leasing can be stopped.
>
>
>
> For example in first phase, leasing among countries can be stopped, if the
> owner company doesn't provide any services beyond its home country. For
> example if a company in India doesn't have any operation in Singapore or
> Japan , can't lease resources to those companies in Singapore or Japan.
> This can be verified by taking business registration documents of both
> lease and lessor.
>
> Once this is done same may be granularized at RIR level, where in country
> like India, leasing can be restricted to the licensed service area for
> service provider within their designated service area.
>
> This may stop majority of issues, barring few exceptions.
>
> Some more brainstorming is required for better understanding and precise
> implementation.
>
>
>
> Regards,
>
>
>
> Rajesh Panwala
>
> For Smartlink Solutions Pvt Ltd
>
> +91-9227886001
>
> +91-9426110781
>
>
>
> On Fri, Sep 2, 2022, 10:44 AM Tsurumaki, Satoru  wrote:
>
> Dear Colleagues,
>
> I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..
>
> I would like to share key feedback in our community for prop-148,
> based on a meeting we organised on 29th Aug to discuss these proposals.
>
> Many participants support the intent of the proposal but felt that
> implementation would be challenging.
>
> (comment details)
> - It is undisputed that the current policy allows for the distribution
>   of IP addresses according to the actual demand of one's own
>   organization or directly connected customers, and does not allow for
>   the leasing of IP addresses.
> - I think this proposal would be useful if the concept of leasing is
> accurately defined.
> - Leasing IP addresses that damage the accuracy of whois information
>   should not be allowed, but I find it difficult to implement.
>
>
> Regards,
>
> Satoru Tsurumaki / JPOPF Steering Team
>
> 2022年8月26日(金) 17:27 Shaila Sharmin :
> >
> > Dear SIG members,
> >
> > A new version of the proposal "prop-148-v002: Clarification - Leasing of
> > Resources is not Acceptable" has been sent to the Policy SIG for review.
> >
> > Information about earlier versions is available from:
> >
> > http://www.apnic.net/policy/proposals/prop-148
> >
> > 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.
> >
> > Regards,
> > Bertrand, Shaila, and Ching-Heng
> > APNIC Policy SIG Chairs
> >
> >
> > --
> > prop-148-v002: Clarification - Leasing of Resources is not Acceptable
> > --
> >
> > Proposer: Jordi Palet Martinez (jordi.palet@theipv6company.comAnupam)
> >Amrita Choudhury (amritachoudh...@ccaoi.in)
> >Fernando Frediani (fhfred...@gmail.com)
> >
> >
> > 1. Problem statement
> > 
> > RIRs have 

[sig-policy] Re: prop-147-v001: Historical Resources Management

[Aftab Siddiqui]

Hi Vivek,

On Mon, 29 Aug 2022 at 18:15, Vivek Nigam  wrote:

> Hi Aftab,
>
>
>
> APNIC creates RPKI ROAs with origin AS0 for all undelegated address space
> (marked as “Available” and “Reserved” in the
> delegated-apnic-extended-latest stats file. It may be worth noting that
> APNIC publishes these AS0 ROAs in a different Trust Anchor (AS0 TAL) and
> recommends its Members use APNIC AS0 TAL as a routing information service
> only.
>
>
>
>
> https://www.apnic.net/community/security/resource-certification/apnic-limitations-of-liability-for-rpki-2/
>
>
>
That is incorrect, there are more than 160 IPv4 prefixes (I haven't checked
v6 yet) which are marked as either "reserved" or "available" in the APNIC
delegation file and they don't exist in AS-0 ROA. So there must be some
policy which is in place.

delegate file: 2.3|apnic|20220830|158240||20220829|+1000
AS0 ROA: SigningTime:2022-08-30T01:10:15Z

Regards,

Aftab A. Siddiqui
___
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: prop-147-v001: Historical Resources Management

[Aftab Siddiqui]

Hi Jordi,
I absolutely concur with Brett and Andrew, they have already mentioned the
reasoning very clearly. I don't support this policy right now and maybe we
can review the status in 12 months and have another constructive
discussion.

Also, it would be a right time to have a clear policy from APNIC to clarify
what and when any (available + reserved) resource goes into AS0 TAL.

Regards,

Aftab A. Siddiqui


On Sat, 27 Aug 2022 at 14:21, Brett O'Hara  wrote:

> Hi Jordi and SIG
>
> The implication of your proposal, by 5.1.4, is that by putting them in
> Reserved status, APNIC will assign them RPKI ROA AS0 and deny them routing
> on the Internet.  You will then allow them 12 months grace after you have
> denied their operation to officially claim them.  Your update from 6 to 12
> months has not allowed APNIC any more time to contact custodians.
>
> I agree with Andrew that the current impact is too large and too damaging
> to internet end point users in your proposed time frame.
>
> I believe APNIC members should asess the progress of the HRM project in 12
> months time and consider your proposal then, rather than mandating in a
> policy final date in this cycle, despite your afore mentioned risks.
>
> Regards,
> Brett
>
> On Fri, Aug 26, 2022 at 10:19 PM JORDI PALET MARTINEZ via sig-policy <
> sig-policy@lists.apnic.net> wrote:
>
>> Hi Andrew, all,
>>
>>
>>
>> I see it otherwise.
>>
>>
>>
>> We are providing APNIC one year to resolve the remaining cases. If we
>> don’t have this policy on January 1st 2023, all those addresses will be
>> “frozen” into reserved status.
>>
>>
>>
>> Please note this:
>>
>>
>>
>> “The recent EC resolution (22nd February 2022), imply that historical
>> resource holders in the APNIC region would need to become Members or
>> Non-Members by 1st January 2023 in order to receive registration
>> services. Failing this, historical resource registration will no longer be
>> published in the APNIC Whois Database and said resources will be placed
>> into reserved status.”
>>
>>
>>
>> Failing to reach consensus on this proposal (suggestions to improve it,
>> of course, are welcome, as we can publish new versions in the next few
>> days), means that we can’t change the situation up to a new alternative
>> proposal reach consensus, which could happen around March 2023, or may be
>> September 2023. Till then those resources are “lost” in the wild.
>>
>>
>>
>> Resources in the wild could be more easily hijacked or used for all kind
>> of malicious activities. Do you think the community should accept that risk?
>>
>>
>>
>> In the impact analysis of the first version, APNIC indicated that 6
>> months may be too short, and 12 months will be safer, so we opted for
>> keeping the 12 months option only. Do you have any data that suggest that
>> APNIC will be unable to complete the project in the next year?
>>
>>
>>
>>
>>
>> Regards,
>>
>> Jordi
>>
>> @jordipalet
>>
>>
>>
>>
>>
>>
>>
>> El 26/8/22, 2:56, "Andrew Yager"  escribió:
>>
>>
>>
>> Hi,
>>
>>
>>
>> Thanks for this data vivek.
>>
>>
>>
>> On the basis of this I cannot suggest this proposal can be accepted - the
>> impact is too large.
>>
>>
>>
>> Certainly we, as a community, and APNIC as a whole, need to look at what
>> can be done to assist these prefixes coming "into the fold" - but with 581
>> still with no response, and 175 "not yet done" - the risk of this proposal
>> having adverse consequences on the routing table is too great.
>>
>>
>>
>> Andrew
>>
>>
>>
>>
>>
>> On Fri, 26 Aug 2022 at 17:45, Vivek Nigam  wrote:
>>
>> Hi Andrew,
>>
>>
>>
>> Please see my responses below.
>>
>>
>>
>> > a) the number of legacy resources currently in use (as in, visible in
>> the global table), but not yet claimed through this process
>>
>>
>>
>> We started this project in February this year and identified 3932
>> historical IPv4 prefixes that were not managed under an APNIC account. 885
>> of these prefixes are currently visible in the routing table. Following if
>> the breakdown of these 885 prefixes.
>>
>>
>>
>> Retained by custodian: 81
>>
>> These prefixes have successfully been claimed and are managed under
>> active APNIC accounts now.
>>
>>
>>
>> Being claimed by custodian: 175
>>
>> We are in contact with the potential custodians and they are in the
>> process of claiming these prefixes.
>>
>>
>>
>> No response: 581
>>
>> We have sent emails to the custodians but have not got a response as yet.
>> We are in the process to find alternate contacts by contacting the ASN
>> announcing these prefixes.
>>
>>
>>
>> Yet to contact: 44
>>
>> No valid contact information available in whois. We are in the process to
>> look for alternate contacts via publicly available searches as well as
>> contacting the ASN announcing these prefixes.
>>
>>
>>
>> No longer needed: 4
>>
>> The custodians have informed us they no longer need these prefixes. We
>> are in the process to contact the ASN announcing these prefixes to check
>> why they are announcing 

[sig-policy] Re: APNIC Nomination Review Committee - Proposal

[Aftab Siddiqui]

On Fri, 26 Aug 2022 at 15:45, Gaurav Kansal  wrote:

>
>
> On 25-Aug-2022, at 12:52, aftab.siddi...@gmail.com wrote:
>
> Hi Gaurav,
> Thanks for your comments
>
> On Thu, 25 Aug 2022 at 16:31, Gaurav Kansal  wrote:
>
>> We should avoid un-limited number of terms for any member in any role,
>> like max 2 consecutive tenure for any post and a cool off period of 2-4
>> years for next tenure and have a max limit on an individual member tenures.
>>
>
> NRC is for review of all elected community nominations. For this
> particular suggestion, you have to change SIG guidelines, NRO-NC election
> procedure and also the APNIC bylaws. This change is out of the scope of NRC
> but your point is taken and NRC can publish the number of years a
> candidate has already served on a particular seat.
>
> For NomCom or NRC, or whatever for this proposal is, don’t it need the
> same approvals, which are required for bringing the reforms in the current
> election processes ? As per the timeline/stages section, it look like this
> document/proposal is pushed from the top to the bottom and set timelines
> are very stringent. Don’t it be better if we have the election and voting
> rights reforms before this NRC/NomCom ?
>

As I mentioned in my previous comments, if you want to change voting
mechanism ("voting rights" doesn't make sense in this discussion) then
there are 3 separate forums for that, SIG guidelines can be changed at
SIGs, NRO-NC election procedure require a separate change proposal and for
EC you need to change APNIC bylaws. If you think that has to be done in
parallel then I would suggest you organise a BoF in the upcoming APNIC54
and share it with community members and if there is a consensus from the
community then a working group can be formed to make that happen. Otherwise
you can come up with a proposal and share it with all SIGs and ask for
their opinion.

Also, what’s the general trend in APNIC w.r.t. proposals ? Is it top-down
> approach or bottom-up approach, as this proposal is first reviewed by the
> top and then shared with the community, so is it a general trend in APNIC ?
> I am considering that APNIC doesn’t think that elected members or the APNIC
> leaders are the only wise members in this region.
>

On your point about top-down approach, I'm not sure what made you think
like that? If it was a top-down process then you would have heard about the
formation of NRC by now with TOR set in stone whereas right now we are
talking about a proposal, an idea which some of the community members
(including me) have been discussing for last few years and finally got the
chance (thanks to lockdowns) to put this into wordings, primary discussion
was with all the chairs/co-chairs of SIGs, NRO-NC, IRC, APIX and APNOG
members - this is what we call elected leadership group, a big enough group
of community representatives who are active and willing to provide
feedback. This document is still a proposal and no decision has been made
yet. Set timelines - yeah because we have a BoF at APNIC54 so its better to
collect as much opinion/comments from the mailing list so we can address it
before the BoF and have a constructive discussion there. I hope that helps
clarify your misconception of top-down approach.


>
>
>
>> This will help in bringing the new blood into the system and will be able
>> to achieve geographical diversity , plus a rotation will be able to help us
>> in catching the flaws/frauds in the very early stages.
>>
>
> If you read the document then you will understand how we are supporting at
> least the geographical diversity in the NRC. While I do support your point
> of geographical diversity, to make it clear Diversity is not about
> geography only and we have to make APNIC more inclusive at every level.
>
> from geographical pov
> EC - 7 members representing 7 different economies
> NRO NC - 3 members 3 different economies
> SIG - Routing Security - 3 members 3 economies
> SIG - Cooperation - 2 members 2 economies
> SIG - NIR - 2 members 2 economies
> SIG - Policy - 3 members 3 economies
>
> Out of these 20 elected members there are at least 15 different economies
> represented here out of 56 economies of APNIC service region.
>
> We have to think and achieve the resilience so that we should be in a same
>> position of AFRINIC.
>>
>
> Any further suggestions to improve the NRC?
>
>
> In one of the discussions, I proposed for building the appropriate
> resilience at various levels of the core institutions of APNIC in order to
> prevent any major disruptions to the operations of APNIC. To start with we
> can explore the feasibility of setting up a regional office of APNIC in any
> other member country and distribute some of the resources of APNIC across
> different geographies, So that any legal/regulatory actions of one host
> country doesn't bring the operations of APNIC to a standstill.
>

I'm not sure what sub-regional offices will do for the resiliency of APNIC.
There are 7 NIRs right now which get the 

[sig-policy] Re: APNIC Nomination Review Committee - Proposal

[Aftab Siddiqui]

Hi Gaurav,
Thanks for your comments

On Thu, 25 Aug 2022 at 16:31, Gaurav Kansal  wrote:

> We should avoid un-limited number of terms for any member in any role,
> like max 2 consecutive tenure for any post and a cool off period of 2-4
> years for next tenure and have a max limit on an individual member tenures.
>

NRC is for review of all elected community nominations. For this particular
suggestion, you have to change SIG guidelines, NRO-NC election procedure
and also the APNIC bylaws. This change is out of the scope of NRC but your
point is taken and NRC can publish the number of years a candidate has
already served on a particular seat.


> This will help in bringing the new blood into the system and will be able
> to achieve geographical diversity , plus a rotation will be able to help us
> in catching the flaws/frauds in the very early stages.
>

If you read the document then you will understand how we are supporting at
least the geographical diversity in the NRC. While I do support your point
of geographical diversity, to make it clear Diversity is not about
geography only and we have to make APNIC more inclusive at every level.

from geographical pov
EC - 7 members representing 7 different economies
NRO NC - 3 members 3 different economies
SIG - Routing Security - 3 members 3 economies
SIG - Cooperation - 2 members 2 economies
SIG - NIR - 2 members 2 economies
SIG - Policy - 3 members 3 economies

Out of these 20 elected members there are at least 15 different economies
represented here out of 56 economies of APNIC service region.

We have to think and achieve the resilience so that we should be in a same
> position of AFRINIC.
>

Any further suggestions to improve the NRC?


Regards,

Aftab A. Siddiqui


>
> On 25-Aug-2022, at 05:38, aftab.siddi...@gmail.com wrote:
>
> Hi Everyone,
>
> As you are aware the current nomination process for any community elected
> position is defined where APNIC secretariat sends the call for nomination
> on various forums and once they (secretariat) receives the nominations an
> internal due diligence process is performed and then the names of nominees
> are published with their details. The process ran so far on a need-to-know
> basis and the community had access to information that was deemed essential
> by the Secretariat. In order to build a strong and community driven
> structure it is important to have community oversight in the whole
> process, which at the moment doesn't exist. For that reason we are
> proposing a new committee called "Nomination Review Committee" and we
> believe that it will bring much needed improvements to the process of
> electing members to various community elected positions.
>
> Please review the proposal here
> 
> and provide your feedback through the mailing list. We are also organising
> a BoF
> 
> on 14th Sep during APNIC54 to further discuss this in-person/online.
>
> BoF:
> https://conference.apnic.net/54/program/schedule/#/day/6/bof---apnic-nominating-committee-nomcom
>
> Link:
> https://docs.google.com/document/d/1w0uANFm5j1qCFCxQR_rXlwyGg_4NXme50J-HcZ0QeQM/edit?usp=sharing
>
>
> Regards,
>
> Aftab A. Siddiqui
> On behalf of SIG Chairs/Co-Chairs
> ___
> sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
> To unsubscribe send an email to sig-policy-le...@lists.apnic.net
>
>
>
> 
>
>
___
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: APNIC Nomination Review Committee - Proposal

[Aftab Siddiqui]

Hi Lu, though most of your comments are not related to the content of the
proposal but I'm happy to respond.


On Thu, 25 Aug 2022 at 16:00, Lu Heng  wrote:

> Nomination committees of any sort, only create controversies within RIRs.
>

That's your opinion and you are entitled to have one, so let's just leave
it there.


> In ARIN, there have been multiple controversies where qualified candidates 
> weren't included in the voting process, thereby causing community backlash.
>
>
NRC's role and responsibilities are different, please review the document
again.


> In AFRINIC, the so-called nomination committee that disqualified everyone is 
> the very reason the whole election was injuncted and is currently pending a 
> court order to be organized and run.
>
>
can't comment on a case pending court order but again review the role and
responsibility of NRC again.

A background info search and publication of such search info together
in which relation with candidacy is reasonable, a clear guideline of
what info would be considered relevant to the relevant position should
be established, and a fine balance must be struck between respecting a
candidates' privacy and the voter's rights to relevant information.
>
>
Glad to know that you do support publication of relevant information of
candidates. Once again if you read the role and responsibility of the NRC
then it will help you understand more.

In that case, anyone should be able to be a candidate, provided full
information has been given to the voters. And even if the voters
decide to vote for a person with a criminal record, as long as all
voters are well informed and decide that person deserves a second
chance, then we must respect this bottom-up and democratic process.
>
>
Help me understand, do you support a committee (in this case NRC) which is
elected by the community in a most transparent manner, which is the whole
idea of bottom-up approach?


> In most democratic states, anyone can run for head of the state without a 
> nomination committee hand pick them in a dark room, and I don't think any 
> position here would be more important than an actual President of the states, 
> so why do we want to prevent people from running and contesting?
>
>
Nope, that's not that case in many democratic states. People don't actually
vote for the head of state but we are not discussing the presidential and
the parliamentary system here and lets not add Monarchy in the mix.
Anyways, I love this topic but it's not relevant for this discussion.

Give the voters all the information they need and let them decide for
themselves who they want as their leaders. Anything other than that
will lead to either community backlash or court proceedings; both of
which Afrinic is currently experiencing right now. And what happened
in ARIN multiple times now.
>
>
Again, I'm not going to comment on what is happening in AFRINIC but if you
once again read the role and responsibilities of NRC then it will help you
understand more.


I know the RIRs recently don’t like the fact that they are private
companies and subject to rule of law, but until all of them become
intergovernmental bodies with attached immunity they wanted in their
letter to the government, the common law still applies to them.
>
>
APNIC Pty Ltd is an Australian Private Company and I'm not sure what you
are talking about when you say "become intergovernmental bodies" because
thats not what APNIC is and I know that because I'm a member and the
invoice I get is from a private company.


> Hence, the solution to this problem is simple:
>
>
> 1. Give the voters complete information
>
>
> 2. Anyone can be a candidate and let the voters decide.
>
>
> 3. We shouldn’t only let a small group of individuals in a dark room decide 
> who the voters can vote on.
>
>
> There is no need for NRC, all we need is to agree on what personal 
> information is relevant for each position, so anyone who wants to participate 
> can publish on their own and be verified by the Secretariat.
>
>
Again, for the last time I would suggest reading the document please.


> And let voters decide.
>
>
Voters will decide that ultimately because we are not changing the SIG
guidelines OR APNIC bylaws so literally no one is taking that voting rights
away . But thanks for highlighting that.

Regards,

Aftab A. Siddiqui


>
> With regards.
>
>
> Lu
>
>
>
>
>
>
>
>
> On Thu, 25 Aug 2022 at 08:08, Aftab Siddiqui 
> wrote:
>
>> Hi Everyone,
>>
>> As you are aware the current nomination process for any community elected
>> position is defined where APNIC secretariat sends the call for nomination
>> on various forums and once they (secretariat) receives the nominations an
>> internal due diligence process is performed and then the names 

[sig-policy] APNIC Nomination Review Committee - Proposal

[Aftab Siddiqui]

Hi Everyone,

As you are aware the current nomination process for any community elected
position is defined where APNIC secretariat sends the call for nomination
on various forums and once they (secretariat) receives the nominations an
internal due diligence process is performed and then the names of nominees
are published with their details. The process ran so far on a need-to-know
basis and the community had access to information that was deemed essential
by the Secretariat. In order to build a strong and community driven
structure it is important to have community oversight in the whole
process, which at the moment doesn't exist. For that reason we are
proposing a new committee called "Nomination Review Committee" and we
believe that it will bring much needed improvements to the process of
electing members to various community elected positions.

Please review the proposal here

and provide your feedback through the mailing list. We are also organising
a BoF

on 14th Sep during APNIC54 to further discuss this in-person/online.

BoF:
https://conference.apnic.net/54/program/schedule/#/day/6/bof---apnic-nominating-committee-nomcom

Link:
https://docs.google.com/document/d/1w0uANFm5j1qCFCxQR_rXlwyGg_4NXme50J-HcZ0QeQM/edit?usp=sharing


Regards,

Aftab A. Siddiqui
On behalf of SIG Chairs/Co-Chairs
___
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

Re: [sig-policy] APNIC EC endorses policy proposals from APNIC 52

[Aftab Siddiqui]

Hi Sunny,

prop-138: Restricting AS-ID in ROA, that reached consensus at APNIC 52
> to be a guideline will also be implemented along with these four
> proposals.
>

As per this link here
 [1], APNIC
secretariat updated the guidelines on 6th December. The text mentioned
there does not comply with what is suggested in the prop-138. I can still
create ROAs and route/route6 objects using the ROA interface.

[1] - https://www.apnic.net/community/policy/proposals/prop-138/
*  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] Community Feedback Required

[Aftab Siddiqui]

[Cross posting it to Policy SIG list]

Hi Everyone,
We have only received 10 responses so far. Working on RPKI Road Map and any
policy change depends on your feedback.

https://forms.gle/vE7ojtnMjEyAcS7N7

Regards,

Aftab A. Siddiqui


On Mon, 18 Oct 2021 at 18:39, Aftab Siddiqui 
wrote:

> Hi Everyone, As discussed on the call, here
> <https://docs.google.com/forms/d/e/1FAIpQLSeu5xnD44lt7hrSKdgrKvOny3vfqB04CLxSj6ExKwpcUKLtCQ/viewform?usp=sf_link>
> is the link to collect your feedback. Your response will help us shape up
> the discussion and help develop the road map and any policy changes (if
> required).
>
> https://forms.gle/vE7ojtnMjEyAcS7N7
>
> Regards,
>
> Aftab A. Siddiqui
>
*  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-141-v003: Change maximum delegation, size of IPv4 address from 512 ( /23 ) to 768 (/23+/24) addresses

[Aftab Siddiqui]

Hi Owen,
I understand your concern but even with /23 delegation size as of today,
APNIC delegated 1300+ /24s only in last 18 months (not the full /23) it
could be because of many reasons and one of them is fee (APNIC charges on
HD ratio). If we go ahead with further /23 + /24 it will create more
deaggregation which I agree but with almost 50% of the global routing table
based on /24s it is not going to make much difference that it will another
may be 8k /24s

Regards,

Aftab A. Siddiqui


On Wed, 15 Sept 2021 at 15:32, Owen DeLong  wrote:

> Opposed.
>
> Not in favor of moving to non-prefix aligned allocations from an RIR.
>
> Owen
>
>
> > On Sep 14, 2021, at 20:37 , Bertrand Cherrier 
> wrote:
> >
> > Dear SIG members,
> >
> > A new version of the proposal "prop-141-v003: Change maximum delegation
> > size of IPv4 address from 512 ( /23 ) to 768 (/23+/24) addresses" has
> > been sent to the Policy SIG for review.
> >
> > It will be presented at the Open Policy Meeting (OPM) at APNIC 52
> > on Thursday, 16 September 2021.
> >
> > https://conference.apnic.net/52/program/schedule/#/day/4
> >
> > We invite you to review and comment on the proposal on the mailing
> > list before the OPM.
> >
> > The comment period on the mailing list before the OPM is an important
> > part of the Policy Development Process (PDP). We encourage you to
> > express your views on the proposal:
> >
> >   - Do you support or oppose this proposal?
> >   - Does this proposal solve a problem you are experiencing? If so,
> > tell the community about your situation.
> >   - Do you see any disadvantages in this proposal?
> >   - Is there anything in the proposal that is not clear?
> >   - What changes could be made to this proposal to make it more
> effective?
> >
> > Information about earlier versions is available at:
> >
> > http://www.apnic.net/policy/proposals/prop-141
> >
> > Regards,
> > Bertrand and Ching-Heng
> > APNIC Policy SIG Chairs
> >
> >
> >
> --
>
> >
> > prop-141-v003: Change maximum delegation size of IPv4 address from 512 (
> /23 ) to 768 (/23+/24) addresses.
> >
> >
> ---
>
> >
> > Proposer: Simon Sohel Baroi (sba...@gmail.com)
> >   Aftab Siddiqui (aftab.siddi...@gmail.com)
> >
> >
> > 1. Problem statement
> > 
> > According to the APNIC IPv4 Address Report,(
> https://www.apnic.net/manage-ip/ipv4-exhaustion/ ) the available
> > and reserve pool size is as follows:
> >
> > Available Pool : IP Address 3,782,144 | 14,774 Of /24
> > Reserved Pool : IP Address 1,831,680 | 7,155 Of /24
> >
> > If APNIC continues to delegate IPv4 in size of /23 with the average
> growth rate of 145 x /23 delegations per
> > month the pool will be exhausted around Aug/Sep 2027. Which means the
> huge number of IPv4 addresses will be
> > unused for a long time and large community members will still remain
> behind the NAT box or even without
> > Internet Connectivity.
> >
> >
> > 2. Objective of policy change
> > -
> > The current final /8 allocation policy [1] advise that the current
> minimum delegation size for IPv4 is 256 (/24)
> > addresses and each APNIC account holder is only eligible to receive IPv4
> address delegations totaling a maximum
> > 512 (/23) addresses from the APNIC 103/8 IPv4 address pool. (6.1.
> Minimum and maximum IPv4 delegations)
> >
> > This is a proposal to change the maximum size of IPv4 address
> delegations from the available IPv4 address pool to
> > a totaling of 768 (/23+/24) addresses. This proposal also indicates how
> APNIC will distribute the IPv4 resources
> > systematically when the available pool size reduces.
> >
> > Increasing the maximum IPv4 delegation size from 512 ( /23 ) to 768
> (/23+/24) address pool will allow Newcomers
> > and also Existing APNIC account holders to get maximum number of IPv4
> address resources.
> >
> >
> > 3. Situation in other regions
> > -
> > There is no similar policy in place in other RIR regions.
> >
> >
> > 4. Proposed policy solution
> > ---
> > It is recommended to increase the IPv4 address delegation size from 512
> max (/23) to 768 (/23 + /24). The address
> > space can now 

Re: [sig-policy] prop-141-v002: Change maximum delegation, size of IPv4 address from 512 ( /23 ) to 768 (/23+/24) addresses

[Aftab Siddiqui]

Hi Vivek,


> We would like some clarification on the following two points as they are
> not consistent.
>
> > Increasing the maximum IPv4 delegation size from /23 to /23+/24 IPv4
> address pool will allow Newcomers and also
> > Existing APNIC account holders who only received /23 after Thursday, 28
> February 2019 to receive 256 (/24) IPv4
> > addresses.
>
> The above point suggests regardless when an organization became an APNIC
> member, if they only received /23 after Thursday, 28 February 2019, they
> will be eligible to receive an additional /24.
> What happens if an account holder had only received a /24 before Thursday,
> 28 February 2019? Would they be excluded from receiving this additional
> delegation?
>

Anyone who became a member after 28th February 2019 was only eligible for a
maximum of /23. So anyone who received /23 after 28th Feb is eligible for
extra /24. Anyone who only received /24 after 28th Feb is eligible for /23
(/24 as per existing policy and /24 from this proposed policy).


>
> > The Organization who became an APNIC member after Thursday, 28 February
> 2019 and received only /23, can receive
> > another /24 IPv4 Resources.
>
> The above point suggests that only those organizations who became an APNIC
> member after Thursday, 28 February 2019 are eligible for this additional
> delegation.
>

I understand your point, this statement not only applicable to members who
were impacted by the change of policy from /22 to /23 on 28th Feb 2019 but
Any member who only received /23 or /24 under previous policy (max
delegation size of /22 or before that), who had the opportunity to receive
up to /22 and they either never asked for it or were not eligible that time
can still apply for extra IPv4 addresses. This Is because we are suggesting
to increase the maximum delegation size from /23 (512 IPv4 addresses) to
/23 + /24 (768 IPv4 addresses), we have submitted the updated the text
without any date reference to make sure there is no confusion.


>
> Thanks
> Vivek
>
> On 8/9/21, 8:04 am, "sig-policy-boun...@lists.apnic.net on behalf of
> Bertrand Cherrier"  b.cherr...@micrologic.nc> wrote:
>
> Dear SIG members,
>
> A new version of the proposal "prop-141-v002: Change maximum delegation
> size of IPv4 address from 512 ( /23 ) to 768 (/23+/24) addresses" has
> been sent to the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting (OPM) at APNIC 52
> on Thursday, 16 September 2021.
>
>
> https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconference.apnic.net%2F52%2Fprogram%2Fschedule%2F%23%2Fday%2F4data=04%7C01%7C%7Ceacb8eda14bc4e33f6d908d9724b394d%7C127d8d0d7ccf473dab096e44ad752ded%7C0%7C0%7C637666490899858782%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Ecb%2F0sTectMW8UL03w9f8aCpprpr2wMiwGVuZGjKNgc%3Dreserved=0
>
> We invite you to review and comment on the proposal on the mailing
> list before the OPM.
>
> The comment period on the mailing list before the OPM is an important
> part of the Policy Development Process (PDP). We encourage you to
> express your views on the proposal:
>
>- Do you support or oppose this proposal?
>- Does this proposal solve a problem you are experiencing? If so,
>   tell the community about your situation.
>- Do you see any disadvantages in this proposal?
>- Is there anything in the proposal that is not clear?
>- What changes could be made to this proposal to make it more
> effective?
>
> Information about earlier versions is available at:
>
>
> https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apnic.net%2Fpolicy%2Fproposals%2Fprop-141data=04%7C01%7C%7Ceacb8eda14bc4e33f6d908d9724b394d%7C127d8d0d7ccf473dab096e44ad752ded%7C0%7C0%7C637666490899858782%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=wDguOAVH5Rw%2FFFKibNrMOXWY6IKyBro1v6E%2BdSLqftk%3Dreserved=0
>
> Regards,
> Bertrand and Ching-Heng
> APNIC Policy SIG Chairs
>
>
>
> --
>
>
>
> prop-141-v002: Change maximum delegation size of IPv4 address from 512
> (
> /23 ) to 768 (/23+/24) addresses.
>
>
> ---
>
>
>
> Proposer: Simon Sohel Baroi (sba...@gmail.com)
>Aftab Siddiqui (aftab.siddi...@gmail.com)
>
>
> 1. Problem statement
> ---

Re: [sig-policy] New Proposal prop-137-v001: IPv6 assignment for associate members

[Aftab Siddiqui]

Hi Hiroki san,

On Mon, 13 Sept 2021 at 09:19, Hiroki Kawabata  wrote:

> Aftab-san,
>
> Our position is neutral. At the point of promoting IPv6 deployment, we
> support this. But,
>
> When "Go IPv6" criteria (it probably means 9.2.1. in policy document) was
> implemented,
> we were expecting to use IPv6 in an IPv4 network.
> This proposal is different from above assumption, so it feels little
> strange.
>

Yes, this proposal is for IPv6 only assignments. If a member is requesting
for both IPv4 and IPv6 then it will be dealt with under current policy.
9.2.1 apply to those who already have IPv4 resources.


>
> In addition to this, we feel that small assignment tend to obscure the
> resource holder to which prefix is assigned. It is necessary to properly
> grasp them.
>

There are more than 61,500 /48s in the IPv6 routing table currently so I'm
not sure if I understand your point. PI is not further assigned to
downstream customers so it will not go beyond that. Deaggregation beyond
/48 is not an issue in IPv6 as most of the operators filter it out. Please
let me know if I misunderstood your point.


> Regards,
> Hiroki
>
>
*  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] New Proposal prop-137-v001: IPv6 assignment for associate members

[Aftab Siddiqui]

Hi Satoru san,


> As an NIR, JPNIC does not have a tier of associate members, making
> it difficult to supporce or opporse from Japanese community members.
>

Yes, I totally understand, once this policy is accepted by the community
then it is upto individual NIRs to decide whether to implement this or not.
IMO, this is not in conflict with RIR policy because you don't have an
associate membership tier.


>
> (comment details)
>  - It may be necessary to sort out the consistency of this proposal
>when it becomes a consensus, including other NIRs that similarly
>do not have an associate member tier.
>

I will be happy to discuss this in the NIR SIG session, if NIRs want to
provide IPv6 only resources to their members easily then they can come up
with their own policies. If the existing policy is supporting that anyway
then there is no need to update anything.


>  - The points of concern in the case of JPNIC are as follows:
>- Implementation is difficult because there is no tier of associate
> members.
>- There may be no need to force the implementation.
>

I totally agree.


>
>
> Regards,
>
> Satoru Tsurumaki / JPOPF Steering Team
>
> 2021年8月13日(金) 8:56 Bertrand Cherrier :
>
>> Dear SIG members,
>>
>> The proposal "prop-137-v001: IPv6 assignment for associate members"
>> has been sent to the Policy SIG for review.
>>
>> It will be presented at the Open Policy Meeting (OPM) at APNIC 52
>> on Thursday, 16 September 2021.
>>
>> https://conference.apnic.net/52/program/schedule/#/day/4
>>
>> We invite you to review and comment on the proposal on the mailing
>> list before the OPM.
>>
>> The comment period on the mailing list before the OPM is an important
>> part of the Policy Development Process (PDP). We encourage you to
>> express your views on the proposal:
>>
>>- Do you support or oppose this proposal?
>>- Does this proposal solve a problem you are experiencing? If so,
>>  tell the community about your situation.
>>- Do you see any disadvantages in this proposal?
>>- Is there anything in the proposal that is not clear?
>>- What changes could be made to this proposal to make it more
>> effective?
>>
>> Information about this proposal is appended below and also available at:
>>
>> http://www.apnic.net/policy/proposals/prop-137
>>
>> Regards,
>> Bertrand and Ching-Heng
>> APNIC Policy SIG Chairs
>>
>>
>> ---
>>
>> prop-137-v001: IPv6 assignment for associate members
>>
>> ---
>>
>> Proposer: Aftab Siddiqui (aftab.siddi...@gmail.com)
>>
>>
>> 1. Problem statement
>> 
>> The first tier of membership in APNIC is "Associate". As per APNIC-121
>> Section 2.1 and 2.2, the Associate members do not receive any address
>> space (IPv4 or IPv6). In order to be eligible for IPv6 assignment APNIC
>> Members that have been delegated an IPv4 address block from APNIC, but
>> have no IPv6 space, instantly qualify for an appropriately sized IPv6
>> block without any restriction. If you have no IPv4 delegation and only
>> requesting IPv6 assignment then as per APNIC-127 section 10.1.4
>> "Requests for Provider Independent assignments must include a detailed
>> plan of intended usage of the proposed address block over at least the
>> 12 months following the allocation". The minimum size of the assignment
>> is a /48 and requires annual fees of AUD 1,180 as per HD ratio.
>>
>> In the IPv4 exhaustion world, this policy limits anyone who wants to
>> only use IPv6 provider independent assignment for personal use as it
>> doesn't incentivise IPv6 assignment only. The same fees and
>> justification is applied to receive /24 IPv4 + /48 IPv6 address space.
>>
>> This is perceived as a clear barrier to deploy IPv6. This policy
>> proposal addresses that barrier aims to solve this problem by means of
>> providing a Provider Independent assignment to Associate members.
>>
>>
>> 2. Objective of policy change
>> -
>> Provide an incentive to small enterprises and academia/researchers to
>> receive IPv6 assignment.
>>
>>
>> 3. Situation in other regions
>> -
>> RIPE NCC: IPv6 PI can be sponsored by an LIR (EUR 50/yr)
>> ARIN: As an end-user IPv6 only can be requested following certain criteria
>> AFRINIC: Must not be an LIR
>> LACNIC: Not been an LIR or ISP, s

Re: [sig-policy] New Proposal prop-138-v001: Restricting AS-ID in ROA

[Aftab Siddiqui]

Responding to Secretariat questions.


> Clarifications required:
> 1. Since the route management interface in MyAPNIC (Member Portal)
> permits Members to create both route objects and ROAs
> with arbitrary ASNs, should this proposal be extended to include
> restricting of AS-ID in route objects as well?
>

Yes. It should be uniform for both route objects and ROAs. Currently, APNIC
restricts the creation of route-objects with "Reserved" ASNs using whois
update panel but allows the same using ROA creation panel.


> 2. Does this proposal requires the deletion of all existing ROAs
> referencing unallocated, private, and reserved ASNs?
>

ROAs already created should be revoked.

Another point raised during yesterday's discussion. Whether there is a need
to have a policy or guideline would be enough. I'm fine either way and
leave this on community consensus.

I will submit an updated version with the same statement in it.

>
> Regards,
> Sunny
>
> On 13/08/2021 9:58 am, Bertrand Cherrier wrote:
> > Dear SIG members,
> >
> > The proposal "prop-138-v001: Restricting AS-ID in ROA" has been
> > sent to the Policy SIG for review.
> >
> > It will be presented at the Open Policy Meeting (OPM) at APNIC 52
> > on Thursday, 16 September 2021.
> >
> >
> https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconference.apnic.net%2F52%2Fprogram%2Fschedule%2F%23%2Fday%2F4data=04%7C01%7C%7Cbafa554ae97d4bc47b7008d95ded0f93%7C127d8d0d7ccf473dab096e44ad752ded%7C0%7C0%7C637644095039717635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=0g1ckVVVxjWuI8efLzNSHLehu%2Bbu2cD5DwSFzgjsHmY%3Dreserved=0
> >
> >
> > We invite you to review and comment on the proposal on the mailing
> > list before the OPM.
> >
> > The comment period on the mailing list before the OPM is an important
> > part of the Policy Development Process (PDP). We encourage you to
> > express your views on the proposal:
> >
> >   - Do you support or oppose this proposal?
> >   - Does this proposal solve a problem you are experiencing? If so,
> > tell the community about your situation.
> >   - Do you see any disadvantages in this proposal?
> >   - Is there anything in the proposal that is not clear?
> >   - What changes could be made to this proposal to make it more
> > effective?
> >
> > Information about this proposal is appended below and also available at:
> >
> >
> https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apnic.net%2Fpolicy%2Fproposals%2Fprop-138data=04%7C01%7C%7Cbafa554ae97d4bc47b7008d95ded0f93%7C127d8d0d7ccf473dab096e44ad752ded%7C0%7C0%7C637644095039717635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=wbpAlgDbnl7%2FAPD5c2odGyVRKC83KeO%2F4T9BrgF9U%2FE%3Dreserved=0
> >
> >
> > Regards,
> > Bertrand and Ching-Heng
> > APNIC Policy SIG Chairs
> >
> >
> > ---
> >
> > prop-138-v001: Restricting AS-ID in ROA
> >
> > ---
> >
> > Proposer: Aftab Siddiqui (aftab.siddi...@gmail.com)
> >
> >
> > 1. Problem statement
> > 
> > RFC6482 - A Profile for Route Origin Authorisations (ROAs) defines the
> > content of a ROA and one of the field is called "asID" Autonomous
> > System Identifier. It is defined in the RFC as "The asID field
> > contains the AS number that is authorised to originate routes to the
> > given IP address prefixes."
> >
> > asID is an Integer value and the RFC doesn't restrict the range of
> > numbers which can be placed here but technically only allocated ASNs
> > should only be allowed to be added as "asID" or "Origin AS". APNIC ROA
> > management system allows any number between 0 - 4294967295, which
> > includes many ranges of Private ASNs, Reserved ASNs and unallocated
> > ASNs as well. This may lead to creating ROAs with Origin AS which
> > should not be in the global routing table.
> >
> >
> > 2. Objective of policy change
> > -
> > Restrict APNIC members to create ROAs with private, reserved or
> > unallocated ASN.
> >
> >
> > 3. Situation in other regions
> > -
> > In process of verifying this information.
> >
> >
> > 4. Proposed policy solution
> > ---
> > Route Origin Authorisation (ROA) is an RPKI object signed by a prefix
> >

Re: [sig-policy] Abuse Role Object

[Aftab Siddiqui]

Hi Jordi,

I think we need to get clear responses from the secretariat if “anything”
> requires a policy update, or it is just implementation details that they
> can adjust without working out a policy proposal.
>
>
I have the same opinion.


>
>
>
>
> In my opinion, the policy text + the explanations/presentation provided by
> the authors + the “additional information” section of the policy proposal,
> was providing the information to avoid this type of issues.
>

Yes, It wasn't mentioned in the policy that a new role object should be
created and filled with IRT object's attributes. I don't see any reason for
an update in the policy, it's an operational issue BUT if the Secretariat
believes that they can't make any changes and require policy support then
please let us know.


>
>
> Of course, the secretariat could take different implementation approaches,
> but the fact that we worked the details in the “additional information” was
> precisely because we foresee some possible issues and we suggested some
> implementation details to avoid them. I recall I’ve already sent a couple
> of emails to respond to some of those issues after a presentation of
> George, they should be archived. Actually, I think one of those emails that
> I’ve sent was not responded. I was asking there if some of the issues
> require an update of the policy via a new proposal. Could the secretariat
> take a look and tell us?
>
>
>
> Trying to summarize:
>
>
>
> 1)  IRT was meant to (optionally) disappear at some point, or be an
> “alias” of abuse-c.
>
> 2)  Initially it is expected that the “main” abuse-c is created as a
> duplicate of the existing IRT.
>
I agree with the latter part.

> 3)  Each organization need to define if they want additional abuse-c
> for different set of resources. For example, you may have a different abuse
> handling team for IPv6 and IPv4, or even for different IPv4 blocks; you may
> want to have a customer-assigned block to be handled by the customer abuse
> team, etc.
>
Well, NO. Let's stick to what was proposed in prop-125 :)

> 4)  I don’t think Country and Phone should be mandatory, but of
> course, instead of bogus data should be empty, if no data is available.
> Note that I’m also not opposed to have them with mandatory Country and
> Phone, but the full idea of the validation process is to have a “working
> email” so if the working email being validated doesn’t work, the policy
> escalate to other contacts and those contacts, should already have the
> right country and phones, right?
>
Country and Phone number fields are mandatory as per the APNIC whois policy
and can't be left blank, that's why they are filled with ZZ (ISO-3166 code
for user defined country) and +0 as phone number. Validation is not
an issue here as the email address attribute exists in both objects and has
been verified.
*  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

[sig-policy] Abuse Role Object

[Aftab Siddiqui]

Hi Everyone,

As some of you have already seen the discussion
 [1] on
twitter, started by Fakrul.

Just sharing the problem here. As part of some of the additional
request/reference in prop-125 (Validation of “abuse-mailbox” and other IRT
emails) "*APNIC will publish the IRT also as abuse-c, in order to
facilitate the search in whois, for the same information, regardless if
looking for abuse-c or IRT. This is done in order to assimilate the IRT to
the majority of the RIRs where it is abuse-c.*"

APNIC Secretariat implemented this by adding "abuse-c" attribute in the
inetnum (example below) and inet6num.

inetnum:103.162.142.0 - 103.162.143.255
netname:ISAL-SG
descr:  Internet Society Asia Limited
descr:  3 Temasek Avenue Level 21 Centennial Tower
country:SG
org:ORG-ISAL1-AP
admin-c:ISAL1-AP
tech-c: ISAL1-AP

*abuse-c:AI706-AP*

The abuse-c attribute requires NIC-handle but which NIC-handle? There can
be many NIC-handle within the organisation but one organisation can only
have one IRT object. So, APNIC generated a new "role object" using the data
from the IRT-object.

Now, the problem is that role object has some mandatory field as per APNIC
whois policy defined here
 [2], which either
doesn't exist (country) or are optional (phone) in IRT object i.e.

role:  [mandatory]  [single] [lookup key]
address:[mandatory]  [multiple]   [ ]
country:[mandatory]  [single] [ ]
phone:  [mandatory]  [multiple]   [ ]

irt:[mandatory]  [single] [primary/lookup key]
address:[mandatory]  [multiple]   [ ]
phone:  [optional]   [multiple]   [ ]
fax-no: [optional]   [multiple]   [ ]

When APNIC auto generated the data for this new abuse-c NIC-handle, they
filled it with bogus data.

role:   ABUSE ISALSG
address:3 Temasek Avenue Level 21 Centennial Tower, Singapore
Singapore 039190


*country:ZZphone:  +0*

The APNIC Secretariat is seeking suggestions to fix this problem as to how
to fill up the missing information.

IMO, a simple way would be to make Country (ISO-3166) and Phone number
mandatory in the IRT object (currently they are optional). This can be done
during the next IRT validation cycle.
Btw, Country Code in the role object is not a mandatory attribute (it
doesn't exist) as per RFC2622
 [3] but it is
as per APNIC whois policy.

[1] - https://twitter.com/rapappu/status/1397522066002247686?s=21
[2] - https://www.apnic.net/manage-ip/using-whois/guide/role/
[3] - https://datatracker.ietf.org/doc/html/rfc2622#section-3.3

Regards,

Aftab A. Siddiqui
*  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 new version email draft (003)

[Aftab Siddiqui]

Hi Job,
I raised these questions as part of my presentation and happy to respond
here as well.

Regards,

Aftab A. Siddiqui


On Fri, Sep 27, 2019 at 3:10 AM Job Snijders  wrote:

> Dear all,
>
> Since we are in final comment period, I’d like to learn more about the
> below questions.
>
> Kind regards,
>
> Job
>
> On Sat, Sep 7, 2019 at 17:32 Job Snijders  wrote:
>
>> Dear all,
>>
>> I'm happy to see the proposal has been updated, I think it'll make
>> discussion easier.
>>
>> I have some questions:
>>
>> 1/  How much trouble are those ~ 100 prefixes actually causing the
>> community? I'm sure we all agree that its not fair that these
>> entities are announcing space that wasn't assigned / allocated to
>> them; and probably not paying the bill either... and it would be
>> cool if those 100 prefixes can be assigned to elgible end users
>> through the normal process; but that's not worth infinite effort.
>>
>
As a member of the community and a paying member of APNIC, even a single
prefix from unallocated block bothers me because its one entity using the
prefix without paying a dime while I pay in full.


>
>> 1a/ What does APNIC currently do to 'reclaim' or 'clean up' space that
>> APNIC would like to assign to an eligible enduser, but is currently
>> being announce by some unrelated third party? What is today's
>> process?
>>
>
They certainly have processes in place, which ofcourse not working. This is
not the first time I have raised this question. I raised it in multiple
meetings and answer was same "we are trying". Here is the transcript from
APNIC46. (vogons = bogons)
https://conference.apnic.net/46/assets/files/APNC402/20180913_AMM1.txt

=
>>Aftab Siddiqui: Gaurab invited me up here, so I can't say no.  Just a
quick question on the treasurer's report. I just want to highlight one
important thing, and that is related to lost revenue.  I can give a few
examples, but let's not call names here.  There are certain --
I mean, everyone is aware of vogons, Geoff will look at me now.  So as per
the CiDR report, there are vogons
currently advertised in our region and there are certain 49 organisations
which have been announcing unallocated address space for more than one
year.  I just checked it, it is five /22 which is roughly around $3,500 in
lost revenue. So what APNIC is planning to do about that?  Any
actions or anything?  The member was de-registered early last year.  I'm
talking about one-year loss in revenue.

>>Gaurab Raj Upadhaya: Thank you.  I think I'll let Paul handle that.

>>Paul Wilson: This is something that you have mentioned to us before,
Aftab, and it is something that is being looked at.  I'm afraid that for
the latest status I'll have to defer to George Kuo, who's approaching the
mic.

>>George Kuo: Thanks, Paul, and thanks, Aftab, for your question.  We are
of this announcement activities. Guangliang's team, the registration team,
do plan to check it on a very regular basis and will be doing our best to
contact all the contact information we have. But if there is anything
better we can do, I'm happy to hear information from either Aftab yourself,
or anyone here.  Thanks will.
=


>
>> 1b/ Why should it be APNIC itself that makes the ROAs for unassigned
>> space? Perhaps the process should remain as-is: APNIC assigns space
>> to an enduser, and the enduser themselves can create a ROA if they
>> need to 'reclaim' the space. Using ROAs to supress rogue
>> announcements is great, but this mechanism can be used either before
>> and after assignment. I think the answer to this question in part
>> will derive from how we feel about (1) and what APNIC does in (1a).
>>
>
There are 3 issues with as-is process,
1 - the issues of unallocated address space won't be solved.
2 - member who receive the block might be tainted due to abuse/spam etc.
3 - most importantly, it is against the goal of NRO "
https://www.nro.net/about/nro-faq/;

===
What are the goals of the NRO?

The main goals of the NRO are to:
Protect the unallocated Internet number resource pool
Promote and protect the bottom-up policy development process
Act as a focal point for Internet community input into the RIR system
===


>> 2/  Has the community considered whether this proposal should be
>> implemented under the current 'production' APNIC TAL, or perhaps a
>> new TAL should be instantiated (let's call it the "APNIC-UNASSIGNED
>> TAL").  An advantage of using a separate TAL is that may address
>> some concerns about the RIRs operational involvement in routing.
>> Operators would need to explicitly opt-in into receiving ROAs for
>> the unassi

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

[Aftab Siddiqui]

Hi Job,


> On Thu, Aug 22, 2019 at 11:52:13AM +0600, Sumon Ahmed Sabir wrote:
> > A new version of the proposal "prop-132: AS0 for Bogons"
> > has been sent to the Policy SIG for review.
> >
> > Information about earlier versions is available from:
> > http://www.apnic.net/policy/proposals/prop-132
>
> Attached is a rewrite of prop-132-v002 ('prop-132-v003.txt') where the
> word "bogon" has been mostly replaced with (in my mind) more descriptive
> terms.
>
> The reason for wording things a bit different is that when I first heard
> about this proposal I thought the idea was to create ROAs for bogons
> such as RFC 1918 space, and thought "THEY WHAT NOW?!" :-)



> If we think in Venn diagrams, indeed, "bogons" contain all "unallocated
> and unassigned APNIC address space", and "unallocated and unassigned
> APNIC address space" are "bogons", but "bogons" to many operators means
> much more than just the APNIC managed portion of it.
>
> A clear advantage of ensuring unassigned or unallocated address space is
> not in use by unauthorized parties is that such address space can be
> assigned to eligible APNIC members instead. This proposal may (slightly)
> increase the pool of available IP address space for the APNIC community.
>

actually, you are not the only one, many (off list+on list) shared the same
opinion and then I had to explain Bogon to them (exactly as you explained
in second para) :) somewhere during the initial discussion of this proposal
there were some points about bogons vs martians and sometimes the terms are
confusing as well to operators as they use it differently, I agree.

Your edits are providing clear description, I will accomodate in the v3.
Thanks.
*  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

[Aftab Siddiqui]

t; service and legal perspective so the community can better understand
> >> the implementation, if this proposal reaches consensus.
> >>
> >>
> >> Kind regards
> >> Javed Khan
> >> MSCE and CCSP
> >>
> >>
> >> 
> >> *From:* sig-policy-boun...@lists.apnic.net
> >>  on behalf of David Farmer
> >> 
> >> *Sent:* Friday, 23 August 2019 10:48 AM
> >> *To:* Aftab Siddiqui 
> >> *Cc:* Sumon Ahmed Sabir ; Policy SIG
> >> 
> >> *Subject:* Re: [sig-policy] prop-132-v002: AS0 for Bogons
> >>
> >>
> >> On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui
> >> mailto:aftab.siddi...@gmail.com>> wrote:
> >>
> >> Hi David,
> >>
> >>
> >> On Fri, Aug 23, 2019 at 6:36 AM David Farmer  >> <mailto:far...@umn.edu>> wrote:
> >>
> >> The problem statement says;
> >>
> >> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons")
> >> is a packet
> >> with an IP source address in an address block not yet
> >> allocated by IANA
> >> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC,
> >> AFRINIC and
> >> LACNIC)...
> >>
> >>
> >> So that raises a question, what about resources that are
> >> deregisterd because they are returned, revoked, or otherwise
> >> reclaimed, for any of a myriad of reasons, including non-payment
> >> of fees? Do they become Bogons with AS0 ROAs the moment they are
> >> deregistered? Later, if so when? What if there is a ROA for them
> >> in the system? Are the ROAs removed, if so when?
> >>
> >>
> >> I also had some concerns about revoked and/or reclaimed space and
> >> closed account due to non payment so I asked Secretariat in advance
> >> and here is the response.
> >> ===
> >> APNIC membership account is classified as closed when its status is
> >> flagged as ‘closed’ in APNIC’s internal system.
> >>
> >> 30 days - payment period upon issuance of invoice, if no payment is
> >> received within this period member receives expiry notice and the
> >> account status becomes 'suspended'
> >> After 15 days – member receives email notification for closure
> >> giving them another 15 days to pay
> >> After 15 days – the status of the account becomes 'closed' and all
> >> delegated resources under the account are reclaimed
> >>
> >> All in all members have 60 days period to pay before the status of
> >> the account becomes ‘closed’.
> >> ===
> >>
> >> As long as the account is suspended APNIC doesn't consider those
> >> resources as free/available/reclaimed and because they are not part
> >> of unallocated pool thats why no need to create AS0 ROAs for such
> >> resources. AS0 ROAs will be created once APNIC mark those resources
> >> available and remove them from their delegation record. Now, the
> >> second issue is if there is a ROA for them in the system. Because AS
> >> 0 ROA has a lower relative preference than any other ROA that has a
> >> routable AS then APNIC has to somehow delete the existing ROA from
> >> the system. Its easy if the member account is closed and all
> >> resources are reclaimed. But I leave this to APNIC to decide how
> >> they are going to make that happen.
> >>
> >>
> >> Currently, when the account is closed nothing actively makes the
> >> resources unusable, accept for if you were also changing providers
> >> during this timeframe, then when the new provider checks the resources
> >> they will be unregistered. But most providers don't recheck the
> >> registration of resources very often, if ever, other than at the time
> >> of setup of service.
> >>
> >> With this proposal at some point, the resource will effectively become
> >> unusable with nonpayment, when the AS0 ROA is created, and any ROAs
> >> are removed, I'm fine with this, but it should be called out as a
> >> consequence of the proposal, so no one can say they didn't realize
> >> that is a consequence of the proposal.
> >>
> >> This 

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 po

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

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

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 t

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

[Aftab Siddiqui]

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

This policy is addressing only one thing "Control Bogon Announcements". If
the XYZ 

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

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

[Aftab Siddiqui]

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.

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

> I would propose something like the following;
>
>1. Upon de-reregistration any existing ROAs are removed from RPKI
>2. 30 days after de-registraion, AS0 ROAs are created except for
>non-payment fees
>3. 90 days after de-registraion, AS0 ROAs are created in the case of
>non-payment fees
>
> Thanks.
>

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


>
> On Thu, Aug 22, 2019 at 12:52 AM Sumon Ahmed Sabir 
> wrote:
>
>> Dear SIG members
>>
>> A new version of the proposal "prop-132: AS0 for Bogons"
>> has been sent to the Policy SIG for review.
>>
>> Information about earlier versions is available from:
>> http://www.apnic.net/policy/proposals/prop-132
>>
>> 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-132-v002: AS0 for Bogons
>>
>> --
>>
>> Proposer: Aftab Siddiqui
>>aftab.siddi...@gmail.com
>>
>>
>> 1. Problem statement
>> 
>> 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) as well as all addresses reserved for private or special use by
>> RFCs.  See [RFC3330] and [RFC1918].
>>
>> As of now, there are 287 IPv4 bogons and 73 IPv6 bogons in the global
>> routing
>> table. In the past, several attempts have been ma

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

[Aftab Siddiqui]

Ok I get your point now. During my ops days I used to manage "Martians"
(reserved blocks/special use blocks) and "Bogons" (unallocated address
blocks) prefix filters :)

Regards,

Aftab A. Siddiqui


On Thu, Aug 22, 2019 at 9:09 AM Owen DeLong  wrote:

> Fair enough. I tend to think of Bogons as “Those addresses which shouldn’t
> be advertised _EVER_” (e.g. 10.0.0.0/8) while I tend to think of
> Unallocated as being more transient in nature.
>
> I realize that makes 224.0.0.0/4 classification as a bogon a bit of a
> grey area, while including all unallocated space makes a cleaner definition.
>
> I suppose part of the reason for that was I always tended to maintain
> bogons and unallocated as separate lists in ACLs and I usually kept the
> unallocated one in the dynamic configuration (in Juniper land) since it
> tended to need frequent update.
>
> Owen
>
>
> On Aug 21, 2019, at 16:02 , Aftab Siddiqui 
> wrote:
>
> Hi Owen,
>
> On Thu, Aug 22, 2019 at 7:10 AM Owen DeLong  wrote:
>
>> I don’t tend to regard unallocated as “bogons”,
>>
>
> Why is that?
> RFC3871 <https://tools.ietf.org/html/rfc3871> - Bogon: 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,
> APNIC...) as well as all addresses reserved for private or special use by
> RFCs.
>
>
>> but sure, if this proposal is strictly about unallocated space in the
>> APNIC free pool(s), then I have no problem with that.
>>
>
> Yes, the policy is strictly talking about "unallocated address space" in
> APNIC free pool.
>
>
>>
>> Owen
>>
>>
>> On Aug 15, 2019, at 17:15 , Aftab Siddiqui 
>> wrote:
>>
>> Hi Owen,
>> Just to give you an example, all unallocated address space from 103/8 are
>> under APNIC's management unless they were transferred to other RIRs and
>> then reclaimed by that RIR due to whatever reason. This policy covers all
>> unallocated address space under APNIC's management and asking APNIC to
>> create AS0 ROAs for all those unallocated addresses.
>>
>> Regards,
>>
>> Aftab A. Siddiqui
>>
>>
>> On Fri, Aug 16, 2019 at 9:03 AM Owen DeLong  wrote:
>>
>>> Since we are talking about bigots, other than Unallocated space in RIR
>>> inventory, I’m not sure how you would consider a bogota to be within any
>>> particular RIRs jurisdiction. As such, I was under the impression from the
>>> policy proposal that the intent was for APNIC to issue AS0 ROAs for global
>>> bogons.
>>>
>>> Owen
>>>
>>>
>>> On Aug 15, 2019, at 15:12, Andrew Dul  wrote:
>>>
>>>
>>> On 8/15/2019 12:19 AM, Aftab Siddiqui wrote:
>>>
>>> Hi Owen,
>>>
>>> On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong  wrote:
>>>
>>>> Looks like IETF wants the global BOGONs to be attested by IANA rather
>>>> than by an RIR from what you quoted.
>>>>
>>>
>>> Yes, for resources not allocated by IANA or marked as Reserved But IANA
>>> has nothing to do with resources allocated to RIRs already.
>>>
>>>
>>>> Any reason APNIC feels the need to usurp that process?
>>>>
>>>
>>> Accordingly to IANA 103/8 was allocated to APNIC and now they don't have
>>> unallocated IPv4 address space.
>>> 103/8 APNIC 2011-02 whois.apnic.net https://rdap.apnic.net/ ALLOCATED
>>> The policy is addressing the unallocated address space within APNIC
>>>
>>>
>>> If this policy is only speaking to /8 IPv4 blocks & IPv6 blocks which
>>> are administered by APNIC, it should be noted that because of inter-RIR
>>> transfers of IPv4 addresses between regions RIRs other than APNIC are now
>>> administering sub-portions of the larger IANA allocated blocks.  There are
>>> portions of a /8 for example which are now delegated to other RIRs for
>>> registrations in those regions.   Should it be assumed that those
>>> sub-portions administered by RIRs now are considered allocated (and not
>>> bogons) for purposes of this policy?
>>>
>>> Andrew
>>>
>>>
>>>> Owen
>>>>
>>>>
>>>> On Aug 14, 2019, at 21:58 , Aftab Siddiqui 
>>>> wrote:
>>>>
>>>> Hi Owen,
>>>> Thanks for your response, sorry for replying late though.
>>>>
>>>> IMO, IETF has done its part already.
>&g

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

[Aftab Siddiqui]

Hi Owen,

On Thu, Aug 22, 2019 at 7:10 AM Owen DeLong  wrote:

> I don’t tend to regard unallocated as “bogons”,
>

Why is that?
RFC3871 <https://tools.ietf.org/html/rfc3871> - Bogon: 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,
APNIC...) as well as all addresses reserved for private or special use by
RFCs.


> but sure, if this proposal is strictly about unallocated space in the
> APNIC free pool(s), then I have no problem with that.
>

Yes, the policy is strictly talking about "unallocated address space" in
APNIC free pool.


>
> Owen
>
>
> On Aug 15, 2019, at 17:15 , Aftab Siddiqui 
> wrote:
>
> Hi Owen,
> Just to give you an example, all unallocated address space from 103/8 are
> under APNIC's management unless they were transferred to other RIRs and
> then reclaimed by that RIR due to whatever reason. This policy covers all
> unallocated address space under APNIC's management and asking APNIC to
> create AS0 ROAs for all those unallocated addresses.
>
> Regards,
>
> Aftab A. Siddiqui
>
>
> On Fri, Aug 16, 2019 at 9:03 AM Owen DeLong  wrote:
>
>> Since we are talking about bigots, other than Unallocated space in RIR
>> inventory, I’m not sure how you would consider a bogota to be within any
>> particular RIRs jurisdiction. As such, I was under the impression from the
>> policy proposal that the intent was for APNIC to issue AS0 ROAs for global
>> bogons.
>>
>> Owen
>>
>>
>> On Aug 15, 2019, at 15:12, Andrew Dul  wrote:
>>
>>
>> On 8/15/2019 12:19 AM, Aftab Siddiqui wrote:
>>
>> Hi Owen,
>>
>> On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong  wrote:
>>
>>> Looks like IETF wants the global BOGONs to be attested by IANA rather
>>> than by an RIR from what you quoted.
>>>
>>
>> Yes, for resources not allocated by IANA or marked as Reserved But IANA
>> has nothing to do with resources allocated to RIRs already.
>>
>>
>>> Any reason APNIC feels the need to usurp that process?
>>>
>>
>> Accordingly to IANA 103/8 was allocated to APNIC and now they don't have
>> unallocated IPv4 address space.
>> 103/8 APNIC 2011-02 whois.apnic.net https://rdap.apnic.net/ ALLOCATED
>> The policy is addressing the unallocated address space within APNIC
>>
>>
>> If this policy is only speaking to /8 IPv4 blocks & IPv6 blocks which are
>> administered by APNIC, it should be noted that because of inter-RIR
>> transfers of IPv4 addresses between regions RIRs other than APNIC are now
>> administering sub-portions of the larger IANA allocated blocks.  There are
>> portions of a /8 for example which are now delegated to other RIRs for
>> registrations in those regions.   Should it be assumed that those
>> sub-portions administered by RIRs now are considered allocated (and not
>> bogons) for purposes of this policy?
>>
>> Andrew
>>
>>
>>> Owen
>>>
>>>
>>> On Aug 14, 2019, at 21:58 , Aftab Siddiqui 
>>> wrote:
>>>
>>> Hi Owen,
>>> Thanks for your response, sorry for replying late though.
>>>
>>> IMO, IETF has done its part already.
>>>
>>> RFC6483 defines the term “Disavowal of Routing Origination”.
>>>
>>> “A ROA is a positive attestation that a prefix holder has authorized an
>>> AS to originate a route for this prefix into the inter-domain routing
>>> system.  It is possible for a prefix holder to construct an authorization
>>> where no valid AS has been granted any such authority to originate a route
>>> for an address prefix.  This is achieved by using a ROA where the ROA’s
>>> subject AS is one that must not be used in any routing context.
>>> Specifically, AS0 is reserved by the IANA such that it may be used to
>>> identify non-routed networks
>>>
>>> A ROA with a subject of AS0 (AS0 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
>>> procedure will provide 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.  Consequently, an AS0 ROA has a
>>> lower relative preference than any other ROA that has a routable AS, as its
>>> subject.  This allows a prefix holder to use an AS0 ROA to declare

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

[Aftab Siddiqui]

Hi Andrew,
Good suggestion, it makes more sense and very well noted. I will made the
change accordingly. Let me see if any other suggestions comes out later
today otherwise I will update the policy.

Regards,

Aftab A. Siddiqui


On Fri, Aug 16, 2019 at 10:13 AM Andrew Dul  wrote:

> Hello!
> On 8/15/2019 5:00 PM, Aftab Siddiqui wrote:
>
> Hi Andrew,
>
>>
>> On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong  wrote:
>>
>>> Looks like IETF wants the global BOGONs to be attested by IANA rather
>>> than by an RIR from what you quoted.
>>>
>>
>> Yes, for resources not allocated by IANA or marked as Reserved But IANA
>> has nothing to do with resources allocated to RIRs already.
>>
>>
>>> Any reason APNIC feels the need to usurp that process?
>>>
>>
>> Accordingly to IANA 103/8 was allocated to APNIC and now they don't have
>> unallocated IPv4 address space.
>> 103/8 APNIC 2011-02 whois.apnic.net https://rdap.apnic.net/ ALLOCATED
>> The policy is addressing the unallocated address space within APNIC
>>
>>
>> If this policy is only speaking to /8 IPv4 blocks & IPv6 blocks which are
>> administered by APNIC, it should be noted that because of inter-RIR
>> transfers of IPv4 addresses between regions RIRs other than APNIC are now
>> administering sub-portions of the larger IANA allocated blocks.  There are
>> portions of a /8 for example which are now delegated to other RIRs for
>> registrations in those regions.   Should it be assumed that those
>> sub-portions administered by RIRs now are considered allocated (and not
>> bogons) for purposes of this policy?
>>
> The policy is for unallocated address space (v4 and v6) under APNIC
> bucket. If the resources has been transferred to other RIRs means they are
> not unallocated anymore. If a /8 has been chopped by IANA and allocated to
> multiple RIRs e.g. 202/8 then APNIC will create AS0 ROAs for only those
> unallocated address space under APNIC's management. Any address space which
> is not under APNIC's resource bucket is not covered by this policy. I hope
> that answers your question.
>
>
> I'd like to suggest that the text "in its bucket" is not very well
> defined.  Can I suggest this updated policy text to clarify the intent as
> you've described.
>
>
> APNIC will create AS0(zero) ROAs for all the unallocated (IPv4 and IPv6)
> address space for which APNIC is the current administrator.  APNIC will not
> create AS0(zero) ROAs for any block which is currently allocated or
> transferred to another RIR, or is a private, special purpose, or any other
> IANA reserved or unallocated block.
>
>
> Hope this helps,
>
> Andrew
>
*  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-v001 AS0 for Bogons

[Aftab Siddiqui]

Hi Owen,
Just to give you an example, all unallocated address space from 103/8 are
under APNIC's management unless they were transferred to other RIRs and
then reclaimed by that RIR due to whatever reason. This policy covers all
unallocated address space under APNIC's management and asking APNIC to
create AS0 ROAs for all those unallocated addresses.

Regards,

Aftab A. Siddiqui


On Fri, Aug 16, 2019 at 9:03 AM Owen DeLong  wrote:

> Since we are talking about bigots, other than Unallocated space in RIR
> inventory, I’m not sure how you would consider a bogota to be within any
> particular RIRs jurisdiction. As such, I was under the impression from the
> policy proposal that the intent was for APNIC to issue AS0 ROAs for global
> bogons.
>
> Owen
>
>
> On Aug 15, 2019, at 15:12, Andrew Dul  wrote:
>
>
> On 8/15/2019 12:19 AM, Aftab Siddiqui wrote:
>
> Hi Owen,
>
> On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong  wrote:
>
>> Looks like IETF wants the global BOGONs to be attested by IANA rather
>> than by an RIR from what you quoted.
>>
>
> Yes, for resources not allocated by IANA or marked as Reserved But IANA
> has nothing to do with resources allocated to RIRs already.
>
>
>> Any reason APNIC feels the need to usurp that process?
>>
>
> Accordingly to IANA 103/8 was allocated to APNIC and now they don't have
> unallocated IPv4 address space.
> 103/8 APNIC 2011-02 whois.apnic.net https://rdap.apnic.net/ ALLOCATED
> The policy is addressing the unallocated address space within APNIC
>
>
> If this policy is only speaking to /8 IPv4 blocks & IPv6 blocks which are
> administered by APNIC, it should be noted that because of inter-RIR
> transfers of IPv4 addresses between regions RIRs other than APNIC are now
> administering sub-portions of the larger IANA allocated blocks.  There are
> portions of a /8 for example which are now delegated to other RIRs for
> registrations in those regions.   Should it be assumed that those
> sub-portions administered by RIRs now are considered allocated (and not
> bogons) for purposes of this policy?
>
> Andrew
>
>
>> Owen
>>
>>
>> On Aug 14, 2019, at 21:58 , Aftab Siddiqui 
>> wrote:
>>
>> Hi Owen,
>> Thanks for your response, sorry for replying late though.
>>
>> IMO, IETF has done its part already.
>>
>> RFC6483 defines the term “Disavowal of Routing Origination”.
>>
>> “A ROA is a positive attestation that a prefix holder has authorized an
>> AS to originate a route for this prefix into the inter-domain routing
>> system.  It is possible for a prefix holder to construct an authorization
>> where no valid AS has been granted any such authority to originate a route
>> for an address prefix.  This is achieved by using a ROA where the ROA’s
>> subject AS is one that must not be used in any routing context.
>> Specifically, AS0 is reserved by the IANA such that it may be used to
>> identify non-routed networks
>>
>> A ROA with a subject of AS0 (AS0 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
>> procedure will provide 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.  Consequently, an AS0 ROA has a
>> lower relative preference than any other ROA that has a routable AS, as its
>> subject.  This allows a prefix holder to use an AS0 ROA to declare a
>> default condition that any route that is equal to or more specific than the
>> prefix to be considered “invalid”, while also allowing other concurrently
>> issued ROAs to describe valid origination authorizations for more specific
>> prefixes.”
>>
>> RFC6491 says - "IANA SHOULD issue an AS 0 ROA for all reserved IPv4 and
>> IPv6 resources not intended to be routed." also "IANA SHOULD issue an AS
>> 0 ROA for all Unallocated Resources."
>>
>> Once allocated to RIRs then IANA can't issue any ROA (they are not doing
>> it to any resource anyway) but there is unallocated address space with
>> RIRs, they can issue AS0 ROAs.
>>
>> I hope this clarifies your point of IETF's involvement first.
>>
>> Regards,
>> Aftab A. Siddiqui
>>
>> On Sat, Aug 10, 2019 at 6:40 AM Owen DeLong  wrote:
>>
>>> IMHO, while I’m perfectly fine with APNIC administering this and
>>> maintaining the ROAs, etc., I believe that the decision to allocate AS0 to
>>> this purpose and documentation of this intent shoul

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

[Aftab Siddiqui]

Hi Andrew,

>
> On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong  wrote:
>
>> Looks like IETF wants the global BOGONs to be attested by IANA rather
>> than by an RIR from what you quoted.
>>
>
> Yes, for resources not allocated by IANA or marked as Reserved But IANA
> has nothing to do with resources allocated to RIRs already.
>
>
>> Any reason APNIC feels the need to usurp that process?
>>
>
> Accordingly to IANA 103/8 was allocated to APNIC and now they don't have
> unallocated IPv4 address space.
> 103/8 APNIC 2011-02 whois.apnic.net https://rdap.apnic.net/ ALLOCATED
> The policy is addressing the unallocated address space within APNIC
>
>
> If this policy is only speaking to /8 IPv4 blocks & IPv6 blocks which are
> administered by APNIC, it should be noted that because of inter-RIR
> transfers of IPv4 addresses between regions RIRs other than APNIC are now
> administering sub-portions of the larger IANA allocated blocks.  There are
> portions of a /8 for example which are now delegated to other RIRs for
> registrations in those regions.   Should it be assumed that those
> sub-portions administered by RIRs now are considered allocated (and not
> bogons) for purposes of this policy?
>
The policy is for unallocated address space (v4 and v6) under APNIC bucket.
If the resources has been transferred to other RIRs means they are not
unallocated anymore. If a /8 has been chopped by IANA and allocated to
multiple RIRs e.g. 202/8 then APNIC will create AS0 ROAs for only those
unallocated address space under APNIC's management. Any address space which
is not under APNIC's resource bucket is not covered by this policy. I hope
that answers your question.
*  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-v001 AS0 for Bogons

[Aftab Siddiqui]

Hi Owen,

On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong  wrote:

> Looks like IETF wants the global BOGONs to be attested by IANA rather than
> by an RIR from what you quoted.
>

Yes, for resources not allocated by IANA or marked as Reserved But IANA has
nothing to do with resources allocated to RIRs already.


> Any reason APNIC feels the need to usurp that process?
>

Accordingly to IANA 103/8 was allocated to APNIC and now they don't have
unallocated IPv4 address space.
103/8 APNIC 2011-02 whois.apnic.net https://rdap.apnic.net/ ALLOCATED
The policy is addressing the unallocated address space within APNIC


>
> Owen
>
>
> On Aug 14, 2019, at 21:58 , Aftab Siddiqui 
> wrote:
>
> Hi Owen,
> Thanks for your response, sorry for replying late though.
>
> IMO, IETF has done its part already.
>
> RFC6483 defines the term “Disavowal of Routing Origination”.
>
> “A ROA is a positive attestation that a prefix holder has authorized an AS
> to originate a route for this prefix into the inter-domain routing system.
> It is possible for a prefix holder to construct an authorization where no
> valid AS has been granted any such authority to originate a route for an
> address prefix.  This is achieved by using a ROA where the ROA’s subject AS
> is one that must not be used in any routing context.  Specifically, AS0 is
> reserved by the IANA such that it may be used to identify non-routed
> networks
>
> A ROA with a subject of AS0 (AS0 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 procedure
> will provide 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.  Consequently, an AS0 ROA has a lower
> relative preference than any other ROA that has a routable AS, as its
> subject.  This allows a prefix holder to use an AS0 ROA to declare a
> default condition that any route that is equal to or more specific than the
> prefix to be considered “invalid”, while also allowing other concurrently
> issued ROAs to describe valid origination authorizations for more specific
> prefixes.”
>
> RFC6491 says - "IANA SHOULD issue an AS 0 ROA for all reserved IPv4 and
> IPv6 resources not intended to be routed." also "IANA SHOULD issue an AS
> 0 ROA for all Unallocated Resources."
>
> Once allocated to RIRs then IANA can't issue any ROA (they are not doing
> it to any resource anyway) but there is unallocated address space with
> RIRs, they can issue AS0 ROAs.
>
> I hope this clarifies your point of IETF's involvement first.
>
> Regards,
> Aftab A. Siddiqui
>
> On Sat, Aug 10, 2019 at 6:40 AM Owen DeLong  wrote:
>
>> IMHO, while I’m perfectly fine with APNIC administering this and
>> maintaining the ROAs, etc., I believe that the decision to allocate AS0 to
>> this purpose and documentation of this intent should be done through the
>> IETF and be documented in an STD or RFC.
>>
>> I support the idea, but I believe the proper place to start is the IETF.
>>
>> Owen
>>
>>
>> On Aug 9, 2019, at 3:01 AM, Sumon Ahmed Sabir  wrote:
>>
>>
>> Dear SIG members,
>>
>> The proposal "prop-132-v001: AS0 for Bogons" has been sent to
>> the Policy SIG for review.
>>
>> It will be presented at the Open Policy Meeting at APNIC 48 in
>> Chiang Mai, Thailand on Thursday, 12 September 2019.
>>
>> We invite you to review and comment on the proposal on the mailing list
>> before the meeting.
>>
>> The comment period on the mailing list before an APNIC meeting is an
>> important part of the policy development process. We encourage you to
>> express your views on the proposal:
>>
>>   - Do you support or oppose this proposal?
>>   - Does this proposal solve a problem you are experiencing? If so,
>> tell the community about your situation.
>>   - Do you see any disadvantages in this proposal?
>>   - Is there anything in the proposal that is not clear?
>>   - What changes could be made to this proposal to make it more
>>     effective?
>>
>> Information about this proposal is available at:
>> http://www.apnic.net/policy/proposals/prop-132
>>
>> Regards
>>
>> Sumon, Bertrand, Ching-Heng
>> APNIC Policy SIG Chairs
>>
>>
>> --
>>
>> prop-132-v001: AS0 for Bogons
>>
>> --
>>
>> Proposer

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

[Aftab Siddiqui]

Hi Owen,
Thanks for your response, sorry for replying late though.

IMO, IETF has done its part already.

RFC6483 defines the term “Disavowal of Routing Origination”.

“A ROA is a positive attestation that a prefix holder has authorized an AS
to originate a route for this prefix into the inter-domain routing system.
It is possible for a prefix holder to construct an authorization where no
valid AS has been granted any such authority to originate a route for an
address prefix.  This is achieved by using a ROA where the ROA’s subject AS
is one that must not be used in any routing context.  Specifically, AS0 is
reserved by the IANA such that it may be used to identify non-routed
networks

A ROA with a subject of AS0 (AS0 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 procedure
will provide 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.  Consequently, an AS0 ROA has a lower
relative preference than any other ROA that has a routable AS, as its
subject.  This allows a prefix holder to use an AS0 ROA to declare a
default condition that any route that is equal to or more specific than the
prefix to be considered “invalid”, while also allowing other concurrently
issued ROAs to describe valid origination authorizations for more specific
prefixes.”

RFC6491 says - "IANA SHOULD issue an AS 0 ROA for all reserved IPv4 and
IPv6 resources not intended to be routed." also "IANA SHOULD issue an AS 0
ROA for all Unallocated Resources."

Once allocated to RIRs then IANA can't issue any ROA (they are not doing it
to any resource anyway) but there is unallocated address space with RIRs,
they can issue AS0 ROAs.

I hope this clarifies your point of IETF's involvement first.

Regards,
Aftab A. Siddiqui

On Sat, Aug 10, 2019 at 6:40 AM Owen DeLong  wrote:

> IMHO, while I’m perfectly fine with APNIC administering this and
> maintaining the ROAs, etc., I believe that the decision to allocate AS0 to
> this purpose and documentation of this intent should be done through the
> IETF and be documented in an STD or RFC.
>
> I support the idea, but I believe the proper place to start is the IETF.
>
> Owen
>
>
> On Aug 9, 2019, at 3:01 AM, Sumon Ahmed Sabir  wrote:
>
>
> Dear SIG members,
>
> The proposal "prop-132-v001: AS0 for Bogons" has been sent to
> the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 48 in
> Chiang Mai, Thailand on Thursday, 12 September 2019.
>
> We invite you to review and comment on the proposal on the mailing list
> before the meeting.
>
> The comment period on the mailing list before an APNIC meeting is an
> important part of the policy development process. We encourage you to
> express your views on the proposal:
>
>   - Do you support or oppose this proposal?
>   - Does this proposal solve a problem you are experiencing? If so,
> tell the community about your situation.
>   - Do you see any disadvantages in this proposal?
>   - Is there anything in the proposal that is not clear?
>   - What changes could be made to this proposal to make it more
> effective?
>
> Information about this proposal is available at:
> http://www.apnic.net/policy/proposals/prop-132
>
> Regards
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
>
>
> ------
>
> prop-132-v001: AS0 for Bogons
>
> --
>
> Proposer: Aftab Siddiqui
>aftab.siddi...@gmail.com
>
>
> 1. Problem statement
> 
> 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) as well as all addresses reserved for private or special use by
> RFCs.  See [RFC3330] and [RFC1918].
>
> As of now, there are 287 IPv4 bogons and 73 IPv6 bogons in the global
> routing table. In the past, several attempts have been made to filter
> out such bogons through various methods such as static filters and updating
> them occasionally but it is hard to keep an up to date filters,
> TeamCymru and
> CAIDA provides full bogon list in text format to update such filters.
> TeamCymru
> also provides bogon BGP feed where they send all the bogons via a BGP
> session
> which then can be discarded automatically. Beside all these attempts the
> issue
> of Bogon Advertisement hasn't be resolved so far.
&

Re: [sig-policy] Amendment of SIG Charter

[Aftab Siddiqui]

Policy manual or updates of it”.
> >
> >
> > Regards,
> >
> > Jordi
> >
> > El 9/5/19 23:51, "Paul Wilson"
> >  > <mailto:sig-policy-boun...@lists.apnic.net>en nombre
> > depwil...@apnic.net <mailto:pwil...@apnic.net>> escribió:
> >
> > Dear Sumon and all,
> >
> > To reduce confusion over ISP/LIR/etc terminology, perhaps the
> > charter could be stated more simply, along these lines:
> >
> > “The Policy SIG charter is to develop policies which relate to
> > the management and use of Internet address resources within the
> > Asia Pacific region. …”
> >
> > My 2c, with best regards,
> >
> >
>  
> > Paul Wilson, Director-General, APNIC d...@apnic.net
> > <mailto:d...@apnic.net>
> > http://www.apnic.net <http://www.apnic.net/>@apnicdg
> >
> > On 9 May 2019, at 19:53, Sumon Ahmed Sabir wrote:
> >
> > Thank you very much Aftab and Owen for your constructive
> > feedback. We will definitely consider those views.
> >
> > If any one has any different perspective please jump in and
> > share your thoughts.
> >
> > Sincerely,
> >
> > Sumon
> >
> > On Mon, May 6, 2019 at 10:52 AM Owen DeLong  > <mailto:o...@delong.com>> wrote:
> >
> > Aftab, I think you misread the proposed language.
> >
> > First, neither the current version nor the proposed
> > version refer to members at all, but to the actions of
> > the APNIC, NIRs, and ISPs. The one change I think should
> > be made there is to replace ISPs with LIRs since not all
> > LIRs are technically ISPs, though that is certainly the
> > most common case.
> >
> > As to your “not limited to” or “services related to
> > resources”, I fail to see how that is not addressed by
> > the proposed “…and related services”.
> >
> > I support the language proposed by Sumon whether or not
> > he chooses to take my NIR suggestion.
> >
> > Owen
> >
> >
> >
> >
> >
> > On May 5, 2019, at 03:21 , Aftab Siddiqui
> >  > <mailto:aftab.siddi...@gmail.com>> wrote:
> >
> > Thanks Sumon bhai for the initiative,
> >
> > 
> >
> > Revised text suggest that all members/resource
> > holders in APNIC are ISPs only, I would suggest to
> > make it "APNIC and NIR members or resource holders
> > in Asia Pacific region". Because not all members are
> > resource holders.
> >
> > Secondly, when you start mentioning topics in the
> > charter then it may create confusion moving forward
> > that only these topics can be covered so how about
> > adding "not limited to" or "services related to
> > resources" or something like that.
> >
> > 
> >
> > Regards,
> >
> > Aftab A. Siddiqui
> >
> > On Sun, May 5, 2019 at 4:31 PM Sumon Ahmed Sabir
> > mailto:sasa...@gmail.com>>
> wrote:
> >
> > Dear Members,
> >
> >
> >
> >
> >
> > In the last APNIC meeting in Daejoan there was a
> > discussion that there is a perception
> >
> > That Policy SIG discusses only about “Address
> > Policy”. On the other hand there is a
> understanding
> >
> > that Policy SIG covers a wider range of registry
> > issues, RPKI or any other topics that requires a
> >
> > procedures and rules.
> >
> >
> >
> >
> >
> > To avoid confusion and to bring clarity in the
> > Policy Charter few proposal

Re: [sig-policy] Amendment of SIG Charter

[Aftab Siddiqui]

Thanks Paul,

This addresses all my concerns.

Regards,

Aftab A. Siddiqui


On Fri, May 10, 2019 at 1:51 PM Paul Wilson  wrote:

> Dear Sumon and all,
>
> To reduce confusion over ISP/LIR/etc terminology, perhaps the charter
> could be stated more simply, along these lines:
>
> “The Policy SIG charter is to develop policies which relate to the
> management and use of Internet address resources within the Asia Pacific
> region. …”
>
> My 2c, with best regards,
>
> 
> Paul Wilson, Director-General, APNIC d...@apnic.net
> http://www.apnic.net @apnicdg
>
> On 9 May 2019, at 19:53, Sumon Ahmed Sabir wrote:
>
>
> Thank you very much Aftab and Owen for your constructive feedback. We will
> definitely consider those views.
>
> If any one has any different perspective please jump in and share
> your thoughts.
>
> Sincerely,
>
> Sumon
>
>
>
> On Mon, May 6, 2019 at 10:52 AM Owen DeLong  wrote:
>
>> Aftab, I think you misread the proposed language.
>>
>> First, neither the current version nor the proposed version refer to
>> members at all, but to the actions of the APNIC, NIRs, and ISPs. The one
>> change I think should be made there is to replace ISPs with LIRs since not
>> all LIRs are technically ISPs, though that is certainly the most common
>> case.
>>
>> As to your “not limited to” or “services related to resources”, I fail to
>> see how that is not addressed by the proposed “…and related services”.
>>
>> I support the language proposed by Sumon whether or not he chooses to
>> take my NIR suggestion.
>>
>> Owen
>>
>>
>> On May 5, 2019, at 03:21 , Aftab Siddiqui 
>> wrote:
>>
>> Thanks Sumon bhai for the initiative,
>>
>> 
>> Revised text suggest that all members/resource holders in APNIC are ISPs
>> only, I would suggest to make it "APNIC and NIR members or resource holders
>> in Asia Pacific region". Because not all members are resource holders.
>>
>> Secondly, when you start mentioning topics in the charter then it may
>> create confusion moving forward that only these topics can be covered so
>> how about adding "not limited to" or "services related to resources" or
>> something like that.
>> 
>>
>>
>> Regards,
>>
>> Aftab A. Siddiqui
>>
>>
>> On Sun, May 5, 2019 at 4:31 PM Sumon Ahmed Sabir 
>> wrote:
>>
>>> Dear Members,
>>>
>>> In the last APNIC meeting in Daejoan there was a discussion that there
>>> is a perception
>>> That Policy SIG discusses only about “Address Policy”. On the other hand
>>> there is a understanding
>>> that Policy SIG covers a wider range of registry issues, RPKI or any
>>> other topics that requires a
>>> procedures and rules.
>>>
>>> To avoid confusion and to bring clarity in the Policy Charter few
>>> proposals came in. That either we can change the Name of the Policy SIG
>>> to cover wider range or to amend the Policy-SIG Charter to bring clarity
>>> about the scope of Policy SIG.
>>>
>>> After discussions chairs feels that we can make some changes in the SIG
>>> Charter to bring clarity:
>>>
>>>
>>> Current SIG Charter https://www.apnic.net/community/policy/policy-sig/
>>>  says:
>>>
>>>
>>> ‘The Policy SIG charter is to develop policies and procedures
>>> which relate to the management and
>>> use of Internet address resources by APNIC, NIRs, and ISPs within the
>>> Asia Pacific region.”
>>>
>>> And here is the possible changes proposed:
>>>
>>>  “The Policy SIG charter is to develop policies which relate to
>>> the management and use of Internet  address resources by APNIC, NIRs,
>>> and ISPs within the Asia Pacific region.  These include policies for
>>> resource allocation, recovery and transfer, and for resource registration
>>> within whois, reverse DNS, RPKI and related services.”
>>>
>>> Please share your views, comments or suggestions in this regard.
>>>
>>>
>>> Sincerely,
>>>
>>> Sumon, Bertrand and Ching-Heng
>>> Chairs, Policy-SIG
>>> *  sig-policy:  APNIC SIG on resource management policy
>>>  *
>>> ___
>>> sig-policy mailing list
>>> sig-policy@lists.apnic.net
>>> https://mailman.apnic.

Re: [sig-policy] Amendment of SIG Charter

[Aftab Siddiqui]

Hi Owen,

On Mon, May 6, 2019 at 2:52 PM Owen DeLong  wrote:

> Aftab, I think you misread the proposed language.
>
> First, neither the current version nor the proposed version refer to
> members at all, but to the actions of the APNIC, NIRs, and ISPs. The one
> change I think should be made there is to replace ISPs with LIRs since not
> all LIRs are technically ISPs, though that is certainly the most common
> case.
>

I agree with your first point, I did misread the language slightly :) so no
argument on that. But LIR will further confuse people as within APNIC
region we don't use this term as in RIPE NCC to replace it with every
member.


> As to your “not limited to” or “services related to resources”, I fail to
> see how that is not addressed by the proposed “…and related services”.
>

The whole argument in the last meeting started because it states "Address
Resource" and whether this is the right platform to discuss something
related to whois or any other topic. I am in favor of making it more
generic rather putting specific words.


>
> I support the language proposed by Sumon whether or not he chooses to take
> my NIR suggestion.
>
> Owen
>
>
*  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] Amendment of SIG Charter

[Aftab Siddiqui]

Thanks Sumon bhai for the initiative,


Revised text suggest that all members/resource holders in APNIC are ISPs
only, I would suggest to make it "APNIC and NIR members or resource holders
in Asia Pacific region". Because not all members are resource holders.

Secondly, when you start mentioning topics in the charter then it may
create confusion moving forward that only these topics can be covered so
how about adding "not limited to" or "services related to resources" or
something like that.



Regards,

Aftab A. Siddiqui


On Sun, May 5, 2019 at 4:31 PM Sumon Ahmed Sabir  wrote:

> Dear Members,
>
>
> In the last APNIC meeting in Daejoan there was a discussion that there is
> a perception
>
> That Policy SIG discusses only about “Address Policy”. On the other hand
> there is a understanding
>
> that Policy SIG covers a wider range of registry issues, RPKI or any other
> topics that requires a
>
> procedures and rules.
>
>
> To avoid confusion and to bring clarity in the Policy Charter few
> proposals came in. That either we can change the Name of the Policy SIG
> to cover wider range or to amend the Policy-SIG Charter to bring clarity
> about the scope of Policy SIG.
>
>
> After discussions chairs feels that we can make some changes in the SIG
> Charter to bring clarity:
>
>
>
> Current SIG Charter https://www.apnic.net/community/policy/policy-sig/
>  says:
>
>
>
> ‘The Policy SIG charter is to develop policies and procedures which relate
> to the management and
>
> use of Internet address resources by APNIC, NIRs, and ISPs within the Asia
> Pacific region.”
>
>
> And here is the possible changes proposed:
>
>
>  “The Policy SIG charter is to develop policies which relate to
> the management and use of Internet  address resources by APNIC, NIRs,
> and ISPs within the Asia Pacific region.  These include policies for
> resource allocation, recovery and transfer, and for resource registration
> within whois, reverse DNS, RPKI and related services.”
>
>
> Please share your views, comments or suggestions in this regard.
>
>
>
> Sincerely,
>
>
> Sumon, Bertrand and Ching-Heng
>
> Chairs, Policy-SIG
> *  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
*  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] Policy Proposal: prop-130-v001: Modification of transfer policies

[Aftab Siddiqui]

If I may ask the author.

- Explain the problem statement.
- Can you provide an example where this "unclear policy of M" created a
problem?
- Did you ask Secretariat if this is actually a problem? Did they provide
any stats?

Regards,

Aftab A. Siddiqui


On Thu, Mar 14, 2019 at 11:59 PM Sumon Ahmed Sabir 
wrote:

>
> Dear SIG members,
>
> The proposal "prop-130-v001: Modification of transfer policies"
> has been sent to the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 48 in
> Chiang Mai, Thailand on Thursday, 12 September 2019.
>
> We invite you to review and comment on the proposal on the mailing list
> before the meeting.
>
> The comment period on the mailing list before an APNIC meeting is an
> important part of the policy development process. We encourage you to
> express your views on the proposal:
>
>   - Do you support or oppose this proposal?
>   - Does this proposal solve a problem you are experiencing? If so,
> tell the community about your situation.
>   - Do you see any disadvantages in this proposal?
>   - Is there anything in the proposal that is not clear?
>   - What changes could be made to this proposal to make it more
> effective?
>
> Information about this proposal is available at:
>
> http://www.apnic.net/policy/proposals/prop-130
>
> Regards
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> *  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
*  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

[sig-policy] IANA Recovered Space

[Aftab Siddiqui]

Dear APNIC Secretariat,
Can you please confirm if this is what APNIC got from IANA recovered pool
in 2018.

160.238.0.0/24 APNIC 2018-03
192.26.110.0/24 APNIC 2018-03
192.75.137.0/24 APNIC 2018-03
192.135.99.0/24 APNIC 2018-03
192.145.228.0/23 APNIC 2018-03
192.156.144.0/24 APNIC 2018-03
192.156.220.0/24 APNIC 2018-03
192.197.113.0/24 APNIC 2018-09
199.212.57.0/24 APNIC 2018-09
204.52.191.0/24 APNIC 2018-09
192.51.188.0/24 APNIC 2018-09

Regards,

Aftab A. Siddiqui
*  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-127 announcement : Change maximum delegation size of 103/8 IPv4 address, pool to a /23

[Aftab Siddiqui]

Hi Satoru san,
Thanks for gathering feedback from the community. Let me try to respond.


> * I am worried that the change a allocation size and this discussion
> will be repeated each time the 103/8 address pool decreases.
>

> * It should be /24 in this time if it will be changed it in the future.
>
> * I'd like to know the reason why "/23", not "/24" or other prefix size.
>

There are only 2 viable options, either /23 or /24 there can not be any
other prefix size. I believe /23 is big enough for a new entrant whether a
small ISP or an enterprise to keep their infrastructure dual stacked or
keep it for a transition technology.


>
> * /23 seems too small for a newcomer.
>

Its a contradicting to above 2 points. If /23 is small then how come /24 is
enough? and as of today how /22 was enough?


> * A Newcomer can choose a transfer as a alternative if the proposal not
> reach consensus.
>

Yes they can abosolutely. But we need to manage the resources available at
the moment in the best possible way.


>
>
> Best Regards,
>
> Satoru Tsurumaki
> JPOPF-ST
>
> 2019年1月18日(金) 15:17 Bertrand Cherrier :
>
>> Dear SIG members,
>>
>> The proposal "prop-127-v001: Change maximum delegation size of 103/8
>> IPv4 address pool to a /23" has been sent to the Policy SIG for review.
>>
>> It will be presented at the Open Policy Meeting at APNIC 47 in
>> Daejeon, South Korea on Wednesday, 27 February 2019.
>>
>> We invite you to review and comment on the proposal on the mailing list
>> before the meeting.
>>
>> The comment period on the mailing list before an APNIC meeting is an
>> important part of the policy development process. We encourage you to
>> express your views on the proposal:
>>
>>- Do you support or oppose this proposal?
>>- Does this proposal solve a problem you are experiencing? If so,
>>tell the community about your situation.
>>- Do you see any disadvantages in this proposal?
>>- Is there anything in the proposal that is not clear?
>>- What changes could be made to this proposal to make it more
>>effective?
>>
>> Information about this proposal is available at:
>>
>> http://www.apnic.net/policy/proposals/prop-127
>>
>> Regards
>>
>> Sumon, Bertrand, Ching-Heng
>> APNIC Policy SIG Chairs
>> --
>>
>> prop-127-v001: Change maximum delegation size of 103/8 IPv4 address
>> pool to a /23
>> --
>>
>> Proposers: Ching-Heng Ku, Aftab Siddiqui, Yen-Chieh Wang
>> c...@twnic.tw
>> 1. Problem Statement
>>
>> This is a proposal to change the maximum size of IPv4 address delegations
>> from the APNIC 103/8 IPv4 address pool [1] to a /23.
>> 2. Objective of policy change
>>
>> The current final /8 allocation policy[1] requires that the current
>> minimum
>> delegation size for IPv4 is a /24 and each APNIC account holder is only
>> eligible
>> to receive IPv4 address delegations totalling a maximum /22 from the
>> APNIC 103/8
>> IPv4 address pool.
>>
>> According to the APNIC IPv4 Address Report, https://ipv4.potaroo.net/,
>> remaining
>> addresses in the APNIC 103/8 pool are 42.8%, 33.3%, 23.4% of /8 in the
>> end of
>> 2016, 2017, and 2018, respectively. The remaining number of APNIC 103/8
>> IPv4
>> address pool for APNIC account holder is less and less. It is predicted
>> that
>> the 103/8 pool will be exhausted in 2020.
>>
>> Reducing the maximum IPv4 delegation size from APNIC 103/8 IPv4 address
>> pool can
>> prolong the exhaustion time of the 103/8. Newcomers of APNIC account
>> holders will
>> have the benefit in this period of time. New companies can obtain some
>> IPv4 address
>> space in the APNIC service region without the need to trade for address
>> space and
>> can make the preparation for the subsequent IPv6 migration.
>>
>> It is recommended that the number of assigned IPv4 addresses in Final /8
>> be reduced
>> from a maximum of /22 to /23. It will be estimated to extend the
>> exhaustion time
>> for at least three years or more.
>> 3. Situation in other regions
>>
>> There is no similar policy in place in other RIR regions.
>> 4. Proposed policy solution
>>
>> It is proposed to modify the 6.1 Minimum and maximum IPv4 delegations of
>> the APNIC
>> Internet Number Resource Policies[1].
>>
>> This proposal is to change the maximum size of IPv4 address delegations
>> from the
>> APNIC 103/8 I

Re: [sig-policy] prop-129-v001: Abolish Waiting list for unmet IPv4 requests

[Aftab Siddiqui]

Hi Ernest,


> I support this proposal but not all of the view.
>

Thanks for your partial support, I hope I will be able to transform it in
full support :)


> The point:
> The last APNIC 103/8 block is a brand new came from IANA, unused IPv4
> block, and it is never used by other user on the Internet from other RIR.
>

This SHOULD be the case but unfortunately, it isn't true. Let me explain it
why. As I'm writing this email, there are 43 prefixes from 103/8 block on
the global routing table which are not allocated to anyone by APNIC. Yes,
43 Bogons from 103/8. All these prefixes are most likely to be allocated to
new members in the future. They are "used" and probably "abused" prefixes
by all means. [source: cidr-report.org]


> The recovered pool IP block is used by other user from other RIR may be.
>

Same is the case with 103/8 block


> If the recovered pool IP will assign to the new member, would it have some
> problem when use it ?
>

All the recovered blocks have the same issues like 103/8.



> Best Regards,
>
> Ernest Tse
>
>
> On Tue, 22/01/2019 08.15, Bertrand Cherrier 
> wrote:
>
> Dear SIG members,
>
> The proposal "prop-129-v001: Abolish Waiting list for unmet IPv4
> requests" has been sent to the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 47 in
> Daejeon, South Korea on Wednesday, 27 February 2019.
>
> We invite you to review and comment on the proposal on the mailing list
> before the meeting.
>
> The comment period on the mailing list before an APNIC meeting is an
> important part of the policy development process. We encourage you to
> express your views on the proposal:
>
>- Do you support or oppose this proposal?
>- Does this proposal solve a problem you are experiencing? If so, tell
>the community about your situation.
>- Do you see any disadvantages in this proposal?
>- Is there anything in the proposal that is not clear?
>- What changes could be made to this proposal to make it more
>effective?
>
> Information about this proposal is available at:
>
>  http://www.apnic.net/policy/proposals/prop-129
>
> Regards
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> --
>
> prop-129-v001: Abolish Waiting list for unmet IPv4 requests
> --
>
> Proposers: Aftab Siddiqui
> aftab.siddi...@gmail.com
> 1. Problem Statement
>
> The current APNIC IPv4 Policy allows each APNIC account holder to receive
> up to a /22 from the IPv4 Recovered Pool after they have received a /22
> from
> the final /8 pool (103/8). However, the Recovered Pool may not always have
> enough resources for delegation, therefore a waiting list was created. The
> position of a Member on the waiting list is strictly determined by the date
> and time that the Member’s completed request received by APNIC. At the time
> of writing, there are 658 members in the waiting list. In 2018, APNIC
> received 10 x /24 and 1 x /23 (equal to 3 x /22) from IANA recovered pool.
> In the same year, more than 400 members were added to the waiting list
> where the majority were requesting for /22. IANA recovered address
> delegations
> are shrinking to a level where it is impossible to provide IPv4
> resources to
> current 658 members in the waiting list.
> 2. Objective of policy change
>
> The objective is to remove the waiting list as the IANA or APNIC
> recovered address
> space is not enough. All the members in the waiting list already have a
> minimum of
> /22 address space from last /8 (103/8) address block. Whatever is
> recovered by IANA
> or by APNIC should be left aside to new members ONLY.
> 3. Situation in other regions
>
> Please correct if otherwise
> ARIN - returned and/or recovered address space is added to the ARIN's
> free pool
> RIPE NCC - returned and/or recovered address space is added to the RIPE
> NCC’s free pool
> LACNIC - returned and/or recovered address space is added to reserve block
> AFRINIC - No Clear
> 4. Proposed policy solution
>
> Abolish the current waiting list and once the APNIC receives IPv4
> recovered address
> space from IANA or recovered by themselves (through closures or returns
> etc) then
> it should be treated under the same policy as last /8 (103/8).
>
> A waiting list will be created once APNIC runs out of resources in last
> /8 and same
> last /8 allocation policy will be applied to the waiting list.
> 5. Advantages / Disadvantages
>
> Advantages:
> Removing an unnecessary waiting list and able to utilize the recovered
> address pool
> as part of available IPv4 resources or last /8.
>
> It wi

Re: [sig-policy] prop-120: waiting list management

[Aftab Siddiqui]

[image: image.png]
×

This is what APNIC got from the recovered pool yesterday. This will serve 2
members on the waiting list since Jan 2017. After that, the waiting list
will be of 426 members. We need something close to /13 (or /14+/15+/16) to
clear the existing waiting list (assuming that all members are requesting
for /22)

On Fri, 23 Feb 2018 at 17:16 藤崎智宏  wrote:

> Dear policy sig colleagues,
>
> I got a clarification question from APNIC secretariat about waiting
> list management.
> Let me share my answer for that question.
>
> Q:
> Currently, we still have IPv4 addresses available in the 103/8 pool,
> so when NEW members
> apply for IPv4 delegation, they always first receive from the 103/8
> pool, before they receive
> delegation from the non-103/8 pool. However, after the 103/8 pool
> exhaustion, it is possible
> there are IPv4 addresses available in the non-103/8 but not in 103/8 pool.
>
> In this case, should new members be able to first receive delegations
> from the non-103/8 pool without wait listed for 103/8 pool?
>
> A:
> With my current proposal, approved new member requests up to /22 will
> be placed on
> 103/8 pool waiting list and approved addition amount (maximum /22)
> will be placed on
>  non-103/8 pool waiting list.
>
> If there are other questions or comments, please let me know.
>
> Thank you!
>
> Yours Sincerely,
> ---
> Tomohiro Fujisaki
> *  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
>
-- 
Best Wishes,

Aftab A. Siddiqui
*  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

[sig-policy] Fwd: Call for volunteers to participate in ASO Review Working Group

[Aftab Siddiqui]

[Apologies for cross-posting]

For Policy SIG and Cooperation SIG folks.
If you are still interested in joining in as a volunteer then please
contact me or Izumi Okutani. If you want to observe and participate in the
discussion happening in this WG then you can join the mailing list [1] and
also can join us at the ASO-Review consultation session [2]

[1] https://mailman.apnic.net/mailman/listinfo/wg-aso-review
[2]
https://2018.apricot.net/program/schedule/#/day/9/aso-review-consultation

-- Forwarded message -
From: Aftab Siddiqui <aftab.siddi...@gmail.com>
Date: Mon, 29 Jan 2018 at 19:13
Subject: Call for volunteers to participate in ASO Review Working Group
To: apnic-t...@apnic.net <apnic-t...@apnic.net>


_
Call for volunteers to participate in ASO Review Working Group
_

At APNIC 44, Izumi Okutani and I accepted nominations to chair an ASO
Review Working Group to help collate feedback from the APNIC community on
the ASO Review, and report the community’s input to the NRO.

Ahead of the next consultation session at APRICOT 2018 in Kathmandu, Nepal,
we would like to invite volunteers to join the Working Group (WG) to assist
us in this task. We also would like to invite all other interested
community members to join the mailing list to contribute to discussions on
the ASO Review.

All interested participants can join the WG mailing list here:

https://mailman.apnic.net/mailman/listinfo/wg-aso-review

Volunteers for the WG can email their interest to the APNIC Secretariat [
secretar...@apnic.net] by 14th February 2018.

For details, you are welcome to join us for the Webinar on Wednesday, 7
February 2018 at 1400 Brisbane time (UTC+10), information for webinar has
been announced by the APNIC Secretariat earlier.

For more background information on the ASO Review consultation process, and
to read the ASO Review Report, visit:

https://www.nro.net/aso-review-consultation-2018/

To view the presentations made at the first APNIC community consultation
held at APNIC 44 in Taichung, Taiwan, in September 2017, visit:

https://conference.apnic.net/44/program/schedule/#/day/7/address-supporting-organisation-aso-review

We thank you in advance for your participation.

Kind regards

Izumi Okutani and Aftab Siddiqui
Chairs, ASO Review Working Group
-- 
Best Wishes,

Aftab A. Siddiqui
-- 
Best Wishes,

Aftab A. Siddiqui
*  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-123-v001: Modify 103/8 IPv4 transfer policy

[Aftab Siddiqui]

Hi Alex,

> 1. Problem statement
> ---
>
> Policy Proposal prop-116-v006: Prohibit to transfer IPv4 addresses in
> the final /8 block reached consensus at the APNIC 44 AMM on 14 Sep
> 2017. Since that APNIC has stopped all the IPv4 transfers from 103/8
> block if the delegation date is less than 5 years.
>
> However, some of the 103/8 ranges were delegated before 14 Sep 2017.
> Those resources should not be subjected to 5 years restriction. The
> community was not aware of the restriction when they received those
> resources, some of the resources have been transferred or planning to
> transfer.
>
> ftp://ftp.apnic.net/apnic/docs/membership-agreement.txt

5General


5.1APNIC Documents
The Member agrees that:
(a) The APNIC Documents may be amended from time to time in
accordance with the Document Review Policy;
(b) Any such amendments are binding upon the Member;
(c) APNIC Documents as they exist from time to time form an integral
part of and apply fully to this agreement; and


If APNIC is not allow those transfers to be registered,
> there will be underground transfers.
>
> You mean leasing? or resource holder gives away access to myapnic account
along with resources? because there is no such thing as underground
transfer.

> This will cause incorrect APNIC Whois data.
>
>  I appreciate your intentions.
-- 
Best Wishes,

Aftab A. Siddiqui
*  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] [Sig-policy] prop-118: No need policy in APNIC region, to be dis cussed at APNIC 44 Policy SIG

[Aftab Siddiqui]

*Recipient could not demonstrate needs:   1*

Everyone is entitled to have their own opinion after reading the data.

On Wed, 23 Aug 2017 at 13:04 Lu Heng <h...@anytimechinese.com> wrote:

> My reads to the data shows exact needs for the policy.
>
> So don't blame data.
>
> On Wed, Aug 23, 2017 at 16:03 Aftab Siddiqui <aftab.siddi...@gmail.com>
> wrote:
>
>>
>>> I don't think George's data can leads your conclusion.
>>>
>>>
>> If the data from APNIC Sec can't help you to make up your mind then there
>> is nothing I can do. The information was good enough for me.
>>
>>
>>>
>>> On Wed, Aug 23, 2017 at 15:35 Aftab Siddiqui <aftab.siddi...@gmail.com>
>>> wrote:
>>>
>>>> Thanks George for the details.
>>>>
>>>> So this policy is trying to solve the problems which don't exist.
>>>>
>>>>
>>>> On Wed, 23 Aug 2017 at 12:28 George Kuo <geo...@apnic.net> wrote:
>>>>
>>>>> Hi Aftab,
>>>>>
>>>>> Thanks for your patience. I now have more information for you.
>>>>>
>>>>> Total number of IPv4 market transfers that did not get completed in the
>>>>> last 12 months is 97.
>>>>>
>>>>> Below is the breakdown of reasons:
>>>>> Fraud:   4
>>>>> Recipient could not demonstrate needs:   1
>>>>> Recipient did not accept transfer:   6
>>>>> Requests corrected as M transfer: 23
>>>>> No response from member:30
>>>>> Member requested to cancel transfer:33
>>>>>
>>>>> As far as administration of these requests is concerned, it's just part
>>>>> of hostmasters routines required by the APNIC policy.
>>>>>
>>>>>
>>>>> George
>>>>>
>>>>>
>>>>> On 18/8/17 6:48 pm, George Kuo wrote:
>>>>> > Hi Aftab,
>>>>> >
>>>>> > For 2017, the secretariat has processed 158 market transfers as of 15
>>>>> > August. So, this is roughly about 5 transfer requests a week.
>>>>> > On average, it takes about 4-5 responses from APNIC hostmasters to
>>>>> > complete a transfer request. We have a procedure to respond to a
>>>>> > correspondence within two working days.
>>>>> >
>>>>> > We are getting the rest of the answers for you. I'll come back to
>>>>> you as
>>>>> > soon as I have the information.
>>>>> >
>>>>> > thanks,
>>>>> >
>>>>> > George
>>>>> >
>>>>> >
>>>>> > On 18/8/17 3:29 pm, Aftab Siddiqui wrote:
>>>>> >> Dear APNIC Sec,
>>>>> >>
>>>>> >> Can you share some stats:
>>>>> >>
>>>>> >> - How many transfers request denied in last 12 months?
>>>>> >> - How many requests were denied just because of bad documentation?
>>>>> >> - How many transfer request you are receiving every week?
>>>>> >> - How long does it take to process a transfer request?
>>>>> >> - Does it create any administrative burden?
>>>>> >>
>>>>> >> On Wed, 9 Aug 2017 at 16:14 chku <c...@twnic.net.tw
>>>>> >> <mailto:c...@twnic.net.tw>> wrote:
>>>>> >>
>>>>> >> Dear SIG members
>>>>> >>
>>>>> >> The proposal "prop-118: No need policy in APNIC region" was
>>>>> >> discussed at
>>>>> >> APNIC 43 Policy SIG, but did not reach consensus.
>>>>> >>
>>>>> >> It will be presented at the Open Policy Meeting at APNIC 44
>>>>> which
>>>>> >> will
>>>>> >> be held in Taichung, Taiwan on Wednesday and Thursday, 14 & 15
>>>>> >> September
>>>>> >> 2017.
>>>>> >>
>>>>> >> Information about the proposal is available from:
>>>>> >>
>>>>> >> http://www.apnic.net/policy/proposals/prop-118
>>>>> >>
>>>>> >> You are encouraged to express your views on the proposal:
>>>>&

Re: [sig-policy] [Sig-policy] prop-118: No need policy in APNIC region, to be dis cussed at APNIC 44 Policy SIG

[Aftab Siddiqui]

>
> I don't think George's data can leads your conclusion.
>
>
If the data from APNIC Sec can't help you to make up your mind then there
is nothing I can do. The information was good enough for me.


>
> On Wed, Aug 23, 2017 at 15:35 Aftab Siddiqui <aftab.siddi...@gmail.com>
> wrote:
>
>> Thanks George for the details.
>>
>> So this policy is trying to solve the problems which don't exist.
>>
>>
>> On Wed, 23 Aug 2017 at 12:28 George Kuo <geo...@apnic.net> wrote:
>>
>>> Hi Aftab,
>>>
>>> Thanks for your patience. I now have more information for you.
>>>
>>> Total number of IPv4 market transfers that did not get completed in the
>>> last 12 months is 97.
>>>
>>> Below is the breakdown of reasons:
>>> Fraud:   4
>>> Recipient could not demonstrate needs:   1
>>> Recipient did not accept transfer:   6
>>> Requests corrected as M transfer: 23
>>> No response from member:30
>>> Member requested to cancel transfer:33
>>>
>>> As far as administration of these requests is concerned, it's just part
>>> of hostmasters routines required by the APNIC policy.
>>>
>>>
>>> George
>>>
>>>
>>> On 18/8/17 6:48 pm, George Kuo wrote:
>>> > Hi Aftab,
>>> >
>>> > For 2017, the secretariat has processed 158 market transfers as of 15
>>> > August. So, this is roughly about 5 transfer requests a week.
>>> > On average, it takes about 4-5 responses from APNIC hostmasters to
>>> > complete a transfer request. We have a procedure to respond to a
>>> > correspondence within two working days.
>>> >
>>> > We are getting the rest of the answers for you. I'll come back to you
>>> as
>>> > soon as I have the information.
>>> >
>>> > thanks,
>>> >
>>> > George
>>> >
>>> >
>>> > On 18/8/17 3:29 pm, Aftab Siddiqui wrote:
>>> >> Dear APNIC Sec,
>>> >>
>>> >> Can you share some stats:
>>> >>
>>> >> - How many transfers request denied in last 12 months?
>>> >> - How many requests were denied just because of bad documentation?
>>> >> - How many transfer request you are receiving every week?
>>> >> - How long does it take to process a transfer request?
>>> >> - Does it create any administrative burden?
>>> >>
>>> >> On Wed, 9 Aug 2017 at 16:14 chku <c...@twnic.net.tw
>>> >> <mailto:c...@twnic.net.tw>> wrote:
>>> >>
>>> >> Dear SIG members
>>> >>
>>> >> The proposal "prop-118: No need policy in APNIC region" was
>>> >> discussed at
>>> >> APNIC 43 Policy SIG, but did not reach consensus.
>>> >>
>>> >> It will be presented at the Open Policy Meeting at APNIC 44 which
>>> >> will
>>> >> be held in Taichung, Taiwan on Wednesday and Thursday, 14 & 15
>>> >> September
>>> >> 2017.
>>> >>
>>> >> Information about the proposal is available from:
>>> >>
>>> >> http://www.apnic.net/policy/proposals/prop-118
>>> >>
>>> >> You are encouraged to express your views on the proposal:
>>> >>
>>> >>  - Do you support or oppose the proposal?
>>> >>  - Do you see any disadvantages in this proposal?
>>> >>  - Is there anything in the proposal that is not clear?
>>> >>  - What changes could be made to this proposal to make it more
>>> >> effective?
>>> >>
>>> >> Please find the text of the proposal below.
>>> >>
>>> >> Kind Regards,
>>> >>
>>> >> Sumon, Bertrand, Ching-Heng
>>> >> APNIC Policy SIG Chairs
>>> >>
>>> >>
>>> >> ---
>>> >>
>>> >> prop-118-v001: No need policy in APNIC region
>>> >>
>>> >> ---
>>> >>
>>> >> Proposer:   David Hilario
>>> >> d.hila...@laruscloudservice.net
>>> &g

Re: [sig-policy] prop-119: Temporary transfers, to be discussed at APNIC 44 Polic y SIG

[Aftab Siddiqui]

> It is already a possibility in the RIPE region to do such transfers.
>
>
And?


> It is really to cover a corner case where organisations are not able
> or interested in receiving the IP space in form of assignments or
> sub-allocations, but need them to be part of their own registry for
> full control of the space and only for a pre-set amount of time.
>

Solution is simple, if the organization is not interested in receiving the
resources as assignments and sub-allocations then just buy it.

What is full control? creation of route-objects? or anything which can't be
done by sending an email to helpd...@apnic.net?


> I do not believe that spammer would benefit from this policy as they
> would have to register with APNIC as members and provide all the
> needed paperwork such as company registration papers, ID/passports,
> billing address etc...
>

It will definitely support the spammers by all means. You temperorary
transfer resource to Spammer, they do their thing and get black listed
everywhere and then you get the resources back and ask everyone that we are
the new owner of this resource so kindly remove all the listing. REPEAT.


> They are much better off renting a /24 from the black market with no
> traces or documented changes ion the address block.
>

Yup, let them pay black market rates for black market business model.

And what will be the temporary transfer fees? same as permanent transfer
fees? or free?

In order to resolve a corner case it will open up opertunities for
spammers. I stronly oppose it.
-- 
Best Wishes,

Aftab A. Siddiqui
*  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-118-v001: No need policy in APNIC region

[Aftab Siddiqui]

Hi George,
Thanks for quick response and clarification.

Again, still not sure what problem we are trying to solve? Haven't seen a
single use case.

On Sun, 26 Feb 2017 at 10:02 George <geo...@apnic.net> wrote:

>
> Hi Aftab,
>
> We are happy to share more information if we have the permission from
> the account holder. Otherwise, it is not possible for the APNIC
> Secretariat to disclose individual account and request information on
> the public mailing list.
>
>
> George Kuo
> APNIC
>
> On 25/2/17 10:04 pm, Aftab Siddiqui wrote:
> > Interesting.
> >
> > I hope secretariat/hostmaster can comment.
> >
> > On Sat, 25 Feb 2017 at 12:32 Pacswitch Email <ernest@pacswitch.com
> > <mailto:ernest@pacswitch.com>> wrote:
> >
> > Dear all,
> >
> > I can tell you my real experience with APNIC, when I want to
> > transfer my unused IP ranges to a Singapore based ISP from my
> > account, they deny it!! That is ridiculous! They said I cannot
> > transfer! I cannot believe it if the IP address I owned but I cannot
> > transfer it to a new owner.
> >
> > Can anyone tell me who has the same experience?
> >
> > Ernest Tse
> >
> > Sent from Mobile
> >
> > David Hilario <d.hila...@laruscloudservice.net
> > <mailto:d.hila...@laruscloudservice.net>> 於 2017年2月25日 12:24 寫道：
> >
> >>
> >> Hi,
> >>
> >> The justification for the needs was/is great to have in place to
> >> protect a free pool of scarce resources.
> >>
> >> Maintaining a correct registry, with the proper information is one
> >> of the core responsibilities of the RIRs, and as a community we
> >> must develop policies that allows the RIR to do that job in the
> >> most easy and convenient manner, no need would enable that for
> >> APNIIC, their time can then be spent on other things.
> >>
> >> Unused resources, ideally should be returned to the free pool, but
> >> that almost never happen voluntarily, they will instead be
> >> transferred, or even simply assigned or sub-allocated, no real big
> >> difference here, just different values in the Database and
> >> different real world contracts, some Database editing you can do
> >> yourself, others you need to ask your RIR for assistance.
> >>
> >> Resources that get transferred are not issued by the RIR from
> >> their free pool, they are already out there, I do not see any
> >> positive impact if APNIC rejects a transfer because the recipient
> >> cannot justify the whole prefix to be transferred.
> >>
> >> It will not increase the free pool available at APNIC.
> >> It may as well cancel the whole transfer.
> >> If initially rejected and further information is needed, it delays
> >> what is a very sensitive process, where both the offering and
> >> receiving party wants the whole process rounded up as fast as
> >> possible.
> >>
> >> RIPE region has had the "no need policy" in place for years, I
> >> don't believe any sign of massive hoarding for speculative purpose
> >> is visible over there (Multiple membership process gets abused,
> >> but that is another issue altogether).
> >> Large transfers were made, and you do not need to have access to
> >> any stats to know those organisations needed that space,
> >> justifying large allocations can be extremely time consuming and
> >> ultimately detrimental to the overall LIR's business.
> >>
> >>
> >> David Hilario
> >>
> >> /IP Manager/
> >>
> >> *Larus Cloud Service Limited*
> >>
> >> p: +852 29888918 <+852%202988%208918> <tel:+852%202988%208918>  m: +359
> 89 764 1784 <+359%2089%20764%201784>
> >> <tel:+359%2089%20764%201784>
> >> f:+852 29888068 <+852%202988%208068> <tel:+852%202988%208068>
> >> a:Flat B5, 11/F, TML Tower, No.3 Hoi Shing Road, Tsuen Wan, HKSAR
> >> w:laruscloudservice.net/uk <http://laruscloudservice.net/uk>
> >> e: d.hila...@laruscloudservice.net
> >> <mailto:d.hila...@outsideheaven.com>
> >>
> >>
> >> On 25 February 2017 at 02:03, Owen DeLong <o...@delong.com
> >> <mailto:o...@delong.com>> wrote:
> >>
> >&

Re: [sig-policy] prop-118-v001: No need policy in APNIC region

[Aftab Siddiqui]

Interesting.

I hope secretariat/hostmaster can comment.

On Sat, 25 Feb 2017 at 12:32 Pacswitch Email <ernest@pacswitch.com>
wrote:

> Dear all,
>
> I can tell you my real experience with APNIC, when I want to transfer my
> unused IP ranges to a Singapore based ISP from my account, they deny it!!
> That is ridiculous! They said I cannot transfer! I cannot believe it if the
> IP address I owned but I cannot transfer it to a new owner.
>
> Can anyone tell me who has the same experience?
>
> Ernest Tse
>
> Sent from Mobile
>
> David Hilario <d.hila...@laruscloudservice.net> 於 2017年2月25日 12:24 寫道：
>
>
> Hi,
>
> The justification for the needs was/is great to have in place to protect a
> free pool of scarce resources.
>
> Maintaining a correct registry, with the proper information is one of the
> core responsibilities of the RIRs, and as a community we must develop
> policies that allows the RIR to do that job in the most easy and convenient
> manner, no need would enable that for APNIIC, their time can then be spent
> on other things.
>
> Unused resources, ideally should be returned to the free pool, but that
> almost never happen voluntarily, they will instead be transferred, or even
> simply assigned or sub-allocated, no real big difference here, just
> different values in the Database and different real world contracts, some
> Database editing you can do yourself, others you need to ask your RIR for
> assistance.
>
> Resources that get transferred are not issued by the RIR from their free
> pool, they are already out there, I do not see any positive impact if APNIC
> rejects a transfer because the recipient cannot justify the whole prefix to
> be transferred.
>
> It will not increase the free pool available at APNIC.
> It may as well cancel the whole transfer.
> If initially rejected and further information is needed, it delays what is
> a very sensitive process, where both the offering and receiving party wants
> the whole process rounded up as fast as possible.
>
> RIPE region has had the "no need policy" in place for years, I don't
> believe any sign of massive hoarding for speculative purpose is visible
> over there (Multiple membership process gets abused, but that is another
> issue altogether).
> Large transfers were made, and you do not need to have access to any stats
> to know those organisations needed that space, justifying large allocations
> can be extremely time consuming and ultimately detrimental to the overall
> LIR's business.
>
>
> David Hilario
>
> *IP Manager*
>
> *Larus Cloud Service Limited*
>
> p: +852 29888918 <+852%202988%208918>  m: +359 89 764 1784
> <+359%2089%20764%201784>
> f: +852 29888068 <+852%202988%208068>
> a: Flat B5, 11/F, TML Tower, No.3 Hoi Shing Road, Tsuen Wan, HKSAR
> w: laruscloudservice.net/uk
> e: d.hila...@laruscloudservice.net <d.hila...@outsideheaven.com>
>
> On 25 February 2017 at 02:03, Owen DeLong <o...@delong.com> wrote:
>
> I disagree…
>
> I believe that needs testing still preserves the idea of distributing
> addresses to those with need even in a post-exhaustion world.
>
> This serves to discourage speculative transactions and other transfers to
> those not actually needing addresses which would only drive prices up and
> not provide any benefit to the community.
>
> Owen
>
> On Feb 24, 2017, at 08:32 , Pacswitch Email <ernest@pacswitch.com>
> wrote:
>
> Hello all,
>
> I agreed that APNIC should accept all transfer without question because IP
> resource could be count into a assets to the IP holder in accounting.
> That's mean the ip holder have the right to request transfer to or from
> other APNIC members or other RIR.
>
> Ernest Tse
>
> Sent from Mobile
>
> David Hilario <d.hila...@laruscloudservice.net> 於 2017年2月24日 22:04 寫道：
>
>
>
> Hi Aftab,
>
> This is only to simplify things, need based policies are there to protect
> the free pool from exhaustion and ensure fair distribution.
>
> Space that is already out there can already be transferred without much
> hassle, removing the need base justification just simplifies the whole
> process, making the transfer faster and smoother.
>
>
> David Hilario
>
> *IP Manager*
>
> *Larus Cloud Service Limited*
>
> p: +852 29888918 <+852%202988%208918>  m: +359 89 764 1784
> <+359%2089%20764%201784>
> f: +852 29888068 <+852%202988%208068>
> a: Flat B5, 11/F, TML Tower, No.3 Hoi Shing Road, Tsuen Wan, HKSAR
> w: laruscloudservice.net/uk
> e: d.hila...@laruscloudservice.net <d.hila...@outsideheaven.com>
>
> On 22 February 2017 at 10:04, Aft

Re: [sig-policy] prop-117-v001: Returned IPv4 address management and Final /8 exhaustion

[Aftab Siddiqui]

Thanks for the reference. So there is no policy. During APNIC42 secretariat
was seeking clarification for APNIC's Internet Number Resources Policy

APNIC-127-v002
*6.1.1. Additional allocation rounds*
Address space returned to APNIC, or allocated to APNIC from the 'IANA
Recovered IPv4 Pool' will be added to the non-103/8 IPv4 address pool. If
address space in this pool becomes sufficient to delegate a further /22 to
each APNIC account holder, additional delegation rounds will be announced.

APNIC-127 is derived from various documents (apnic-089, apnic-094
apnic-109, apnic-116, apnic-123, apnic-124, apnic-125) and the above
statement probably came from apnic-124 which states:

"Following the additional delegation of IPv4 address space to APNIC from
the 'IANA Recovered IPv4 Pool' as the result of the "Global policy for post
exhaustion IPv4 allocation mechanisms by the IANA", from 27 May 2014, each
APNIC account holder will become eligible to request and receive additional
delegations up to a maximum of /22 address space from an APNIC non-103/8
IPv4 address pool."

Everywhere "non-103/8" has been mentioned. If APNIC member returns 103/8
address space then it shouldn't be re-allocated through above procedure.


On Sun, 29 Jan 2017 at 19:20 藤崎智宏 <fujis...@syce.net> wrote:

> Hi Aftab,
>
> 2017-01-29 20:54 GMT+09:00 Aftab Siddiqui <aftab.siddi...@gmail.com>:
> >
> >>
> >> 1. Problem statement
> >> 
> >> APNIC currently makes delegations from two IPv4 pools. These are the
> >> 103/8 (Final /8) pool and the non-103/8 IPv4 Recovered pool.
> >>
> >> With current policy, all returned address space, including 103/8 blocks,
> >> will be merged into the IPv4 Recovered pool.
> >
> >
> > Under which policy 103/8 returned addresses will be merged in recovered
> > pool? Please share the reference.
>
> My understanding is that after prop-105 was implemented, returned IPv4
> address processing was changed, and current practice is merging all
> returned addresses into the recovered pool.
>
> Please refer the transcript at APNIC 42, and chair's e-mail to the
> policy sig ML.
>
> Email:
>
> http://mailman.apnic.net/mailing-lists/sig-policy/archive/2016/11/msg1.html
>
> From the transcript of APNIC 42:
> https://conference.apnic.net/42/program#/schedule/day/8/policy-sig-3
>
>  > I think the Secretariat is
>  >
>  > looking for more input from the community about
>  >
>  > where returned 103s should be because currently we
>  >
>  > are putting them in the recovered pool, which would
>  >
>  > be very complicated if this policy went ahead.
>
> Yours Sincerely,
> ---
> Tomohiro Fujisaki
>
> 2017-01-29 20:54 GMT+09:00 Aftab Siddiqui <aftab.siddi...@gmail.com>:
> >
> >>
> >> 1. Problem statement
> >> 
> >> APNIC currently makes delegations from two IPv4 pools. These are the
> >> 103/8 (Final /8) pool and the non-103/8 IPv4 Recovered pool.
> >>
> >> With current policy, all returned address space, including 103/8 blocks,
> >> will be merged into the IPv4 Recovered pool.
> >
> >
> > Under which policy 103/8 returned addresses will be merged in recovered
> > pool? Please share the reference.
> >
> >
> > --
> > Best Wishes,
> >
> > Aftab A. Siddiqui
> >
> > *  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
>
-- 
Best Wishes,

Aftab A. Siddiqui
*  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-117-v001: Returned IPv4 address management and Final /8 exhaustion

[Aftab Siddiqui]

> 1. Problem statement
> 
> APNIC currently makes delegations from two IPv4 pools. These are the
> 103/8 (Final /8) pool and the non-103/8 IPv4 Recovered pool.
>
> With current policy, all returned address space, including 103/8 blocks,
> will be merged into the IPv4 Recovered pool.
>

Under which policy 103/8 returned addresses will be merged in recovered
pool? Please share the reference.


-- 
Best Wishes,

Aftab A. Siddiqui
*  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] Regarding Return Address spaces from 103/8 Pool

[Aftab Siddiqui]

Its better to wait for the updated version of prop-116 which hopefully will
address most of the issues raised here and were raised during APNIC42.
Tomohiro San agreed to come up with a solution so its just a matter of few
more weeks :)

On Thu, 24 Nov 2016 at 23:45 Sumon Ahmed Sabir 
wrote:

>
> Dear Community Members,
>
>
>
> Under current IPv4 policy, each APNIC account holder can request a /22
>
> from the Final /8 pool (103/8) and a /22 from the IPv4 Recovered Address
>
> Pool.
>
>
>
> There is currently a waiting list for delegations from the recovered
>
> address pool.
>
>
>
> If an APNIC Member closes their membership and returns a 103/8 block of
>
> addresses to APNIC, this space is placed in the recovered pool not in
>
> the Final /8 pool.
>
>
>
> The Secretariat would like to confirm where the policy community would
>
> like these addresses returned to, either the Final /8 Pool, or the IPv4
>
> Recovered Address Pool.
>
>
>
> Advantages of returning recovered 103/8 addresses to the Final /8 pool
>
>
>
> - The Final /8 pool will last longer.
>
>
>
> - Policies such as prop-116 are easier and fairer to implement.
>
>
>
> Disadvantage of returning recovered 103/8 addresses to the Final /8 pool
>
>
>
> - Not everybody receiving delegations from 103/8 will get a “clean”,
>
>unused block.
>
>
>
> - Members on the waiting list for addresses from the recovered pool
>
>will wait longer.
>
>
>
> Please reply to the mailing list to provide your feedback and opinion.
>
>
>
>
>
> Regards,
>
>
>
> Masato, Sumon
>
> APNIC Policy SIG Chairs
> *  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

-- 
Best Wishes,

Aftab A. Siddiqui
*  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] APNIC Whois Database Accuracy

[Aftab Siddiqui]

Hi Adam/Secretariat,

Just to get more information.

Can you please share the following stats.

- how many request APNIC received in last 12 months to correct the whois
record?
- how many active myapnic accounts we have as compare to total numbers of
active APNIC members. Assuming 1 myapnic account = 1 member?
- how many members have not created IRT object yet?
- how many emails bounce back from billing contacts (just an average per
month)?

On Tue, 21 Jun 2016 at 16:53 Jahangir Hossain <jahan...@parween.net> wrote:

> Thanks Aftab for your comments and information .
>
> We already know the importance of  Whois database accuracy specially the
> exchange of information for cyber security mitigation . if community have
> mixed comments then we can execute this as pilot project specially on IRT
> object or single country .
>
>
>
>
>
> *Regards / Jahangir *
>
> On Tue, Jun 21, 2016 at 12:21 PM, Aftab Siddiqui <aftab.siddi...@gmail.com
> > wrote:
>
>> I also support Gaurab’s idea to tag the authoritative of account holder.
>>> Besides i would like to add one point with Gaurab's idea ;* Can we send
>>> verification message through mail to account holder's corporate and
>>> technical contact person by quarterly/half a year/yearly basis?*
>>>
>>> if one of the contact person is not verify this information then account
>>> accessibility will be disable . Other wise it's really hard to make more
>>> reliable and accurate whois database that we are thinking .
>>>
>>>
>> +0.5
>>
>> I've been proposing this for years now (earlier in Network abuse BoF) and
>> recently did it in policy-sig and there was very mixed response. ARIN has
>> this policy but as per Leslie Noble (ARIN) it is not very successful in
>> their region but she also mentioned that they are planning to make few
>> changes in the process (need to reach out to her again for the update).
>>
>> For those who were not present there.. here is the transcript link
>> https://conference.apnic.net/data/41/20160225-Policy-SIG-2.txt
>> (hint: search my name)
>>
>> --
>> Best Wishes,
>>
>> Aftab A. Siddiqui
>>
>
>
>
> --
>
> --
Best Wishes,

Aftab A. Siddiqui
*  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] APNIC Whois Database Accuracy

[Aftab Siddiqui]

>
> I also support Gaurab’s idea to tag the authoritative of account holder.
> Besides i would like to add one point with Gaurab's idea ;* Can we send
> verification message through mail to account holder's corporate and
> technical contact person by quarterly/half a year/yearly basis?*
>
> if one of the contact person is not verify this information then account
> accessibility will be disable . Other wise it's really hard to make more
> reliable and accurate whois database that we are thinking .
>
>
+0.5

I've been proposing this for years now (earlier in Network abuse BoF) and
recently did it in policy-sig and there was very mixed response. ARIN has
this policy but as per Leslie Noble (ARIN) it is not very successful in
their region but she also mentioned that they are planning to make few
changes in the process (need to reach out to her again for the update).

For those who were not present there.. here is the transcript link
https://conference.apnic.net/data/41/20160225-Policy-SIG-2.txt
(hint: search my name)

-- 
Best Wishes,

Aftab A. Siddiqui
*  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] 1.2.3.4

[Aftab Siddiqui]

+1

 Please stop attempting to rearrange the deckchairs on the Titanic.

And I don't want to renumber my home network :) [its friday]

Regards,

Aftab A. Siddiqui
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Aftab Siddiqui]

Hi Izumi,


 Thanks. Helpful to know and that's consistent with how we handle ASN
 requests in JPNIC.


w.r.t JPNIC, do they ask for the details of those ASN (along with contact
details) with whom applicant is planning to multi-home in future? Do they
have any mechanism to check the authenticity of those ASN and contact
details provided?

Regards,

Aftab A. Siddiqui
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Aftab Siddiqui]

Thanks Guangliang for the update,


 According to the current APNIC ASN policy document, the definition of
 multihomed is as below.

 http://www.apnic.net/policy/asn-policy#3.4

 3.4 Multihomed

 A multi-homed AS is one which is connected to more than one other AS. An
 AS also qualifies as multihomed if it is connected to a public Internet
 Exchange Point.

 In the ASN request form, you will be asked to provide the estimate ASN
 implementation date, two peer AS numbers and their contact details. It is
 also acceptable if your network only connect to an IXP.


So what if I only have one upstream provider and doesn't have a Public IX
in place? What If I just whois any member from my country and provide AS
numbers and contact details publicly available? Do you check back after 3
months that the AS you provided to the applicant is actually peering with
the ones they mentioned in the application? Do you send email notification
to those contacts provided in the application that XYZ has mentioned your
AS to be peer with in future?

Regards,

Aftab A. Siddiqui.
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] [New Policy Proposal] prop-113: Modification in the IPv4 eligibility criteria

[Aftab Siddiqui]

Hi Dean

This proposal seems to advocates two things:

 The removal of any requirement for organisations to be multihomed


Yes,


 The removal of any needs based allocation for IPv4 address allocation.


Not exactly.



 The proposed wording states:

   Section 3.3: Criteria for small delegations
 An organization is eligible if it is currently multi-homed or
 inter-connected with provider (ISP)-based addresses, or demonstrates
 a plan to advertise the prefixes within 3 months.

 Can the authors clarify that their intended state is one where an LIR
 is only required to demonstrate a plan to advertise the addresses
 rather than demonstrate an actual need for them?


Let me give you the example from current policy text:

Current Section 3.3 para 2:
Organizations requesting a delegation under these terms must demonstrate
that they are able to use 25% of the requested addresses immediately and
50% within one year.

It means all LIRs who already got the prefixes under this policy used 50%
of the address space within an year? Because thats what they said while
submitting the application. Right?

I don't see any reason to force LIR to provide justification that how they
will use the prefixes with in 3 months or an year and now we are not
talking about /18s /17s any more. Or do you want to continue with
fabricated demonstrated need :)

Regards,

Aftab A. Siddiqui.
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Aftab Siddiqui]

Hi Dean,
Thanks for raising the question.

Could I ask that the APNIC hostmasters to comment on the following:

 Have you ever been made aware of a situation where due of the current
 wording of the relevant clauses in the policy, a member or potential member
 has not made a resource application where they would otherwise have been
 able to?


Would like to add something here to the question, have you even been made
aware of a situation where applicant provided wrong or fake multi-homing
information just to meet the criteria?


 In other words has the current policy in the eyes of the host masters
 ever been a barrier to entry?

 Very valid point.


Regards,

Aftab A. Siddiqui
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Aftab Siddiqui]

Hi Randy,

i liked dean's question.  is there actually a problem?  have folk who
 really needed asns not been able to get one under current policy?


Even, I liked Dean's question and would like to see what data hostmasters
have on this.


 randy, thinking of reintroducing the no more policies policy proposal.


I would love to see prop-108 again :)
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default allocation size

[Aftab Siddiqui]

Hi David,


 Also, correct me if I'm mistaken, but by raising the default from /32 to
 /29, you are raising the barrier to entry for small LIRs.  I believe
 APNIC's fees are based on your allocation size.  Yes, its a logarithmic
 function, but it still raises the fees.  So a small LIR that doesn't
 currently need a /29 may prefer to stick with a /32 for the lower fees.
  This policy seems to force all new allocations to /29, regardless of what
 an LIR needs or wants.  Minimally, this change should be optional, allowing
 an LIR request range a larger range, but not requiring a larger range.


IMO The whole idea of this prop is to remove the justification barrier to
get more address space during initial allocation or at subsequent
allocation level. No change in minimum initial allocation (/32 for LIRs and
/48 for end-sites) has been proposed (or atleast I don't see it). So any
who doesn't agree with the positives of /29 which came out during the
discussion here doesn't have to pay higher amount.. APNIC fee for /32 is
AUD 1,994 and for /29 it is AUD 4,381 (provided that you don't have more
then /22 IPv4)

*Proposed Changes (as requested in prop):*

*Organizations that meet the initial allocation criteria are eligible to
receive an initial allocation of /32. For allocations up to /29 no
additional documentation is necessary. *

*And for existing members*

*LIRs that hold one or more IPv6 allocations are able to request extension
of each of these allocations up to a /29 without meeting the utilization
rate for subsequent allocation and providing further documentation.*
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy