On 19 March 2017 at 21:44, Suzanne Woolf <suzworldw...@gmail.com> 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.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
