Subject: [GROW] Fwd: I-D Action: draft-mcpherson-irr-routing-policy-considerations-01.txt

From: Danny McPherson <[email-masked]>
Date: Tue, 4 Sep 2012 15:17:09 -0400

FYI, may be able to find a home here in grow if folks are interested.  Encourage feedback from all...

Thanks, 

-danny

Begin forwarded message:

> From: [email-masked]
> Subject: I-D Action: draft-mcpherson-irr-routing-policy-considerations-01.txt
> Date: September 4, 2012 11:32:25 AM EDT
> To: [email-masked]
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : IRR & Routing Policy Configuration Considerations
> 	Author(s)       : Danny McPherson
>                          Shane Amante
>                          Eric Osterweil
>                          Larry J. Blunk
> 	Filename        : draft-mcpherson-irr-routing-policy-considerations-01.txt
> 	Pages           : 15
> 	Date            : 2012-09-04
> 
> Abstract:
>   The purpose of this document is to catalog past issues influencing
>   the efficacy of Internet Routing Registries (IRR) for inter-domain
>   routing policy specification and application in the global routing
>   system over the past two decades.  Additionally, it provides a
>   discussion regarding which of these issues are still problematic in
>   practice, and which are simply artifacts that are no longer
>   applicable but continue to stifle inter-provider policy-based
>   filtering adoption and IRR utility to this day.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-mcpherson-irr-routing-policy-considerations
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-mcpherson-irr-routing-policy-considerations-01
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-mcpherson-irr-routing-policy-considerations-01
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 04 Sep 2012 23:12:06 +0100

> Encourage feedback from all...

Danny,

regarding section #4, "Accuracy and Integrity of Data", you've missed the
most important part of all - the tie between the resource and the end user.
 If this cannot be verified, then certification of any form is basically
pointless because you're only certifying the assertions that the creator /
maintainer of the resource object.

The RIPE community dealt with this by putting in a foundation policy
(policy 2007-01, written by yours truly), which requires a contractual link
between the RIPE NCC and the end user in direct assignment + asn assignment
cases which weren't previously covered by LIR contracts for address
allocations.  There were a couple of intentions with this policy:

1. there was an encumbrance placed in the policy for the LIR to charge the
end-user for provider independent resources.  This action creates a natural
garbage collection mechanism for PI address resources (v4 / v6 space, asns).

2. it guaranteed that all RIPE NCC allocated/assigned space would be
subject to a contractual link, and that this contractual chain might end up
actually meaning something when it came to the issue of who made what claim
about what number resource.

3. it would tie into the RIPE NCC's object grandfathering policy which ties
the registration details of the end-user to the object registered in the
irr database.

So unless you have similar chain-of-ownership functionality in other
IRRDBs, the whole discussion about certification and pretty much everything
else related is moot.

In section 7.3, I would view it as useful to note that SIDR does not
currently include bgp as-path validation, and that this is a Difficult Problem.

I think your draft has merit (no pun intended).  I'd like to see it
developed further because it provides a lot of important background
information on where we stand at the moment, and it's difficult to move
forward unless we have a clear idea we are.

nit: "ISP's" should be "ISPs" in the case where you are talking about
multiple ISPs.

Nick

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 6 Sep 2012 16:11:53 -0400

Hey everyone,

I just wanted to drop a quick note and thank the list for the feedback on the draft.  I just wanted to ping out and say that we're working on this internally.

Thanks,

Eric

On Sep 4, 2012, at 3:17 PM, Danny McPherson wrote:

> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow