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: <[email protected] <mailto:[email protected]>>
Date: Wed, Mar 23, 2016 at 12:45 PM
Subject: I-D ACTION:draft-lemon-homenet-naming-architecture-00.txt
To: [email protected] <mailto:[email protected]>
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 protected] <mailto:[email protected]>
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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
