> Date: Fri, 29 Jun 2007 20:23:54 +0000 > From: Paul Vixie <[EMAIL PROTECTED]> > Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > >> Additionally, I believe that there exist RIR policies which are >> resulting >> in some pressure towards implementing ULA/ULA-C -- policies which can >> and >> should be modified by the membership constituency of the RIRs. > > on this, there is broad agreement, but the outcome has been to request > that > IANA (by way of an IETF specification) set aside some non-DFZ space so > that > RIRs can hand it out for non-DFZ use with a lower barrier to acquisition.
(*) See below at the bottom - I believe there are two contradictory statements (unless publishing an RFC which requests that an RIR do some particular thing, does not constitute "setting RIR policy".) >> ULA-C is an interesting middle ground, but the mere existence of ULA-C >> as a >> concept, and as a draft that we're discussing, is a strong indicator >> that >> these RIR policies are a problem. And moreover, as a compromise, ULA-C >> is >> causing more harm than good. > > obligatory disclaimer: while i'm not speaking for ARIN here, i am a member > of > ARIN's board of trustees, and i have not set ARIN's interests aside for > the > purpose of pure academic debate. and briefly, as a trustee for this > sentence > alone, let me point out that ARIN's policies are set by the community and > if > you think those policies are "a problem" you should join [EMAIL PROTECTED] and > also attend ARIN meetings and consider submitting some policy proposals to > change them. Don't worry - those are already things I'm planning on doing. (Thanks for the mailing list pointer - it saves me a bit of searching. ;-)). And thanks for pointing out the ARIN meta-policy - I don't think enough people understand that. Shouting over the wall pretty much by definition does not constitute submitting proposals. :-) And the reason I brought up the issue, and made the proposal, is for that exact reason. If any of what I said made any sense, then anyone who has reason to support those suggestions would probably be best served by also joining in on this ARIN pariticipation activity, in a very concrete way. I think that more "bridging the gap" between operators, policy makers, and (<insert label for IETF here>) everyone else, needs to occur. It's bad enough that vendors making hardware are so far behind the curve... I also think that it's just a question of realizing that ARIN is part of the community, part of the process, and that not participating means not having visibility or input into things that can affect your network, further down the road... (end of plug for civic duties) >> The requirements that I see ULA/ULA-C addressing are: >> - need for IPv6 space >> - need for this space to be globally unique >> - need for this space to be easily acquired >> - need for this space to be acquired for no cost >> - need for the status of this space to be easily identifyable (DFZ or >> not) > > others see additional requirements. for example, the need for global > WHOIS, > global DNS, and global RPKI support for ULA space, so that even in ad-hoc > networking environments, "recourse" will be possible against malefactors. > as > a result of that requirement, a role for the regional internet registries, > and a fee level set at the cost recovery level for efficient > not-for-profit > operations, has been strongly suggested. I don't disagree with any of the stuff that follows "as a result". I in fact agree that there is a reasonable basis for doing so which pretty much stands by itself, without needing any support from anyone. Please answer me this, however (anyone, not just Paul): - of the additional requirements listed, which of those are not available (e.g. automatically) for PI allocations in the DFZ? What I'm asking, of course, is this: Is there *anything* unique to ULA that is not possible to implement with PI allocations by RIRs? And if so, why would it not be something to add on to every PI allocation? (I do profess ignorance RPKI; I'm pretty sure that WHOIS and DNS are part of the DFZ :-)). > (don't think that your own requirements aren't relevant or that your > description of them is unappreciated, but the resulting specification if > any will include a larger set of requirements and features than any one > person is likely to have, and is likely to be seen as a compromise by most > if not all of us.) > >> All but the last issue, are trivially manageable by relaxing the >> existing >> requirements in place at the RIRs, for acquiring space. [...] > > as before, if you think that the existing RIR policies are wrong, there's > a > mechanism in place in every region for improving those policies. one > thing > to add at this point: IETF is not where RIR policies are made or changed. (*) Second part of same comment from above - if the IETF publishes an RFC, requesting that RIRs do some particular thing on a systematic basis, is that not in effect dictating (in a passive-aggressive manner) policy to RIRs? I do understand the difference between requesting something of RIRs, and telling them to do something, but fundamentally, either the RIRs do what is asked in the RFC, or they do not. If they do not, the whole RFC is mooted. If they do, then they have made a policy change at the behest of the IETF. Either way, this begs the question - how is what I was suggesting, other than in the sense that I did not couch my suggestion as "ask nicely", any different than ULA-C? As far as I can tell, the main differences have to do with ULA itself, the fact that the allocations are from a single block, and that the single block has associated with it some rather nasty mandatory extra bits. (Yes, I know I'm being a bit facetious - and deliberately - but the question isn't entirely rhetorical. If the suggestion were couched the same way as the ULA-C proposal, would it be considered acceptable from the ARIN perspective?) Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
