Subject: Re: [homegate] Draft BoF Agenda @ IETF 78

From: Jason Livingood <[email-masked]>
Date: Mon, 28 Jun 2010 19:43:51 -0400

There¹s been no feedback so far on the draft BoF agenda.  I¹ll have to
assume if we receive no feedback that everyone either (a) thinks it looks
fine or (b) isn¹t paying attention.  ;-)

Jason

On 5/31/10 11:23 AM, "Jason Livingood" <[email-masked]>
wrote:

> As noted in my previous email, here is a summary of the BoF request we have
> sent for IETF 78.
> 
> 1 - Expected Attendance: 75 People
> 2 - Number of sessions: 1
> 3 - Length of sessions: 1 Hour
> 4  Agenda:
> (Assume start of BoF is 0:00 for simplicity)
> 0:00  0:05     Blue Sheets, Agenda Bashing
> 0:05  0:10     Review of Goals of BoF
> 0:10  0:30     Review of Charter
> 0:30  0:45     Discussion of Concerns from Other SDOs / Potential Overlap
> 0:45  1:00     Final Discussion of Charter & How/Whether to Proceed with
> Homegate
> 
> Regards
> Jason
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 28 Jun 2010 17:22:26 -0700

At 7:43 PM -0400 6/28/10, Jason Livingood wrote:
>There's been no feedback so far on the draft BoF agenda.  I'll have to assume if we receive no feedback that everyone either (a) thinks it looks fine or (b) isn't paying attention.  ;-)

I'll take (a). And we have 1 hr 15 mins, so we have 15 minutes more than you scheduled. I propose that you stretch out the review of the charter instead of more about "concerns from other SDOs", give that the telecon a few weeks earlier will cover the latter topic.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Mon, 28 Jun 2010 17:37:44 -0700

Jason Livingood wrote:
> There’s been no feedback so far on the draft BoF agenda.  I’ll have to 
> assume if we receive no feedback that everyone either (a) thinks it 
> looks fine or (b) isn’t paying attention.  ;-)
> 
> Jason
> 
> 
> On 5/31/10 11:23 AM, "Jason Livingood" 
> <[email-masked]> wrote:
> 
>     As noted in my previous email, here is a summary of the BoF request
>     we have sent for IETF 78.
> 
>     1 - Expected Attendance: *75 People*
>     2 - Number of sessions: *1
>     *3 - Length of sessions: *1 Hour
>     *4 – Agenda:
>     *(Assume start of BoF is 0:00 for simplicity)

has the date and time been set?

>     0:00 – 0:05     Blue Sheets, Agenda Bashing
>     0:05 – 0:10     Review of Goals of BoF

What document will be used for this agenda item?

>     0:10 – 0:30     Review of Charter

What document will be used for this agenda item?

>     0:30 – 0:45     Discussion of Concerns from Other SDOs / Potential
>     Overlap

Will the concerns be documented?

Perhaps a more "postiive" approach would be to list some
other related SDOs and indicate how Homegate would differentiate
itself from said SDOs to prevent overlap.

regards, kiwin

-- 
Stephen [kiwin] Palm   Ph.D.                          E:  [email-masked]
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: Paul Hoffman <[email-masked]>
Date: Mon, 28 Jun 2010 17:50:30 -0700

>has the date and time been set?

The current IETF agenda (<https://datatracker.ietf.org/meeting/78/agenda.html>) has HOMEGATE Wednesday morning at 9AM; Maastricht is GMT+2.

>>    0:00 - 0:05     Blue Sheets, Agenda Bashing
>>    0:05 - 0:10     Review of Goals of BoF
>

Good question, and one that should be answered ahead of the BoF.

>>    0:10 - 0:30     Review of Charter
>

<http://trac.tools.ietf.org/area/tsv/trac/wiki/HOMEGATE>

>>    0:30 - 0:45     Discussion of Concerns from Other SDOs / Potential
>>    Overlap
>

It would be grand if someone on the telecon would send a summary of those to the mailing list well before the BoF.

>itself from said SDOs to prevent overlap.

That's one approach, but not a typical one in the IETF. My preference would be more discussion of the charter than other SDOs.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Mon, 28 Jun 2010 19:02:17 -0700

> That's one approach, but not a typical one in the IETF. My preference would be more discussion of the charter than other SDOs.

As I have seen nothing proposed that isn't already being addressed in other SDOs,
it would be a prudent step in this case.  This information need not be in the charter itself,
but would help craft a focused charter (if possible) and
could provide justification for the obvious questions
that folks will ask.

regards, kiwin

---

From: Jari Arkko <[email-masked]>
Date: Tue, 29 Jun 2010 12:51:59 +0300

Stephen,

> itself from said SDOs to prevent overlap.

I agree. Hopefully the virtual meeting will give us the necessary 
information on what other SDOs are doing (I know I know too little of 
that). Then in the BOF we can we have a discussion on how the proposed 
IETF activity would fit into the map.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 29 Jun 2010 13:07:37 +0300

Paul ,

> That's one approach, but not a typical one in the IETF. My preference would be more discussion of the charter than other SDOs.

I like to think of this more as an issue of existing work vs. proposed 
work question. That is the heart of any charter discussion. What 
specifications and ongoing efforts already exist, and what exactly are 
we proposing on top of them?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 29 Jun 2010 13:09:53 +0300

Jason Livingood kirjoitti:

There’s been no feedback so far on the draft
BoF agenda.  I’ll have to assume if we receive no feedback that
everyone either (a) thinks it looks fine or (b) isn’t paying attention.
;-)

I think the agenda looks fine at a high level, assuming we take
Stephen's comment about the overlap section into account.

But the crux is of course in the details. What specific issues get
presented and discussed, for instance. Does someone have a good
document or a slide set that explains who is doing what in this space,
for instance?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 29 Jun 2010 14:36:06 +0300

I have read the charter on the wiki page at
http://trac.tools.ietf.org/area/tsv/trac/wiki/HOMEGATE and have some
comments. I think it is basically in the right direction, but needs
more "beef", particularly around description of the current problems,
and needs to be more specific. I have some suggested changes below.

Proposed Charter:
Access to broadband Internet services use networking technology of one
form or another within the home, small office/home office (SOHO) or
small to medium business (SMB) as the demarcation between the local
network and the Internet. These technologies almost always involve a
single entity - which is not purely a router - called a "home gateway".
This entity connects a local user or users to various LAN services,
providing some basic level of security. The majority of Internet users
employ home gateways for this purpose.

Rewriting to make the first sentence simpler and to remove the feeling
that the gateway's main purpose is to provide security:

Broadband Internet service to homes and small offices typically employ
a "home gateway" device. This device acts as the demarcation line
between the local network and the service provider's network. Typical
implementations employ routing and/or address translation
functionality, and may involve additional capabilities for firewalling,
wireless networking, and local services.

However, many serious, long-term problems face users of home
gateways today. At the root of many of these problems is the fact that
device manufacturers, and/or the organizations that specify
requirements for such devices, are not certain which IETF standards and
best current practices should be supported, and when/why that support
is needed. As a result of this, millions of devices are being deployed
every year, which do not work with important IETF protocols, standards,
and best practices that are central to the future of the Internet.

One of the problems in this area appears to be that home gateway
vendors are unclear which RFCs are important, or current, and why they
are important and in what context they matter. Thus, the primary
objective of the group is document a baseline of requirements derived
from "core" RFCs which must be supported. A secondary objective is to
list desired-but-optional, or "advanced", requirements from the same
RFCs as well as other, non-core RFCs. The context and reasoning behind
each document which is included should be summarized as well, in order
to improve comprehension of why a given document has been included.
These things will help improve compatibilities with and capabilities
for use of the Internet of today. This will include a focus in areas
such as DNS proxy behavior, congestion mechanisms support, and
security.

I'm not super enthusiastic about this problem description. How about
this:

The basic functionality of home gateways is simple, works well, and is
in daily use by hundreds of millions of people. However, there are also
problems. These problems appear particularly with traffic types outside
the most common ones, new and upcoming Internet functionality, and
under extreme conditions. These problems include but are not limited to:

* Many gateways employ simple queuing algorithms in their forwarding
logic. These algorithms are simple to implement, but behave badly under
load conditions that occur commonly in home networks with, for
instance, P2P or IPTV traffic. This can lead to poor response times on
interactive traffic.

* Many gateways offer DNS proxying or perform firewalling that affects
DNS traffic. However, while basic DNS functionality works with these
designs they often fail with more complex DNS transactions, for
instance when employ TCP transport or with EDNS0. The problem is that
while these complex cases are uncommon today, they are becoming more
common due various reasons.

* Support
for IPv6 is lacking to a great degree, more importantly, there is no
clear
understanding of what IPv6 features would be necessary on a home
gateway beyond those specified in RFC 4294. For instance, what
firewalling functionality should be employed, and with what defaults?

* While basic NAT functionality on outgoing TCP sessions typically
works well in the gateways, they do not always support the current
timeout recommendations or additional transport protocols.

The basic hypothesis of this working group is that a well organized
collection of requirements for support of various features would make
it more likely that future home gateway devices behave better in these
situations. This collection of requirements would form a single
document to document the baseline requirements derived
from "core" RFCs which must be supported. A secondary objective is to
list desired-but-optional, or "advanced", requirements from the same
RFCs as well as other, non-core RFCs. The context and reasoning behind
each document which is included should be summarized as well, in order
to improve comprehension of why a given document has been included. In
most cases there are existing RFCs that already contain the necessary
requirements, such as RFC 4294, RFC 4787, RFC 5508, RFC 5382, RFC 5625,
or RFC-to-be-draft-ietf-dnsext-dns-tcp-requirements. In some other
cases new requirements have to be developed.

A secondary problem is compatibility with and capability for the
use of
the Internet of tomorrow. New security needs related to DNS are
motivating a move to DNSSEC. However, many if not most home gateways
cannot handle DNSSEC, which is expected to be a major problem that
could significantly impede the deployment of DNSSEC globally. Support
for IPv6 is also lacking to a great degree and there is no clear
understanding of how such devices should support IPv6.

Good, but given my suggested edit above I would shorten this to:

A secondary problem is compatibility with and capability for the use of
the Internet of tomorrow. New security needs related to DNS are
motivating a move to DNSSEC. However, many if not most home gateways
cannot handle DNSSEC, which is expected to be a major problem that
could significantly impede the deployment of DNSSEC globally.

This working group will not develop new Internet protocols, but
may
create different requirements in the context of home gateways.

I would say:

This working group will not develop new protocols, but makes
recommendations on supported features and protocols in the context of
home gateways.

If the
Working Group believes that new protocols are needed, it will refer the
problem to the IESG for further work in existing or new Working Groups.

OK

Add: The working group works together with other standards bodies (such
as the Broadband Forum) that define requirements on home gateways. The
role of the working group is to focus on the recommendations related to
the use of IETF-specified technology such as DNS, NATs, or IPv6 and not
overlap with system-level or link layer technology related
specifications from these other standards bodies.

Proposed Deliverables and Priorities:The Working
Group
would work to improve the network experience that a user of a home
gateway gets when using the Internet. This means specifying the
requirements from different RFCs should be supported in home gateways.
This will touch on standards such as:

* IPv6

* DNSSEC RFCs and BCPs

* ECN

* RED (or other queue management)

* DNS Proxy BCPs

* Security-Related BCPs

* Other TBD

The group will create a BCP-level document for home gateways that only
support IPv4, and a second BCP-level document for home gateways that
only support both IPv4 and IPv6.

The group shall prioritize work as follows:

1. IPv4-related topics

2. IPv6-related topics

3. DNS-related topics (DNSSEC, DNS Proxies, etc.)

4. ECN-related topics (congestion and queue management)

5. Security-related topics

Too handwavy and may be too detailed given that the preceding
paragraphs should have already defined the problems.

How about this:

The working group works to improve the networking experience for the
user of home gateways. The group has the following work items:

1. Requirements document for basic, mandatory functionality for
IPv4-only home gateways (BCP)

2. Requirements document for basic, mandatory functionality for
dual-stack home gateways (BCP)

3. Requirements document for additional, optional functionality in home
gateways (BCP)

Please find suggested full edit and diffs as attachments.

Jari

Broadband Internet service to homes and small offices typically employ
a "home gateway" device. This device acts as the demarcation line
between the local network and the service provider's network. Typical
implementations employ routing and/or address translation
functionality, and may involve additional capabilities for
firewalling, wireless networking, and local services.

The basic functionality of home gateways is simple, works well, and is
in daily use by hundreds of millions of people. However, there are
also problems. These problems appear particularly with traffic types
outside the most common ones, new and upcoming Internet functionality,
and under extreme conditions. These problems include but are not
limited to:

* Many gateways employ simple queuing algorithms in their forwarding
  logic. These algorithms are simple to implement, but behave badly
  under load conditions that occur commonly in home networks with, for
  instance, P2P or IPTV traffic. This can lead to poor response times
  on interactive traffic.

* Many gateways offer DNS proxying or perform firewalling that affects
  DNS traffic. However, while basic DNS functionality works with these
  designs they often fail with more complex DNS transactions, for
  instance when employ TCP transport or with EDNS0. The problem is
  that while these complex cases are uncommon today, they are becoming
  more common due various reasons.

* Support for IPv6 is lacking to a great degree, more importantly,
  there is no clear understanding of what IPv6 features would be
  necessary on a home gateway beyond those specified in RFC 4294. For
  instance, what firewalling functionality should be employed, and
  with what defaults?

* While basic NAT functionality on outgoing TCP sessions typically
  works well in the gateways, they do not always support the current
  timeout recommendations or additional transport protocols.

The basic hypothesis of this working group is that a well organized
collection of requirements for support of various features would make
it more likely that future home gateway devices behave better in these
situations. This collection of requirements would form a single
document to document the baseline requirements derived from "core"
RFCs which must be supported. A secondary objective is to list
desired-but-optional, or "advanced", requirements from the same RFCs
as well as other, non-core RFCs. The context and reasoning behind each
document which is included should be summarized as well, in order to
improve comprehension of why a given document has been included. In
most cases there are existing RFCs that already contain the necessary
requirements, such as RFC 4294, RFC 4787, RFC 5508, RFC 5382, RFC
5625, or RFC-to-be-draft-ietf-dnsext-dns-tcp-requirements. In some
other cases new requirements have to be developed.

A secondary problem is compatibility with and capability for the use
of the Internet of tomorrow. New security needs related to DNS are
motivating a move to DNSSEC. However, many if not most home gateways
cannot handle DNSSEC, which is expected to be a major problem that
could significantly impede the deployment of DNSSEC globally.

This working group will not develop new protocols, but makes
recommendations on supported features and protocols in the context of
home gateways. If the Working Group believes that new protocols are
needed, it will refer the problem to the IESG for further work in
existing or new Working Groups.

The working group works together with other standards bodies (such as
the Broadband Forum) that define requirements on home gateways. The
role of the working group is to focus on the recommendations related
to the use of IETF-specified technology such as DNS, NATs, or IPv6 and
not overlap with system-level or link layer technology related
specifications from these other standards bodies.

The working group works to improve the networking experience for the
user of home gateways. The group has the following work items:

1. Requirements document for basic, mandatory functionality for
IPv4-only home gateways (BCP)

2. Requirements document for basic, mandatory functionality for
dual-stack home gateways (BCP)

3. Requirements document for additional, optional functionality in
home gateways (BCP)
charter-original.txt

charter-jari.txt

Access to broadband Internet services use networking technology of one

Broadband Internet service to homes and small offices typically employ

form or another within the home, small office/home office (SOHO) or

a "home gateway" device. This device acts as the demarcation line

small to medium business (SMB) as the demarcation between the local

between the local network and the service provider's network. Typical

network and the Internet. These technologies almost always involve a

implementations employ routing and/or address translation

single entity - which is not purely a router - called a "home

functionality, and may involve additional capabilities for

gateway". This entity connects a local user or users to various LAN

firewalling, wireless networking, and local services.

services, providing some basic level of security. The majority of

Internet users employ home gateways for this purpose.

However, many serious, long-term problems face users of home gateways

The basic functionality of home gateways is simple, works well, and is

today. At the root of many of these problems is the fact that device

in daily use by hundreds of millions of people. However, there are

manufacturers, and/or the organizations that specify requirements for

also problems. These problems appear particularly with traffic types

such devices, are not certain which IETF standards and best current

outside the most common ones, new and upcoming Internet functionality,

practices should be supported, and when/why that support is needed. As

and under extreme conditions. These problems include but are not

a result of this, millions of devices are being deployed every year,

limited to:

which do not work with important IETF protocols, standards, and best

practices that are central to the future of the Internet.

One of the problems in this area appears to be that home gateway

* Many gateways employ simple queuing algorithms in their forwarding

vendors are unclear which RFCs are important, or current, and why they

logic. These algorithms are simple to implement, but behave badly

are important and in what context they matter. Thus, the primary

under load conditions that occur commonly in home networks with, for

objective of the group is document a baseline of requirements derived

instance, P2P or IPTV traffic. This can lead to poor response times

from "core" RFCs which must be supported. A secondary objective is to

on interactive traffic.

list desired-but-optional, or "advanced", requirements from the same

RFCs as well as other, non-core RFCs. The context and reasoning behind

* Many gateways offer DNS proxying or perform firewalling that affects

each document which is included should be summarized as well, in order

DNS traffic. However, while basic DNS functionality works with these

to improve comprehension of why a given document has been

designs they often fail with more complex DNS transactions, for

included. These things will help improve compatibilities with and

instance when employ TCP transport or with EDNS0. The problem is

capabilities for use of the Internet of today. This will include a

that while these complex cases are uncommon today, they are becoming

focus in areas such as DNS proxy behavior, congestion mechanisms

more common due various reasons.

support, and security.

* Support for IPv6 is lacking to a great degree, more importantly,

there is no clear understanding of what IPv6 features would be

necessary on a home gateway beyond those specified in RFC 4294. For

instance, what firewalling functionality should be employed, and

with what defaults?

* While basic NAT functionality on outgoing TCP sessions typically

works well in the gateways, they do not always support the current

timeout recommendations or additional transport protocols.

The basic hypothesis of this working group is that a well organized

collection of requirements for support of various features would make

it more likely that future home gateway devices behave better in these

situations. This collection of requirements would form a single

document to document the baseline requirements derived from "core"

RFCs which must be supported. A secondary objective is to list

desired-but-optional, or "advanced", requirements from the same RFCs

as well as other, non-core RFCs. The context and reasoning behind each

document which is included should be summarized as well, in order to

improve comprehension of why a given document has been included. In

most cases there are existing RFCs that already contain the necessary

requirements, such as RFC 4294, RFC 4787, RFC 5508, RFC 5382, RFC

5625, or RFC-to-be-draft-ietf-dnsext-dns-tcp-requirements. In some

other cases new requirements have to be developed.

A secondary problem is compatibility with and capability for the use

A secondary problem is compatibility with and capability for the use

of the Internet of tomorrow. New security needs related to DNS are

of the Internet of tomorrow. New security needs related to DNS are

motivating a move to DNSSEC. However, many if not most home gateways

motivating a move to DNSSEC. However, many if not most home gateways

cannot handle DNSSEC, which is expected to be a major problem that

cannot handle DNSSEC, which is expected to be a major problem that

could significantly impede the deployment of DNSSEC globally. Support

could significantly impede the deployment of DNSSEC globally.

for IPv6 is also lacking to a great degree and there is no clear

understanding of how such devices should support IPv6.

This working group will not develop new Internet protocols, but may

This working group will not develop new protocols, but makes

create different requirements in the context of home gateways. If the

recommendations on supported features and protocols in the context of

Working Group believes that new protocols are needed, it will refer

home gateways. If the Working Group believes that new protocols are

the problem to the IESG for further work in existing or new Working

needed, it will refer the problem to the IESG for further work in

Groups.

existing or new Working Groups.

Proposed Deliverables and Priorities:The Working Group would work to

The working group works together with other standards bodies (such as

improve the network experience that a user of a home gateway gets when

the Broadband Forum) that define requirements on home gateways. The

using the Internet. This means specifying the requirements from

role of the working group is to focus on the recommendations related

different RFCs should be supported in home gateways. This will touch

to the use of IETF-specified technology such as DNS, NATs, or IPv6 and

on standards such as:

not overlap with system-level or link layer technology related

specifications from these other standards bodies.

* IPv6

The working group works to improve the networking experience for the

* DNSSEC RFCs and BCPs

user of home gateways. The group has the following work items:

* ECN

* RED (or other queue management)

* DNS Proxy BCPs

* Security-Related BCPs

* Other TBD

The group will create a BCP-level document for home gateways that only

1. Requirements document for basic, mandatory functionality for

support IPv4, and a second BCP-level document for home gateways that

IPv4-only home gateways (BCP)

only support both IPv4 and IPv6.

The group shall prioritize work as follows:

2. Requirements document for basic, mandatory functionality for

dual-stack home gateways (BCP)

1. IPv4-related topics

3. Requirements document for additional, optional functionality in

2. IPv6-related topics

home gateways (BCP)

3. DNS-related topics (DNSSEC, DNS Proxies, etc.)

4. ECN-related topics (congestion and queue management)

5. Security-related topics

End of changes. 10 change blocks.

53 lines changed or deleted

67 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 30 Jun 2010 12:32:26 -0700

At 1:07 PM +0300 6/29/10, Jari Arkko wrote:
>I like to think of this more as an issue of existing work vs. proposed work question. That is the heart of any charter discussion. What specifications and ongoing efforts already exist, and what exactly are we proposing on top of them?

It seems that other SDOs are creating profiles of what a gateway should support, and those profiles often include a list of IETF protocols and BCPs. If the IETF wants to make a standards track consensus-based profile of our own, I do not think the fact that other SDOs are working on their own affects us. If all we are going to do is an Informational RFC that is a profile, there is not much reason to have a WG at all.

--Paul Hoffman, Director
--VPN Consortium