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

[Ralph Droms <[e-mail]>]

On Jun 29, 2012, at 4:07 PM 6/29/12, Kerry Lynn wrote:

> 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.

Yes ... which is roughly the message I took from Ted's contribution at the WG meeting.  That way of thinking about local and non-local names might even be a GUI or some other way of presenting a list of choices to a user.  As long as there as the information is "just right" (not too much and not too little), the underlying resolution methods can be hidden.
 
> 
>> 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)?

Roughly speaking.  I think what's needed is some equivalent of RFC 1918 addressing: a way of doing name resolution that has a "local" context without needing to have a globally unique name for that context.

>  
>> > 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.

Or, perhaps, bandwidth requirement scales with the number of devices interested in the specific queries and responses.  Assuming the name-service functions across the whole site, I was thinking in particular of the case of an IEEE 802.15.4 network of constrained devices that don't need to see all the name-service traffic for printers, mobile devices, etc.
> 
>> > 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...

...if there is one.

>  
> i) Unmanaged operation
> 
> Yes!!!

A universal point of agreement?

- Ralph

> 
> -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
>