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?
> 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?
> 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?
> 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".
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
i) Unmanaged operation
>
> I'm expecting a lively discussion on this topic :-)
OK, I've contributed to the discussion.
- Ralph
>
> Olafur
> _______________________________________________
> homenet mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
