in line... Stephen Sprunk wrote: > > Thus spake "Brian E Carpenter" <[EMAIL PROTECTED]> > > Margaret Wasserman wrote: > > ... > > > SUBSTANTIVE ISSUES: > > > > > > (1) This draft doesn't mention the reverse DNS tree. Is it expected > that > > > whatever registry assigns these values will also populate the > reverse > > > DNS tree? Or not? > > > > I think it is better to leave this question for a separate document (which > > certainly needs to be written). I don't think we should delay the present > > document for this. > > I think this revolves around a basic question of whether information about > centrally-assigned local prefixes should be available to third parties. If > so -- and that is my preference -- then WHOIS information should be provided > and DNS delegations should be available, though not mandatory. Optional > global DNS delegations may be beneficial to those using local addresses to > communicate privately between organizations because it can remove the need > for split DNS. > > > Yes. I suggest rewriting the first extract as: > > > > Global IDs should be assigned under the authority of a single allocation > > organization because they are pseudo-random and without any structure. > > This is easiest to accomplish if there is a single authority for the > > assignments. > > This wording still doesn't seem consistent with the possibility of having > multiple central authorities. If we are going to allow IANA the discretion > to assign multiple allocators, then we need to specify how that will be > handled, i.e. either assigning sub-prefixes to each authority or requiring > real-time checking between authorities to prevent collisions.
Send text? I meant mine to say that the authority (IANA) is unique - that doesn't preclude (or require) sub delegation. > > > > It seems strange to say that there can be no periodic fees when the > > > document doesn't mention fees anywhere else... Perhaps this is a > > > leftover from previous versions of the document that did include a > fee > > > structure? > > > > No, I think it is a principle and a directive to the IANA that we should > > keep. > > Agreed. Perhaps we should emphasize the permanent (i.e. rent-free) nature > of these allocations earlier in the draft so this statement doesn't seem out > of place? > > > > I am not sure that requiring a permanent escrow is consistent with > the > > > idea that there will be no ongoing revenue stream (i.e. periodic > fees) > > > associated with an address. > > > > But it's a matter of principle. If the IANA really thinks this is an > issue, > > it's for them to say so, not us. > > This is more of a business concern than a technical one, which seems outside > the IETF's purview. Maybe under IANA considerations we could add a > statement about how IANA should require a prospective allocation authority > present how it can fund indefinite operation from one-time fees? As has > been discussed, any competent accountant can figure how to determine a > one-time fee that equates to indefinitely recurring fees. > > It might be desirable for IANA/ISOC/whoever to set up a permanent trust > which receives one-time allocation fees and pays recurring fees (from > interest) to the actual allocation authority; such trust could also be > responsible for the escrow of registrations. This would protect against > bankruptcy of (or subsequent change in) the particular allocation authority. > I'm not sure this level of detail belongs in the draft, but this is the > model I had in mind. That certainly doesn't belong in an IETF document. But saying "no recurring fee" seems to me to be something we *can* say. And that's the text that went through WG last call. Brian > > > > Are you intending that centrally assigned addresses will all be > > > generated using the EUI-64 address of a server at the centralized > > > registration authority? What affect would this have on the > randomness > > > of these allocations, and does that matter? > > > > Actually the randomness doesn't matter much - we need enough > > randomness to ensure that people don't imagine these things aggregate, > > but there is no need for a mathematically "good" randomness. > > It's possible that the generation method could be bottlenecked by the rate > of timestamp changes if centrally-assigned prefixes become very popular. > Since the centrally-assigned half of the address space doesn't need the > level of collision prevention that the locally-assigned half does, could we > change this from a MUST to a SHOULD for the former? Any pseudo-random > algorithm should be sufficient for a central authority, provided it gives no > potential for aggregation. > > S > > Stephen Sprunk "Stupid people surround themselves with smart > CCIE #3723 people. Smart people surround themselves with > K5SSS smart people who disagree with them." --Aaron Sorkin -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
