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. > > (2) The document says: > > > Global IDs should be assigned centrally by a single allocation > > authority because they are pseudo-random and without any structure. > > This is easiest to accomplish if there is a single source for the > > assignments. > > This would appear to be incompatible with the IANA considerations > section that says: > > > If deemed > > appropriate, the authority may also consist of multiple organizations > > performing the authority duties. > > To avoid a situation where a single entity can request a large number > of local prefixes and aggregate them, it isn't strictly necessary that > the addresses be allocated from a single pool. If there were several > pools (for different geographical regions, for example) random > allocations from one of those pools would achieve the same result. 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. > > (3) The document also says: > > > The requirements for centrally assigned global ID allocations are: > > > > - Available to anyone in an unbiased manner. > > - Permanent with no periodic fees. > > 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. > > - Allocation on a permanent basis, without any need for renewal > > and without any procedure for de-allocation. > > - Provide mechanisms that prevent hoarding of these allocations. > > - The ownership of each individual allocation should be private, > > but should be escrowed. > > 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. > > (4) The algorithm for random number generation is: > > >3.2.3 Sample Code for Pseudo-Random Global ID Algorithm > > > > The algorithm described below is intended to be used for centrally > > and locally assigned Global IDs. In each case the resulting global > > ID will be used in the appropriate prefix as defined in section 3.2. > > > > 1) Obtain the current time of day in 64-bit NTP format [NTP]. > > 2) Obtain an EUI-64 identifier from the system running this > > algorithm. If an EUI-64 does not exist, one can be created from > > a 48-bit MAC address as specified in [ADDARCH]. If an EUI-64 > > cannot be obtained or created, a suitably unique identifier, > > local to the node, should be used (e.g. system serial number). > > 3) Concatenate the time of day with the system-specific identifier > > creating a key. > > 4) Compute an MD5 digest on the key as specified in [MD5DIG]. > > 5) Use the least significant 40 bits as the Global ID. > > > > This algorithm will result in a global ID that is reasonably unique > > and can be used as a Global ID. > > 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. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
