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

Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> Thu, 03 July 2014 12:14 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 86D2F1B2919 for <homenet@ietfa.amsl.com>; Thu, 3 Jul 2014 05:14:03 -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 nYxA_CfbBZFl for <homenet@ietfa.amsl.com>; Thu, 3 Jul 2014 05:14:02 -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 BAB751B2916 for <homenet@ietf.org>; Thu, 3 Jul 2014 05:14:01 -0700 (PDT)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s63CDxca002145; Thu, 3 Jul 2014 14:13:59 +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 8F67C2C0CA1; Thu, 3 Jul 2014 14:13:59 +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 2t5kgq-0E8RF; Thu, 3 Jul 2014 14:13:58 +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 6286E2C0C8B; Thu, 3 Jul 2014 14:13:58 +0200 (CEST)
Date: Thu, 03 Jul 2014 14:14:04 +0200
Message-ID: <87k37uy703.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: <CADZyTkk2bv7T-Bs_ckG4i2MpXVDRqLA2R1dQgrMVrPSckOy-GQ@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>
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 [194.254.61.138]); Thu, 03 Jul 2014 14:13:59 +0200 (CEST)
X-Miltered: at korolev with ID 53B54907.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 53B54907.001 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 : 53B54907.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/m3tmE8m1pt11YIB5yAtWUMFlv3c
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: Thu, 03 Jul 2014 12:14:03 -0000

Thanks for your answer, Daniel.

> If I understand it properly, the use case you consider: 1) you set up
> a web server in your homenet, 2) you want it to be accessed from the
> outside so you register your domain name and register the IP address to
> the zone. Note that In this case, the Authoritative Naming service is
> outsourced to a third party which is what we want to achieve to.

No, I think that I'm speaking of the same use case as your draft.  (I'm
not sure, since your draft takes the use case for granted -- I'm probably
missing some background here, sorry for not being more attentive previously.)

I've got a device that wants to be advertised in the global DNS (a web
server is the obvious example, but it doesn't matter).  Your draft
suggests (I think) that the device should speak to the CPE which will take
care of the interaction with the public DNS (arrow 6 in Figure 1 is
missing, by the way).  I'd like to understand why the device needs to go
through the middleman rather than speaking directly to the authoritative
DNS server.

My family was poor but honest, Daniel, and NATed addresses were all we
could afford.  Notwithstanding our difficult conditions, my parents took
a lot of care to bring me up to believe that end-to-end is always better
than proxying.  Since you're advocating proxying, I'd like to understand
why you think it is necessary.  What is more, I'd like to understand why
you require that the proxy be co-located with the CPE.  (It could
certainly be implemented on the CPE, but I don't understand why the
protocol requires that.)

You give some good reasons below, and I think they should be included in
the draft:

>     - Ease the naming of device of various nature.

Please explain.

>     - CPE remains in the homenet and may be easier to be authenticated
> than all different devices.

Good point.

>     - CPE presents a centralized point for end user interactions

I'm not convinced about that, the authoritative DNS master seems like the
natural place for end-user interactions.  (Note that this does not prevent
the CPE's web interface from implementing some sort of proxy to the DNS
master's interface.)

>     - CPE are "powerful enough" to handle complex policies...

Everything is powerful enough nowadays.  My abacus has a four-core chip.

>     - CPE can integrate multiple protocols to publish a zone. Suppose mDNS is
> used by a node, than registration of its IP address and name cannot be
> perfomed on a public authoritative server cannot be performed using mDNS.

I strongly disagree.  I don't want mDNS->DNS proxying.  Registering in the
global DNS is something that should be under user control, while mDNS
is something that happens automatically (for better or worse).

-- Juliusz