Re: [homenet] Fwd: I-D ACTION:draft-lemon-homenet-naming-architecture-00.txt

"Ray Hunter (v6ops)" <v6ops@globis.net> Fri, 25 March 2016 11:19 UTC

Return-Path: <v6ops@globis.net>
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 427F012D16F for <homenet@ietfa.amsl.com>; Fri, 25 Mar 2016 04:19:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 pZ2hRU6zKr0j for <homenet@ietfa.amsl.com>; Fri, 25 Mar 2016 04:19:06 -0700 (PDT)
Received: from globis01.globis.net (092-111-140-212.static.chello.nl [92.111.140.212]) by ietfa.amsl.com (Postfix) with ESMTP id 280F712D0AB for <homenet@ietf.org>; Fri, 25 Mar 2016 04:19:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id BCC4E40340; Fri, 25 Mar 2016 12:19:03 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at globis01.globis.net
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIBfGSj4_SKv; Fri, 25 Mar 2016 12:18:59 +0100 (CET)
Received: from Rays-MacBook-Pro.local (178-84-244-32.dynamic.upc.nl [178.84.244.32]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E6D5D402CE; Fri, 25 Mar 2016 12:18:58 +0100 (CET)
Message-ID: <56F51EA1.6040001@globis.net>
Date: Fri, 25 Mar 2016 12:18:57 +0100
From: "Ray Hunter (v6ops)" <v6ops@globis.net>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Ted Lemon <mellon@fugue.com>
References: <20160323164509.2510.24152.idtracker@ietfa.amsl.com> <CAPt1N1ni-01feyMSaa0-7GhFCXPSS0gPSL8fAzVnhWehih2Pug@mail.gmail.com>
In-Reply-To: <CAPt1N1ni-01feyMSaa0-7GhFCXPSS0gPSL8fAzVnhWehih2Pug@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------040702070501020003010601"
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/8Q8mHoplZLb-ZUmnEeyYufQMuHc>
Cc: homenet@ietf.org
Subject: Re: [homenet] Fwd: I-D ACTION:draft-lemon-homenet-naming-architecture-00.txt
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 25 Mar 2016 11:19:09 -0000

see below.

Ted Lemon wrote:
> I've published a straw-man homenet naming architecture document for 
> discussion at IETF in Buenos Aires.   This document is a first 
> attempt, and represents just my thoughts, not the thoughts of the 
> architecture team as a whole, because I didn't get it out in time for 
> us to discuss it--that's why I published it just in my name.
>
> It's a 20-page document, but should be a fairly painless read.   
> There's some extra detail in it that doesn't belong in the final 
> document because I wanted to include some ideas that need to be 
> fleshed out in other drafts, which don't yet exist.
>
> One big issue that DNSSD folks will recognize is that this draft does 
> not adopt mdns hybrid as a solution.   This is something I'd 
> particularly like to discuss--when I reread the MDNS hybrid draft in 
> the process of working on this document, I wasn't happy with the 
> direction it had gone--it didn't look like it would really be 
> consistent with the goals of the homenet project.   But I may have 
> misunderstood the intention of the draft, and I it may also be that 
> the Homenet working group would prefer to settle for something that 
> basically works rather than pushing to reinvent the wheel.
>
> Anyway, please don't take this document as an assertion that this is 
> definitely what the homenet naming architecture should look like.   
> Your reactions to what's written in the document - agreement, 
> disagreement, why is this missing, why is this here, will help to move 
> the discussion forward and get us to something that the working group 
> can have consensus on.
>
> Thanks!
>
>
> ---------- Forwarded message ----------
> From: <Internet-Drafts@ietf.org <mailto:Internet-Drafts@ietf.org>>
> Date: Wed, Mar 23, 2016 at 12:45 PM
> Subject: I-D ACTION:draft-lemon-homenet-naming-architecture-00.txt
> To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
>
>
> A new Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
>     Title         : Homenet Naming and Service Discovery Architecture
>     Author(s)     : T. Lemon
>     Filename      : draft-lemon-homenet-naming-architecture
>     Pages         : 20
>     Date          : 2016-03-23
>
>    This document recommends a naming and service discovery resolution
>    architecture for homenets.  This architecture covers the publication
>    and resolution of names of hosts on the homenet both within the
>    homenet and on the public internet, and the use of such names for
>    offering and discovering services that exist on the homenet both
>    within the homenet and on the public internet.  Security and privacy
>    implications and techniques for automatically and administratively
>    setting security and privacy policies for such names are also
>    described.
>
> A URL for this Internet-Draft is:
> https://www.ietf.org/internet-drafts/draft-lemon-homenet-naming-architecture-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft 
> <https://www.ietf.org/mailman/listinfo/i-d-announce%0AInternet-Draft> 
> directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
I have read the draft.

On the whole I think it is an excellent straw man. Thanks.

Some specific comments:

1. I think it would be useful at some point in the document to produce a 
matrix of functions/feature required for Homenet versus 
functions/feature supported by existing implementations. That would then 
lead to a gap analysis.

2. Like you, I'm not convinced that the DNSSD work I've read so far 
matches 100% with Homenet. Whereas it probably should.

3. I miss logical zones. Why just "public" and "local"?
Logical zones was an explicit part of the Homenet Architecture.

For the rest, there's a whole load of good detail information, but I 
miss the overview.


Section 2 dives straight into details of individual elements.

I think it would be better to start with an overview of the 
architectural elements we want in Homenet Naming, and then discuss the 
choices available, and their possible relationships. If we start with 
existing technology then we'll probably end up in a discussion of whose 
existing technology is better.

For example I'd start with something like:

A Homenet can be considered to be a well-defined collection of 
networking and end user equipment running under a common management as 
defined in the Homenet Architecture.

An Upstream ISP is an upstream network service provider using the IPv6 
Internet Protocol, directly connected to the Homenet at a Homenet Border 
Router. An Upstream ISPs may provide access to the global Internet, or 
they may be "walled gardens" with limited global connectivity.

A Homenet has zero or more upstream ISPs connected at the Homenet Border 
Routers. A Homenet may function completely isolated from the global 
Internet.

A Homenet Address Space is a contiguous block of globally unique IPv6 
addresses defined by a prefix, for exclusive use by this Homenet.

A Homenet utilizes one or more Homenet Address Spaces. Address spaces 
may be locally provisioned whilst ensuring global uniqueness (e.g. ULA), 
or delegated from upstream ISPs (e.g. via DHCP PD).

A name is a sequence of labels.

A label is an atomic element of a name. Individual labels must be 
locally unique and consistent at each point in the sequence of labels. 
This leads to a requirement for either a conflict resolution mechanism 
or a centralized label assignment mechanism.

An Upstream Name Space Provider is a provider of naming services. Unlike 
an Upstream ISP, the Upstream Name Space Provider may or may not be 
directly connected to the Homenet at a Homenet Border Router. Upstream 
Name Space Providers may provide access to resolution of the entire 
global Internet name space, or they may be "walled gardens" with limited 
ability to resolve names.

A Homenet Name Space is a proper subset of the globally unique name 
space, defined by a sequence of labels appended as a suffix. Global 
uniqueness is required due to the highly mobile nature of Homenet 
devices, and to avoid potential conflicts between Upstream Name Space 
Providers.

A Homenet utilizes one or more Homenet Name Spaces. The Homenet may 
locally provision its own Homenet Name Space (for stand alone 
operation), or by delegating name space from an upstream Name Space 
Provider.

A Homenet Zone is a proper subset of the Homenet Name Space, and which 
represents a logical grouping of names, services, and resources. A 
Homenet Zone may include a collection of links and end hosts that may be 
mapped onto security and privacy policies. So for example, the set of 
end nodes connected to a guest LAN may be placed in a specific Homenet 
Zone, and this Homenet Zone not published outside of the Homenet.

Then you can talk about the elements in more detail:

A Homenet Name is a concatenation of a sequence of labels (the Homenet 
specific portion) and a suffix (the Homenet Name Space)

The Homenet specific portion may be hierarchical or flat. A flat Homenet 
Name Space is desirable to ease conflict resolution as nodes and 
services relocated within the Homenet.

Homenet Name spaces may be locally hosted, ISP hosted, or 3rd party 
hosted (ISP independent).

The Homenet specific portion of names within a Homenet Name Space can be 
generated by nodes, or by the infra, or a combination of both.



-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>