Re: [fun] new version of the charter

["David Harrington" <[e-mail]>]

Hi,

a few comments:
 
1) I think this proposal is obviously AD-shopping with roughly the
same proposal that was rejected last year, because the scope was too
open-ended.  

I notice the FUN mailng list has no discussions on it.

2) "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."
If you need a mechanism to turn it on, then it apparently is not on by
default.
Or it is on by default, but you need a mechanism for an administrator
to turn it on/off as desired.

3) "It is expected that the working group will define a set of
protocol
specifications to accomplish the five requirements from
above. ... Prefix configuration, routing, and security
related work shall not cause any changes that are not backwards
compatible to existing IPv6 hosts... The working group will liaise
with the relevant IETF working groups
and other standards bodies. "

I think this is way too open-ended. Can this WG modify security
protocol standards that have been developed in the security area? Can
it modify protocols TCP options without bother to go through the TCP
maintenece WG, which has been chartered to handle TCP maintenance
issues? This charter certainly does not constrain such things.

If the INT ADs want to allow a free-hand on modifying INT protocols,
that's their business (to a degree), and obviously the charter has
constraints on modification of INT protocols like DNS and DHCP. Giving
these guys free rein to modify any protocol they choose, apparently
from any area, seems over-reaching to me. I would be much more
accepting of a charter that said they could identify proposed
requirements and proposed changes to meet those requirements, but any
such changes to existing protocols would need to be done by WGs in the
appropriate area, or require a re-charter as deliverables for this WG
to develop. 

I raise this point partly because, for example, it is important to
keep TCP stable; but the TCPM WG gets (fairly) frequent requests to
modify or add TCP options. If any TCP option proposals might be
handled, I would want to know they go through the TCPM WG. If storage
were to be addressed, I would want the storage experts from NFS/STORM
involved. If a security protocol is going to be modified, I would want
to know that the security experts have a hand in the design to ensure
that the assumptions built into our current security standards .

I do not find the following sufficiently constraining "The working
group will liaise with the relevant IETF working groups
and other standards bodies." I think, at a minimum, the area
responsible for a protocol should be required to approve changes to
their area's protocols. And the recharter process is designed to make
sure that changes in WG direction are transparent, and that the IETF
as a whole has rough consensus on the proposed WG directions. The
charter as written seems to relieve the WG of the responsibility for
such transparency and IETF consensus.

4) Even the text that does constrain their work on routing apparently
gives them absolute control over the architecure and requirements: "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."
I would be happier with "with the HOMENET working group providing a
proposed architecture and proposed requirements for such
enhancements."

5) The HOMENET WG is mentioned in the charter. Is this proposed WG
going to be called HOMENET? or FUN?

6) The milestones aren't very specific.
"Oct 2011 First WG draft on the architecture"
	So is this WG going to define just one architecture that all
home networks are expected to use?
	Do the home architectures typically found in US home networks
match the architectures used in European home networks and Chinese
home networks and South Amrican home networks? My impression is the
relationship between ISPs and home users differ markedly between US
users and Chinese home users. Are we favoring a particular
architectural approach (and particular vendors) by defining one
architecture?
	Would it be more realistic to call this "an" architecture? Is
this really an appicability statement about the
	home network designs to which the other WG documents will
apply? and is that architecture vendor-neutral?
"Dec 2011 First WG draft on routing" and "Apr 2012 Submission of the
routing draft to the IESG as Informational RFC"
	What is going to be included in this draft? proposed routing
enhancements? proposed requirements?

7) If a similar open-ended charter were submitted to us by a proponent
of clouds, such as Bhumip, or a proponent from Huawei or China Mobile,
would we really approve such an open charter?  

8) To look beyond just the charter of a specific WG, there has been a
recent trend away from the Internet-stack approach,  reflected in the
IETF organization of INT/TSV/APP, toward a deployment/use-case and
multi-layer approach to development, reflected in recent barBOFs and
BOFs such as Clouds, data center, and home networking. Is this a
direction the IETF should be going? Should we change our
organizational structure (and possibly the architecture of the
Internet) to reflect this change in thinking? Since the IESG members
are the managers of the IETF standards process, should we be
developing process regarding cross-area work such as clouds, data
center, and home networking?

David Harrington
Director, IETF Transport Area
[e-mail] (preferred for ietf)
[e-mail]
[phone] (cell)

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Jari Arkko
> Sent: Thursday, June 16, 2011 1:16 AM
> To: [e-mail]
> Subject: [fun] new version of the charter
> 
> 
> Mark Townsley provided me with a suggested edit of the 
> charter. I think 
> it looks pretty good. Thoughts?
> 
> Home Networks (homenet)
> -----------------------------------
> 
> Current Status: Proposed
> Last Edit: Friday, June 16th, 2011
> 
> Chairs:
> TBD
> 
> Internet Area Directors:
> Ralph Droms <[e-mail]>
> Jari Arkko <[e-mail]>
> 
> Internet Area Advisor:
> Jari Arkko <[e-mail]>
> 
> Routing Area Technical Advisor:
> TBD
> 
> Security Area Technical Advisor:
> TBD
> 
> Mailing Lists:
> General Discussion: [e-mail]
> 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 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.
> 
> o Home networks are moving from a "one size fits all" model to
> incorporation of dedicated segments for specific purposes. For
> instance, a common feature in modern 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 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 and 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
and
> necessary additional tools addressing this full scope of
requirements:
> 
> o prefix configuration for routers
> 
> o managing routing
> 
> o name resolution
> 
> o service discovery
> 
> o network security
> 
> Specifically, the group will 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
by
> default. For name resolution and service discovery, extensions are
> needed to mDNS and DNS-SD 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
> 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 HOMENET 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
> 
> _______________________________________________
> fun mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/fun
>