Problem Definition and Classification of BGP Route Leaks
RFC 7908

Note: This ballot was opened for revision 04 and is now closed.

Alvaro Retana No Objection

(Alia Atlas; former steering group member) Yes

Yes ( for -05)
No email
send info

(Alissa Cooper; former steering group member) Yes

Yes ( for -05)
No email
send info

(Ben Campbell; former steering group member) Yes

Yes ( for -05)
No email
send info

(Joel Jaeggli; former steering group member) Yes

Yes ( for -04)
No email
send info

(Kathleen Moriarty; former steering group member) Yes

Yes ( for -05)
No email
send info

(Stephen Farrell; former steering group member) Yes

Yes (2016-05-03 for -05)
No email
send info
- Thanks for doing this. The set of references alone seems
particularly valuable.

- section 2, does "propagation" in the definition mean
that purely faked announcement messages (ignoring RPKI for
the moment) that overlap with genuine announcements cannot
be considered route-leaks?  From the receiver POV, those
would not be distinct. It was probably already suggested
but if not, do you think would s/propagation/receipt/ or
similar be a little better?

(Terry Manderson; former steering group member) Yes

Yes (2016-05-03 for -05)
No email
send info
Thank you for an exceptionally well formed and well written coverage of route leaks.

(Deborah Brungard; former steering group member) No Objection

No Objection (2016-05-04 for -05)
No email
send info
Thanks for this well written document as others noted. I prefer a rewording of a somewhat choppy sentence in section 3.2 as it inaccurately quotes from the reference. The sentence says "[Mauch] observes that these are anomalies and potentially route leaks because very large ISPs such as ATT, Sprint, Verizon, and Globalcrossing do not in general buy transit services from each other." But the reference says "Example: UUNet (701) does not buy from Sprint (1239) to get to Globalcrossing (3549)." As this section in the document is "Example incidents" for Type 2, it infers this was an actual incident. But the reference itself simply says it is monitoring for this association.

Suggest to reword:
[Mauch] observes that its detection algorithm detects for these anomalies and potentially route leaks because very large ISPs do not in general buy transit services from each other.

(Jari Arkko; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Mirja Kühlewind; former steering group member) No Objection

No Objection ( for -05)
No email
send info

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -05)
No email
send info