[CRISP-TEAM] draft proposal issue: reverse DNS

[Izumi Okutani]

Many thanks Andrei for a very comprehensive summary of the current
situation.

It's helpful to clarify:

 -  NTIA is not involved in delegation of *.IN-ADDR.ARPA and *.IP6.ARPA

 -  IETF, as the delegated entity of TLD ".ARPA" defines delegations of
    *.IN-ADDR.ARPA and *.IP6.ARPA

 -  IETF defines to delegate *.IN-ADDR.ARPA and *.IP6.ARPA according to
    address management heirachical structure
    i.e. -->IANA-->RIRs

Does anyone feel we *shouldn't* include it in the draft proposal,
suggested by Alan below?

If not, let's prepare to include it. If we document this, I feel we want
to be clear that this does not involve NTIA, as Andrei's suggested
approach about overlaps.

I'd like to call for volunteers to work on this wording.

Alan and/or Andrei, would you be willing to help in drafting this part?
Anyone else would be welcome to volunteer ofcourse.

> If the IETF chose not to mention this issue, that's all the more reason
> for us to address it.
>
> I think that we should mention the mapping between IPv4 or IPv6
> addresses and corresponding domain names in in-addr.arpa or ip6.arpa,
> refer to the RFCs that say delegation of the sub-domain name space
> should follow allocation/assignment/delegation of the addresses, and say
> that the IANA operator should delegate domain names to RIRs (or end
> users).  Any SLA between the RIRs and the IANA operator should also deal
> with this issue.

Thanks Alan to this specific suggestion.
References to relevant RFCs and suggestions are helpful as well.

> An affirmation of commitments between the RIRs (or the NRO) and the IETF
> seems reasonable.

Anyone has other comments, especially from RIR staff?

If no further comments, let's take and suggest this approach as CRISP
team. This also makes sense to me personally.


Izumi


(2014/12/16 5:33), Alan Barrett wrote:
> On Mon, 15 Dec 2014, Andrei Robachevsky wrote:
>>> One issue I did not see discussed yet is around .arpa - I recall the 
>>> NRO EC suggested the CRISP team appoints a liaison to the IETF to 
>>> ensure that the proposal from IETF meets the numbering's community's 
>>> expectations as far as .arpa is concerned.
>>
>> Before discussing a specific solution, I'd like to better understand 
>> the relationships between the parties involved, which in this context 
>> are not entirely clear to me.
> 
> My understanding is that the IETF (through the IAB) asserts control of 
> the .ARPA top level domain, and instructs the IANA on what to do with 
> portions of the name space; see RFC 3172.
> 
> The mapping between IPv4 addresses and *.IN-ADDR.ARPA domains is 
> described in RFC 1034.  Delegation of portions of the name space to RIRs 
> or end users is described in RFC 2050.  RFC 3172 section 3 also says 
> "Sub-delegations within this hierarchy are undertaken in accordance with 
> the IANA's address allocation practices."
> 
> The mapping between IPv6 addresses and *.IP6.ARPA domains is described 
> in RFC 2874, and RFC 3152 requests IANA to sub-delegate portions of 
> IP6.ARPA to regional internet registries.  RFC 3172 section 3 also says 
> "names within this zone further delegated to the regional IP registries 
> in accordance with the delegation of IPv6 address space to those 
> registries."
> 
>> As I see this, the domains in question: ip6.arpa and in-addr.arpa are 
>> delegated to IANA by the IETF (RFC3172, RFC3152). The IETF also 
>> defined the policy. E.g. for ip6.arpa: "Names within this zone are to 
>> be further delegated to the regional IP registries in accordance with 
>> the delegation of IPv6 address space to those registries. The names 
>> allocated should be hierarchic in accordance with the address space 
>> assignment."
>>
>> The administration of these domains is "a technical work item per the 
>> existing ICANN/IETF MOU (RFC2860)" (see 
>> https://www.iab.org/documents/correspondence-reports-documents/docs2010/transition-of-in-addr-arpa-generation/), 
>> so strictly speaking the performance of this function is under the 
>> *IETF* purview (although I am not sure if/what SLAs are defined for 
>> this).
> 
> Yes, I think that's right.
> 
>> Now, if one looks at this from the perspective of the NTIA contract, 
>> the administration of these domains and delegations is out of scope. 
>> Add to this that these sub-registries are not mentioned in the IETF 
>> response either.
>>
>> Perhaps a good way forward would be to leave this issue outside this 
>> particular project altogether. The only problem is that the RIRs will 
>> probably need to draft a contract with the SLAs and this is one of the 
>> "IETF IANA" (but not "NTIA IANA") services they are getting, so it 
>> will have to be addressed.
> 
> If the IETF chose not to mention this issue, that's all the more reason 
> for us to address it.
> 
> I think that we should mention the mapping between IPv4 or IPv6 
> addresses and corresponding domain names in in-addr.arpa or ip6.arpa, 
> refer to the RFCs that say delegation of the sub-domain name space 
> should follow allocation/assignment/delegation of the addresses, and say 
> that the IANA operator should delegate domain names to RIRs (or end 
> users).  Any SLA between the RIRs and the IANA operator should also deal 
> with this issue.
> 
>> This issue is somewhat related to the shared management of the top IP 
>> address registry (see my mail "draft proposal: overlaps"). So I am 
>> thinking of the AoC mentioned in ARIN's draft proposal between the 
>> RIRs and the IETF. Perhaps an even better form would be an MoU that 
>> will take the spirit of the proposed AoC and the substance related to 
>> this particular service (+ the management of the shared registry), but 
>> IANAL ;)
> 
> An affirmation of commitments between the RIRs (or the NRO) and the IETF 
> seems reasonable.
> 
> --apb (Alan Barrett)
> 
> _______________________________________________
> CRISP mailing list
> CRISP at nro.net
> https://www.nro.net/mailman/listinfo/crisp