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

J Khan

________________________________
From: Srinivas Chendi <su...@apnic.net>
Sent: Tuesday, 27 August 2019 7:25 AM
To: Javed Khan <javedkha...@outlook.com>
Cc: mailman_SIG-policy <sig-pol...@apnic.net>
Subject: Re: [sig-policy] prop-132-v002: AS0 for Bogons

Hi Javed,

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

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

Regards
Sunny

On 24/08/2019 12:28 am, Javed Khan wrote:
> For now, I'm neither for or against this proposal. I think the intention
> of the author is good but the implementation is not as easy as is
> explained in the proposal. QoS is very crucial for ISPs to sustain the
> fierce market competition and if APNIC fails to timely update the AS0
> ROAs, this will effect the service delivery and/or network downtime.
>
> I request APNIC to provide a detailed review of this proposal from a
> service and legal perspective so the community can better understand the
> implementation, if this proposal reaches consensus.
>
>
> Kind regards
> Javed Khan
> MSCE and CCSP
>
>
> ------------------------------------------------------------------------
> *From:* sig-policy-boun...@lists.apnic.net
> <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 <aftab.siddi...@gmail.com>
> *Cc:* Sumon Ahmed Sabir <sasa...@gmail.com>; 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 <aftab.siddi...@gmail.com
> <mailto:aftab.siddi...@gmail.com>> wrote:
>
>     Hi David,
>
>
>     On Fri, Aug 23, 2019 at 6:36 AM David Farmer <far...@umn.edu
>     <mailto:far...@umn.edu>> wrote:
>
>         The problem statement says;
>
>             Bogons are defined in RFC3871, A "Bogon" (plural: "bogons")
>             is a packet
>             with an IP source address in an address block not yet
>             allocated by IANA
>             or the Regional Internet Registries (ARIN, RIPE NCC, APNIC,
>             AFRINIC and
>             LACNIC)...
>
>
>         So that raises a question, what about resources that are
>         deregisterd because they are returned, revoked, or otherwise
>         reclaimed, for any of a myriad of reasons, including non-payment
>         of fees? Do they become Bogons with AS0 ROAs the moment they are
>         deregistered? Later, if so when? What if there is a ROA for them
>         in the system? Are the ROAs removed, if so when?
>
>
>     I also had some concerns about revoked and/or reclaimed space and
>     closed account due to non payment so I asked Secretariat in advance
>     and here is the response.
>     =======
>     APNIC membership account is classified as closed when its status is
>     flagged as ‘closed’ in APNIC’s internal system.
>
>     30 days - payment period upon issuance of invoice, if no payment is
>     received within this period member receives expiry notice and the
>     account status becomes 'suspended'
>     After 15 days – member receives email notification for closure
>     giving them another 15 days to pay
>     After 15 days – the status of the account becomes 'closed' and all
>     delegated resources under the account are reclaimed
>
>     All in all members have 60 days period to pay before the status of
>     the account becomes ‘closed’.
>     =======
>
>     As long as the account is suspended APNIC doesn't consider those
>     resources as free/available/reclaimed and because they are not part
>     of unallocated pool thats why no need to create AS0 ROAs for such
>     resources. AS0 ROAs will be created once APNIC mark those resources
>     available and remove them from their delegation record. Now, the
>     second issue is if there is a ROA for them in the system. Because AS
>     0 ROA has a lower relative preference than any other ROA that has a
>     routable AS then APNIC has to somehow delete the existing ROA from
>     the system. Its easy if the member account is closed and all
>     resources are reclaimed. But I leave this to APNIC to decide how
>     they are going to make that happen.
>
>
> Currently, when the account is closed nothing actively makes the
> resources unusable, accept for if you were also changing providers
> during this timeframe, then when the new provider checks the resources
> they will be unregistered. But most providers don't recheck the
> registration of resources very often, if ever, other than at the time of
> setup of service.
>
> With this proposal at some point, the resource will effectively become
> unusable with nonpayment, when the AS0 ROA is created, and any ROAs are
> removed, I'm fine with this, but it should be called out as a
> consequence of the proposal, so no one can say they didn't realize that
> is a consequence of the proposal.
>
> This proposal changes the consequences for nonpayment, that should be
> made clear in the proposal one way or another.
>
> Also as Owen noted the RIRs frequently have a hold period after the
> account is closed, resource are usually held for some period after
> account closure and before they are reissued to a new user.
>
>         Personally I think they should be deregistered for some amount
>         of time before the becoming Bogons and have an AS0 ROA created
>         them, also for the AS0 ROA to be effective any ROAs for these
>         deregistered resources need to be removed as well.
>
>
>         I would propose something like the following;
>
>          1. Upon de-reregistration any existing ROAs are removed from RPKI
>          2. 30 days after de-registraion, AS0 ROAs are created except
>             for non-payment fees
>          3. 90 days after de-registraion, AS0 ROAs are created in the
>             case of non-payment fees
>
>         Thanks.
>
>
>     Thanks for these suggestions but do you think the existing waiting
>     period as outlined above in APNIC's response is good enough to mark
>     them as free/unallocated? or you think additional cooling-off window
>     should be added after the account is closed? How about 30 days after
>     de-registration whether it was closed due to non-payment or otherwise.
>
>
> They were just suggestions, but I will note that you only discussed the
> timing for nonpayment, resources can be returned voluntarily or they can
> be revoked for cause, this is rare but it does happen and the timing
> assoicated with these instances should be understood as well.
>
> Also, I was suggesting the AS0 ROAs should not created immediately on
> account closure but some period of time after that,
>
> Right now there seems to be two phases, suspension and account closure,
> I'm proposing a third phase resource deactivation, the creation of the
> AS0 ROAs. I suppose account closure and resource deactivation can occur
> simultaneously, I think they should be separate as an escalating series
> of events.
> Thanks
>
>         On Thu, Aug 22, 2019 at 12:52 AM Sumon Ahmed Sabir
>         <sasa...@gmail.com <mailto:sasa...@gmail.com>> 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 <mailto: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.
>
>
>             2. Objective of policy change
>             -----------------------------
>             The purpose of creating AS0 (zero) ROAs for unallocated
>             address space by
>             APNIC
>             is to resolve the issue of Bogon announcement. When APNIC
>             issues an AS0
>             ROA for
>             unallocated address space under APNIC’s administration then
>             it will be
>             marked as
>             “Invalid” if someone tries to advertise the same address space.
>
>
>             Currently, in the absence of any ROA, these bogons are
>             marked as
>             “NotFound”. Since
>             many operators have implemented ROV and either planning or
>             already
>             discarding “Invalid”
>             then all the AS0 ROAs which APNIC will create for
>             unallocated address
>             space will be
>             discarded as well.
>
>             3. Situation in other regions
>             -----------------------------
>             No such policy in any region at the moment.
>
>
>             4. Proposed policy solution
>             ---------------------------
>             APNIC will create AS0(zero) ROAs for all the unallocated
>             address space
>             (IPv4 and IPv6)
>             for which APNIC is the current administrator. Any resource
>             holder (APNIC
>             member) can
>             create AS0 (zero) ROAs for the resources they have under their
>             account/administration.
>
>
>             A ROA is a positive attestation that a prefix holder has
>             authorised an
>             AS to originate a
>             route for this prefix whereas, a ROA for the same prefixes
>             with AS0
>             (zero) origin shows
>             negative intent from the resource holder that they don't
>             want to
>             advertise the prefix(es)
>             at this point but they are the rightful custodian.
>
>
>             Only APNIC has the authority to create ROAs for address
>             space not yet
>             allocated to the members
>             and only APNIC can issue AS0 (zero) ROAs. Once they ROA is
>             issued and
>             APNIC wants to allocate
>             the address space to its member, simply they can revoke the
>             ROA and
>             delegate the address space
>             to members. (this proposal doesn't formulate operational
>             process).
>
>             5. Advantages / Disadvantages
>             -----------------------------
>             Advantages:
>             Those implementing ROV globally and discarding the invalids
>             will be able
>             to discard bogons from
>             APNIC region automatically.
>
>             Disadvantages:
>             No apparent disadvantage
>
>             6. Impact on resource holders
>             -----------------------------
>             No impact to APNIC or respective NIR resource holders not
>             implementing
>             ROV. Those implementing ROV
>             and discarding the invalids will not see any bogons in their
>             routing table.
>
>
>             7. References
>             -------------------------------------------------------
>             RFC6483 - https://tools.ietf.org/rfc/rfc6483.txt
>             RFC6491 - https://tools.ietf.org/rfc/rfc6491.txt
>             RFC7607 - https://tools.ietf.org/rfc/rfc7607.txt
>             _______________________________________________
>             *              sig-policy:  APNIC SIG on resource management
>             policy           *
>             _______________________________________________
>             sig-policy mailing list
>             sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net>
>             https://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
>
>         --
>         ===============================================
>         David Farmer Email:far...@umn.edu <mailto:email%3afar...@umn.edu>
>         Networking & Telecommunication Services
>         Office of Information Technology
>         University of Minnesota
>         2218 University Ave SE        Phone: 612-626-0815
>         Minneapolis, MN 55414-3029   Cell: 612-812-9952
>         ===============================================
>         *              sig-policy:  APNIC SIG on resource management
>         policy           *
>         _______________________________________________
>         sig-policy mailing list
>         sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net>
>         https://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
>
> --
> ===============================================
> David Farmer Email:far...@umn.edu <mailto:email%3afar...@umn.edu>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>
> *              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

Reply via email to