The Eternal Non-Existence of SINK.ARPA (and other stories)
draft-jabley-sink-arpa-03

Section 6, requests IAB approval of this document. How is this to be handled or
already done?

I think the asnwers are in RFC3172 "Management Guidelines &
Operational Requirements for
         the Address and Routing Parameter Area Domain ("arpa")"

From RFC3172, section2:
   The operational administration of this domain, in accordance with
the
   provisions described in this document, shall be performed by the
IANA
   under the terms of the MoU between the IAB and ICANN concerning the
   IANA [3].

From RFC3172, section 2.1:
   The IESG consideration of a document which proposes the use of an
   "arpa" sub-domain shall include consideration of the "IANA
   Considerations" section.  If the document is approved, the IESG
will
   ask the IAB to request the IANA to add the corresponding protocol
   object sub-domain domain to the "arpa" domain, in accordance with
RFC
   2860 [3], with administration of the sub-domain undertaken in
   accordance with the provisions described in this document.

From RFC3172, section 3:
   The IAB shall only recommend the creation of "arpa" sub-domains
   corresponding to protocol entities where:

   -  the delegation, and the hierarchical name structure, is
described
      by an IETF Standards Track document [4], and

   -  the use of the "arpa" domain is explicitly recommended in the
      "IANA Considerations" section of that document.

From RFC3172, section 7:
   As noted in section 3 of this document, the IAB may request the
IANA
   to delegate the sub-domains of "arpa" in accordance with the "IANA
   Considerations" section of an IETF Standards Track document.  This
   request falls under the scope of section 4 of the MoU between the
   IETF and ICANN concerning the IANA [3].


So, according to 2.1, having this approved by the IAB appears to
simply be "we ask the IAB to make the request to IANA", which seems to
answer the practical question in the DISCUSS.

I think section 6 might be worded incorrectly. RFC 3172 doesn't seem
to actually give IAB the right to "approve" the request; only IESG
approval is mentioned. 
And the MoU (RFC 2860) doesn't seem to give IAB approval, unless there
is a technical dispute between IESG and IANA:
   If in doubt or in case of a technical dispute, IANA will seek and
   follow technical guidance exclusively from the IESG. Where
   appropriate the IESG will appoint an expert to advise IANA.
   The IANA will work with the IETF to develop any missing criteria
and
   procedures over time, which the IANA will adopt when so instructed
by
   the IESG.

   4.2. In the event of technical dispute between the IANA and the
IESG,
   both will seek guidance from the IAB whose decision shall be final.

It appears to me that IESG has the approval authority, not IAB. 

Does that address the DISCUSS adequately?

-- a new related DISCUSS? --

draft-jabley-sink-arpa is an IAB stream BCP, not an IETF Standards
Track document, and section 3 and 7 of RFC 3172 require the IESG
approval of an IETF Standards Track document before
we ask IAB to make the request to IANA to delegate a sub-domain of
"arpa". 

So, should draft-abley-sink-arpa be published as an IETF Standards
Track document?

Section 6, requests IAB approval of this document. How is this to be handled or already done?

Picking up Magnus' DISCUSS:

  Section 6, requests IAB approval of this document. How is this to be
  handled or already done?

DISCUSS related to IAB review: the IAB sent a long, informal review that raises some issues; summary, extracted from longer IAB response, is here:

   The document, as it stands, is not actionable. It is a call to do
   nothing. IANA has not currently created any records for "sink.arpa"
   or delegated that name, and this document is a call for no change
   in that respect.

   However, [...], this name *does* currently exist for many Internet
   users, [...]. [jumping to end of response] Finally, with today's
   (unfortunate) habit of many ISPs creating fake answers for NXDOMAIN
   responses, to redirect careless web browsers to that ISP's
   advertising page, for many Internet users the name "sink.arpa."
   does in fact have address records.

   This document would be more effective if it specified concrete
   protocol rules, e.g.: 

   * DNS stub resolvers are required to special-case "sink.arpa." and
     return NXDOMAIN without issuing any network packets. 

   * DNS server software implementations are required to special-case
     "sink.arpa." and refuse to offer positive answers for such
     queries. 

   The document also combines two proposals: (a) creating an IANA
   registry for reserved DNS names, and (b) an allocation of one of
   those reserved DNS names. It might be better to split this into two
   documents.