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

Ted Lemon <> Mon, 20 March 2017 20:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1456E1293E9 for <>; Mon, 20 Mar 2017 13:15:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6HA11sYFZujb for <>; Mon, 20 Mar 2017 13:15:53 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD3D4126C0F for <>; Mon, 20 Mar 2017 13:15:53 -0700 (PDT)
Received: by with SMTP id n21so116566843qta.1 for <>; Mon, 20 Mar 2017 13:15:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2uVPOmhrIRxJYATJRDTGxp605VBsh1waEr/uOSXMZBM=; b=CiIOT9FaCUCsW/aIcvHVvOniXIAw6uYTGG3yy/hPkmggG8hpainXRAzcHEKAR0CN0l 38W3BIuKJhbXkxoT3GzHaaCyqfNc9uaimC9C5vIlqtkEqV9n124CimnLY5Kqmp834cGI gt58yzSJaw9Ag/sc6eKq1iZj5rvo9HT5kbNLOeIs2VSH4YAjF9UrtvN5AsGTYKEJEgQa jc/v47tBgkFB4Ndw2lYUP90IQyhDZffolm5UOSjiku30OwBFGBSvwS6kORl9wT/qdVJA 9gsTa4EHrjHSdHJO8DaQssdconGPenNj84BlvKtfFiaWtlyqat5DNHjTXy5ULZkWYor8 TxTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2uVPOmhrIRxJYATJRDTGxp605VBsh1waEr/uOSXMZBM=; b=W2pvvJ2tUSdNlk8OgsjLP1cEpa+rLr2rkl1ft6tPLl+d8bF05LAx5MAz3sj0UXmeBi kfXtOegajnndKLRw8w9RS2DvzOwhWFBsdgM0GkaqHTCnKnjK54jdBVYIgeGxO3fzf7+M GcBbqMtow4rOJ1A5d6t+PnAS29cbY3qSvZfgery4L844mLbviVdMexlnO4pD/cQpzapK RHKXPxj92QqY4NyPf//yBgFVpy4+sjW+AOnVvUsJNvXnBIZgfqD6afqYAIQmgHmurd/i huHH+nt9L/iCQ9sGqOzCn6gQG1fFGSv2JizH7sTxIUn9Au+74AUYGnS3NKXN0KovzMGE xDRQ==
X-Gm-Message-State: AFeK/H3nhM1hBxfxo6CiKXpX+4BIZy5SJa68DYUXVBvdtP2aKsC64z0uNTW7fmKhlJ+EIg==
X-Received: by with SMTP id k24mr31670889qta.67.1490040952663; Mon, 20 Mar 2017 13:15:52 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id j11sm13086744qta.39.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Mar 2017 13:15:51 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DE353637-BDCD-4402-BADC-A4D54FC87F7C"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Mon, 20 Mar 2017 16:15:50 -0400
In-Reply-To: <>
Cc: Ralph Droms <>, dnsop <>, Terry Manderson <>
To: Russ Housley <>
References: <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Subject: Re: [DNSOP] WG review of draft-ietf-homenet-dot-03
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Mar 2017 20:15:57 -0000

On Mar 20, 2017, at 3:44 PM, Russ Housley <> wrote:
> This document does not describe a collaborative approach.

The document specifies what the working group needs to have happen in order for the specification to work.   How the collaboration happens is out of scope for the homenet working group.   The working group understands that a process needs to be invented, and I believe that the document says so.

> Steve Crocker has already stated that he does not believe that entries that cannot be DNSSEC signed belong in the DNS root zone.  I know that others share this view.  For this reason, I do not think that the IETF should approve a document that specifies this processing until the root zone publication process is successful.

Yes, I understand that Steve Crocker has said this.   And perhaps Steve Crocker's opinion should be considered normative.   However, like you, Steve didn't give a technical reason why this policy must be applied universally, even in the case of technical uses.

We have a legitimate question to answer here.   It seems reasonable to say that under the MoU, the IETF can designate a name for the use that homenet is trying to designate.   Maybe the IETF consensus will be that the IETF should not designate this particular use.   But it doesn't make sense to me that the IETF should decide not to try to do what the working group thinks is the right thing technically, because the process for doing this thing is not yet known.   If the IETF doesn't try to do this, the process will never be known.   So I don't see how this can be a valid technical objection to going forward with the proposal.

> Further, the intent is that .homenet will be used with the DNS protocol.  Section 3 of the document makes it very clear that users, applications, resolution APIs, and most resolvers will not to treat that domain name in a special in any way.  For this reason, I do not think it meets the definition of a special-use domain name in RFC 6761, which says:
>    ... if a domain name has special properties that affect the
>    way hardware and software implementations handle the name, that apply
>    universally regardless of what network the implementation may be
>    connected to, then that domain name may be a candidate for having the
>    IETF declare it to be a Special-Use Domain Name and specify what
>    special treatment implementations should give to that name.
> So, I think that the desired outcome requires the use of the existing process to get it registered in the root zone and some standards-track RFC to describe the environment where:
>        … Only a DNS server that is authoritative for the root ('.') or is
>        configured to be authoritative for '.homenet' or a subdomain of
>        '.homenet' will ever answer a query about '.homenet.’

I don't think this is a correct reading of RFC 6761.   If it were, we could drop most of the considerations in section 5 of the document.

As for the process, it may be that in the end, ICANN pushes back and says no, absolutely not, we won't do this.   But when they say that, they will give a reason.   It is their decision to make, not ours, as long as they don't violate the MoU.   Our decision is whether or not to ask them to make this decision.

Maybe there is a good reason not to ask them.   If so, you haven't yet stated that reason.