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

2019-09-02 Thread Satoru Tsurumaki
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-132, based on a meeting we organized on 21th Aug to discuss these proposals. Please note that these discussion is based on the first Proposal,

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

2019-08-21 Thread 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

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

2019-08-21 Thread Owen DeLong
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

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

2019-08-21 Thread 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 - Bogon: A "Bogon" (plural: "bogons") is a packet with an IP source address in an address block not yet allocated by IANA

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

2019-08-21 Thread Owen DeLong
I don’t tend to regard unallocated as “bogons”, but sure, if this proposal is strictly about unallocated space in the APNIC free pool(s), then I have no problem with that. Owen > On Aug 15, 2019, at 17:15 , Aftab Siddiqui wrote: > > Hi Owen, > Just to give you an example, all unallocated

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

2019-08-15 Thread 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

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

2019-08-15 Thread 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

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

2019-08-15 Thread Andrew Dul
Hello! On 8/15/2019 5:00 PM, Aftab Siddiqui wrote: Hi Andrew, On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong mailto:o...@delong.com>> 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

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

2019-08-15 Thread 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

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

2019-08-15 Thread Owen DeLong
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

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

2019-08-15 Thread Andrew Dul
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

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

2019-08-15 Thread 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

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

2019-08-15 Thread Owen DeLong
Looks like IETF wants the global BOGONs to be attested by IANA rather than by an RIR from what you quoted. Any reason APNIC feels the need to usurp that process? Owen > On Aug 14, 2019, at 21:58 , Aftab Siddiqui wrote: > > Hi Owen, > Thanks for your response, sorry for replying late though.

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

2019-08-14 Thread Md. Abdul Awal
Hi Aftab-bhai, While I totally support the proposal, I think this will only isolate BOGON/Martian routes in AP region and so all the other regions must do the same to make the idea fully functional. By that, I indicate of a global policy, may be at the NRO level. But anyway, at least it can be

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

2019-08-14 Thread Md. Abdul Awal
Hi Aftab-bhai, While I totally support the proposal, I think this will only identify BOGON/Martian routes in AP region and so all the other regions must do the same to make the idea fully functional. By that, I indicate of a global policy, may be at the NRO level. But anyway, at least it can be

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

2019-08-14 Thread 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

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

2019-08-09 Thread Owen DeLong
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