Thus spake "Brian Haberman" <[EMAIL PROTECTED]> > Would anyone be able to ask whether a specific prefix was > allocated or not?
This makes sense, whether or not the particular registrant is named. > Would a holder be able to 'recover' their prefix from the > registry? What does 'recover' mean in this context? > Could a holder request the registry to expose their holding to > a specific third party? Presumably the registrant would be given some sort of non-repudiable proof of their registration which could be shown to a third party, but the draft doesn't require this nor does it cover the case where such proof is lost. > Could the privacy requirement be changed at a later date? > > Would any future changes to the privacy requirement (or any > other characteristics of these addresses) be a policy matter to > be determined within the addressing community, or would any > changes to the characteristics of this space remain solely > within the purview of the IETF? Given that the target market for local addresses are typically those who would normally not be RIR members, it seems illogical to let the RIRs set policy over consumers who have little or no representation. For lack of a better body, the IETF should retain control. > - Permanence of allocation. Should there be a capability for an > assignee to voluntarily return an allocation? How can the assignee > and the returnee be matched? If the allocation is not public > knowledge how can a return be effected? Should these allocations > be permanent or of some fixed term with a periodic renewal option? A return could be effected because the registrar necessarily knows who it assigned each prefix to, even if that information is not published. I don't see how it would be possible for a registrar to discard this information, since the registrant may want to make changes (eg. DNS, WHOIS) after the initial assignment, or transfer it to a third party. > - Distribution functions. Should there be some form of 'wholesale' > form of bulk access to this registry, to allow, for example, a > manufacturer to place pre-registered prefixes into manufacture > devices? If not, could this form of use of the central registry > services be supported using mechanisms described in the current > draft? Can we get an example of how this might be useful? > - Associated information and pointers. The draft is silent on > reverse DNS for these prefixes. Perhaps the final version of this > document could explicitly say that this requires private DNS (two- > faced DNS) deployment and that placing these prefixes in the > ip6.arpa zone is not to be supported. Or should such reverse DNS > delegation be allowed? Section 7.0 of the first draft seems to cover this adequately. > The draft is also silent on WHOIS entries. It appears that there > is an implicit privacy assumption which precludes inclusion > in the WHOIS databases, but an explicit statement to this > effect in a final version of this document would be preferred. It > is probable that inclusion in the public DNS, whois information > and the privacy of these assignments are related matters. The presence of WHOIS entries should follow the same policy as DNS entries. WHOIS has an interesting corner case, as the registrar may wish to indicate a prefix is assigned but not to whom (see first question). > - Routability of these prefixes. The RIRs mintain that they take no > position on the routeability of prefixes that they assign. It > would appear that this position extends to any central-registry > managed site local prefix. It may be that the IESG is also silent > on routeability of these prefixes as this is more a business/ > operational issue that a standards-based issue. I thought the difference was implicit in Section 4.0 of the first draft with the general ban on inter-domain routing absent specific exceptions; this is signiticantly different than merely not guaranteeing routability of normal unicast prefixes (which is a case of the RIRs covering their asses since they have no control over ISPs). Is there a stronger wording that makes this difference more explicit? S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
