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>
- [homenet] Fwd: I-D ACTION:draft-lemon-homenet-nam… Ted Lemon
- Re: [homenet] Fwd: I-D ACTION:draft-lemon-homenet… Ray Hunter (v6ops)
- Re: [homenet] I-D ACTION:draft-lemon-homenet-nami… Ralph Droms
- Re: [homenet] I-D ACTION:draft-lemon-homenet-nami… Markus Stenberg
- Re: [homenet] I-D ACTION:draft-lemon-homenet-nami… Ted Lemon
- Re: [homenet] I-D ACTION:draft-lemon-homenet-nami… Markus Stenberg
- Re: [homenet] I-D ACTION:draft-lemon-homenet-nami… Ted Lemon