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
