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

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Mar 2016 08:02:38 -0400

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: <[email-masked]>
Date: Wed, Mar 23, 2016 at 12:45 PM
Subject: I-D ACTION:draft-lemon-homenet-naming-architecture-00.txt
To: [email-masked]

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
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Fri, 25 Mar 2016 12:18:57 +0100

see below.

Ted Lemon wrote:
> 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.
>
> 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!
>
>
> From: <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]>
>
>
> [email-masked] <mailto:[email-masked]>
> Internet-Draft 
> <https://www.ietf.org/mailman/listinfo/i-d-announce%0AInternet-Draft> 
> directories: http://www.ietf.org/shadow.html
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>

---

From: Ralph Droms <[email-masked]>
Date: Fri, 25 Mar 2016 08:29:28 -0400

(BCC dnssd WG mailing list)

Ted - now would be really good time to discuss draft-ietf-dnssd-hybrid, as it's in WG last call on the dnssd WG mailing list.

- Ralph

> On Mar 24, 2016, at 8:02 AM 3/24/16, Ted Lemon <[email-masked]> 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!
> 
> 
> A new Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> https://www.ietf.org/internet-drafts/draft-lemon-homenet-naming-architecture-00.txt <https://www.ietf.org/internet-drafts/draft-lemon-homenet-naming-architecture-00.txt>
> 
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> Internet-Draft <https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft> directories: http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
> 
> 
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet