Re: [homenet] review of draft-ietf-homenet-redact and draft-ietf-homenet-dot

Jari Arkko <jari.arkko@piuha.net> Sun, 12 March 2017 12:45 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260DF1293EB for <homenet@ietfa.amsl.com>; Sun, 12 Mar 2017 05:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pij7yul907hs for <homenet@ietfa.amsl.com>; Sun, 12 Mar 2017 05:45:03 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id C8C00128DF6 for <homenet@ietf.org>; Sun, 12 Mar 2017 05:45:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1E6D32CFD8; Sun, 12 Mar 2017 14:45:02 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcMrGWYtQpMn; Sun, 12 Mar 2017 14:45:01 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 78F6E2CCC1; Sun, 12 Mar 2017 14:45:01 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_363526B9-2FB4-4478-B2A0-6879B6AC88A1"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <43E15F33-EFE4-4690-88FD-76977C930055@fugue.com>
Date: Sun, 12 Mar 2017 13:45:01 +0100
Message-Id: <A7C3CA63-7D0A-4F93-9924-7384E713D43B@piuha.net>
References: <42ECD4C1-3A87-414C-91D3-8B709A8B3FB5@piuha.net> <43E15F33-EFE4-4690-88FD-76977C930055@fugue.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/z6w3sIhzR7XPig2f7rJqQs8A_Eo>
Cc: homenet@ietf.org
Subject: Re: [homenet] review of draft-ietf-homenet-redact and draft-ietf-homenet-dot
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Mar 2017 12:45:05 -0000

>> I would like to add that the issue is not just a process issue;
>> the questions one would have to answer (like how other
>> entities in the Internet should deal with the newly allocated
>> name) went unanswered. Maybe:
> 
> While this is true, it is not why we are doing the redact.   We actually do the enumeration in homenet-dot.   I think changing the text would confuse the issue by leading the reader to believe something that isn't true.

Perhaps, but I wanted to be accurate as to why the original thing
wasn’t satisfactory. Your point about confusing with regards to
the current thing is of course valid. Presumably that could
be addressed by explicitly saying that there’s ongoing work
that intends to not make the same mistakes :-)

>> However, there are first of all some unclear
>> details, but more importantly, I fear that the class of
>> name being requested is wrong. I say this with the
>> understanding that I’m not an DNS expert, but despite
>> efforts I have failed to understand the logic, and I can
>> see some issues in doing it the way that you’re crafting
>> the request.
> 
> You use the word type later on, not class, so my initial reaction to this text was wrong.   To be clear, I assume you are not proposing that we use a different CLASS value.

Right. Sorry. You can tell that I’m not a DNS expert… :)

> 
>> I’m not clear how to implement this MUST NOT. Is there
>> a requirement here that any recursive resolver either
>> knows about the logical boundaries of a home network,
>> or does not forward .homenet queries?
> 
> This is addressed in points 4 and 5 of section 3.   Your objection to the normative language in section 2 makes sense, though.
> 
>> This is fine, but that should probably be ‘… any assumption
>> about the security properties based on the use of this special
>> name.’ (It is not clear to me that there’d be additional security
>> level, could also be reduced security, e.g., if DNSSEC was not
>> locally available.)
> 
> That makes sense.

Ok.

More later, gotta run. Thanks for the quick response!

Jari