Subject: [homegate] A new proposed charter (and name) for HOMEGATE

From: Ray Bellis <[email-masked]>
Date: Tue, 7 Sep 2010 17:04:56 +0000

Mark Townsley and I, with lots of help from Ole Troan and input from various ADs and from Jason, have authored a new potential charter for this group.

We've taken a bit of a different direction from the previously proposed charter, but we think it is one which is more within the scope of what we believe the IETF can deliver, and takes into account most of the comments and feedback to date.

To avoid conflicting with the Home Gateway Initiative, and to better reflect the proposed scope of the group, the new name is the Home Networking (HOMENET) Working Group.

We believe that if the group agrees to this charter in general, we can start the process for WG formation.  That means we at least need to tell the ADs that we are OK asking them to circulate the text among the IESG and IAB by this Thursday, Sept 9th.

So, please send comments ASAP - positive or negative - so we can get a feel for whether this is the right way to go.

We'd also like to thank Jason Livingood for getting us this far.

--8<--8<--
Home networks are used for communication among networked devices
deployed within a home, and for communication with the Internet at
large. The manner in which a home network is used is evolving rapidly,
at times resulting in interoperability and/or performance problems on
the home network. In some cases, those working to solve these problems
have suggested the need for clarification of existing protocol
functionality or definition of new protocol functionality.

A home network can include a variety of data-link technologies, be it
Ethernet, 802.11, 802.15.4 or power line communication. Connected
devices may be as diverse as personal computers, televisions, digital
video recorders, telephones, computing tablets, digital cameras,
IP-enabled light switches, gaming consoles, audio output speakers, smart
electricity meters, toys, printers, routers and more. The home network
provides important local connectivity, Internet connectivity through one
or more Internet Service Providers, and connectivity to closed networks,
such as corporate VPNs and walled garden services.

Home networks offer unique challenges not only because of the wide range
of devices, applications, and user types, but also in that they are
typically not actively managed.

The broad purpose of the home networking (HOMENET) working group is to
describe the home network IP architecture and to work on clarifications
and improvements to IETF protocols to allow the home network to better
meet present and anticipated future requirements. Under this scope, the
current work items of the working group are related to addressing the
following requirements:

- Support for IPv4 and IPv6 with zero configuration, for IP prefix
 assignments and other fundamental aspects that are critical for
 network operation.

- Simple naming for devices in the home network, so they can be accessed
 from within the home network as well as from elsewhere on the
 Internet.

- Support for connections to multiple Internet service providers or
 closed networks (VPNs, walled gardens) at the same time

- IP routing across subnets and network segments with different Layer 2
 media (e.g., between Ethernet and 802.15.4).

- Effective queuing and forwarding mechanisms to enable efficient
 communication between network segments of different speeds.

- Reasonable default network layer security in accordance with known
 and/or expected threats, while not hindering the deployment of new
 applications or transport layer protocols.

- Support for DNSSEC validation within the home network.

The working group will work together with other standards development
organizations that define requirements on home networking devices
(including groups such as the Home Gateway Initiative, Broadband Forum,
CableLabs, UPnP, DLNA, etc.).

The HOMENET working group focuses on recommendations related to the use
of IETF-specified technologies such as DNS, DNSSEC, NATs, or IPv6, and
will not overlap with specifications related to system-level or
link-layer technologies developed by other standards bodies.

Extensions to IETF technologies will typically occur in the relevant
working groups chartered to maintain those technologies, based on
requirements from the HOMENET working group.

--8<--8<--

Ray and Mark

---

From: "Marco Davids (SIDN)" <[email-masked]>
Date: Wed, 8 Sep 2010 08:54:06 +0200

> please send comments ASAP - positive or negative - so we can get a feel for whether this is the right way to go.
> 

> deployed within a home

Ray et al,

While reading your mail, SoHo came to my mind.

http://en.wikipedia.org/wiki/Small_office/home_office

I guess some of the topics and issues as mentioned in the charter also
apply to a small office, not just to a home network, right?

Where 'small offices' in your mind, when you wrote the charter?

Regards,

--
Marco

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Sep 2010 07:01:03 -0700

>Where 'small offices' in your mind, when you wrote the charter?

That hit me too when reading the proposed charter (which I support, FWIW), but I don't think it is inherent to the charter. That is, if a "small office network" has exactly the same properties as a "home network", it isn't necessary to change the charter to encompass it. If the two types of networks are actually different, we can have that discussion, but I couldn't see where they might differ in a way that would change the work of the prospective WG.

--Paul Hoffman, Director
--VPN Consortium

---

From: Mark Townsley <[email-masked]>
Date: Wed, 08 Sep 2010 19:37:50 +0200

> Where 'small offices' in your mind, when you wrote the charter?

I think by "home" we are really just trying to cast a certain management
model (e.g. "not actively managed), size (relatively small), and variety
of devices (more than just what a working adult uses for his/her job).

If some small offices happen to fit into this model, there is nothing
stopping them from being run as "homenets" - but I don't think we want
to go out of our way to enter the territory of branch offices, SLAs,
separate "IT dept" administrators, etc.

- Mark

> 
> Regards,
> 
> --
> Marco
> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate
>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Sep 2010 15:44:43 -0400

> So, please send comments ASAP - positive or negative - so we can get a feel for whether this is the right way to go.

I can support that charter, and within my scope of competence can
commit to doing work on WG tasks.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Kirksey, Heather R (Heather)" <[email-masked]>
Date: Wed, 8 Sep 2010 15:22:43 -0500

Ray and Mark,

I like this updated charter and think it sounds like a good way forward.  I also think it's less likely to incur overlap with other groups, while focusing on some areas where IETF can provide good value to the community.  

My only feedback/concern is that it's a rather long list of items you have on there to address -- I think that the working group leadership would need to be very focused to ensure that the work doesn't drag on too long.  

Thanks,
Heather

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ray Bellis
Sent: Tuesday, September 07, 2010 12:05 PM
To: [email-masked]
Subject: [homegate] A new proposed charter (and name) for HOMEGATE

--8<--8<--

--8<--8<--

Ray and Mark

---

From: "Marco Davids (SIDN)" <[email-masked]>
Date: Thu, 9 Sep 2010 09:23:20 +0200

> of devices (more than just what a working adult uses for his/her job).

Excellent defenition, would fit in the charter quite well :-)

--
Marco

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Thu, 9 Sep 2010 04:07:57 -0700

> of devices (more than just what a working adult uses for his/her job).

A network is not just management model.  Entertainment source/sinks (and possibly
sensor sources) are significantly greater in a home environment.

> separate "IT dept" administrators, etc.

Agreed. Perhaps those actually should be stated as non-goals.

regards, kiwin

-- 
Stephen [kiwin] Palm   Ph.D.                          E:  [email-masked]
Senior Technical Director                             T: +1-949-926-PALM
Broadcom Broadband Communications Group               F: +1-949-926-7256
Irvine, California                               W: http://www.kiwin.com
Secondary email accounts:  [email-masked]  [email-masked]
[email-masked]  [email-masked]  [email-masked]  [email-masked]

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Thu, 9 Sep 2010 04:11:15 -0700

> That hit me too when reading the proposed charter (which I support, FWIW), but I don't think it is inherent to the charter. That is, if a "small office network" has exactly the same properties as a…

We should clearly state that only small offices that have very similar characteristics
as home networks will be implicitly addressed. ie, there cannot be scope creep.

regards, kiwin

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Thu, 9 Sep 2010 04:41:50 -0700

> Mark Townsley and I, with lots of help from Ole Troan and input from various ADs and from Jason, have authored a new potential charter for this group.

Overall the proposed charter looks much better than before.
Some clarifications suggested below.

> Ethernet, 802.11, 802.15.4 or power line communication.

Please add "MoCA" (over coax) to the list.

> Connected
> electricity meters, toys, printers, routers and more.

Seems we should add "bridges" to that list. 8-)
The devices are listed in plural form, perhaps as a grammar artifact,
or do we explicitly want to address multiple routerS?

> The home network provides important local connectivity,

Seems we should delete "important" unless we clarify what was implied.
Was it an implicit reference to QoS?

> Internet connectivity through one

Perhaps we should scope that to "personal usage of corporate VPNs"
so we dont stray to far into small/medium office.

> - Support for IPv4 and IPv6 with zero configuration,

Please add "simultaneously both" before IPv4 to make the simultaneous requirement explicit.

>   from within the home network as well as from elsewhere on the

The later "internet" naming requirement seems to imply a
larger domain effort that probably should be outside the scope of homenet?

>   closed networks (VPNs, walled gardens) at the same time

I suppose there will be a lot of future discussion on whether the burden
to achieve that should fall on the router or the clients.

>   communication between network segments of different speeds.

append: ", latencies and error rates".

> - Support for DNSSEC validation within the home network.

It seems odd to call out one specific protocol in this bullet list.
Generalize or remove.

> CableLabs, UPnP, DLNA, etc.).

some folks have a very limited definition of SDOs, so please add "and fora"
after "organizations". (The examples imply fora, but let's make it explicit)

regards, kiwin

---

From: Mark Townsley <[email-masked]>
Date: Thu, 09 Sep 2010 14:15:17 +0200

> sensor sources) are significantly greater in a home environment.

Above, I mention 3 aspects, (1) management, (2) size, (3) variety of
devices. Entertainment+sensors would be part of #3.

> Agreed. Perhaps those actually should be stated as non-goals.

If not in the charter, certainly within the "architecture/framework"
document that the group would produce.

- Mark

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Thu, 9 Sep 2010 09:42:26 -0400

> Please add "MoCA" (over coax) to the list.

<sigh> Unless you want to add everyone's favorite physical layer
technology, you may want to "genericize" all but the 2 most prevalent
(Ethernet and 802.11). For example: "... Ethernet, 802.11, over coax,
over power line, over phone line, or other wireless communication
technologies."

Barbara

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Sep 2010 10:08:24 -0400

> as home networks will be implicitly addressed. ie, there cannot be scope creep.

I don't find that argument compelling.  Implicit in the scope outlined
by a charter is the assumption that expanding the scope requires
rechartering.  Otherwise, every charter would have to list the
(numerically unlimited) things that they won't address.  I know that
some people feel that chartering discussions currently take an
infinitely long time, but this would be a way to ensure that :)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Sep 2010 10:10:13 -0400

> over power line, over phone line, or other wireless communication

How about just changing "be it" to "such as"?  Then the physical layer
isn't actually constrained but the text is understandable to those not
familiar with every possible permutation.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 9 Sep 2010 16:12:25 +0200

I think it's important to mention 802.15.4 explicitly, as that technology is a specific motivator for the use of routing rather than bridging in the home/premises/office network...

- Ralph

---

From: Mark Townsley <[email-masked]>
Date: Thu, 09 Sep 2010 16:28:32 +0200

> familiar with every possible permutation.

done.

---

From: Mark Townsley <[email-masked]>
Date: Thu, 09 Sep 2010 16:35:28 +0200

On 9/9/10 1:41 PM, Stephen [kiwin] PALM wrote:
>> Mark Townsley and I, with lots of help from Ole Troan and input from
>> various ADs and from Jason, have authored a new potential charter for
>> this group.
> 

Latest version (which is coming to the list shortly, we've been
incorporating comments from lots of angles) has "such as" here anyway.
I'd rather avoid making the list longer than it already is.

> Seems we should add "bridges" to that list. 8-)

Well, hopefully a bridge is transparent to L3 and above. Can we just say
this is part of "and more" ?

> or do we explicitly want to address multiple routerS?

Yes, we want to address multiple routers. That will be more clear in the
bullet list later in the charter.

> Seems we should delete "important" unless we clarify what was implied.

OK.

> Was it an implicit reference to QoS?

No, that was not the intent. Just that local connectivity, even without
internet connectivity, is important. But I am ok taking out the word as
it is apparently confusing.

> so we dont stray to far into small/medium office.

How about we scope this to "IP connectivity of..."

I agree that a corporate VPN is where we start venturing into soho
territory. Based on a comment from Lars, we've amended the first
sentence to include "home office" ... but not "small office". This is a
difficult designation, and perhaps we need to include some text from our
earlier exchange to be clear, though I am very sensitive to Andrew's
comment that we cannot list all negative cases, and we don't want to end
up writing the architecture document in the charter.

> Please add "simultaneously both" before IPv4 to make the simultaneous

I think that in general, any work we do on IPv4 that also works for IPv6
is find and good. But, we very well end up developing solutions that
work with IPv6 that do not work with IPv4.

> larger domain effort that probably should be outside the scope of homenet?

The problem is that we believe we cannot develop a solution that handles
naming internally without at least considering the external world at the
same time (in particular for any solutions involving DNS). Also, I think
that remote access into the home is something that is of high importance
to at least "future" network requirements.

> append: ", latencies and error rates".

OK.

> It seems odd to call out one specific protocol in this bullet list.

The cost of doing business with the IETF these days is IPv6 and DNSSEC.

> after "organizations". (The examples imply fora, but let's make it

Done.

- Mark

---

From: Mark Baugher <[email-masked]>
Date: Thu, 9 Sep 2010 07:41:47 -0700

Ralph, I don't see why 802.15.4 is a specific motivator for developing home routing. Would you explain that?

Mark

---

From: Ralph Droms <[email-masked]>
Date: Thu, 9 Sep 2010 17:55:33 +0200

802.15.4 is not bridgeable to other common home network technologies, so a router will be required to connect an 802.15.4 subnet into a home/premises/office network.

- Ralph

---

From: Mark Townsley <[email-masked]>
Date: Thu, 09 Sep 2010 18:28:25 +0200

On 9/9/10 4:44 PM, Stephen [kiwin] PALM wrote:
> 
> 
> On 9/9/2010 7:35 AM, Mark Townsley wrote:
> 
> There are more MoCA deployments than powerline... so the list
> should actually reflect reality.

I think the idea was simply to show diversity, not a popularity contest
by any means. If you think we need MoCA, it's fine with me. Side
questin: Are there any aspects of it that make it difficult to bridge to
other media types (similar to the zigbee requirement that Ralph is
pointing to)?

> Not if the L2 characteristics are different.

But, is there anything specific that homegate would need to do be sure
IP operates through a bridge? Perhaps you are you thinking of QoS here?

> home office is OK.
> We cannot ignore the legacy devices in homes

Absolutely IPv6 and IPv4 will have to coexist.

But we can't impose the legacy on IPv6 either. e.g., just because IPv4
in the home looks a like what is described in RFC 5684 today, I don't
think we want to carry that over in the design for IPv6.

While solving something for IPv6 we might very well end up designing
something that would work with IPv4 as well. But, I wouldn't want to
pretend we have to deal with NAPT everywhere in IPv6 just because IPv4
does. This *might* also mean that something is solvable in IPv6 that is
not (realistically) in IPv4.

- Mark

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Thu, 9 Sep 2010 09:55:26 -0700

> other media types (similar to the zigbee requirement that Ralph is

Fortunately there are no difficulties with MoCA.
MoCA-Ethernet bridges, for example, have been around for years.

> IP operates through a bridge? Perhaps you are you thinking of QoS here?

Yes and other issues caused by differences in throughput, latency
and error-rate.  Flow control comes to mind.

regards, kiwin

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Thu, 9 Sep 2010 13:28:56 -0400

> 802.15.4 is not bridgeable to other common home network technologies,
> so a router will be required to connect an 802.15.4 subnet into a
> home/premises/office network.
> 
> - Ralph

Please forgive my ignorance -- but I thought 802.15.4 was a PHY + MAC
definition, and that it had absolutely no L3 in that standard. ZigBee is
a specific technology that uses 802.15.4 PHY + MAC and defines L3 to run
over it. BTW, ZigBee is not the only group to define L3 over 802.15.4.
They're just the most successful/well-known, to date.

As such, I'm completely confused why 802.15.4 is relevant -- of course
it isn't bridgeable (at an IP layer -- I assume you aren't referring to
IETF tackling bridgeability at L2), it's just PHY and MAC! But, if
you're saying that ZigBee isn't bridgeable, then your statement makes
sense. But if that's what you mean, then you should say so. And if there
are other technologies over 802.15.4 that you want to create solutions
for, then those should be called out, too, because they may have
different needs than what ZigBee has.

IMO, a router that connects to a ZigBee subnet is more of a "gateway"
device. That is, if it takes something special (at L3 and above) to go
between a "standard" home network, and a ZigBee network, then it's a
gateway. [BTW, ZigBee Alliance has been working on such gateway
definition, according to their website.] And ZigBee needs to be
primarily responsible for figuring out how this works. IETF homenet
would be well within its charter to advise ZigBee to help figure this
out. But that falls clearly within the "work with other orgs/fora" part
of the charter, and I don't see why it needs to be noted as a specific
PHY.

Will this group also be defining a gateway function for Z-Wave? Or is
there a decision that this group will support ZigBee and not Z-Wave? Or
do we really want to go there? [I know I don't.]
Barbara

---

From: Ole Troan <[email-masked]>
Date: Thu, 9 Sep 2010 20:23:28 +0200

Barbara,

> different needs than what ZigBee has.

there are / will be home networks with data link layers which cannot be bridged together. so we need to connect these links at layer 3.
that text is there to give one reason to consider a "routed home", and from that perspective 802.15.4 is just one example.
others could have been Frame Relay, ATM, Cisco HDLC, FDDI, PPP, LocalTalk, Token ring..., but you can judge the relevance of those yourself. ;-)

cheers,
Ole

---

From: Mark Baugher <[email-masked]>
Date: Thu, 9 Sep 2010 12:24:45 -0700

I think this might be a topic for home routing requirements.  I know there are 802.15.4 gateway products that connect to bridged home networks today.  This design may be broken.  Either way, I think it's worth considering as part of the requirements work. 

Mark