I have a few points on Paul's draft: Nit - LocalNum = 28 bits (you lost 4 bits somewhere)
Minor point - 5.1 is not globally true yet, but should be Major complaint - aggregation There needs to be at least a modest capability to aggregate. I understand the aversion to having these show up in the DFZ, but if 5.1 were really true that would not be an issue. The use case that needs to be supported is for internal aggregation of private peering clusters. Global organizations have many external relationships, but typically have them clustered in small groupings for logistics reasons. At the same time they don't necessarily want to carry the explicit routes for every organization throughout their internal network. If the ULA-C/G space has some modest aggregation like sparse allocation of the RIR num block to allow clustering subsequent block to the same RIR and a suggestion for E-W-N-S regional management within the RIR space, then it would be possible to aggregate the internal routes to these private peering clusters. 5.6 last sentence seems to be prescriptive, and would be more descriptive if opened with 'It is expected that ...' 6.1 - One point of the entire ULA space is that this is a different 'filtering process'. Where typical filters block packets received at the border for the target address, the ULA space is about not even having a route for that packet in the first place. Yes there is no more or less security than any other unicast address when routing announcements and packet filtering match, but the default assumption that ULA is a bogon routing announcement should add a layer of security that can't be done with PI for most use cases. Tony > -----Original Message----- > From: Paul Vixie [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 11, 2007 7:24 AM > To: ipv6@ietf.org > Subject: Re: draft-ietf-ipv6-ula-central-02.txt > > > Paul's draft which assigns 12 bits to each RIR seems to be the right > > thing since it clearly delineates which RIR is responsible for each > > subset range, and therefore if an RIR policy dictates special > handling > > for certain ULA addresses, there is a simple technical means to > > accomplish this. > > it's expected that iana will hand out blocks of 100 RIR-sized ULA-G > blocks > to each RIR, similar to how ASN blocks are assigned, just to save > paperwork. > but yes, since each RIR will have its own chunks of this space, they > can do > whatever their regional member-driven policy development process tells > them > to do as far as carving it up and handing it out to LIRs, endusers, > etc. > > > I'm not sure what the status of Paul's document is since the drafts > > directory only contains this one: > > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central- > 02.txt > > > > Is Paul's superceding that or is there a merge in process? > > the other authors of ula-global have not commented on my hijackery. > they > might be supportive, or angry, or complacent, about the draft-fork i > made. > maybe they'll want their names removed. maybe they'll want to merge > ula-g > into ula-c and have my name removed. maybe they'll want the fork to > stay. > > the i-d editor determined that my submission came after the chicago > cutoff, > which really oughtn't apply for WG's that are not meeting, but so it > goes. > > the WG chairs have ignored my mail thus far. > > so my take is, suggested changes and statements of opposition||support > can > be made based on the text at http://sa.vix.com/~vixie/ula-global.txt. > i'll > be rev'ing the draft based on james' and scott's comments shortly. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------