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

From: "Osterweil, Eric" <[email-masked]>
Date: Fri, 3 May 2013 21:48:55 -0400

Hey Nick,

First, I'm very sorry for the absurd delay in addressing these comments, but thank you very much for them.  I've incorporated most of them and will be pushing a new version soon.

Eric

On Sep 4, 2012, at 6:12 PM, Nick Hilliard <[email-masked]> wrote:

> On 04/09/2012 20:17, Danny McPherson wrote:
>> FYI, may be able to find a home here in grow if folks are interested.
>> 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
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: "Osterweil, Eric" <[email-masked]>
Date: Fri, 3 May 2013 21:49:12 -0400

Hey Wes,

Sorry for the protracted delay… I'll start taking a look at this!

Thanks!

Eric

On Sep 6, 2012, at 11:22 AM, "George, Wes" <[email-masked]> wrote:

> I think this is useful, and I think grow is a good place to discuss it. I might recommend a slight reorganization to keep all of the historical issues that have been resolved in one section, and then have the focus of the document be more on a good articulation of the current issues and gaps.
> 
> Thanks,
> 
> Wes
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Danny McPherson
>> Sent: Tuesday, September 04, 2012 3:17 PM
>> To: [email-masked]
>> Subject: [GROW] Fwd: I-D Action: draft-mcpherson-irr-routing-policy-
>> considerations-01.txt
>> 
>> 
>> 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-co
>>> nsiderations
>>> 
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-mcpherson-irr-routing-policy-consider
>>> ations-01
>>> 
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-mcpherson-irr-routing-policy-co
>>> nsiderations-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
>> 
> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.