Subject: Re: New Non-WG Mailing List: fun -- FUture home Networking (FUN)

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 6 Jun 2011 22:47:55 +0200

On Mon, Jun 06, 2011 at 09:54:56AM -0700,
 IETF Secretariat <[email-masked]> wrote 
 a message of 15 lines which said:

> Purpose: Mailing list for proposed working group on FUture home Networking (FUN)

And nothing more (same thing on the Web site). Could we ask for a
little bit more context when a new IETF list is created?

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Jun 2011 22:16:35 -0400

--On Monday, June 06, 2011 22:47 +0200 Stephane Bortzmeyer
<[email-masked]> wrote:

> And nothing more (same thing on the Web site). Could we ask
> for a little bit more context when a new IETF list is created?

Stephane,

I think asking is perfectly reasonable.  But I also think we
should trust the ADs who need to agree to these things to
determine when the right point is reached to create a mailing
list for discussion.  I have no idea whether it is the case
here, but it is not at all hard for me to imagine circumstances
in which it would be appropriate to create and announce a
mailing list when there are few specifics beyond a very general
topic area.

Someone can always take the action to make a more comprehensive
announcement to the IETF list when things come together more.

    john

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 Jun 2011 04:56:40 +0000

> mailing list when there are few specifics beyond a very general

That may sometimes be true, but I don't think it's the typical case.
It's certainly not the case here, where there's a clear problem
statement, with a strawman proposal for what the working group will do
(even if it's not in charter form yet).  Something of that should have
been in the mailing list announcement.

We've seen quite a few non-WG mailing lists announced, where the title
of the list was all we got, and we'd have no idea whatsoever if we
wanted to subscribe to it.  Please, when we send out announcements,
let's include enough of a description -- even two or three paragraphs,
if that's what it takes -- so that we can understand what's meant to
be discussed, and so that we can know whether we want to subscribe.

The announcements for the obscurity-interest and paws lists are
examples of particularly good ones.  This one and the one for "weirds"
are particularly lacking.

Barry

---

From: Jari Arkko <[email-masked]>
Date: Tue, 07 Jun 2011 08:01:48 +0300

Stephane, John,

FUN is a new working group proposal, a variation of the HOMEGATE / 
HOMENET theme that we discussed some time ago but this time looking at 
it from a different angle. Roughly speaking, its about how to run IPv6 
in home networks, including some possibly missing protocol pieces.

The proposal has been under private discussion during the spring, and is 
now coming to a state where it can be brought for more public 
discussion. I have asked for comments from a few directorates etc last 
week, and was about to ask more publicly once I had the mailing list up 
and running :-)

The draft charter is below. Comments very much appreciated. Subscription 
to the list open.

FUture home Networks (FUN)
-------------------------

Current Status: Proposed
Last Edit: Friday, June 3rd, 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 in
small networks such as those in homes. This evolution sets some
requirements on IETF protocols. An obvious trend for home networking
is the proliferation of networking technology in increasing number of
different devices, from home entertainment systems to appliances and
energy applications, just to name a few examples.  This leads to a
higher number of networked devices in each network.  However, some
more fundamental changes are occurring at the same time as well:

o  First, the link layer networking technology is become more
   heterogeneous, as networks are starting to employ, for instance,
   both traditional Ethernet technology and link layers designed for
   low-powered sensor networks.

o  Networks are also moving from a "one size fits all" model to
   dedicated segments for specific purposes. For instance, a common
   feature in high-end home routers in the ability to support both
   guest and private network segments. Similar needs for separation
   may occur in other cases, such as separating building control from
   the Internet access network. Typically, different subnets, routing
   and firewalls are used between the different segments.

o  Service providers are rolling out networks that support IPv6, and
   home gateway support for IPv6 is starting to appear. But for home
   networks, IPv6 is not just a new protocol, it also changes address
   allocation principles and allows end-to-end communication to the
   devices in the home.

o  End-to-end communication is both an opportunity and a problem, as it
   enables new applications but also exposes nodes in the internal
   networks to unwanted traffic from the Internet. Firewalls are in
   many cases needed to prevent exposure. However, this reduces the
   usefulness of end-to-end connectivity, as the firewall policy model
   is usually default deny, only allowing a small set of known
   protocols. In addition, consumer equipment typically reacts slowly
   if at all to changes in the typical Internet application, and it is
   likely that traffic for a popular application is not recognized by
   devices manufactured before that application was launched.

Future home networks need to provide the tools to handle these
situations in an easy manner. It is obvious that manual configuration
is rarely possible. For IPv4, NAT and private address based solutions
already provide limited solutions. The purpose of this working group
is to develop an architecture and necessary additional tools for IPv6,
to address the full scope of requirements:

o  prefix configuration for routers
o  managing routing (including turning it on by default)
o  name resolution
o  service discovery
o  perimeter security

Specifically, the group should 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.

In addition, the group will apply existing protocols to handle the
five requirements above. For prefix configuration, DHCPv6 PD is an
obvious candidate solution, possibly supplemented by 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.
For name resolution and service discovery, extensions are needed to
mDNS and DNS-SD to enable them to work across subnets.

For perimeter 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 default allow
security policy. This may be accomplished, for instance, through
driving security policy from an up-to-date database in the Internet or
using simple security along with firewall control protocols such as
PCP.

It is expected that the working group defines 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 visible to 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 working group will liaise with the relevant IETF working groups
and other standards bodies. 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 get feedback on DNS issues from
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 FUN working group
providing the architecture and requirements for such enhancements.

Milestones:

Oct 2011    First WG draft on the architecture
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    Submission of the architecture draft to the IESG as 
Informational RFC
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: John C Klensin <[email-masked]>
Date: Tue, 07 Jun 2011 10:20:03 -0400

--On Tuesday, June 07, 2011 04:56 +0000 Barry Leiba
<[email-masked]> wrote:

>... 
> We've seen quite a few non-WG mailing lists announced, where
> the title of the list was all we got, and we'd have no idea
> whatsoever if we wanted to subscribe to it.  Please, when we
> send out announcements, let's include enough of a description
> -- even two or three paragraphs, if that's what it takes -- so
> that we can understand what's meant to be discussed, and so
> that we can know whether we want to subscribe.

Agreed.  I certainly wasn't trying to suggest that
zero-information announcements were a good thing, only that we
shouldn't try to prohibit them if an AD believed that was the
right thing to do.

> examples of particularly good ones.  This one and the one for
> "weirds" are particularly lacking.

Especially since it is now apparent that the relevant
information was readily available in both cases: See Jari's note
for this one; in the case of "weirds", three documents are now
in the I-D directory and there is apparently a plan to ask for a
BOF in Quebec.

     john