From jason_livingood@cable.comcast.com Tue Sep 1 14:00:36 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCACE3A6B69 for ; Tue, 1 Sep 2009 14:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.26 X-Spam-Level: ** X-Spam-Status: No, score=2.26 tagged_above=-999 required=5 tests=[AWL=-3.046, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, PLING_QUERY=1.39, RCVD_NUMERIC_HELO=2.067, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFTNKb4kb+ZN for ; Tue, 1 Sep 2009 14:00:29 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 948D73A68A1 for ; Tue, 1 Sep 2009 14:00:25 -0700 (PDT) Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.68311052; Tue, 01 Sep 2009 17:00:14 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 17:00:14 -0400 Received: from 198.137.252.126 ([198.137.252.126]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([198.137.252.76]) with Microsoft Exchange Server HTTP-DAV ; Tue, 1 Sep 2009 21:00:13 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 01 Sep 2009 17:00:12 -0400 From: "Livingood, Jason" To: Message-ID: Thread-Topic: Homegate BoF @ IETF 76? Then we need to narrow our scope! Thread-Index: AcorRzJMcBoLX+wtBk+JIgSW5sc65w== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3334669212_4089459" X-OriginalArrivalTime: 01 Sep 2009 21:00:14.0544 (UTC) FILETIME=[33D04500:01CA2B47] Subject: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 21:00:36 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3334669212_4089459 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable So the deadline for BoF requests for the upcoming meeting is rather early IMHO, set for 7 September. I believe we had a great deal of interest in a BoF, based on the Bar BoF we had at IETF 75. However, I do believe that consensus indicated that our scope was rather to= o broad and should be narrowed substantially. Here=B9s a quick stab at this. I=B9d like a LOT of feedback please, to try to refine this. Don=B9t take anything included or omitted as any kind of a statement at all. Regards Jason IETF 76 BoF Proposal Title: Broadband Home Gateway [HomeGate] BoF =20 Proposed IETF Area: Transport =20 Transport Area Directors: Lars Eggert (lars.eggert@nokia.com) Magnus Westerlund (magnus.westerlund@ericsson.com) =20 BoF Organizers:=20 Jason Livingood (jason_livingood@cable.comcast.com) Dave Oran (oran@cisco.com) =20 Conflicts to Avoid: First Priority: speermint alto ledbat drinks enum v6ops tsvwg dnsext dnsop Second Priority: behave BoFs:=20 =20 Expected Attendance: 25 - 50 people =20 Special Requests: None =20 Number of Sessions: 1 =20 Length of Session: 2 hours =20 Proposed Charter: There are a large number of subscribers to broadband Internet services who use one form or another of networking technology within the home in order t= o share broadband access to the Internet among local users, provide various LAN services, and provide some basic level of security. The majority of Internet users employ =B3home gateways=B2 for this purpose (they are not purely =B3routers=B2). =20 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 no= t 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 IET= F protocols, standards, and best practices that are central to the future of the Internet.=20 =20 One of the problems in this area appears to be that home gateway vendors ar= e unclear which RFCs are important, or current, and why they are important an= d in what context they matter. Thus, the primary objective of the group is document a baseline of =B3core=B2 RFCs/BCPs which must be supported, followed b= y some =B3advanced=B2 RFCs/BCPs which are to be considered optional. The context and reasoning behind each document which is included should be summarized a= s 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 i= n areas such as DNS proxy behavior, congestion mechanisms support, and security.=20 =20 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. =20 Proposed Deliverables: The BoF/WG would work to improve the network experience that a SOHO / residential home user gets when using the Internet. This includes providin= g a tiered specification for what RFCs and BCPs should be supported, in what order/priority, and in what manner. This will touch on standards such as: o IPv6 o DNSSEC RFCs and BCPs o ECN o RED (or other queue management) o DNS Proxy BCPs o Security-Related BCPs o Other TBD=20 Contributors: ISPs and home gateway developers / vendors =20 Proposed Agenda: (120 minutes) 1 =AD Agenda, Goals, and Administrivia / Chairs 5 minutes 2 =AD HomeGate Problem Statement Exploration 60 minutes - Draft problem statement I-D / TBD 10 minutes - Issues with DNSSEC, DNS Proxies / Ray Bellis 10 minutes - IPv6 support issues / John Brzozowski 10 minutes - ECN support issues / TBD 10 minutes - Security issues / TBD 10 minutes - Zero-Config issues / James Woodyatt? 10 minutes 3 =AD Discussion / All 45 minutes 4 =AD Questions and Next Steps / Chairs 10 minutes =20 --B_3334669212_4089459 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Homegate BoF @ IETF 76?  Then we need to narrow our scope!</TIT= LE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>So the deadline for BoF requests for the upcoming meeting is rather early = IMHO, set for 7 September.  I believe we had a great deal of interest i= n a BoF, based on the Bar BoF we had at IETF 75.  <BR> <BR> <U>However, I do believe that consensus indicated that our scope was rather= too broad and should be narrowed substantially.<BR> <BR> </U>Here’s a quick stab at this.  I’d like a LOT of feedba= ck please, to try to refine this.  Don’t take anything included o= r omitted as any kind of a statement at all.<BR> <BR> Regards<BR> Jason<BR> <BR> </SPAN></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12pt'><B>= IETF 76 BoF Proposal<BR> Title</B>: Broadband Home Gateway [HomeGate] BoF<BR>  <BR> <B>Proposed IETF Area</B>: Transport <BR>  <BR> <B>Transport Area Directors</B>: <BR> Lars Eggert (<a href=3D"lars.eggert@nokia.com">lars.eggert@nokia.com</a>)<BR> Magnus Westerlund (<a href=3D"magnus.westerlund@ericsson.com">magnus.westerlu= nd@ericsson.com</a>)<BR>  <BR> <B>BoF Organizers</B>: <BR> Jason Livingood (<a href=3D"jason_livingood@cable.comcast.com">jason_livingoo= d@cable.comcast.com</a>)<BR> Dave Oran (<a href=3D"oran@cisco.com">oran@cisco.com</a>)<BR>  <BR> <B>Conflicts to Avoid</B>: <BR> <B>First Priority</B>: speermint alto ledbat drinks enum v6ops tsvwg dnsext= dnsop<BR> <B>Second Priority</B>: behave<BR> <B>BoFs</B>: <BR>  <BR> <B>Expected Attendance</B>: 25 - 50 people<BR>  <BR> <B>Special Requests</B>: None<BR>  <BR> <B>Number of Sessions</B>: 1<BR>  <BR> <B>Length of Session</B>: 2 hours<BR>  <B> <BR> Proposed Charter</B>:<BR> There are a large number of subscribers to broadband Internet services who = use one form or another of networking technology within the home in order to= share broadband access to the Internet among local users, provide various L= AN services, and provide some basic level of security. The majority of Inter= net users employ “<B>home gateways” </B>for this purpose (they a= re not purely “routers”).<BR>  <BR> 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 manufa= cturers, 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, m= illions of devices are being deployed every year, which do not work with imp= ortant IETF protocols, standards, and best practices that are central to the= future of the Internet. <BR> <I> <BR> </I>One of the problems in this area appears to be that home gateway vendor= s are unclear which RFCs are important, or current, and why they are importa= nt and in what context they matter. Thus, the primary objective of the group= is document a baseline of “core” RFCs/BCPs which must be suppor= ted, followed by some “advanced” RFCs/BCPs which are to be consi= dered optional.  The context and reasoning behind each document which i= s included should be summarized as well, in order to improve comprehension o= f why a given document has been included.  These things will help impro= ve compatibilities with and capabilities for use of the Internet <I>of today= </I>.  This will include a focus in areas such as DNS proxy behavior, c= ongestion mechanisms support, and security. <BR>  <BR> A secondary problem is compatibility with and capability for the use of the= Internet <I>of tomorrow</I>.  New security needs related to DNS are mo= tivating a move to DNSSEC.  However, many if not most home gateways can= not handle DNSSEC, which is expected to be a major problem that could signif= icantly impede the deployment of DNSSEC globally. Support for IPv6 is also l= acking to a great degree and there is no clear understanding of how such dev= ices should support IPv6.<BR>  <BR> <B>Proposed Deliverables</B>:<BR> The BoF/WG would work to improve the network experience that a SOHO / resid= ential home user gets when using the Internet.  This includes providing= a tiered specification for what RFCs and BCPs should be supported, in what = order/priority, and in what manner.  This will touch on standards such = as:<BR> </SPAN></FONT><SPAN STYLE=3D'font-size:12pt'><FONT FACE=3D"Courier New">o  = ; </FONT><FONT FACE=3D"Times New Roman">IPv6<BR> </FONT></SPAN><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'= font-size:11pt'><BR> </SPAN></FONT><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-size:12pt'>o  = ; </SPAN></FONT><SPAN STYLE=3D'font-size:12pt'><FONT FACE=3D"Times New Roma= n">DNSSEC RFCs and BCPs<BR> </FONT></SPAN><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'= font-size:11pt'><BR> </SPAN></FONT><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-size:12pt'>o  = ; </SPAN></FONT><SPAN STYLE=3D'font-size:12pt'><FONT FACE=3D"Times New Roma= n">ECN<BR> </FONT></SPAN><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'= font-size:11pt'><BR> </SPAN></FONT><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-size:12pt'>o  = ; </SPAN></FONT><SPAN STYLE=3D'font-size:12pt'><FONT FACE=3D"Times New Roma= n">RED (or other queue management)<BR> </FONT></SPAN><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'= font-size:11pt'><BR> </SPAN></FONT><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-size:12pt'>o  = ; </SPAN></FONT><SPAN STYLE=3D'font-size:12pt'><FONT FACE=3D"Times New Roma= n">DNS Proxy BCPs<BR> </FONT></SPAN><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'= font-size:11pt'><BR> </SPAN></FONT><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-size:12pt'>o  = ; </SPAN></FONT><SPAN STYLE=3D'font-size:12pt'><FONT FACE=3D"Times New Roma= n">Security-Related BCPs<BR> </FONT></SPAN><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'= font-size:11pt'><BR> </SPAN></FONT><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-size:12pt'>o  = ; </SPAN></FONT><SPAN STYLE=3D'font-size:12pt'><FONT FACE=3D"Times New Roma= n">Other TBD <BR> </FONT></SPAN><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'= font-size:11pt'><BR> </SPAN></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12pt'><B>= Contributors</B>: ISPs and home gateway developers / vendors<BR>  <BR> <B>Proposed Agenda</B>:  (120 minutes)<BR> 1 – Agenda, Goals, and Administrivia / Chairs     = ;            &nb= sp;            &= nbsp;            = ;     5 minutes<BR> 2 – HomeGate Problem Statement Exploration     &n= bsp;            =             &nbs= p;            &n= bsp;   60 minutes<BR>             <I>= - Draft problem statement I-D / TBD       &nbs= p;            &n= bsp;            =             &nbs= p;           10 minut= es<BR>             - I= ssues with DNSSEC, DNS Proxies / Ray Bellis      &n= bsp;            =             &nbs= p;      10 minutes<BR>             - I= Pv6 support issues / John Brzozowski       &nb= sp;            &= nbsp;            = ;            &nb= sp;      10 minutes<BR>             - E= CN support issues / TBD         &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;          10 minutes<B= R>             - S= ecurity issues / TBD          &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;    10 minutes<BR>             - Z= ero-Config issues / James Woodyatt?       &nbs= p;            &n= bsp;            =             &nbs= p;     10 minutes<BR> </I>3 – Discussion / All        &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;     45 minutes<BR> 4 – Questions and Next Steps / Chairs      &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;   10 minutes<BR>  <BR> </SPAN></FONT> </BODY> </HTML> --B_3334669212_4089459-- From jmpolk@cisco.com Tue Sep 1 15:14:31 2009 Return-Path: <jmpolk@cisco.com> X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A76A3A6804 for <homegate@core3.amsl.com>; Tue, 1 Sep 2009 15:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.377 X-Spam-Level: X-Spam-Status: No, score=-5.377 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vg9Fiot5zJ4U for <homegate@core3.amsl.com>; Tue, 1 Sep 2009 15:14:29 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B4ED63A69AF for <homegate@ietf.org>; Tue, 1 Sep 2009 15:14:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FAP85nUqrR7MV/2dsb2JhbACIVLoliEEBkC4FgjiBY4Fc X-IronPort-AV: E=Sophos;i="4.44,314,1249257600"; d="scan'208";a="380007502" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 01 Sep 2009 22:14:42 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n81MEgFc012484; Tue, 1 Sep 2009 15:14:42 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n81MEgox004464; Tue, 1 Sep 2009 22:14:42 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 15:14:42 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.5.240]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 15:14:41 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 01 Sep 2009 17:14:40 -0500 To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com> From: "James M. Polk" <jmpolk@cisco.com> In-Reply-To: <C6C3039C.11F1B%Jason_Livingood@cable.comcast.com> References: <C6C3039C.11F1B%Jason_Livingood@cable.comcast.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: <XFE-SJC-212KO8FNpyL000026fc@xfe-sjc-212.amer.cisco.com> X-OriginalArrivalTime: 01 Sep 2009 22:14:41.0486 (UTC) FILETIME=[9A5186E0:01CA2B51] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6195; t=1251843282; x=1252707282; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20<jmpolk@cisco.com> |Subject:=20Re=3A=20[homegate]=20Homegate=20BoF=20@=20IETF= 2076?=20Then=20we=20need=20to=20narrow=0A=20=20our=20scope! |Sender:=20; bh=zrdpgPFpkf6G3Xp3PoI39AzDLBui575fBisOCAGQnoA=; b=a/e+br758Raqlma5os1razNuESyXrMYvvWYkfmjr13uZ4BvnqpWMG78M3m jq1zK/IOJxNPDqk/O1oxI4lEt+Anizk0D2jJh32khFSQdId9q9gcByBy/DQO iY0DDiBxCosnevsNanFhDTBE4bUW0B1R2kfDT68oiRtLlKFFfgMzs=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: homegate@ietf.org Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion <homegate.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/homegate>, <mailto:homegate-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/homegate> List-Post: <mailto:homegate@ietf.org> List-Help: <mailto:homegate-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/homegate>, <mailto:homegate-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 01 Sep 2009 22:14:31 -0000 in-line below At 04:00 PM 9/1/2009, Livingood, Jason wrote: >So the deadline for BoF requests for the=20 >upcoming meeting is rather early IMHO, set for 7=20 >September. I believe we had a great deal of=20 >interest in a BoF, based on the Bar BoF we had at IETF 75. > >However, I do believe that consensus indicated=20 >that our scope was rather too broad and should be narrowed substantially. > >Here=92s a quick stab at this. I=92d like a LOT of=20 >feedback please, to try to refine this. Don=92t=20 >take anything included or omitted as any kind of a statement at all. > >Regards >Jason > >IETF 76 BoF Proposal >Title: Broadband Home Gateway [HomeGate] BoF > >Proposed IETF Area: Transport > >Transport Area Directors: >Lars Eggert (<lars.eggert@nokia.htm>lars.eggert@nokia.com) >Magnus Westerlund=20 >(<magnus.westerlund@ericsson.htm>magnus.westerlund@ericsson.com) > >BoF Organizers: >Jason Livingood=20 >(<jason_livingood@cable.comcast.htm>jason_livingood@cable.comcast.com) >Dave Oran (<oran@cisco.htm>oran@cisco.com) > >Conflicts to Avoid: >First Priority: speermint alto ledbat drinks enum v6ops tsvwg dnsext dnsop >Second Priority: behave >BoFs: > >Expected Attendance: 25 - 50 people > >Special Requests: None > >Number of Sessions: 1 > >Length of Session: 2 hours > >Proposed Charter: >There are a large number of subscribers to=20 >broadband Internet services who use one form or=20 >another of networking technology within the home=20 >in order to share broadband access to the=20 >Internet among local users, provide various LAN=20 >services, and provide some basic level of=20 >security. The majority of Internet users employ=20 >=93home gateways=94 for this purpose (they are not purely =93routers=94). Jason - I suggest an alternate first paragraph=20 (as the existing 1st sentence wondered too much IMO), as follows: "Access to broadband Internet services use=20 networking technology of one form or another=20 within the home, small office/home office (SOHO)=20 or small to medium business (SMB) as the demarc=20 between the local network and the Internet. These=20 technologies almost always involve a single=20 entity - which is not purely a router - called a=20 "home gateway". This entity connects a local=20 user or users to various LAN services, providing=20 some basic level of security. The majority of=20 Internet users employ home gateways for this purpose." > >However, many serious, long-term problems face=20 >users of home gateways today. At the root of=20 >many of these problems is the fact that device=20 >manufacturers, and/or the organizations that=20 >specify requirements for such devices, are not=20 >certain which IETF standards and best current=20 >practices should be supported, and when/why that=20 >support is needed. As a result of this,=20 >millions of devices are being deployed every=20 >year, which do not work with important IETF=20 >protocols, standards, and best practices that=20 >are central to the future of the Internet. > >One of the problems in this area appears to be=20 >that home gateway vendors are unclear which RFCs=20 >are important, or current, and why they are=20 >important and in what context they matter. Thus,=20 >the primary objective of the group is document a=20 >baseline of =93core=94 RFCs/BCPs which must be=20 >supported, followed by some =93advanced=94 RFCs/BCPs=20 >which are to be considered optional. The=20 >context and reasoning behind each document which=20 >is included should be summarized as well, in=20 >order to improve comprehension of why a given=20 >document has been included. These things will=20 >help improve compatibilities with and=20 >capabilities for use of the Internet of=20 >today. This will include a focus in areas such=20 >as DNS proxy behavior, congestion mechanisms support, and security. > >A secondary problem is compatibility with and=20 >capability for the use of the Internet of=20 >tomorrow. New security needs related to DNS are=20 >motivating a move to DNSSEC. However, many if=20 >not most home gateways cannot handle DNSSEC,=20 >which is expected to be a major problem that=20 >could significantly impede the deployment of=20 >DNSSEC globally. Support for IPv6 is also=20 >lacking to a great degree and there is no clear=20 >understanding of how such devices should support IPv6. > >Proposed Deliverables: >The BoF/WG would work to improve the network=20 >experience that a SOHO / residential home user=20 >gets when using the Internet. This includes=20 >providing a tiered specification for what RFCs=20 >and BCPs should be supported, in what=20 >order/priority, and in what manner. This will touch on standards such as: >o IPv6 > >o DNSSEC RFCs and BCPs > >o ECN > >o RED (or other queue management) > >o DNS Proxy BCPs > >o Security-Related BCPs > >o Other TBD > >Contributors: ISPs and home gateway developers / vendors > >Proposed Agenda: (120 minutes) >1 =96 Agenda, Goals, and Administrivia /=20 >Chairs 5 minutes >2 =96 HomeGate Problem Statement=20 >Exploration 60 minutes > - Draft problem statement I-D /=20 > TBD 10 minutes > - Issues with DNSSEC, DNS Proxies /=20 > Ray Bellis 10 minutes > - IPv6 support issues / John=20 > Brzozowski 10 minutes > - ECN support issues /=20 > TBD=20 > 10 minutes > - Security issues /=20 > TBD=20 > 10 minutes > - Zero-Config issues / James=20 > Woodyatt? 10 minutes >3 =96 Discussion /=20 >All=20 >45 minutes >4 =96 Questions and Next Steps /=20 >Chairs 10= minutes > >_______________________________________________ >homegate mailing list >homegate@ietf.org >https://www.ietf.org/mailman/listinfo/homegate From carlberg@g11.org.uk Tue Sep 1 17:59:27 2009 Return-Path: <carlberg@g11.org.uk> X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20CF28C2D6 for <homegate@core3.amsl.com>; Tue, 1 Sep 2009 17:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, PLING_QUERY=1.39] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkQy5HEvS0O0 for <homegate@core3.amsl.com>; Tue, 1 Sep 2009 17:59:26 -0700 (PDT) Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 1120F28C904 for <homegate@ietf.org>; Tue, 1 Sep 2009 17:58:42 -0700 (PDT) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:49259 helo=[192.168.0.20]) by portland.eukhost.com with esmtpa (Exim 4.69) (envelope-from <carlberg@g11.org.uk>) id 1MieBI-00037D-8Q; Wed, 02 Sep 2009 00:58:36 +0000 Message-Id: <2CE9EAC8-2AFA-40C3-A95F-4AF000C816B9@g11.org.uk> From: ken carlberg <carlberg@g11.org.uk> To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com> In-Reply-To: <C6C3039C.11F1B%Jason_Livingood@cable.comcast.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1-815492260 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 1 Sep 2009 20:58:35 -0400 References: <C6C3039C.11F1B%Jason_Livingood@cable.comcast.com> X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk Cc: homegate@ietf.org Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion <homegate.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/homegate>, <mailto:homegate-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/homegate> List-Post: <mailto:homegate@ietf.org> List-Help: <mailto:homegate-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/homegate>, <mailto:homegate-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 02 Sep 2009 00:59:27 -0000 --Apple-Mail-1-815492260 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Sep 1, 2009, at 5:00 PM, Livingood, Jason wrote: > Proposed Deliverables: > The BoF/WG would work to improve the network experience that a > SOHO / residential home user gets when using the Internet. This > includes providing a tiered specification for what RFCs and BCPs > should be supported, in what order/priority, and in what manner. > This will touch on standards such as: > o IPv6 > > o DNSSEC RFCs and BCPs > > o ECN > > o RED (or other queue management) > > o DNS Proxy BCPs > > o Security-Related BCPs > > o Other TBD could you expand on what is meant by "will touch on standards"? One thing I thought that the participants in the BoF seemed to gravitate to was a simple requirements doc like what was produced ages ago in rfc-1812 and rfc-1123. If this is what you meant in the above excerpt, then its probably best to say so more explicitly. And while I appreciate interest expressed in the BoF for a more in-depth requirements document covering areas like VPNs, I'd prefer to keep that separate and sequential to a baseline requirements doc. -ken --Apple-Mail-1-815492260 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable <html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; "><br><div><div>On Sep 1, 2009, = at 5:00 PM, Livingood, Jason wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span = class=3D"Apple-style-span" style=3D"border-collapse: separate; color: = rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: = normal; font-variant: normal; font-weight: normal; letter-spacing: = normal; line-height: normal; orphans: 2; text-align: auto; text-indent: = 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: = 0px; -webkit-border-horizontal-spacing: 0px; = -webkit-border-vertical-spacing: 0px; = -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; "><span class=3D"Apple-style-span" = style=3D"font-family: 'Times New Roman'; font-size: 16px; "><b>Proposed = Deliverables</b>:<br>The BoF/WG would work to improve the network = experience that a SOHO / residential home user gets when using the = Internet.  This includes providing a tiered specification for what = RFCs and BCPs should be supported, in what order/priority, and in what = manner.  This will touch on standards such = as:</span></span></blockquote></div><div><br></div><blockquote = type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: = separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: = medium; font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; line-height: normal; orphans: 2; text-indent: = 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: = 0px; -webkit-border-horizontal-spacing: 0px; = -webkit-border-vertical-spacing: 0px; = -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; "><span style=3D"font-size: 12pt; = "><font face=3D"Courier New">o   </font><font face=3D"Times = New Roman">IPv6<br></font></span><font face=3D"Calibri, Verdana, = Helvetica, Arial"><span style=3D"font-size: 11pt; = "><br></span></font><font face=3D"Courier New"><span style=3D"font-size: = 12pt; ">o   </span></font><span style=3D"font-size: 12pt; = "><font face=3D"Times New Roman">DNSSEC RFCs and = BCPs<br></font></span><font face=3D"Calibri, Verdana, Helvetica, = Arial"><span style=3D"font-size: 11pt; "><br></span></font><font = face=3D"Courier New"><span style=3D"font-size: 12pt; ">o =   </span></font><span style=3D"font-size: 12pt; "><font = face=3D"Times New Roman">ECN<br></font></span><font face=3D"Calibri, = Verdana, Helvetica, Arial"><span style=3D"font-size: 11pt; = "><br></span></font><font face=3D"Courier New"><span style=3D"font-size: = 12pt; ">o   </span></font><span style=3D"font-size: 12pt; = "><font face=3D"Times New Roman">RED (or other queue = management)<br></font></span><font face=3D"Calibri, Verdana, Helvetica, = Arial"><span style=3D"font-size: 11pt; "><br></span></font><font = face=3D"Courier New"><span style=3D"font-size: 12pt; ">o =   </span></font><span style=3D"font-size: 12pt; "><font = face=3D"Times New Roman">DNS Proxy BCPs<br></font></span><font = face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size: = 11pt; "><br></span></font><font face=3D"Courier New"><span = style=3D"font-size: 12pt; ">o   </span></font><span = style=3D"font-size: 12pt; "><font face=3D"Times New = Roman">Security-Related BCPs<br></font></span><font face=3D"Calibri, = Verdana, Helvetica, Arial"><span style=3D"font-size: 11pt; = "><br></span></font><font face=3D"Courier New"><span style=3D"font-size: = 12pt; ">o   </span></font><span style=3D"font-size: 12pt; = "><font face=3D"Times New Roman">Other = TBD </font></span></span></blockquote><div><br></div><div>could you = expand on what is meant by "will touch on standards"? =  </div><div><br></div><div>One thing I thought that the = participants in the BoF seemed to gravitate to was a simple requirements = doc like what was produced ages ago in rfc-1812 and rfc-1123.  If = this is what you meant in the above excerpt, then its probably best to = say so more explicitly.  And while I appreciate interest expressed = in the BoF for a more in-depth requirements document covering areas like = VPNs, I'd prefer to keep that separate and sequential to a baseline = requirements = doc.</div><div><br></div><div>-ken</div><div><br></div></body></html>= --Apple-Mail-1-815492260-- From paul.hoffman@vpnc.org Tue Sep 1 19:03:14 2009 Return-Path: <paul.hoffman@vpnc.org> X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98BC3A68A5 for <homegate@core3.amsl.com>; Tue, 1 Sep 2009 19:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.423 X-Spam-Level: X-Spam-Status: No, score=-3.423 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xk+2Y4cS62ev for <homegate@core3.amsl.com>; Tue, 1 Sep 2009 19:03:14 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id F1BD23A6840 for <homegate@ietf.org>; Tue, 1 Sep 2009 19:03:13 -0700 (PDT) Received: from [75.101.18.87] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8220pVH048491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <homegate@ietf.org>; Tue, 1 Sep 2009 19:00:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: <p062408bdc6c37f8c0828@[75.101.18.87]> In-Reply-To: <2CE9EAC8-2AFA-40C3-A95F-4AF000C816B9@g11.org.uk> References: <C6C3039C.11F1B%Jason_Livingood@cable.comcast.com> <2CE9EAC8-2AFA-40C3-A95F-4AF000C816B9@g11.org.uk> Date: Tue, 1 Sep 2009 19:00:46 -0700 To: homegate@ietf.org From: Paul Hoffman <paul.hoffman@vpnc.org> Content-Type: text/html; charset="us-ascii" Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion <homegate.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/homegate>, <mailto:homegate-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/homegate> List-Post: <mailto:homegate@ietf.org> List-Help: <mailto:homegate-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/homegate>, <mailto:homegate-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 02 Sep 2009 02:03:14 -0000 <!doctype html public "-//W3C//DTD W3 HTML//EN"> <html><head><style type="text/css"><!-- blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 } --></style><title>Re: [homegate] Homegate BoF @ IETF 76? Then we need to nar
At 8:58 PM -0400 9/1/09, ken carlberg wrote:
On Sep 1, 2009, at 5:00 PM, Livingood, Jason wrote:

Proposed Deliverables:
The BoF/WG would work to improve the network experience that a SOHO / residential home user gets when using the Internet.  This includes providing a tiered specification for what RFCs and BCPs should be supported, in what order/priority, and in what manner.  This will touch on standards such as:

o   IPv6

o   DNSSEC RFCs and BCPs

o   ECN

o   RED (or other queue management)

o   DNS Proxy BCPs

o   Security-Related BCPs

o   Other TBD 

could you expand on what is meant by "will touch on standards"?

One thing I thought that the participants in the BoF seemed to gravitate to was a simple requirements doc like what was produced ages ago in rfc-1812 and rfc-1123.  If this is what you meant in the above excerpt, then its probably best to say so more explicitly.  And while I appreciate interest expressed in the BoF for a more in-depth requirements document covering areas like VPNs, I'd prefer to keep that separate and sequential to a baseline requirements doc.

Another way to factor the work would be a base document that *only* covered IPv4, IPv6, and DNS (including DNSSEC). Additional topic-specific docs could be added if there was agreement in the WG. I would not want to mention "DNS proxies BCPs" in the main doc: SOHO boxes really should rely on ISPs for DNS. "Security-related BCP" probably means "documenting stupid firewall tricks", and those may be hard to come to consensus on.

Thus, I would change the latter part of the BoF proposal to:

Proposed Deliverables:

The eventual WG's goal is to improve the network experience that a SOHO / residential home user gets when using the Internet. To do this, the WG will create one or more BCP-style documents aimed at home gateway vendors pointing to the RFCs that they should support, and pointing out specific areas where there are known problems today due to not including important features or mis-implementation of important features.

The first document to be produced by the WG would cover IPv4, IPv6, and DNS (including DNSSEC) and little else. The WG can add follow-on documents to the charter later after showing enough interest to write and review those documents. These additional documents might cover topics such as firewall best practices, ECN, RED, DNS proxies, and so on.

(As a side note, charters are plain-text, even in 2009.)

--Paul Hoffman, Director
--VPN Consortium
From jmpolk@cisco.com Tue Sep 1 20:36:49 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45C33A68D2 for ; Tue, 1 Sep 2009 20:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.814 X-Spam-Level: X-Spam-Status: No, score=-5.814 tagged_above=-999 required=5 tests=[AWL=-0.605, BAYES_00=-2.599, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5OnPTq3tTLu for ; Tue, 1 Sep 2009 20:36:48 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EC7C83A67E1 for ; Tue, 1 Sep 2009 20:36:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8GAP+EnUqrR7MV/2dsb2JhbACIVbk3iEEBkFIFhBuBXA X-IronPort-AV: E=Sophos;i="4.44,316,1249257600"; d="scan'208";a="380140596" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 02 Sep 2009 03:36:04 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n823a4s3013683; Tue, 1 Sep 2009 20:36:04 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n823a4nL012864; Wed, 2 Sep 2009 03:36:04 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 20:36:04 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.5.240]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 20:36:04 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 01 Sep 2009 22:36:02 -0500 To: Paul Hoffman , homegate@ietf.org From: "James M. Polk" In-Reply-To: References: <2CE9EAC8-2AFA-40C3-A95F-4AF000C816B9@g11.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Sep 2009 03:36:04.0081 (UTC) FILETIME=[7FA40610:01CA2B7E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3415; t=1251862565; x=1252726565; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[homegate]=20Homegate=20BoF=20@=20IETF= 2076?=20Then=20we=20need=20to=20narrow=0A=20=20our=20scope! |Sender:=20; bh=G4V+Tlgffgb3yE2ekI46C/pxoJoigiutndD8jYo/rk0=; b=RVau4HeEjL9Sbz/2vvj35H+nkc03SpRi7JtuBw8Dakh8Af+meo6N21q31T zVB/M0cA3Kp7aaM8jGHyW60OQ3zb+xLn97LZsvvevWzwpXTPgGNZvJEpIt0o ykC9kMqaximlWU65sQo5VgCiNAO56zcjsMWSELWS2Cdp1d8eUyyWI=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 03:36:50 -0000 At 09:00 PM 9/1/2009, Paul Hoffman wrote: >At 8:58 PM -0400 9/1/09, ken carlberg wrote: >>On Sep 1, 2009, at 5:00 PM, Livingood, Jason wrote: >> >>>Proposed Deliverables: >>>The BoF/WG would work to improve the network experience that a >>>SOHO / residential home user gets when using the Internet. This >>>includes providing a tiered specification for what RFCs and BCPs >>>should be supported, in what order/priority, and in what >>>manner. This will touch on standards such as: >> >>>o IPv6 >>> >>>o DNSSEC RFCs and BCPs >>> >>>o ECN >>> >>>o RED (or other queue management) >>> >>>o DNS Proxy BCPs >>> >>>o Security-Related BCPs >>> >>>o Other TBD >> >>could you expand on what is meant by "will touch on standards"? >> >>One thing I thought that the participants in the BoF seemed to >>gravitate to was a simple requirements doc like what was produced >>ages ago in rfc-1812 and rfc-1123. If this is what you meant in >>the above excerpt, then its probably best to say so more >>explicitly. And while I appreciate interest expressed in the BoF >>for a more in-depth requirements document covering areas like VPNs, >>I'd prefer to keep that separate and sequential to a baseline requirements doc. > >Another way to factor the work would be a base document that *only* >covered IPv4, IPv6, and DNS (including DNSSEC). Additional >topic-specific docs could be added if there was agreement in the WG. >I would not want to mention "DNS proxies BCPs" in the main doc: SOHO >boxes really should rely on ISPs for DNS. "Security-related BCP" >probably means "documenting stupid firewall tricks", and those may >be hard to come to consensus on. > >Thus, I would change the latter part of the BoF proposal to: > >Proposed Deliverables: > >The eventual WG's goal is to improve the network experience that a >SOHO / residential home user gets when using the Internet. To do >this, the WG will create one or more BCP-style documents aimed at >home gateway vendors pointing to the RFCs that they should support, >and pointing out specific areas where there are known problems today >due to not including important features or mis-implementation of >important features. > >The first document to be produced by the WG would cover IPv4, IPv6, >and DNS (including DNSSEC) and little else. The WG can add follow-on >documents to the charter later after showing enough interest to >write and review those documents. These additional documents might >cover topics such as firewall best practices, ECN, RED, DNS proxies, and so on. While I'm not sold on the idea of v4, v6 and DNS *only* in the first doc (I think firewall best practices should be in here, as well as what not to break that is already standardized (i.e., ECN)), I firmly believe the charter should state that this group will *not* produce standards track documents, as that is left for the specific WGs that are chartered to work on those protocols in the standards track effort. I think this needs to be explicit in the charter. BCPs should be the strongest status of doc from this group. >(As a side note, charters are plain-text, even in 2009.) > >--Paul Hoffman, Director >--VPN Consortium >_______________________________________________ >homegate mailing list >homegate@ietf.org >https://www.ietf.org/mailman/listinfo/homegate From Ray.Bellis@nominet.org.uk Wed Sep 2 02:09:06 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 112EC3A68DE for ; Wed, 2 Sep 2009 02:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRTsE6YHRxDP for ; Wed, 2 Sep 2009 02:09:05 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 7F57728C55D for ; Wed, 2 Sep 2009 02:06:53 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:To:Subject:MIME-Version:X-Mailer: Message-ID:From:Date:X-MIMETrack:Content-Type; b=w762Gr2Pf6R7v0Xp3SwWkPhCcof4zTMN9X+eo5jy1O02NbHsf5j5r5Qz /7VbD+YSowQAOIL0YUvZe5AX3Ic4bmzBmjdrIDNr2CqbpciO/xVz3kTsV us8DgHirocWdqRo; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1251882429; x=1283418429; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20RFC=205625 =20published|Date:=20Wed,=202=20Sep=202009=2010:05:57=20+ 0100|Message-ID:=20|To:=20homegate@ietf. org|MIME-Version:=201.0; bh=UZp5Rg2zoMTu0084COfhz2rq8qs+N53KQnYMrb5zhqU=; b=yWaLH8JEJ21ETh8mWlUkhlLEdaHGpRaqq1WU8kCMZB8zvL1GHyemN3qu CvNZLTAaWbgmjTseIMtbvkHL7u/6TQiogcijfbeeSK7ZJOG8GOEcLdLZK 5u6Gd+D0to9GAhb; X-IronPort-AV: E=Sophos;i="4.44,317,1249254000"; d="scan'208";a="17263733" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 02 Sep 2009 10:05:59 +0100 To: homegate@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 2 Sep 2009 10:05:57 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 02/09/2009 10:05:59 AM, Serialize complete at 02/09/2009 10:05:59 AM Content-Type: multipart/alternative; boundary="=_alternative 0031FBC280257625_=" Subject: [homegate] RFC 5625 published X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 09:09:06 -0000 This is a multipart message in MIME format. --=_alternative 0031FBC280257625_= Content-Type: text/plain; charset="US-ASCII" For those not following DNSEXT, my draft relating to DNS proxies (as found in home gateways) and their broken-ness has now been published as RFC 5625: http://tools.ietf.org/html/rfc5625 Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 0031FBC280257625_= Content-Type: text/html; charset="US-ASCII" For those not following DNSEXT, my draft relating to DNS proxies (as found in home gateways) and their broken-ness has now been published as RFC 5625:

  http://tools.ietf.org/html/rfc5625

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211


 --=_alternative 0031FBC280257625_=-- From paul.hoffman@vpnc.org Wed Sep 2 09:13:49 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2C5528C15A for ; Wed, 2 Sep 2009 09:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.147 X-Spam-Level: X-Spam-Status: No, score=-4.147 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND7Bys0SxFJc for ; Wed, 2 Sep 2009 09:13:48 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id C740C28C136 for ; Wed, 2 Sep 2009 09:13:47 -0700 (PDT) Received: from [75.101.18.87] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n82GCX9p018020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2009 09:12:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <2CE9EAC8-2AFA-40C3-A95F-4AF000C816B9@g11.org.uk> Date: Wed, 2 Sep 2009 09:11:55 -0700 To: "James M. Polk" , homegate@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 16:13:49 -0000 At 10:36 PM -0500 9/1/09, James M. Polk wrote: >At 09:00 PM 9/1/2009, Paul Hoffman wrote: >While I'm not sold on the idea of v4, v6 and DNS *only* in the first doc (I think firewall best practices should be in here, as well as what not to break that is already standardized (i.e., ECN)), Let's tease those two things out a bit. I believe both are way more controversial than you would hope. Firewall best practices are mostly about allowing users to block/allow certain ports and applications. Ports are easy, applications are difficult. There is a *huge* difference between port filtering and application sniffing. Without application sniffing, the actual security offered is much worse. So, for home and SOHO routers, do we say "here's how to offer worse security" or "you need to offer good security, which is much more than most of the devices do today"? I propose that there will strong opinions on both sides. "Do not break standardized things" sounds good, but the question is whether it is easy. That is, how much packet inspection and follow-up processing is needed to not break each feature? And what is our list of features? ECN seems obvious, but it is barely seen in the wild due to chicken-and-egg problems. Would SIP be on that list? IKE? IKEv2? > I firmly believe the charter should state that this group will *not* produce standards track documents, as that is left for the specific WGs that are chartered to work on those protocols in the standards track effort. I think this needs to be explicit in the charter. BCPs should be the strongest status of doc from this group. This is a common misconception. BCPs *are* essentially standards track documents; see RFC 2026. You probably meant that the WG would not produce documents introduce new protocols or change existing protocols. On that, I think there is widespread agreement. --Paul Hoffman, Director --VPN Consortium From jmpolk@cisco.com Wed Sep 2 10:36:29 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D270D3A70E5 for ; Wed, 2 Sep 2009 10:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.802 X-Spam-Level: X-Spam-Status: No, score=-5.802 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeuLDbCNckJl for ; Wed, 2 Sep 2009 10:36:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3633E3A6D1A for ; Wed, 2 Sep 2009 10:36:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroGAGdJnkqrR7MV/2dsb2JhbACIVbp+iEEBkFgFhBuBXA X-IronPort-AV: E=Sophos;i="4.44,319,1249257600"; d="scan'208";a="236449964" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 02 Sep 2009 17:35:24 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n82HZOlF030149; Wed, 2 Sep 2009 10:35:24 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n82HZOsS027809; Wed, 2 Sep 2009 17:35:24 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 10:35:24 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.2.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 10:35:23 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 02 Sep 2009 12:35:22 -0500 To: Paul Hoffman , homegate@ietf.org From: "James M. Polk" In-Reply-To: References: <2CE9EAC8-2AFA-40C3-A95F-4AF000C816B9@g11.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Sep 2009 17:35:23.0727 (UTC) FILETIME=[C0542DF0:01CA2BF3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3748; t=1251912924; x=1252776924; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[homegate]=20Homegate=20BoF=20@=20IETF= 2076?=20Then=20we=20need=20to=20narrow=0A=20=20our=20scope! |Sender:=20; bh=90kF4UNOz2md1CBfQsavo51ILFjO6D52dwiMZDStMzM=; b=bpJg9XSuJf91AgJBohdfxlRKVHdmscIrzWJF8D7QYwvqpNxfS2LxD3nJ0f 2Js7NWFtb9oJ0LkosESdv7Dbeh+4W7mQjRrD8cNxVxXOEIy691QT+MBlPugW 5Fz5uHa82CzSwNvqUSXggeHtEXK19Z+2PVY6fE2myI+Yq4Xd8MG/k=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 17:36:29 -0000 At 11:11 AM 9/2/2009, Paul Hoffman wrote: >At 10:36 PM -0500 9/1/09, James M. Polk wrote: > >At 09:00 PM 9/1/2009, Paul Hoffman wrote: > >While I'm not sold on the idea of v4, v6 and DNS *only* in the > first doc (I think firewall best practices should be in here, as > well as what not to break that is already standardized (i.e., ECN)), > >Let's tease those two things out a bit. I believe both are way more >controversial than you would hope. > >Firewall best practices are mostly about allowing users to >block/allow certain ports and applications. Ports are easy, >applications are difficult. There is a *huge* difference between >port filtering and application sniffing. Without application >sniffing, the actual security offered is much worse. So, for home >and SOHO routers, do we say "here's how to offer worse security" or >"you need to offer good security, which is much more than most of >the devices do today"? I propose that there will strong opinions on both sides. I don't understand why this group doesn't do the latter of your two quotes. "...which is much more than most of the devices do today..." is what Homegate is all about, isn't it? I mean, look at the proposed charter and tell me where this mindset is inconsistent...? >"Do not break standardized things" sounds good, but the question is >whether it is easy. That is, how much packet inspection and >follow-up processing is needed to not break each feature? And what >is our list of features? ECN seems obvious, but it is barely seen in >the wild due to chicken-and-egg problems. Would SIP be on that list? >IKE? IKEv2? This is exactly what I believe the group ought to discuss, and not decide day -50 of the WG forming. I agree with the minimum goal of starting with v4, v6 and DNS -- but adding to the list as the group thinks it can accomplish the next protocol or function to be specified, then the next, then the next, to the point that the group believes "now we have a critical mass of minimum *things* included, we'll run with this list in our first doc". You're right, ECN seems obvious. I don't know what is the next one is, or the one after that. I know I have my list of preferences, and I believe I have to justify each one to this group to gain agreement that each should be included (right?). > > I firmly believe the charter should state that this group will > *not* produce standards track documents, as that is left for the > specific WGs that are chartered to work on those protocols in the > standards track effort. I think this needs to be explicit in the > charter. BCPs should be the strongest status of doc from this group. > >This is a common misconception. you misunderstand... >BCPs *are* essentially standards track documents; see RFC 2026. I've always believed BCPs are "one shot" standards, and not "standards track" (the latter meaning there are more than one standards level within the "track" - such as PS, DS and FS). This differentiation has always been clear in all the WGs I've written IDs into (I think 11 so far), as well as TSVWG that I chair. >You probably meant that the WG would not produce documents introduce >new protocols or change existing protocols. not producing any PS, DS or FS RFC, yes - this group should not. >On that, I think there is widespread agreement. but I don't see that in the charter, and it would greatly help prevent the future wonderer - who might be new to the group with legitimate intentions of contributing their energy that might not see this in the current charter text that would greatly benefit if it were there. >--Paul Hoffman, Director >--VPN Consortium From paul.hoffman@vpnc.org Wed Sep 2 16:49:57 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 285B83A69DA for ; Wed, 2 Sep 2009 16:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.18 X-Spam-Level: X-Spam-Status: No, score=-4.18 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVwzIwrj2O+Q for ; Wed, 2 Sep 2009 16:49:56 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 3C1ED3A63EC for ; Wed, 2 Sep 2009 16:49:56 -0700 (PDT) Received: from [75.101.18.87] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n82NfkLn046035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2009 16:41:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <2CE9EAC8-2AFA-40C3-A95F-4AF000C816B9@g11.org.uk> Date: Wed, 2 Sep 2009 16:41:45 -0700 To: "James M. Polk" , homegate@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 23:49:57 -0000 At 12:35 PM -0500 9/2/09, James M. Polk wrote: >At 11:11 AM 9/2/2009, Paul Hoffman wrote: >>At 10:36 PM -0500 9/1/09, James M. Polk wrote: >>>At 09:00 PM 9/1/2009, Paul Hoffman wrote: >>>While I'm not sold on the idea of v4, v6 and DNS *only* in the first doc (I think firewall best practices should be in here, as well as what not to break that is already standardized (i.e., ECN)), >> >>Let's tease those two things out a bit. I believe both are way more controversial than you would hope. >> >>Firewall best practices are mostly about allowing users to block/allow certain ports and applications. Ports are easy, applications are difficult. There is a *huge* difference between port filtering and application sniffing. Without application sniffing, the actual security offered is much worse. So, for home and SOHO routers, do we say "here's how to offer worse security" or "you need to offer good security, which is much more than most of the devices do today"? I propose that there will strong opinions on both sides. > >I don't understand why this group doesn't do the latter of your two quotes. "...which is much more than most of the devices do today..." is what Homegate is all about, isn't it? I mean, look at the proposed charter and tell me where this mindset is inconsistent...? Three likely reasons: - Application sniffing is much more CPU-intensive than port blocking - It also takes much more expensive programming for these cheap devices - Getting rough consensus in an IETF WG about how to block application protocols could be really really hard >>"Do not break standardized things" sounds good, but the question is whether it is easy. That is, how much packet inspection and follow-up processing is needed to not break each feature? And what is our list of features? ECN seems obvious, but it is barely seen in the wild due to chicken-and-egg problems. Would SIP be on that list? IKE? IKEv2? > >This is exactly what I believe the group ought to discuss, and not decide day -50 of the WG forming. I agree with the minimum goal of starting with v4, v6 and DNS -- but adding to the list as the group thinks it can accomplish the next protocol or function to be specified, then the next, then the next, to the point that the group believes "now we have a critical mass of minimum *things* included, we'll run with this list in our first doc". OK, maybe I was being too cautious. If we can get an early list of standardized things that we are willing to work on at the BoF, there is no reason not to put them in the initial WG charter. >You're right, ECN seems obvious. I don't know what is the next one is, or the one after that. I know I have my list of preferences, and I believe I have to justify each one to this group to gain agreement that each should be included (right?). Right, we could do a laundry list request, not for discussion immediately, but to find if there is enough juiced to work on them. >>On that, I think there is widespread agreement. > >but I don't see that in the charter, and it would greatly help prevent the future wonderer - who might be new to the group with legitimate intentions of contributing their energy that might not see this in the current charter text that would greatly benefit if it were there. Ah, good point. I would definitely support putting that in the charter. --Paul Hoffman, Director --VPN Consortium From jmpolk@cisco.com Wed Sep 2 23:44:25 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06F763A6781 for ; Wed, 2 Sep 2009 23:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.793 X-Spam-Level: X-Spam-Status: No, score=-5.793 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuzYwecICyrx for ; Wed, 2 Sep 2009 23:44:24 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 1C53F3A67A1 for ; Wed, 2 Sep 2009 23:44:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEGAJ8Bn0qrR7PE/2dsb2JhbACIVbhriEEBkDMFhBuBXA X-IronPort-AV: E=Sophos;i="4.44,324,1249257600"; d="scan'208";a="201364042" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 03 Sep 2009 06:40:05 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n836e54X032536; Wed, 2 Sep 2009 23:40:05 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n836e5Kh028141; Thu, 3 Sep 2009 06:40:05 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 23:40:05 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.2.119]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 23:40:04 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 03 Sep 2009 01:40:01 -0500 To: Paul Hoffman , homegate@ietf.org From: "James M. Polk" In-Reply-To: References: <2CE9EAC8-2AFA-40C3-A95F-4AF000C816B9@g11.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 03 Sep 2009 06:40:04.0561 (UTC) FILETIME=[5EB15410:01CA2C61] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2011; t=1251960005; x=1252824005; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[homegate]=20Homegate=20BoF=20@=20IETF= 2076?=20Then=20we=20need=20to=20narrow=0A=20=20our=20scope! |Sender:=20; bh=gO5BdPpQmUPKZCQqRXPSp/wSq+9qF5i6V8mzQAPqCVY=; b=MH02jAf02VKHMM8yXU4wIPgqXU7EFZMTiw7lppISYQEOS0NY/Qxh/XnOUO 6tgXzw0zd+92G3UTCNuCtqtStUXcX43h1MjgFIdkqJbKCeihZxncg/VrlIXR bw09KfoWgj; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 06:44:25 -0000 At 06:41 PM 9/2/2009, Paul Hoffman wrote: > >>"Do not break standardized things" sounds good, but the question > is whether it is easy. That is, how much packet inspection and > follow-up processing is needed to not break each feature? And what > is our list of features? ECN seems obvious, but it is barely seen > in the wild due to chicken-and-egg problems. Would SIP be on that > list? IKE? IKEv2? > > > >This is exactly what I believe the group ought to discuss, and not > decide day -50 of the WG forming. I agree with the minimum goal of > starting with v4, v6 and DNS -- but adding to the list as the group > thinks it can accomplish the next protocol or function to be > specified, then the next, then the next, to the point that the > group believes "now we have a critical mass of minimum *things* > included, we'll run with this list in our first doc". > >OK, maybe I was being too cautious. If we can get an early list of >standardized things that we are willing to work on at the BoF, there >is no reason not to put them in the initial WG charter. > > >You're right, ECN seems obvious. I don't know what is the next one > is, or the one after that. I know I have my list of preferences, > and I believe I have to justify each one to this group to gain > agreement that each should be included (right?). > >Right, we could do a laundry list request, not for discussion >immediately, but to find if there is enough juiced to work on them. > > >>On that, I think there is widespread agreement. > > > >but I don't see that in the charter, and it would greatly help > prevent the future wonderer - who might be new to the group with > legitimate intentions of contributing their energy that might not > see this in the current charter text that would greatly benefit if > it were there. > >Ah, good point. I would definitely support putting that in the charter. cool, at least we two agree. >--Paul Hoffman, Director >--VPN Consortium From jason_livingood@cable.comcast.com Thu Sep 3 08:18:21 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129813A6C16 for ; Thu, 3 Sep 2009 08:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, PLING_QUERY=1.39, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWbATIfFnroE for ; Thu, 3 Sep 2009 08:18:19 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 948903A6BF2 for ; Thu, 3 Sep 2009 08:18:19 -0700 (PDT) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.52212779; Thu, 03 Sep 2009 11:15:39 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 11:15:40 -0400 Received: from 69.249.204.17 ([69.249.204.17]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Sep 2009 15:15:39 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 03 Sep 2009 11:15:35 -0400 From: "Livingood, Jason" To: "James M. Polk" Message-ID: Thread-Topic: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! Thread-Index: AcosqWKrJUG/IKPxd0mXPjvrwJxXmw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 03 Sep 2009 15:15:40.0780 (UTC) FILETIME=[661DBAC0:01CA2CA9] Cc: homegate@ietf.org Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 15:18:21 -0000 Excellent improvement, incorporated into my latest version (sending soon)! On 9/1/09 6:14 PM, "James M. Polk" wrote: > in-line below >=20 > At 04:00 PM 9/1/2009, Livingood, Jason wrote: >> So the deadline for BoF requests for the >> upcoming meeting is rather early IMHO, set for 7 >> September. I believe we had a great deal of >> interest in a BoF, based on the Bar BoF we had at IETF 75. >>=20 >> However, I do believe that consensus indicated >> that our scope was rather too broad and should be narrowed substantially= . >>=20 >> Here=B9s a quick stab at this. I=B9d like a LOT of >> feedback please, to try to refine this. Don=B9t >> take anything included or omitted as any kind of a statement at all. >>=20 >> Regards >> Jason >>=20 >> IETF 76 BoF Proposal >> Title: Broadband Home Gateway [HomeGate] BoF >>=20 >> Proposed IETF Area: Transport >>=20 >> Transport Area Directors: >> Lars Eggert (lars.eggert@nokia.com) >> Magnus Westerlund >> (magnus.westerlund@ericsson.com) >>=20 >> BoF Organizers: >> Jason Livingood=20 >> (jason_livingood@cable.comcast.com) >> Dave Oran (oran@cisco.com) >>=20 >> Conflicts to Avoid: >> First Priority: speermint alto ledbat drinks enum v6ops tsvwg dnsext dns= op >> Second Priority: behave >> BoFs: >>=20 >> Expected Attendance: 25 - 50 people >>=20 >> Special Requests: None >>=20 >> Number of Sessions: 1 >>=20 >> Length of Session: 2 hours >>=20 >> Proposed Charter: >> There are a large number of subscribers to >> broadband Internet services who use one form or >> another of networking technology within the home >> in order to share broadband access to the >> Internet among local users, provide various LAN >> services, and provide some basic level of >> security. The majority of Internet users employ >> =B3home gateways=B2 for this purpose (they are not purely =B3routers=B2). >=20 > Jason - I suggest an alternate first paragraph > (as the existing 1st sentence wondered too much IMO), as follows: >=20 > "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 demarc > 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." >=20 >>=20 >> 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. >>=20 >> 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 =B3core=B2 RFCs/BCPs which must be >> supported, followed by some =B3advanced=B2 RFCs/BCPs >> which are to be considered optional. 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. >>=20 >> 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. >>=20 >> Proposed Deliverables: >> The BoF/WG would work to improve the network >> experience that a SOHO / residential home user >> gets when using the Internet. This includes >> providing a tiered specification for what RFCs >> and BCPs should be supported, in what >> order/priority, and in what manner. This will touch on standards such a= s: >> o IPv6 >>=20 >> o DNSSEC RFCs and BCPs >>=20 >> o ECN >>=20 >> o RED (or other queue management) >>=20 >> o DNS Proxy BCPs >>=20 >> o Security-Related BCPs >>=20 >> o Other TBD >>=20 >> Contributors: ISPs and home gateway developers / vendors >>=20 >> Proposed Agenda: (120 minutes) >> 1 =AD Agenda, Goals, and Administrivia / >> Chairs 5 minutes >> 2 =AD HomeGate Problem Statement >> Exploration 60 minutes >> - Draft problem statement I-D / >> TBD 10 minutes >> - Issues with DNSSEC, DNS Proxies / >> Ray Bellis 10 minutes >> - IPv6 support issues / John >> Brzozowski 10 minutes >> - ECN support issues / >> TBD=20 >> 10 minutes >> - Security issues / >> TBD=20 >> 10 minutes >> - Zero-Config issues / James >> Woodyatt? 10 minutes >> 3 =AD Discussion / >> All=20 >> 45 minutes >> 4 =AD Questions and Next Steps / >> Chairs 10 min= utes >>=20 >> _______________________________________________ >> homegate mailing list >> homegate@ietf.org >> https://www.ietf.org/mailman/listinfo/homegate >=20 Regards, Jason =20 Jason Livingood Executive Director Internet Systems Engineering National Engineering & Technical Operations Comcast Cable Communications 215-286-7813 jason_livingood@cable.comcast.com=20 From jason_livingood@cable.comcast.com Thu Sep 3 08:23:23 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580103A6D94 for ; Thu, 3 Sep 2009 08:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.549 X-Spam-Level: X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, PLING_QUERY=1.39, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cItAC42sDsaZ for ; Thu, 3 Sep 2009 08:23:22 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 5166D3A6D62 for ; Thu, 3 Sep 2009 08:23:22 -0700 (PDT) Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.52213937; Thu, 03 Sep 2009 11:20:55 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 11:20:56 -0400 Received: from 69.249.204.17 ([69.249.204.17]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Sep 2009 15:20:55 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 03 Sep 2009 11:20:54 -0400 From: "Livingood, Jason" To: "James M. Polk" , Paul Hoffman , Message-ID: Thread-Topic: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! Thread-Index: AcosqiDPZw74w/YbS0K9CoFjrI/tng== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Sep 2009 15:20:56.0246 (UTC) FILETIME=[22260560:01CA2CAA] Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 15:23:23 -0000 I understand Paul's desire to constrain the problem space. But I tend to agree with James that IPv4 and v6 and DNS may not be enough. Here's a proposed addition to the charter to try to make it clear that new protocol work is not the aim: "This working group will not develop new or extend existing Internet protocols. Should any such need develop, the chairs will refer the work to another working group that is chartered to focus on the relevant problem." Jason On 9/1/09 11:36 PM, "James M. Polk" wrote: >> The first document to be produced by the WG would cover IPv4, IPv6, >> and DNS (including DNSSEC) and little else. The WG can add follow-on >> documents to the charter later after showing enough interest to >> write and review those documents. These additional documents might >> cover topics such as firewall best practices, ECN, RED, DNS proxies, and so >> on. > > While I'm not sold on the idea of v4, v6 and DNS *only* in the first > doc (I think firewall best practices should be in here, as well as > what not to break that is already standardized (i.e., ECN)), I firmly > believe the charter should state that this group will *not* produce > standards track documents, as that is left for the specific WGs that > are chartered to work on those protocols in the standards track > effort. I think this needs to be explicit in the charter. BCPs should > be the strongest status of doc from this group. From jason_livingood@cable.comcast.com Thu Sep 3 08:25:46 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3B773A6D94 for ; Thu, 3 Sep 2009 08:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[AWL=-3.771, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, PLING_QUERY=1.39, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtNNSKWQU+PJ for ; Thu, 3 Sep 2009 08:25:46 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id F21973A6D8C for ; Thu, 3 Sep 2009 08:25:45 -0700 (PDT) Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.78184494; Thu, 03 Sep 2009 11:24:00 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 11:24:00 -0400 Received: from 69.249.204.17 ([69.249.204.17]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Sep 2009 15:24:00 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 03 Sep 2009 11:23:57 -0400 From: "Livingood, Jason" To: Paul Hoffman , "James M. Polk" , Message-ID: Thread-Topic: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! Thread-Index: Acosqo3iDYFE/hDggkyrEHtfDkDtsw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Sep 2009 15:24:00.0875 (UTC) FILETIME=[90322BB0:01CA2CAA] Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 15:25:46 -0000 > This is a common misconception. BCPs *are* essentially standards track > documents; see RFC 2026. You probably meant that the WG would not produce > documents introduce new protocols or change existing protocols. On that, I > think there is widespread agreement. Precisely why I didn't say "standards track" in this below. The important thing is to steer clear of things like developing protocols. That is much better left to other WGs. "This working group will not develop new or extend existing Internet protocols. Should any such need develop, the chairs will refer the work to another working group that is chartered to focus on the relevant problem." JL From jason_livingood@cable.comcast.com Thu Sep 3 08:31:24 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F04333A6D8C for ; Thu, 3 Sep 2009 08:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.664 X-Spam-Level: X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, PLING_QUERY=1.39, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brPJRcSDdUX9 for ; Thu, 3 Sep 2009 08:31:17 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 5B59728C1ED for ; Thu, 3 Sep 2009 08:31:17 -0700 (PDT) Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.52215720; Thu, 03 Sep 2009 11:29:44 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 11:29:45 -0400 Received: from 69.249.204.17 ([69.249.204.17]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Sep 2009 15:29:44 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 03 Sep 2009 11:29:42 -0400 From: "Livingood, Jason" To: Message-ID: Thread-Topic: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! Thread-Index: AcorRzJMcBoLX+wtBk+JIgSW5sc65wBZCk6z In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3334822183_207891" X-OriginalArrivalTime: 03 Sep 2009 15:29:45.0154 (UTC) FILETIME=[5D66FA20:01CA2CAB] Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 15:31:25 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3334822183_207891 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Here is the latest version. Feedback welcome, as always. Take a look at the priorities as well. I have coded the changes in BLUE. Proposed Charter: Access to broadband Internet services use networking technology of one form or another=20 within the home, small office/home office (SOHO) or small to medium busines= s (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. =20 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 no= t 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 IET= F protocols, standards, and best practices that are central to the future of the Internet.=20 =20 One of the problems in this area appears to be that home gateway vendors ar= e unclear which RFCs are important, or current, and why they are important an= d in what context they matter. Thus, the primary objective of the group is document a baseline of =B3core=B2 RFCs/BCPs which must be supported, followed b= y some =B3advanced=B2 RFCs/BCPs which are to be considered optional. The context and reasoning behind each document which is included should be summarized a= s 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 i= n areas such as DNS proxy behavior, congestion mechanisms support, and security.=20 =20 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. =20 This working group will not develop new or extend existing Internet protocols. Should any such need develop, the chairs will refer the work to another working group that is chartered to focus on the relevant problem. =20 Proposed Deliverables and Priorities: The BoF/WG would work to improve the network experience that a SOHO / residential home user gets when using the Internet. This includes providin= g a tiered specification for what RFCs and BCPs should be supported, in what order/priority, and in what manner. This will touch on standards such as: o IPv6 o DNSSEC RFCs and BCPs o ECN o RED (or other queue management) o DNS Proxy BCPs o Security-Related BCPs o Other TBD =20 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 On 9/1/09 5:00 PM, "Jason Livingood" wrote: > So the deadline for BoF requests for the upcoming meeting is rather early > IMHO, set for 7 September. I believe we had a great deal of interest in = a > BoF, based on the Bar BoF we had at IETF 75. >=20 > However, I do believe that consensus indicated that our scope was rather = too > broad and should be narrowed substantially. >=20 > Here=B9s a quick stab at this. I=B9d like a LOT of feedback please, to try t= o > refine this. Don=B9t take anything included or omitted as any kind of a > statement at all. >=20 > Regards > Jason --B_3334822183_207891 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our sc= ope! Here is the latest version.  Feedback welcome, as always.  Take = a look at the priorities as well.  I have coded the changes in BLUE.

= 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 busines= s (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 loc= al user or users to various LAN services, providing some basic level of secu= rity.  The majority of Internet users employ home gateways for this pur= pose.
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 manufa= cturers, 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, m= illions of devices are being deployed every year, which do not work with imp= ortant 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 vendor= s are unclear which RFCs are important, or current, and why they are importa= nt and in what context they matter. Thus, the primary objective of the group= is document a baseline of “core” RFCs/BCPs which must be suppor= ted, followed by some “advanced” RFCs/BCPs which are to be consi= dered optional.  The context and reasoning behind each document which i= s included should be summarized as well, in order to improve comprehension o= f why a given document has been included.  These things will help impro= ve compatibilities with and capabilities for use of the Internet of today= .  This will include a focus in areas such as DNS proxy behavior, c= ongestion mechanisms support, and security.
 
A secondary problem is compatibility with and capability for the use of the= Internet of tomorrow.  New security needs related to DNS are mo= tivating a move to DNSSEC.  However, many if not most home gateways can= not handle DNSSEC, which is expected to be a major problem that could signif= icantly impede the deployment of DNSSEC globally. Support for IPv6 is also l= acking to a great degree and there is no clear understanding of how such dev= ices should support IPv6.
 
This working group will not develop new or extend exi= sting Internet protocols.  Should any such need develop, the chairs wil= l refer the work to another working group that is chartered to focus on the = relevant problem.
Proposed Deliverables and Priorities:
The BoF/WG would work to improve the network experience that a SOHO / resid= ential home user gets when using the Internet.  This includes providing= a tiered specification for what RFCs and BCPs should be supported, in what = order/priority, and in what manner. This will touch on standards such as: o  = ; IPv6

o  = ; DNSSEC RFCs and BCPs

o  = ; ECN

o  = ; RED (or other queue management)

o  = ; DNS Proxy BCPs

o  = ; Security-Related BCPs

o  = ; Other TBD

 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





On 9/1/09 5:00 PM, "Jason Livingood" <jason_livingood@cable.comcast.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>So the deadline for BoF requests for the upcomin= g meeting is rather early IMHO, set for 7 September.  I believe we had = a great deal of interest in a BoF, based on the Bar BoF we had at IETF 75. &= nbsp;

However, I do believe that consensus indicated that our scope was rather= too broad and should be narrowed substantially.

Here’s a quick stab at this.  I’d like a LOT of feedba= ck please, to try to refine this.  Don’t take anything included o= r omitted as any kind of a statement at all.

Regards
Jason
--B_3334822183_207891-- From jason.weil@cox.com Thu Sep 3 09:44:03 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 885A23A6838 for ; Thu, 3 Sep 2009 09:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.746 X-Spam-Level: X-Spam-Status: No, score=-2.746 tagged_above=-999 required=5 tests=[AWL=-0.853, BAYES_00=-2.599, HTML_MESSAGE=0.001, PLING_QUERY=1.39, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ffa9uWrVAcNF for ; Thu, 3 Sep 2009 09:43:57 -0700 (PDT) Received: from cox.com (post1.cox.com [24.248.74.35]) by core3.amsl.com (Postfix) with ESMTP id A2B3A3A6872 for ; Thu, 3 Sep 2009 09:41:56 -0700 (PDT) Received: from ([192.168.74.254]) by post1.cox.com with ESMTP with TLS id 5502276.145698720; Thu, 03 Sep 2009 12:13:17 -0400 Received: from CATL0MS112.corp.cox.com ([169.254.1.132]) by CATL0MS404.corp.cox.com ([10.62.236.93]) with mapi; Thu, 3 Sep 2009 12:13:17 -0400 From: To: , Date: Thu, 3 Sep 2009 12:13:16 -0400 Thread-Topic: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! Thread-Index: AcorRzJMcBoLX+wtBk+JIgSW5sc65wBZCk6zAAEE3jA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C1920346B731FE48822877D74F28C8A307A2D15C59CATL0MS112cor_" MIME-Version: 1.0 Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 16:44:03 -0000 --_000_C1920346B731FE48822877D74F28C8A307A2D15C59CATL0MS112cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would recommend striking the phrase or small to medium business (SMB) fro= m the proposed charter. Extending beyond the SOHO to the the SMB drasticall= y increases the number of possible network topologies. This seems to imply = that you are no longer interested in just the home network architecture but= all small office park/building and similar networks as well. If this is th= e intent then the term homegate and the stated deliverables may be a tad to= o narrow in scope. Jason Weil ________________________________ From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behal= f Of Livingood, Jason Sent: Thursday, September 03, 2009 11:30 AM To: homegate@ietf.org Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our = scope! Here is the latest version. Feedback welcome, as always. Take a look at t= he priorities as well. I have coded the changes in BLUE. 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 busines= s (SMB) as the demarcation between the local network and the Internet. Thes= e technologies almost always involve a single entity - which is not purely = a router - called a "home gateway". This entity connects a local user or u= sers to various LAN 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 today= . At the root of many of these problems is the fact that device manufactur= ers, and/or the organizations that specify requirements for such devices, a= re not certain which IETF standards and best current practices should be su= pported, and when/why that support is needed. As a result of this, million= s of devices are being deployed every year, which do not work with importan= t IETF protocols, standards, and best practices that are central to the fut= ure of the Internet. One of the problems in this area appears to be that home gateway vendors ar= e 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 i= s document a baseline of "core" RFCs/BCPs which must be supported, followed= by some "advanced" RFCs/BCPs which are to be considered optional. The con= text and reasoning behind each document which is included should be summari= zed as well, in order to improve comprehension of why a given document has = been included. These things will help improve compatibilities with and cap= abilities for use of the Internet of today. This will include a focus in a= reas such as DNS proxy behavior, congestion mechanisms support, and securit= y. 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 DNSS= EC, 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 g= reat degree and there is no clear understanding of how such devices should = support IPv6. This working group will not develop new or extend existing Internet protoco= ls. Should any such need develop, the chairs will refer the work to anothe= r working group that is chartered to focus on the relevant problem. Proposed Deliverables and Priorities: The BoF/WG would work to improve the network experience that a SOHO / resid= ential home user gets when using the Internet. This includes providing a t= iered specification for what RFCs and BCPs should be supported, in what ord= er/priority, and in what manner. This will touch on standards such as: o IPv6 o DNSSEC RFCs and BCPs o ECN o RED (or other queue management) o DNS Proxy BCPs o Security-Related BCPs o Other TBD 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 On 9/1/09 5:00 PM, "Jason Livingood" wr= ote: So the deadline for BoF requests for the upcoming meeting is rather early I= MHO, set for 7 September. I believe we had a great deal of interest in a B= oF, based on the Bar BoF we had at IETF 75. However, I do believe that consensus indicated that our scope was rather to= o broad and should be narrowed substantially. Here's a quick stab at this. I'd like a LOT of feedback please, to try to = refine this. Don't take anything included or omitted as any kind of a stat= ement at all. Regards Jason --_000_C1920346B731FE48822877D74F28C8A307A2D15C59CATL0MS112cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [homegate] Homegate BoF @ IETF 76? Then we need to n= arrow our scope!
I would recommend striking the phrase or small to medium business (SMB)<= /U>=20 from the proposed charter. Extending beyond the SOHO to the the S= MB=20 drastically increases the number of possible network topologies. This = seems=20 to imply that you are no longer interested in just the home network archite= cture=20 but all small office park/building and similar networks as well. = If=20 this is the intent then the term homegate and the stated deliverables = may=20 be a tad too narrow in scope.
 
Jason=20 Weil

From: homegate-bounces@ietf.org=20 [mailto:homegate-bounces@ietf.org] On Behalf Of Livingood,=20 Jason
Sent: Thursday, September 03, 2009 11:30 AM
To:=20 homegate@ietf.org
Subject: Re: [homegate] Homegate BoF @ IETF 76?= Then=20 we need to narrow our scope!

Here is the latest version.  Feedback welcom= e, as=20 always.  Take a look at the priorities as well.  I have coded the= =20 changes in BLUE.

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

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

One of the problems in this area appears to be that home gat= eway=20 vendors are unclear which RFCs are important, or current, and why they are= =20 important and in what context they matter. Thus, the primary objective of t= he=20 group is document a baseline of “core” RFCs/BCPs which must be = supported,=20 followed by some “advanced” RFCs/BCPs which are to be considere= d optional.=20  The context and reasoning behind each document which is included shou= ld be=20 summarized as well, in order to improve comprehension of why a given docume= nt=20 has been included.  These things will help improve compatibilities wit= h and=20 capabilities for use of the Internet of today.  This will inclu= de a=20 focus in areas such as DNS proxy behavior, congestion mechanisms support, a= nd=20 security.
 
A secondary problem is compatibility with and capab= ility=20 for the use of the Internet of tomorrow.  New security needs re= lated=20 to DNS are motivating a move to DNSSEC.  However, many if not most hom= e=20 gateways cannot handle DNSSEC, which is expected to be a major problem that= =20 could significantly impede the deployment of DNSSEC globally. Support for I= Pv6=20 is also lacking to a great degree and there is no clear understanding of ho= w=20 such devices should support IPv6.
 
This w= orking=20 group will not develop new or extend existing Internet protocols.  Sho= uld=20 any such need develop, the chairs will refer the work to another working gr= oup=20 that is chartered to focus on the relevant problem.

Propos= ed=20 Deliverables and Priorities:
The BoF/WG would work to improve the ne= twork=20 experience that a SOHO / residential home user gets when using the Internet= .=20  This includes providing a tiered specification for what RFCs and BCPs= =20 should be supported, in what order/priority, and in what manner. This will = touch=20 on standards such as:
o   IPv6

o   DNSSEC RFCs and=20 BCPs

o   ECN

o   RED (or other queu= e=20 management)

o   DNS Proxy=20 BCPs

o   Security-Related=20 BCPs

o   Other=20 TBD


The group shall priorit= ize work=20 as follows:
1.    IPv4-related=20 topics

2.    IPv6-related=20 topics
<= SPAN=20 style=3D"FONT-SIZE: 10.5pt">
3.    DNS-related topics (DNSSEC, = DNS=20 Proxies, etc.)

4.    ECN-related topics (congesti= on and=20 queue management)

5.    Security-related=20 topics





On 9/1/09 5:00 PM, "Jason Liv= ingood"=20 <jason_livingood@cable.comcast.co= m>=20 wrote:

So the deadline for BoF requests for the upcomi= ng=20 meeting is rather early IMHO, set for 7 September.  I believe we had= a=20 great deal of interest in a BoF, based on the Bar BoF we had at IETF 75.= =20  

However, I do believe that consensus indicated that our = scope=20 was rather too broad and should be narrowed substantially.

Her= e’s a=20 quick stab at this.  I’d like a LOT of feedback please, to try= to refine=20 this.  Don’t take anything included or omitted as any kind of = a statement=20 at all.

Regards
Jason
--_000_C1920346B731FE48822877D74F28C8A307A2D15C59CATL0MS112cor_-- From bs7652@att.com Thu Sep 3 12:35:43 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB72E3A68BA for ; Thu, 3 Sep 2009 12:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.713 X-Spam-Level: X-Spam-Status: No, score=-104.713 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeJx-ZBO6zW5 for ; Thu, 3 Sep 2009 12:35:34 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id CCC5E3A689A for ; Thu, 3 Sep 2009 12:35:30 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-6.tower-161.messagelabs.com!1252006482!17418646!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 29954 invoked from network); 3 Sep 2009 19:34:43 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-6.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Sep 2009 19:34:43 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n83JYib5011057; Thu, 3 Sep 2009 15:34:44 -0400 Received: from 01GAF5142010625.AD.BLS.COM (01GAF5142010625.ad.bls.com [139.76.131.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n83JYeMF010998; Thu, 3 Sep 2009 15:34:41 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 15:34:38 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 15:34:38 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA2CCD.92F77B8B" Date: Thu, 3 Sep 2009 15:34:35 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0FDAB7F0@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! thread-index: AcorRzJMcBoLX+wtBk+JIgSW5sc65wBZCk6zAAGHTHA= References: From: "Stark, Barbara" To: "Livingood, Jason" , X-OriginalArrivalTime: 03 Sep 2009 19:34:38.0873 (UTC) FILETIME=[938A9090:01CA2CCD] Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 19:35:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2CCD.92F77B8B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have 2 concerns: 1. IPv6 - v6ops is currently working on a draft identifying which IPv6 RFCs "CPE Routers" (which is pretty much the same thing as a home gateway, in my book) need to support. Homegate's claim of ownership over this topic is in direct conflict. I believe these IPv6 recommendations are quite important (just like the proposed charter says); so important that I don't want to see in-fighting over ownership, transfer of ownership, or anything that might derail or slow down progress. v6ops has an aggressive schedule in mind for these requirements. I do not see how homegate inserting itself into the equation will have anything but a negative impact on the continuity of work and timelines. 2. DNSSEC - I am not convinced that DNSSEC deployment is critical for the future. I am willing to discuss and consider it with an open mind; but only within the context of WG list discussions, and not within the context of the proposed charter of a WG. If the WG charter included identification of best practices, present and future, around DNS (looking at DNS Proxy, DNSSEC, Dynamic DNS, in-home domain, etc.), then I think that might be a good thing, and there could be good discussion. I disagree with having the charter state that it's a given that DNSSEC is a must have for the future and that the only question is how to convince home gateway vendors to implement it. =20 Barbara =20 From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behalf Of Livingood, Jason Sent: Thursday, September 03, 2009 11:30 AM To: homegate@ietf.org Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! =20 Here is the latest version. Feedback welcome, as always. Take a look at the priorities as well. I have coded the changes in BLUE. Proposed Charter: Access to broadband Internet services use networking technology of one form or another=20 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. 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.=20 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 "core" RFCs/BCPs which must be supported, followed by some "advanced" RFCs/BCPs which are to be considered optional. 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.=20 =20 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. =20 This working group will not develop new or extend existing Internet protocols. Should any such need develop, the chairs will refer the work to another working group that is chartered to focus on the relevant problem. Proposed Deliverables and Priorities: The BoF/WG would work to improve the network experience that a SOHO / residential home user gets when using the Internet. This includes providing a tiered specification for what RFCs and BCPs should be supported, in what order/priority, and in what manner. This will touch on standards such as: o IPv6 o DNSSEC RFCs and BCPs o ECN o RED (or other queue management) o DNS Proxy BCPs o Security-Related BCPs o Other TBD 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 On 9/1/09 5:00 PM, "Jason Livingood" wrote: So the deadline for BoF requests for the upcoming meeting is rather early IMHO, set for 7 September. I believe we had a great deal of interest in a BoF, based on the Bar BoF we had at IETF 75. =20 However, I do believe that consensus indicated that our scope was rather too broad and should be narrowed substantially. Here's a quick stab at this. I'd like a LOT of feedback please, to try to refine this. Don't take anything included or omitted as any kind of a statement at all. Regards Jason ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA625 ------_=_NextPart_001_01CA2CCD.92F77B8B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our = scope!

I have 2 concerns:

1.       IPv6 – v6ops is currently working on a draft = identifying which IPv6 RFCs “CPE Routers” (which is pretty much the same thing = as a home gateway, in my book) need to support. Homegate’s claim of = ownership over this topic is in direct conflict. I believe these IPv6 = recommendations are quite important (just like the proposed charter says); so important that = I don’t want to see in-fighting over ownership, transfer of ownership, or = anything that might derail or slow down progress. v6ops has an aggressive schedule in = mind for these requirements. I do not see how homegate inserting itself into = the equation will have anything but a negative impact on the continuity of = work and timelines.

2.       DNSSEC – I am not convinced that DNSSEC deployment = is critical for the future. I am willing to discuss and consider it with an = open mind; but only within the context of WG list discussions, and not within = the context of the proposed charter of a WG. If the WG charter included = identification of best practices, present and future, around DNS (looking at DNS Proxy, = DNSSEC, Dynamic DNS, in-home domain, etc.), then I think that might be a good = thing, and there could be good discussion. I disagree with having the charter = state that it’s a given that DNSSEC is a must have for the future and = that the only question is how to convince home gateway vendors to implement = it.

 

Barbara

 

From:= homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On = Behalf Of Livingood, Jason
Sent: Thursday, September 03, 2009 11:30 AM
To: homegate@ietf.org
Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to = narrow our scope!

 

Here is the latest version. =  Feedback welcome, as always.  Take a look at the priorities as well.  I = have coded the changes in BLUE.

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.

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 “core” RFCs/BCPs which must be = supported, followed by some “advanced” RFCs/BCPs which are to be = considered optional.  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.
 
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.
 
This working group will not develop new or = extend existing Internet protocols.  Should any such need develop, the = chairs will refer the work to another working group that is chartered to focus = on the relevant problem.

Proposed Deliverables and Priorities:
The BoF/WG would work to improve the network experience that a SOHO / residential home user gets when using the Internet.  This includes providing a tiered specification for what RFCs and BCPs should be = supported, in what order/priority, and in what manner. This will touch on standards = such as:
o   IPv6

o =   DNSSEC RFCs and BCPs

o =   ECN

o =   RED (or other queue management)

o =   DNS Proxy BCPs

o =   Security-Related BCPs

o =   Other TBD


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





On 9/1/09 5:00 PM, "Jason Livingood" <jason_livingood@cable.comcast.= com> wrote:

So the deadline for BoF requests for the upcoming meeting is rather early = IMHO, set for 7 September.  I believe we had a great deal of interest in = a BoF, based on the Bar BoF we had at IETF 75.  

However, I do believe that consensus indicated that our scope was = rather too broad and should be narrowed substantially.

Here’s a quick stab at this.  I’d like a LOT of = feedback please, to try to refine this.  Don’t take anything included = or omitted as any kind of a statement at all.

Regards
Jason

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. GA625

 ------_=_NextPart_001_01CA2CCD.92F77B8B-- From jmpolk@cisco.com Thu Sep 3 12:49:15 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A72893A685A for ; Thu, 3 Sep 2009 12:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.783 X-Spam-Level: X-Spam-Status: No, score=-5.783 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_00=-2.599, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoEry3nfMoD2 for ; Thu, 3 Sep 2009 12:49:14 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DCB303A6778 for ; Thu, 3 Sep 2009 12:49:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAHABO6n0qrR7O6/2dsb2JhbACIVbogiEEBkCkFhBuBXQ X-IronPort-AV: E=Sophos;i="4.44,326,1249257600"; d="scan'208";a="381481564" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Sep 2009 19:48:37 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n83Jmbkd012605; Thu, 3 Sep 2009 12:48:37 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n83JmbMB006573; Thu, 3 Sep 2009 19:48:37 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 12:48:37 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.2.174]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 12:48:37 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 03 Sep 2009 14:48:35 -0500 To: "Livingood, Jason" , Paul Hoffman , From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 03 Sep 2009 19:48:37.0186 (UTC) FILETIME=[8736FA20:01CA2CCF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1605; t=1252007317; x=1252871317; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[homegate]=20Homegate=20BoF=20@=20IETF= 2076?=20Then=20we=20need=20to=20narrow=0A=20=20our=20scope! |Sender:=20; bh=6X5MG7mVBNoZ3FKUFMoNCUL7NrL+d9PPss90St3Ea6Y=; b=pUxeQI9STHB2DcBlGiCbtOW6WUgTYYg9+xz2kOBuHvM/SLkLUG/hM9CghZ eOF4UmtA0ph6P1fraD+8Ba94FjhH58U4zX/dTtamgp/Fd8f+tlQvtUkyk5Hg RrI3yRsjik; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 19:49:15 -0000 At 10:20 AM 9/3/2009, Livingood, Jason wrote: >I understand Paul's desire to constrain the problem space. But I tend to >agree with James that IPv4 and v6 and DNS may not be enough. Here's a >proposed addition to the charter to try to make it clear that new protocol >work is not the aim: > >"This working group will not develop new or extend existing Internet >protocols. Should any such need develop, the chairs will refer the work to >another working group that is chartered to focus on the relevant problem." I like this new text. James >Jason > > > >On 9/1/09 11:36 PM, "James M. Polk" wrote: > > >> The first document to be produced by the WG would cover IPv4, IPv6, > >> and DNS (including DNSSEC) and little else. The WG can add follow-on > >> documents to the charter later after showing enough interest to > >> write and review those documents. These additional documents might > >> cover topics such as firewall best practices, ECN, RED, DNS > proxies, and so > >> on. > > > > While I'm not sold on the idea of v4, v6 and DNS *only* in the first > > doc (I think firewall best practices should be in here, as well as > > what not to break that is already standardized (i.e., ECN)), I firmly > > believe the charter should state that this group will *not* produce > > standards track documents, as that is left for the specific WGs that > > are chartered to work on those protocols in the standards track > > effort. I think this needs to be explicit in the charter. BCPs should > > be the strongest status of doc from this group. From jmpolk@cisco.com Thu Sep 3 13:00:35 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A06FD3A67C2 for ; Thu, 3 Sep 2009 13:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.615 X-Spam-Level: X-Spam-Status: No, score=-5.615 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qT5LvSgOrZQU for ; Thu, 3 Sep 2009 13:00:34 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 54A393A67A1 for ; Thu, 3 Sep 2009 13:00:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAHAB+9n0qrR7O6/2dsb2JhbACIVbooiEEBkCkFgikGCYFjgV0 X-IronPort-AV: E=Sophos;i="4.44,326,1249257600"; d="scan'208";a="237174617" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 03 Sep 2009 19:59:39 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n83JxdSb003742; Thu, 3 Sep 2009 12:59:39 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n83Jxd8M018025; Thu, 3 Sep 2009 19:59:39 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 12:59:39 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.2.174]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 12:59:39 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 03 Sep 2009 14:59:37 -0500 To: , , From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 03 Sep 2009 19:59:39.0149 (UTC) FILETIME=[11C683D0:01CA2CD1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6244; t=1252007979; x=1252871979; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[homegate]=20Homegate=20BoF=20@=20IETF= 2076?=20Then=20we=20need=20to=20narrow=0A=20=20our=20scope! |Sender:=20; bh=kn85BajbcifyCvqrVat9lOdNJ/8VKLudu4CAHXdi+yk=; b=a7uSu7XnVsKBNXflCc5G2ZeGKdP4c4Nm6UB6jQc6pjwa+0i2aAhi7AkY3W 5wsgh4dXxNd614GTMfWQwUPBsydKIPHMm+0mq+YIRrZaPPWe4Qqp8OOnbcDN qSHD80Gj8l; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 20:00:35 -0000 At 11:13 AM 9/3/2009, Jason.Weil@cox.com wrote: >Content-Language: en-US >Content-Type: multipart/alternative; > >boundary="_000_C1920346B731FE48822877D74F28C8A307A2D15C59CATL0MS112cor_" > >I would recommend striking the phrase or small to medium business >(SMB) from the proposed charter. Extending beyond the SOHO to the >the SMB drastically increases the number of possible network topologies. yeah - but we're talking about defining the demarcation entity only. We're not choosing between token ring (which might be in a SMB) and Ethernet (which will nearly always be in the home) as a consideration. "SMB" is the market segment name, and while I'm not a fan of covering a 300-400 user medium business, we certainly want to cover a Starbucks, or a small insurance company, or a bank branch office, or a McDonalds type of location. This is certainly within the same scope as a power home user that has 50-100 Cat 5 jacks in their home (with 10-20+ being active). It's the same scale, and we're talking about the same network entity demarc. Each of the SMB instances I gave above certainly are the target of an MSO or business class DSL offering. Admittedly this is on the upper end of what this group should touch. James >This seems to imply that you are no longer interested in just the >home network architecture but all small office park/building and >similar networks as well. If this is the intent then the term >homegate and the stated deliverables may be a tad too narrow in scope. > >Jason Weil > > >---------- >From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] >On Behalf Of Livingood, Jason >Sent: Thursday, September 03, 2009 11:30 AM >To: homegate@ietf.org >Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to >narrow our scope! > >Here is the latest version. Feedback welcome, as always. Take a >look at the priorities as well. I have coded the changes in BLUE. > >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. > >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 "core" >RFCs/BCPs which must be supported, followed by some "advanced" >RFCs/BCPs which are to be considered optional. 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. > >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. > >This working group will not develop new or extend existing Internet >protocols. Should any such need develop, the chairs will refer the >work to another working group that is chartered to focus on the >relevant problem. > >Proposed Deliverables and Priorities: >The BoF/WG would work to improve the network experience that a SOHO >/ residential home user gets when using the Internet. This includes >providing a tiered specification for what RFCs and BCPs should be >supported, in what order/priority, and in what manner. This will >touch on standards such as: >o IPv6 > >o DNSSEC RFCs and BCPs > >o ECN > >o RED (or other queue management) > >o DNS Proxy BCPs > >o Security-Related BCPs > >o Other TBD > > >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 > > > > > >On 9/1/09 5:00 PM, "Jason Livingood" ><jason_livingood@cable.comcast.com> wrote: > >So the deadline for BoF requests for the upcoming meeting is rather >early IMHO, set for 7 September. I believe we had a great deal of >interest in a BoF, based on the Bar BoF we had at IETF 75. > >However, I do believe that consensus indicated that our scope was >rather too broad and should be narrowed substantially. > >Here's a quick stab at this. I'd like a LOT of feedback please, to >try to refine this. Don't take anything included or omitted as any >kind of a statement at all. > >Regards >Jason > >_______________________________________________ >homegate mailing list >homegate@ietf.org >https://www.ietf.org/mailman/listinfo/homegate From Ray.Bellis@nominet.org.uk Fri Sep 4 02:26:05 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF5CB3A65A6; Fri, 4 Sep 2009 02:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.095 X-Spam-Level: X-Spam-Status: No, score=-5.095 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdXOb2ADB3tt; Fri, 4 Sep 2009 02:26:04 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 0A7913A68C3; Fri, 4 Sep 2009 02:26:00 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=bjtBWvrl/YrwcG9wklGQ2OHOGS0LRFFxEuXpwTPL+i+O/uS+aD5J8n4d pEiffNYVL32TWaoTtSPzYF93fdcO5q0PSb07okfMtlQOkVzTLwfQxkHu4 JUVBvkT+ybbeECa; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1252056384; x=1283592384; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[home gate]=20Homegate=20BoF=20@=20IETF=2076?=20Then=20we=20nee d=20to=20narrow=20our=09scope!|Date:=20Fri,=204=20Sep=202 009=2010:25:01=20+0100|Message-ID:=20 |To:=20"Stark,=20Barbara"=20|Cc:=20homega te@ietf.org,=0D=0A=09homegate-bounces@ietf.org,=0D=0A=09" Livingood,=20Jason"=20 |MIME-Version:=201.0|In-Reply-To:=20<7582BC68E4994F4ABF0B D4723975C3FA0FDAB7F0@crexc41p>|References:=20=09=20<7582BC68E4994F4ABF0 BD4723975C3FA0FDAB7F0@crexc41p>; bh=rFqwPnhWQYThDflrfSh7VRCtNtP9TZC7weeE74I2Ot8=; b=szTLCSplxiWE0kurokmL1EfP5bwmumogl07OWahGe/i9cPJI3mkoK101 EOqritgV8NmvePIQyUpk1JJhDtIPpsEDusQwddn4L38l8pWvr6qtkGkkt ykt41bbjJF6PuHF; X-IronPort-AV: E=Sophos;i="4.44,331,1249254000"; d="scan'208";a="12659209" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 04 Sep 2009 10:25:06 +0100 In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0FDAB7F0@crexc41p> References: <7582BC68E4994F4ABF0BD4723975C3FA0FDAB7F0@crexc41p> To: "Stark, Barbara" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 4 Sep 2009 10:25:01 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 04/09/2009 10:25:09 AM, Serialize complete at 04/09/2009 10:25:09 AM Content-Type: multipart/alternative; boundary="=_alternative 0033BAF680257627_=" Cc: homegate-bounces@ietf.org, "Livingood, Jason" , homegate@ietf.org Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 09:26:06 -0000 This is a multipart message in MIME format. --=_alternative 0033BAF680257627_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 PiAyLiAgICAgICBETlNTRUMg4oCTIEkgYW0gbm90IGNvbnZpbmNlZCB0aGF0IEROU1NFQyBkZXBs b3ltZW50IGlzIA0KPiBjcml0aWNhbCBmb3IgdGhlIGZ1dHVyZS4gSSBhbSB3aWxsaW5nIHRvIGRp c2N1c3MgYW5kIGNvbnNpZGVyIGl0IA0KPiB3aXRoIGFuIG9wZW4gbWluZDsgYnV0IG9ubHkgd2l0 aGluIHRoZSBjb250ZXh0IG9mIFdHIGxpc3QgDQo+IGRpc2N1c3Npb25zLCBhbmQgbm90IHdpdGhp biB0aGUgY29udGV4dCBvZiB0aGUgcHJvcG9zZWQgY2hhcnRlciBvZiBhDQo+IFdHLiBJZiB0aGUg V0cgY2hhcnRlciBpbmNsdWRlZCBpZGVudGlmaWNhdGlvbiBvZiBiZXN0IHByYWN0aWNlcywgDQo+ IHByZXNlbnQgYW5kIGZ1dHVyZSwgYXJvdW5kIEROUyAobG9va2luZyBhdCBETlMgUHJveHksIERO U1NFQywgDQo+IER5bmFtaWMgRE5TLCBpbi1ob21lIGRvbWFpbiwgZXRjLiksIHRoZW4gSSB0aGlu ayB0aGF0IG1pZ2h0IGJlIGEgDQo+IGdvb2QgdGhpbmcsIGFuZCB0aGVyZSBjb3VsZCBiZSBnb29k IGRpc2N1c3Npb24uIEkgZGlzYWdyZWUgd2l0aCANCj4gaGF2aW5nIHRoZSBjaGFydGVyIHN0YXRl IHRoYXQgaXTigJlzIGEgZ2l2ZW4gdGhhdCBETlNTRUMgaXMgYSBtdXN0IA0KPiBoYXZlIGZvciB0 aGUgZnV0dXJlIGFuZCB0aGF0IHRoZSBvbmx5IHF1ZXN0aW9uIGlzIGhvdyB0byBjb252aW5jZSAN Cj4gaG9tZSBnYXRld2F5IHZlbmRvcnMgdG8gaW1wbGVtZW50IGl0Lg0KDQpJIHN0cm9uZ2x5IGRp YWdyZWUuDQoNCkROU1NFQyBfaXNfIGNvbWluZywgYnV0IGhvbWUgZ2F0ZXdheXMgY2FuIGFuZCBk byBpbnRlcmZlcmUgd2l0aCBpdHMgDQpjb3JyZWN0IG9wZXJhdGlvbi4NCg0KRm9ydHVuYXRlbHkg bXVjaCBvZiB0aGlzIGlzIGFscmVhZHkgY292ZXJlZCBieSBteSBSRkMgNTYyNS4NCg0KUmF5DQoN Ci0tIA0KUmF5IEJlbGxpcywgTUEoT3hvbikgTUlFVA0KU2VuaW9yIFJlc2VhcmNoZXIgaW4gQWR2 YW5jZWQgUHJvamVjdHMsIE5vbWluZXQNCmU6IHJheUBub21pbmV0Lm9yZy51aywgdDogKzQ0IDE4 NjUgMzMyMjExDQoNCg== --=_alternative 0033BAF680257627_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDIuICZuYnNwOyAmbmJzcDsgJm5ic3A7IEROU1NFQyDigJMg SSBhbSBub3QgY29udmluY2VkDQp0aGF0IEROU1NFQyBkZXBsb3ltZW50IGlzIDxicj4NCiZndDsg Y3JpdGljYWwgZm9yIHRoZSBmdXR1cmUuIEkgYW0gd2lsbGluZyB0byBkaXNjdXNzIGFuZCBjb25z aWRlciBpdCA8YnI+DQomZ3Q7IHdpdGggYW4gb3BlbiBtaW5kOyBidXQgb25seSB3aXRoaW4gdGhl IGNvbnRleHQgb2YgV0cgbGlzdCA8YnI+DQomZ3Q7IGRpc2N1c3Npb25zLCBhbmQgbm90IHdpdGhp biB0aGUgY29udGV4dCBvZiB0aGUgcHJvcG9zZWQgY2hhcnRlciBvZg0KYTxicj4NCiZndDsgV0cu IElmIHRoZSBXRyBjaGFydGVyIGluY2x1ZGVkIGlkZW50aWZpY2F0aW9uIG9mIGJlc3QgcHJhY3Rp Y2VzLCA8YnI+DQomZ3Q7IHByZXNlbnQgYW5kIGZ1dHVyZSwgYXJvdW5kIEROUyAobG9va2luZyBh dCBETlMgUHJveHksIEROU1NFQywgPGJyPg0KJmd0OyBEeW5hbWljIEROUywgaW4taG9tZSBkb21h aW4sIGV0Yy4pLCB0aGVuIEkgdGhpbmsgdGhhdCBtaWdodCBiZSBhIDxicj4NCiZndDsgZ29vZCB0 aGluZywgYW5kIHRoZXJlIGNvdWxkIGJlIGdvb2QgZGlzY3Vzc2lvbi4gSSBkaXNhZ3JlZSB3aXRo IDxicj4NCiZndDsgaGF2aW5nIHRoZSBjaGFydGVyIHN0YXRlIHRoYXQgaXTigJlzIGEgZ2l2ZW4g dGhhdCBETlNTRUMgaXMgYSBtdXN0DQo8YnI+DQomZ3Q7IGhhdmUgZm9yIHRoZSBmdXR1cmUgYW5k IHRoYXQgdGhlIG9ubHkgcXVlc3Rpb24gaXMgaG93IHRvIGNvbnZpbmNlDQo8YnI+DQomZ3Q7IGhv bWUgZ2F0ZXdheSB2ZW5kb3JzIHRvIGltcGxlbWVudCBpdC48L2ZvbnQ+PC90dD4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPkkgc3Ryb25nbHkgZGlhZ3JlZS48L2ZvbnQ+PC90dD4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPkROU1NFQyBfaXNfIGNvbWluZywgYnV0IGhvbWUgZ2F0ZXdh eXMgY2FuIGFuZCBkbyBpbnRlcmZlcmUNCndpdGggaXRzIGNvcnJlY3Qgb3BlcmF0aW9uLjwvZm9u dD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Rm9ydHVuYXRlbHkgbXVjaCBvZiB0 aGlzIGlzIGFscmVhZHkgY292ZXJlZCBieSBteQ0KUkZDIDU2MjUuPC9mb250PjwvdHQ+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5SYXk8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPi0tIDxicj4NClJheSBCZWxsaXMsIE1BKE94b24pIE1JRVQ8YnI+DQpTZW5pb3Ig UmVzZWFyY2hlciBpbiBBZHZhbmNlZCBQcm9qZWN0cywgTm9taW5ldDxicj4NCmU6IHJheUBub21p bmV0Lm9yZy51aywgdDogKzQ0IDE4NjUgMzMyMjExPGJyPg0KPC9mb250PjwvdHQ+DQo= --=_alternative 0033BAF680257627_=-- From iljitsch@muada.com Fri Sep 4 03:30:29 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BE103A67F9; Fri, 4 Sep 2009 03:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoJ7p9-UXbPu; Fri, 4 Sep 2009 03:30:28 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 110FF3A65A6; Fri, 4 Sep 2009 03:30:27 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.71]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n84AR7Ps007823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 Sep 2009 12:27:08 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum In-Reply-To: Date: Fri, 4 Sep 2009 12:27:47 +0200 Content-Transfer-Encoding: 7bit Message-Id: <244B11C6-4DEF-4BD9-8F8E-F3644101BDD7@muada.com> References: <68A1E2ED-774A-40B2-B0A5-8A2F7EF59753@nokia.com> <4A7E4674.8050500@isi.edu> <4A7EF180.1030109@isi.edu> <7132B313-6C17-45C0-914E-EF5BDBF037C8@bittorrent.com> <439A249E-196C-41B1-B175-10C55415B2AD@cisco.com> <4A7F6964.3020701@isi.edu> <81FAA1B1-98A0-415B-805F-DDB0F1FC00A1@bittorrent.com> <451394FB-E239-4886-A05A-0A075B6C3F87@bittorrent.com> To: Ray.Bellis@nominet.org.uk X-Mailer: Apple Mail (2.1075.2) Cc: homegate-bounces@ietf.org, Paul Hoffman , homegate@ietf.org, Stanislav Shalunov Subject: Re: [homegate] Home gateway systems X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 10:30:29 -0000 On 10 Aug 2009, at 9:15 , Ray.Bellis@nominet.org.uk wrote: > HomeGate is _not_ only about congestion management and queueing, Why not? If you do everything right but do this part wrong, you still have a miserable user experience that is almost impossible to fix elsewhere. > Where it is relevant is > in making sure that the relatively smart router doesn't throw > packets out > of its WAN port faster than the dumb modem can handle. And how exactly is device A supposed to know how fast device B can transmit packets over the broadband link? Since ADSL and cable aren't ethernet, there is no 1-to-1 relationship between the size of ethernet packets that A sees and the size and therefore supported rate for the non-ethernet packets that B transmits. On cable it's worse it's a shared medium with ever changing uplink capacity. Maybe it makes sense for A to send packets to B at something like 150% of B's uplink capacity rather than the default 100 Mbps if A has more advanced queuing than B as a step in the right direction, but it's never going to be as good as sitting right on top of the actual uplink and doing the smart queuing there, unless you're ok with staying well below the real uplink capacity, which is a terrible way to handle this with today's uplink-starved broadband. About the charter(-like) discussion: someone suggested IPv4, IPv6 and DNS. Why IPv4? Don't we know how to do that by now? From bs7652@att.com Fri Sep 4 07:11:49 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD68B3A6965; Fri, 4 Sep 2009 07:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.133 X-Spam-Level: X-Spam-Status: No, score=-105.133 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6u4GWoBYcPj4; Fri, 4 Sep 2009 07:11:47 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with SMTP id 52E993A679F; Fri, 4 Sep 2009 07:11:47 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-12.tower-120.messagelabs.com!1252073397!47816914!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 31854 invoked from network); 4 Sep 2009 14:09:58 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-12.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Sep 2009 14:09:58 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n84E9wej014281; Fri, 4 Sep 2009 10:09:59 -0400 Received: from 01GAF5142010624.AD.BLS.COM (01GAF5142010624.ad.bls.com [139.76.131.91]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n84E9s4p014212; Fri, 4 Sep 2009 10:09:55 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 10:09:52 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 10:09:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA2D69.5F2277BF" Date: Fri, 4 Sep 2009 10:09:50 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0FDAB9A8@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! Thread-Index: AcotQZ1TZTBrFUpvQdOQ0tUA3NcnYwAJzBUg References: <7582BC68E4994F4ABF0BD4723975C3FA0FDAB7F0@crexc41p> From: "Stark, Barbara" To: X-OriginalArrivalTime: 04 Sep 2009 14:09:52.0379 (UTC) FILETIME=[5F194CB0:01CA2D69] Cc: homegate-bounces@ietf.org, "Livingood, Jason" , homegate@ietf.org Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 14:11:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2D69.5F2277BF Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5kIEkgaGF2ZSBubyBwcm9ibGVtIHdpdGggdGhlIHRoaW5ncyBJIHJlYWQgaW4gUkZDIDU2MjUu IEJ1dCBJIHJlYWQgdGhvc2UgYXMg4oCcdGhlIGhvbWUgZ2F0ZXdheSBtdXN0IG5vdCBpbnRlcmZl cmUgd2l0aCBETlNTRUPigJ0sIGFuZCBub3Qg4oCcdGhlIGhvbWUgZ2F0ZXdheSBtdXN0IHN1cHBv cnQgRE5TU0VD4oCdLiBUaGVyZeKAmXMgYSBkaWZmZXJlbmNlIGJldHdlZW4gbm9uLWludGVyZmVy ZW5jZSBhbmQgc3VwcG9ydC4gSSBkaWRu4oCZdCBzZWUgaW4gdGhlIFJGQyB3aGVyZSB0aGUgZ2F0 ZXdheSBuZWVkZWQgdG8gYWN0dWFsbHkga25vdyB0aGF0IEROU1NFQyB3YXMgaGFwcGVuaW5nLCBh bmQgcmVhY3QgYWNjb3JkaW5nbHkuIElmIEkgbWlzc2VkIHRoYXQgcGFydCwgcGxlYXNlIGxldCBt ZSBrbm93Lg0KDQpCYXJiYXJhDQoNCiANCg0KRnJvbTogUmF5LkJlbGxpc0Bub21pbmV0Lm9yZy51 ayBbbWFpbHRvOlJheS5CZWxsaXNAbm9taW5ldC5vcmcudWtdIA0KU2VudDogRnJpZGF5LCBTZXB0 ZW1iZXIgMDQsIDIwMDkgNToyNSBBTQ0KVG86IFN0YXJrLCBCYXJiYXJhDQpDYzogaG9tZWdhdGVA aWV0Zi5vcmc7IGhvbWVnYXRlLWJvdW5jZXNAaWV0Zi5vcmc7IExpdmluZ29vZCwgSmFzb24NClN1 YmplY3Q6IFJlOiBbaG9tZWdhdGVdIEhvbWVnYXRlIEJvRiBAIElFVEYgNzY/IFRoZW4gd2UgbmVl ZCB0byBuYXJyb3cgb3VyIHNjb3BlIQ0KDQogDQoNCj4gMi4gICAgICAgRE5TU0VDIOKAkyBJIGFt IG5vdCBjb252aW5jZWQgdGhhdCBETlNTRUMgZGVwbG95bWVudCBpcyANCj4gY3JpdGljYWwgZm9y IHRoZSBmdXR1cmUuIEkgYW0gd2lsbGluZyB0byBkaXNjdXNzIGFuZCBjb25zaWRlciBpdCANCj4g d2l0aCBhbiBvcGVuIG1pbmQ7IGJ1dCBvbmx5IHdpdGhpbiB0aGUgY29udGV4dCBvZiBXRyBsaXN0 IA0KPiBkaXNjdXNzaW9ucywgYW5kIG5vdCB3aXRoaW4gdGhlIGNvbnRleHQgb2YgdGhlIHByb3Bv c2VkIGNoYXJ0ZXIgb2YgYQ0KPiBXRy4gSWYgdGhlIFdHIGNoYXJ0ZXIgaW5jbHVkZWQgaWRlbnRp ZmljYXRpb24gb2YgYmVzdCBwcmFjdGljZXMsIA0KPiBwcmVzZW50IGFuZCBmdXR1cmUsIGFyb3Vu ZCBETlMgKGxvb2tpbmcgYXQgRE5TIFByb3h5LCBETlNTRUMsIA0KPiBEeW5hbWljIEROUywgaW4t aG9tZSBkb21haW4sIGV0Yy4pLCB0aGVuIEkgdGhpbmsgdGhhdCBtaWdodCBiZSBhIA0KPiBnb29k IHRoaW5nLCBhbmQgdGhlcmUgY291bGQgYmUgZ29vZCBkaXNjdXNzaW9uLiBJIGRpc2FncmVlIHdp dGggDQo+IGhhdmluZyB0aGUgY2hhcnRlciBzdGF0ZSB0aGF0IGl04oCZcyBhIGdpdmVuIHRoYXQg RE5TU0VDIGlzIGEgbXVzdCANCj4gaGF2ZSBmb3IgdGhlIGZ1dHVyZSBhbmQgdGhhdCB0aGUgb25s eSBxdWVzdGlvbiBpcyBob3cgdG8gY29udmluY2UgDQo+IGhvbWUgZ2F0ZXdheSB2ZW5kb3JzIHRv IGltcGxlbWVudCBpdC4gDQoNCkkgc3Ryb25nbHkgZGlhZ3JlZS4gDQoNCkROU1NFQyBfaXNfIGNv bWluZywgYnV0IGhvbWUgZ2F0ZXdheXMgY2FuIGFuZCBkbyBpbnRlcmZlcmUgd2l0aCBpdHMgY29y cmVjdCBvcGVyYXRpb24uIA0KDQpGb3J0dW5hdGVseSBtdWNoIG9mIHRoaXMgaXMgYWxyZWFkeSBj b3ZlcmVkIGJ5IG15IFJGQyA1NjI1LiANCg0KUmF5IA0KDQotLSANClJheSBCZWxsaXMsIE1BKE94 b24pIE1JRVQNClNlbmlvciBSZXNlYXJjaGVyIGluIEFkdmFuY2VkIFByb2plY3RzLCBOb21pbmV0 DQplOiByYXlAbm9taW5ldC5vcmcudWssIHQ6ICs0NCAxODY1IDMzMjIxMQ0KDQo= ------_=_NextPart_001_01CA2D69.5F2277BF Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N CiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnR0DQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LlNlY3Rpb24xDQoJ e3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVT IGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+QW5kIEkgaGF2ZSBubyBwcm9i bGVtIHdpdGggdGhlIHRoaW5ncyBJIHJlYWQgaW4gUkZDIDU2MjUuIEJ1dCBJDQpyZWFkIHRob3Nl IGFzIOKAnHRoZSBob21lIGdhdGV3YXkgbXVzdCBub3QgaW50ZXJmZXJlIHdpdGggRE5TU0VD4oCd LCBhbmQgbm90IOKAnHRoZQ0KaG9tZSBnYXRld2F5IG11c3Qgc3VwcG9ydCBETlNTRUPigJ0uIFRo ZXJl4oCZcyBhIGRpZmZlcmVuY2UgYmV0d2Vlbg0Kbm9uLWludGVyZmVyZW5jZSBhbmQgc3VwcG9y dC4gSSBkaWRu4oCZdCBzZWUgaW4gdGhlIFJGQyB3aGVyZSB0aGUgZ2F0ZXdheSBuZWVkZWQNCnRv IGFjdHVhbGx5IGtub3cgdGhhdCBETlNTRUMgd2FzIGhhcHBlbmluZywgYW5kIHJlYWN0IGFjY29y ZGluZ2x5LiBJZiBJIG1pc3NlZA0KdGhhdCBwYXJ0LCBwbGVhc2UgbGV0IG1lIGtub3cuPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMx RjQ5N0QnPkJhcmJhcmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K DQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPg0KDQo8ZGl2Pg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbic+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48 c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiJz4NClJheS5CZWxsaXNAbm9taW5ldC5vcmcudWsgW21haWx0bzpSYXkuQmVsbGlzQG5v bWluZXQub3JnLnVrXSA8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBTZXB0ZW1iZXIgMDQsIDIw MDkgNToyNSBBTTxicj4NCjxiPlRvOjwvYj4gU3RhcmssIEJhcmJhcmE8YnI+DQo8Yj5DYzo8L2I+ IGhvbWVnYXRlQGlldGYub3JnOyBob21lZ2F0ZS1ib3VuY2VzQGlldGYub3JnOyBMaXZpbmdvb2Qs IEphc29uPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaG9tZWdhdGVdIEhvbWVnYXRlIEJvRiBA IElFVEYgNzY/IFRoZW4gd2UgbmVlZCB0byBuYXJyb3cNCm91ciBzY29wZSE8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHR0PjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Jz4mZ3Q7IDIuICZuYnNwOyAmbmJzcDsNCiZuYnNwOyBETlNTRUMg4oCT IEkgYW0gbm90IGNvbnZpbmNlZCB0aGF0IEROU1NFQyBkZXBsb3ltZW50IGlzIDwvc3Bhbj48L3R0 PjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci Jz48YnI+DQo8dHQ+Jmd0OyBjcml0aWNhbCBmb3IgdGhlIGZ1dHVyZS4gSSBhbSB3aWxsaW5nIHRv IGRpc2N1c3MgYW5kIGNvbnNpZGVyIGl0IDwvdHQ+PGJyPg0KPHR0PiZndDsgd2l0aCBhbiBvcGVu IG1pbmQ7IGJ1dCBvbmx5IHdpdGhpbiB0aGUgY29udGV4dCBvZiBXRyBsaXN0IDwvdHQ+PGJyPg0K PHR0PiZndDsgZGlzY3Vzc2lvbnMsIGFuZCBub3Qgd2l0aGluIHRoZSBjb250ZXh0IG9mIHRoZSBw cm9wb3NlZCBjaGFydGVyIG9mIGE8L3R0Pjxicj4NCjx0dD4mZ3Q7IFdHLiBJZiB0aGUgV0cgY2hh cnRlciBpbmNsdWRlZCBpZGVudGlmaWNhdGlvbiBvZiBiZXN0IHByYWN0aWNlcywgPC90dD48YnI+ DQo8dHQ+Jmd0OyBwcmVzZW50IGFuZCBmdXR1cmUsIGFyb3VuZCBETlMgKGxvb2tpbmcgYXQgRE5T IFByb3h5LCBETlNTRUMsIDwvdHQ+PGJyPg0KPHR0PiZndDsgRHluYW1pYyBETlMsIGluLWhvbWUg ZG9tYWluLCBldGMuKSwgdGhlbiBJIHRoaW5rIHRoYXQgbWlnaHQgYmUgYSA8L3R0Pjxicj4NCjx0 dD4mZ3Q7IGdvb2QgdGhpbmcsIGFuZCB0aGVyZSBjb3VsZCBiZSBnb29kIGRpc2N1c3Npb24uIEkg ZGlzYWdyZWUgd2l0aCA8L3R0Pjxicj4NCjx0dD4mZ3Q7IGhhdmluZyB0aGUgY2hhcnRlciBzdGF0 ZSB0aGF0IGl04oCZcyBhIGdpdmVuIHRoYXQgRE5TU0VDIGlzIGEgbXVzdCA8L3R0Pjxicj4NCjx0 dD4mZ3Q7IGhhdmUgZm9yIHRoZSBmdXR1cmUgYW5kIHRoYXQgdGhlIG9ubHkgcXVlc3Rpb24gaXMg aG93IHRvIGNvbnZpbmNlIDwvdHQ+PGJyPg0KPHR0PiZndDsgaG9tZSBnYXRld2F5IHZlbmRvcnMg dG8gaW1wbGVtZW50IGl0LjwvdHQ+PC9zcGFuPiA8YnI+DQo8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQnPkkgc3Ryb25nbHkgZGlhZ3JlZS48L3NwYW4+PC90dD4gPGJyPg0K PGJyPg0KPHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5ETlNTRUMgX2lzXyBjb21p bmcsIGJ1dCBob21lIGdhdGV3YXlzIGNhbg0KYW5kIGRvIGludGVyZmVyZSB3aXRoIGl0cyBjb3Jy ZWN0IG9wZXJhdGlvbi48L3NwYW4+PC90dD4gPGJyPg0KPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Jz5Gb3J0dW5hdGVseSBtdWNoIG9mIHRoaXMgaXMgYWxyZWFkeSBjb3Zl cmVkDQpieSBteSBSRkMgNTYyNS48L3NwYW4+PC90dD4gPGJyPg0KPGJyPg0KPHR0PjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Jz5SYXk8L3NwYW4+PC90dD4gPGJyPg0KPGJyPg0KPHR0Pjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4tLSA8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxicj4NCjx0dD5S YXkgQmVsbGlzLCBNQShPeG9uKSBNSUVUPC90dD48YnI+DQo8dHQ+U2VuaW9yIFJlc2VhcmNoZXIg aW4gQWR2YW5jZWQgUHJvamVjdHMsIE5vbWluZXQ8L3R0Pjxicj4NCjx0dD5lOiByYXlAbm9taW5l dC5vcmcudWssIHQ6ICs0NCAxODY1IDMzMjIxMTwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K DQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K ------_=_NextPart_001_01CA2D69.5F2277BF-- From Ray.Bellis@nominet.org.uk Fri Sep 4 07:22:53 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D16113A6A22; Fri, 4 Sep 2009 07:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph1tn0Ui0GM0; Fri, 4 Sep 2009 07:22:52 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id BDC843A69F7; Fri, 4 Sep 2009 07:22:51 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=YVKozLvURa/pLrS794AHomau8+OFZIK4Q80QEyB90xec1qpYG9DRuh8h gTnWVzt94+517eP1+SdN92Nii08nmuky1PAZ8FisnIi/akbrfscafD4dW Bak4LCuSbQHQ+q4; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1252074193; x=1283610193; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20RE:=20[home gate]=20Homegate=20BoF=20@=20IETF=2076?=20Then=20we=20nee d=20to=20narrow=20our=09scope!|Date:=20Fri,=204=20Sep=202 009=2015:21:39=20+0100|Message-ID:=20 |To:=20"Stark,=20Barbara"=20|Cc:=20homega te@ietf.org,=0D=0A=09homegate-bounces@ietf.org,=0D=0A=09" Livingood,=20Jason"=20 |MIME-Version:=201.0|In-Reply-To:=20<7582BC68E4994F4ABF0B D4723975C3FA0FDAB9A8@crexc41p>|References:=20=09=20<7582BC68E4994F4ABF0 BD4723975C3FA0FDAB7F0@crexc41p>=20=20<75 82BC68E4994F4ABF0BD4723975C3FA0FDAB9A8@crexc41p>; bh=wneUcpH4JLBNalONQROI8P4jo7bKkCPxcCsD/+VcIr0=; b=z12CmYBThVxSsfbzByuWHW2Am+G8avxNgi7I6fPUpHX+ZbnzfBq5Ok/f rCOlZ1tCJfZXlBJ36aC19UeTSCjQyhbskSQtwVloGRpA4u/OdxHBpFrBb SESG0j4mDDakiJg; X-IronPort-AV: E=Sophos;i="4.44,333,1249254000"; d="scan'208";a="17349168" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 04 Sep 2009 15:21:49 +0100 In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0FDAB9A8@crexc41p> References: <7582BC68E4994F4ABF0BD4723975C3FA0FDAB7F0@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA0FDAB9A8@crexc41p> To: "Stark, Barbara" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 4 Sep 2009 15:21:39 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 04/09/2009 03:21:50 PM, Serialize complete at 04/09/2009 03:21:50 PM Content-Type: multipart/alternative; boundary="=_alternative 004EE2F080257627_=" Cc: homegate-bounces@ietf.org, "Livingood, Jason" , homegate@ietf.org Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 14:22:53 -0000 This is a multipart message in MIME format. --=_alternative 004EE2F080257627_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 PiBBbmQgSSBoYXZlIG5vIHByb2JsZW0gd2l0aCB0aGUgdGhpbmdzIEkgcmVhZCBpbiBSRkMgNTYy NS4gQnV0IEkgcmVhZA0KPiB0aG9zZSBhcyDigJx0aGUgaG9tZSBnYXRld2F5IG11c3Qgbm90IGlu dGVyZmVyZSB3aXRoIEROU1NFQ+KAnSwgYW5kIG5vdCANCj4g4oCcdGhlIGhvbWUgZ2F0ZXdheSBt dXN0IHN1cHBvcnQgRE5TU0VD4oCdLiBUaGVyZeKAmXMgYSBkaWZmZXJlbmNlIGJldHdlZW4NCj4g bm9uLWludGVyZmVyZW5jZSBhbmQgc3VwcG9ydC4gSSBkaWRu4oCZdCBzZWUgaW4gdGhlIFJGQyB3 aGVyZSB0aGUgDQo+IGdhdGV3YXkgbmVlZGVkIHRvIGFjdHVhbGx5IGtub3cgdGhhdCBETlNTRUMg d2FzIGhhcHBlbmluZywgYW5kIHJlYWN0DQo+IGFjY29yZGluZ2x5LiBJZiBJIG1pc3NlZCB0aGF0 IHBhcnQsIHBsZWFzZSBsZXQgbWUga25vdy4NCg0KQWgsIGluIHRoYXQgY2FzZSBJIHNlZSB3aGF0 IHlvdSBtZWFuLg0KDQpJbmRlZWQgSSB3b3VsZCByYXRoZXIgdGhhdCB0aGUgcHJveHkgZ290IG91 dCBvZiB0aGUgd2F5IGlmIGF0IGFsbCANCnBvc3NpYmxlLCBhbmQgSSB3b3VsZCBhbHNvIGFncmVl IHRoYXQgaG9tZSBnYXRld2F5cyBfc2hvdWxkbid0XyBhY3RpdmVseSANCnBhcnRpY2lwYXRlIGlu IEROU1NFQyBhdCBhbGwuDQoNClRoZSByaWdodCBwbGFjZSAoSU1ITykgZm9yIEROU1NFQyBpcyBv biB0aGUgY2xpZW50IHN0dWIsIG9yIHBvc3NpYmx5IGF0IA0KdGhlIElTUCdzIHJlY3Vyc29yLiAg SXQgc2hvdWxkbid0IGJlIG9uIHNvbWUgbWlkZGxlYm94IHNhdCBpbiB0aGUgbWlkZGxlLg0KDQpS YXkNCg0K --=_alternative 004EE2F080257627_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IEFuZCBJIGhhdmUgbm8gcHJvYmxlbSB3aXRoIHRo ZSB0aGluZ3MgSSByZWFkIGluIFJGQyA1NjI1LiBCdXQgSSByZWFkPGJyPg0KJmd0OyB0aG9zZSBh cyDigJx0aGUgaG9tZSBnYXRld2F5IG11c3Qgbm90IGludGVyZmVyZSB3aXRoIEROU1NFQ+KAnSwg YW5kDQpub3QgPGJyPg0KJmd0OyDigJx0aGUgaG9tZSBnYXRld2F5IG11c3Qgc3VwcG9ydCBETlNT RUPigJ0uIFRoZXJl4oCZcyBhIGRpZmZlcmVuY2UgYmV0d2Vlbjxicj4NCiZndDsgbm9uLWludGVy ZmVyZW5jZSBhbmQgc3VwcG9ydC4gSSBkaWRu4oCZdCBzZWUgaW4gdGhlIFJGQyB3aGVyZSB0aGUg PGJyPg0KJmd0OyBnYXRld2F5IG5lZWRlZCB0byBhY3R1YWxseSBrbm93IHRoYXQgRE5TU0VDIHdh cyBoYXBwZW5pbmcsIGFuZCByZWFjdDxicj4NCiZndDsgYWNjb3JkaW5nbHkuIElmIEkgbWlzc2Vk IHRoYXQgcGFydCwgcGxlYXNlIGxldCBtZSBrbm93LjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+QWgsIGluIHRoYXQgY2FzZSBJIHNlZSB3aGF0IHlvdSBtZWFuLjwvZm9u dD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SW5kZWVkIEkgd291bGQgcmF0aGVy IHRoYXQgdGhlIHByb3h5IGdvdCBvdXQgb2YgdGhlDQp3YXkgaWYgYXQgYWxsIHBvc3NpYmxlLCBh bmQgSSB3b3VsZCBhbHNvIGFncmVlIHRoYXQgaG9tZSBnYXRld2F5cyBfc2hvdWxkbid0Xw0KYWN0 aXZlbHkgcGFydGljaXBhdGUgaW4gRE5TU0VDIGF0IGFsbC48L2ZvbnQ+PC90dD4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPlRoZSByaWdodCBwbGFjZSAoSU1ITykgZm9yIEROU1NFQyBpcyBv biB0aGUgY2xpZW50DQpzdHViLCBvciBwb3NzaWJseSBhdCB0aGUgSVNQJ3MgcmVjdXJzb3IuICZu YnNwO0l0IHNob3VsZG4ndCBiZSBvbiBzb21lDQptaWRkbGVib3ggc2F0IGluIHRoZSBtaWRkbGUu PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5SYXk8L2ZvbnQ+PC90dD4N Cjxicj4NCg== --=_alternative 004EE2F080257627_=-- From rdroms@cisco.com Fri Sep 4 08:05:15 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D7DB28C0CF; Fri, 4 Sep 2009 08:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.777 X-Spam-Level: X-Spam-Status: No, score=-5.777 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_00=-2.599, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QReTYSl5jDSL; Fri, 4 Sep 2009 08:05:13 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C2CC03A6403; Fri, 4 Sep 2009 08:05:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAETJoEpAZnmf/2dsb2JhbADBPYhBAZA6BYQbgV0 X-IronPort-AV: E=Sophos;i="4.44,333,1249257600"; d="scan'208";a="56818441" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 04 Sep 2009 15:04:20 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n84F4KgC015450; Fri, 4 Sep 2009 11:04:20 -0400 Received: from bxb-rdroms-8714.cisco.com (bxb-rdroms-8714.cisco.com [10.98.10.85]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n84F4Fpa001355; Fri, 4 Sep 2009 15:04:20 GMT Message-Id: <6CD0B32C-A207-4BCB-AFC1-C56111E53EF4@cisco.com> From: Ralph Droms To: Ray.Bellis@nominet.org.uk In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 4 Sep 2009 11:04:10 -0400 References: <7582BC68E4994F4ABF0BD4723975C3FA0FDAB7F0@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA0FDAB9A8@crexc41p> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1508; t=1252076660; x=1252940660; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[homegate]=20Homegate=20BoF=20@=20IETF= 2076?=20Then=20we=20need=20to=20narrow=20our=09scope! |Sender:=20 |To:=20Ray.Bellis@nominet.org.uk; bh=+t/jmaOuB8WQxs3eyln2NjZN/8tNLNNMOJ24oSwMOvc=; b=LV1u5HCDSB7RJ/QW58uoNhsYxjPNQQDGWSrqhYa4kwxAS4DiesSyjADjnX 2EJTUizLWF1oBaA1/+vxBEv6vyZDkddzV50x5RHFmZyPfEx/6m4M3bS3m6bl LPZa9AnDA9; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: homegate-bounces@ietf.org, Jason Livingood , homegate@ietf.org Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 15:05:15 -0000 I agree that current home gateways interfere needlessly with DNS. However, in future deployments esp. including IPv6, uninterrupted DNS =20= service in the home may be important. Similarly, DNSSEC for hosts in =20= the home that don't have a DNSSEC stub client will be important. So, =20= I see a full DNSSEC-capable recursive resolver in the home gateway as =20= an alternative to be considered. - Ralph On Sep 4, 2009, at 10:21 AM 9/4/09, Ray.Bellis@nominet.org.uk wrote: > > > And I have no problem with the things I read in RFC 5625. But I read > > those as =93the home gateway must not interfere with DNSSEC=94, and = not > > =93the home gateway must support DNSSEC=94. There=92s a difference = between > > non-interference and support. I didn=92t see in the RFC where the > > gateway needed to actually know that DNSSEC was happening, and react > > accordingly. If I missed that part, please let me know. > > Ah, in that case I see what you mean. > > Indeed I would rather that the proxy got out of the way if at all =20 > possible, and I would also agree that home gateways _shouldn't_ =20 > actively participate in DNSSEC at all. > > The right place (IMHO) for DNSSEC is on the client stub, or possibly =20= > at the ISP's recursor. It shouldn't be on some middlebox sat in the =20= > middle. > > Ray > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate From jason_livingood@cable.comcast.com Fri Sep 4 10:17:24 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70D863A683D for ; Fri, 4 Sep 2009 10:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, PLING_QUERY=1.39, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5r19ZNEm8sNL for ; Fri, 4 Sep 2009 10:17:20 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id E93183A67FE for ; Fri, 4 Sep 2009 10:17:19 -0700 (PDT) Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.52381928; Fri, 04 Sep 2009 13:14:40 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 13:14:40 -0400 Received: from 69.249.204.17 ([69.249.204.17]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 Sep 2009 17:14:39 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 04 Sep 2009 13:14:37 -0400 From: "Livingood, Jason" To: Ray Bellis , "Stark, Barbara" Message-ID: Thread-Topic: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! Thread-Index: Acotgy4MeP9BSkfT8kWdlPsXahn/Mg== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3334914878_1067144" X-OriginalArrivalTime: 04 Sep 2009 17:14:40.0475 (UTC) FILETIME=[301E7AB0:01CA2D83] Cc: homegate@ietf.org Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 17:17:24 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3334914878_1067144 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable And, as such, we may simply find we can address this as noted below, but with somewhat more text. Jason On 9/4/09 10:21 AM, "Ray Bellis" wrote: >=20 >> > And I have no problem with the things I read in RFC 5625. But I read >> > those as =B3the home gateway must not interfere with DNSSEC=B2, and not >> > =B3the home gateway must support DNSSEC=B2. There=B9s a difference between >> > non-interference and support. I didn=B9t see in the RFC where the >> > gateway needed to actually know that DNSSEC was happening, and react >> > accordingly. If I missed that part, please let me know. >=20 > Ah, in that case I see what you mean. >=20 > Indeed I would rather that the proxy got out of the way if at all possibl= e, > and I would also agree that home gateways _shouldn't_ actively participat= e in > DNSSEC at all.=20 >=20 > The right place (IMHO) for DNSSEC is on the client stub, or possibly at t= he > ISP's recursor. It shouldn't be on some middlebox sat in the middle. >=20 Ray --B_3334914878_1067144 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our sc= ope! And, as such, we may simply find we can address this as noted below, but w= ith somewhat more text.

Jason


On 9/4/09 10:21 AM, "Ray Bellis" <Ray.Bellis@nominet.org.uk> wrote:


> And I have no problem with the things I read in RFC 5625. But I read > those as “the home gateway must not interfere with DNSSEC”= , and not
> “the home gateway must support DNSSEC”. There’s a di= fference between
> non-interference and support. I didn’t see in the RFC where the =
> gateway needed to actually know that DNSSEC was happening, and react > accordingly. If I missed that part, please let me know.

Ah, in that case I see w= hat you mean.

Indeed I would rather th= at the proxy got out of the way if at all possible, and I would also agree t= hat home gateways _shouldn't_ actively participate in DNSSEC at all.<= FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">

The right place (IMHO) f= or DNSSEC is on the client stub, or possibly at the ISP's recursor.  It= shouldn't be on some middlebox sat in the middle.

Ray --B_3334914878_1067144-- From jason_livingood@cable.comcast.com Fri Sep 4 10:35:46 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0B073A68F5 for ; Fri, 4 Sep 2009 10:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.712 X-Spam-Level: X-Spam-Status: No, score=0.712 tagged_above=-999 required=5 tests=[AWL=-4.279, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, PLING_QUERY=1.39, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUYryQSzSOSL for ; Fri, 4 Sep 2009 10:35:42 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 0BEEB3A693E for ; Fri, 4 Sep 2009 10:35:41 -0700 (PDT) Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.78269377; Fri, 04 Sep 2009 13:17:24 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 13:17:25 -0400 Received: from 69.249.204.17 ([69.249.204.17]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 Sep 2009 17:17:24 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 04 Sep 2009 13:17:22 -0400 From: "Livingood, Jason" To: "Stark, Barbara" , Message-ID: Thread-Topic: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! Thread-Index: AcorRzJMcBoLX+wtBk+JIgSW5sc65wBZCk6zAAGHTHAANIXsLA== In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0FDAB7F0@crexc41p> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3334915043_1069356" X-OriginalArrivalTime: 04 Sep 2009 17:17:25.0312 (UTC) FILETIME=[925E9C00:01CA2D83] Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 17:35:46 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3334915043_1069356 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re IPv6-related issues, we=B9re certainly aware of the work v6ops is doing on CPE routers. We may end up referring to what they are doing, or we may hav= e a different take on it since we may be describing how v4 and v6 should work in the same device (which again may overlap). In such case, we=B9ll seek the guidance of the relevant ADs, since that=B9s part of what they=B9re here for. Jason On 9/3/09 3:34 PM, "Stark, Barbara" wrote: > I have 2 concerns: > 1. IPv6 =AD v6ops is currently working on a draft identifying which IP= v6 > RFCs =B3CPE Routers=B2 (which is pretty much the same thing as a home gateway= , in > my book) need to support. Homegate=B9s claim of ownership over this topic i= s in > direct conflict. I believe these IPv6 recommendations are quite important > (just like the proposed charter says); so important that I don=B9t want to = see > in-fighting over ownership, transfer of ownership, or anything that might > derail or slow down progress. v6ops has an aggressive schedule in mind fo= r > these requirements. I do not see how homegate inserting itself into the > equation will have anything but a negative impact on the continuity of wo= rk > and timelines. --B_3334915043_1069356 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our sc= ope! Re IPv6-related issues, we’re certainly aware of the work v6ops is d= oing on CPE routers.  We may end up referring to what they are doing, o= r we may have a different take on it since we may be describing how v4 and v= 6 should work in the same device (which again may overlap).  In such ca= se, we’ll seek the guidance of the relevant ADs, since that’s pa= rt of what they’re here for.

Jason


On 9/3/09 3:34 PM, "Stark, Barbara" <= bs7652@att.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>I have 2 concerns:
1.      IPv6 – v6ops is currently working on= a draft identifying which IPv6 RFCs “CPE Routers” (which is pre= tty much the same thing as a home gateway, in my book) need to support. Home= gate’s claim of ownership over this topic is in direct conflict. I bel= ieve these IPv6 recommendations are quite important (just like the proposed = charter says); so important that I don’t want to see in-fighting over = ownership, transfer of ownership, or anything that might derail or slow down= progress. v6ops has an aggressive schedule in mind for these requirements. = I do not see how homegate inserting itself into the equation will have anyth= ing but a negative impact on the continuity of work and timelines.
--B_3334915043_1069356-- From ajs@shinkuro.com Fri Sep 4 14:32:39 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B676E3A6821 for ; Fri, 4 Sep 2009 14:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, PLING_QUERY=1.39, SARE_CSBIG=1.65] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZMHq4cDxxwP for ; Fri, 4 Sep 2009 14:32:39 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id E73753A6811 for ; Fri, 4 Sep 2009 14:32:38 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6F0192FE8CE0 for ; Fri, 4 Sep 2009 21:32:48 +0000 (UTC) Date: Fri, 4 Sep 2009 17:32:46 -0400 From: Andrew Sullivan To: homegate@ietf.org Message-ID: <20090904213246.GD21542@shinkuro.com> References: <7582BC68E4994F4ABF0BD4723975C3FA0FDAB7F0@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA0FDAB9A8@crexc41p> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 21:32:39 -0000 On Fri, Sep 04, 2009 at 03:21:39PM +0100, Ray.Bellis@nominet.org.uk wrote: > The right place (IMHO) for DNSSEC is on the client stub, or possibly at > the ISP's recursor. It shouldn't be on some middlebox sat in the middle. Well, anyway, it _needn't_ be on some clueless middlebox. I can think of a really nice deployment scenario in which the gateway does all validation, and in fact mostly replaces some of the work that would otherwise be done by the central ISP's name servers. In particular, if I were an ISP, I could see great gains to be had by adding $5 to the initial acquisition cost of a customer, who would then get a more intelligent validating box, just so that I wouldn't have to spend $BIGNUM on centralised validating resolvers. This for two reasons: 1. Centralized validators could be a fairly serious CPU hog, which effectively means much more money sunk into that service to make sure it is adequately provisioned. 2. Distributing the workload also means that a peculiar, locally-generated high load query (or series thereof) does not cause everyone's validation to slow down. Better still, I could charge extra for the "secure DNS" service for the first few years its rolling out -- premium service gets a premium box. If the end node so happens to do all its own validation as well, bully for it. But in the meantime, there's a validator out near the edge, where it is still potentially effective, unlikely to be on-path attacked (stub to validator), and not shared by every user. All of this is especially true when we think of this as SOHO-gate, as (I think it was) Paul Hoffman urged when we were in Stockholm. None of this is to say we ought to be mandating any of the above, but I see no harm in describing this use profile as part of the homegate work. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From mbaugher@cisco.com Fri Sep 4 14:39:17 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8685A3A68A4; Fri, 4 Sep 2009 14:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.077 X-Spam-Level: X-Spam-Status: No, score=-5.077 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVQveshQv2D5; Fri, 4 Sep 2009 14:39:16 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4160F3A6813; Fri, 4 Sep 2009 14:39:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAA8moUqrR7PD/2dsb2JhbADBUohBAZA8BYQbgV0 X-IronPort-AV: E=Sophos;i="4.44,334,1249257600"; d="scan'208";a="237769912" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 04 Sep 2009 21:38:29 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n84LcT44014855; Fri, 4 Sep 2009 14:38:29 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n84LcTKh022062; Fri, 4 Sep 2009 21:38:29 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 14:38:29 -0700 Received: from sjc-mbaugher-8711.cisco.com ([10.19.93.34]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 14:38:28 -0700 Message-Id: <5609DD54-5659-499C-A965-90499E6A8CAB@cisco.com> From: Mark Baugher To: Ralph Droms In-Reply-To: <6CD0B32C-A207-4BCB-AFC1-C56111E53EF4@cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 4 Sep 2009 14:38:28 -0700 References: <7582BC68E4994F4ABF0BD4723975C3FA0FDAB7F0@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA0FDAB9A8@crexc41p> <6CD0B32C-A207-4BCB-AFC1-C56111E53EF4@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 04 Sep 2009 21:38:28.0995 (UTC) FILETIME=[0AA6F530:01CA2DA8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2133; t=1252100309; x=1252964309; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20[homegate]=20Homegate=20BoF=20@=20IETF= 2076?=20Then=20we=20need=20to=20narrow=20our=09scope! |Sender:=20; bh=/xWlUmYDyD/FAOBff6orTirdGy/ol26yzPrSf7eBdJw=; b=XOdMRyseDhBquWNw8ruJaTWNnP7AE8zEtaJVNfFfd32W76kiO5yxTephpG xgs2QHOvYHYfGwBodLjrSl8LxwXM0U9Ek/2BwRrGQEN9b6VqSCRJoMNBj+6o QkycpyOdj/; Authentication-Results: sj-dkim-3; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Ray.Bellis@nominet.org.uk, homegate-bounces@ietf.org, Jason Livingood , homegate@ietf.org Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 21:39:17 -0000 On 4/09/2009, at 8:04 AM, Ralph Droms wrote: > I agree that current home gateways interfere needlessly with DNS. > > However, in future deployments esp. including IPv6, uninterrupted =20 > DNS service in the home may be important. Uninterrupted DNS service is certainly important, but so is =20 uninterrupted Internet service. So we already depend on the SP for =20 broadband service. Why not depend on them for DNS as well? Pushing lots of function into an unmanaged device is ill-advised. And =20= we are talking about an unmanaged device, for the most part. My two cents. Mark > Similarly, DNSSEC for hosts in the home that don't have a DNSSEC =20 > stub client will be important. So, I see a full DNSSEC-capable =20 > recursive resolver in the home gateway as an alternative to be =20 > considered. > > - Ralph > > On Sep 4, 2009, at 10:21 AM 9/4/09, Ray.Bellis@nominet.org.uk wrote: > >> >> > And I have no problem with the things I read in RFC 5625. But I =20 >> read >> > those as =93the home gateway must not interfere with DNSSEC=94, and = not >> > =93the home gateway must support DNSSEC=94. There=92s a difference =20= >> between >> > non-interference and support. I didn=92t see in the RFC where the >> > gateway needed to actually know that DNSSEC was happening, and =20 >> react >> > accordingly. If I missed that part, please let me know. >> >> Ah, in that case I see what you mean. >> >> Indeed I would rather that the proxy got out of the way if at all =20 >> possible, and I would also agree that home gateways _shouldn't_ =20 >> actively participate in DNSSEC at all. >> >> The right place (IMHO) for DNSSEC is on the client stub, or =20 >> possibly at the ISP's recursor. It shouldn't be on some middlebox =20= >> sat in the middle. >> >> Ray >> _______________________________________________ >> homegate mailing list >> homegate@ietf.org >> https://www.ietf.org/mailman/listinfo/homegate > > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate From ajs@shinkuro.com Fri Sep 4 15:28:40 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BDFD3A691C for ; Fri, 4 Sep 2009 15:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.135 X-Spam-Level: X-Spam-Status: No, score=-1.135 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, PLING_QUERY=1.39] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeWtEuusTwwp for ; Fri, 4 Sep 2009 15:28:39 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 84B773A687B for ; Fri, 4 Sep 2009 15:28:39 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 04DE72FE8CE0 for ; Fri, 4 Sep 2009 22:28:58 +0000 (UTC) Date: Fri, 4 Sep 2009 18:28:57 -0400 From: Andrew Sullivan To: homegate@ietf.org Message-ID: <20090904222856.GG21542@shinkuro.com> References: <7582BC68E4994F4ABF0BD4723975C3FA0FDAB7F0@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA0FDAB9A8@crexc41p> <6CD0B32C-A207-4BCB-AFC1-C56111E53EF4@cisco.com> <5609DD54-5659-499C-A965-90499E6A8CAB@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5609DD54-5659-499C-A965-90499E6A8CAB@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 22:28:40 -0000 On Fri, Sep 04, 2009 at 02:38:28PM -0700, Mark Baugher wrote: > uninterrupted Internet service. So we already depend on the SP for > broadband service. Why not depend on them for DNS as well? Speaking as a disgruntled consumer, it's because many of them have a countervailing interest to implementing DNSSEC[1]. I don't want to imagine for a moment that we can specify away people's nasty and mercenary business practices, but I do think it worthwhile to specify an interoperable way for non-mercenary ISPs to distinguish themselves consistently. A [1] For those not aware, several large ISPs do nasty things to DNS query answers in an effort to "protect" their customers. This protection quite often involves the redirection of various kinds of answers to a "landing" host, which host actually only speaks HTTP, meaning that "internet service provision" boils down to "web service provision". It turns out that there's a small but not ignored revenue stream available from this sort of redirection. Therefore, some ISPs are opposed "in principle" to pushing DNS resolution out to the end node. I am aware that there's an argument stemming from certain malware that this attempt to control DNS traffic is still warranted. I find it hard to swallow such a claim if there's no opt-out function at all. -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From iljitsch@muada.com Sun Sep 6 05:54:37 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6DA13A68D8 for ; Sun, 6 Sep 2009 05:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.741 X-Spam-Level: X-Spam-Status: No, score=-4.741 tagged_above=-999 required=5 tests=[AWL=-1.182, BAYES_00=-2.599, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4, SARE_CSBIG=1.65] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7jltdXTQ4-j for ; Sun, 6 Sep 2009 05:54:37 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id B9E063A67CF for ; Sun, 6 Sep 2009 05:54:36 -0700 (PDT) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n86Csu0d031504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 6 Sep 2009 14:54:57 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum In-Reply-To: <20090904213246.GD21542@shinkuro.com> Date: Sun, 6 Sep 2009 14:54:52 +0200 Content-Transfer-Encoding: 7bit Message-Id: <2FD9197B-0280-41EC-8548-0704FC2DB92B@muada.com> References: <7582BC68E4994F4ABF0BD4723975C3FA0FDAB7F0@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA0FDAB9A8@crexc41p> <20090904213246.GD21542@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1075.2) Cc: homegate@ietf.org Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 12:54:37 -0000 On 4 Sep 2009, at 23:32 , Andrew Sullivan wrote: > I can think of a really nice deployment scenario in which the gateway > does all validation, and in fact mostly replaces some of the work that > would otherwise be done by the central ISP's name servers. In > particular, if I were an ISP, I could see great gains to be had by > adding $5 to the initial acquisition cost of a customer, who would > then get a more intelligent validating box, just so that I wouldn't > have to spend $BIGNUM on centralised validating resolvers. This for > two reasons: I'm not disagreeing with any of this, but I am very worried about what will happen when there is a snag somewhere. I currently have a CPE that is mostly managed by my ISP, and it says that it is the DNS server in DHCP. I don't know what forwarders it uses, but I do know they're pretty crappy from time to time, triggering me to switch to OpenDNS. The problem with that is that I can't have the CPE automatically advertise the OpenDNS addresses to my hosts so I need to set it up manually, forget that it's there so I still use OpenDNS at work etc etc. Now imagine what can go wrong with DNSSEC validation. First of all, this is all quite new so prone to be buggy. Then, when OSes start to support it, the resolver libraries will start asking stuff from the integrated DNSSEC implementations that they didn't ask before, providing an opportunity to be bitten by previously unseen bugs. How are the trust anchors managed? What if there is a breakdown in the trust delegation somewhere, making it necessary to turn DNSSEC off, possibly for only part of the naming hierarchy? Do we really want something this complex and relatively unproven in an unmanaged or at best bulk-managed device? From jason_livingood@cable.comcast.com Sun Sep 6 12:40:56 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF6643A68BB; Sun, 6 Sep 2009 12:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.746 X-Spam-Level: X-Spam-Status: No, score=-2.746 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_20=-0.74, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, PLING_QUERY=1.39, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05pnMe4IlGoM; Sun, 6 Sep 2009 12:40:55 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id D635A3A68DB; Sun, 6 Sep 2009 12:40:54 -0700 (PDT) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.52522495; Sun, 06 Sep 2009 15:41:17 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Sep 2009 15:41:18 -0400 Received: from 69.249.204.17 ([69.249.204.17]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Sun, 6 Sep 2009 19:41:17 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Sun, 06 Sep 2009 15:41:16 -0400 From: "Livingood, Jason" To: Mark Baugher , Ralph Droms Message-ID: Thread-Topic: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! Thread-Index: AcovKf98fbd7nX4OBE+xba+Lf1Xnfg== In-Reply-To: <5609DD54-5659-499C-A965-90499E6A8CAB@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Sep 2009 19:41:18.0238 (UTC) FILETIME=[00D213E0:01CA2F2A] Cc: Ray Bellis , homegate-bounces@ietf.org, homegate@ietf.org Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 19:40:56 -0000 > Uninterrupted DNS service is certainly important, but so is > uninterrupted Internet service. So we already depend on the SP for > broadband service. Why not depend on them for DNS as well? > > Pushing lots of function into an unmanaged device is ill-advised. And > we are talking about an unmanaged device, for the most part. Yes, particularly when the local security of some of those devices is relatively poor (such as when many users leave the default admin p/w in place for the life of the device). Jason From jason_livingood@cable.comcast.com Sun Sep 6 12:45:46 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A59C3A690D for ; Sun, 6 Sep 2009 12:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.725 X-Spam-Level: X-Spam-Status: No, score=-3.725 tagged_above=-999 required=5 tests=[AWL=1.281, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, PLING_QUERY=1.39, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTthzFkP-U2c for ; Sun, 6 Sep 2009 12:45:45 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 6E55F3A68FE for ; Sun, 6 Sep 2009 12:45:45 -0700 (PDT) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.52522636; Sun, 06 Sep 2009 15:46:06 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Sep 2009 15:46:07 -0400 Received: from 69.249.204.17 ([69.249.204.17]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Sun, 6 Sep 2009 19:46:06 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Sun, 06 Sep 2009 15:46:05 -0400 From: "Livingood, Jason" To: Andrew Sullivan , Message-ID: Thread-Topic: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! Thread-Index: AcovKqu+ZsepoCUvlUqZ7kU0VA1hew== In-Reply-To: <20090904222856.GG21542@shinkuro.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Sep 2009 19:46:07.0868 (UTC) FILETIME=[AD741BC0:01CA2F2A] Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 19:45:46 -0000 For background, I believe Andrew primarily refers to a recent draft that's been discussed in DNSOP, so please wander over there for more discussion and take a look as well at http://tools.ietf.org/html/draft-livingood-dns-redirect-00 (to be updated in the next 30 - 45 days). Jason > Speaking as a disgruntled consumer, it's because many of them have a > countervailing interest to implementing DNSSEC[1]. I don't want to > imagine for a moment that we can specify away people's nasty and > mercenary business practices, but I do think it worthwhile to specify > an interoperable way for non-mercenary ISPs to distinguish themselves > consistently. > > A > > [1] For those not aware, several large ISPs do nasty things to DNS > query answers in an effort to "protect" their customers. This > protection quite often involves the redirection of various kinds of > answers to a "landing" host, which host actually only speaks HTTP, > meaning that "internet service provision" boils down to "web service > provision". It turns out that there's a small but not ignored revenue > stream available from this sort of redirection. Therefore, some ISPs > are opposed "in principle" to pushing DNS resolution out to the end > node. I am aware that there's an argument stemming from certain > malware that this attempt to control DNS traffic is still warranted. > I find it hard to swallow such a claim if there's no opt-out function > at all. From ajs@shinkuro.com Mon Sep 7 07:28:50 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581B93A6A1C for ; Mon, 7 Sep 2009 07:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, PLING_QUERY=1.39] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxImLNN5Pzno for ; Mon, 7 Sep 2009 07:28:49 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id A4A323A695A for ; Mon, 7 Sep 2009 07:28:49 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A5C032FE8CE2 for ; Mon, 7 Sep 2009 14:29:16 +0000 (UTC) Date: Mon, 7 Sep 2009 10:29:15 -0400 From: Andrew Sullivan To: homegate@ietf.org Message-ID: <20090907142914.GC22176@shinkuro.com> References: <7582BC68E4994F4ABF0BD4723975C3FA0FDAB7F0@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA0FDAB9A8@crexc41p> <20090904213246.GD21542@shinkuro.com> <2FD9197B-0280-41EC-8548-0704FC2DB92B@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2FD9197B-0280-41EC-8548-0704FC2DB92B@muada.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope! X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 14:28:50 -0000 On Sun, Sep 06, 2009 at 02:54:52PM +0200, Iljitsch van Beijnum wrote: > Do we really want something this complex and relatively unproven in an > unmanaged or at best bulk-managed device? Surely all of those considerations are exactly what we should be documenting, and for which we need to state the trade-offs? I'm not arguing that we should be mandating anything in this area, but it doesn't seem silly to say, "If you're going to do _X_, this is how to do it." That would doubtless include pointers to root trust anchor management, to security practices that ensure the device isn't a major vector for problems, &c. &c. If that's not the sort of work we're talking about undertaking, then I've probably misunderstood exactly what it is we were supposed to be planning to do. As others have pointed out, there are already SDOs specifying various pieces in this area, and I don't see any reason to reproduce that other work. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From lars.eggert@nokia.com Mon Sep 28 06:33:34 2009 Return-Path: X-Original-To: homegate@core3.amsl.com Delivered-To: homegate@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D2DF3A6982; Mon, 28 Sep 2009 06:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90bmnk3T9nCB; Mon, 28 Sep 2009 06:33:33 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 63B2B3A6985; Mon, 28 Sep 2009 06:33:33 -0700 (PDT) Received: from pc-a80034.wlan.inet.fi (pc-a80034.wlan.inet.fi [194.111.80.34]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n8SDYHWw063480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Sep 2009 16:34:34 +0300 (EEST) (envelope-from lars.eggert@nokia.com) From: Lars Eggert Content-Type: multipart/signed; boundary=Apple-Mail-10-955332272; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 28 Sep 2009 15:20:39 +0300 To: homegate@ietf.org Message-Id: <2D2211CA-98B6-4C0A-9892-4DC8C4079DAE@nokia.com> Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Mon, 28 Sep 2009 16:34:34 +0300 (EEST) Subject: [homegate] HOMEGATE BOF approved X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 13:33:34 -0000 --Apple-Mail-10-955332272 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, I just wanted to drop you all a quick note that after the IAB/IESG BOF call last Friday, we've approved the HOMEGATE BOF for the next IETF in Hiroshima. I'll work with the proponents on detailing the BOF agenda and assigning some BOF chairs. Lars PS: Secretariat (BCC'ed), please allocate an agenda slot for the HOMEGATE BOF. --Apple-Mail-10-955332272 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MDkyODEyMjAzOVowIwYJKoZIhvcNAQkEMRYEFPV4pljSx7DG28X7KVpbg+LTg+oWMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCvT8hhs22OpDoaBXm1KaYGBk+7kz5erzfuvc8C1kdthf6kGWDQd3ETvbrp7Xq674icNSmm CKPFXQ+AKWxTmbg7TkrS9EDOVxorKj0Ly7AtBPQxDWhtBikfNWno4KmmpqiQ/GJt1MVpWY+1sFhD IkpAvMs1RVSWuh2qoDPgaXIbYAkv8+c3iuD1iVWY6OddQCEqBbTZGWpyaMiJuYyUVjzvhrdNS+vt FzSBHdkoyVLxw3oOWGiOXco7JH461ceLfytQH6OtiR4zBVcNdxq+InUY4QA3YlEd990OcVSVOrOM I3UanZorjZDa3p1M91MNrAv6MqiXjB2MDCI+ZggPG7xvAAAAAAAA --Apple-Mail-10-955332272--