Re: [homenet] Name service design principles: a proposal

[Kerry Lynn <[e-mail]>]

On Fri, Jun 29, 2012 at 11:34 AM, Ralph Droms <[e-mail]> 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:
> >
>
You don't state the usual "strong bias toward existing standards/running
code",
so I assume it goes without saying ;-)


> > 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'd go further and say users want a single way to THINK about local and
wide-area names and resolution.  Some of us with a strong bias toward a
DNS-like solution have been looking at this issue for 2+ years in other
contexts.


> 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
>
> Is the desire here to preserve the "main" element of the name (e.g. the
leftmost label of a FQDN)?


> > b) Homenet name-service MUST NOT be in Internet name space.
>
> How are things in the home identified from outside the homenet?
>
> It would be helpful Olafur if you could provide some motivation for these
requirements.   I agree that local naming and discovery should be possible
without requiring a directory server.  But if I can access
myHost.myDomain.net
from outside, why not from inside the home net?


> > 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
> >
>
Could this be restated as "the bandwidth requirement for discovery should
remain
relatively constant as the network scales"?  The cost of achieving this may
be
to add additional elements like proxies or directory servers to the network.

> 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?
>
> This may be tricky in practice, and should be prioritized relative to
other requirements.
We discuss methods in http://tools.ietf.org/html/draft-vanderstok-core-dna.
 If
this requirement must be met by a multicast protocol, the fact is that many
OSs
only support a handful of multicast addresses.


> > 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".
>
> An important point here is that existing discovery protocols are not going
away any
time soon and could be leveraged to "seed" a directory server with records.

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
>
> And if the local directory server goes down...


> i) Unmanaged operation
>
> Yes!!!

-K-


> >
> > I'm expecting a lively discussion on this topic :-)
>
> OK, I've contributed to the discussion.
>
> - Ralph
>
>
>
> >
> >    Olafur
> > _______________________________________________
> > homenet mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/homenet
>
> _______________________________________________
> homenet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet
>