[homenet] tuscles and conflicting goals / trust with draft-tldm-simple-homenet-naming CFA

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 16 August 2017 19:50 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 1764B1326D6 for <homenet@ietfa.amsl.com>; Wed, 16 Aug 2017 12:50:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ubx4XpqRBSB1 for <homenet@ietfa.amsl.com>; Wed, 16 Aug 2017 12:50:37 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9644132350 for <homenet@ietf.org>; Wed, 16 Aug 2017 12:50:37 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 18E51E1ED for <homenet@ietf.org>; Wed, 16 Aug 2017 15:53:16 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 80ECA80B17 for <homenet@ietf.org>; Wed, 16 Aug 2017 15:50:36 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: HOMENET <homenet@ietf.org>
In-Reply-To: <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com>
References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.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> <87valry4o7.fsf@toke.dk> <FCAD81FA-BBA0-45B0-8F1F-D1D5FD010484@fugue.com> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <E3E75086-BF36-4F59-86BD-7FFDAFE772AB@fugue.com> <87fuctxdrc.fsf@toke.dk> <FB44A942-9DE3-4CE6-88C5-402B20756462@fugue.com> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 16 Aug 2017 15:50:36 -0400
Message-ID: <12755.1502913036@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/wQUrbWICxMc1Hvy8fIwbOwyhiSc>
Subject: [homenet] tuscles and conflicting goals / trust with 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: Wed, 16 Aug 2017 19:50:40 -0000

Ted and Toke have many emails about DNS and servers and the like.
I think that it would be useful to take a few steps back to understand some
assumptions.  Many of these are tied up in layer 8 and layer 9 issues.

Toke wrote:  in my part of the world ISP DNS servers are
             broken *by design*

Ted meanwhile has written that that there are potential situations where
one provider may intentially misconfigure something so that a customer
will pick a more expensive way to get data.

In both cases we are trying to build into our protocols some kind of defense
against stupidity.   In Homenet, we are really trying to defend against
ISP stupidity, while trying to leverage intelligence from the ISP to guard
against end-user stupidity.

I don't pretend to capture their debate very well.

A lot of the DNS publish/public/private, etc. debate centers around tuscles
between clue-ful users (engineers) on this list who want to code something
sensible so that they can share their clue with the clueless, vs other
engineers who want to enable clue-ful ISPs to provide service to clueless
users.  Then the response from the first group is that this might force them
to do stupid things which they have fought against for ages.

I can not really characterise the debate very well, but this is what I think
I know:

1) ISPs that insist on controlling too much in the homenet will find
   themselves fighting against Googles, Apples (and Microsoft) who want it
   to work right.   We see this in the CAPPORT debates.
   By and large, "we" (the public) have "routed around" ISP stupidity, but
   the collatoral damage to the infrastructure has been immense. (e.g:
   NAPT44, SCTP, ...)

2) It's very hard to get people to vote with their wallet when it comes to
   poor ISP performance.  Performance usually means speed, but of course
   there is a whole lot of other variables.
   The 300Mb/s-marketing-speed fiber vs high-quality 50Mb/s IPv6, and my very
   technical friends pick the "faster" connection....
   Many times, it is because nobody has any actual information.  Such as,
   how often they are really getting 300Mb/s, or how often they are using
   IPv6 via a bad tunnel.

3) We've tried in HOMENET to automate things; and at the DNS space we are
   getting to limit of how much policy we can derive automatically.   There
   is SIGNIFICANT work that we can do to automate the implementation of the
   policy, if we can figure out what the policy is.

So I suggest that in order to make progress, we should split things up into
ways to implement a policy (assuming the policy is known a-priori), and ways
in which can we collect information about when the policy is failing so that
things can get fixed; perhaps by a local geek, perhaps by a clueful ISP
helpdesk, or eventually, perhaps by a smarter HNCP end-point.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-