Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt

Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> Fri, 04 July 2014 22:12 UTC

Return-Path: <jch@pps.univ-paris-diderot.fr>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDA01A004A for <homenet@ietfa.amsl.com>; Fri, 4 Jul 2014 15:12:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.349
X-Spam-Level:
X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35] autolearn=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 C_WEs_shx4Ai for <homenet@ietfa.amsl.com>; Fri, 4 Jul 2014 15:12:48 -0700 (PDT)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 B5FF71A003B for <homenet@ietf.org>; Fri, 4 Jul 2014 15:12:47 -0700 (PDT)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s64MCkZB027696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 5 Jul 2014 00:12:46 +0200
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id s64MCjrZ020258; Sat, 5 Jul 2014 00:12:45 +0200
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id CE8FD2A654E; Sat, 5 Jul 2014 00:12:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id FfjAvIJRMlB6; Sat, 5 Jul 2014 00:12:43 +0200 (CEST)
Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9F1DB115ED; Sat, 5 Jul 2014 00:12:42 +0200 (CEST)
Date: Sat, 05 Jul 2014 00:12:42 +0200
Message-ID: <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr>
From: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
To: Daniel Migault <mglt.ietf@gmail.com>
In-Reply-To: <CADZyTk=YgD=JtyDpEz8TXOQmHxKzBoiEZbbW0LhZQy2GaKLqZQ@mail.gmail.com>
References: <CADZyTkk6rUuFJ5Wds2hioBBQa9-kXDJxyg_gBGQ1R6u5CHF2Ww@mail.gmail.com> <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <CADZyTkk2bv7T-Bs_ckG4i2MpXVDRqLA2R1dQgrMVrPSckOy-GQ@mail.gmail.com> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <CADZyTk=YgD=JtyDpEz8TXOQmHxKzBoiEZbbW0LhZQy2GaKLqZQ@mail.gmail.com>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 05 Jul 2014 00:12:46 +0200 (CEST)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 05 Jul 2014 00:12:45 +0200 (CEST)
X-Miltered: at korolev with ID 53B726DE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 53B726DD.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 53B726DE.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/<jch@pps.univ-paris-diderot.fr>
X-j-chkmail-Enveloppe: 53B726DD.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@pps.univ-paris-diderot.fr>
X-j-chkmail-Score: MSGID : 53B726DE.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 53B726DD.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
X-j-chkmail-Status: Ham
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/7JmkTCBSSMs5nnH3VWPj6JAL0cA
Cc: "homenet@ietf.org" <homenet@ietf.org>
Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 04 Jul 2014 22:12:50 -0000

> The main idea is that the CPE builds the zone for the whole home network.

Thanks for the clarification.

Daniel, perhaps I'm still misunderstanding something -- but I'm afraid that
right now I'm strongly opposed to this protocol.  I hold no opinion yet on
whether proxying is necessary (although I hope it isn't), but I am strongly
opposed to binding the DNS proxy role with the CPE at the protocol level.
(This does not mean that the DNS proxy cannot be colocated with the CPE,
only that I find a protocol that mandates this kind of colocation unacceptable.)

> I am rephrasing your use case to make sure we have the same in mind. Please
> clarify if we do not agree on the use case. You consider is a web server in
> the home network, that you want to be reachable from the Internet. In order to
> do that you buy a specific domain name www.homenet.com. The domain is hosted
> on a Public Authoritative Server, you edit the zone, add the IP address of
> your server.

Oh, nothing that geeky.  I copy my vacation photographs onto my NAS.
I click the "share over the Internet" button on the NAS's web interface.
The NAS performs DynDNS registration, I get a link that I can copy-paste
into an e-mail to my mom: "Mom, the vacation photographs are on
http://www.user-fe83-paris-13.dyndns.example.com:8080/photos, the password
is 1234."  I've avoided putting my private photographs on Google's
servers -- and we're changing the world.

I click on the "share over the internet" button on my stereo's web
interface.  The stereo performs DynDNS registration, I get a link that
I can copy-paste.  "Daniel, the song you found so funny at my place last
night night is on http://www.user-fe83-paris-13.dyndns.example.com/funny-music,
the password is 1234".  I've avoided sending 20MB of Ukrainian R'n'B over
SMTP -- and we're changing the world.

I'm at the train station.  There's a strike on.  I'm playing Civilisation
on my laptop in an internet cafe.  I click the "Invite over the Internet"
button.  Civilisation performs DynDNS registration, I get a link which
I can copy-paste.  "Daniel, I'm bored, join me for a game of Civilisation,
link is civ://www.user-fe83-paris-13.dyndns.example.com, password is
1234", and now I can wholeheartedly support the cheminot's strike -- we're
changing the world again.

>     1) It is not scalable in term of configuration: if you have a single
> server, you can edit the zone. If you have 100 devices (which is not much) you
> will not be able to do it especially if you IP prefix changes every day.

Sure.  Just like you, I'm expecting dynamic updates.  But I don't expect
dynamic updates to be dependent on my CPE, which is buggy (it was provided
by the major competitor of your employer) and isn't available at the
internet cafe.

>     2) It is not scalable in term of software installation: every registrar
> have its own API for configuring the zone.

Then why not standardise a registration API?

> Furthermore, if you suppose all registrar agree to have a unique way to
> do so, -- suppose nsupdate -- all devices will have to implement this
> protocol. For most devices this may be not a problem, however, for all
> devices like sensors having to perform nsupdate every day, may impact
> their battery life time for nothing.

If you really believe that proxying is necessary (and I'd like actual
figures to support this claim -- how many devices do you have in your home
that cannot afford the cost of one registration every few hours?), then
there's nothing preventing a DNS proxy from using the standardised
registration protocol on behalf of its clients.  Then clients can choose
whether to go through the proxy, and users can choose whether use the
ISP-provided proxy (co-located with the CPE) or a third-party proxy that
happens to work.

>     3) It is not automatic and flexible: A new device that is in your network
> cannot have a name, as an admin needs to register its name in the zone 
> myhomenet.com, or provide the credential for it to all new devices.

That's what we have HNCP for -- for distributing random data to all devices.

>     4) It is not scalable in term of zone management and bandwidth: Suppose
> you have n devices in the home network and a renumbering occurs. All these n
> devices will contact the Public Authoritative Server that may be miles away
> from your home network.

I've got 100 devices.  I renumber.  Each device sends 500 bytes of
registration data.  My monthly Internet bill has just increased by 50 kB.

>     5) it exposes your homenet to IP disruption. Suppose your ISP has a
> connectivity issue, even a node in your home network will not be able to
> contact your web server as the DNS(SEC) resolution is not possible. 

But my nodes are still running mDNS/zeroconf, right?  Or are you deprecating
that?

-- Juliusz