Hi, (please see inline) On Thu, 21 Mar 2019, Jacob Slater wrote:
First, I'm not sure I either understand or am even aware of these alleged "forms of permission for announcement {that} are not documented". So perhaps Mr. Slater could elaborate upon that, for my benefit, and perhaps also for that of others who may also be similarly in the dark about what he's talking about here.
Route objects are not always required. While route objects are generally preferred and should be used, letters of authorization are still in use today. You certainly wouldn't see them in a public database (though you might see objects which claim to be tied to them). Even if you do, they may well be stale and no longer accurate.
While i don't have seen any of those, i was told they exist. I fail to understand how they are still 'acceptable'. Can't they be easily forged? I hope everyone agrees that authenticated IRR and preferably RPKI should be the way to go. Globally.
and if so, the reasons for that.
Because they have had no valid reason to do so yet. Making it a policy violation doesn't seem like the right way to encourage them to do so. It is not the job of the NCC to tell users how to run their network. As annoying as it is at times, this includes how users choose to authenticate their announcements.
The main difference i see between LoA vs. IRR/RPKI is partial visibility. The 'BGP core ring of trust' is way broken with 60.000+ ASNs, so we need everyone to be able to see if any announcement has any hint of being aligned with the legitimate resource holder. Isn't it time for people to get their act together? :-)
I think the proposal moves us closer to a state of civility and civilization. You might well claim, as you have, that it permits and carves out some space still for "vigilantism" in the process, but it does so only with respect to the submission of reports that would then, by design, be reviewed and judged by others. I have trouble seeing how this could be harmful. I do agree that it opens up the possibility of perhaps having everyone's time wasted, perhaps even frequently, with meritless and bogus reports, but I think that it is premature to assume that such an outcome will, in practice, be common enough to merit serious concern. Time will tell.
I agree that it may be presumptuous to guess at how much time will be wasted without any justification. That said, I have seen a significant number of recent reports on various mailing lists of accused hijackers. While some of them have been accurate, some of them definitively jump to premature conclusions. I, for one, would like to at the very least minimize the impact (in both stress and time) that such users would have on the time of all involved.
Sure, but 2019-03 proposes several steps where premature conclusions can be discarded.
Given your comments (along with some of the others mentioned), perhaps the best way to approach the issue is with explicitly stated guidelines for how hijacking reports should be processed and treated on the basis of both credibility (i.e. bogon/prefix holder) and bulk in a holistic sense. If done properly, it would minimize the risk for noncredible reports to cause impact for a given entity (based on the beliefs of a particular expert) while allowing groups beyond the specific prefix holder to make complaints (which have the potential to be taken seriously).
Sure. Let's then refine the process in subsequent versions.
>Additionally, while the policy does define a difference between accidental >and intentional hijacking, it does not differentiate between the two...
If that's true, then it should certainly be fixed.
Reading through the exact text, the only mention of the distinction appears to be a definition.
Can you propose an ammendment or addon? Thanks. Best Regards, Carlos