On 29/06/2012 11:34, Ralph Droms wrote:
So, let's compare this with what I talked about during the Paris WG meeting:
* Disconnected operation ("fate sharing"): name resolution for reachable
devices continues if the local network is disconnected from the global
Internet
* Relative name resolution: some naming convention that allows name
resolution while mitigating the need to know an absolute location in the
global DNS namespace
* Representation in the global DNS namespace, for access from off-net
* Unmanaged operation
* Efficient message utilization: for example, keep unwanted traffic
off of an IEEE802.15.4 network
Merging those points with comments in-line...
On Jun 29, 2012, at 11:06 AM 6/29/12, Olafur Gudmundsson wrote:
After the Homenet meeting in Paris I realized that the group needs
good principles for its name-space work. The principles in -arch-02 are
a good start but IMHO not sufficient.
It makes not sense to be proposing/evaluating solutions when there
are no agreed upon principles/requirements.
The chairs have been bugging me to follow up with a contribution.
Below is my attempt at defining as compactly/broadly as
possible design principles for Name services:
a) Homenet name-service MUST NOT interfere with Internet name-service
"Internet name-service"? Do you mean "DNS"? "Co-exist" might be a
better word. Users want a single interface into naming and don't
want to have to differentiate between "naming stuff on my local network"
and "naming stuff in the Internet". Ted Lemon raised this issue much
more eloquently during the WG meeting.
I'll add my first bullet here, rephrased a little:
a.1) Relative name resolution: some naming convention that allows name
resolution while mitigating the need to know an absolute location in the
Internet name-service
b) Homenet name-service MUST NOT be in Internet name space.
How are things in the home identified from outside the homenet?
They will have to have two names one internal and one externally visible.
e) Homenet name-service MUST function throughout the whole "site"
c) Homenet name-service SHOULD support both lookups and discovery
What do you mean by "lookups and discovery"? Are they different
forms of name resolution?
lookup is direct query,
discovery may use broadcast/multicast messages or a service where
applications register in order to be found.
d) Homenet name-service SHOULD be considerate of bandwidth usage
e) Homenet name-service MUST allow segmentation of "name space" for
different classes/groups/cliques of applications/devices
What requirements is this segmentation intended to satisfy?
Think kitchen appliances and media center do they ever need to talk ?
I worry that if they talk, that one day I open the refrigerator and grab
a beer, now suddenly the music changes to polka.
But seriously, I want to be able to drop/ignore messages, that nothing
on the device cares about, at the lowest layer possible.
g) Homenet name-service SHOULD allow both broadcast service as well as
more traditional lookup service.
Seems like an implementation detail to support a higher level requirement
like "must not require a centralized registration/resolution service".
Maybe, but as some people seem to assume that only one and not the other
operating mode be used I wanted to put this on the table.
Two operational points from my list:
h) Disconnected operation ("fate sharing"): name resolution for reachable
devices continues if the local network is disconnected from the global
Internet
This is a violation of my principle b) home net names should always work
if the supplier of the data is awake.
I was debating to put in something about supporting devices that are
only sometimes on but decided to keep that out.
i) Unmanaged operation
This is a good one
Olafur
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
