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
