Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Matthew Pounsett <[e-mail]>]

On 19 March 2017 at 21:44, Suzanne Woolf <[e-mail]> wrote:

> This document is the product of the homenet WG, which has asked the IESG
> to approve it for publication, so our comments are strictly advisory to the
> IESG. There was some discussion of the draft on this list shortly after it
> appeared, in November 2016, but it’s always the AD’s prerogative to ask for
> additional review.
>
>
To first answer the two questions in the call for reviews:  I see no
technical problems either with the RFC6761 application in the draft, or
with having an unsecured delegation in the root zone, should 'homenet.' be
chosen to anchor HNCP names.   There's a clear technical need for special
handling at the border between the local network and the Internet (local
names) and–in the absence of a specification for getting local trust
anchors into every validating resolver inside the local network–an
unsecured delegation for whatever name is chosen to facilitate end-to-end
security.

The reason we have a problem here is that this has been gone about in
entirely the wrong order, and procedurally leaves the IETF in a difficult
position.  We have no business demanding a root zone delegation from ICANN,
and publishing an RFC that requires that to happen in order to be useful is
tantamount to making that demand, regardless of how nicely the demand is
worded.

The need to correct the mistakes of the HNCP draft has, I think, resulted
in a rush that has been detrimental to careful consideration.  At the risk
of repeating the obvious, so that I can refer back to this list, what
should have been done is:
1) speak to ICANN (the community) about whether/how it's possible for IETF
to reserve & delegate an unsecured name from the root
2) if the community says yes, and after a process is defined, pick a name
that doesn't conflict with anything (including DITL research)
3) write the draft to reserve the name

While I appreciate that there's some risk this name might be exposed to end
users, and that perhaps some tiny percentage of end users might react badly
to seeing a reference to ARPA, I think that exposure is mostly going to
happen with technology professionals and hobbyists (power users), not the
typical home user.  So while it still may be preferable to use homenet.
over homenet.arpa., I'm unconvinced that it *needs* to be that way.

If HOMENET is set on trying for homenet., then I would recommend proceeding
with draft-ietf-homenet-redact, and shelving this draft until (1) and (2)
can be completed.

If there's a need that draft-ietf-homenet-dot be finalized before (1) and
(2) can happen, then homenet. should be replaced with homenet.arpa..

- Matt


PS: given that there is already talk of lawsuits over home. and corp., and
given that for any name that might be chosen there's likely somebody out
there in the world that thinks that name might be valuable to register, I
think the chances of getting a 'yes' out of the ICANN community is very
nearly zero.