Subject: [homegate] Proposed Charter Update - 2010/09/09

From: Ray Bellis <[email-masked]>
Date: Thu, 9 Sep 2010 15:18:22 +0000

Based on (long) discussions with ADs, and feedback from the IP Directorate and various people here, please find below our latest draft.

Most of the changes relate to scope and work items - in particular the ADs wanted to see a concrete list of proposed goals and milestones.  There's also some structural change - mostly moving the text that was below the bullet list higher up the document. 

Ray and Mark

[with thanks also to Ole for his help with the editing]

--8<--8<--

Home Networking (homenet)

Current status: Proposed Working group
Last Updated: 2010-09-09

Chairs:
	TBD1
	TBD2

TBD Area Directors:
	TBD3
	TBD4

Internet Area Advisor:
	TBD3

Mailing List: 
	Address: [email-masked]
	To subscribe: https://www.ietf.org/mailman/listinfo/homenet
	Archive: http://www.ietf.org/mail-archive/web/homenet

Description of working group:
-----------------------------

Home networks are used for communication among networked devices
deployed within a home or home office, and for communication with the
Internet at large. The manner in which a home network is used is
evolving, at times resulting in interoperability and/or performance
problems.

A home network can include a variety of data-link technologies, such as
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, gaming
consoles, audio output speakers, smart electricity meters, light
switches, toys, printers, routers and more. The home network provides
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 because 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. The HOMENET working
group will deliver recommendations related to the use of IETF-specified
technologies such as TCP, IPv6, DNS, and IP routing protocols and will
not overlap with specifications related to system-level or link-layer
technologies developed by other standards bodies.

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

Extensions to IETF technologies will typically occur in the relevant
working groups chartered to maintain those technologies, based on
recommendations and requirements from the HOMENET working group. When
appropriate, the HOMENET working group itself may advance protocol
specifications with close review from any affected working groups in the
IETF.

The initial deliverable for the HOMENET working group is a Home
Networking Architecture document. This document will define terminology,
specific problem statements, and describe how various solution areas fit
together. These areas include, but are not limited to:

* Routed home - automatic prefix assignment and distribution of other
  configuration information in a network with multiple routers, subnets
  and data link types.

* Simple naming for entities 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.

* Effective queuing and forwarding mechanisms to enable efficient
  communication between network segments of different speeds, latencies
  and error rates.

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

Goals and Milestones:
---------------------

Nov 2010 - Initial revision of a Home Network Architecture document
Mar 2011 - Adopt a Home Network Architecture document as a WG item
Mar 2011 - Individual drafts as WG candidates for Routed home requirements
Mar 2011 - Individual drafts as WG candidates for Simple naming requirements
Mar 2011 - Individual drafts as WG candidates for Multi-homing requirements
Mar 2011 - Individual drafts as WG candidates for QoS requirements
Mar 2011 - Individual drafts as WG candidates for Security requirements
Mar 2011 - Individual drafts as WG candidates for DNSSEC requirements
Jul 2011 - Recharter the working group
Dec 2011 - Submission of the Home Network Architecture document to the IESG

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Sep 2010 08:51:33 -0700

>Most of the changes relate to scope and work items - in particular the ADs wanted to see a concrete list of proposed goals and milestones.  There's also some structural change - mostly moving the te…

. . .

>Goals and Milestones:

This list seems wrong on three axes:

- The first two happen at the same time; that is, the -00 draft of the Home Network Architecture document *is* adopted as a WG item. That can be done in Nov 2010.

- It is questionable to start having further drafts until the definitions-and-architecture draft is fairly stable. If it is stable, it should be sent to the IESG. Thus, consider moving the last element up to April 2011 and move all the "Mar 2011" items down to April.

- Having multiple drafts on six different topics floating around all at once will cause us to produce much less useful work. Vendors won't know what to implement to, and purchasers won't know what to specify. We'll most likely cave in and publish two or more competing documents on a single topic because of strongly-held views of a small number of WG members. We'll have to hold some completed documents for a long time while slower referenced documents complete. These are common hallmarks of dysfunctional IETF WGs.

If we have agreed on a single architecture, why not create a single requirements document? That gives vendors a single point of reference for their implementations, it gives purchasers a single RFC to specify, it gives the future chairs a stronger stick with which to beat out rough consensus, and it means that we all finish at the same time.

Given those three issues, a different set of goals and milestones would be:

Nov 2010 - Initial version of WG's Home Network Architecture document
Apr 2011 - Submit Home Network Architecture document to the IESG
Apr 2011 - Initial version of WG's Home Network Requirements document
Apr 2012 - Submit Home Network Requirements document to the IESG
Apr 2012 - Possible recharter of WG

Does this sound reasonable?

--Paul Hoffman, Director
--VPN Consortium

---

From: "David Harrington" <[email-masked]>
Date: Thu, 9 Sep 2010 15:49:20 -0400

Hi,

Let me explain the rationale behind the new milestones.

The previously proposed charter is just way too open-ended. 

<sermon>
There is a real possibility I will be the Responsible AD. Maybe a
different AD would have a different idea on this, and I won't be
offended if you choose to AD-shop, but  my impression is the IESG
won't approve this charter without tighter scope. I've asked the other
INT/TSV ADs for their feedback.

I favor charters that have tight enough scope to help chairs keep ML
discussions focused on deliverables, and away from tangential
discussions that produce nothing. I find this ML has done a great deal
of "well, we need to include this, and this, and this, and what about
that ...?" I have given my sermon about not continuning to expand the
scope, but starting to focus on cutting the scope. I really didn't see
that happen much.

I favor charters that allow me as an AD (and previously as a chair) to
assess whether the chairs are able to get the deliverables delivered
reasonably on-time. If the charter makes no promises about what will
be delivered or when, then obviously it's not very useful for that
purpose. 

I make it a policy not to sign blank checks or contracts with fields
"to be filled in later". Per RFC2418 "IETF Working Group Guidelines
and Procedures", 

   A charter is a contract between a working group and the IETF to
perform
   a set of tasks.

The previously proposed charter was missing the set of tasks.

Jari sent the proposed charter to the INT area directorate for
comments, and the responses were "this is way too open-ended, and I
can't even tell what is supposed to be delivered".

There were lots of people in the last BOF, but I didn't recognize many
of them. I suspect many were from other SDOs (or fora) and won't be
around to do the WORKing group tasks. 

The BOF also failed to demonstrate to me that there was consensus on
the golas and deliverables for this proposed WG. and, for me, it is a
bad sign when a second BOF fails to reach consensus. and just to mak
things worse, this mailing list has chosen to change the focus from
homegate to homenet.

Now let me be very clear. I personally look to the WG to be the
technical experts on this work, the chairs are the first-line
managers, and I'm just a facilitator and second-line manager. I'm not
trying to force my technical views on the WG; I'm trying to make sure
this group has a reasonable project plan to produce something useful.
If you give me a good project plan, and the chairs make you follow it,
you will probably see very little of me until you're ready to submit
documents to the IESG. 
</sermon>

I want to see a tighter project plan. I worked with Ray to get a set
of tasks into the contract.

We discussed a few ways to try to do that, 
1) serialize the work. Have one architecture/framework document as a
deliverable. Ray and I had agreed to this approach in an earlier
proposed charetr. Such a framework document would likely do a gap
analysis. When the gap analysis is completed, then we can look to
recharter with some specific items to work on.

Mark's argument against doing this serialized approach is that each
player has their own special interests, and if their favorite topic
won't be addressed now, then they'll walk away and maybe come back
when their stuff gets addressed. Even if everybody stays, using a
serial approach slows everything down.

Mark, and others, also pointed out that the architecture doc will be
inter-related with individual topics to be addressed. Until we start
poking at the individual topics, we might not agree on scope and how
it fits into the architecrture, so it would be difficult to develop an
architecture without starting to look at the individual topics and
their scope.

2) parallelize the work. Identify all the work items and put each task
into the charter now. The problem is that we don't know what all the
work items are. Part of the work of this WG will be to develop a
better understanding of what a home network is, including better
defining the scope to include/exclude SOHO, IT-managed networks in the
SOHO, various layer 2 technologies, mutiple routers, cascading
routers, etc.

We're not ready yet to identify and prioritize all the tasks that need
to be addressed. So this approach seems highly impractical at this
time.

3) choose one (or more) serial activity to all work on together - the
framework doc, and parallelize individual efforts so everybody gets to
start work on their favorite technology.

The framework doc might be considered a WG draft from the start,
although Lars and I both favor having it first published as an
individual draft, and later adopted as a WG item once we see the
quality and quantity of content. This framework document will require
the WG members to work together to achieve consensus. 

The parallel work of delivering individual drafts lets everybody be
involved in their favorite topic, and gives the WG something "with
meat" to discuss, so we can try to achieve consensus on the directions
for each of the seven bullet topics. These drafts would be the input
to a re-chartering effort. If some of the drafts never get written,
obviously the WG didn't have enough resources, or the topic wasn't
high enough priority, and it won't end up in the recharter. If
multiple individual drafts get written for a topic, then obviously we
have resources and a priority topic, and the WG will have some
consensus-building to do to converge the positions.

As contributors work on specific topics, they will likely raise
question on the ML about scope and specific requirements. Portions of
individual drafts might end up being incorporated into the
framework/architecture draft, and the eveolving arch draft might help
guide the individual drafts. Individual drafts might also end up being
recognized as work appropriate for another existing WG, so it won't
need to be part of the recharter. Or individual drafts might have
portions farmed out to other WGs, and portions incorporated into the
arch/framework draft.

>From my perspective, the third approach seems most appropriate right
now, since we have a bunch of people with "special interests" but we
also need to come together more to achieve consensus on how to deliver
promised deliverables on a timely basis. We can do both at the same
time.

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Thursday, September 09, 2010 11:52 AM
> To: [email-masked]
> Subject: Re: [homegate] Proposed Charter Update - 2010/09/09
> 
> >Most of the changes relate to scope and work items - in 
> particular the ADs wanted to see a concrete list of proposed 
> goals and milestones.  There's also some structural change - 
> mostly moving the text that was below the bullet list higher 
> up the document.
> 
> . . .
> 
> >Goals and Milestones:
> >---------------------
> >
> >Nov 2010 - Initial revision of a Home Network Architecture 
> document Mar 
> >2011 - Adopt a Home Network Architecture document as a WG 
> item Mar 2011 
> >- Individual drafts as WG candidates for Routed home 
> requirements Mar 
> >2011 - Individual drafts as WG candidates for Simple naming 
> >requirements Mar 2011 - Individual drafts as WG candidates for 
> >Multi-homing requirements Mar 2011 - Individual drafts as WG 
> candidates 
> >for QoS requirements Mar 2011 - Individual drafts as WG 
> candidates for 
> >Security requirements Mar 2011 - Individual drafts as WG 
> candidates for 
> >DNSSEC requirements Jul 2011 - Recharter the working group 
> Dec 2011 - 
> >Submission of the Home Network Architecture document to the IESG
> 
> - The first two happen at the same time; that is, the -00 
> draft of the Home Network Architecture document *is* adopted 
> as a WG item. That can be done in Nov 2010.
> 
> - It is questionable to start having further drafts until the 
> definitions-and-architecture draft is fairly stable. If it is 
> stable, it should be sent to the IESG. Thus, consider moving 
> the last element up to April 2011 and move all the "Mar 2011" 
> items down to April.
> 
> - Having multiple drafts on six different topics floating 
> around all at once will cause us to produce much less useful 
> work. Vendors won't know what to implement to, and purchasers 
> won't know what to specify. We'll most likely cave in and 
> publish two or more competing documents on a single topic 
> because of strongly-held views of a small number of WG 
> members. We'll have to hold some completed documents for a 
> long time while slower referenced documents complete. These 
> are common hallmarks of dysfunctional IETF WGs.
> 
> If we have agreed on a single architecture, why not create a 
> single requirements document? That gives vendors a single 
> point of reference for their implementations, it gives 
> purchasers a single RFC to specify, it gives the future 
> chairs a stronger stick with which to beat out rough 
> consensus, and it means that we all finish at the same time.
> 
> Nov 2010 - Initial version of WG's Home Network Architecture 
> document Apr 2011 - Submit Home Network Architecture document 
> to the IESG Apr 2011 - Initial version of WG's Home Network 
> Requirements document Apr 2012 - Submit Home Network 
> Requirements document to the IESG Apr 2012 - Possible recharter of
WG
> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate
>

---

From: "David Harrington" <[email-masked]>
Date: Thu, 9 Sep 2010 16:26:26 -0400

Hi Paul,

I sent another email with my whole spiel, but I'll respond to your
points.

> as a WG item. That can be done in Nov 2010.

If you can get the draft written and achieve consensus by November,
great!
There are no penalties for delivering before a milestone date.

> the last element up to April 2011 and move all the "Mar 2011" 

I explained the rationale for further drafts in my other email.
If somebody wants something included in the WG recharter, first, write
a draft!

The arch document might be delivered earlier than promised.
There are no penalties for delivering before a milestone date.

> won't know what to specify. 

Part of my goal is to see if the WG can achieve enough consensus to
achieve useful work. If not, the WG will be closed.

The multiple draft approach is to have solid input for a recharter
process.
The recharter process should happen in July, so multiple drafts
floating around is a short-lived problem.

I recommend vendors not implement against works-in-progress.
I recommend purchasers not stipluate requirements based on
works-in-progress.

> We'll most likely cave in and 
> members. 

I do not expect to approve multiple competing documents in the
recharter.
The WG needs to achieve consensus.
If that consensus is that there really are different sets of
requirements to meet, there might be justification for multiple
competing drafts.
I'll need to be convinced.

> We'll have to hold some completed documents for a 
> long time while slower referenced documents complete. 

Well, that might be true unless you are very careful about how you
handle normative references.
There already is a proposal to reduce the burden of downrefs.

> These 

The single biggest hallmark of a dysfunctional WG in my experience, is
the inability to achieve consensus. So far, I have not been impressed
by the ability of this group to achieve consensus, which is why I am
involved at all in helping to craft a clearly-scoped charter. 

Traditionally, I have not worked much at helping people with barBOFs
or documents craft their proposals. Some of my coworkers with
less-than-examplary-English or less-than-perfect-expertise wish I
would. Typically I give strategic and tactical advice and then see if
they can execute effectively on the strategy and tactics. That's part
of my test of whether a group is ready to have a WG, or a contributor
is ready to submit a technical proposal.

I think this is an important WG effort, which is why I am helping
craft a charter.
I am unimpressed by the ability to converge on a consensus so far. 

> consensus, and it means that we all finish at the same time.

Well, I question whether this group has agreed on a single
architecture.
I suspect there are lots of unspoken assumptions in people's minds
about what will go into the architecture, and what requirements will
be included in a WG requirements document.

Having multiple drafts floating around will help get some of the
unspoken assumptions from strong-willed individuals into writing, so
we discuss them, shoot down some of the strong-willed assumptions,
work toward consensus on the set of assumptions, and ultimately get WG
consensus documented in RFCs.

WG

---

From: Mark Townsley <[email-masked]>
Date: Fri, 10 Sep 2010 01:23:35 +0200

> I recommend vendors not implement against works-in-progress.

Working, independent, implementation against "works-in-progress" is the
best indicator we have for relevance, accuracy, and consensus.

Rough consensus *and* running code.

- Mark

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Sep 2010 17:12:34 -0700

>Goals and Milestones:

Given what you said, I do not understand the first two and last line.

- Why would the WG not adopt the early version of the Home Network Architecture document?

- Why would the IESG want the WG to recharter when the WG still hasn't agreed on the contents of the Home Network Architecture document?

--Paul Hoffman, Director
--VPN Consortium

---

From: "David Harrington" <[email-masked]>
Date: Thu, 9 Sep 2010 22:56:47 -0400

Hi,

Initial can be individual, adopted later.
Arch doc can morph while the WG decides on scope and priorities, and
finish after recharter.
I don't see a problem.

Maybe we have different assumptions about the contents of the arch
doc.
Home networks take many forms, so I don't see one stable architecture.
If the WG reaches consensus on home network arch contents and finishes
earlier than I anticipate, that's fine.

Ray raised a point - is the arch doc about home network design, or is
it a framework that describes how various technologies (the seven
bullets) fit together?

dbh

> From: Paul Hoffman [mailto:[email-masked]] 
> Sent: Thursday, September 09, 2010 8:13 PM
> To: David Harrington
> Cc: [email-masked]
> OK, that all makes sense. I did not understand that the 
> purpose of the many drafts on many topics was to help the 
> rechartering effort. However, we still have some issues. The 
> current proposal is:
> 
> >Goals and Milestones:
> >---------------------
> >
> - Why would the IESG want the WG to recharter when the WG 
> still hasn't agreed on the contents of the Home Network 
> Architecture document?
> 
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Jari Arkko <[email-masked]>
Date: Fri, 10 Sep 2010 13:30:56 +0300

For what it is worth, I do share many of the same concerns David has. 
After showing the charter to a number of experts, all came back with 
question marks on what the group actually intends to work on. Here are 

>   configuration information in a network with multiple routers, subnets

Does this include the development of new routing protocols, DHCP PD 
extensions, operational advice on how to use existing mechanisms, or 
standardized templates for structuring the site's address space? Are we 
talking about 1-5 routers, or aiming for a more general purpose 
automatic prefix assignment mechanism?

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

Does this mean pointing to DNS or possibly to DNS and mDNS as the 
solutions and just providing operational advice on how to run these 
types of networks and what the default configs should be? Or are you 
also planning to extend some of the naming mechanisms to go beyond one 
subnet?

Why are local and global naming bundled here? I presume we have dyndns 
and other solutions for the global naming problem already, and that 
problem space seems different from the local routed network problem.

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

This seems like an undesirable overlap with the MIF working group.

>   communication between network segments of different speeds, latencies

I'm not sure what this is, beyond recommending the proper queuing 
algorithms. I certainly hope developing some new forwarding semantics is 
not in scope. But is ECN, BEHAVE NAT specifications etc in scope? And 
again, is the group making a profile of existing specifications or 
collecting them together, or developing some new (e.g., a new queuing 
algorithm).

I am not sure slicing and dicing the deliverables at this stage is the 
right answer to making the group's focus clearer. I for one would like 
to get some answers to the fundamental questions about which of these 
questions are in scope. I wouldn't mind if the eventual document was 
still just one deliverable.

Jari

---

From: Mark Townsley <[email-masked]>
Date: Fri, 10 Sep 2010 14:53:52 +0200

> automatic prefix assignment mechanism?

My thoughts are that this is more than operational advice (remember, the
technical skills of our target "operator" doesn't know what the IETF is,
much less how to read one of our RFCs).

This could be a routing protocol, it also could be extensions to DHCP;
that's not clear yet, but that's also solution space so doesn't need to
be decided here and now.

As for number of routers, If you forced a number on me it would in the
single-digit range, but this is something we'd specify in the
architecture document.

> also planning to extend some of the naming mechanisms to go beyond one

This certainly could be mDNS, but again that's solution space. Within
the home, traversing one subnet by routing multicast is an option, but
so would be proxying.

I think that for IPv6, the minimum thing here would be for devices to be
identified simply by something other than their address (e.g., a
replacement to what we almost always do today in IPv4:
http://192.168.1.1). The maximum is full-on cross-subnet and wide-area
service discovery. Success for the IETF due to history here might only
be the former, but I'd still like to think we could tackle the latter.

> problem space seems different from the local routed network problem.

Bundled because if DNS is used for both, you hit a split DNS issue that
must be carefully addressed.

> This seems like an undesirable overlap with the MIF working group.

Is MIF scoped to just the home network?

> algorithms. 

Yes, I think so. This was one of the primary problems cited early on in
homegate, before I started paying attention so much, so perhaps someone
else should chime in.

> I certainly hope developing some new forwarding semantics is
> not in scope. 

I don't think so.

> But is ECN, BEHAVE NAT specifications etc in scope? And

I think Lars asked for explicit scoping-in of ECN. I think NAT should
only be included by reference to behave.

> still just one deliverable.

I agree that less is more, one document would be fabulous. But, we can't
do that by ignoring part of the problem space or requirements. Either
all the homenet protocols work to deliver a real solution, or they
don't. It only takes one bad actor to take the whole system down in this
case (and by "down" I mean one protocol that blows the operator's mind
by asking him or her to perform arcane configuration tasks).

- Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 10 Sep 2010 09:33:24 -0400

> must be carefully addressed.

Let me put on my dnsext hat for a moment and agree with Mark.  Llmnr
and mDNS are treated up in the clients as though they're just part of
the unified DNS name space.  But they're not part of that name space.
Moreover, stuff leaks from local networks to the global DNS all the
time.  If it didn't, we wouldn't need the AS112 project and drafts
like draft-ietf-dnsop-default-local-zones (even though that latter
isn't explicitly named at the home network).  Even DNS experts can't
navigate the huge number of DNS-related RFCs.  So developing a codex
for home network device implementers would be very helpful: "Here's
the stuff you need to know, and here's where it's written down." 

A

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Sep 2010 08:06:25 -0700

>earlier than I anticipate, that's fine.

OK, that all makes sense. It's not what we typically see IESG members asking for, but if you're willing to defend this charter to the IESG, that's good enough for me.

>it a framework that describes how various technologies (the seven

It should be both. We can then see if we believe that things actually "fit together".

--Paul Hoffman, Director
--VPN Consortium