Given the "complexity" of a potential home net, a complexity that is often alluded to on the mail list (including below), there will no doubt be "policy" that has to be introduced - a policy language or facility that can be described or communicated by an end user, preferably without technical jargon. This policy language, or "facility" could also offer options for how the user(s) of the home net would want to be notified in the event of any exceptions.
Randy On Nov 13, 2012, at 9:22 AM, Mark Townsley <m...@townsley.net> wrote: > > On Nov 13, 2012, at 5:27 PM, Dave Taht wrote: > >> On Tue, Nov 13, 2012 at 5:01 PM, Michael Thomas <m...@mtcc.com> wrote: >>> On 11/13/2012 12:24 AM, Brian E Carpenter wrote: >>>> >>>> On 12/11/2012 17:33, Mark Townsley wrote: >>>>> >>>>> Nice to see a constructive thread with suggested text for the editors of >>>>> the homenet arch, thank you. >>>>> >>>>> I'm concerned with any "issue a warning" type suggestions though. We are >>>>> working hard to develop automatic configuration that assumes there is no >>>>> operator involved here. If there is no operator to configure our >>>>> protocols, >>>>> there is no operator to issue a warning to either. >>>>> >>>>> If the homenet runs out of /64s to hand out, and we recommend not to >>>>> route /128s, bridge, NPTv6, etc... then the final option is, simply, "no >>>>> IPv6" for that given link. Falling back to the user to try and interpret a >>>>> cryptic message about IPv6 prefixes is simply not a realistic option for >>>>> the >>>>> protocols we are working on here. >>>> >>>> Which is a FAIL if there are any v6-only devices around. Ultimately I >>>> don't see >>>> how you can avoid some kind of warning to the user, even if it's the >>>> equivalent >>>> of the beeping from a smoke detector whose battery is fading. >>>> >>> >>> I too am bothered quite a lot by the notion that nothing will ever go wrong >>> therefore we don't have to plan for it. With the complexity of networks >>> being >>> contemplated here, I think the likelihood that they will self-organize and >>> just >>> "work" completely unattended in all/most cases asymptotically approaches >>> zero. >>> We simply have no empirical evidence that any such thing has ever been done, >>> and plenty of evidence that even given huge amounts of networking clue that >>> awful things happen awfully often. >>> >>> What really bothers me is that routers are treated as "others": the notion >>> that >>> normal people are not just expected to have no clue about networking, but >>> that they should be actively prevented from gaining clue by interacting with >>> their infrastructure. I really think that's wrongheaded. While I think that >>> a >>> beeping box is a horrible idea, I wouldn't be adverse to my box, say, >>> sending >>> me email alerting me to what is wrong, and how I might fix it. There are >>> probably >>> many other ways to deal with this too, and the problem isn't limited to >>> routers >>> but all headless boxen -- though routers may have some unique properties. >> >> +1 >> >> One of the innovations in cerowrt is that it includes a mini-jabber >> server, to which a given user could subscribe, for critical messages. > > My mother doesn't know how to subscribe to jabber. You might reach her by > having the router be her friend and sending a status update via facebook > though. > > I'm not against next-gen management interfaces, or sending messages or giving > config knobs to users that understand what they mean. I think some of the new > products that let you manage your home router from your iphone or android > device are fantastic for the average user. When a guest came to my house > recently, I pushed a few buttons on my iPhone which sent him a text message > with all he needed to connect to the guest SSID. I could have let him take a > picture of a QR code on my iPhone as well. Or tapped his NFC compliant device > with a little card that came with the router. Or pressed two buttons. There > are all sorts of ways to configure a router these days. All good. > > But remember we're just one layer here. If each and every thing a router did > thought it was so self-important that it could communicate with the user > whenever it liked, imagine how much SPAM that might produce. Do you remember > some of the cryptic dialog boxes you used to get from PC software 10 years > ago? True story: I once got flooded with emails from random America Online > users all over the world because the company that wrote the AOL networking > stack that came on the AOL CD-ROMs threw up a dialog box with L2TP in the > message. At the time, when you typed L2TP into the AOL search engine, you got > the RFC and my email address. People sent me email asking why their AOL > wasn't working. > > Each and every part of the router must do everything it can to work without > bugging the user. it's enough work to bother them for the *really* important > stuff like "do I let this device on the network?", "do I allow connectivity > with my neighbor", etc. > > - Mark > >> >>> Mike >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >> >> >> >> -- >> Dave Täht >> >> Fixing bufferbloat with cerowrt: >> http://www.teklibre.com/cerowrt/subscribe.html > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
