Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 30 March 2017 04:41 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B017F129572; Wed, 29 Mar 2017 21:41:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 qgTBRyWxYCfJ; Wed, 29 Mar 2017 21:41:01 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B885129445; Wed, 29 Mar 2017 21:41:01 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id b140so12080865iof.1; Wed, 29 Mar 2017 21:41:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3/Yv0uEFj/rCgItYGiY1hdPHWI3qRb+vRR/dgng5Mik=; b=qqahZI/qlRLiozgqXOzyRy5NCpqYLW0YKwTG5yLucB9D+3402sK4zRSbgMY406dcj3 oi+ksHRlc36rZ2tsNfV+tHYnMZlJU18ETjuLgcof+KxUo70GpsXy5Usrrhp4DvaiVIWQ xYcnuD3SBFj7349Hl1TcAU2E+ITMGw5Y1xq9/LTfo/8EYcIfTAns3Bo2XhLDmvhwoj2O Is1mKpE3Zm8kmb2ktYraBxTL2tsSsEmPzOHUgKYbiQpB5ECrvhdKn9Zk40s1hsnk6IuQ P7iPgfdEjyLTLde+q04T2tWz4Bl6dnpLU35hwBzGonzzypQgXrSoxEYvL789qWvvnwQh OyGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3/Yv0uEFj/rCgItYGiY1hdPHWI3qRb+vRR/dgng5Mik=; b=L+aa0kHn8FFaRZX0yRrgqQyocBYx4DK9bFCmjcEv6qmZ3ROcBQiAkLY5ZD+FTte/E9 WtO2U8HlNFLXpoNpI17MFrQZ3n/0aJTFBXkYAeCMzcyrNN+L7U7t0gyfcXYufnj+2iPW TbWyqWNK4Fb4MBEvQv8SkxklPkN3/0j9J6xwUgeD0LuIw0Vr+lZYdjcY1WG324ueswMq N9UN3O4e24bqhIe7y5NRxVDxP9CPOjCMO9K9LoBxZTTmNZRuj+FOP9leUIMU1M94RrUB GSfw31GlKs8h7riGOZqG35VxmuUmz0PR/RCJ6n5I8lbFOVVHYH2s9A1gywcu2/wBOOPT UpTA==
X-Gm-Message-State: AFeK/H2WgeoXr/Po1XL70wAU1q6hbRkvHOn0HyQXFw5iA5Ps691Nrys0MY8CW4GCoKLQfZpHQFcChJvzbfHygA==
X-Received: by 10.107.136.41 with SMTP id k41mr5326826iod.160.1490848860719; Wed, 29 Mar 2017 21:41:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.46.151 with HTTP; Wed, 29 Mar 2017 21:41:00 -0700 (PDT)
In-Reply-To: <D04E5190-AEE4-4F0A-9879-A913D5E65C28@townsley.net>
References: <DAC83E33-A206-4EAA-BC96-E26ACCC013A6@icann.org> <29150.1490800075@obiwan.sandelman.ca> <D04E5190-AEE4-4F0A-9879-A913D5E65C28@townsley.net>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 29 Mar 2017 23:41:00 -0500
Message-ID: <CAH1iCiozhJ3CxRDXh8R1kfv40SZvA2MqPmsstx__+34BRowwUw@mail.gmail.com>
To: Mark Townsley <mark@townsley.net>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, HOMENET <homenet@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>, Terry Manderson <terry.manderson@icann.org>
Content-Type: multipart/alternative; boundary=001a113ec618c1d412054beb4ce3
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3fvH2uBiX7kqRSiqwYAfMN1LDmg>
Subject: Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2017 04:41:04 -0000

On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley <mark@townsley.net> wrote:

>
> > On Mar 29, 2017, at 10:07 AM, Michael Richardson <mcr+ietf@sandelman.ca>
> wrote:
> >
> >
> > Terry Manderson <terry.manderson@icann.org> wrote:
> >> B) seek a .homenet special use domain WITHOUT the delegation request
> >> AND ask the IETF/IESG/IAB to commence the discussion with the ICANN
> >> community to achieve an insecure delegation
> >
> >> c) seek a <SOMETHING>.arpa insecure special use delegation
> >
> >> d) go for "B" and if that doesn't work shift to "C"
> >
> > Is there some reason we can not proceed with "C", concurrently with (B).
>
> I think that would require a new consensus call. There was a lot of work
> done to get to the point of agreeing on a path forward at the last IETF,
> and this path would be rather different than that.
>
> > This might cause stub resolvers to have to have two cases
> > (SOMETHING.arpa, and .homenet) eventually, but at least we could deploy
> > and attempt interop with SOMETHING.arpa NOW, and it would more clearly
> > permit "home." to be removed from code.
> >
>
> /chair-hat-off
>
> I don’t think we want to have two defaults in our specs. It’s bad enough
> that we are already going to end up with .home and .homenet depending on
> the version of code used or forked from, I really don’t want to do anything
> that could lead to a third if we can avoid it.
>
> - Mark
>

Taking a STRICTLY devil's advocate position here:

Isn't it the case that the thing that knows what the <homenet> label is,
should be able to masquerade on behalf of anything that isn't aware of the
divergence of the three possible values for <homenet>? If you end up with
some boxes thinking it is ".home", some ".homenet", and some
".homenet.arpa", as long as one of them knows about all three, it should be
possible to resolve the differences.

The scope of the namespace is "the home network", and never reaches the
real DNS (roots), so at worst it would be folding the three fake namespaces
into a unified (three-headed) fake namespace.

I.e. avoid it if you can, but if you can't, I think the issues are
solvable, even if they get a little funky/ugly under the hood.

None of that should be visible to users, I don't think.

Brian

P.S. Guide to implementers - never expose multiple handles for the same
object; over-exuberant users may be tempted to try to "clean up" the
duplicates.