Re: [homenet] draft-mglt-homenet-front-end-naming-delegation-01

Andrew Sullivan <ajs@anvilwalrusden.com> Wed, 07 November 2012 20:51 UTC

Return-Path: <ajs@anvilwalrusden.com>
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 9162621F8C3E for <homenet@ietfa.amsl.com>; Wed, 7 Nov 2012 12:51:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.683
X-Spam-Level:
X-Spam-Status: No, score=-0.683 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yx97yqO5hlOS for <homenet@ietfa.amsl.com>; Wed, 7 Nov 2012 12:51:48 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 1907A21F8C27 for <homenet@ietf.org>; Wed, 7 Nov 2012 12:51:47 -0800 (PST)
Received: from crankycanuck.ca (dhcp-2113.meeting.ietf.org [130.129.33.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 262BF8A031 for <homenet@ietf.org>; Wed, 7 Nov 2012 20:51:47 +0000 (UTC)
Date: Wed, 07 Nov 2012 15:51:34 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: homenet@ietf.org
Message-ID: <20121107205133.GE75182@crankycanuck.ca>
References: <20121107163120.GN74706@mx1.yitter.info> <FC97784E1B4396449E619F58B1738C1A20747D9E@PACDCEXMB15.cable.comcast.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <FC97784E1B4396449E619F58B1738C1A20747D9E@PACDCEXMB15.cable.comcast.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [homenet] draft-mglt-homenet-front-end-naming-delegation-01
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 07 Nov 2012 20:51:48 -0000

Out of order:

On Wed, Nov 07, 2012 at 05:46:20PM +0000, Griffiths, Chris wrote:

> As an operator who is deploying
> home network platforms to millions of customers today, I politely
> disagree that this problem is nearly solved today in shipping
> products, but could be solved with existing platforms and protocols
> which desperately needs documentation.

Yeah, that's probably a fairer description of what I was trying to
say, and I appreciate the correction.

> which desperately needs documentation..  Given the proposed
> architecture for Homenet, and the ability to have multiple layers of
> networks, there is going to be a need for a scaled approach to deal
> with internal and external naming which will need to include service
> discovery and publishing naming to outside the home.

This I strongly agree with.

Mostly, I am worried that this proposal is a cure worse than the
disease.  I've read the draft several times, and I just don't get why
it isn't better to put all this DNS data out in a public DNS server
somewhere, and have everything (including the nodes inside the homenet
boundary) query that.  If you want to reduce traffic, put a DNS
cacheing resolver on the CPE.  Use a simple-minded http-based
injection protocol for DNS data that the CPE can use (we have several
of those deployed, although none is an IETF protocol).

The proposal as it stands includes support for different views; for
mixed-mode authoritative and recursive services in the same resolver,
something we regularly say is a bad thing; and three options for
securing zone transfers, one of which we heard in mdnsext is the
barrier to adoption of unicast DNS DNS-SD.  Many of these tricks --
views in particular -- work only most of the time when careful
administrators set the whole thing up, and so I'm worried that we're
not going to be able to build automatic tools that allow this all to
work completely reliably, _especially_ when inside the homenet most of
the time people will actually get mDNS answers anyway and so there'll
be a mismatch between the name spaces.  It's mostly the complexity of
all of this that troubles me.

How much of it is necessary?  

Best,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com