Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Toke Høiland-Jørgensen <toke@toke.dk> Sun, 13 August 2017 13:32 UTC

Return-Path: <toke@toke.dk>
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 946BB13262B for <homenet@ietfa.amsl.com>; Sun, 13 Aug 2017 06:32:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk
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 0sQqThrpfJEE for <homenet@ietfa.amsl.com>; Sun, 13 Aug 2017 06:32:11 -0700 (PDT)
Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03EC01324B9 for <homenet@ietf.org>; Sun, 13 Aug 2017 06:32:10 -0700 (PDT)
From: Toke Høiland-Jørgensen <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502631127; bh=iPytzBgroCiZu5FNjP0zIm76QPObGTvPvGZB97yEv5U=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nuo9LMaT9G45f75BW7kFcuYbNGeSIgICDVUDXDSp4VT/9nJJoSklZ+Rqg+PIgx4/r t5QUJtk3a6CULUTD0OY1OSGZ0c7q0299wSnYS+rDATunz/h3qgdzKOUUvvkBcUmlO4 I5jovJENZElmJdf1q2L8Fn/5fxY56/ONKX+p/3zz4bjviIMLOiFJxV/NBFQ2UCEJnc iAFVRxicD5hYgO1GsWBvDsH+sFs2GLfaYsYaYRSAuG2LsS7e5fXy0ZHeiIejZOyZcB wfv743yzn24kJA91ynzIbmRBUO2JW7H0RsA2i3IZOaY1BcSskPoZPNDYv8I4VvxyVB zGk3ShDgTLojw==
To: Ted Lemon <mellon@fugue.com>
Cc: Juliusz Chroboczek <jch@irif.fr>, HOMENET <homenet@ietf.org>
In-Reply-To: <CAPt1N1=oiU+DbjD6izOBNJOnC25d=-S3ARqFxydRfWLEet5mEQ@mail.gmail.com>
References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <A9C8CA05-54A0-4160-B2F0-645744BD259E@fugue.com> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <CAPt1N1m+218+FX_G+2W-msDWmxP8XXMKF9S0faTeCBnEEzk1uw@mail.gmail.com> <877eyaz2jm.fsf@toke.dk> <CAPt1N1m5nVGD-y2VrbkoTEPTs4qF98oRxGuvd-Has1yzuS0fmg@mail.gmail.com> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <CAPt1N1=oiU+DbjD6izOBNJOnC25d=-S3ARqFxydRfWLEet5mEQ@mail.gmail.com>
Date: Sun, 13 Aug 2017 15:32:08 +0200
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87valry4o7.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/2DAcrvSmQ50youegO6hAm2ismw8>
Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.22
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, 13 Aug 2017 13:32:14 -0000

> The point is that what I have specified in the architecture document is
> what is minimally required to allow a homenet to function given ordinary
> ISPs and ordinary users.   I think trying to do some of the things on the
> above laundry list would be very interesting work; trying to get it to
> where end-users can use it without being experts and without being made
> vulnerable to scams would be very cool, but is out of scope for this
> document.
>
> Does that make sense?

Sure. I'm just not sure I agree that MPvD shouldn't also be on the "nice
to have" list, rather than the "absolutely required" list.

Perhaps it would help if you could explain (a) the details of "the CDN
problem" (what mechanism is used to determine answers for a given
prefix, and what is the failure mode if the wrong address is used?), and
(b) how the client is supposed to actually work with this mechanism
(seems to me an unmodified client will probably make a mess of things?).

As for an "ideal" resolver behaviour, to me that would be full recursive
resolution from the root inside the home, replicating all queries across
all upstreams and picking the best reply (best being something like
"first reply that passes DNSSEC validation"). With an "advanced
configuration" option somewhere that allows the user to override
arbitrary names/zones as they see fit.

-Toke