Subject: Re: [fun] Revised homenet charter for IESG consideration

From: "David Harrington" <[email-masked]>
Date: Mon, 27 Jun 2011 13:52:21 -0400

Hi,

I think work on home networking standards is very important, and
strongly support the effort.
A little guidance on how I think this charter can be improved.

>From the 110623 version, 
"Specific protocol work described below is anticipated to be within 
the scope of the working group. However,
the group is required to review its charter and milestones with the
IESG and IETF community before submitting documents that make protocol
changes."

"anticipated to be within the scope" is very unclear as to what is or
is not in scope.
Is that "anticipated to be within the scope" AFTER a re-charter, and
thus is NOT NOW is scope of this charter?
or is that "anticipated to be within the scope", so WG members can
interpret it as being in scope NOW?

My concern, and the concern of others, was that the original charter
was too open-ended and did not provide for IETF review of the
architecture and the potential changes it might drive before the WG
was chartered to make such changes. This left  potentially important,
and possibly bad, changes in protocols to be caught in IETF Last Call
or IESG Evaluation, rather than in a review of the proposed protocol
work during the chartering process.

The charter text makes it obvious that the engineering changes are not
yet clearly understood: 
"The architecture document should drive what protocols changes, if
any, are necessary."
"existing protocols are likely sufficient, and at worst may need some
small enhancements, ..."
"it is expected that existing routing protocols can be used as is,
however, a new mechanism may be needed ..."
"The main goal of this [security] work is to enable a security policy
that adapts to IPv6 threats as they emerge,..."

This sounds more like the description of an IRTF RG than an IETF WG.
The ***engineering*** apparently is not yet clearly understood, and
the "specific protocol work described below" is not at all specific.

If the engineering is not yet understood, then I think research needs
to be done, and a resulting architecture document needs to be clear
about what specific engineering work is needed, and a subsequent
re-charter should be clear about the ***engineering*** work to be
done.

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 Jari Arkko
> Sent: Thursday, June 23, 2011 7:05 AM
> To: IAB; IESG; [email-masked]
> Subject: Revised homenet charter for IESG consideration
> 
> Secretary (Bcced),
> 
> Please start an internal review and place this charter for 
> consideration 
> for external review in today's IESG telechat. (We will not approve
it 
> for external review today, it will take at least until next 
> week. But I 
> would like to discuss it anyway.)
> 
> All,
> 
> This charter has been revised per discussion from the BOF call last 
> week. The biggest change is that the group is required to produce an

> architecture document and then come back to the IESG/community to
ask 
> for revising/confirming the rest of its charter. My plan is to
create 
> the working group before Quebec City. Should that fail, the 
> backup plan 
> is to run a BOF. But I personally believe this is something 
> we could and 
> should charter now. I understand the concerns people raised 
> in the BOF 
> call and I'm hoping that this version has made some 
> significant progress 
> in resolving those concerns.
> 
> Jari
> 
> -----
> 
> Home Networks (homenet)
> -----------------------------------
> 
> Current Status: Proposed
> Last Edit: Friday, June 23rd, 2011
> 
> Chairs:
> TBD
> 
> Internet Area Directors:
> Ralph Droms <[email-masked]>
> Jari Arkko <[email-masked]>
> 
> Internet Area Advisor:
> Jari Arkko <[email-masked]>
> 
> Routing Area Technical Advisor:
> TBD
> 
> Security Area Technical Advisor:
> TBD
> 
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: https://www.ietf.org/mailman/listinfo/fun
> Archive: http://www.ietf.org/mail-archive/web/fun
> 
> Description of Working Group:
> 
> This working group focuses on the evolving networking technology
> within and among relatively small "residential home" networks. For
> example, an obvious trend in home networking is the proliferation of
> networking technology in an increasingly broad range and number of
> devices. This evolution in scale and diversity sets some
requirements
> on IETF protocols. Some of the relevant trends include:
> 
> o Multiple segments: While less complex L3-toplogies involving as
few
> subnets as possible are preferred in home networks for a variety of
> reasons including simpler management and service discovery,
> incorporation of dedicated segments remain necessary for some
> cases. For instance, a common feature in modern home routers in the
> ability to support both guest and private network segments. Also,
link
> layer networking technology is poised to become more heterogeneous,
as
> networks begin to employ both traditional Ethernet technology and
link
> layers designed for low-powered sensor networks. Finally, similar
> needs for segmentation may occur in other cases, such as separating
> building control or corporate extensions from the Internet access
> network. Different segments may be associated with subnets that have
> different routing and security policies.
> 
> o Service providers are deploying IPv6, and support for IPv6 is
> increasingly available in home gateway devices. While IPv6 resembles
> IPv4 in many ways, it changes address allocation principles and
allows
> direct IP addressability and routing to devices in the home from the
> Internet. This is a promising area in IPv6 that has proved
challenging
> in IPv4 with the proliferation of NAT.
> 
> o End-to-end communication is both an opportunity and a concern as
it
> enables new applications but also exposes nodes in the internal
> networks to receipt of unwanted traffic from the Internet. Firewalls
> that restrict incoming connections may be used to prevent exposure,
> however, this reduces the efficacy of end-to-end connectivity that
> IPv6 has the potential to restore.
> 
> Home networks need to provide the tools to handle these situations
in
> a manner accessible to all users of home networks. Manual
> configuration is rarely, if at all, possible. The purpose of this
> working group is to focus on this evolution, in particular as it
> addresses the introduction of IPv6, by developing an architecture
> addressing this full scope of requirements:
> 
> o prefix configuration for routers
> o managing routing
> o name resolution
> o service discovery
> o network security
> 
> The task of the group is to produce an architecture document 
> that outlines
> how to construct home networks involving multiple routers and
> subnets. This document is expected to apply the IPv6 addressing
> architecture, prefix delegation, global and ULA addresses, source
> address selection rules and other existing components of the IPv6
> architecture. The architecture document should drive what protocols
> changes, if any, are necessary. Specific protocol work described
below
> is anticipated to be within the scope of the working group. However,
> the group is required to review its charter and milestones with the
> IESG and IETF community before submitting documents that make
protocol
> changes.
> 
> The group will apply existing protocols to handle the five
> requirements above. For prefix configuration, existing protocols are
> likely sufficient, and at worst may need some small enhancements,
such
> as new options. For automatic routing, it is expected that existing
> routing protocols can be used as is, however, a new mechanism may be
> needed in order to turn a selected protocol on by default. For name
> resolution and service discovery, extensions to existing
> multicast-based name resolution protocols are needed to enable them
to
> work across subnets.
> 
> For network security, the group shall document the concept of
> "advanced security" as a further development of "simple security"
from
> RFC 6092. The main goal of this work is to enable a security policy
> that adapts to IPv6 threats as they emerge, taking into account not
> only traffic from the Internet at large, but within and leaving the
> home network itself.
> 
> It is expected that the working group will define a set of protocol
> specifications to accomplish the five requirements from
> above. However, it is not in the scope of the working group to
define
> entirely new routing protocols or address allocation protocols. As
> noted, additional options or other small extensions may be necessary
> to use the existing protocols in these new configuration tasks. The
> working group shall also not make any changes to IPv6 protocols or
> addressing architecture. Prefix configuration, routing, and security
> related work shall not cause any changes that are not backwards
> compatible to existing IPv6 hosts. There may be host visible changes
> in the work on naming and discovery protocols, however. In its
design,
> the working group shall also consider security aspects and the
impact
> on manageability. The main focus of the working group is home
> networks, but the group's results may also find applications in
other
> small networks.
> 
> The working group will liaise with the relevant IETF working
> groups. In particular, the group should work closely with the V6OPS
> working group, review any use or extension of DHCP with the DHC
> working group, and work with additional DNS requirements with the
> DNSEXT and DNSOP working groups. If it turns out that additional
> options are needed for a routing protocol, they will be developed in
> the appropriate Routing Area working group, with the HOMENET working
> group providing the architecture and requirements for such
> enhancements. The working group will also liase with external
> standards bodies where it is expected that there are normative
> dependencies between the specifications of the two bodies.
> It is expected that in the architecture definition stage liaising
> with the Broadband Forum, DLNA, and UPnP Forum is necessary.
> 
> Milestones:
> 
> Jul 2011 Formation of the working group
> Sep 2011 First WG draft on the architecture
> Dec 2011 Submission of the architecture draft to the IESG as 
> Informational RFC
> Dec 2011 Charter re-evaluation based on the architecture work
> Dec 2011 First WG draft on prefix configuration
> Dec 2011 First WG draft on routing
> Jan 2011 First WG draft on name resolution
> Feb 2011 First WG draft on service discovery
> Feb 2011 First WG draft on perimeter security
> Feb 2012 Start of routing related work in the relevant routing area 
> working group, if needed
> Mar 2012 Submission of the prefix configuration draft to the IESG as

> Standards Track RFC
> Apr 2012 Submission of the routing draft to the IESG as 
> Informational RFC
> Jun 2012 Submission of the name resolution draft to the IESG as 
> Standards Track RFC
> Jun 2012 Submission of the service discovery draft to the IESG as 
> Standards Track RFC
> Aug 2012 Submission of the perimeter security draft to the IESG as 
> Informational RFC
> 
>

---

From: Ralph Droms <[email-masked]>
Date: Mon, 27 Jun 2011 17:07:20 -0400

> A little guidance on how I think this charter can be improved.

David - frankly, you have given advice that this effort should be moved to the IRTF.  I  see very little advice on how to improve the charter for the WG in the IETF.

> interpret it as being in scope NOW?

Can this issue be fixed with a simple rewording:

  Specific protocol work described below is anticipated
  to be identified by the architecture document as areas
  of work to be chartered as within the scope of the
  working group. 

> My concern, and the concern of others, was that the original charter

I'd like to hear directly from others about their concerns regarding
the current charter.

> work during the chartering process.

Do you still have this same concern about the *current* charter?

> the "specific protocol work described below" is not at all specific.

I strongly disagree with you here.  This charter represents engineering work exactly as intended by the IETF.  The WG is chartered to define an architecture, and then engineer a system to meet the requirements of that architecture using existing protocols as building blocks.  Making a home network work is clearly not a research problem.  We know what needs to be done, with the major constraint that a simple network of a few links and routers has to operate with active admin intervention.  The hard work in the architecture will be to bound the problem and get consensus on how many is "a few".  If anything, the charter should more strongly express the strength of its convictions and state explicitly that existing protocols will be used with as few extensions as possible.  Otherwise, I'm fine with the charter as written and am happy to approve it.

- Ralph

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 28 Jun 2011 00:52:48 +0200

David,

> A little guidance on how I think this charter can be improved.

Great!

> thus is NOT NOW is scope of this charter?

After the recharter. I can clarify this. And it already says what 
specifically is not in scope (submitting documents that make protocol 
changes). How about this:

OLD:
Specific protocol work described below
is anticipated to be within the scope of the working group. However,
the group is required to review its charter and milestones with the
IESG and IETF community before submitting documents that make protocol
changes.
NEW:
Specific protocol work described below
is expected to be within the scope of the working group one the 
architecture work
is complete. However,
the group is required to review its charter and milestones with the
IESG and IETF community before submitting documents that make protocol
changes. It is expected that the group has to discuss some of the below 
solutions,
however, in order to complete the architecture work.

Would this be clearer?

> work during the chartering process.

Right. I was one of those ADs who balloted against the charter back 
then. But lets focus on the current charter. I don't think this issue 
exists in the current charter as written.

> The charter text makes it obvious that the engineering changes are not

That's right. There's some work to be done. And given your comments from 
a couple of IESG meetings ago, we've changed the charter so that the 
architecture and plan for changes needs to come first. Once it is clear, 
the group can proceed for real with the changes.

> the "specific protocol work described below" is not at all specific.

I think we need to distinguish engineering efforts with a priori known 
end result (build this house) from those with more initial effort on 
requirements (build the optimal house for this family) and from research 
(develop new materials technology for houses). HOMENET is of the second 
type. In general, the IETF does not work only on the first type of 
efforts. We do constrain (and sometimes over- or under-constrain) 
efforts based on specific concerns, of course. The method that we're 
using in this case is to have the scope of solutions work decided by the 
IESG/IETF only after the architecture is clear. Continuing with the 
house construction analogy, this is like asking for the architects to 
make a plan for the house before committing to materials and 
construction contracts. However, just like with architecture, materials 
choices and technology has to be discussed as part of the architectural 
design, as they drive what can be built.

> a resulting architecture document needs to be clear

I think that is the intent. Is there something missing from the current 
charter text with regards to this? It says:

The task of the group is to produce an architecture document that outlines
how to construct home networks involving multiple routers and
subnets. This document is expected to apply ... and other existing 
components of the IPv6
architecture. The architecture document should drive what protocols
changes, if any, are necessary.

Jari

---

From: Ralph Droms <[email-masked]>
Date: Tue, 28 Jun 2011 06:16:41 -0400

On Jun 27, 2011, at 1:52 PM 6/27/11, David Harrington wrote:
> [...]

[...] with the major constraint that a simple network of a few links and routers has to operate with active admin intervention.

s/with active admin intervention/without active admin intervention/

- Ralph

---

From: Randy Turner <[email-masked]>
Date: Tue, 28 Jun 2011 07:06:34 -0700

"without active administration" should probably be the goal regardless of topology..,

Randy

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 28 Jun 2011 09:23:53 -0500

Dear INT ADs,

I don't want to interrupt the food fight just to ask someone to pass the 
salt, but ... :D

The current (last I saw) proposed charter for HOMENET didn't seem quite 
clear enough that having "as few subnets as possible" doesn't make the 
complexity of having multiple subnets go away. I was hoping that this could 
be stated a little more bluntly.

Could I suggest something like

OLD: o Multiple segments: While less complex L3-toplogies involving as few
subnets as possible are preferred in home networks for a variety of
reasons including simpler management and service discovery,
incorporation of dedicated segments remain necessary for some
cases. For instance, ... (excellent reasons deleted because I wasn't 
questioning them)

NEW: o Multiple segments: While less complex L3-toplogies involving as few 
subnets as possible are preferred in home networks for a variety of reasons 
including simpler management and service discovery, the introduction of more 
than one subnet into a home network is enough to add complexity that needs 
to be addressed, and multiple dedicated segments are necessary for some 
cases. For instance, ... (excellent reasons remain unchanged)

I hope this is a helpful comment, because I don't want to derail the general 
conversation by saying something NOT helpful.

Spencer

---

From: Ralph Droms <[email-masked]>
Date: Tue, 28 Jun 2011 10:30:12 -0400

> "without active administration" should probably be the goal regardless of topology..,

Obscure wording on my part.  What I was trying to express was, in fact, homenet should do its work within two independent constraints:

* simple network of a few links and routers
* operates without active admin intervention

- Ralph

---

From: Mark Townsley <[email-masked]>
Date: Tue, 28 Jun 2011 16:34:03 +0200

Thanks Spencer. For my part, I have no problem with your proposed text.

- Mark

On Jun 28, 2011, at 4:23 PM, Spencer Dawkins wrote:

> Dear INT ADs,
> 
> I don't want to interrupt the food fight just to ask someone to pass the salt, but ... :D
> 
> The current (last I saw) proposed charter for HOMENET didn't seem quite clear enough that having "as few subnets as possible" doesn't make the complexity of having multiple subnets go away. I was hoping that this could be stated a little more bluntly.
> 
> cases. For instance, ... (excellent reasons deleted because I wasn't questioning them)
> 
> NEW: o Multiple segments: While less complex L3-toplogies involving as few subnets as possible are preferred in home networks for a variety of reasons including simpler management and service discovery, the introduction of more than one subnet into a home network is enough to add complexity that needs to be addressed, and multiple dedicated segments are necessary for some cases. For instance, ... (excellent reasons remain unchanged)
> 
> I hope this is a helpful comment, because I don't want to derail the general conversation by saying something NOT helpful.
> 
> Spencer

---

From: Mark Townsley <[email-masked]>
Date: Tue, 28 Jun 2011 16:38:35 +0200

> "without active administration" should probably be the goal regardless of topology..,

+1

- Mark

---

From: Ralph Droms <[email-masked]>
Date: Tue, 28 Jun 2011 10:41:21 -0400

> Thanks Spencer. For my part, I have no problem with your proposed text.

Fine with me, too...

- Ralph

---

From: Jari Arkko <[email-masked]>
Date: Wed, 29 Jun 2011 09:30:17 +0200

Randy, Mark, et al -- I agree about the without active administration 
part, of course. But was there a change in the charter text that you 
wanted based on this exchange?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 29 Jun 2011 09:35:36 +0200

Spencer, Mark: Agreed. I have made this change to the current copy of 
the charter. Thanks.

Jari