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. > > 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. > > 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
