Early Review of draft-ietf-homenet-dot-03
review-ietf-homenet-dot-03-intdir-early-thaler-2017-03-14-00

Request Review of draft-ietf-homenet-dot-02
Requested rev. 02 (document currently at 14)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2017-03-17
Requested 2017-03-02
Requested by Terry Manderson
Authors Pierre Pfister, Ted Lemon
Draft last updated 2017-03-14
Completed reviews Opsdir Early review of -03 by Jon Mitchell (diff)
Intdir Early review of -03 by Dave Thaler (diff)
Secdir Last Call review of -12 by Daniel Migault (diff)
Genart Last Call review of -12 by Dale Worley (diff)
Assignment Reviewer Dave Thaler 
State Completed
Review review-ietf-homenet-dot-03-intdir-early-thaler-2017-03-14
Reviewed rev. 03 (document currently at 14)
Review result Not Ready
Review completed: 2017-03-14

Review
review-ietf-homenet-dot-03-intdir-early-thaler-2017-03-14

Section 6 says:
   IANA is requested to arrange for an insecure delegation for
   '.homenet' in the root zone.  This delegation MUST NOT be signed, and
   MUST point to some IANA-operated black hole servers, for example
   BLACKHOLE-1.IANA.ORG and BLACKHOLE-2.IANA.ORG.  Not signing the
   delegation breaks the DNSSEC chain of trust, which prevents a
   validating stub resolver from rejecting names on a local homenet.

   This request is being made under the terms of the Memorandum of
   Understanding [RFC2860] between IETF and ICANN; the IETF considers
   the use of '.homenet' to be a "technical use" under the terms of the
   MoU.  The working group understands that there is no precedent for
   such a request and that some process may have to be developed for
   addressing it.

My understanding is that IANA cannot "arrange for an insecure delegation for
'.homenet' in the root zone" unless/until a process is first created for that.
And if such a process were defined, it's not clear to me that it would be IANA's
responsibility to "arrange for" it, and so I think it is premature to request
IANA to do so.   The last sentence quoted above is of course correct, but
I believe the request cannot even be properly formed until after such a process
has been developed, hence my evaluation of "not ready", and it won't be
unless/until such a process exists.   (As an aside, it's also not clear to me
whether such a process will ever exist due to the problematic requirement that
"delegation MUST NOT be signed", but there are others who know much
more about this than I do.)   A solution that allowed a response to be signed,
even if it's just a signed NXDOMAIN or NXRRSET, would not have this issue.