[anti-abuse-wg] [routing-wg] AS43890

Hi,

On Mon, Nov 17, 2014 at 01:16:08PM -0800, Ronald F. Guilmette wrote:
> In message <20141117084633.GA20482 at Space.Net>, 
> Gert Doering <gert at space.net> wrote:
> 
> >MCCI should really, really clean up all route objects that cover parts
> >of their address space but point to other origin ASes.
> 
> Wait, so you are saying that the *Iranians* should be responsible for
> cleaning up the mess that was left behind by their predecessors, i.e.
> the folks who had the 188.229.0.0/17 block before the Iranians did??

Well, it should be part of the purchase contract - "we buy this block
under the condition that... and only pay if this is all fulfilled".

In any case it is partly their responsibility to check that there is
nothing lingering.

> Can they even remove those route objects, given that they didn't even
> create them in the first place?
> 
> Can any arbitrary RIPE member remove route objects that were created
> by any other RIPE member?

Generally speaking, no.

Routes that point to parts of *your* address space, you can remove, if
I remember right - because normally you need to approve the creation
anyway (by authorizing the update).  I need to find the flow chart on
the RIPE web site that precisely describes which authorization is checked
where, but if I remember right, for deletion, the "mnt-routes:" (fallback
to mnt-by: if no mnt-routes:) authorization on the inetnum is sufficient 
for removal.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: </ripe/mail/archives/anti-abuse-wg/attachments/20141117/7c7871c1/attachment.sig>