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 <far...@umn.edu> 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 <o...@delong.com> wrote: > >> >> >> On Aug 28, 2019, at 20:37 , Aftab Siddiqui <aftab.siddi...@gmail.com> >> wrote: >> >> >> Hi Owen, >> cutting some stuff out, just to keep the thread small. >> >> Anyone can very quickly put just about anything in RADB if they want to. >>> It’s also relatively easy to put nearly anything in the current ARIN IRR >>> (not to be confused with the ARIN RIR database). There are also some other >>> IRRs that accept almost anything at face value. >>> >> >> Exactly, thats why you have so much garbage in RADB and other IRR db. >> >> >> It’s also why the RIR withdrawing an entry isn’t as likely to cause an >> unmitigable outage than would occur under this policy. >> >> >> >>> >>> Finally, route object based filters tend to get updated rather slowly >>> and not everyone updates in sync, so it’s a gradually progressing outage >>> that allows some reaction time before becoming completely catastrophic. >>> >> >> Similarly, not everyone is doing ROV. But for the first time people are >> worried about consequences of their laziness because RPKI is going to work >> much better than IRR based filtering. >> >> >> I’m not sure that’s a completely fair characterization of the situation, >> but for whatever reason, despite its inability to do more than provide a >> really good cryptographically signed hint at what to forge in your >> hijacking announcements, RPKI is spreading like an unstoppable cancer and >> more and more people are beginning to do ROV in a mode which permits >> unknowns, but rejects known invalids. >> >> RIRs implementing AS0 raises the stakes by giving RIRs the power to >> create “known invalids” where the previous state would be “unknown”. >> >> >>> OTOH, if APNIC accidentally deletes the registration and issues an AS0 >>>> ROA for the entire netback, then you’re (potentially) talking about near >>>> total catastrophic routing failure for this ISP and all of his customers. >>>> >>> >>> Let’s assume they accidentally delete the registration for any reason >>> there are cooling off periods in place which goes up to 60 days or we can >>> put measures in place through policy to have decent cooking off periods. >>> Also let’s talk about stats, how many times how many RIRs have deleted >>> their members by mistake? Do you have any case? >>> >>> >>> Honestly, I have no way to know. Such an event would likely not be made >>> particularly public. The RIR would consider it confidential to the affected >>> party and the affected party would have little motivation to announce it to >>> the world after the fact. >>> >> >> So we are debating a scenario which we are not even aware ever happened. >> I'm still not saying that it never happened and will not happen but >> likelihood of such incident is just very small. >> >> >> No… You asked for an example of how an AS0 ROA could get into the wild >> erroneously and I presented one scenario which you are now arguing is >> unlikely. >> I agree that particular scenario may well be unlikely, but I’m not >> convinced it is the only circumstance in which such an event could occur. >> Depending on how AS-0 ROAs are generated, I see lots of possible ways for >> fat-finger incidents at the RIR to result in dangerous issuances. >> >> >> >>> >>> So I am not in favor of asking the RIR to create AS0 ROA. >>>>> >>>> >>>> Thats absolutely fine we can agree to disagree but let’s have a clear >>>> understanding of the policy. >>>> >>>> >>>> What makes you think he does not understand the policy? >>>> >>> >>> Because the policy only addresses the bogon, how an address space >>> becomes a bogon is APNIC operating procedure. Do you see the problem of >>> understanding here? >>> >>> >>> Yes, but it’s not his. The policy creates new more severe consequences >>> for things moving “routable” -> “bogon”. When you increase the consequences >>> of an action, it’s often a good idea to review the potential causes of that >>> action and consider what avenues exist for erroneous triggers. >>> >> >> Absolutely, its a good idea to have measures in place to avoid any >> erroneous triggers and thats why I said APNIC can put operational practices >> in place for that. Its shouldn't be part of the policy. >> >> >> I never advocated for making it part of the policy. I advocated for >> reviewing it as part of the considerations BEFORE consenting to >> implementation of the policy. >> >> I never asked for a change to the policy text. I asked for APNIC to >> publish their anticipated operational procedures for review so that the >> community can consider them in determining whether or not to come to >> consensus on this policy proposal. >> >> In other words, I agree they shouldn’t be part of the policy, but they >> MUST be part of the policy deliberation, IMHO. >> >> Also it’s seems you are fine with people advertising bogons just because >>> fixing it might make one/two people unhappy. >>> >>> >>> I’m not necessarily fine with people advertising bogons, but I’m also >>> not necessarily convinced that I want the RIRs to become the routing police. >>> >>> This proposal literally moves the routing police role from the hands of >>> those who run routers into the hands of the RIRs (well, specifically it >>> moves part of that 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. >> >> >> If you believe that first sentence, then you really don’t understand the >> current operational state of the internet. >> >> While you are correct about other ROAs, those other ROAs are not >> originated by RIRs and cannot come into existence as a result of >> disagreement between an ISP and an RIR (e.g. a billing dispute with an RIR). >> >> This does, in fact, substantially expand the power of the RIR to impact >> ROAs. That is reality. >> >> I haven’t decided whether that’s a good ting or bad, but it’s definitely >> a question that the community should carefully consider in evaluating this >> policy. >> >> I’m not saying the potential outcomes are necessarily bad, but whatever >> they may be, I want to maximize the probability that they are intended >> rather than unintended consequences. >> >> 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 > > > > -- > =============================================== > David Farmer Email:far...@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
