Subject: [homenet] tunnels as way to disambiguate .local

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Jul 2012 19:04:32 -0700

Since I apparently got a few heads shaking today from my jabber comment,
I guess I should at least throw it on the list.

My observation -- and I'm not necessarily saying it's a [good] solution -- is
that one way that we could deal with the ambiguity of what fridge.local[site]
means  when I elsewhere is to say that .local[site] is exactly what it says it is:
a property of the local site. As such, if I'm roaming and do not have topological
connectivity, the proper way to get that connectivity would be to use some
form of tunneling back to the .local[site] I actually intended and thus be part
of the .local[site] topology again.

On the plus side, this puts it into the hands of somebody to deal with the
ambiguity. On the minus side, this puts it into the hands of somebody to
deal with the ambiguity.

Mike

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 01 Aug 2012 00:48:08 -0400

In message <[email-masked]>
Michael Thomas writes:
 
> Since I apparently got a few heads shaking today from my jabber
> comment, I guess I should at least throw it on the list.
>  
> My observation -- and I'm not necessarily saying it's a [good]
> solution -- is that one way that we could deal with the ambiguity of
> what fridge.local[site] means when I elsewhere is to say that
> .local[site] is exactly what it says it is: a property of the local
> site. As such, if I'm roaming and do not have topological
> connectivity, the proper way to get that connectivity would be to use
> some form of tunneling back to the .local[site] I actually intended
> and thus be part of the .local[site] topology again.
>  
> On the plus side, this puts it into the hands of somebody to deal with
> the ambiguity. On the minus side, this puts it into the hands of
> somebody to deal with the ambiguity.
>  
> Mike

For a mobile device, including a laptop, sitelocal should reflect
where you are.

In someone else's house, printer.sitelocal should be their printer.
If that someone else gives you authentication credentials or you give
then a public key and they install it on the printer, then you can
print.  Today, more likely the home printer is USB and you plug it in
to your laptop.

Getting to your own fridge or printer from elsewhere would require
that you have a domain name and know what your domain name is.
Presumably you'd already have whatever you need for authentication.

There is no ambiguity.

It is a personal choice whether you want to put sitelocal first in the
search path or your own domain first.  I suggest that your own domain
would be a better choice.  fridge means the same thing no matter where
you are.  fridge.sitelocal means the fridge near you if you are
elsewhere.

fridge.sitelocal. is a FQDN with site local scope.  fridge.yourdomain
is a FQDN with global scope.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 01 Aug 2012 01:02:00 -0400

Correction.  A mobile device on the a site's wireless LAN would see
fridge.sitelocal.  The cellular provider would be better off just
populating sitelocal with any services offerred by the cellular
provider, such as mediadownload.sitelocal or ntp.sitelocal (unlikely,
but hopeful).

Sitelocal might be problematic for a mobile phone in a fast moving
car on a highway through an urban area.  Sitelocal would change with
each cell tower handoff.

Curtis

In message <[email-masked]>
Curtis Villamizar writes:

There is no ambiguity.

Curtis
_______________________________________________
homenet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/homenet