Subject: [homenet] IETF 87 - call for agenda items

From: Ray Bellis <[email-masked]>
Date: Thu, 4 Jul 2013 07:48:54 +0000

The Homenet WG is currently scheduled to meet for 2.5 hours on the Monday of IETF 87 at 09:00

Please send requests for agenda time to the chairs as soon as possible, and not later than the (single) draft submission deadline of July 15th.

In the event that we get too many requests for agenda time, priority will be given to drafts and/or ideas that have generated active discussion on the list.

thanks,

Ray & Mark

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Jul 2013 09:56:09 -0400

I would like the WG to spend some face time dealing with (making a list of),
things that need to be configured, which are not routes.

(So, I would include prefixes in the list)

I think that it is important for the group as a whole to recap some of the
discussion that has occured here.

If it would help the group, I could write a draft that had an initial list.

(I will not be in Berlin, but I will be remote)

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 5 Jul 2013 08:53:50 +0200 (CEST)

On Thu, 4 Jul 2013, Michael Richardson wrote:

> I would like the WG to spend some face time dealing with (making a list 
> of), things that need to be configured, which are not routes.

I would like to see a scheme where anything can be configured, including 
stuff which can be vendor-specific/proprietary so vendors can deploy new 
functionality quickly without going through a standardisation process, and 
then at a later date when it becomes a standard, they can abolish the 
vendor-specific identifiers they've been using. I'm thinking along the way 
SNMP works here... So yes, there should be a discussion about what homenet 
needs to be configured, but overall I would homenet to create a solution 
that other configuration information can ride along with.

High level goal I have in mind I would like to see "just working" in 5-10 
years.

I buy a new device. I unpack it and start it up. It sees a bunch of Wifi 
networks, I select one that is mine. On another device I run a "control my 
home" app, where I can see in chronological order what devices have 
requested access. I grant access to the device I just started up, it 
connects, sees configuration information from the network, and asks what 
role it should configure itself as. I select "Mikael Abrahamsson portable 
device", and through the same app mentioned before, I get a request, and I 
grant it. Now this device aquires a certain amount of privileges and 
configuration that I have configured all my portable devices to have, 
including mail accounts etc. All authorization/encryption/communication is 
done encrypted with a TPM style component internal to the device. Now this 
device automatically has configured itself to have my printers etc.

Now I bring this device to my friends house. He has already allowed access 
to "Mikael Abrahamsson devices" with some kind of guest privileges. My new 
device has already received information about what "friends" I have and 
since my friends network is broadcasting a key that belongs to my friend, 
my device automatically tries to connect, before that it verifies that the 
public key is correct (authenticating the network), my friends network 
autenticates my device, and my new device is allowed to connect without 
any unique action taken by my friend or me.

Same thing when I buy a new network device to connect to my network, I 
connect it, authorize it, what role it should have, and then everything is 
configured automatically.

The above scenario requires a staggering amount of configuration 
information, discovery and interaction. Not all of it new, but it needs to 
be tied together a lot and whatever configuration/discovery architecture 
we come up with should not be in the way of future developments in this 
area.

Am I totally "up in the sky" with the above vision of where things should 
be headed, or do we have a shared long-term vision within the WG?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 5 Jul 2013 16:59:16 +0900

> (So, I would include prefixes in the list)

I disagree that routes prefixes can be treated separately from routes,
because one router's prefixes are every other router's routes (well, either
that,or things don't work).

Far be it from me to object to people doing more work, but... isn't it
premature to attempt to define a generic architecture to configure anything
that's possible to congfigure? That seems like it's a lot to bite off, and
would take a while. Can we get away with a layered approach, where we first
build a network with working routing, and then we figure out how to run
services on top of it?

---

From: Ray Hunter <[email-masked]>
Date: Fri, 05 Jul 2013 13:02:06 +0200

Lorenzo Colitti wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I would like the WG to spend some face time dealing with (making a
>     list of), things that need to be configured, which are not routes.
>
> because one router's prefixes are every other router's routes (well,
> either that,or things don't work).
>
> premature to attempt to define a generic architecture to configure
> anything that's possible to congfigure? That seems like it's a lot to
> bite off, and would take a while. Can we get away with a layered
> approach, where we first build a network with working routing, and
> then we figure out how to run services on top of it?
I think the hugely varying abilities of homenet devices is going to
*force* a layered approach: sensors, routers, high capability/ media/
phones etc.

Sensors being fixed and extremely limited, routers standardised and
cross-vendor interoperable, and the rest highly extensible and possibly
vendor specific.

regards,
RayH

---

From: Tim Chown <[email-masked]>
Date: Fri, 5 Jul 2013 12:20:21 +0100

On 5 Jul 2013, at 08:59, Lorenzo Colitti <[email-masked]> wrote:

> On Thu, Jul 4, 2013 at 10:56 PM, Michael Richardson <[email-masked]> wrote:
> I would like the WG to spend some face time dealing with (making a list of), things that need to be configured, which are not routes.
> 
> I disagree that routes prefixes can be treated separately from routes, because one router's prefixes are every other router's routes (well, either that,or things don't work).
> 
> Far be it from me to object to people doing more work, but... isn't it premature to attempt to define a generic architecture to configure anything that's possible to congfigure? That seems like it's a lot to bite off, and would take a while. Can we get away with a layered approach, where we first build a network with working routing, and then we figure out how to run services on top of it?

That seems eminently sensible.

Tim

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Jul 2013 09:42:03 -0400

> I would like to see a scheme where anything can be configured,
    > including stuff which can be vendor-specific/proprietary so vendors can
    > deploy new functionality quickly without going through a

DHCP is pretty good at this, as is Radius.
Using the DHCP option containers would make sense.

However, the important part of this discussion is to understand what kinds of
configuration parameters need to have fate sharing with the routing
information, and what kinds of things do not care.

I read the rest of the message, and I suggest that you start a new thread.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Jul 2013 09:47:20 -0400

> either that,or things don't work).

That's the point.  We have prefixes for interfaces and we have routes, and
they could, in theory, be configured seperately, but as you have pointed out
repeatedly, it makes no sense to do so, because they need to fate share.

In theory, one could have a route that leads somewhere, but once you get
there, it happens that no hosts are using that prefix, for some reason.

The question is: what other things do we need to configure, which are not
routes?   Do they fate share or not?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Thomas <[email-masked]>
Date: Fri, 05 Jul 2013 13:27:21 -0700

> Using the DHCP option containers would make sense.

Is AAA run to "untrusted" routers (ie, CPE)?

It's probably worth bearing in mind that while home routers may be a convenient place to
run things like DNS and all kinds of other non-router like services, I don't think we want
to make that the only place they are allowed in a homenet architecture. Right?

Mike

---

From: mike <[email-masked]>
Date: Tue, 09 Jul 2013 08:55:13 -0700

On 7/5/13 12:59 AM, Lorenzo Colitti wrote:
>
> Far be it from me to object to people doing more work, but... isn't it premature to attempt to define a generic architecture to configure anything 
> that's possible to congfigure? That seems like it's a lot to bite off, and would take a while. Can we get away with a layered approach, where we 
> first build a network with working routing, and then we figure out how to run services on top of it?
>

Given the breadth of protocols and services, many lacking any network based configuration
at all, and combine that permanent infrastructure mated with the ad hoc roaming on and
off my homenet, I think that the idea there there is going to be a One True Configuration
protocol is... well, pretty dubious.

What I've been wondering is whether we need a meta layer that stimulates other configuration
layers to initiate configuration/etc in their own native tongue. We have many protocols
(eg IXFR, DHCP) but the coordination is either lacking in a littleconf situation (IXFR), or klunky
and trying to go beyond its pay grade in a complicated topology (DHCP).  The first step of
getting things autoconfigured is to decide who arbitrates conflicts and how end devices
react to the various authorities (eg, when I roam onto my neighbor's net).

This strikes me as a very hard problem in general.

Mike

---

From: Dave Taht <[email-masked]>
Date: Tue, 9 Jul 2013 10:30:34 -0700

> This strikes me as a very hard problem in general.

I've been sort of waiting for the list to discover commonly deployed
protocols like upnp and ssdp. Multicasting a little bit...

http://en.wikipedia.org/wiki/Universal_Plug_and_Play

http://tools.ietf.org/html/draft-bnss-v6ops-upnp-01
>
> Mike
>
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Michael Thomas <[email-masked]>
Date: Tue, 09 Jul 2013 11:16:23 -0700

> http://tools.ietf.org/html/draft-bnss-v6ops-upnp-01

I think that one of the things that has profoundly changed since all of these
have been deployed is the challenges of mobility in the sense of roaming.
It's dirt common these days to get on your friend's wireless with phones, but
what does that really mean from a configuration standpoint for the homenet
itself, and for the roamer? They only trust each other to a degree, and probably
mostly on the bits level. But my neighbor's may really want to give me access
to their display and speakers so I can show them a cool video I just shot, or what
have you.

It's yet another problem with pure zeroconf solutions: being able to discover
something isn't enough: there is an implicit authz/enrollment problem to say
whether I *can* use those services. It's just not enough to equate network
admission with authorization these days. I don't see how you get around
that without littleconf.

Mike, in fact just giving out your guestnet password is "littleconf" in and of itself.