AS8584 taking over the internet

Mailman List Mirror (Read Only)
1

You might want to look at:

  http://www.iops.org/Documents/routing.html

wrt to Dana Hude's comments:

    It is such accidents that reinforce the notion of per-prefix
    filtering. Of course if one changes one's IRR/RIPE DB/RADB entries to
    deliberately announce the world there could still be a problem with
    auto-generated accept policy. The solution to *that* is quality
    assurance of the database, an ongoing issue in RIPE DB WG at least.

    Even then how does one prevent someone coding 'ANY' for their
    announce policy when they should not? In the old NFSNET days
    human inspection of IRR entries assured quality but that's not
    practical anymore at a central registry.

BTW- You can code ANY for your announce policy. What matters is what
is coded in someone else's accept policy.

On the broader topic of quality assurance of the database see:

  http://engr.ans.net/rps-auth/
  and draft-ietf-rps-auth-00

The goals of the RPS WG are:

  RPSL - improve the ability to describe policy and aggregation so
  that a larger set of router configuration requirements can be met.

  authorization and authentication - provide an enforceable set of
  rules as to who can register what and provide the authentication
  support to verify the claimed "who".

  distributed registry - RSN draft-ietf-rps-dist-00 - distribute the
  database efficiently and in a way that doesn't comprise the
  authorization and authentication model.

Likely to be added later is:

  query - provide a standardized query interface to make it easier to
  write tools that rely on being able to query the database.

Curtis

2

Hmmm... what else is there?

http://www.iops.org/Documents/escalation.html

Oh my! Look what it says at the end here...

    Point-of-contact information is required for each escalation level
    defined above. Telephone numbers and email addresses are required for
    each level. Information regarding appropriate protocols and methods
    for reliably making contact with each level should also be provided by
    the concerned organizations, including pager numbers, primary and
    alternate contacts, and information regarding preferred time windows,
    as appropriate.

    The contact information will be shared only among those providers who
    are IOPS members and who have subscribed to the process documented
    herein.

While such sentiments may be appropriate in a private club, one wonders
whether they should be found in documents from an organization that bills
itself as the Internet Operators Organization.

One also wonders whether a lot more could be accomplished simply by
gathering the collected knowledge from the NANOG mailing list, NANOG
meetings and other sources into a series of "Best Practices" documents.