Early Review of draft-ietf-homenet-dot-03
review-ietf-homenet-dot-03-opsdir-early-mitchell-2017-03-18-00

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Overall - document has issues, could likely benefit from further reviews.  This
document was asked for early review by with a specific request instructions to
look at in context of RFC6761 definition of special use domain names as well as
from the operational implications of having an unsigned root zone.  Having read
the document and a number of related works that I found useful in understanding
further the implications of this document (such as those laid out by
draft-ietf-dnsop-sutld-ps-03), I think it would be useful for this document to
go through an additional further early review by dnsop working group directly,
however here is my non-DNS expert feedback:

This document does spell out handling for .homenet as required by RFC6761,
specifically in Section 3 of the draft, and does seem to adequately fit under
the definition of a special used domain name, primarily only based on the
difference of user experience with the domain (criteria #1).  That said, I have
several concerns with the wording in this draft regarding criteria in this
section, here they are in the same numbered list as in the draft (and as
required by RFC6761).

1.  This does not adequately identify that users should not treat .homenet like
any other domain name in the sense that entries in this top level domain are
pretty much guaranteed to be non-unique, and likely this will pose general
confusion, service reachability, as well as security concerns that are somewhat
glossed over as well in the security considerations section of the draft.

2.  All though this states that applications should not consider .homenet
domain has having an elevation of security, user facing applications may want
to actually notify users of the special behavior of this domain and the fact
that it is more insecure as the names are not globally unique and using them
outside of the local networking environment will likely have unexpected
results.  Further applications are pretty much guaranteed to not be able to
have certificate based trust of the hosts at this domain since they are not
globally unique.

3.  No issues with section wording which basically prescribes no difference
from normal DNS behavior, although this section is a bit verbose about how a
host gets it's nameservers, which seems unnecessary.

4.  This section is a bit confusing as it says that .homenet is effectively a
locally served zone as described by RFC6303, but then there is no request for
IANA to add this to the locally served zones registry which was established by
that RFC, not to mention that registry does not currently contain any non
reverse zones today.  My reading is that homenet's desired behavior for this
and section 5 are similar to the description of the .test domain handling in
RFC6761, and I'm curious (not familiar with history or timing of the two
documents) that none of the domain handling in RFC6761 defer to RFC6303 for
specification handling like .homenet tries to do here.

5 and 6.  Similar concern as above, wonder why same wording as prescribed for
.test domain in RFC6761 is not used for .homenet

7.  No concerns.

Concerns with security considerations - user surprise (and threat) is something
that is basically being designed into this use case, as well as is the need to
disable DNSSEC and some of the ability to use certain types of certificate
based application security that relies on CA trust based on names.  This
doesn't feel adequately called out.

IANA considerations - as described below section doesn't mention locally served
zone registry, although it's unclear as described above whether or not that's
really the behavior desired.