From jason_livingood@cable.comcast.com Thu Jun 4 12:11: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 04D6F3A6AFB for ; Thu, 4 Jun 2009 12:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 m8SOfBotE0kZ for ; Thu, 4 Jun 2009 12:11:49 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 221873A6951 for ; Thu, 4 Jun 2009 12:11:46 -0700 (PDT) Received: from ([10.195.246.152]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.72474027; Thu, 04 Jun 2009 15:11:28 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 15:11:28 -0400 Received: from 147.191.227.143 ([147.191.227.143]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Thu, 4 Jun 2009 19:10:33 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 04 Jun 2009 15:10:34 -0400 From: "Livingood, Jason" To: Message-ID: Thread-Topic: Test Message Thread-Index: AcnlSCK9aNayOFj+yEiOl8UmDF4tsg== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3326973034_5145950" X-OriginalArrivalTime: 04 Jun 2009 19:11:28.0316 (UTC) FILETIME=[431D27C0:01C9E548] Subject: [homegate] Test Message 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, 04 Jun 2009 19:11:50 -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_3326973034_5145950 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit This is a test message to verify that this list is functioning properly. I will send an introductory note early next week. Regards Jason Livingood --B_3326973034_5145950 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Test Message This is a test message to verify that this list is functioning properly. &= nbsp;I will send an introductory note early next week.

Regards
Jason Livingood

 --B_3326973034_5145950-- From jason_livingood@cable.comcast.com Thu Jun 4 13:07:11 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 B7DCF28C1E5 for ; Thu, 4 Jun 2009 13:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 vp+2dl+JZEfs for ; Thu, 4 Jun 2009 13:07:11 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id BC3BE3A6A0D for ; Thu, 4 Jun 2009 13:07:10 -0700 (PDT) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.40513964; Thu, 04 Jun 2009 16:06:57 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 16:06:57 -0400 Received: from 147.191.227.143 ([147.191.227.143]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Thu, 4 Jun 2009 20:06:48 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 04 Jun 2009 16:06:48 -0400 From: "Livingood, Jason" To: Message-ID: Thread-Topic: PDF of BoF Proposal Thread-Index: AcnlT/3MNVmcm3uk50m9lhkRARH+sg== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3326976410_5380954" X-OriginalArrivalTime: 04 Jun 2009 20:06:57.0912 (UTC) FILETIME=[03B52F80:01C9E550] Subject: [homegate] PDF of BoF Proposal 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, 04 Jun 2009 20:07:11 -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_3326976410_5380954 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit The PDF of the BoF proposal, which is informative to anyone joining this list, is available for your review at: http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/HomeGate%20BoF %20Proposal%20-%20IETF%2075%20-%20v7.pdf Regards Jason --B_3326976410_5380954 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable PDF of BoF Proposal The PDF of the BoF proposal, which is informative to anyone joining this l= ist, is available for your review at:
http://trac.tools.ietf.org/bof/trac/att= achment/wiki/WikiStart/HomeGate%20BoF%20Proposal%20-%20IETF%2075%20-%20v7.pd= f

Regards
Jason --B_3326976410_5380954-- From lars.eggert@nokia.com Thu Jun 11 10:51: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 5B5763A68B8 for ; Thu, 11 Jun 2009 10:51:05 -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 Jcsk-3DHR4Cd for ; Thu, 11 Jun 2009 10:51:04 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 3CA6E3A6954 for ; Thu, 11 Jun 2009 10:51:04 -0700 (PDT) Received: from [192.168.11.68] (106.Red-83-57-1.dynamicIP.rima-tde.net [83.57.1.106]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n5BHoxP1045198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Jun 2009 20:51:02 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> From: Lars Eggert To: Jason Livingood , David Oran In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-8-147484997; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 19:50:57 +0200 References: X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Thu, 11 Jun 2009 20:51:07 +0300 (EEST) Cc: "iesg@ietf.org IESG" , ipdir@ietf.org, IAB IAB , homegate@ietf.org, TSV Dir Subject: Re: [homegate] PDF of BoF Proposal 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, 11 Jun 2009 17:51:05 -0000 --Apple-Mail-8-147484997 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, the IESG and IAB have discussed this BOF proposal today, and I have decided to not accept this BOF for Stockholm. That said, I believe that the IETF should spin up work in this space, and my impression was that much of the IESG and IAB shared that opinion. The decision to turn down the BOF proposal for Stockholm was based on other factors: First, the proposed work needs to be focused and detailed more, it is currently still too broad for an IETF effort and some of it is still unclear. (There is no charter proposal, for example.) Second, because other industry forums and SDOs have been producing specifications in this space (DLS Forum, CableLabs, UPnP Forum, Wimax Forum, etc.), it will be important to identify where we will overlap with them and where we can complement their efforts. Third, it is currently not clear how substantial the community is that would participate in an IETF effort in this space. Traffic on the mailing list has been absent, and I have also received only very few direct emails about it. This effort may require more socializing. In order to get this work to a point where we can BOF it, I'd be very happy to offer time in the transport area area open meeting in Stockholm to discuss this effort. Another alternative may be the Internet area open meeting, because the proposed work touches on both areas. Instead of these open meeting discussion (or in addition to them), I'm also happy to get you a room for a bar BOF, if you like. The idea is to raise interest in this work in Stockholm and discuss the issues I've identified above, in order to form a community around this work that will carry it to a successful BOF at IETF-76 in Hiroshima. I'm looking forward to help the effort along as best as I can. Lars --Apple-Mail-8-147484997 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA2MTExNzUwNTdaMCMGCSqGSIb3DQEJBDEWBBRGGMH/CUXrBvc/ xdU3mrX9AsuJnjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEATxU+MzGDMgyU/F+o7hOH/qj3K+vo8awlZ93RbYPnJlarvTBofK1V yDD4Ud5hYLGbCss7pxW7CF0958jJndU01rm+g11T7zb1MYNbhbZVVOb5zg1fQUDmdieymXhtmjMb KIWqSqnUPa6lQURbDngmzKc7B+GrypxNxwch+bI9JN03IN8dNj4W9L55JgMxbMB4yDNQ7jHpIE3e uiLe7hXeUopxLaIQcZ2dW2er3bGUvFnkdXM4ZoiSaCj+WWlV/tI2LuAjAoKFpF1LF8MLt7/qwX8z IZMXxFjSryeC/ulDMuLWLWo6Q5sWo3fbJVrVWMZJe05BjkEJGx8qEkxGP6Fs4QAAAAAAAA== --Apple-Mail-8-147484997-- From garmitage@swin.edu.au Thu Jun 11 15:16: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 435FE3A6BFC; Thu, 11 Jun 2009 15:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 3I5OmKb4olJK; Thu, 11 Jun 2009 15:16:42 -0700 (PDT) Received: from gpo4.cc.swin.edu.au (gpo4.cc.swin.edu.au [136.186.1.33]) by core3.amsl.com (Postfix) with ESMTP id 4EEB13A6BA3; Thu, 11 Jun 2009 15:16:41 -0700 (PDT) Received: from [127.0.0.1] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo4.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id n5BMGLms017717; Fri, 12 Jun 2009 08:16:40 +1000 Message-ID: <4A3182AE.9040508@swin.edu.au> Date: Fri, 12 Jun 2009 08:18:22 +1000 From: grenville armitage User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Lars Eggert , Jason Livingood References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> In-Reply-To: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homegate@ietf.org, ipdir@ietf.org, IAB IAB , "iesg@ietf.org IESG" , TSV Dir Subject: Re: [homegate] PDF of BoF Proposal 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, 11 Jun 2009 22:16:43 -0000 Lars Eggert wrote: [..] > Third, it is currently not clear how substantial the community is that > would participate in an IETF effort in this space. Traffic on the > mailing list has been absent, and I have also received only very few > direct emails about it. This effort may require more socializing. I wonder how many people (like me) subscribed when we first saw the mailing list announced last week on ietf@ietf.org, and have since been waiting to have someone kick off discussions. cheers, gja From mail@sabahattin-gucukoglu.com Thu Jun 11 15:29:07 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 93FA53A6D93 for ; Thu, 11 Jun 2009 15:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=1.055, 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 1wEEfQ6Jz2Mj for ; Thu, 11 Jun 2009 15:29:06 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 8B5C33A6D24 for ; Thu, 11 Jun 2009 15:29:06 -0700 (PDT) Received: by ewy6 with SMTP id 6so2453492ewy.37 for ; Thu, 11 Jun 2009 15:29:12 -0700 (PDT) Received: by 10.216.15.85 with SMTP id e63mr1066026wee.199.1244759351891; Thu, 11 Jun 2009 15:29:11 -0700 (PDT) Received: from ?192.168.1.3? (62-30-111-115.cable.ubr07.dals.blueyonder.co.uk [62.30.111.115]) by mx.google.com with ESMTPS id p37sm874938gvf.12.2009.06.11.15.29.10 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Jun 2009 15:29:11 -0700 (PDT) Resent-To: homegate@ietf.org From: Sabahattin Gucukoglu To: Lars Eggert In-Reply-To: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> Resent-From: Sabahattin Gucukoglu References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> Message-Id: <83282EBF-92AC-45B5-9051-45DFE84799AC@sabahattin-gucukoglu.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Resent-Date: Thu, 11 Jun 2009 23:29:09 +0100 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 22:34:33 +0100 X-Mailer: Apple Mail (2.935.3) Resent-Message-Id: <20090611222906.8B5C33A6D24@core3.amsl.com> Subject: Re: [homegate] PDF of BoF Proposal 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, 11 Jun 2009 22:29:07 -0000 Sorry, I was expecting a roundup before discussion began on homegate. I do think a lot of this should be standardised behaviour, and that IETF is the place to standardise it. In particular, v6 security policy and v4 traversal issues need standardising in a way favourable to IETF participants and by extension the net community (EG: v6 defaulted, UPnP alternative). I cannot speak for media protocols, that's for ITU or cable forum or whoever it is. But I wanted to signify my interest in consensus-driven practices, though I can't attend IETF sessions yet. Is there an alternative format for the PDF proposal? I think I may not have read the entire thing (I'm using clumsy access with a screen reader at the moment and haven't installed pdf2txt). Cheers, Sabahattin From carolin.latze@unifr.ch Thu Jun 11 23:59:09 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 E3B153A6B72 for ; Thu, 11 Jun 2009 23:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.307 X-Spam-Level: X-Spam-Status: No, score=-5.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 Yn+PO8tWI0rg for ; Thu, 11 Jun 2009 23:59:09 -0700 (PDT) Received: from siufsrv105.unifr.ch (siufsrv105.unifr.ch [134.21.14.71]) by core3.amsl.com (Postfix) with ESMTP id 0CCAA3A6AAA for ; Thu, 11 Jun 2009 23:59:09 -0700 (PDT) Received: from sr-blw-202.unifr.ch ([134.21.40.65]) by siufsrv105.unifr.ch stage1 with esmtp with id 1MF0j7-0000W8-AG from ; Fri, 12 Jun 2009 08:59:01 +0200 Received: from [134.21.34.136] (134.21.34.136) by post.unifr.ch (134.21.39.51) with Microsoft SMTP Server id 8.1.375.2; Fri, 12 Jun 2009 08:59:00 +0200 Message-ID: <4A31FCB3.7080607@unifr.ch> Date: Fri, 12 Jun 2009 08:58:59 +0200 From: Carolin Latze User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> <4A3182AE.9040508@swin.edu.au> In-Reply-To: <4A3182AE.9040508@swin.edu.au> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: Jason Livingood , "homegate@ietf.org" Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 06:59:10 -0000 grenville armitage wrote: > Lars Eggert wrote: > [..] > >> Third, it is currently not clear how substantial the community is that >> would participate in an IETF effort in this space. Traffic on the >> mailing list has been absent, and I have also received only very few >> direct emails about it. This effort may require more socializing. >> > > I wonder how many people (like me) subscribed when we first saw > the mailing list announced last week on ietf@ietf.org, and have since > been waiting to have someone kick off discussions. > tbh I also expected somebody of the authors of the BOF proposal to kick off the discussion. If it up to the silent listeners to start it, I will do it now :-) I think that the topic is very important and interesting, but I am not sure, the IETF is the right place for it. For me it sounds like the only thing you can standardize here is something like "A home gateway has to support protocol X, Y, and Z" and I don't see that there is the need to form a WG to do that. The protocol standards exist and most of the home gateways support them (or a subset of them), so why do we need another standard here? What did I miss here? BTW I am sure whether I got it right, but a home gateway here is more or less that what xDSL modems are today? I mean, something that serves as a router for your local network and gateway to the internet? Carolin From henk@ripe.net Fri Jun 12 00:09:32 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 6D13228C133; Fri, 12 Jun 2009 00:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.418 X-Spam-Level: X-Spam-Status: No, score=-7.418 tagged_above=-999 required=5 tests=[AWL=3.181, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 m5YOPPk-r9he; Fri, 12 Jun 2009 00:09:31 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id F2BC828C148; Fri, 12 Jun 2009 00:09:30 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MF0tB-0005FK-LW; Fri, 12 Jun 2009 09:09:31 +0200 Received: from geir-3.local (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id 992582F595; Fri, 12 Jun 2009 09:09:25 +0200 (CEST) Message-ID: <4A31EDD1.8000202@ripe.net> Date: Fri, 12 Jun 2009 07:55:29 +0200 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: grenville armitage References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> <4A3182AE.9040508@swin.edu.au> In-Reply-To: <4A3182AE.9040508@swin.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5fba03c76d2b5b7c3b74cbfa941e57e7a Cc: homegate@ietf.org, ipdir@ietf.org, IAB IAB , "iesg@ietf.org IESG" , TSV Dir , Jason Livingood Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 07:09:32 -0000 grenville armitage wrote: > Lars Eggert wrote: > [..] >> Third, it is currently not clear how substantial the community is that >> would participate in an IETF effort in this space. Traffic on the >> mailing list has been absent, and I have also received only very few >> direct emails about it. This effort may require more socializing. > > I wonder how many people (like me) subscribed when we first saw > the mailing list announced last week on ietf@ietf.org, and have since > been waiting to have someone kick off discussions. I agree, the PDF looked interesting, so I put myself on the list and waited for a kick-off. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Belgium: an unsolvable problem, discussed in endless meetings, with no hope for a solution, where everybody still lives happily. From muraris@microsoft.com Fri Jun 12 00:18: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 DD9C628C16A; Fri, 12 Jun 2009 00:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.49 X-Spam-Level: X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ZYlifJnl+LFy; Fri, 12 Jun 2009 00:18:03 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id BDE5428C159; Fri, 12 Jun 2009 00:18:03 -0700 (PDT) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Fri, 12 Jun 2009 00:17:11 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.162]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.88.96]) with mapi; Fri, 12 Jun 2009 00:17:11 -0700 From: Murari Sridharan To: Henk Uijterwaal , grenville armitage Date: Fri, 12 Jun 2009 00:17:10 -0700 Thread-Topic: [homegate] PDF of BoF Proposal Thread-Index: AcnrLO8u8N/5YHb2TZ6mGipy7MXYMgAAMH/A Message-ID: References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> <4A3182AE.9040508@swin.edu.au> <4A31EDD1.8000202@ripe.net> In-Reply-To: <4A31EDD1.8000202@ripe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homegate@ietf.org" , "ipdir@ietf.org" , IAB IAB , "iesg@ietf.org IESG" , TSV Dir , Jason Livingood Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 07:18:04 -0000 PDF definitely looked interesting, a bit too broad but I assumed scoping di= scussions would start to happen on the mailing lists.=20 Murari=20 -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behal= f Of Henk Uijterwaal Sent: Thursday, June 11, 2009 10:55 PM To: grenville armitage Cc: homegate@ietf.org; ipdir@ietf.org; IAB IAB; iesg@ietf.org IESG; TSV Dir= ; Jason Livingood Subject: Re: [homegate] PDF of BoF Proposal grenville armitage wrote: > Lars Eggert wrote: > [..] >> Third, it is currently not clear how substantial the community is that=20 >> would participate in an IETF effort in this space. Traffic on the=20 >> mailing list has been absent, and I have also received only very few=20 >> direct emails about it. This effort may require more socializing. >=20 > I wonder how many people (like me) subscribed when we first saw > the mailing list announced last week on ietf@ietf.org, and have since=20 > been waiting to have someone kick off discussions. I agree, the PDF looked interesting, so I put myself on the list and waited for a kick-off. Henk --=20 ---------------------------------------------------------------------------= --- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.ne= t RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ---------------------------------------------------------------------------= --- Belgium: an unsolvable problem, discussed in endless meetings, with no hope for a solution, where everybody still lives happily. _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate From richard@bennett.com Fri Jun 12 03:45:09 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 BE9FF3A6CC0 for ; Fri, 12 Jun 2009 03:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 lsH3lXb+tNrk for ; Fri, 12 Jun 2009 03:45:08 -0700 (PDT) Received: from outbound-mail-308.bluehost.com (outbound-mail-308.bluehost.com [67.222.53.254]) by core3.amsl.com (Postfix) with SMTP id 6B7853A6A70 for ; Fri, 12 Jun 2009 03:45:08 -0700 (PDT) Received: (qmail 17930 invoked by uid 0); 12 Jun 2009 10:45:16 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy6.bluehost.com with SMTP; 12 Jun 2009 10:45:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-MimeOLE:Thread-Index:X-Identified-User; b=MePrAIbLreH46DDRpYRurhmD32mLqP5AMiBaBh/ge7T0L+PmfJgBwMT6Ea8yCtgBRjTWBGCJGDZKrR+fgS11QKNusjk7mAfeKtkRGkRJPATeZdRmuJXNAq5hYklhDvXd; Received: from c-24-5-230-26.hsd1.ca.comcast.net ([24.5.230.26] helo=Honkin) by host46.hostmonster.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MF4G3-0004a6-CL; Fri, 12 Jun 2009 04:45:15 -0600 From: "Richard Bennett" To: "'Murari Sridharan'" , "'Henk Uijterwaal'" , "'grenville armitage'" References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com><4A3182AE.9040508@swin.edu.au> <4A31EDD1.8000202@ripe.net> In-Reply-To: Date: Fri, 12 Jun 2009 03:45:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Thread-Index: AcnrLO8u8N/5YHb2TZ6mGipy7MXYMgAAMH/AAAYOYcA= X-Identified-User: {:host46.hostmonster.com:judith+bennett.com:} {sentby:bopbeforesmtp 24.5.230.26 authed with judith+bennett.com} Cc: homegate@ietf.org, ipdir@ietf.org, 'IAB IAB' , iesg@ietf.org, 'TSV Dir' , 'Jason Livingood' Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 10:45:09 -0000 Could be that the authors are busy or off the net at the moment, they'll have to speak for that. From my own experience as an engineer who until recently worked for a home gateway company in a product development role, I think this is a vital piece of work and an area where IETF could make a huge positive impact with less effort than is involved in several other areas. Home gateways are the combinations of a NAT, an Ethernet switch, a Wi-Fi access point, and some sort of WAN connection, which can be either a DSL adapter, a cable modem, or a connection to an external layer two device reached over a separate Ethernet connection or something more obscure like MoCA. They're very low margin products, so the companies that produce them tend to have more expertise at manufacturing than engineering, and very little expertise specific to IETF protocols. The norm in the industry is engineering managers who understand DSL but not DHCP and certainly not DSCP. If you asked one to explain MPLS they would probably tell you it's the sister city of St. Paul. A sub-sector of that industry builds specialized gateways for telcos that includes a suite of management protocol called things like TR069 and TR098, which were defined by the DSL Forum (now called the Broadband Forum) because they didn't understand SNMP. The "TR" protocols have a very bizarre object model that bears a minimal resemblance to any actual network devices, and uses SOAP and XML instead of ASN.1. The one good thing about it is that it can used to download firmware updates the ISP wants to get out. The software in these boxes is open source combinations of Linux kernels, busybox, and the related networking pieces, packaged with proprietary TR069 components. The principal packagers are Broadcom and Jungo. >From the perspective of the engineering managers and customers, the software is at best a nuisance, as they view their hardware and manufacturing processes as the primary value of the boxes. Hardware tends to be designed according to reference designs from the chip companies. Specs in this industry are laughably terse, generally consisting of Excel spreadsheets that describe complete functional subsystems with two or three garbled sentences. They're very heavy on buzzwords. It's a miracle that most of these products don't explode the first time they're powered on. The value of this BOF and eventual working group would be to define a thorough BCP for the software components that go into home gateways. The management protocol is pretty hopeless, but probably 75% of the code can be drastically improved if the right people were to write a spec that described the proper revisions, options, and features for the IETF protocols involved. ECN was mentioned prominently in the PDF, and I can guarantee you personally that there is no knowledge of ECN or why anybody would want it in the home gateway industry. But if the IETF produces a BCP that says "Home gateways should not halt and catch fire if they receive an IPv4 packet with ECN set," the next round of RFPs from the telcos and other ISPs to the gateway vendors would include that requirement and the products would conform. I don't think it's realistic to try and slough this work off on UPnP or DLNA, as those organizations are very application-oriented and don't have great awareness of IETF protocols either. I personally sat through a whole series of teleconference in which DLNA leaders proposed to limit MTU sizes to 1000 octets because they didn't know how to do Path MTU discovery, such a new thing it's only been specified since RFC 1191. According to DLNA, the de facto standard protocol for streaming Internet video is HTTP, not RTP/RTSP. The DNSSEC people have tested home gateways for compliance and found none of them can handle UDP-framed request packets larger than 512 bytes. The home gateway response is "what's DNSSEC?" I went to work in that particular segment because it seemed to me that it's dragging down the whole Internet because it installs obsolete protocols in hundreds of millions of homes and small offices around the world. I quickly found that one person was not going to make much of a difference, and now feel that it's an urgent priority for IETF to show some leadership in this area. And believe me, if you don't, nobody else will and we'll all just keep on complaining about the fact at ECN languishes even though it's been a draft standard since 2001 (RFC 3168), and similar fate will befall DNSSEC. This is important work and it deserves some serious attention. Richard Bennett -----Original Message----- From: Murari Sridharan [mailto:muraris@microsoft.com] Sent: Friday, June 12, 2009 12:17 AM To: Henk Uijterwaal; grenville armitage Cc: homegate@ietf.org; ipdir@ietf.org; IAB IAB; iesg@ietf.org IESG; TSV Dir; Jason Livingood Subject: Re: [homegate] PDF of BoF Proposal PDF definitely looked interesting, a bit too broad but I assumed scoping discussions would start to happen on the mailing lists. Murari -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behalf Of Henk Uijterwaal Sent: Thursday, June 11, 2009 10:55 PM To: grenville armitage Cc: homegate@ietf.org; ipdir@ietf.org; IAB IAB; iesg@ietf.org IESG; TSV Dir; Jason Livingood Subject: Re: [homegate] PDF of BoF Proposal grenville armitage wrote: > Lars Eggert wrote: > [..] >> Third, it is currently not clear how substantial the community is that >> would participate in an IETF effort in this space. Traffic on the >> mailing list has been absent, and I have also received only very few >> direct emails about it. This effort may require more socializing. > > I wonder how many people (like me) subscribed when we first saw > the mailing list announced last week on ietf@ietf.org, and have since > been waiting to have someone kick off discussions. I agree, the PDF looked interesting, so I put myself on the list and waited for a kick-off. Henk -- ---------------------------------------------------------------------------- -- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ---------------------------------------------------------------------------- -- Belgium: an unsolvable problem, discussed in endless meetings, with no hope for a solution, where everybody still lives happily. _______________________________________________ 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 bernard_aboba@hotmail.com Fri Jun 12 02:17: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 19FE23A6A69; Fri, 12 Jun 2009 02:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Dcm7oYeVPRgx; Fri, 12 Jun 2009 02:17:38 -0700 (PDT) Received: from blu0-omc2-s15.blu0.hotmail.com (blu0-omc2-s15.blu0.hotmail.com [65.55.111.90]) by core3.amsl.com (Postfix) with ESMTP id C449B3A6925; Fri, 12 Jun 2009 02:17:37 -0700 (PDT) Received: from BLU137-W6 ([65.55.111.73]) by blu0-omc2-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 02:17:45 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_701cb626-207c-45b1-bf40-ca0be230ac05_" X-Originating-IP: [24.16.113.61] From: Bernard Aboba To: , , Date: Fri, 12 Jun 2009 02:17:45 -0700 Importance: Normal In-Reply-To: References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> <4A3182AE.9040508@swin.edu.au> <4A31EDD1.8000202@ripe.net> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jun 2009 09:17:45.0919 (UTC) FILETIME=[A5D0BCF0:01C9EB3E] X-Mailman-Approved-At: Fri, 12 Jun 2009 03:57:28 -0700 Cc: homegate@ietf.org, ipdir@ietf.org, iab@iab.org, "iesg@ietf.org" , tsv-dir@ietf.org Subject: Re: [homegate] [tsv-dir] PDF of BoF Proposal 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, 12 Jun 2009 09:17:39 -0000 --_701cb626-207c-45b1-bf40-ca0be230ac05_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lack of a "kick-off" indicates that the people whose career is focused on h= ome gateways were not sufficiently motivated to participate to bring the effort to critical m= ass.=20 Ideally an outreach effort would include not only the organizations that fo= cus on=20 standardization of aspects of home gateways=2C but also the implementers of= home gateway products. =20 Given the razor thin margins of the home gateway industry=2C structuring th= e effort to cater to remote participants (e.g. virtual interim meetings) wouldn't hu= rt either.=20 > -----Original Message----- > From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Beh= alf Of Henk Uijterwaal > Sent: Thursday=2C June 11=2C 2009 10:55 PM > To: grenville armitage > Cc: homegate@ietf.org=3B ipdir@ietf.org=3B IAB IAB=3B iesg@ietf.org IESG= =3B TSV Dir=3B Jason Livingood > Subject: Re: [homegate] PDF of BoF Proposal >=20 > grenville armitage wrote: > > Lars Eggert wrote: > > [..] > >> Third=2C it is currently not clear how substantial the community is th= at=20 > >> would participate in an IETF effort in this space. Traffic on the=20 > >> mailing list has been absent=2C and I have also received only very few= =20 > >> direct emails about it. This effort may require more socializing. > >=20 > > I wonder how many people (like me) subscribed when we first saw > > the mailing list announced last week on ietf@ietf.org=2C and have since= =20 > > been waiting to have someone kick off discussions. >=20 > I agree=2C the PDF looked interesting=2C so I put myself on the list and > waited for a kick-off. >=20 > Henk >=20 >=20 >=20 > --=20 > -------------------------------------------------------------------------= ----- > Henk Uijterwaal Email: henk.uijterwaal(at)ripe.= net > RIPE Network Coordination Centre http://www.xs4all.nl/~henku > P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands The Netherlands Mobile: +31.6.55861746 > -------------------------------------------------------------------------= ----- >=20 > Belgium: an unsolvable problem=2C discussed in endless meetings=2C with n= o > hope for a solution=2C where everybody still lives happily. >=20 > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate >=20 --_701cb626-207c-45b1-bf40-ca0be230ac05_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lack of a "kick-off" indicates that the people whose career is focused on h= ome gateways were
not sufficiently motivated to participate to bring the= effort to critical mass.

Ideally an outreach effort would include = not only the organizations that focus on
standardization of aspects of = home gateways=2C but also the implementers of home
gateway products.&nbs= p=3B

Given the razor thin margins of the home gateway industry=2C s= tructuring the effort
to cater to remote participants (e.g. virtual inte= rim meetings) wouldn't hurt
either.

>=3B -----Original Message= -----
>=3B From: homegate-bounces@ietf.org [mailto:homegate-bounces@ie= tf.org] On Behalf Of Henk Uijterwaal
>=3B Sent: Thursday=2C June 11=2C= 2009 10:55 PM
>=3B To: grenville armitage
>=3B Cc: homegate@ietf= .org=3B ipdir@ietf.org=3B IAB IAB=3B iesg@ietf.org IESG=3B TSV Dir=3B Jason= Livingood
>=3B Subject: Re: [homegate] PDF of BoF Proposal
>=3B =
>=3B grenville armitage wrote:
>=3B >=3B Lars Eggert wrote:>=3B >=3B [..]
>=3B >=3B>=3B Third=2C it is currently not= clear how substantial the community is that
>=3B >=3B>=3B would = participate in an IETF effort in this space. Traffic on the
>=3B >= =3B>=3B mailing list has been absent=2C and I have also received only ver= y few
>=3B >=3B>=3B direct emails about it. This effort may requi= re more socializing.
>=3B >=3B
>=3B >=3B I wonder how many p= eople (like me) subscribed when we first saw
>=3B >=3B the mailing l= ist announced last week on ietf@ietf.org=2C and have since
>=3B >= =3B been waiting to have someone kick off discussions.
>=3B
>=3B= I agree=2C the PDF looked interesting=2C so I put myself on the list and>=3B waited for a kick-off.
>=3B
>=3B Henk
>=3B
>= =3B
>=3B
>=3B --
>=3B -----------------------------------= -------------------------------------------
>=3B Henk Uijterwaal = Email: henk.uijterwaal(at)ripe.net
>=3B RIPE Netw= ork Coordination Centre http://www.xs4all.nl/~henku
>=3B P.O.= Box 10096 Singel 258 Phone: +31.20.5354414
>=3B 1001 = EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445
>=3B The Neth= erlands The Netherlands Mobile: +31.6.55861746
>=3B --------= ----------------------------------------------------------------------
&= gt=3B
>=3B Belgium: an unsolvable problem=2C discussed in endless mee= tings=2C with no
>=3B hope for a solution=2C where everybody= still lives happily.
>=3B
>=3B ________________________________= _______________
>=3B homegate mailing list
>=3B homegate@ietf.org=
>=3B https://www.ietf.org/mailman/listinfo/homegate
>=3B
= --_701cb626-207c-45b1-bf40-ca0be230ac05_-- From lars.eggert@nokia.com Fri Jun 12 09:45: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 661F63A68FB; Fri, 12 Jun 2009 09:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 z-3odorRLagy; Fri, 12 Jun 2009 09:45:48 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 3DD5F3A67AF; Fri, 12 Jun 2009 09:45:48 -0700 (PDT) Received: from [192.168.0.198] (wlan.fit.nokia.com [195.148.124.254]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n5CGjLBF062493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Jun 2009 19:45:22 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <2E30BCA2-A95F-47B5-851D-00F2371C7DB3@nokia.com> From: Lars Eggert To: grenville armitage In-Reply-To: <4A3182AE.9040508@swin.edu.au> Content-Type: multipart/signed; boundary=Apple-Mail-4-229944494; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 18:45:16 +0200 References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> <4A3182AE.9040508@swin.edu.au> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Fri, 12 Jun 2009 19:45:22 +0300 (EEST) Cc: "homegate@ietf.org" , "ipdir@ietf.org" , IAB IAB , "iesg@ietf.org IESG" , TSV Dir , Jason Livingood Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 16:45:49 -0000 --Apple-Mail-4-229944494 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-6-12, at 0:18, grenville armitage wrote: > I wonder how many people (like me) subscribed when we first saw > the mailing list announced last week on ietf@ietf.org, and have since > been waiting to have someone kick off discussions. that discussion seems to have started now, which I'm very happy about. Andrew made a good proposal in his email: let's use the time before Stockholm to start working out what should be done, have an informal meeting in Stockholm with whoever is there to discuss things in person, and aim for a BOF in Hiroshima. Lars --Apple-Mail-4-229944494 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA2MTIxNjQ1MTdaMCMGCSqGSIb3DQEJBDEWBBTt8YJRAB7RtjO+ oOjIuD3eqHHLtTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAKjPDffRqrDJC7c57m8AOd3P9YdP4P27F/T6p5wKJCZA8XC0zB01q /Rl7VuO1zwXINRbKVTv3/UWd6cshLkhEs1pguK5b5YT4OxVao2XWgJ9nTtcN3AqfhHovtDi4yBQV Ro1bmTvFPUxE3DM7ADvKANK4Vtsh+ByK7u0yfuAswH/oi9iob8dtMaWq1jpM5MCMOkQetnULUKR5 I9S1TLRsM/a+qloMDAHBc3WKyYwE9qV41AEciDxxS1rVAVBudWUqQQyR81WywaJeOIXFBMowUUjt ueZ3Jpg0nCt0faPuqgjwNv5x1NwSa+/objLsmeKnV9YMNyfThBIq7IPyZNim9wAAAAAAAA== --Apple-Mail-4-229944494-- From lars.eggert@nokia.com Fri Jun 12 09:50: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 8D35028C196 for ; Fri, 12 Jun 2009 09:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 nk+PE4JX0bwE for ; Fri, 12 Jun 2009 09:50:04 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 6747528C1D6 for ; Fri, 12 Jun 2009 09:50:04 -0700 (PDT) Received: from [192.168.0.198] (wlan.fit.nokia.com [195.148.124.254]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n5CGo48Z062619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Jun 2009 19:50:05 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Carolin Latze In-Reply-To: <4A31FCB3.7080607@unifr.ch> Content-Type: multipart/signed; boundary=Apple-Mail-5-230227583; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 18:49:59 +0200 References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> <4A3182AE.9040508@swin.edu.au> <4A31FCB3.7080607@unifr.ch> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Fri, 12 Jun 2009 19:50:05 +0300 (EEST) Cc: Jason Livingood , "homegate@ietf.org" Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 16:50:05 -0000 --Apple-Mail-5-230227583 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-6-12, at 8:58, Carolin Latze wrote: > I think that the topic is very important and interesting, but I am not > sure, the IETF is the right place for it. For me it sounds like the > only > thing you can standardize here is something like "A home gateway has > to > support protocol X, Y, and Z" and I don't see that there is the need > to > form a WG to do that. The protocol standards exist and most of the > home > gateways support them (or a subset of them), so why do we need another > standard here? What did I miss here? the protocol specifications are there, but some if not many home routers don't implement what some of us would consider the minimal subset of modern Internet functionality, and sometimes what they try and implement is buggy (braindead queueing, no ECN, no DNS over TCP or EDNS0, DHCP oddities, etc., etc.) The idea isn't for this effort to do major (or maybe even any) protocol work; the idea is to document what the IETF believes a home gateway should implement at the minimum, and maybe at the optimum. A set of BCPs seems to be the correct vessel for this. > BTW I am sure whether I got it right, but a home gateway here is > more or > less that what xDSL modems are today? I mean, something that serves > as a > router for your local network and gateway to the internet? Correct. Thanks, Lars --Apple-Mail-5-230227583 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA2MTIxNjQ5NjBaMCMGCSqGSIb3DQEJBDEWBBSbRCalAITiYqD6 XRoEEUSrsJIwdDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAB9PD8x/HKTHY1NDwdFSO5V7PkIQ8Xw5Unma2jCYYcmLC4Nkktu5U cA5vynjHsjn6osH3NvMQslNB49tAYNTVIZ5lkBPx8Shvj7DVF41MQ3Nrgh7+a+KZBkGJROEH7LEA 4G1h1eSua+ab1mWvpxSTWWmjz1q+hXFpgRtPW3U/zrTxTqKdw3by7MtkfcNXUpWIXE41iEqNQall gPZAiMIJPgIn5HiQqk2Bu2JerLpJLV7xthoWjy9x1WklRkCT/RYk5W+UarMDBMYQbT1lLPIEckbe JdYvNKnUwJR1NK55JfyHO3JmBwIxlDSsc1cw52W4nAJSWOiGSBClsfPjm1dVdgAAAAAAAA== --Apple-Mail-5-230227583-- From kirk.erichsen@twcable.com Fri Jun 12 09:52:42 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 F139928C233; Fri, 12 Jun 2009 09:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 d3Vile2t9wky; Fri, 12 Jun 2009 09:52:42 -0700 (PDT) Received: from pblpas02.twcable.com (pblpas02.twcable.com [204.235.121.150]) by core3.amsl.com (Postfix) with ESMTP id 7F06F28C22D; Fri, 12 Jun 2009 09:52:42 -0700 (PDT) X-SENDER-IP: 10.157.247.211 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,210,1243828800"; d="scan'208";a="421628117" Received: from unknown (HELO prvpmailconn1.corp.twcable.com) ([10.157.247.211]) by pblpas02.twcable.com with ESMTP; 12 Jun 2009 12:51:50 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn1.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 12:51:50 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Jun 2009 12:49:18 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] PDF of BoF Proposal thread-index: AcnrfVkWYw1CLfe/SzKkqD+AhqOkigAAGFL0 References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com><4A3182AE.9040508@swin.edu.au> <2E30BCA2-A95F-47B5-851D-00F2371C7DB3@nokia.com> From: "Erichsen, Kirk" To: "Lars Eggert" , "grenville armitage" X-OriginalArrivalTime: 12 Jun 2009 16:51:50.0105 (UTC) FILETIME=[149D9C90:01C9EB7E] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: homegate@ietf.org, ipdir@ietf.org, IAB IAB , iesg@ietf.org, TSV Dir , Jason Livingood Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 16:52:43 -0000 SSB0b28gZGFmdGx5IGFzc3VtZWQgc29tZXRoaW5nIHdvdWxkIGJlIHRyYW5zbWl0dGVkIHRvIHRo ZSBsaXN0IGFmdGVyIEkgam9pbmVkIHRvIGtpY2sgdGhpbmdzIG9mZiwgYnV0IHRoYXQgd2FzIGEg cGFzc2l2ZSB2aWV3IHBvaW50LiBJIGNvbmN1ciB3aXRoIEFuZHJldyBvbiBpbml0aWF0aW5nIGFu IGVmZm9ydCBhbmQgd29yayB0b3dhcmRzIHRoZSBuZXh0IG1lZXRpbmcgdG8gcGVyaGFwcyBmaW5h bGl6ZSBzb21lIG9mIHRoZSBkZXRhaWxzIG9mIHRoZSBkb2N1bWVudCBpdHNlbGYgYW5kIHBlcmhh cHMgZXZlbiB0aGUgY2hhcnRlci4KIAotS0UKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCgpGcm9tOiBob21lZ2F0ZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBMYXJzIEVn Z2VydApTZW50OiBGcmkgNi8xMi8yMDA5IDEwOjQ1IEFNClRvOiBncmVudmlsbGUgYXJtaXRhZ2UK Q2M6IGhvbWVnYXRlQGlldGYub3JnOyBpcGRpckBpZXRmLm9yZzsgSUFCIElBQjsgaWVzZ0BpZXRm Lm9yZyBJRVNHOyBUU1YgRGlyOyBKYXNvbiBMaXZpbmdvb2QKU3ViamVjdDogUmU6IFtob21lZ2F0 ZV0gUERGIG9mIEJvRiBQcm9wb3NhbAoKCgpIaSwKCk9uIDIwMDktNi0xMiwgYXQgMDoxOCwgZ3Jl bnZpbGxlIGFybWl0YWdlIHdyb3RlOgo+IEkgd29uZGVyIGhvdyBtYW55IHBlb3BsZSAobGlrZSBt ZSkgc3Vic2NyaWJlZCB3aGVuIHdlIGZpcnN0IHNhdwo+IHRoZSBtYWlsaW5nIGxpc3QgYW5ub3Vu Y2VkIGxhc3Qgd2VlayBvbiBpZXRmQGlldGYub3JnLCBhbmQgaGF2ZSBzaW5jZQo+IGJlZW4gd2Fp dGluZyB0byBoYXZlIHNvbWVvbmUga2ljayBvZmYgZGlzY3Vzc2lvbnMuCgp0aGF0IGRpc2N1c3Np b24gc2VlbXMgdG8gaGF2ZSBzdGFydGVkIG5vdywgd2hpY2ggSSdtIHZlcnkgaGFwcHkgYWJvdXQu IApBbmRyZXcgbWFkZSBhIGdvb2QgcHJvcG9zYWwgaW4gaGlzIGVtYWlsOiBsZXQncyB1c2UgdGhl IHRpbWUgYmVmb3JlIApTdG9ja2hvbG0gdG8gc3RhcnQgd29ya2luZyBvdXQgd2hhdCBzaG91bGQg YmUgZG9uZSwgaGF2ZSBhbiBpbmZvcm1hbCAKbWVldGluZyBpbiBTdG9ja2hvbG0gd2l0aCB3aG9l dmVyIGlzIHRoZXJlIHRvIGRpc2N1c3MgdGhpbmdzIGluIApwZXJzb24sIGFuZCBhaW0gZm9yIGEg Qk9GIGluIEhpcm9zaGltYS4KCkxhcnMgCgoKUCBHbyBHcmVlbiEgUHJpbnQgdGhpcyBlbWFpbCBv bmx5IHdoZW4gbmVjZXNzYXJ5LiBUaGFuayB5b3UgZm9yIGhlbHBpbmcgVGltZSBXYXJuZXIgQ2Fi bGUgYmUgZW52aXJvbm1lbnRhbGx5IHJlc3BvbnNpYmxlLgogCiAKVGhpcyBFLW1haWwgYW5kIGFu eSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIKQ2FibGUgcHJvcHJp ZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwKb3Ig c3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlz IEUtbWFpbAppcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwg b3IgZW50aXR5IHRvIHdoaWNoCml0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzCkUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQg dGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwKZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24g dGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzCm9mIGFuZCBhdHRhY2htZW50cyB0byB0 aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUKdW5sYXdmdWwuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5CnRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwg YW5kIGFueQpjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuCg== From kirk.erichsen@twcable.com Fri Jun 12 10:30:42 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 0452B3A6923 for ; Fri, 12 Jun 2009 10:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 IRrcxf4m9VVP for ; Fri, 12 Jun 2009 10:30:41 -0700 (PDT) Received: from pblpas02.twcable.com (pblpas02.twcable.com [204.235.121.150]) by core3.amsl.com (Postfix) with ESMTP id BB5973A68CE for ; Fri, 12 Jun 2009 10:30:40 -0700 (PDT) X-SENDER-IP: 10.157.247.214 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,210,1243828800"; d="scan'208";a="421648770" Received: from unknown (HELO prvpmailconn4.corp.twcable.com) ([10.157.247.214]) by pblpas02.twcable.com with ESMTP; 12 Jun 2009 13:30:48 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn4.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 13:30:48 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Jun 2009 13:30:48 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] PDF of BoF Proposal thread-index: Acnrfe59d5RXsZnXSHmHdiCvUrTPVwAAESUI References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com><4A3182AE.9040508@swin.edu.au> <4A31FCB3.7080607@unifr.ch> From: "Erichsen, Kirk" To: "Lars Eggert" , "Carolin Latze" X-OriginalArrivalTime: 12 Jun 2009 17:30:48.0561 (UTC) FILETIME=[8671AE10:01C9EB83] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: Jason Livingood , homegate@ietf.org Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 17:30:42 -0000 TGFycywKIApJIGFncmVlIHdpdGggeW91ciBwcm9wb3NlZCBzY29wZSBiZWxvdyB0byB3aGljaCBJ IHByb3Bvc2Ugc29tZSBhZGRpdGlvbmFsIHdvcmsgaXRlbXMuIEkgd291bGQgYWdyZWUgdGhhdCB3 ZSBjYW4gcmVmZXJlbmNlIGFueSByZXF1aXJlZCBwcm90b2NvbHMgd2l0aGluIHRoZWlyIHJlc3Bl Y3RpdmUgc3RhbmRhcmRzIGJvZHkgd2hpbGUgZm9jdXNpbmcgb24gdGhlIG5lY2Vzc2FyeSBmZWF0 dXJlcyBhbmQgdGhlIGZlYXR1cmUgYmVoYXZpb3JzIHdlIGV4cGVjdCBmb3IgdGhlIGhvbWUgZ2F0 ZXdheS4gSSB0aGluayB3ZSB3aWxsIGZpbmQgd2UgaGF2ZSBicm9hZCBjb25zZW5zdXMgb24gd2hh dCB3ZSBhcmUgcmVhbGx5IGxvb2tpbmcgZm9yLCB0aGF0IHRoZXJlIGlzIGEgbmVlZCBmb3IgYSBt b3JlIGRlZmluaXRpdmUgY29tcGVuZGl1bSBvZiBmZWF0dXJlcyB3aXRoaW4gdGhlIGdhdGV3YXkg cm91dGluZyBkZXZpY2UuIFdlIG5lZWQgbm90LCBpbiBteSBvcGluaW9uLCBpbml0aWF0ZSBkcmFm dGluZyBvZiBuZXcgcHJvdG9jb2xzIHRvIGFjY29tcGxpc2ggdGhpcyBnb2FsLiAgCiAKSSB3b3Vs ZCBsaWtlIHRvIGVzdGFibGlzaCBzb21lIG9mIG91ciBlc3NlbnRpYWwgYXNzdW1wdGlvbnMgcmVn YXJkaW5nIHRoZSBlbnZpcm9ubWVudCB3ZSBhcmUgdGFpbG9yaW5nIHRoaXMgZWZmb3J0IHRvLiBJ IGJlbGlldmUgd2UgYXJlIGFscmVhZHkgZXF1aXBwZWQgdG8gZXN0YWJsaXNoIHRoZSBhc3N1bXB0 aW9ucyBiYXNlZCBvbiBvYnNlcnZlZCB0cmVuZHMgaW4gZXhpc3RpbmcgaG9tZS9zbWFsbCBidXNp bmVzcyBjdXN0b21lciBuZXR3b3Jrcy4gCiAKMSkgRm9yIHRoZSBtb3N0IHBhcnQgYW5kIHdpdGgg ZmV3IGV4Y2VwdGlvbnMsIHdlIGV4cGVjdCBhIHY2IHJvdXRlciBpbiBldmVyeSBob21lIHdlIHBy b3ZpZGUgSVB2NiBlbmFibGVkIHNlcnZpY2VzIHRvLiBUaGUgZXhjZXB0aW9ucyBmb3IgYSBub24t ZW1iZWRkZWQgZGV2aWNlIChhIHJvdXRlciB3aGljaCBlbWJlZHMgbm8gbW9kZW0pIHdvdWxkIGxp a2VseSBiZSBkdXJpbmcgaW5pdGlhbCBpbnN0YWxsYXRpb24gYW5kIHdoZW4gZGlhZ25vc3RpY3Mg b2YgdGhlIHVuZGVybHlpbmcgYmFuZHdpZHRoIHNlcnZpY2VzIGFyZSBjYWxsZWQgZm9yLiBUaGUg ZXhwZWN0YXRpb24gYXNzdW1lcyB3ZSBwcm92aWRlIG9ubHkgYSBzaW5nbGUgSVB2NiBwcmVmaXgg dG8gdGhlIGN1c3RvbWVyLCBldmVuIGlmIGxlZ2FjeSBkZXZpY2VzL2NvbXB1dGVyIHN5c3RlbXMg c3VwcG9ydGluZyBvbmx5IElQdjQgY29udGludWUgdG8gcmVzaWRlIGJlaGluZCB0aGUgSVB2NiBn YXRld2F5LiAKIAoyKSBUaGF0IHRoZSBnYXRld2F5IHdlIGRlZmluZSBpcyB0aGUgY29yZSBvZiB0 aGUgY3VzdG9tZXIncyBuZXR3b3JrIGFuZCBpcyB0aGUgb25seSByb3V0ZXIgbGlrZWx5IHRvIGJl IHByZXNlbnQuIFdlIGNhbiBjb250ZW1wbGF0ZSBhZGRpdGlvbmFsIGxpbmtzIHdpdGggYWRkaXRp b25hbCByb3V0ZXJzIGFmdGVyIHdlJ3ZlIGhhc2hlZCBvdXQgZGV0YWlscyBmb3IgdGhlIHNpbXBs ZXIgdXNlIGNhc2VzLiBJbiBhc3N1bWluZyB0aGF0IHRoZSBjdXN0b21lciBuZXR3b3JrIGlzIGZs YXQgYW5kIHVuY29tcGxpY2F0ZWQsIHdlIGNhbiByZWR1Y2UgdGhlIHNjb3BlIG9mIHVzZSBjYXNl cyAoYXQgbGVhc3QgYXQgZmlyc3QpIHRvIHRoZSBiYXNpYyBuZXR3b3JrcyB3ZSBjdXJyZW50bHkg c2VlIGluIGhvbWUgbmV0d29ya3MgdG9kYXkuIEl0IGNhbiBiZSBhbnRpY2lwYXRlZCB0aGF0IHRo ZSBudW1iZXIgb2Ygcm91dGVycyB3aXRoaW4gdGhlIGhvbWUgd2lsbCBpbmNyZWFzZSBvdmVyIHRp bWUsIGJ1dCB0aGF0IHdlIGhhdmUgc29tZSBkZWJhdGUgdG8gZ2V0IHRocm91Z2ggb24gaG93IHRv IHN0cnVjdHVyZSB0aGF0IGV4cGVjdGF0aW9uLiAgCiAKMykgVGhhdCB0aGUgcm91dGVyIHdvdWxk IHJlcXVpcmUsIGFzIGEgbWluaW11bSwgYSBzdGF0ZWxlc3MgREhDUCBzZXJ2ZXIgYW5kIEROUyBw cm94eSBhbmQgYXQgbGVhc3Qgb25lIExBTiBpbnRlcmZhY2UgYW5kIG9uZSBXQU4uIERlcGVuZGlu ZyBvbiB0aGUgbW9kZWwgb2Ygc2VydmljZSBkZWxpdmVyeSwgYSBzdGF0ZWZ1bCBESENQIHNlcnZl ciBhbmQgdGhlIGFzc29jaWF0ZWQgY29kZS1ibG9hdCBtYXkgYmUgbmVjZXNzYXJ5IChwYXJ0aWN1 bGFybHkgaWYgd2Ugc3RyYXkgZnJvbSB0aGUgc2ltcGxlciBjYXNlIG9mIGEgc2luZ2xlIHJvdXRl ciwgd2l0aCB0aGUgZGV2aWNlIHdlIGFyZSBkZWZpbmluZyBiZWluZyB0aGF0IGNvcmUgb2YgdGhl IGN1c3RvbWVyIG5ldHdvcmspLiAKIAo0KSBUaGF0IHdoaWxlIGxpa2VseSB0byBiZSBwcmVzZW50 LCB0aGUgZnVsbCBkZXRhaWxzIG9mIHRoZSBwYWNrZXQgZmlsdGVyaW5nIGZpcmV3YWxsIHNob3Vs ZCBiZSBsZWZ0LCB3aGVyZXZlciBwb3NzaWJsZSwgdG8gdmVuZG9yIGludGVycHJldGF0aW9uIHRv IHdvcmsgb3V0IHdpdGggdGhlIHNlcnZpY2UgcHJvdmlkZXJzL01TTy4gSWYgdGhlcmUgaXMgYSBy b2xlIGZvciBkaXNjdXNzaW5nIHRoZSBwYWNrZXQgZmlsdGVyaW5nLCBpdCB3aWxsIHByb2JhYmx5 IHJlbGF0ZSB0byBhIE5BVCBmb3IgdHJhbnNsYXRpbmcgKGFzIG1lbnRpb25lZCBhYm92ZSBpbiBt eSBmaXJzdCBhc3N1bXB0aW9uKSBJUHY0IGxlZ2FjeSBjbGllbnRzIGJlaGluZCB0aGUgSVB2NiBy b3V0ZXIuIEkgd291bGQgc3VnZ2VzdCB3ZSBsaW1pdCB0aGUgc2NvcGUgb2YgYW55IE5BVC9wYWNr ZXQgZmlsdGVyaW5nIGRpc2N1c3Npb24gdG8gdGhlIHRyYXZlcnNhbCBhc3BlY3RzIHdoZXJlIHRy YW5zbGF0aW9uIGlzIGNhbGxlZCBmb3IuIEl0IG1heSBiZSBhIGJyaWRnZSB0byBmYXIgYXQgdGhp cyBwb2ludCB0byBhc3N1bWUgYnJvYWQgYWdyZWVtZW50IHdpdGggbG9jYWwgcHJvdG9jb2wgZmFt aWx5IHRyYW5zbGF0aW9uIGF0IHRoZSBjdXN0b21lciBnYXRld2F5LiBJIGFkZCBpdCBoZXJlIHRv IHN0aW11bGF0ZSB0aGF0IGNvbnZlcnNhdGlvbi4KIAo1KSBRb1MgaXMgYSBzbGlwcGVyeSBzbG9w ZSBhbmQgbWF5IGJlIHNvbWV0aGluZyB3ZSBjYW4gbGltaXQgZGVzY3JpcHRpb24gb2YgYXMgaXQg aXMgYWxtb3N0IGFsd2F5cyBhcHBsaWNhdGlvbiBzcGVjaWZpYyBhbmQgcmVsYXRlcyB0byB3aGlj aCBzZXJ2aWNlcyBhIHNlcnZpY2UgcHJvdmlkZXIvTVNPIG1heSBwbGFuIHRvIG9mZmVyIG92ZXIg dGhlIGdhdGV3YXkuIEknZCBsaWtlIHRvIGFwcHJvYWNoIHRoZSBpc3N1ZSBzaW1pbGFyIHRvIHdo YXQgSSBzdWdnZXN0IGZvciBwYWNrZXQgZmlsdGVyaW5nL2ZpcmV3YWxsLiAKIAo2KSBPdXIgaGln aCBsZXZlbCAobm9uIHBhY2tldCBmaWx0ZXJpbmcvZmlyZXdhbGwgcmVsYXRlZCkgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMsIGluIG15IG9waW5pb24sIHNob3VsZCBmbG93IGZyb20gdGhlIHNpbXBs ZXIgdXNlIGNhc2VzIEkgcHJvcG9zZSBhYm92ZSBhbmQgYmUgYWRkZWQgdXBvbiBhcyB3ZSBicmFu Y2ggb3V0IGFzIGZhciBhcyB3ZSBmZWVsIGNvbWZvcnRhYmxlIHdpdGggcmVnYXJkaW5nIGhvbWUg bmV0d29yayBjb21wbGV4aXR5LiBJJ2xsIHN0YXRlIG15IHNlY3VyaXR5IGFzc3VtcHRpb25zIGFz IGJlaW5nIHJlbGF0aXZlbHkgbWluaW1hbCwgYXQgbGVhc3QgZm9yIHdoYXQgSSBwcmVzdW1lIHRv IGJlIHRoZSBidWxrIG9mIGN1cnJlbnQgYW5kIGZ1dHVyZSBkZXBsb3ltZW50cyBhcyBhIG5vbi1t YW5hZ2VkIHNlcnZpY2VzIChiYXNpYyBiYW5kd2lkdGggc2VydmljZXMsIHZzLiBhICJtYW5hZ2Vk IHNlcnZpY2UiKS4gSW4gbXkgdmlldywgdGhlIHByaW1hcnkgb2JqZWN0aXZlIGluIG91ciBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBzaG91bGQgYmUgaW4gcHJvdGVjdGluZyBhc3NldHMgb2YgdGhl IHNlcnZpY2UgcHJvdmlkZXIgZnJvbSB1bnRydXN0ZWQgZWxlbWVudHMgd2l0aGluIHRoZSBjdXN0 b21lciBuZXR3b3JrLCBvciBldmVuIGZyb20gdGhlIGN1c3RvbWVyIHRoZW1zZWx2ZXMgKHdoZXRo ZXIgdW5rbm93aW5nbHkgYXMgYnkgY29uZmlndXJhdGlvbiBlcnJvciwgY29kZSBkZWZlY3RzIGlu IHNvZnR3YXJlIG9yIHZpYSBnZW51aW5lbHkgbmVmYXJpb3VzIGludGVudGlvbnMpLiBJdCdzIG15 IG9waW5pb24sIGNvbnNpZGVyYXRpb25zIHdoaWNoIHNlZWsgcHJpbWFyaWx5IHRvIHByb3RlY3Qg dGhlIGN1c3RvbWVyIGZyb20gb3RoZXIgY3VzdG9tZXJzIG9yIHVua25vd24gZXh0ZXJuYWwgcGFy dGllcyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBlZmZvcnQuICAgCiAKTGV0IHRoZSBk ZWJhdGUgYmVnaW4hCiAKV2FybSByZWdhcmRzLAogCi1LRQogCiAKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KCkZyb206IGhvbWVnYXRlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxm IG9mIExhcnMgRWdnZXJ0ClNlbnQ6IEZyaSA2LzEyLzIwMDkgMTA6NDkgQU0KVG86IENhcm9saW4g TGF0emUKQ2M6IEphc29uIExpdmluZ29vZDsgaG9tZWdhdGVAaWV0Zi5vcmcKU3ViamVjdDogUmU6 IFtob21lZ2F0ZV0gUERGIG9mIEJvRiBQcm9wb3NhbAoKCgpIaSwKCk9uIDIwMDktNi0xMiwgYXQg ODo1OCwgQ2Fyb2xpbiBMYXR6ZSB3cm90ZToKPiBJIHRoaW5rIHRoYXQgdGhlIHRvcGljIGlzIHZl cnkgaW1wb3J0YW50IGFuZCBpbnRlcmVzdGluZywgYnV0IEkgYW0gbm90Cj4gc3VyZSwgdGhlIElF VEYgaXMgdGhlIHJpZ2h0IHBsYWNlIGZvciBpdC4gRm9yIG1lIGl0IHNvdW5kcyBsaWtlIHRoZSAK PiBvbmx5Cj4gdGhpbmcgeW91IGNhbiBzdGFuZGFyZGl6ZSBoZXJlIGlzIHNvbWV0aGluZyBsaWtl ICJBIGhvbWUgZ2F0ZXdheSBoYXMgCj4gdG8KPiBzdXBwb3J0IHByb3RvY29sIFgsIFksIGFuZCBa IiBhbmQgSSBkb24ndCBzZWUgdGhhdCB0aGVyZSBpcyB0aGUgbmVlZCAKPiB0bwo+IGZvcm0gYSBX RyB0byBkbyB0aGF0LiBUaGUgcHJvdG9jb2wgc3RhbmRhcmRzIGV4aXN0IGFuZCBtb3N0IG9mIHRo ZSAKPiBob21lCj4gZ2F0ZXdheXMgc3VwcG9ydCB0aGVtIChvciBhIHN1YnNldCBvZiB0aGVtKSwg c28gd2h5IGRvIHdlIG5lZWQgYW5vdGhlcgo+IHN0YW5kYXJkIGhlcmU/IFdoYXQgZGlkIEkgbWlz cyBoZXJlPwoKdGhlIHByb3RvY29sIHNwZWNpZmljYXRpb25zIGFyZSB0aGVyZSwgYnV0IHNvbWUg aWYgbm90IG1hbnkgaG9tZSAKcm91dGVycyBkb24ndCBpbXBsZW1lbnQgd2hhdCBzb21lIG9mIHVz IHdvdWxkIGNvbnNpZGVyIHRoZSBtaW5pbWFsIApzdWJzZXQgb2YgbW9kZXJuIEludGVybmV0IGZ1 bmN0aW9uYWxpdHksIGFuZCBzb21ldGltZXMgd2hhdCB0aGV5IHRyeSAKYW5kIGltcGxlbWVudCBp cyBidWdneSAoYnJhaW5kZWFkIHF1ZXVlaW5nLCBubyBFQ04sIG5vIEROUyBvdmVyIFRDUCBvciAK RUROUzAsIERIQ1Agb2RkaXRpZXMsIGV0Yy4sIGV0Yy4pCgpUaGUgaWRlYSBpc24ndCBmb3IgdGhp cyBlZmZvcnQgdG8gZG8gbWFqb3IgKG9yIG1heWJlIGV2ZW4gYW55KSAKcHJvdG9jb2wgd29yazsg dGhlIGlkZWEgaXMgdG8gZG9jdW1lbnQgd2hhdCB0aGUgSUVURiBiZWxpZXZlcyBhIGhvbWUgCmdh dGV3YXkgc2hvdWxkIGltcGxlbWVudCBhdCB0aGUgbWluaW11bSwgYW5kIG1heWJlIGF0IHRoZSBv cHRpbXVtLiBBIApzZXQgb2YgQkNQcyBzZWVtcyB0byBiZSB0aGUgY29ycmVjdCB2ZXNzZWwgZm9y IHRoaXMuCgo+IEJUVyBJIGFtIHN1cmUgd2hldGhlciBJIGdvdCBpdCByaWdodCwgYnV0IGEgaG9t ZSBnYXRld2F5IGhlcmUgaXMgCj4gbW9yZSBvcgo+IGxlc3MgdGhhdCB3aGF0IHhEU0wgbW9kZW1z IGFyZSB0b2RheT8gSSBtZWFuLCBzb21ldGhpbmcgdGhhdCBzZXJ2ZXMgCj4gYXMgYQo+IHJvdXRl ciBmb3IgeW91ciBsb2NhbCBuZXR3b3JrIGFuZCBnYXRld2F5IHRvIHRoZSBpbnRlcm5ldD8KCkNv cnJlY3QuCgpUaGFua3MsCkxhcnMgCgoKUCBHbyBHcmVlbiEgUHJpbnQgdGhpcyBlbWFpbCBvbmx5 IHdoZW4gbmVjZXNzYXJ5LiBUaGFuayB5b3UgZm9yIGhlbHBpbmcgVGltZSBXYXJuZXIgQ2FibGUg YmUgZW52aXJvbm1lbnRhbGx5IHJlc3BvbnNpYmxlLgogCiAKVGhpcyBFLW1haWwgYW5kIGFueSBv ZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIKQ2FibGUgcHJvcHJpZXRh cnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwKb3Igc3Vi amVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUt bWFpbAppcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3Ig ZW50aXR5IHRvIHdoaWNoCml0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCBvZiB0aGlzCkUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhh dCBhbnkgZGlzc2VtaW5hdGlvbiwKZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFr ZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzCm9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlz IEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUKdW5sYXdmdWwuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5CnRoZSBz ZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5k IGFueQpjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuCg== From dgerow@afflictions.org Fri Jun 12 10:32:16 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 E9ECF3A67D7 for ; Fri, 12 Jun 2009 10:32:16 -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 odbn3zlwviJe for ; Fri, 12 Jun 2009 10:32:16 -0700 (PDT) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by core3.amsl.com (Postfix) with ESMTP id 2026A3A68CE for ; Fri, 12 Jun 2009 10:32:16 -0700 (PDT) Received: from plebeian.afflictions.org (CPE000db917e8b9-CM0019475d4056.cpe.net.cable.rogers.com [99.241.168.103]) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id 76C002552F7; Fri, 12 Jun 2009 19:32:22 +0200 (CEST) Date: Fri, 12 Jun 2009 13:32:20 -0400 From: Damian Gerow To: Lars Eggert Message-Id: <20090612133220.70c3094c.dgerow@afflictions.org> In-Reply-To: References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> <4A3182AE.9040508@swin.edu.au> <4A31FCB3.7080607@unifr.ch> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "homegate@ietf.org" Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 17:32:17 -0000 Thus spake Lars Eggert [Fri, 12 Jun 2009 18:49:59 +0200]: : The idea isn't for this effort to do major (or maybe even any) : protocol work; the idea is to document what the IETF believes a home : gateway should implement at the minimum, and maybe at the optimum. A : set of BCPs seems to be the correct vessel for this. As the target consumers of this effort would be the end user, I think a set of BCPs falls just short of the mark. There needs to be some way for John Q. Public to pick up a box, look at a logo or phrase, and understand exactly what that product gives him. i.e. 'Gateway Certified' would meet all stated requirements for acting as your standard home gateway. 'Media Certified' means it would also provide media functionality (DAAP, UPnP/DLNA). 'Print Certified' would mean it provides a standard printer interface (can load arbitrary printers, provides an IPP/whatever interface). 'Wireless Certified' would mean it provided a WiFi-compliant network. A small handful of 'certifications', as well as, say, a rating of 1-3 for each of those certifications, would provide something clear and concise for the consumer. So, 'WiFi Level 1' would mean it provides basic Wireless access. Level 3 would be WPA2, WMM, and XYZ support. And so on. Obviously, this would quickly become overwhelming, so the number of 'certifications' would have to be kept to a minimum. However, this may be overstepping the boundaries of the IETF; I don't know. From Ray.Bellis@nominet.org.uk Fri Jun 12 10:37: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 93B253A6A4B for ; Fri, 12 Jun 2009 10:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.367, 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 7ATQc3bFhBxo for ; Fri, 12 Jun 2009 10:37:33 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 5C9F43A6A99 for ; Fri, 12 Jun 2009 10:37:32 -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=Nj0T5uwdJslPg3GEgRW2aAwDvdZvYCEfeH0MK1xYni0g1MYED2zwLnfC fUQllZ/WhZUS/alYaQzkfWN8OgSbgdxt63F/r5YA4Zd9F7DmWRVOdrsI/ qln98ud3Mj8LPmk; 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=1244828262; x=1276364262; 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]=20PDF=20of=20BoF=20Proposal|Date:=20Fri,=2012=20Jun =202009=2013:37:34=20-0400|Message-ID:=20|To:=20"Erichsen,=20Kirk"=20 |Cc:=20homegate@ietf.org|MIME-Version:=201.0|In-Reply-To: =20|References:=20<922BA6F4-A3B6-46AD-8144-B8715E4 6F783@nokia.com><4A3182AE.9040508@swin.edu.au>=0D=0A=09<4 A31FCB3.7080607@unifr.ch>=09=20; bh=Fcz+JB5DMj9Nksp8/ad51PY7r/S9uBj7d7VN9yXp6cw=; b=eTZrzjvZ4PB8RB9AJd0aJHJeRHMPypX+vVchGSJqtOegf0/DTe8DYcpY yq5FNbSUWK9+bmHFd+U7YPx920wK6pfp00MVLZiP6p3FGxewV8VdEeiUq UDhYNkNtEBovMry; X-IronPort-AV: E=Sophos;i="4.42,210,1243810800"; d="scan'208";a="10792945" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 12 Jun 2009 18:37:37 +0100 In-Reply-To: References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com><4A3182AE.9040508@swin.edu.au> <4A31FCB3.7080607@unifr.ch> To: "Erichsen, Kirk" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 12 Jun 2009 13:37:34 -0400 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 12/06/2009 06:37:39 PM, Serialize complete at 12/06/2009 06:37:39 PM Content-Type: text/plain; charset="US-ASCII" Cc: homegate@ietf.org Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 17:37:34 -0000 > 3) That the router would require, as a minimum, a stateless DHCP > server and DNS proxy and at least one LAN interface and one WAN. > Depending on the model of service delivery, a stateful DHCP server > and the associated code-bloat may be necessary (particularly if we > stray from the simpler case of a single router, with the device we > are defining being that core of the customer network). If at all possible the router SHOULD NOT act as the default DNS proxy. See draft-ietf-dnsext-dnsproxy for why. Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 From kirk.erichsen@twcable.com Fri Jun 12 10:40: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 A138C3A6A4B for ; Fri, 12 Jun 2009 10:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 9Px3iF8+9bVP for ; Fri, 12 Jun 2009 10:40:05 -0700 (PDT) Received: from pblpas01.twcable.com (pblpas01.twcable.com [204.235.121.149]) by core3.amsl.com (Postfix) with ESMTP id 952363A68D8 for ; Fri, 12 Jun 2009 10:40:05 -0700 (PDT) X-SENDER-IP: 10.157.247.211 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,210,1243828800"; d="scan'208";a="422525430" Received: from unknown (HELO prvpmailconn1.corp.twcable.com) ([10.157.247.211]) by pblpas01.twcable.com with ESMTP; 12 Jun 2009 13:40:14 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn1.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 13:40:13 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Jun 2009 13:35:28 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] PDF of BoF Proposal thread-index: Acnrg8GZpF6Wjo4KSYGrPcPu7NXodgAAGt8h References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com><4A3182AE.9040508@swin.edu.au> <4A31FCB3.7080607@unifr.ch> <20090612133220.70c3094c.dgerow@afflictions.org> From: "Erichsen, Kirk" To: "Damian Gerow" , "Lars Eggert" X-OriginalArrivalTime: 12 Jun 2009 17:40:13.0331 (UTC) FILETIME=[D712BE30:01C9EB84] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: homegate@ietf.org Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 17:40:06 -0000 RGFtaWFuLAogClRoZSBpc3N1ZSBvZiBzb21lIHNvcnQgb2YgbGFiZWwgdG8gcHJvdmlkZSBndWlk YW5jZSB0byBhIHJldGFpbCBjb25zdW1lciBpcyBwYXJ0aWN1bGFybHkgc2FsaWVudC4gSG93IHdl IGFjY29tcGxpc2ggdGhhdCB0YXNrIHNob3VsZCBiZSBkaXNjdXNzZWQgZnVydGhlci4gV2l0aGlu IGNhYmxlIHdlIGhhdmUgdGhlIERPQ1NJUyBjZXJ0aWZpZWQgbG9nbyB0byBndWlkZSBjdXN0b21l cidzIGluIG9idGFpbmluZyBwcm9kdWN0cyBrbm93biB0byBpbnRlcm9wZXJhdGUgYW5kIGNvbXBs eSB3aXRoIHRoZSBmZWF0dXJlIHJlcXVpcmVtZW50cyBvZiBhIHBhcnRpY3VsYXIgaW50ZXJmYWNl IHNwZWNpZmljYXRpb24uIEl0IG1heSBiZSBvdXRzaWRlIG9mIHRoZSBJRVRGIHRvIHByb3ZpZGUg c3VjaCBicmFuZGluZy9sb2dvIHByb2dyYW1zLCBidXQgd2UgbWF5IGJlIGFibGUgdG8gcHJvdmlk ZSBndWlkYW5jZSB0byB2ZW5kb3JzIGFzIHRvIHdoYXQgZWFzaWx5IGNvbnZleWVkIHRlcm0vdGVy bXMgbWlnaHQgYWNjb21wbGlzaCBtdWNoIHRoZSBzYW1lIGVmZmVjdC4gCiAKIkNvbXBsaWVzIHdp dGggeHh4eHh4eCIgb24gdGhlIHByb2R1Y3QgcGFja2FnaW5nIG1heSBub3QgYmUgcXVpdGUgd2hh dCB3ZSBoYWQgaW4gbWluZCwgYnV0IG1heSBiZSBzdWZmaWNpZW50IGZvciBvdXIgcHVycG9zZXMu IEknbGwgdGhyb3cgc29tZSBpZGVhcyBvdXQgYXMgdGhleSBjb21lLiAKIAotS0UgCgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwoKRnJvbTogaG9tZWdhdGUtYm91bmNlc0BpZXRmLm9y ZyBvbiBiZWhhbGYgb2YgRGFtaWFuIEdlcm93ClNlbnQ6IEZyaSA2LzEyLzIwMDkgMTE6MzIgQU0K VG86IExhcnMgRWdnZXJ0CkNjOiBob21lZ2F0ZUBpZXRmLm9yZwpTdWJqZWN0OiBSZTogW2hvbWVn YXRlXSBQREYgb2YgQm9GIFByb3Bvc2FsCgoKClRodXMgc3Bha2UgTGFycyBFZ2dlcnQgPGxhcnMu ZWdnZXJ0QG5va2lhLmNvbT4gW0ZyaSwgMTIgSnVuIDIwMDkgMTg6NDk6NTkgKzAyMDBdOgo6IFRo ZSBpZGVhIGlzbid0IGZvciB0aGlzIGVmZm9ydCB0byBkbyBtYWpvciAob3IgbWF5YmUgZXZlbiBh bnkpIAo6IHByb3RvY29sIHdvcms7IHRoZSBpZGVhIGlzIHRvIGRvY3VtZW50IHdoYXQgdGhlIElF VEYgYmVsaWV2ZXMgYSBob21lIAo6IGdhdGV3YXkgc2hvdWxkIGltcGxlbWVudCBhdCB0aGUgbWlu aW11bSwgYW5kIG1heWJlIGF0IHRoZSBvcHRpbXVtLiBBIAo6IHNldCBvZiBCQ1BzIHNlZW1zIHRv IGJlIHRoZSBjb3JyZWN0IHZlc3NlbCBmb3IgdGhpcy4KCkFzIHRoZSB0YXJnZXQgY29uc3VtZXJz IG9mIHRoaXMgZWZmb3J0IHdvdWxkIGJlIHRoZSBlbmQgdXNlciwgSSB0aGluayBhIHNldCBvZgpC Q1BzIGZhbGxzIGp1c3Qgc2hvcnQgb2YgdGhlIG1hcmsuICBUaGVyZSBuZWVkcyB0byBiZSBzb21l IHdheSBmb3IgSm9obiBRLgpQdWJsaWMgdG8gcGljayB1cCBhIGJveCwgbG9vayBhdCBhIGxvZ28g b3IgcGhyYXNlLCBhbmQgdW5kZXJzdGFuZCBleGFjdGx5CndoYXQgdGhhdCBwcm9kdWN0IGdpdmVz IGhpbS4gIGkuZS4gJ0dhdGV3YXkgQ2VydGlmaWVkJyB3b3VsZCBtZWV0IGFsbCBzdGF0ZWQKcmVx dWlyZW1lbnRzIGZvciBhY3RpbmcgYXMgeW91ciBzdGFuZGFyZCBob21lIGdhdGV3YXkuICAnTWVk aWEgQ2VydGlmaWVkJyBtZWFucwppdCB3b3VsZCBhbHNvIHByb3ZpZGUgbWVkaWEgZnVuY3Rpb25h bGl0eSAoREFBUCwgVVBuUC9ETE5BKS4gICdQcmludCBDZXJ0aWZpZWQnCndvdWxkIG1lYW4gaXQg cHJvdmlkZXMgYSBzdGFuZGFyZCBwcmludGVyIGludGVyZmFjZSAoY2FuIGxvYWQgYXJiaXRyYXJ5 CnByaW50ZXJzLCBwcm92aWRlcyBhbiBJUFAvd2hhdGV2ZXIgaW50ZXJmYWNlKS4gICdXaXJlbGVz cyBDZXJ0aWZpZWQnIHdvdWxkCm1lYW4gaXQgcHJvdmlkZWQgYSBXaUZpLWNvbXBsaWFudCBuZXR3 b3JrLgoKQSBzbWFsbCBoYW5kZnVsIG9mICdjZXJ0aWZpY2F0aW9ucycsIGFzIHdlbGwgYXMsIHNh eSwgYSByYXRpbmcgb2YgMS0zIGZvciBlYWNoCm9mIHRob3NlIGNlcnRpZmljYXRpb25zLCB3b3Vs ZCBwcm92aWRlIHNvbWV0aGluZyBjbGVhciBhbmQgY29uY2lzZSBmb3IgdGhlCmNvbnN1bWVyLiAg U28sICdXaUZpIExldmVsIDEnIHdvdWxkIG1lYW4gaXQgcHJvdmlkZXMgYmFzaWMgV2lyZWxlc3Mg YWNjZXNzLgpMZXZlbCAzIHdvdWxkIGJlIFdQQTIsIFdNTSwgYW5kIFhZWiBzdXBwb3J0LiAgQW5k IHNvIG9uLiAgT2J2aW91c2x5LCB0aGlzIHdvdWxkCnF1aWNrbHkgYmVjb21lIG92ZXJ3aGVsbWlu Zywgc28gdGhlIG51bWJlciBvZiAnY2VydGlmaWNhdGlvbnMnIHdvdWxkIGhhdmUgdG8KYmUga2Vw dCB0byBhIG1pbmltdW0uCgpIb3dldmVyLCB0aGlzIG1heSBiZSBvdmVyc3RlcHBpbmcgdGhlIGJv dW5kYXJpZXMgb2YgdGhlIElFVEY7IEkgZG9uJ3Qga25vdy4KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KaG9tZWdhdGUgbWFpbGluZyBsaXN0CmhvbWVnYXRl QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaG9tZWdhdGUK CgoKUCBHbyBHcmVlbiEgUHJpbnQgdGhpcyBlbWFpbCBvbmx5IHdoZW4gbmVjZXNzYXJ5LiBUaGFu ayB5b3UgZm9yIGhlbHBpbmcgVGltZSBXYXJuZXIgQ2FibGUgYmUgZW52aXJvbm1lbnRhbGx5IHJl c3BvbnNpYmxlLgogCiAKVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5 IGNvbnRhaW4gVGltZSBXYXJuZXIKQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNo IGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwKb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVs b25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbAppcyBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoCml0IGlz IGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlz CkUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwK ZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhl IGNvbnRlbnRzCm9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBw cm9oaWJpdGVkIGFuZCBtYXkgYmUKdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg RS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5CnRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5k IHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueQpjb3B5IG9mIHRoaXMgRS1t YWlsIGFuZCBhbnkgcHJpbnRvdXQuCg== From jhw@apple.com Fri Jun 12 10:47: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 8A73F3A6A99; Fri, 12 Jun 2009 10:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ugQxTjaITVdc; Fri, 12 Jun 2009 10:47:28 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id D783C3A69D1; Fri, 12 Jun 2009 10:47:28 -0700 (PDT) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 4EB936496FF9; Fri, 12 Jun 2009 10:47:37 -0700 (PDT) Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Brightmail Gateway) with ESMTP id 3464928050; Fri, 12 Jun 2009 10:47:37 -0700 (PDT) X-AuditID: 1180711d-aae05bb000005f4f-9f-4a3294b9744d Received: from [17.151.123.255] (unknown [17.151.123.255]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay13.apple.com (Apple SCV relay) with ESMTP id 0E47228084; Fri, 12 Jun 2009 10:47:37 -0700 (PDT) Message-Id: <0492FC01-160E-48FD-99B7-8C65C9297E4C@apple.com> From: james woodyatt To: homegate@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 10:47:36 -0700 References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> <4A3182AE.9040508@swin.edu.au> <4A31EDD1.8000202@ripe.net> X-Mailer: Apple Mail (2.935.3) X-Brightmail-Tracker: AAAAAA== Cc: IAB IAB , IESG IESG Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 17:47:29 -0000 On Jun 12, 2009, at 03:45, Richard Bennett wrote: > > I don't think it's realistic to try and slough this work off on > [organizations that are not] very application-oriented and don't > have great awareness of IETF protocols either. Concur with all of the excerpted message, and especially this part I just quoted. I'd much prefer that IETF be where the IPv4 and IPv6 functional requirements of residential Internet gateways are nailed down. If we allow others to set these standards, then the whole Internet community will be forced to endure behaviors at residential gateways that may not fit well with the Internet architecture and could potentially cause widespread damage to the total utility of the Internet. Politeness requires that I refrain from citing historical precedents for this that spring to mind when I think about how similar past missteps by IETF have greatly damaged the Internet. I expect everyone on this distribution has already heard my intemperate rants on that subject. Summary: I strongly advocate getting all our gear in one sack and setting a proper agenda for this work. I'm prepared to take an active role in a working group, should one be formed. -- james woodyatt member of technical staff, communications engineering From jhw@apple.com Fri Jun 12 11:10: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 6058528C240 for ; Fri, 12 Jun 2009 11:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 jZDDUQCB6RbV for ; Fri, 12 Jun 2009 11:10:24 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 40D4028C1B1 for ; Fri, 12 Jun 2009 11:10:24 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id B741B67BB35B for ; Fri, 12 Jun 2009 11:10:32 -0700 (PDT) Received: from relay15.apple.com (unknown [127.0.0.1]) by relay15.apple.com (Symantec Brightmail Gateway) with ESMTP id A93E55A0003 for ; Fri, 12 Jun 2009 11:10:32 -0700 (PDT) X-AuditID: 11807136-aad05bb00000447e-6e-4a329a18362f Received: from [17.151.123.255] (unknown [17.151.123.255]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay15.apple.com (Apple SCV relay) with ESMTP id 9A6EF558004 for ; Fri, 12 Jun 2009 11:10:32 -0700 (PDT) Message-Id: <1B8725E3-34F4-4ECB-86FE-5B9B5306D6D0@apple.com> From: james woodyatt To: homegate@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 11:10:32 -0700 References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> <4A3182AE.9040508@swin.edu.au> <4A31FCB3.7080607@unifr.ch> X-Mailer: Apple Mail (2.935.3) X-Brightmail-Tracker: AAAAAA== Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 18:10:25 -0000 On Jun 12, 2009, at 10:37, ray.bellis@nominet.org.uk wrote: > If at all possible the router SHOULD NOT act as the default DNS proxy. > See draft-ietf-dnsext-dnsproxy for why. That draft does not appear to explain why residential gateways SHOULD NOT be composed with a DNS proxy. Indeed it makes no such recommendation, and its title suggests that it should be interpreted as guidelines for implementing a DNS proxy integrated with residential gateways. If necessary, I'll be happy to explain why all Apple residential gateway appliances since January 2003 have had an integrated forwarding/resolving/caching DNS server, i.e. not merely a translating proxy. We didn't bite off the extra work of doing it that way for light and transient reasons, not the least of which is the need to prepare IPv6 transition with Internet service providers where DNS service is provided over only one of the two protocol versions, IPv4 or IPv6. -- james woodyatt member of technical staff, communications engineering From rdroms@cisco.com Fri Jun 12 11:14: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 AFF923A6B84 for ; Fri, 12 Jun 2009 11:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 zeHdBEVSBNYn for ; Fri, 12 Jun 2009 11:14:14 -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 8C2E03A6A8D for ; Fri, 12 Jun 2009 11:14:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,210,1243814400"; d="scan'208";a="47181816" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 12 Jun 2009 18:14:22 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5CIELbV024064 for ; Fri, 12 Jun 2009 14:14:21 -0400 Received: from bxb-rdroms-8717.cisco.com (bxb-rdroms-8717.cisco.com [10.98.10.88]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5CIELPw021648 for ; Fri, 12 Jun 2009 18:14:22 GMT Message-Id: From: Ralph Droms To: homegate@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 14:14:21 -0400 References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com><4A3182AE.9040508@swin.edu.au> <4A31FCB3.7080607@unifr.ch> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1080; t=1244830461; x=1245694461; c=relaxed/simple; s=rtpdkim1001; 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]=20PDF=20of=20BoF=20Proposal |Sender:=20 |To:=20homegate@ietf.org; bh=Wsw3bfbPVMFVrxRbSQ1wKk3krTcnyBg1rbQdHjCZIhY=; b=BRuAESJq+AqFEqR94vD9u7mugMJjCnutjaBPynCNGAJqUCXMKsPpIR7iEn Y0AbqGiX6y4GvArvC5IWjXBMFDJDG+Te9y+2qhbWThOXjKirs4pi9aMacP1Q r5uAPIkQgQ; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 18:14:15 -0000 I agree with Ray. Those DNS proxies exist only as an inadequate alternative to properly providing devices in the home with pointers to real recursive resolvers. - Ralph On Jun 12, 2009, at 1:37 PM 6/12/09, Ray.Bellis@nominet.org.uk wrote: >> 3) That the router would require, as a minimum, a stateless DHCP >> server and DNS proxy and at least one LAN interface and one WAN. >> Depending on the model of service delivery, a stateful DHCP server >> and the associated code-bloat may be necessary (particularly if we >> stray from the simpler case of a single router, with the device we >> are defining being that core of the customer network). > > If at all possible the router SHOULD NOT act as the default DNS proxy. > > See draft-ietf-dnsext-dnsproxy for why. > > Ray > > -- > Ray Bellis, MA(Oxon) MIET > Senior Researcher in Advanced Projects, Nominet > e: ray@nominet.org.uk, t: +44 1865 332211 > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate From Ray.Bellis@nominet.org.uk Fri Jun 12 11:17:38 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 78E573A6B84; Fri, 12 Jun 2009 11:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.269 X-Spam-Level: X-Spam-Status: No, score=-6.269 tagged_above=-999 required=5 tests=[AWL=0.330, 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 w7hodD8q5JTH; Fri, 12 Jun 2009 11:17:37 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 3D6D23A6A8D; Fri, 12 Jun 2009 11:17:36 -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=b6B5tm2T6hHsm7+fVvvzOGr4ipcvvfdCqglPdcGXWO/ZhI1L6slIeC8B b5ZXoxruAy7O1ywRVGV1FMA5bPiF0rl8phF22FaanH0UlRmZbkAb7k57j 6ZS1rkSoKuBZtnd; 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=1244830666; x=1276366666; 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]=20PDF=20of=20BoF=20Proposal|Date:=20Fri,=2012=20Jun =202009=2014:17:39=20-0400|Message-ID:=20|To:=20james=20woodyatt=20|Cc:=20homegate @ietf.org,=0D=0A=09homegate-bounces@ietf.org |MIME-Version:=201.0|In-Reply-To:=20<1B8725E3-34F4-4ECB-8 6FE-5B9B5306D6D0@apple.com>|References:=20=09<922BA6F4-A3B6-46AD- 8144-B8715E46F783@nokia.com>=0D=0A=09<4A3182AE.9040508@sw in.edu.au>=20<4A31FCB3.7080607@unifr.ch>=09=0D=0A=09=09=20<1B8725E3-34F4-4ECB-86FE-5B9B5306 D6D0@apple.com>; bh=E5Rx1eF0U1+5a6Mn/GL/9n9/w4+3RkpqftxHs3tTzX4=; b=swxd3yLB+eGuZ33ZfMCG+krRFgAllXSZ9Rm+HjnYYm3jOl28qWuLIWFV AlyD5ZKm1yfDB6FUsAwudtF5WMSZUhJn+P6xvYDyw6u5tl0kDiWvIhzQE kHEJCP8M44BWU4V; X-IronPort-AV: E=Sophos;i="4.42,210,1243810800"; d="scan'208";a="10796323" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 12 Jun 2009 19:17:41 +0100 In-Reply-To: <1B8725E3-34F4-4ECB-86FE-5B9B5306D6D0@apple.com> References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> <4A3182AE.9040508@swin.edu.au> <4A31FCB3.7080607@unifr.ch> <1B8725E3-34F4-4ECB-86FE-5B9B5306D6D0@apple.com> To: james woodyatt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 12 Jun 2009 14:17:39 -0400 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 12/06/2009 07:17:43 PM, Serialize complete at 12/06/2009 07:17:43 PM Content-Type: text/plain; charset="US-ASCII" Cc: homegate-bounces@ietf.org, homegate@ietf.org Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 18:17:38 -0000 > That draft does not appear to explain why residential gateways SHOULD > NOT be composed with a DNS proxy. Indeed it makes no such > recommendation, and its title suggests that it should be interpreted > as guidelines for implementing a DNS proxy integrated with residential > gateways. You're correct, it is more accurately a set of guidelines on how to _correctly_ implement a proxy, albeit also containing recommendations on how the proxy should step out of the way whenever possible. > If necessary, I'll be happy to explain why all Apple residential > gateway appliances since January 2003 have had an integrated > forwarding/resolving/caching DNS server, i.e. not merely a translating > proxy. We didn't bite off the extra work of doing it that way for > light and transient reasons, not the least of which is the need to > prepare IPv6 transition with Internet service providers where DNS > service is provided over only one of the two protocol versions, IPv4 > or IPv6. Indeed, on doing the testing for ICANN SSAC report SAC035 we tested an Apple unit, and it faired relatively well. I'd be happy to have a further offlist discussion about those parts where it didn't work quite so well. kind regards, Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 From carolin.latze@unifr.ch Fri Jun 12 12:03:19 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 1004E3A6BC8 for ; Fri, 12 Jun 2009 12:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=0.646, 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 dKxF+oiMzXII for ; Fri, 12 Jun 2009 12:03:18 -0700 (PDT) Received: from sr-svx-320.unifr.ch (sr-svx-320.unifr.ch [134.21.214.75]) by core3.amsl.com (Postfix) with ESMTP id 3BDA73A677C for ; Fri, 12 Jun 2009 12:03:18 -0700 (PDT) Received: from sr-blw-201.unifr.ch ([134.21.40.64]) by sr-svx-320.unifr.ch stage1 with esmtp with id 1MFC1y-0005DY-UI from ; Fri, 12 Jun 2009 21:03:14 +0200 Received: from [134.21.34.133] (134.21.34.133) by post.unifr.ch (134.21.39.51) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 12 Jun 2009 21:03:14 +0200 Message-ID: <4A32A672.9000207@unifr.ch> Date: Fri, 12 Jun 2009 21:03:14 +0200 From: Carolin Latze User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Lars Eggert References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> <4A3182AE.9040508@swin.edu.au> <4A31FCB3.7080607@unifr.ch> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: Jason Livingood , "homegate@ietf.org" Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 19:03:19 -0000 Lars Eggert wrote: > Hi, > > On 2009-6-12, at 8:58, Carolin Latze wrote: >> I think that the topic is very important and interesting, but I am not >> sure, the IETF is the right place for it. For me it sounds like the only >> thing you can standardize here is something like "A home gateway has to >> support protocol X, Y, and Z" and I don't see that there is the need to >> form a WG to do that. The protocol standards exist and most of the home >> gateways support them (or a subset of them), so why do we need another >> standard here? What did I miss here? > > the protocol specifications are there, but some if not many home > routers don't implement what some of us would consider the minimal > subset of modern Internet functionality, and sometimes what they try > and implement is buggy (braindead queueing, no ECN, no DNS over TCP or > EDNS0, DHCP oddities, etc., etc.) > > The idea isn't for this effort to do major (or maybe even any) > protocol work; the idea is to document what the IETF believes a home > gateway should implement at the minimum, and maybe at the optimum. A > set of BCPs seems to be the correct vessel for this. Sounds good, I'm in and would also help to write those documents. Carolin From carolin.latze@unifr.ch Fri Jun 12 12: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 BE5083A6BD9 for ; Fri, 12 Jun 2009 12:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.276 X-Spam-Level: X-Spam-Status: No, score=-6.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 VuSA9GA8AJJt for ; Fri, 12 Jun 2009 12:09:05 -0700 (PDT) Received: from siufsrv105.unifr.ch (siufsrv105.unifr.ch [134.21.14.71]) by core3.amsl.com (Postfix) with ESMTP id 681513A6AC2 for ; Fri, 12 Jun 2009 12:09:05 -0700 (PDT) Received: from sr-blw-201.unifr.ch ([134.21.40.64]) by siufsrv105.unifr.ch stage1 with esmtp with id 1MFC7j-0007CP-EW from ; Fri, 12 Jun 2009 21:09:11 +0200 Received: from [134.21.34.133] (134.21.34.133) by post.unifr.ch (134.21.39.51) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 12 Jun 2009 21:09:11 +0200 Message-ID: <4A32A7D6.7030303@unifr.ch> Date: Fri, 12 Jun 2009 21:09:10 +0200 From: Carolin Latze User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Erichsen, Kirk" References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com><4A3182AE.9040508@swin.edu.au> <4A31FCB3.7080607@unifr.ch> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Jason Livingood , "homegate@ietf.org" Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 19:09:06 -0000 Erichsen, Kirk wrote: > Lars, > =20 > I agree with your proposed scope below to which I propose some addition= al work items. I would agree that we can reference any required protocols= within their respective standards body while focusing on the necessary f= eatures and the feature behaviors we expect for the home gateway. I think= we will find we have broad consensus on what we are really looking for, = that there is a need for a more definitive compendium of features within = the gateway routing device. We need not, in my opinion, initiate drafting= of new protocols to accomplish this goal. =20 > =20 > I would like to establish some of our essential assumptions regarding t= he environment we are tailoring this effort to. I believe we are already = equipped to establish the assumptions based on observed trends in existin= g home/small business customer networks.=20 > =20 > 1) For the most part and with few exceptions, we expect a v6 router in = every home we provide IPv6 enabled services to. The exceptions for a non-= embedded device (a router which embeds no modem) would likely be during i= nitial installation and when diagnostics of the underlying bandwidth serv= ices are called for. The expectation assumes we provide only a single IPv= 6 prefix to the customer, even if legacy devices/computer systems support= ing only IPv4 continue to reside behind the IPv6 gateway.=20 > =20 > 2) That the gateway we define is the core of the customer's network and= is the only router likely to be present. We can contemplate additional l= inks with additional routers after we've hashed out details for the simpl= er use cases. In assuming that the customer network is flat and uncomplic= ated, we can reduce the scope of use cases (at least at first) to the bas= ic networks we currently see in home networks today. It can be anticipate= d that the number of routers within the home will increase over time, but= that we have some debate to get through on how to structure that expecta= tion. =20 > =20 > 3) That the router would require, as a minimum, a stateless DHCP server= and DNS proxy and at least one LAN interface and one WAN. Depending on t= he model of service delivery, a stateful DHCP server and the associated c= ode-bloat may be necessary (particularly if we stray from the simpler cas= e of a single router, with the device we are defining being that core of = the customer network).=20 > =20 > 4) That while likely to be present, the full details of the packet filt= ering firewall should be left, wherever possible, to vendor interpretatio= n to work out with the service providers/MSO. If there is a role for disc= ussing the packet filtering, it will probably relate to a NAT for transla= ting (as mentioned above in my first assumption) IPv4 legacy clients behi= nd the IPv6 router. I would suggest we limit the scope of any NAT/packet = filtering discussion to the traversal aspects where translation is called= for. It may be a bridge to far at this point to assume broad agreement w= ith local protocol family translation at the customer gateway. I add it h= ere to stimulate that conversation. > =20 > 5) QoS is a slippery slope and may be something we can limit descriptio= n of as it is almost always application specific and relates to which ser= vices a service provider/MSO may plan to offer over the gateway. I'd like= to approach the issue similar to what I suggest for packet filtering/fir= ewall.=20 > =20 > 6) Our high level (non packet filtering/firewall related) security cons= iderations, in my opinion, should flow from the simpler use cases I propo= se above and be added upon as we branch out as far as we feel comfortable= with regarding home network complexity. I'll state my security assumptio= ns as being relatively minimal, at least for what I presume to be the bul= k of current and future deployments as a non-managed services (basic band= width services, vs. a "managed service"). In my view, the primary objecti= ve in our security considerations should be in protecting assets of the s= ervice provider from untrusted elements within the customer network, or e= ven from the customer themselves (whether unknowingly as by configuration= error, code defects in software or via genuinely nefarious intentions). = It's my opinion, considerations which seek primarily to protect the custo= mer from other customers or unknown external parties are outside the scop= e of this effort. =20 > =20 > Let the debate begin! > =20 I would like to add the management of the home gateway as one of the=20 items we should work on. Is it a device that is managed locally by the=20 user (which mean he can manage it offline too), or does the=20 configuration reside on a central server in the Internet (which means,=20 the user cannot configure it anymore when he is offline). I don't know=20 how it is handled in all your routers, but parts of my router config are = actually on a server somewhere in the Internet. Carolin From jhw@apple.com Fri Jun 12 12:17:02 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 6463528C1BC for ; Fri, 12 Jun 2009 12:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 le0C5VEz6iHU for ; Fri, 12 Jun 2009 12:17:01 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 8F0603A6BD9 for ; Fri, 12 Jun 2009 12:17:01 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 1B57267BF79C for ; Fri, 12 Jun 2009 12:17:10 -0700 (PDT) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Brightmail Gateway) with ESMTP id EFE02280A8 for ; Fri, 12 Jun 2009 12:17:09 -0700 (PDT) X-AuditID: 11807130-a9ce5bb0000025da-32-4a32a9b5669f Received: from il0602b-dhcp46.apple.com (il0602b-dhcp46.apple.com [17.206.24.46]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay11.apple.com (Apple SCV relay) with ESMTP id C173728095 for ; Fri, 12 Jun 2009 12:17:09 -0700 (PDT) Message-Id: <2F4DB5CE-DC82-4BF1-A2E3-32BD1219B346@apple.com> From: james woodyatt To: homegate@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 12:17:09 -0700 References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> <4A3182AE.9040508@swin.edu.au> <4A31FCB3.7080607@unifr.ch> <1B8725E3-34F4-4ECB-86FE-5B9B5306D6D0@apple.com> X-Mailer: Apple Mail (2.935.3) X-Brightmail-Tracker: AAAAAA== Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 19:17:02 -0000 On Jun 12, 2009, at 11:17, ray.bellis@nominet.org.uk wrote: > > Indeed, on doing the testing for ICANN SSAC report SAC035 we tested an > Apple unit, and it faired relatively well. I'd be happy to have a > further > offlist discussion about those parts where it didn't work quite so > well. I've read the report, and we've had the discussion. I suspect my disagreements about what works better than what else will eventually be part of the group discussion. p1. I've yet to be sold on the proposition that DNSSEC is headed for widespread application deployment. For the sake of discussion here, I'm willing to assume it is, but I'm hesitating because Apple hasn't committed to DNSSEC yet and I'm not sure when, how or if it ever will. p2. There are DHCP-related issues that make attempting transparency of the local DNS proxy a very bad idea. Ralph Droms and I still have a long-standing disagreement over where the root cause of that problem lies, but I contend the problem is with the DHCP protocol. Once a client gets a lease, there isn't a reasonable way for a server to update it with new information immediately, i.e. when the DNS server addresses change. p3. Finally, in any residential gateway with a "connect-on-demand" feature, e.g. for providers who bill by the minute for connect time, which is not uncommon in some parts of the world, then the problem with DHCP described above becomes intolerable. The demand trigger MUST be the initial DNS query, and the service-provider DNS servers haven't been configured yet when the user initiates the demand for an Internet connection, so the query MUST be handled by an integrated forwarding server that's aware of the connection demand protocol. If and when I'm convinced that widespread application of DNSSEC is inevitable, then I will argue that residential gateways should be composed with a non-transparent and security-aware forwarding server. This will be the case unless and until RFC 5006 is used for configuring hosts with DNS server addresses. I don't expect that to *EVER* happen, so I see no alternative to using an integrated, non- transparent DNS server. I suppose it might be possible to enhance the DHCP protocol to address the deficiencies to which I'm referring, but I've been warned repeatedly that such heresy is highly unlikely to be received warmly by the DHCP working group. So, I haven't tried even to initiate an exploration of the topic. Perhaps, if a HOMEGATE working group were to converge on my view of how the DNS configuration problem should be solved, then the DHCP working group might see fit to reconsider some of its ancient history, which has led to the current less than spectacular results. -- james woodyatt member of technical staff, communications engineering From garmitage@swin.edu.au Fri Jun 12 16:42: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 ADC5B3A6781 for ; Fri, 12 Jun 2009 16:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 00u1fsw1f4M8 for ; Fri, 12 Jun 2009 16:42:45 -0700 (PDT) Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) by core3.amsl.com (Postfix) with ESMTP id 858C33A63EC for ; Fri, 12 Jun 2009 16:42:45 -0700 (PDT) Received: from [127.0.0.1] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id n5CNgil8016798; Sat, 13 Jun 2009 09:42:52 +1000 Message-ID: <4A32E869.2050305@swin.edu.au> Date: Sat, 13 Jun 2009 09:44:41 +1000 From: grenville armitage User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "homegate@ietf.org" References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> <4A3182AE.9040508@swin.edu.au> <4A31FCB3.7080607@unifr.ch> <20090612133220.70c3094c.dgerow@afflictions.org> In-Reply-To: <20090612133220.70c3094c.dgerow@afflictions.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 23:42:49 -0000 Damian Gerow wrote: > Thus spake Lars Eggert [Fri, 12 Jun 2009 18:49:59 +0200]: > : The idea isn't for this effort to do major (or maybe even any) > : protocol work; the idea is to document what the IETF believes a home > : gateway should implement at the minimum, and maybe at the optimum. A > : set of BCPs seems to be the correct vessel for this. > > As the target consumers of this effort would be the end user, I think a set of > BCPs falls just short of the mark. That's a key point to clarify early on - I forsee the target consumers as being the box builders (rather than the end users who'll be purchasing the boxes off the shelf of their local WalMart). Getting BCPs on how to build homegateways seems like a concrete and reasonable target, without worry too much about certification labels for now. cheers, gja From lars.eggert@googlemail.com Fri Jun 12 23:42: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 9FA3C3A6A55 for ; Fri, 12 Jun 2009 23:42:40 -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 tLWSAzzbKtRS for ; Fri, 12 Jun 2009 23:42:39 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 3B20B3A6A17 for ; Fri, 12 Jun 2009 23:42:38 -0700 (PDT) Received: by ewy6 with SMTP id 6so3577637ewy.37 for ; Fri, 12 Jun 2009 23:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=vybH0TqBzmh1Oz0cH+nzb+L+LrokhThwdQEJIWhJEDQ=; b=JtvvzX8NDrJMZMqMKH9GWt1Ob5UZihmW3751TUrEP3v3D6yq948lCXhpo9uNuHzbQ+ stmtMD/93UTG0p7/VM1VPIIFCWgJV/wrfY0yWODomCHR18j6Sw7Ys7jEbl1jUDf4zbll fCik3HcbnpMQn0GACgZfz/CS10aaszTFh817U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type:mime-version :subject:date:references:x-mailer; b=QCYYayG86aeaSCXiK5XppVZ7Gv5RJqWRvS0T5+BGR5/SAnlKY+fHkC5E8TEvQ3KV3s 5FogLgAGe9sSKV039lnLsNKahMY+A/XVR/EylBvrrf+wl/n5JQ44C51khWloQQpu4IIV DJwcvF0eGU3BLwtrx47pr0DSsm/4Vi+xVd+PY= Received: by 10.210.137.14 with SMTP id k14mr1680113ebd.93.1244875365242; Fri, 12 Jun 2009 23:42:45 -0700 (PDT) Received: from ?192.168.0.198? (cs78149114.pp.htv.fi [62.78.149.114]) by mx.google.com with ESMTPS id 5sm987235eyh.30.2009.06.12.23.42.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Jun 2009 23:42:44 -0700 (PDT) Sender: Lars Eggert Message-Id: From: Lars Eggert To: Damian Gerow In-Reply-To: <20090612133220.70c3094c.dgerow@afflictions.org> Content-Type: multipart/signed; boundary=Apple-Mail-8-280070076; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 13 Jun 2009 08:40:42 +0200 References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> <4A3182AE.9040508@swin.edu.au> <4A31FCB3.7080607@unifr.ch> <20090612133220.70c3094c.dgerow@afflictions.org> X-Mailer: Apple Mail (2.935.3) Cc: "homegate@ietf.org" Subject: Re: [homegate] PDF of BoF Proposal 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: Sat, 13 Jun 2009 06:42:40 -0000 --Apple-Mail-8-280070076 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-6-12, at 19:32, Damian Gerow wrote: > Thus spake Lars Eggert [Fri, 12 Jun 2009 > 18:49:59 +0200]: > : The idea isn't for this effort to do major (or maybe even any) > : protocol work; the idea is to document what the IETF believes a home > : gateway should implement at the minimum, and maybe at the optimum. A > : set of BCPs seems to be the correct vessel for this. > > As the target consumers of this effort would be the end user, I > think a set of > BCPs falls just short of the mark. it's not clear that the consumer of this effort would be the end user - few IETF specifications are. In my mind, this was mostly about giving guidelines to vendors and operators. We should definitely discuss if this effort could result in a document or two that were targeted at end users, but the bulk of the work probably wouldn't. > There needs to be some way for John Q. > Public to pick up a box, look at a logo or phrase, and understand > exactly > what that product gives him. i.e. 'Gateway Certified' would meet > all stated > requirements for acting as your standard home gateway. 'Media > Certified' means > it would also provide media functionality (DAAP, UPnP/DLNA). 'Print > Certified' > would mean it provides a standard printer interface (can load > arbitrary > printers, provides an IPP/whatever interface). 'Wireless Certified' > would > mean it provided a WiFi-compliant network. The IETF isn't doing standards certification, and there are good reasons for that. But nothing stops an outside entity to run a conformance test program based on IETF specs, and I agree that for the end users, some sort of easily identified distinguisher on the box would be helpful. Thanks, Lars --Apple-Mail-8-280070076 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA2MTMwNjQwNDJaMCMGCSqGSIb3DQEJBDEWBBTne6Chc51G722b LCB3AguSrt6ztDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAFeri5EmBSbbNLFxuKA5vO3Etg+H78fOaKnGPNSZmyqHERDbC/axu 1sBsTxBipfH84yyB9GsqH9KjQ2CXVg6iiYzWKlDXH1uxLviff6ztDzsHudYtmTHlrQFVFp3jB5+x 5FODrTLNPnsxK2mTwAITUZj4lF3gHvnyWBXH0p3Ci+IPbM7AOupTTxCBY16IHFmlRBkqCCWR/Q+f Mrx8w8/BjV3OCTTuDTch/5LtR5gKw7l5KqKz8mnho1xu/rqbDT1F8g/8MAxWNN83UYE6ekllIwnL eD5JmPG4uQldtHSu1k70iVuVUiaXEb9sLdrnZBYn6bVHpNUtk4Ry2VafBE+4fgAAAAAAAA== --Apple-Mail-8-280070076-- From iljitsch@muada.com Mon Jun 15 01:41: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 B42A728C111 for ; Mon, 15 Jun 2009 01:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.393 X-Spam-Level: X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 Np0ZFLJBE0-O for ; Mon, 15 Jun 2009 01:41:40 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id AAD4E28C0CE for ; Mon, 15 Jun 2009 01:41:39 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.219]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n5F8fGrv063958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Jun 2009 10:41:18 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Lars Eggert In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 15 Jun 2009 10:40:43 +0200 References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> <4A3182AE.9040508@swin.edu.au> <4A31FCB3.7080607@unifr.ch> <20090612133220.70c3094c.dgerow@afflictions.org> X-Mailer: Apple Mail (2.935.3) Cc: "homegate@ietf.org" Subject: Re: [homegate] PDF of BoF Proposal 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, 15 Jun 2009 08:41:40 -0000 On 13 jun 2009, at 8:40, Lars Eggert wrote: >> As the target consumers of this effort would be the end user, I >> think a set of >> BCPs falls just short of the mark. > it's not clear that the consumer of this effort would be the end > user - few IETF specifications are. In my mind, this was mostly > about giving guidelines to vendors and operators. Operators are important here, especially in the v6 space where there is no established practice for connecting a home gateway to the ISP network. This has been under discussion in v6ops, how do the efforts here relate to that? Iljitsch From lars.eggert@nokia.com Mon Jun 15 02:40:11 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 D4B7E3A6896 for ; Mon, 15 Jun 2009 02:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 qMo2h+e2TsXV for ; Mon, 15 Jun 2009 02:40:11 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id D5BC93A680E for ; Mon, 15 Jun 2009 02:40:10 -0700 (PDT) Received: from [192.168.0.198] (wlan.fit.nokia.com [195.148.124.254]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n5F9dl1f002604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Jun 2009 12:39:47 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <2929E6CD-8946-4CB2-8604-9FF4A6057D45@nokia.com> From: Lars Eggert To: Iljitsch van Beijnum In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-5-463609789; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 15 Jun 2009 12:39:41 +0300 References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> <4A3182AE.9040508@swin.edu.au> <4A31FCB3.7080607@unifr.ch> <20090612133220.70c3094c.dgerow@afflictions.org> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Mon, 15 Jun 2009 12:39:47 +0300 (EEST) Cc: "homegate@ietf.org" Subject: Re: [homegate] PDF of BoF Proposal 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, 15 Jun 2009 09:40:11 -0000 --Apple-Mail-5-463609789 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2009-6-15, at 11:40, Iljitsch van Beijnum wrote: > Operators are important here, especially in the v6 space where there > is no established practice for connecting a home gateway to the ISP > network. This has been under discussion in v6ops, how do the efforts > here relate to that? This would not only be about IPv6. As far as IPv6 is concerned, the current V6OPS docs would likely be referred to by what this effort would produce. We could even think about moving the IPv6-home-gateway-related work form V6OPS to here, but I don't see that as very critical. Lars --Apple-Mail-5-463609789 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA2MTUwOTM5NDJaMCMGCSqGSIb3DQEJBDEWBBTMjJ2UwNx/MGxi DtLypz9NrE2/GzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAfzFXCAbmDeWvKMZE4a/+4v06+TGh86P7f0fJskFKurLrx25fi6zH k7L/4msSzlV8YIwSSXVAQF9WRcLfXV3T4Hm5et7posP0k5s1hKuX+IvpvkiYGEbychpfB7ezmUMi JM7RbqtH90WjKCxVSSCitEcuhCIuJfjKLar5px03oYiVkuovkIM+QlZC2a2/F+xtMPhGWSuUXcoh JPAiGnzo0e71UTjOXWaZi40b+Av4Fmp27pWrFmAIsDFBwBQy7ajdSd/ja3ugld4ubiMJEokjWkHU gYR8bLmEBcrDUHazkncctL8EXVaCqYoTI1DKBePuLZsXWz6VPEr9EVAUiv83aAAAAAAAAA== --Apple-Mail-5-463609789-- From ajs@shinkuro.com Mon Jun 15 06:31:00 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 A133B3A68A4 for ; Mon, 15 Jun 2009 06:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 WnaoEL-j5hd3 for ; Mon, 15 Jun 2009 06:30:59 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id D1B733A6BE3 for ; Mon, 15 Jun 2009 06:30:59 -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 1E1752FE965D for ; Mon, 15 Jun 2009 13:30:52 +0000 (UTC) Date: Mon, 15 Jun 2009 09:30:49 -0400 From: Andrew Sullivan To: homegate@ietf.org Message-ID: <20090615133048.GA38531@shinkuro.com> References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com> <4A3182AE.9040508@swin.edu.au> <4A31FCB3.7080607@unifr.ch> <20090612133220.70c3094c.dgerow@afflictions.org> 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] PDF of BoF Proposal 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, 15 Jun 2009 13:31:00 -0000 On Sat, Jun 13, 2009 at 08:40:42AM +0200, Lars Eggert wrote: > it's not clear that the consumer of this effort would be the end user - > few IETF specifications are. In my mind, this was mostly about giving > guidelines to vendors and operators. > The IETF isn't doing standards certification, and there are good reasons > for that. But nothing stops an outside entity to run a conformance test > program based on IETF specs, and I agree that for the end users, some > sort of easily identified distinguisher on the box would be helpful. In my view, the above should be a key factor in our thinking. IETF standards get "enforced" by contracts. Large numbers of these gateway devices are sold or otherwise provided to end users by ISPs. So if ISPs have something to which they can require vendors to conform as part of the ISPs' purchase of the devices or recommendation of them to end customers, that will probably be enough market pressure to achieve the desired result. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From hkirksey@motive.com Mon Jun 15 13:58:19 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 498AA3A6D2C for ; Mon, 15 Jun 2009 13:58:19 -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 riNCL9vgqjEo for ; Mon, 15 Jun 2009 13:58:17 -0700 (PDT) Received: from m1.motive.com (m1.motive.com [64.186.184.65]) by core3.amsl.com (Postfix) with ESMTP id 9CDA43A67E1 for ; Mon, 15 Jun 2009 13:58:17 -0700 (PDT) Received: from m1.motive.com (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B96563A07 for ; Mon, 15 Jun 2009 15:57:50 -0500 (CDT) Received: from bellagio.motive.com (unknown [135.115.129.116]) by m1.motive.com (Postfix) with ESMTP id 9E25838B0 for ; Mon, 15 Jun 2009 15:57:50 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 15:57:49 -0500 Message-ID: In-Reply-To: <20090615133048.GA38531@shinkuro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] PDF of BoF Proposal Thread-Index: AcntvY3IJI7GRqqKRyS0ATiRYbfBbgAOUxbg References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com><4A3182AE.9040508@swin.edu.au> <4A31FCB3.7080607@unifr.ch><20090612133220.70c3094c.dgerow@afflictions.org> <20090615133048.GA38531@shinkuro.com> From: "Heather Kirksey" To: X-PMX-Version: 5.4.6.353000 Subject: Re: [homegate] PDF of BoF Proposal 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, 15 Jun 2009 20:58:19 -0000 Andrew, If you're considering ISPs using this work to enforce requirements on = their vendors, it might be worth checking out some work that's already = gone on in this area: Broadband Forum TR-124 defines a set of modular functional requirements = for broadband residential gateways: = http://www.broadband-forum.org/technical/download/TR-124.pdf. The Home Gateway Initiative also has a Home Gateway Requirements: = Residential Profile document: = http://www.homegatewayinitiative.org/publis/HGI_V1.01_Residential.pdf. In addition, Broadband Forum has a work-in-progress document called = PD-192 that deals with the functional IPv6 requirements for gateways in = the home based on current operator plans for migration and deployment. = BBF was already planning to liaise the PD-192 document in the relatively = near future to get feedback on it. Thanks, Heather Heather Kirksey Motive Product Division Alcatel-Lucent hkirksey@motive.com +1.512.531.1126 (office) +1.512.917.7938 (mobile) =A0 -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On = Behalf Of Andrew Sullivan Sent: Monday, June 15, 2009 8:31 AM To: homegate@ietf.org Subject: Re: [homegate] PDF of BoF Proposal On Sat, Jun 13, 2009 at 08:40:42AM +0200, Lars Eggert wrote: > it's not clear that the consumer of this effort would be the end user = -=20 > few IETF specifications are. In my mind, this was mostly about giving=20 > guidelines to vendors and operators. > The IETF isn't doing standards certification, and there are good = reasons [[HRK]]=20 > for that. But nothing stops an outside entity to run a conformance = test=20 > program based on IETF specs, and I agree that for the end users, some=20 > sort of easily identified distinguisher on the box would be helpful. In my view, the above should be a key factor in our thinking. IETF standards get "enforced" by contracts. Large numbers of these gateway devices are sold or otherwise provided to end users by ISPs. So if ISPs have something to which they can require vendors to conform as part of the ISPs' purchase of the devices or recommendation of them to end customers, that will probably be enough market pressure to achieve the desired result. A --=20 Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate From jason_livingood@cable.comcast.com Mon Jun 15 14:22: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 315B53A6826 for ; Mon, 15 Jun 2009 14:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.604 X-Spam-Level: * X-Spam-Status: No, score=1.604 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 H+R0xo3G+VFJ for ; Mon, 15 Jun 2009 14:22:48 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 4DBAD3A6884 for ; Mon, 15 Jun 2009 14:22:47 -0700 (PDT) Received: from ([10.195.246.152]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.73179846; Mon, 15 Jun 2009 17:22:27 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 17:22:27 -0400 Received: from 192.35.166.146 ([192.35.166.146]) 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 ; Mon, 15 Jun 2009 21:21:52 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Mon, 15 Jun 2009 17:21:54 -0400 From: "Livingood, Jason" To: Carolin Latze Message-ID: Thread-Topic: [homegate] PDF of BoF Proposal Thread-Index: Acnt/04hYVk9Y/XjfEiNwIEATF08Pg== In-Reply-To: <4A31FCB3.7080607@unifr.ch> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Jun 2009 21:22:27.0683 (UTC) FILETIME=[6234A330:01C9EDFF] Cc: "homegate@ietf.org" Subject: Re: [homegate] PDF of BoF Proposal 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, 15 Jun 2009 21:22:49 -0000 > I think that the topic is very important and interesting, but I am not > sure, the IETF is the right place for it. For me it sounds like the only > thing you can standardize here is something like "A home gateway has to > support protocol X, Y, and Z" and I don't see that there is the need to > form a WG to do that. The protocol standards exist and most of the home > gateways support them (or a subset of them), so why do we need another > standard here? What did I miss here? Actually, what we're finding is that most of the existing (and currently for sale) home gateways do not provide sufficient support, or support these things in ways not intended by the relevant standards authors. > BTW I am sure whether I got it right, but a home gateway here is more or > less that what xDSL modems are today? I mean, something that serves as a > router for your local network and gateway to the internet? A home gateway is different from a DSL modem, cable modem, etc. It is the general class of device that connects to that access device. These are often branded as "home routers" though they are not purely routers. They variously provide NAT/PAT, firewall services, DHCP servers for the LAN, etc. Jason From jason_livingood@cable.comcast.com Mon Jun 15 14:23:54 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 B0A9C3A68E7; Mon, 15 Jun 2009 14:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 Yx3aKzI9RArI; Mon, 15 Jun 2009 14:23:54 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 7E89D3A6836; Mon, 15 Jun 2009 14:23:53 -0700 (PDT) Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.41770297; Mon, 15 Jun 2009 17:23:28 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 17:23:27 -0400 Received: from 192.35.166.146 ([192.35.166.146]) 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 ; Mon, 15 Jun 2009 21:23:18 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Mon, 15 Jun 2009 17:23:19 -0400 From: "Livingood, Jason" To: Murari Sridharan , Henk Uijterwaal , grenville armitage Message-ID: Thread-Topic: [homegate] PDF of BoF Proposal Thread-Index: AcnrLO8u8N/5YHb2TZ6mGipy7MXYMgAAMH/AALRz6O4= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Jun 2009 21:23:27.0750 (UTC) FILETIME=[86022260:01C9EDFF] Cc: TSV Dir , "ipdir@ietf.org" , IAB IAB , "homegate@ietf.org" , "iesg@ietf.org IESG" Subject: Re: [homegate] PDF of BoF Proposal 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, 15 Jun 2009 21:23:54 -0000 It is probably my job to kick some of this off, and I have just been a bit too busy. ;-) I'll soon start to circulate revisions for comment and I think we'd benefit from some discussion at the next IETF meeting to better hone the scope of potential work. Jason On 6/12/09 3:17 AM, "Murari Sridharan" wrote: > PDF definitely looked interesting, a bit too broad but I assumed scoping > discussions would start to happen on the mailing lists. > > Murari > > -----Original Message----- > From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behalf > Of Henk Uijterwaal > Sent: Thursday, June 11, 2009 10:55 PM > To: grenville armitage > Cc: homegate@ietf.org; ipdir@ietf.org; IAB IAB; iesg@ietf.org IESG; TSV Dir; > Jason Livingood > Subject: Re: [homegate] PDF of BoF Proposal > > grenville armitage wrote: >> Lars Eggert wrote: >> [..] >>> Third, it is currently not clear how substantial the community is that >>> would participate in an IETF effort in this space. Traffic on the >>> mailing list has been absent, and I have also received only very few >>> direct emails about it. This effort may require more socializing. >> >> I wonder how many people (like me) subscribed when we first saw >> the mailing list announced last week on ietf@ietf.org, and have since >> been waiting to have someone kick off discussions. > > I agree, the PDF looked interesting, so I put myself on the list and > waited for a kick-off. > > Henk > From jason_livingood@cable.comcast.com Mon Jun 15 14:27: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 2820D3A697D for ; Mon, 15 Jun 2009 14:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[AWL=-2.699, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 v0dsgbmvubLI for ; Mon, 15 Jun 2009 14:27:00 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id F19E03A6836 for ; Mon, 15 Jun 2009 14:26:59 -0700 (PDT) Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.73180195; Mon, 15 Jun 2009 17:26:33 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 17:26:33 -0400 Received: from 192.35.166.146 ([192.35.166.146]) 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 ; Mon, 15 Jun 2009 21:26:00 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Mon, 15 Jun 2009 17:26:00 -0400 From: "Livingood, Jason" To: Bernard Aboba , , Henk Uijterwaal , Message-ID: Thread-Topic: [tsv-dir] [homegate] PDF of BoF Proposal Thread-Index: Acnt/+DB4SKZry3JEk+mwVIw2cQ/Kg== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3327931561_24831513" X-OriginalArrivalTime: 15 Jun 2009 21:26:33.0246 (UTC) FILETIME=[F49293E0:01C9EDFF] Cc: homegate@ietf.org Subject: Re: [homegate] [tsv-dir] PDF of BoF Proposal 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, 15 Jun 2009 21:27:03 -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_3327931561_24831513 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Good advice, Bernard. We=B9ll have to figure out an easy way to enable remot= e participation. The Hiroshima meeting may be pretty local for some of the major players to do participate economically. Jason On 6/12/09 5:17 AM, "Bernard Aboba" wrote: > Given the razor thin margins of the home gateway industry, structuring th= e > effort > to cater to remote participants (e.g. virtual interim meetings) wouldn't = hurt either. --B_3327931561_24831513 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [tsv-dir] [homegate] PDF of BoF Proposal Good advice, Bernard.  We’ll have to figure out an easy way to = enable remote participation.  The Hiroshima meeting may be pretty local= for some of the major players to do participate economically.

Jason


On 6/12/09 5:17 AM, "Bernard Aboba" <bernard_aboba@hotmail.com> wrote:

Given the razor thin margins of the= home gateway industry, structuring the effort
to cater to remote participants (e.g. virtual interim meetings) wouldn't hu= rt
either. --B_3327931561_24831513-- From jason_livingood@cable.comcast.com Mon Jun 15 14:32:13 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 7A6933A6AF1; Mon, 15 Jun 2009 14:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=2.742, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 Cz2GEpm3GGIF; Mon, 15 Jun 2009 14:32:12 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id A3C863A69C5; Mon, 15 Jun 2009 14:32:11 -0700 (PDT) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.41771354; Mon, 15 Jun 2009 17:31:40 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 17:31:40 -0400 Received: from 192.35.166.146 ([192.35.166.146]) 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 ; Mon, 15 Jun 2009 21:31:20 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Mon, 15 Jun 2009 17:31:17 -0400 From: "Livingood, Jason" To: Richard Bennett , 'Murari Sridharan' , Henk Uijterwaal , 'grenville armitage' Message-ID: Thread-Topic: [homegate] PDF of BoF Proposal Thread-Index: AcnrLO8u8N/5YHb2TZ6mGipy7MXYMgAAMH/AAAYOYcAArqzB6g== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Jun 2009 21:31:40.0158 (UTC) FILETIME=[AB81A1E0:01C9EE00] Cc: 'TSV Dir' , ipdir@ietf.org, 'IAB IAB' , homegate@ietf.org, iesg@ietf.org Subject: Re: [homegate] PDF of BoF Proposal 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, 15 Jun 2009 21:32:13 -0000 Great feedback, Richard. This is certainly consistent with what we've been hearing from a number of concerned parties, and is much of the background motivation for this work. Jason On 6/12/09 6:45 AM, "Richard Bennett" wrote: > Could be that the authors are busy or off the net at the moment, they'll > have to speak for that. From my own experience as an engineer who until > recently worked for a home gateway company in a product development role, I > think this is a vital piece of work and an area where IETF could make a huge > positive impact with less effort than is involved in several other areas. > > Home gateways are the combinations of a NAT, an Ethernet switch, a Wi-Fi > access point, and some sort of WAN connection, which can be either a DSL > adapter, a cable modem, or a connection to an external layer two device > reached over a separate Ethernet connection or something more obscure like > MoCA. They're very low margin products, so the companies that produce them > tend to have more expertise at manufacturing than engineering, and very > little expertise specific to IETF protocols. The norm in the industry is > engineering managers who understand DSL but not DHCP and certainly not DSCP. > If you asked one to explain MPLS they would probably tell you it's the > sister city of St. Paul. > > A sub-sector of that industry builds specialized gateways for telcos that > includes a suite of management protocol called things like TR069 and TR098, > which were defined by the DSL Forum (now called the Broadband Forum) because > they didn't understand SNMP. The "TR" protocols have a very bizarre object > model that bears a minimal resemblance to any actual network devices, and > uses SOAP and XML instead of ASN.1. The one good thing about it is that it > can used to download firmware updates the ISP wants to get out. > > The software in these boxes is open source combinations of Linux kernels, > busybox, and the related networking pieces, packaged with proprietary TR069 > components. The principal packagers are Broadcom and Jungo. > > From the perspective of the engineering managers and customers, the software > is at best a nuisance, as they view their hardware and manufacturing > processes as the primary value of the boxes. Hardware tends to be designed > according to reference designs from the chip companies. > > Specs in this industry are laughably terse, generally consisting of Excel > spreadsheets that describe complete functional subsystems with two or three > garbled sentences. They're very heavy on buzzwords. It's a miracle that most > of these products don't explode the first time they're powered on. > > The value of this BOF and eventual working group would be to define a > thorough BCP for the software components that go into home gateways. The > management protocol is pretty hopeless, but probably 75% of the code can be > drastically improved if the right people were to write a spec that described > the proper revisions, options, and features for the IETF protocols involved. > ECN was mentioned prominently in the PDF, and I can guarantee you personally > that there is no knowledge of ECN or why anybody would want it in the home > gateway industry. But if the IETF produces a BCP that says "Home gateways > should not halt and catch fire if they receive an IPv4 packet with ECN set," > the next round of RFPs from the telcos and other ISPs to the gateway vendors > would include that requirement and the products would conform. > > I don't think it's realistic to try and slough this work off on UPnP or > DLNA, as those organizations are very application-oriented and don't have > great awareness of IETF protocols either. I personally sat through a whole > series of teleconference in which DLNA leaders proposed to limit MTU sizes > to 1000 octets because they didn't know how to do Path MTU discovery, such a > new thing it's only been specified since RFC 1191. According to DLNA, the de > facto standard protocol for streaming Internet video is HTTP, not RTP/RTSP. > > The DNSSEC people have tested home gateways for compliance and found none of > them can handle UDP-framed request packets larger than 512 bytes. The home > gateway response is "what's DNSSEC?" > > I went to work in that particular segment because it seemed to me that it's > dragging down the whole Internet because it installs obsolete protocols in > hundreds of millions of homes and small offices around the world. I quickly > found that one person was not going to make much of a difference, and now > feel that it's an urgent priority for IETF to show some leadership in this > area. And believe me, if you don't, nobody else will and we'll all just keep > on complaining about the fact at ECN languishes even though it's been a > draft standard since 2001 (RFC 3168), and similar fate will befall DNSSEC. > > This is important work and it deserves some serious attention. > > Richard Bennett > > -----Original Message----- > From: Murari Sridharan [mailto:muraris@microsoft.com] > Sent: Friday, June 12, 2009 12:17 AM > To: Henk Uijterwaal; grenville armitage > Cc: homegate@ietf.org; ipdir@ietf.org; IAB IAB; iesg@ietf.org IESG; TSV Dir; > Jason Livingood > Subject: Re: [homegate] PDF of BoF Proposal > > PDF definitely looked interesting, a bit too broad but I assumed scoping > discussions would start to happen on the mailing lists. > > Murari > > -----Original Message----- > From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behalf > Of Henk Uijterwaal > Sent: Thursday, June 11, 2009 10:55 PM > To: grenville armitage > Cc: homegate@ietf.org; ipdir@ietf.org; IAB IAB; iesg@ietf.org IESG; TSV Dir; > Jason Livingood > Subject: Re: [homegate] PDF of BoF Proposal > > grenville armitage wrote: >> Lars Eggert wrote: >> [..] >>> Third, it is currently not clear how substantial the community is that >>> would participate in an IETF effort in this space. Traffic on the >>> mailing list has been absent, and I have also received only very few >>> direct emails about it. This effort may require more socializing. >> >> I wonder how many people (like me) subscribed when we first saw >> the mailing list announced last week on ietf@ietf.org, and have since >> been waiting to have someone kick off discussions. > > I agree, the PDF looked interesting, so I put myself on the list and > waited for a kick-off. > > Henk > From jason_livingood@cable.comcast.com Mon Jun 15 14:35: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 5BD493A6889 for ; Mon, 15 Jun 2009 14:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.182 X-Spam-Level: X-Spam-Status: No, score=-4.182 tagged_above=-999 required=5 tests=[AWL=2.214, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 3hS2ZUIISims for ; Mon, 15 Jun 2009 14:35:49 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 779463A67AF for ; Mon, 15 Jun 2009 14:35:49 -0700 (PDT) Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.41771959; Mon, 15 Jun 2009 17:35:46 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 17:35:45 -0400 Received: from 192.35.166.146 ([192.35.166.146]) 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 ; Mon, 15 Jun 2009 21:35:05 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Mon, 15 Jun 2009 17:35:00 -0400 From: "Livingood, Jason" To: Andrew Sullivan , Richard Bennett Message-ID: Thread-Topic: [homegate] PDF of BoF Proposal Thread-Index: AcnuASKfbMn/MCrhHEyPstYKZyzumQ== In-Reply-To: <20090612163641.GF36147@shinkuro.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Jun 2009 21:35:45.0485 (UTC) FILETIME=[3DBB8FD0:01C9EE01] Cc: homegate@ietf.org Subject: Re: [homegate] PDF of BoF Proposal 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, 15 Jun 2009 21:35:50 -0000 > I would like to suggest that we on the homegate list should take the > time between now and Stockholm to start working out what we want to > do, and perhaps even put a proposed charter -- or -00 draft or two -- I think that's exactly what we'd like to do now and will be a good use of time for the homegate list. > I hereby volunteer to help with such work, particularly with respect > to DNS, DNSSEC and its interactions with home gateways. Cool! Consider yourself volunteered! :-) Jason From jason_livingood@cable.comcast.com Mon Jun 15 14:39: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 EF4D43A6A26 for ; Mon, 15 Jun 2009 14:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.625 X-Spam-Level: X-Spam-Status: No, score=-0.625 tagged_above=-999 required=5 tests=[AWL=-2.229, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 zxvRs6z2AFzX for ; Mon, 15 Jun 2009 14:39:05 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 138C33A68EB for ; Mon, 15 Jun 2009 14:39:04 -0700 (PDT) Received: from ([10.195.246.152]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.63545161; Mon, 15 Jun 2009 17:38:48 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 17:38:48 -0400 Received: from 192.35.166.146 ([192.35.166.146]) 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 ; Mon, 15 Jun 2009 21:38:46 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Mon, 15 Jun 2009 17:38:45 -0400 From: "Livingood, Jason" To: Damian Gerow , Lars Eggert Message-ID: Thread-Topic: [homegate] PDF of BoF Proposal Thread-Index: AcnuAai7P5695VhQmkmQMxqOK7aQPA== In-Reply-To: <20090612133220.70c3094c.dgerow@afflictions.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Jun 2009 21:38:48.0367 (UTC) FILETIME=[AABD23F0:01C9EE01] Cc: "homegate@ietf.org" Subject: Re: [homegate] PDF of BoF Proposal 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, 15 Jun 2009 21:39:06 -0000 I'm not sure that end users are the target audience. Instead, IMHO, I think it is equipment vendors and large buyers (ISPs, mega retailers, etc.). Jason On 6/12/09 1:32 PM, "Damian Gerow" wrote: > As the target consumers of this effort would be the end user, I think a set of > BCPs falls just short of the mark. There needs to be some way for John Q. > Public to pick up a box, look at a logo or phrase, and understand exactly > what that product gives him. i.e. 'Gateway Certified' would meet all stated > requirements for acting as your standard home gateway. 'Media Certified' From iljitsch@muada.com Mon Jun 15 14:44: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 E688D3A6CE1 for ; Mon, 15 Jun 2009 14:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.164 X-Spam-Level: X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=0.435, 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 nR8Pdy473oeO for ; Mon, 15 Jun 2009 14:44:39 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id ED4B53A68EB for ; Mon, 15 Jun 2009 14:44:38 -0700 (PDT) Received: from [192.168.2.4] (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 n5FLj07S070757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Jun 2009 23:45:00 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: "Livingood, Jason" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 15 Jun 2009 23:44:27 +0200 References: X-Mailer: Apple Mail (2.935.3) Cc: homegate@ietf.org Subject: Re: [homegate] PDF of BoF Proposal 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, 15 Jun 2009 21:44:40 -0000 On 15 jun 2009, at 23:38, Livingood, Jason wrote: > I'm not sure that end users are the target audience. They're maybe not the audience for the documents that will be the output of an IETF effort, but they're absolutely the target audience for the products that will be built based on these documents. (Not to mention, they pay for everything!) As such, the user's needs must be front and center. For instance, I think that someone mentioned something along the lines of "let's keep things simple and assume only a single subnet" (my interpretation). This won't do. Today, only advanced or dumb users have multiple subnets, but in the future with more and more heavy security requirements for working from home and appliances that connect to the home network, more and more regular users will want/ need multiple subnets. With IPv6 we have to specifically support this, we can't just let them double NAT like what happens often today if there's more than one IPv4 home gateway. From kirk.erichsen@twcable.com Mon Jun 15 18:46:10 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 EFE643A6ABE for ; Mon, 15 Jun 2009 18:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 cbZYi-FZI2Lj for ; Mon, 15 Jun 2009 18:46:09 -0700 (PDT) Received: from pblpas02.twcable.com (pblpas02.twcable.com [204.235.121.150]) by core3.amsl.com (Postfix) with ESMTP id A0C183A69F6 for ; Mon, 15 Jun 2009 18:46:09 -0700 (PDT) X-SENDER-IP: 10.157.247.214 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,225,1243828800"; d="scan'208";a="422578775" Received: from unknown (HELO prvpmailconn4.corp.twcable.com) ([10.157.247.214]) by pblpas02.twcable.com with ESMTP; 15 Jun 2009 21:46:20 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn4.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 21:46:17 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 Jun 2009 21:43:57 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] PDF of BoF Proposal thread-index: AcntvY3IJI7GRqqKRyS0ATiRYbfBbgAOUxbgAAtD86U= References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com><4A3182AE.9040508@swin.edu.au><4A31FCB3.7080607@unifr.ch><20090612133220.70c3094c.dgerow@afflictions.org><20090615133048.GA38531@shinkuro.com> From: "Erichsen, Kirk" To: "Heather Kirksey" , X-OriginalArrivalTime: 16 Jun 2009 01:46:17.0427 (UTC) FILETIME=[3D77E230:01C9EE24] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: Re: [homegate] PDF of BoF Proposal 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, 16 Jun 2009 01:46:11 -0000 SGVhdGhlciwKClRoZXNlIHdlcmUgYWxsIGdvb2Qgc3RhcnRpbmcgcG9pbnRzLCBidXQgcHJvYmFi bHkgbm90IHF1aXRlIHJpZ2h0IGZvciB0aGUgaW50ZW5kZWQgcm9sZSAoaW5jbHVzaXZlIG9mIE1T T3MvU2VydmljZSBQcm92aWRlcnMgbGV2ZXJhZ2luZyB0aGUgc3BlYyB0byBpbnN0cnVjdCB2ZW5k b3JzIHdoYXQgdG8gYnVpbGQvZXhwZWN0ZWQgYmVoYXZpb3JzKS4gV2UgY2FuIHByb2JhYmx5IGV4 cGxvcmUgZXh0cmFjdGluZyByZXF1aXJlbWVudHMsIGRlZmluaXRpb25zIGZyb20gdGhlc2UgYW5k IG90aGVyIGRvY3VtZW50cyBpbiBvcmRlciB0byBwcm9kdWNlIGEgbW9yZSBhcmNoaXRlY3R1cmUt aW5kZXBlbmRlbnQsIGdlbmVyaWMgcm91dGVyIHNwZWMgd2l0aCBhZGRpdGlvbmFsIHVzZSBjYXNl cyBub3QgbGlrZWx5IHRvIGhhdmUgYmVlbiBjb25zaWRlcmVkIGF0IHRoZSB0aW1lIHRoZXNlIGRv Y3VtZW50cyB3ZXJlIGNyYWZ0ZWQuCiAKLUtFCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwoKRnJvbTogaG9tZWdhdGUtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgSGVhdGhl ciBLaXJrc2V5ClNlbnQ6IE1vbiA2LzE1LzIwMDkgMjo1NyBQTQpUbzogaG9tZWdhdGVAaWV0Zi5v cmcKU3ViamVjdDogUmU6IFtob21lZ2F0ZV0gUERGIG9mIEJvRiBQcm9wb3NhbAoKCgpBbmRyZXcs CgpJZiB5b3UncmUgY29uc2lkZXJpbmcgSVNQcyB1c2luZyB0aGlzIHdvcmsgdG8gZW5mb3JjZSBy ZXF1aXJlbWVudHMgb24gdGhlaXIgdmVuZG9ycywgaXQgbWlnaHQgYmUgd29ydGggY2hlY2tpbmcg b3V0IHNvbWUgd29yayB0aGF0J3MgYWxyZWFkeSBnb25lIG9uIGluIHRoaXMgYXJlYToKCkJyb2Fk YmFuZCBGb3J1bSBUUi0xMjQgZGVmaW5lcyBhIHNldCBvZiBtb2R1bGFyIGZ1bmN0aW9uYWwgcmVx dWlyZW1lbnRzIGZvciBicm9hZGJhbmQgcmVzaWRlbnRpYWwgZ2F0ZXdheXM6IGh0dHA6Ly93d3cu YnJvYWRiYW5kLWZvcnVtLm9yZy90ZWNobmljYWwvZG93bmxvYWQvVFItMTI0LnBkZi4KCgpUaGUg SG9tZSBHYXRld2F5IEluaXRpYXRpdmUgYWxzbyBoYXMgYSBIb21lIEdhdGV3YXkgUmVxdWlyZW1l bnRzOiBSZXNpZGVudGlhbCBQcm9maWxlIGRvY3VtZW50OiBodHRwOi8vd3d3LmhvbWVnYXRld2F5 aW5pdGlhdGl2ZS5vcmcvcHVibGlzL0hHSV9WMS4wMV9SZXNpZGVudGlhbC5wZGYuCgpJbiBhZGRp dGlvbiwgQnJvYWRiYW5kIEZvcnVtIGhhcyBhIHdvcmstaW4tcHJvZ3Jlc3MgZG9jdW1lbnQgY2Fs bGVkIFBELTE5MiB0aGF0IGRlYWxzIHdpdGggdGhlIGZ1bmN0aW9uYWwgSVB2NiByZXF1aXJlbWVu dHMgZm9yIGdhdGV3YXlzIGluIHRoZSBob21lIGJhc2VkIG9uIGN1cnJlbnQgb3BlcmF0b3IgcGxh bnMgZm9yIG1pZ3JhdGlvbiBhbmQgZGVwbG95bWVudC4gIEJCRiB3YXMgYWxyZWFkeSBwbGFubmlu ZyB0byBsaWFpc2UgdGhlIFBELTE5MiBkb2N1bWVudCBpbiB0aGUgcmVsYXRpdmVseSBuZWFyIGZ1 dHVyZSB0byBnZXQgZmVlZGJhY2sgb24gaXQuCgpUaGFua3MsCkhlYXRoZXIKCgpIZWF0aGVyIEtp cmtzZXkKTW90aXZlIFByb2R1Y3QgRGl2aXNpb24KQWxjYXRlbC1MdWNlbnQKaGtpcmtzZXlAbW90 aXZlLmNvbQorMS41MTIuNTMxLjExMjYgKG9mZmljZSkKKzEuNTEyLjkxNy43OTM4IChtb2JpbGUp CiAKCgoKClAgR28gR3JlZW4hIFByaW50IHRoaXMgZW1haWwgb25seSB3aGVuIG5lY2Vzc2FyeS4g VGhhbmsgeW91IGZvciBoZWxwaW5nIFRpbWUgV2FybmVyIENhYmxlIGJlIGVudmlyb25tZW50YWxs eSByZXNwb25zaWJsZS4KIAogCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCkZyb206IGhvbWVn YXRlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpob21lZ2F0ZS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQW5kcmV3IFN1bGxpdmFuClNlbnQ6IE1vbmRheSwgSnVuZSAxNSwgMjAwOSA4 OjMxIEFNClRvOiBob21lZ2F0ZUBpZXRmLm9yZwpTdWJqZWN0OiBSZTogW2hvbWVnYXRlXSBQREYg b2YgQm9GIFByb3Bvc2FsCgpPbiBTYXQsIEp1biAxMywgMjAwOSBhdCAwODo0MDo0MkFNICswMjAw LCBMYXJzIEVnZ2VydCB3cm90ZToKCj4gaXQncyBub3QgY2xlYXIgdGhhdCB0aGUgY29uc3VtZXIg b2YgdGhpcyBlZmZvcnQgd291bGQgYmUgdGhlIGVuZCB1c2VyIC0KPiBmZXcgSUVURiBzcGVjaWZp Y2F0aW9ucyBhcmUuIEluIG15IG1pbmQsIHRoaXMgd2FzIG1vc3RseSBhYm91dCBnaXZpbmcKPiBn dWlkZWxpbmVzIHRvIHZlbmRvcnMgYW5kIG9wZXJhdG9ycy4KCj4gVGhlIElFVEYgaXNuJ3QgZG9p bmcgc3RhbmRhcmRzIGNlcnRpZmljYXRpb24sIGFuZCB0aGVyZSBhcmUgZ29vZCByZWFzb25zIFtb SFJLXV0KPiBmb3IgdGhhdC4gQnV0IG5vdGhpbmcgc3RvcHMgYW4gb3V0c2lkZSBlbnRpdHkgdG8g cnVuIGEgY29uZm9ybWFuY2UgdGVzdAo+IHByb2dyYW0gYmFzZWQgb24gSUVURiBzcGVjcywgYW5k IEkgYWdyZWUgdGhhdCBmb3IgdGhlIGVuZCB1c2Vycywgc29tZQo+IHNvcnQgb2YgZWFzaWx5IGlk ZW50aWZpZWQgZGlzdGluZ3Vpc2hlciBvbiB0aGUgYm94IHdvdWxkIGJlIGhlbHBmdWwuCgpJbiBt eSB2aWV3LCB0aGUgYWJvdmUgc2hvdWxkIGJlIGEga2V5IGZhY3RvciBpbiBvdXIgdGhpbmtpbmcu ICBJRVRGCnN0YW5kYXJkcyBnZXQgImVuZm9yY2VkIiBieSBjb250cmFjdHMuICBMYXJnZSBudW1i ZXJzIG9mIHRoZXNlIGdhdGV3YXkKZGV2aWNlcyBhcmUgc29sZCBvciBvdGhlcndpc2UgcHJvdmlk ZWQgdG8gZW5kIHVzZXJzIGJ5IElTUHMuICBTbyBpZgpJU1BzIGhhdmUgc29tZXRoaW5nIHRvIHdo aWNoIHRoZXkgY2FuIHJlcXVpcmUgdmVuZG9ycyB0byBjb25mb3JtIGFzCnBhcnQgb2YgdGhlIElT UHMnIHB1cmNoYXNlIG9mIHRoZSBkZXZpY2VzIG9yIHJlY29tbWVuZGF0aW9uIG9mIHRoZW0gdG8K ZW5kIGN1c3RvbWVycywgdGhhdCB3aWxsIHByb2JhYmx5IGJlIGVub3VnaCBtYXJrZXQgcHJlc3N1 cmUgdG8gYWNoaWV2ZQp0aGUgZGVzaXJlZCByZXN1bHQuCgpBCgotLQpBbmRyZXcgU3VsbGl2YW4K YWpzQHNoaW5rdXJvLmNvbQpTaGlua3VybywgSW5jLgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpob21lZ2F0ZSBtYWlsaW5nIGxpc3QKaG9tZWdhdGVAaWV0 Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ob21lZ2F0ZQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpob21lZ2F0ZSBtYWls aW5nIGxpc3QKaG9tZWdhdGVAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ob21lZ2F0ZQoKClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRz IG1heSBjb250YWluIFRpbWUgV2FybmVyCkNhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3 aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsCm9yIHN1YmplY3QgdG8gY29weXJpZ2h0 IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwKaXMgaW50ZW5kZWQg c29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaApp dCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2Yg dGhpcwpFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRp b24sCmRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRv IHRoZSBjb250ZW50cwpvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlCnVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeQp0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkKY29weSBvZiB0aGlz IEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lgo= From kirk.erichsen@twcable.com Mon Jun 15 18:49:59 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 695813A69E6 for ; Mon, 15 Jun 2009 18:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 aN8gHW829cFc for ; Mon, 15 Jun 2009 18:49:58 -0700 (PDT) Received: from pblpas01.twcable.com (pblpas01.twcable.com [204.235.121.149]) by core3.amsl.com (Postfix) with ESMTP id 8AB433A67B3 for ; Mon, 15 Jun 2009 18:49:58 -0700 (PDT) X-SENDER-IP: 10.157.247.214 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,225,1243828800"; d="scan'208";a="423449551" Received: from unknown (HELO prvpmailconn4.corp.twcable.com) ([10.157.247.214]) by pblpas01.twcable.com with ESMTP; 15 Jun 2009 21:50:09 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn4.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 21:50:08 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 Jun 2009 21:49:39 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] PDF of BoF Proposal thread-index: Acnt/04hYVk9Y/XjfEiNwIEATF08PgAJWfk7 References: From: "Erichsen, Kirk" To: "Livingood, Jason" , "Carolin Latze" X-OriginalArrivalTime: 16 Jun 2009 01:50:08.0308 (UTC) FILETIME=[C7158740:01C9EE24] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: homegate@ietf.org Subject: Re: [homegate] PDF of BoF Proposal 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, 16 Jun 2009 01:49:59 -0000 SSBjb25jdXIgYW5kIHNlY29uZCB0aGUgcHVzaCBmb3IgYSBXRyB0byBhY2NvbXBsaXNoIG91ciBj b2xsZWN0aXZlIGVuZHMuCiAKLUtFCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoK RnJvbTogaG9tZWdhdGUtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgTGl2aW5nb29kLCBK YXNvbgpTZW50OiBNb24gNi8xNS8yMDA5IDM6MjEgUE0KVG86IENhcm9saW4gTGF0emUKQ2M6IGhv bWVnYXRlQGlldGYub3JnClN1YmplY3Q6IFJlOiBbaG9tZWdhdGVdIFBERiBvZiBCb0YgUHJvcG9z YWwKCgoKPiBJIHRoaW5rIHRoYXQgdGhlIHRvcGljIGlzIHZlcnkgaW1wb3J0YW50IGFuZCBpbnRl cmVzdGluZywgYnV0IEkgYW0gbm90Cj4gc3VyZSwgdGhlIElFVEYgaXMgdGhlIHJpZ2h0IHBsYWNl IGZvciBpdC4gRm9yIG1lIGl0IHNvdW5kcyBsaWtlIHRoZSBvbmx5Cj4gdGhpbmcgeW91IGNhbiBz dGFuZGFyZGl6ZSBoZXJlIGlzIHNvbWV0aGluZyBsaWtlICJBIGhvbWUgZ2F0ZXdheSBoYXMgdG8K PiBzdXBwb3J0IHByb3RvY29sIFgsIFksIGFuZCBaIiBhbmQgSSBkb24ndCBzZWUgdGhhdCB0aGVy ZSBpcyB0aGUgbmVlZCB0bwo+IGZvcm0gYSBXRyB0byBkbyB0aGF0LiBUaGUgcHJvdG9jb2wgc3Rh bmRhcmRzIGV4aXN0IGFuZCBtb3N0IG9mIHRoZSBob21lCj4gZ2F0ZXdheXMgc3VwcG9ydCB0aGVt IChvciBhIHN1YnNldCBvZiB0aGVtKSwgc28gd2h5IGRvIHdlIG5lZWQgYW5vdGhlcgo+IHN0YW5k YXJkIGhlcmU/IFdoYXQgZGlkIEkgbWlzcyBoZXJlPwoKQWN0dWFsbHksIHdoYXQgd2UncmUgZmlu ZGluZyBpcyB0aGF0IG1vc3Qgb2YgdGhlIGV4aXN0aW5nIChhbmQgY3VycmVudGx5IGZvcgpzYWxl KSBob21lIGdhdGV3YXlzIGRvIG5vdCBwcm92aWRlIHN1ZmZpY2llbnQgc3VwcG9ydCwgb3Igc3Vw cG9ydCB0aGVzZQp0aGluZ3MgaW4gd2F5cyBub3QgaW50ZW5kZWQgYnkgdGhlIHJlbGV2YW50IHN0 YW5kYXJkcyBhdXRob3JzLgoKPiBCVFcgSSBhbSBzdXJlIHdoZXRoZXIgSSBnb3QgaXQgcmlnaHQs IGJ1dCBhIGhvbWUgZ2F0ZXdheSBoZXJlIGlzIG1vcmUgb3IKPiBsZXNzIHRoYXQgd2hhdCB4RFNM IG1vZGVtcyBhcmUgdG9kYXk/IEkgbWVhbiwgc29tZXRoaW5nIHRoYXQgc2VydmVzIGFzIGEKPiBy b3V0ZXIgZm9yIHlvdXIgbG9jYWwgbmV0d29yayBhbmQgZ2F0ZXdheSB0byB0aGUgaW50ZXJuZXQ/ CgpBIGhvbWUgZ2F0ZXdheSBpcyBkaWZmZXJlbnQgZnJvbSBhIERTTCBtb2RlbSwgY2FibGUgbW9k ZW0sIGV0Yy4gIEl0IGlzIHRoZQpnZW5lcmFsIGNsYXNzIG9mIGRldmljZSB0aGF0IGNvbm5lY3Rz IHRvIHRoYXQgYWNjZXNzIGRldmljZS4gVGhlc2UgYXJlIG9mdGVuCmJyYW5kZWQgYXMgImhvbWUg cm91dGVycyIgdGhvdWdoIHRoZXkgYXJlIG5vdCBwdXJlbHkgcm91dGVycy4gVGhleSB2YXJpb3Vz bHkKcHJvdmlkZSBOQVQvUEFULCBmaXJld2FsbCBzZXJ2aWNlcywgREhDUCBzZXJ2ZXJzIGZvciB0 aGUgTEFOLCBldGMuCgpKYXNvbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KaG9tZWdhdGUgbWFpbGluZyBsaXN0CmhvbWVnYXRlQGlldGYub3JnCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaG9tZWdhdGUKCgoKUCBHbyBHcmVlbiEg UHJpbnQgdGhpcyBlbWFpbCBvbmx5IHdoZW4gbmVjZXNzYXJ5LiBUaGFuayB5b3UgZm9yIGhlbHBp bmcgVGltZSBXYXJuZXIgQ2FibGUgYmUgZW52aXJvbm1lbnRhbGx5IHJlc3BvbnNpYmxlLgogCiAK VGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBX YXJuZXIKQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQs IGNvbmZpZGVudGlhbCwKb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUg V2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbAppcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoCml0IGlzIGFkZHJlc3NlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzCkUtbWFpbCwgeW91IGFy ZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwKZGlzdHJpYnV0aW9uLCBj b3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzCm9mIGFu ZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBt YXkgYmUKdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5CnRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRl bGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueQpjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJp bnRvdXQuCg== From kirk.erichsen@twcable.com Mon Jun 15 18:59:48 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 B30073A6921 for ; Mon, 15 Jun 2009 18:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 A9YgB-MvXs5K for ; Mon, 15 Jun 2009 18:59:48 -0700 (PDT) Received: from pblpas02.twcable.com (pblpas02.twcable.com [204.235.121.150]) by core3.amsl.com (Postfix) with ESMTP id D5EB33A68F5 for ; Mon, 15 Jun 2009 18:59:47 -0700 (PDT) X-SENDER-IP: 10.157.247.214 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,225,1243828800"; d="scan'208";a="422580604" Received: from unknown (HELO prvpmailconn4.corp.twcable.com) ([10.157.247.214]) by pblpas02.twcable.com with ESMTP; 15 Jun 2009 21:59:57 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn4.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 21:59:56 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 Jun 2009 21:57:19 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] PDF of BoF Proposal thread-index: AcnuAai7P5695VhQmkmQMxqOK7aQPAAJB94b References: From: "Erichsen, Kirk" To: "Livingood, Jason" , "Damian Gerow" , "Lars Eggert" X-OriginalArrivalTime: 16 Jun 2009 01:59:56.0844 (UTC) FILETIME=[25E0FEC0:01C9EE26] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: homegate@ietf.org Subject: Re: [homegate] PDF of BoF Proposal 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, 16 Jun 2009 01:59:48 -0000 SSBjb25jdXIgKGFnYWluKS4gRnJvbSBhbiBNU08vU2VydmljZSBQcm92aWRlciBzdGFuZHBvaW50 LCBpdCdzIGFsbCBhYm91dCBkZXRhaWxlZCBpbnN0cnVjdGlvbiBmb3IgdGhlIGdhdGV3YXkgcm91 dGVyIHZlbmRvcnMgdG8gZW5zdXJlIHdlIGhhdmUgYSBjb25zaXN0ZW50IGZlYXR1cmUgc2V0IGFu ZCBmdW5jdGlvbmFsaXR5IGZyb20gdmVuZG9yIHRvIHZlbmRvciBhbmQgcHJvZHVjdCB0byBwcm9k dWN0LCBhdCBsZWFzdCB3aXRoaW4gdGhlIGNvbnN0cmFpbnRzIG9mIHRoZSBjb3JlIGZ1bmN0aW9u YWxpdHkuIFdlIGNhbiBiZSBtaW5kZnVsIHRoYXQgd2Ugd2lsbCBpbnZhcmlhYmxlIGxlYXZlIGhv bGVzIHRoYXQgYWxsb3cgZm9yIHZlbmRvcnMgdG8gaW5ub3ZhdGUgb24gc29tZSBvZiB0aGUgbGVz cyBjcml0aWNhbCBkZXRhaWxzIHRvIHByb3ZpZGUgcHJvZHVjdCBkaWZmZXJlbnRpYXRpb24uCiAK LUtFCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKRnJvbTogaG9tZWdhdGUtYm91 bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgTGl2aW5nb29kLCBKYXNvbgpTZW50OiBNb24gNi8x NS8yMDA5IDM6MzggUE0KVG86IERhbWlhbiBHZXJvdzsgTGFycyBFZ2dlcnQKQ2M6IGhvbWVnYXRl QGlldGYub3JnClN1YmplY3Q6IFJlOiBbaG9tZWdhdGVdIFBERiBvZiBCb0YgUHJvcG9zYWwKCgoK SSdtIG5vdCBzdXJlIHRoYXQgZW5kIHVzZXJzIGFyZSB0aGUgdGFyZ2V0IGF1ZGllbmNlLiAgSW5z dGVhZCwgSU1ITywgSSB0aGluawppdCBpcyBlcXVpcG1lbnQgdmVuZG9ycyBhbmQgbGFyZ2UgYnV5 ZXJzIChJU1BzLCBtZWdhIHJldGFpbGVycywgZXRjLikuCgpKYXNvbgoKCk9uIDYvMTIvMDkgMToz MiBQTSwgIkRhbWlhbiBHZXJvdyIgPGRnZXJvd0BhZmZsaWN0aW9ucy5vcmc+IHdyb3RlOgoKPiBB cyB0aGUgdGFyZ2V0IGNvbnN1bWVycyBvZiB0aGlzIGVmZm9ydCB3b3VsZCBiZSB0aGUgZW5kIHVz ZXIsIEkgdGhpbmsgYSBzZXQgb2YKPiBCQ1BzIGZhbGxzIGp1c3Qgc2hvcnQgb2YgdGhlIG1hcmsu ICBUaGVyZSBuZWVkcyB0byBiZSBzb21lIHdheSBmb3IgSm9obiBRLgo+IFB1YmxpYyB0byBwaWNr IHVwIGEgYm94LCBsb29rIGF0IGEgbG9nbyBvciBwaHJhc2UsIGFuZCB1bmRlcnN0YW5kIGV4YWN0 bHkKPiB3aGF0IHRoYXQgcHJvZHVjdCBnaXZlcyBoaW0uICBpLmUuICdHYXRld2F5IENlcnRpZmll ZCcgd291bGQgbWVldCBhbGwgc3RhdGVkCj4gcmVxdWlyZW1lbnRzIGZvciBhY3RpbmcgYXMgeW91 ciBzdGFuZGFyZCBob21lIGdhdGV3YXkuICAnTWVkaWEgQ2VydGlmaWVkJwoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KaG9tZWdhdGUgbWFpbGluZyBsaXN0 CmhvbWVnYXRlQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aG9tZWdhdGUKCgoKUCBHbyBHcmVlbiEgUHJpbnQgdGhpcyBlbWFpbCBvbmx5IHdoZW4gbmVjZXNz YXJ5LiBUaGFuayB5b3UgZm9yIGhlbHBpbmcgVGltZSBXYXJuZXIgQ2FibGUgYmUgZW52aXJvbm1l bnRhbGx5IHJlc3BvbnNpYmxlLgogCiAKVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIKQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRp b24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwKb3Igc3ViamVjdCB0byBjb3B5 cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbAppcyBpbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdo aWNoCml0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCBvZiB0aGlzCkUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2Vt aW5hdGlvbiwKZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRp b24gdG8gdGhlIGNvbnRlbnRzCm9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBz dHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUKdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5CnRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueQpjb3B5IG9m IHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuCg== From kirk.erichsen@twcable.com Mon Jun 15 19:13: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 A2E3B3A6D3F for ; Mon, 15 Jun 2009 19:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.443 X-Spam-Level: X-Spam-Status: No, score=-0.443 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 zibXvbszpP9Q for ; Mon, 15 Jun 2009 19:13:24 -0700 (PDT) Received: from pblpas02.twcable.com (pblpas02.twcable.com [204.235.121.150]) by core3.amsl.com (Postfix) with ESMTP id 9A4FE3A6D30 for ; Mon, 15 Jun 2009 19:13:24 -0700 (PDT) X-SENDER-IP: 10.157.247.213 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,225,1243828800"; d="scan'208";a="422582829" Received: from unknown (HELO prvpmailconn3.corp.twcable.com) ([10.157.247.213]) by pblpas02.twcable.com with ESMTP; 15 Jun 2009 22:13:35 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 22:13:35 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 Jun 2009 22:13:34 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] PDF of BoF Proposal thread-index: AcnuAoR+UY3b1qKjSVSCxcr5DdSBuQAI8H2P References: From: "Erichsen, Kirk" To: "Iljitsch van Beijnum" , "Livingood, Jason" X-OriginalArrivalTime: 16 Jun 2009 02:13:35.0170 (UTC) FILETIME=[0DA3A220:01C9EE28] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: homegate@ietf.org Subject: Re: [homegate] PDF of BoF Proposal 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, 16 Jun 2009 02:13:25 -0000 SWxqaXRzY2gsCiAKSSdsbCBjbGFyaWZ5IHRoZSBwb2ludCBpbiBteSBwcmV2aW91cyBwb3N0LiBX aGF0IEkgd2FzIHN1Z2dlc3Rpbmcgd2FzIHRoYXQgd2Ugc3RhcnQgb3VyIGVmZm9ydHMgYXJvdW5k IGEgbW9yZSBiYXNpYyBzZXQgb2YgdXNlIGNhc2UgYXNzdW1wdGlvbnMgKGkuZS4gc2luZ2xlIHN1 Ym5ldCwgZGV2aWNlIGlzIGNvcmUgb2YgdGhlIG5ldHdvcmssIGV0Yy4pLCBmdWxseSBmbGVzaCBv dXQgdGhlIHNpbXBsZXIgdXNlIGNhc2Ugc2NlbmFyaW9zIGFuZCBtb3ZlIG9uIHRvIHRoZSBtb3Jl IGNvbmplY3R1cmUvZGViYXRlLXByb25lIHVzZSBjYXNlcyBmcm9tIHRoZXJlLiBJIGRpZCBub3Qg aW50ZW5kIHRvIHN1Z2dlc3Qgd2Ugd291bGQgbm90IG1ha2UgdGhlIGVmZm9ydCB0byBjYXB0dXJl IHRoZSBtb3JlIGNvbXBsZXggbmV0d29ya3MgdGhhdCB3aWxsIGludmFyaWFibHkgZXhpc3QgKGFu ZCBvdmVyIHRpbWUsIHRoZSBzaW1wbGVyIG5ldHdvcmtzIHdpbGwgYmVjb21lIG1vcmUgY29tcGxp Y2F0ZWQgYXMgYSBmdW5jdGlvbiBvZiBpbmNyZWFzZWQgbnVtYmVycyBvZiBlbWJlZGRlZCBkZXZp Y2VzLCBhbmQgdGhlIGltcGxlbWVudGF0aW9uIG9mIHRob3NlIGRldmljZXMsIGV0Yy4pLiAKIApX aGF0IEkgYW0gcHJvcG9zaW5nIGlzIGEgY3Jhd2wsIHdhbGssIHJ1biBwcm9ncmVzc2lvbiBmcm9t IGxlYXN0IGNvbXBsZXggdG8gbW9zdCBjb21wbGV4LCB3aXRoIHRoZSBkZWNpc2lvbiBvbiBob3cg ZmFyIHdlIGdvIGRldGVybWluZWQgYnkgdGhpcyBncm91cC4gV2Ugd2lsbCBuZWVkIHRvIGRpc2N1 c3MgdGhlIGxpa2VseSBjb21wbGV4aXR5IHRvIGJlIGZvdW5kIGluIHRoZSBmb3Jlc2VlYWJsZSBm dXR1cmUgd2l0aGluIHRoZSBob21lIG5ldHdvcmsgYW5kIGNob29zZSBvdXIgd29yZGluZyBhY2Nv cmRpbmdseSB0byBhY2NvbW1vZGF0ZS4gSSB3YXMgdGhpbmtpbmcgc3BlY2lmaWNhbGx5IG9mIHNv bWUgb2YgdGhlIHNtYWxsIGJ1c2luZXNzZXMvaG9tZSB3b3JrZXIgYW5kIG9mIHRoZSBzYWxlcyBv ZmZpY2UvYnJhbmNoL2RpdmlzaW9uL2hlYWQgcXVhcnRlcnMgbW9kZWwsIHdoZXJlIGh1YiBhbmQg c3Bva2UgYW5kIHBhcnRpYWwgb3IgZnVsbHkgbWVzaGVkIG5ldHdvcmtzIG1heSBleGlzdC4gSSd2 ZSBhbHNvIGNvbnRlbXBsYXRlZCBzb21lIG9mIHRoZSBpbXBsaWNhdGlvbnMgZm9yIHRoZSBtYWpv cml0eSBvZiB0aGUgZW1iZWRkZWQgZGV2aWNlcyBpbiB0aGUgaG9tZSBuZXR3b3JrIGVhY2ggYmVp bmcgYm90aCByb3V0ZXIgYW5kIGhvc3QgKGJhc2VkIG9uIGNlcnRhaW4gQ0UgdHJlbmRzKS4gU2lu Y2UgdGhlIHBlcm11dGF0aW9ucyBhcmUgZHJhbWF0aWNhbGx5IG1vcmUgY29tcGxpY2F0ZWQgdGhh biB0aGUgc2ltcGxlIGNhc2UgSSBwcm9wb3NlZCBpbiBteSBwcmV2aW91cyBwb3N0IChhbmQgc29t ZSBvZiB0aGlzIGlzIGNyeXN0YWwgYmFsbCB0eXBlIGZ1dHVyaXNtKSwgSSByZS1pdGVyYXRlIHdl IGNhbiBwcm9iYWJseSBtb3ZlIGZhc3RlciB3aXRoIGEgZmlyc3QtZHJhZnQgc3RyYXdtYW4gZG9j dW1lbnQgdG8gdGFrZSB0byBIaXJvc2hpbWEgaWYgd2UgY29uZmluZSBvdXJzZWx2ZXMsIGF0IGZp cnN0LCB0byBhIHNpbXBsZXIgc2V0IG9mIHVzZSBjYXNlcyBhbmQgZ2l2ZSBvdXJzZWx2ZXMgc29t ZSB0aW1lIHRvIGNvbnRlbXBsYXRlIHRoZSBtb3JlIGNvbXBsaWNhdGVkIHVzZSBjYXNlIHNjZW5h cmlvcy4gV2hlbiB0aGUgdGltZSBjb21lcywgSSBjYW4gb2ZmZXIgc2V2ZXJhbCBvZiB0aGUgbW9y ZSBjb21wbGV4IHVzZSBjYXNlcyBmb3Igb3BlbiBkZWJhdGUgd2l0aGluIHRoaXMgZ3JvdXAuCiAK LUtFCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKRnJvbTogaG9tZWdhdGUtYm91 bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgSWxqaXRzY2ggdmFuIEJlaWpudW0KU2VudDogTW9u IDYvMTUvMjAwOSAzOjQ0IFBNClRvOiBMaXZpbmdvb2QsIEphc29uCkNjOiBob21lZ2F0ZUBpZXRm Lm9yZwpTdWJqZWN0OiBSZTogW2hvbWVnYXRlXSBQREYgb2YgQm9GIFByb3Bvc2FsCgoKCk9uIDE1 IGp1biAyMDA5LCBhdCAyMzozOCwgTGl2aW5nb29kLCBKYXNvbiB3cm90ZToKCj4gSSdtIG5vdCBz dXJlIHRoYXQgZW5kIHVzZXJzIGFyZSB0aGUgdGFyZ2V0IGF1ZGllbmNlLgoKVGhleSdyZSBtYXli ZSBub3QgdGhlIGF1ZGllbmNlIGZvciB0aGUgZG9jdW1lbnRzIHRoYXQgd2lsbCBiZSB0aGUgCm91 dHB1dCBvZiBhbiBJRVRGIGVmZm9ydCwgYnV0IHRoZXkncmUgYWJzb2x1dGVseSB0aGUgdGFyZ2V0 IGF1ZGllbmNlIApmb3IgdGhlIHByb2R1Y3RzIHRoYXQgd2lsbCBiZSBidWlsdCBiYXNlZCBvbiB0 aGVzZSBkb2N1bWVudHMuIChOb3QgdG8gCm1lbnRpb24sIHRoZXkgcGF5IGZvciBldmVyeXRoaW5n ISkgQXMgc3VjaCwgdGhlIHVzZXIncyBuZWVkcyBtdXN0IGJlIApmcm9udCBhbmQgY2VudGVyLgoK Rm9yIGluc3RhbmNlLCBJIHRoaW5rIHRoYXQgc29tZW9uZSBtZW50aW9uZWQgc29tZXRoaW5nIGFs b25nIHRoZSBsaW5lcyAKb2YgImxldCdzIGtlZXAgdGhpbmdzIHNpbXBsZSBhbmQgYXNzdW1lIG9u bHkgYSBzaW5nbGUgc3VibmV0IiAobXkgCmludGVycHJldGF0aW9uKS4gVGhpcyB3b24ndCBkby4g VG9kYXksIG9ubHkgYWR2YW5jZWQgb3IgZHVtYiB1c2VycyAKaGF2ZSBtdWx0aXBsZSBzdWJuZXRz LCBidXQgaW4gdGhlIGZ1dHVyZSB3aXRoIG1vcmUgYW5kIG1vcmUgaGVhdnkgCnNlY3VyaXR5IHJl cXVpcmVtZW50cyBmb3Igd29ya2luZyBmcm9tIGhvbWUgYW5kIGFwcGxpYW5jZXMgdGhhdCAKY29u bmVjdCB0byB0aGUgaG9tZSBuZXR3b3JrLCBtb3JlIGFuZCBtb3JlIHJlZ3VsYXIgdXNlcnMgd2ls bCB3YW50LwpuZWVkIG11bHRpcGxlIHN1Ym5ldHMuIFdpdGggSVB2NiB3ZSBoYXZlIHRvIHNwZWNp ZmljYWxseSBzdXBwb3J0IHRoaXMsIAp3ZSBjYW4ndCBqdXN0IGxldCB0aGVtIGRvdWJsZSBOQVQg bGlrZSB3aGF0IGhhcHBlbnMgb2Z0ZW4gdG9kYXkgaWYgCnRoZXJlJ3MgbW9yZSB0aGFuIG9uZSBJ UHY0IGhvbWUgZ2F0ZXdheS4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KaG9tZWdhdGUgbWFpbGluZyBsaXN0CmhvbWVnYXRlQGlldGYub3JnCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaG9tZWdhdGUKCgoKUCBHbyBHcmVlbiEgUHJp bnQgdGhpcyBlbWFpbCBvbmx5IHdoZW4gbmVjZXNzYXJ5LiBUaGFuayB5b3UgZm9yIGhlbHBpbmcg VGltZSBXYXJuZXIgQ2FibGUgYmUgZW52aXJvbm1lbnRhbGx5IHJlc3BvbnNpYmxlLgogCiAKVGhp cyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJu ZXIKQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNv bmZpZGVudGlhbCwKb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2Fy bmVyIENhYmxlLiBUaGlzIEUtbWFpbAppcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2Yg dGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoCml0IGlzIGFkZHJlc3NlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzCkUtbWFpbCwgeW91IGFyZSBo ZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwKZGlzdHJpYnV0aW9uLCBjb3B5 aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzCm9mIGFuZCBh dHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkg YmUKdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5CnRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0 ZSB0aGUgb3JpZ2luYWwgYW5kIGFueQpjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRv dXQuCg== From richard@bennett.com Mon Jun 15 22:04:51 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 042C63A6AD1 for ; Mon, 15 Jun 2009 22:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 4WElSdnuMfDy for ; Mon, 15 Jun 2009 22:04:49 -0700 (PDT) Received: from outbound-mail-112.bluehost.com (outbound-mail-112.bluehost.com [69.89.24.2]) by core3.amsl.com (Postfix) with SMTP id C8D503A6A3D for ; Mon, 15 Jun 2009 22:04:49 -0700 (PDT) Received: (qmail 10510 invoked by uid 0); 16 Jun 2009 05:04:58 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy3.bluehost.com with SMTP; 16 Jun 2009 05:04:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-MimeOLE:thread-index:X-Identified-User; b=cU6j9s+2OUyLb+xlWM7Kdz9OWqiPCJuJMG/5h6AT6hGStOXLSVm8Aaj7qnyhktz+xZxavcsH9WLGbAibjWxW66tt6Sjk8UJ5dH+ohGGfi11GTBRe1QmJ1kwTX8rT+94u; Received: from c-24-5-230-26.hsd1.ca.comcast.net ([24.5.230.26] helo=Honkin) by host46.hostmonster.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MGQqw-0007h6-3P; Mon, 15 Jun 2009 23:04:58 -0600 From: "Richard Bennett" To: "'Heather Kirksey'" , References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com><4A3182AE.9040508@swin.edu.au><4A31FCB3.7080607@unifr.ch><20090612133220.70c3094c.dgerow@afflictions.org><20090615133048.GA38531@shinkuro.com> In-Reply-To: Date: Mon, 15 Jun 2009 22:04:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 thread-index: AcntvY3IJI7GRqqKRyS0ATiRYbfBbgAOUxbgABIoduA= X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 24.5.230.26 authed with richard+bennett.com} Subject: Re: [homegate] PDF of BoF Proposal 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, 16 Jun 2009 05:04:51 -0000 These two documents are very informative regarding the state of the art regarding Internet protocol knowledge among gateway vendors, and I = recommend reading them. What you'll likely find most interesting is not what they = say as what they don't; there are enormous holes in both of them. Search for "ECN" and you'll get no hits, for example.=20 >From my experience, Broadband Forum has an international membership with = a North American bias, while HGI has a more European membership, FWIW.=20 Richard Bennett -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On = Behalf Of Heather Kirksey Sent: Monday, June 15, 2009 1:58 PM To: homegate@ietf.org Subject: Re: [homegate] PDF of BoF Proposal Andrew, If you're considering ISPs using this work to enforce requirements on = their vendors, it might be worth checking out some work that's already gone on = in this area: Broadband Forum TR-124 defines a set of modular functional requirements = for broadband residential gateways: http://www.broadband-forum.org/technical/download/TR-124.pdf. The Home Gateway Initiative also has a Home Gateway Requirements: Residential Profile document: http://www.homegatewayinitiative.org/publis/HGI_V1.01_Residential.pdf. In addition, Broadband Forum has a work-in-progress document called = PD-192 that deals with the functional IPv6 requirements for gateways in the = home based on current operator plans for migration and deployment. BBF was already planning to liaise the PD-192 document in the relatively near = future to get feedback on it. Thanks, Heather Heather Kirksey Motive Product Division Alcatel-Lucent hkirksey@motive.com +1.512.531.1126 (office) +1.512.917.7938 (mobile) =A0 -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On = Behalf Of Andrew Sullivan Sent: Monday, June 15, 2009 8:31 AM To: homegate@ietf.org Subject: Re: [homegate] PDF of BoF Proposal On Sat, Jun 13, 2009 at 08:40:42AM +0200, Lars Eggert wrote: > it's not clear that the consumer of this effort would be the end user = -=20 > few IETF specifications are. In my mind, this was mostly about giving=20 > guidelines to vendors and operators. > The IETF isn't doing standards certification, and there are good = reasons [[HRK]]=20 > for that. But nothing stops an outside entity to run a conformance = test=20 > program based on IETF specs, and I agree that for the end users, some=20 > sort of easily identified distinguisher on the box would be helpful. In my view, the above should be a key factor in our thinking. IETF standards get "enforced" by contracts. Large numbers of these gateway devices are sold or otherwise provided to end users by ISPs. So if ISPs have something to which they can require vendors to conform as part of the ISPs' purchase of the devices or recommendation of them to end customers, that will probably be enough market pressure to achieve the desired result. A --=20 Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. _______________________________________________ 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 iljitsch@muada.com Tue Jun 16 01:46:08 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 388603A69E1 for ; Tue, 16 Jun 2009 01:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.332 X-Spam-Level: X-Spam-Status: No, score=-6.332 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 ssxavfv3gwYr for ; Tue, 16 Jun 2009 01:46:07 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 2BCF83A691F for ; Tue, 16 Jun 2009 01:46:07 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.219]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n5G8jgmQ083184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Jun 2009 10:45:42 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: "Erichsen, Kirk" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 10:43:56 +0200 References: X-Mailer: Apple Mail (2.935.3) Cc: homegate@ietf.org Subject: Re: [homegate] PDF of BoF Proposal 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, 16 Jun 2009 08:46:08 -0000 On 16 jun 2009, at 4:13, Erichsen, Kirk wrote: > What I was suggesting was that we start our efforts around a more > basic set of use case assumptions (i.e. single subnet, device is > core of the network, etc.), fully flesh out the simpler use case > scenarios and move on to the more conjecture/debate-prone use cases > from there. I don't really see any value in that. There are two approaches: do it fast, or get it right. As we are more than a decade into the broadband revolution the ship has sailed on the former, so we have to go for the latter. This means addressing everything to the degree it needs to be addressed, not iterate over stuff that has been out in the market for years. I haven't read the PDF that is still mentioned in the subject, apparently I joined the list after it was posted so I'm not sure what's in there that is considered important or time sensitive. But I've been following the IPv6 CPE efforts in v6ops and think that is very important work. Unfortunately, it's a bit too complex to hammer out quickly. From lars.eggert@nokia.com Tue Jun 16 02:32:08 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 392403A6D5C for ; Tue, 16 Jun 2009 02:32:08 -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 mQ-Ji1CwhuAI for ; Tue, 16 Jun 2009 02:32:07 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 999133A69B8 for ; Tue, 16 Jun 2009 02:32:06 -0700 (PDT) Received: from pc-g103.wlan.inet.fi (pc-g103.wlan.inet.fi [62.71.98.103]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n5G9W1W4025658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Jun 2009 12:32:01 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <266CD650-86B9-4DCB-8790-283341B741BA@nokia.com> From: Lars Eggert To: Iljitsch van Beijnum In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-21-549474308; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 12:30:46 +0300 References: X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Tue, 16 Jun 2009 12:32:01 +0300 (EEST) Cc: "homegate@ietf.org" Subject: Re: [homegate] PDF of BoF Proposal 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, 16 Jun 2009 09:32:08 -0000 --Apple-Mail-21-549474308 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2009-6-16, at 11:43, Iljitsch van Beijnum wrote: > I haven't read the PDF that is still mentioned in the subject, I'm sure you know that this list has an archive at http://www.ietf.org/mail-archive/web/homegate/current/maillist.html , but I'll save you some searching: http://www.ietf.org/mail-archive/web/homegate/current/msg00001.html Lars --Apple-Mail-21-549474308 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA2MTYwOTMwNDdaMCMGCSqGSIb3DQEJBDEWBBSzn0hIQ46oErn9 EaAa5fNwA0nlgTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEACNxnAQiQBwAWIE1exSa+wtxqaaQO+DLiUQrFB8WYaBF2BOFk9oc+ 9P3vJh1td0MRZBxhjOCBT7Zv4jF6trQcTO+s9rDiuhpsPKd5xHBdzl35hd4zA1INnPVJwgG6ln9p OkDvoJo8VFfy/P/zfb2+WPZaasvYVqFrEcjkpPSVzQEyE0vHV9MqLUC1BRrn7T/Ozjxf+8hUWcUv rXQHuz5XD469VA7MC6YSBbFV/TRbQp5rCDGRzqI8ulJHOmc7FEWRk2tbtStgm6/PrnjJCnwUdWuq LLtrBF3ICEqtKBw6s/O6Ll7uQ1sDivjVJsE1BmSQJFWgbkApzoNDyigorbi1AAAAAAAAAA== --Apple-Mail-21-549474308-- From ajs@shinkuro.com Fri Jun 12 09:36: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 5637C3A68DB; Fri, 12 Jun 2009 09:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=0.524, 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 Dc9TqsZTrJsp; Fri, 12 Jun 2009 09:36:36 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 7D8573A68CE; Fri, 12 Jun 2009 09:36:36 -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 484792FE9623; Fri, 12 Jun 2009 16:36:43 +0000 (UTC) Date: Fri, 12 Jun 2009 12:36:41 -0400 From: Andrew Sullivan To: Richard Bennett Message-ID: <20090612163641.GF36147@shinkuro.com> References: <4A31EDD1.8000202@ripe.net> 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) X-Mailman-Approved-At: Tue, 16 Jun 2009 02:48:36 -0700 Cc: homegate@ietf.org, ipdir@ietf.org, 'IAB IAB' , iesg@ietf.org, 'TSV Dir' , 'Jason Livingood' Subject: Re: [homegate] PDF of BoF Proposal 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, 12 Jun 2009 16:36:37 -0000 On Fri, Jun 12, 2009 at 03:45:11AM -0700, Richard Bennett wrote: > found that one person was not going to make much of a difference, and now > feel that it's an urgent priority for IETF to show some leadership in this > area. And believe me, if you don't, nobody else will and we'll all just keep > on complaining about the fact at ECN languishes even though it's been a > draft standard since 2001 (RFC 3168), and similar fate will befall DNSSEC. I agree that this is an area where the IETF could do some useful work. One of the things that has historically been a complaint about the DNS specifications (and I bet about other protocols, but I know the DNS case best) is that there's a giant pile of RFCs; and if you want to know what you need to implement you have to read them all, figure out what updates what, and then work out precisely what applies to your case. This is by no means an impossible task for someone who understands how the RFC series works and who knows about DNS, but I think it is unrealistic of us to assume that home-gateway builders are going to undertake that kind of work. I bet the state of affairs is similar for other protocols, particularly older ones. So just putting together a "Home Gateway Builder's Guide to the Perplexed" would be a useful piece of work. That said, I have some sympathy with the decision not to hold the BOF in Stockholm, since there isn't a lot around which to structure a BOF yet. I would like to suggest that we on the homegate list should take the time between now and Stockholm to start working out what we want to do, and perhaps even put a proposed charter -- or -00 draft or two -- together so that we have something to nudge people towards reading in Stockholm. Such work might turn out naturally to fit under one or two existing WGs, or else we might find that we actually need a WG for the work; in the latter case, at the next IETF meeting we'll have the opportunity to ask for a BOF again, with a proposed charter in hand. I hereby volunteer to help with such work, particularly with respect to DNS, DNSSEC and its interactions with home gateways. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From kirk.erichsen@twcable.com Mon Jun 15 18:56: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 E57DE3A6D19; Mon, 15 Jun 2009 18:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.306 X-Spam-Level: X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 BfucR8PMDLWJ; Mon, 15 Jun 2009 18:56:47 -0700 (PDT) Received: from pblpas02.twcable.com (pblpas02.twcable.com [204.235.121.150]) by core3.amsl.com (Postfix) with ESMTP id 766A83A67B3; Mon, 15 Jun 2009 18:56:46 -0700 (PDT) X-SENDER-IP: 10.157.247.213 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,225,1243828800"; d="scan'208";a="422580170" Received: from unknown (HELO prvpmailconn3.corp.twcable.com) ([10.157.247.213]) by pblpas02.twcable.com with ESMTP; 15 Jun 2009 21:56:54 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 21:56:54 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 Jun 2009 21:52:56 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] PDF of BoF Proposal thread-index: AcnrLO8u8N/5YHb2TZ6mGipy7MXYMgAAMH/AAAYOYcAArqzB6gAJI2pG References: From: "Erichsen, Kirk" To: "Livingood, Jason" , "Richard Bennett" , "Murari Sridharan" , "Henk Uijterwaal" , "grenville armitage" X-OriginalArrivalTime: 16 Jun 2009 01:56:54.0029 (UTC) FILETIME=[B8E9A3D0:01C9EE25] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Mailman-Approved-At: Tue, 16 Jun 2009 02:48:57 -0700 Cc: iesg@ietf.org, ipdir@ietf.org, IAB IAB , homegate@ietf.org, TSV Dir Subject: Re: [homegate] PDF of BoF Proposal 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, 16 Jun 2009 01:56:49 -0000 UmljaGFyZCBwb2ludHMgb3V0IGFub3RoZXIgdmVyeSBzYWxpZW50IHBvaW50OiBBIGRldGFpbGVk IHNwZWNpZmljYXRpb24gdGhhdCBjb3ZlcnMgdGhlIHJlbGV2YW50IG9wdGlvbnMgYW5kIG1heSBi ZSBhIHN1YnNldCAob3Igc3VwZXJzZXQpIG9mIHRoZSByZXF1aXJlbWVudHMgKHdoZXJlIHNvbWUg ZnVuY3Rpb25zIG1heSBiZSBtYW5kYXRvcnkgdnMuIG9wdGlvbmFsKSBmcm9tIHRoZSB4LXJlZmVy ZW5jZWQgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbnMgYW5kIGRldGFpbGVkIGV4YW1wbGVzIG9mIHRo ZSBleHBlY3RlZCBiZWhhdmlvcnMgdG8gZmF2b3IgY29uc2lzdGVudCBpbXBsZW1lbnRhdGlvbnMg dGhhdCBiZWFyIG1vcmUgY29tbW9uYWxpdHkgb24gY29yZSBmdW5jdGlvbmFsaXR5IGZyb20gdmVu ZG9yIHRvIHZlbmRvciB0aGFuIG5vdC4gSSB3YXMgZWF0aW5nIGx1bmNoIHdoZW4gSSByZWFkIFJp Y2hhcmQncyBleGFzcGVyYXRpb24gd2l0aCBtYW51ZmFjdHVyaW5nIGZvY3VzIHZzLiBlbmdpbmVl cmluZyBmb2N1cyBhdCB0aGUgZ2F0ZXdheSB2ZW5kb3JzIGFuZCBuZWFybHkgY2hva2VkIHdpdGgg bGF1Z2h0ZXIhIFBhcnRpY3VsYXJseSB0aGUgbGluZSBhYm91dCB0aGUgIm1pcmFjbGUiIG9mIGdh dGV3YXkgcHJvZHVjdHMgc28gYnVpbHQgZGlkIG5vdCBqdXN0IHNwb250YW5lb3VzbHkgZXhwbG9k ZSBvbiBmaXJzdCBwb3dlciB1cCEgVG9vIHRydWUhCiAKLUtFCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwoKRnJvbTogaG9tZWdhdGUtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg b2YgTGl2aW5nb29kLCBKYXNvbgpTZW50OiBNb24gNi8xNS8yMDA5IDM6MzEgUE0KVG86IFJpY2hh cmQgQmVubmV0dDsgJ011cmFyaSBTcmlkaGFyYW4nOyBIZW5rIFVpanRlcndhYWw7ICdncmVudmls bGUgYXJtaXRhZ2UnCkNjOiAnVFNWIERpcic7IGlwZGlyQGlldGYub3JnOyAnSUFCIElBQic7IGhv bWVnYXRlQGlldGYub3JnOyBpZXNnQGlldGYub3JnClN1YmplY3Q6IFJlOiBbaG9tZWdhdGVdIFBE RiBvZiBCb0YgUHJvcG9zYWwKCgoKR3JlYXQgZmVlZGJhY2ssIFJpY2hhcmQuICBUaGlzIGlzIGNl cnRhaW5seSBjb25zaXN0ZW50IHdpdGggd2hhdCB3ZSd2ZSBiZWVuCmhlYXJpbmcgZnJvbSBhIG51 bWJlciBvZiBjb25jZXJuZWQgcGFydGllcywgYW5kIGlzIG11Y2ggb2YgdGhlIGJhY2tncm91bmQK bW90aXZhdGlvbiBmb3IgdGhpcyB3b3JrLgoKSmFzb24KCgpPbiA2LzEyLzA5IDY6NDUgQU0sICJS aWNoYXJkIEJlbm5ldHQiIDxyaWNoYXJkQGJlbm5ldHQuY29tPiB3cm90ZToKCj4gQ291bGQgYmUg dGhhdCB0aGUgYXV0aG9ycyBhcmUgYnVzeSBvciBvZmYgdGhlIG5ldCBhdCB0aGUgbW9tZW50LCB0 aGV5J2xsCj4gaGF2ZSB0byBzcGVhayBmb3IgdGhhdC4gRnJvbSBteSBvd24gZXhwZXJpZW5jZSBh cyBhbiBlbmdpbmVlciB3aG8gdW50aWwKPiByZWNlbnRseSB3b3JrZWQgZm9yIGEgaG9tZSBnYXRl d2F5IGNvbXBhbnkgaW4gYSBwcm9kdWN0IGRldmVsb3BtZW50IHJvbGUsIEkKPiB0aGluayB0aGlz IGlzIGEgdml0YWwgcGllY2Ugb2Ygd29yayBhbmQgYW4gYXJlYSB3aGVyZSBJRVRGIGNvdWxkIG1h a2UgYSBodWdlCj4gcG9zaXRpdmUgaW1wYWN0IHdpdGggbGVzcyBlZmZvcnQgdGhhbiBpcyBpbnZv bHZlZCBpbiBzZXZlcmFsIG90aGVyIGFyZWFzLgo+Cj4gSG9tZSBnYXRld2F5cyBhcmUgdGhlIGNv bWJpbmF0aW9ucyBvZiBhIE5BVCwgYW4gRXRoZXJuZXQgc3dpdGNoLCBhIFdpLUZpCj4gYWNjZXNz IHBvaW50LCBhbmQgc29tZSBzb3J0IG9mIFdBTiBjb25uZWN0aW9uLCB3aGljaCBjYW4gYmUgZWl0 aGVyIGEgRFNMCj4gYWRhcHRlciwgYSBjYWJsZSBtb2RlbSwgb3IgYSBjb25uZWN0aW9uIHRvIGFu IGV4dGVybmFsIGxheWVyIHR3byBkZXZpY2UKPiByZWFjaGVkIG92ZXIgYSBzZXBhcmF0ZSBFdGhl cm5ldCBjb25uZWN0aW9uIG9yIHNvbWV0aGluZyBtb3JlIG9ic2N1cmUgbGlrZQo+IE1vQ0EuIFRo ZXkncmUgdmVyeSBsb3cgbWFyZ2luIHByb2R1Y3RzLCBzbyB0aGUgY29tcGFuaWVzIHRoYXQgcHJv ZHVjZSB0aGVtCj4gdGVuZCB0byBoYXZlIG1vcmUgZXhwZXJ0aXNlIGF0IG1hbnVmYWN0dXJpbmcg dGhhbiBlbmdpbmVlcmluZywgYW5kIHZlcnkKPiBsaXR0bGUgZXhwZXJ0aXNlIHNwZWNpZmljIHRv IElFVEYgcHJvdG9jb2xzLiBUaGUgbm9ybSBpbiB0aGUgaW5kdXN0cnkgaXMKPiBlbmdpbmVlcmlu ZyBtYW5hZ2VycyB3aG8gdW5kZXJzdGFuZCBEU0wgYnV0IG5vdCBESENQIGFuZCBjZXJ0YWlubHkg bm90IERTQ1AuCj4gSWYgeW91IGFza2VkIG9uZSB0byBleHBsYWluIE1QTFMgdGhleSB3b3VsZCBw cm9iYWJseSB0ZWxsIHlvdSBpdCdzIHRoZQo+IHNpc3RlciBjaXR5IG9mIFN0LiBQYXVsLgo+Cj4g QSBzdWItc2VjdG9yIG9mIHRoYXQgaW5kdXN0cnkgYnVpbGRzIHNwZWNpYWxpemVkIGdhdGV3YXlz IGZvciB0ZWxjb3MgdGhhdAo+IGluY2x1ZGVzIGEgc3VpdGUgb2YgbWFuYWdlbWVudCBwcm90b2Nv bCBjYWxsZWQgdGhpbmdzIGxpa2UgVFIwNjkgYW5kIFRSMDk4LAo+IHdoaWNoIHdlcmUgZGVmaW5l ZCBieSB0aGUgRFNMIEZvcnVtIChub3cgY2FsbGVkIHRoZSBCcm9hZGJhbmQgRm9ydW0pIGJlY2F1 c2UKPiB0aGV5IGRpZG4ndCB1bmRlcnN0YW5kIFNOTVAuIFRoZSAiVFIiIHByb3RvY29scyBoYXZl IGEgdmVyeSBiaXphcnJlIG9iamVjdAo+IG1vZGVsIHRoYXQgYmVhcnMgYSBtaW5pbWFsIHJlc2Vt YmxhbmNlIHRvIGFueSBhY3R1YWwgbmV0d29yayBkZXZpY2VzLCBhbmQKPiB1c2VzIFNPQVAgYW5k IFhNTCBpbnN0ZWFkIG9mIEFTTi4xLiBUaGUgb25lIGdvb2QgdGhpbmcgYWJvdXQgaXQgaXMgdGhh dCBpdAo+IGNhbiB1c2VkIHRvIGRvd25sb2FkIGZpcm13YXJlIHVwZGF0ZXMgdGhlIElTUCB3YW50 cyB0byBnZXQgb3V0Lgo+Cj4gVGhlIHNvZnR3YXJlIGluIHRoZXNlIGJveGVzIGlzIG9wZW4gc291 cmNlIGNvbWJpbmF0aW9ucyBvZiBMaW51eCBrZXJuZWxzLAo+IGJ1c3lib3gsIGFuZCB0aGUgcmVs YXRlZCBuZXR3b3JraW5nIHBpZWNlcywgcGFja2FnZWQgd2l0aCBwcm9wcmlldGFyeSBUUjA2OQo+ IGNvbXBvbmVudHMuIFRoZSBwcmluY2lwYWwgcGFja2FnZXJzIGFyZSBCcm9hZGNvbSBhbmQgSnVu Z28uCj4KPiBGcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgZW5naW5lZXJpbmcgbWFuYWdlcnMg YW5kIGN1c3RvbWVycywgdGhlIHNvZnR3YXJlCj4gaXMgYXQgYmVzdCBhIG51aXNhbmNlLCBhcyB0 aGV5IHZpZXcgdGhlaXIgaGFyZHdhcmUgYW5kIG1hbnVmYWN0dXJpbmcKPiBwcm9jZXNzZXMgYXMg dGhlIHByaW1hcnkgdmFsdWUgb2YgdGhlIGJveGVzLiBIYXJkd2FyZSB0ZW5kcyB0byBiZSBkZXNp Z25lZAo+IGFjY29yZGluZyB0byByZWZlcmVuY2UgZGVzaWducyBmcm9tIHRoZSBjaGlwIGNvbXBh bmllcy4KPgo+IFNwZWNzIGluIHRoaXMgaW5kdXN0cnkgYXJlIGxhdWdoYWJseSB0ZXJzZSwgZ2Vu ZXJhbGx5IGNvbnNpc3Rpbmcgb2YgRXhjZWwKPiBzcHJlYWRzaGVldHMgdGhhdCBkZXNjcmliZSBj b21wbGV0ZSBmdW5jdGlvbmFsIHN1YnN5c3RlbXMgd2l0aCB0d28gb3IgdGhyZWUKPiBnYXJibGVk IHNlbnRlbmNlcy4gVGhleSdyZSB2ZXJ5IGhlYXZ5IG9uIGJ1enp3b3Jkcy4gSXQncyBhIG1pcmFj bGUgdGhhdCBtb3N0Cj4gb2YgdGhlc2UgcHJvZHVjdHMgZG9uJ3QgZXhwbG9kZSB0aGUgZmlyc3Qg dGltZSB0aGV5J3JlIHBvd2VyZWQgb24uCj4KPiBUaGUgdmFsdWUgb2YgdGhpcyBCT0YgYW5kIGV2 ZW50dWFsIHdvcmtpbmcgZ3JvdXAgd291bGQgYmUgdG8gZGVmaW5lIGEKPiB0aG9yb3VnaCBCQ1Ag Zm9yIHRoZSBzb2Z0d2FyZSBjb21wb25lbnRzIHRoYXQgZ28gaW50byBob21lIGdhdGV3YXlzLiBU aGUKPiBtYW5hZ2VtZW50IHByb3RvY29sIGlzIHByZXR0eSBob3BlbGVzcywgYnV0IHByb2JhYmx5 IDc1JSBvZiB0aGUgY29kZSBjYW4gYmUKPiBkcmFzdGljYWxseSBpbXByb3ZlZCBpZiB0aGUgcmln aHQgcGVvcGxlIHdlcmUgdG8gd3JpdGUgYSBzcGVjIHRoYXQgZGVzY3JpYmVkCj4gdGhlIHByb3Bl ciByZXZpc2lvbnMsIG9wdGlvbnMsIGFuZCBmZWF0dXJlcyBmb3IgdGhlIElFVEYgcHJvdG9jb2xz IGludm9sdmVkLgo+IEVDTiB3YXMgbWVudGlvbmVkIHByb21pbmVudGx5IGluIHRoZSBQREYsIGFu ZCBJIGNhbiBndWFyYW50ZWUgeW91IHBlcnNvbmFsbHkKPiB0aGF0IHRoZXJlIGlzIG5vIGtub3ds ZWRnZSBvZiBFQ04gb3Igd2h5IGFueWJvZHkgd291bGQgd2FudCBpdCBpbiB0aGUgaG9tZQo+IGdh dGV3YXkgaW5kdXN0cnkuIEJ1dCBpZiB0aGUgSUVURiBwcm9kdWNlcyBhIEJDUCB0aGF0IHNheXMg IkhvbWUgZ2F0ZXdheXMKPiBzaG91bGQgbm90IGhhbHQgYW5kIGNhdGNoIGZpcmUgaWYgdGhleSBy ZWNlaXZlIGFuIElQdjQgcGFja2V0IHdpdGggRUNOIHNldCwiCj4gdGhlIG5leHQgcm91bmQgb2Yg UkZQcyBmcm9tIHRoZSB0ZWxjb3MgYW5kIG90aGVyIElTUHMgdG8gdGhlIGdhdGV3YXkgdmVuZG9y cwo+IHdvdWxkIGluY2x1ZGUgdGhhdCByZXF1aXJlbWVudCBhbmQgdGhlIHByb2R1Y3RzIHdvdWxk IGNvbmZvcm0uCj4KPiBJIGRvbid0IHRoaW5rIGl0J3MgcmVhbGlzdGljIHRvIHRyeSBhbmQgc2xv dWdoIHRoaXMgd29yayBvZmYgb24gVVBuUCBvcgo+IERMTkEsIGFzIHRob3NlIG9yZ2FuaXphdGlv bnMgYXJlIHZlcnkgYXBwbGljYXRpb24tb3JpZW50ZWQgYW5kIGRvbid0IGhhdmUKPiBncmVhdCBh d2FyZW5lc3Mgb2YgSUVURiBwcm90b2NvbHMgZWl0aGVyLiBJIHBlcnNvbmFsbHkgc2F0IHRocm91 Z2ggYSB3aG9sZQo+IHNlcmllcyBvZiB0ZWxlY29uZmVyZW5jZSBpbiB3aGljaCBETE5BIGxlYWRl cnMgcHJvcG9zZWQgdG8gbGltaXQgTVRVIHNpemVzCj4gdG8gMTAwMCBvY3RldHMgYmVjYXVzZSB0 aGV5IGRpZG4ndCBrbm93IGhvdyB0byBkbyBQYXRoIE1UVSBkaXNjb3ZlcnksIHN1Y2ggYQo+IG5l dyB0aGluZyBpdCdzIG9ubHkgYmVlbiBzcGVjaWZpZWQgc2luY2UgUkZDIDExOTEuIEFjY29yZGlu ZyB0byBETE5BLCB0aGUgZGUKPiBmYWN0byBzdGFuZGFyZCBwcm90b2NvbCBmb3Igc3RyZWFtaW5n IEludGVybmV0IHZpZGVvIGlzIEhUVFAsIG5vdCBSVFAvUlRTUC4KPgo+IFRoZSBETlNTRUMgcGVv cGxlIGhhdmUgdGVzdGVkIGhvbWUgZ2F0ZXdheXMgZm9yIGNvbXBsaWFuY2UgYW5kIGZvdW5kIG5v bmUgb2YKPiB0aGVtIGNhbiBoYW5kbGUgVURQLWZyYW1lZCByZXF1ZXN0IHBhY2tldHMgbGFyZ2Vy IHRoYW4gNTEyIGJ5dGVzLiBUaGUgaG9tZQo+IGdhdGV3YXkgcmVzcG9uc2UgaXMgIndoYXQncyBE TlNTRUM/Igo+Cj4gSSB3ZW50IHRvIHdvcmsgaW4gdGhhdCBwYXJ0aWN1bGFyIHNlZ21lbnQgYmVj YXVzZSBpdCBzZWVtZWQgdG8gbWUgdGhhdCBpdCdzCj4gZHJhZ2dpbmcgZG93biB0aGUgd2hvbGUg SW50ZXJuZXQgYmVjYXVzZSBpdCBpbnN0YWxscyBvYnNvbGV0ZSBwcm90b2NvbHMgaW4KPiBodW5k cmVkcyBvZiBtaWxsaW9ucyBvZiBob21lcyBhbmQgc21hbGwgb2ZmaWNlcyBhcm91bmQgdGhlIHdv cmxkLiBJIHF1aWNrbHkKPiBmb3VuZCB0aGF0IG9uZSBwZXJzb24gd2FzIG5vdCBnb2luZyB0byBt YWtlIG11Y2ggb2YgYSBkaWZmZXJlbmNlLCBhbmQgbm93Cj4gZmVlbCB0aGF0IGl0J3MgYW4gdXJn ZW50IHByaW9yaXR5IGZvciBJRVRGIHRvIHNob3cgc29tZSBsZWFkZXJzaGlwIGluIHRoaXMKPiBh cmVhLiBBbmQgYmVsaWV2ZSBtZSwgaWYgeW91IGRvbid0LCBub2JvZHkgZWxzZSB3aWxsIGFuZCB3 ZSdsbCBhbGwganVzdCBrZWVwCj4gb24gY29tcGxhaW5pbmcgYWJvdXQgdGhlIGZhY3QgYXQgRUNO IGxhbmd1aXNoZXMgZXZlbiB0aG91Z2ggaXQncyBiZWVuIGEKPiBkcmFmdCBzdGFuZGFyZCBzaW5j ZSAyMDAxIChSRkMgMzE2OCksIGFuZCBzaW1pbGFyIGZhdGUgd2lsbCBiZWZhbGwgRE5TU0VDLgo+ Cj4gVGhpcyBpcyBpbXBvcnRhbnQgd29yayBhbmQgaXQgZGVzZXJ2ZXMgc29tZSBzZXJpb3VzIGF0 dGVudGlvbi4KPgo+IFJpY2hhcmQgQmVubmV0dAo+Cj4gClAgR28gR3JlZW4hIFByaW50IHRoaXMg ZW1haWwgb25seSB3aGVuIG5lY2Vzc2FyeS4gVGhhbmsgeW91IGZvciBoZWxwaW5nIFRpbWUgV2Fy bmVyIENhYmxlIGJlIGVudmlyb25tZW50YWxseSByZXNwb25zaWJsZS4KIAogCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tCj4gRnJvbTogTXVyYXJpIFNyaWRoYXJhbiBbbWFpbHRvOm11cmFyaXNA bWljcm9zb2Z0LmNvbV0KPiBTZW50OiBGcmlkYXksIEp1bmUgMTIsIDIwMDkgMTI6MTcgQU0KPiBU bzogSGVuayBVaWp0ZXJ3YWFsOyBncmVudmlsbGUgYXJtaXRhZ2UKPiBDYzogaG9tZWdhdGVAaWV0 Zi5vcmc7IGlwZGlyQGlldGYub3JnOyBJQUIgSUFCOyBpZXNnQGlldGYub3JnIElFU0c7IFRTViBE aXI7Cj4gSmFzb24gTGl2aW5nb29kCj4gU3ViamVjdDogUmU6IFtob21lZ2F0ZV0gUERGIG9mIEJv RiBQcm9wb3NhbAo+Cj4gUERGIGRlZmluaXRlbHkgbG9va2VkIGludGVyZXN0aW5nLCBhIGJpdCB0 b28gYnJvYWQgYnV0IEkgYXNzdW1lZCBzY29waW5nCj4gZGlzY3Vzc2lvbnMgd291bGQgc3RhcnQg dG8gaGFwcGVuIG9uIHRoZSBtYWlsaW5nIGxpc3RzLgo+Cj4gTXVyYXJpCj4KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQo+IEZyb206IGhvbWVnYXRlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpob21lZ2F0ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYKPiBPZiBIZW5rIFVpanRlcndh YWwKPiBTZW50OiBUaHVyc2RheSwgSnVuZSAxMSwgMjAwOSAxMDo1NSBQTQo+IFRvOiBncmVudmls bGUgYXJtaXRhZ2UKPiBDYzogaG9tZWdhdGVAaWV0Zi5vcmc7IGlwZGlyQGlldGYub3JnOyBJQUIg SUFCOyBpZXNnQGlldGYub3JnIElFU0c7IFRTViBEaXI7Cj4gSmFzb24gTGl2aW5nb29kCj4gU3Vi amVjdDogUmU6IFtob21lZ2F0ZV0gUERGIG9mIEJvRiBQcm9wb3NhbAo+Cj4gZ3JlbnZpbGxlIGFy bWl0YWdlIHdyb3RlOgo+PiBMYXJzIEVnZ2VydCB3cm90ZToKPj4gICAgIFsuLl0KPj4+IFRoaXJk LCBpdCBpcyBjdXJyZW50bHkgbm90IGNsZWFyIGhvdyBzdWJzdGFudGlhbCB0aGUgY29tbXVuaXR5 IGlzIHRoYXQKPj4+IHdvdWxkIHBhcnRpY2lwYXRlIGluIGFuIElFVEYgZWZmb3J0IGluIHRoaXMg c3BhY2UuIFRyYWZmaWMgb24gdGhlCj4+PiBtYWlsaW5nIGxpc3QgaGFzIGJlZW4gYWJzZW50LCBh bmQgSSBoYXZlIGFsc28gcmVjZWl2ZWQgb25seSB2ZXJ5IGZldwo+Pj4gZGlyZWN0IGVtYWlscyBh Ym91dCBpdC4gVGhpcyBlZmZvcnQgbWF5IHJlcXVpcmUgbW9yZSBzb2NpYWxpemluZy4KPj4KPj4g SSB3b25kZXIgaG93IG1hbnkgcGVvcGxlIChsaWtlIG1lKSBzdWJzY3JpYmVkIHdoZW4gd2UgZmly c3Qgc2F3Cj4+IHRoZSBtYWlsaW5nIGxpc3QgYW5ub3VuY2VkIGxhc3Qgd2VlayBvbiBpZXRmQGll dGYub3JnLCBhbmQgaGF2ZSBzaW5jZQo+PiBiZWVuIHdhaXRpbmcgdG8gaGF2ZSBzb21lb25lIGtp Y2sgb2ZmIGRpc2N1c3Npb25zLgo+Cj4gSSBhZ3JlZSwgdGhlIFBERiBsb29rZWQgaW50ZXJlc3Rp bmcsIHNvIEkgcHV0IG15c2VsZiBvbiB0aGUgbGlzdCBhbmQKPiB3YWl0ZWQgZm9yIGEga2ljay1v ZmYuCj4KPiBIZW5rCj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCmhvbWVnYXRlIG1haWxpbmcgbGlzdApob21lZ2F0ZUBpZXRmLm9yZwpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2hvbWVnYXRlCgoKVGhpcyBFLW1haWwgYW5kIGFu eSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIKQ2FibGUgcHJvcHJp ZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwKb3Ig c3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlz IEUtbWFpbAppcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwg b3IgZW50aXR5IHRvIHdoaWNoCml0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzCkUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQg dGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwKZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24g dGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzCm9mIGFuZCBhdHRhY2htZW50cyB0byB0 aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUKdW5sYXdmdWwuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5CnRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwg YW5kIGFueQpjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuCg== From tme@americafree.tv Tue Jun 16 03:02: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 A71A73A6D58 for ; Tue, 16 Jun 2009 03:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.706 X-Spam-Level: X-Spam-Status: No, score=-2.706 tagged_above=-999 required=5 tests=[AWL=-0.107, 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 QrtswrSZNp+O for ; Tue, 16 Jun 2009 03:02:06 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id D99E73A6AF0 for ; Tue, 16 Jun 2009 03:02:05 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id BC9EF406DD79; Tue, 16 Jun 2009 06:01:53 -0400 (EDT) Message-Id: From: Marshall Eubanks To: "Livingood, Jason" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 06:01:52 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: "homegate@ietf.org" Subject: Re: [homegate] PDF of BoF Proposal 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, 16 Jun 2009 10:02:06 -0000 On Jun 15, 2009, at 5:38 PM, Livingood, Jason wrote: > I'm not sure that end users are the target audience. Instead, IMHO, > I think > it is equipment vendors and large buyers (ISPs, mega retailers, etc.). > +1. The end users, by and large, do not and will not know that the IETF exists. Regards Marshall > Jason > > > On 6/12/09 1:32 PM, "Damian Gerow" wrote: > >> As the target consumers of this effort would be the end user, I >> think a set of >> BCPs falls just short of the mark. There needs to be some way for >> John Q. >> Public to pick up a box, look at a logo or phrase, and understand >> exactly >> what that product gives him. i.e. 'Gateway Certified' would meet >> all stated >> requirements for acting as your standard home gateway. 'Media >> Certified' > > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate > From tme@americafree.tv Tue Jun 16 03:28:09 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 A63733A6D52 for ; Tue, 16 Jun 2009 03:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.703 X-Spam-Level: X-Spam-Status: No, score=-2.703 tagged_above=-999 required=5 tests=[AWL=-0.104, 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 u53HMHASIFlf for ; Tue, 16 Jun 2009 03:28:01 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id BB1C83A692D for ; Tue, 16 Jun 2009 03:27:59 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 65AF1406E86F; Tue, 16 Jun 2009 06:27:53 -0400 (EDT) Message-Id: From: Marshall Eubanks To: homegate@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 06:27:52 -0400 X-Mailer: Apple Mail (2.935.3) Cc: Greg Shepherd , Leonard Giuliano Subject: [homegate] Homegate and Multicast 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, 16 Jun 2009 10:28:09 -0000 I have been wading through all of this, and was surprised to see no mention of multicast in A blow to the first round of multicast deployments (almost a decade ago now!) was the inability of most of the then current home routers to support things such as IGMP proxying. If the IETF is going to specify a new effort to specify home gateways, then in my opinion this specification should support at least SSM multicast reception properly. Supporting multicast in the home environment is becoming common in video deployments, but the end user typically does not see this on their home network and there is very little multicast support to the end user (instead of just to their set top boxes). However, the trend in the industry is towards merging the reception of Internet-transported video and provider-transported video into common hardware platforms. Internet video would certainly benefit from support of multicast reception, and there seems to be a recognition of that in the industry. The CableLabs document "IPv4 and IPv6 eRouter Specification" http://www.cablelabs.com/specifications/CM-SP-eRouter-I03-070518.pdf states as their goal : The specification defines a) CPE provisioning with IPv4 and IPv6 addresses, b) IPv4 data forwarding with NAPT and IPv6 data forwarding, c) Ability to forward IP Multicast traffic and d) Preserving IP QoS markings on IP data to and from the CPE devices. and includes sections on IGMP proxing as well as v4 and v6 multicast support. The other two documents mentioned as parallel efforts : Broadband Forum TR-124 defines a set of modular functional requirements for broadband residential gateways:http://www.broadband-forum.org/technical/download/TR-124.pdf . The Home Gateway Initiative also has a Home Gateway Requirements: Residential Profile document:http://www.homegatewayinitiative.org/publis/HGI_V1.01_Residential.pdf . also include multicast support. So, while I support this effort, I would like to see multicast SSM added to Theme 1. Regards Marshall P.S. Can I also suggest that what is basically a text file BOF charter should be served as a text file in the usual fashion ? From lars.eggert@nokia.com Tue Jun 16 04:04:16 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 5E4E13A6AA7 for ; Tue, 16 Jun 2009 04:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 l8978BJjOcen for ; Tue, 16 Jun 2009 04:04:15 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 560513A69C5 for ; Tue, 16 Jun 2009 04:04:15 -0700 (PDT) Received: from pc-g103.wlan.inet.fi (pc-g103.wlan.inet.fi [62.71.98.103]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n5GB2mRO026619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Jun 2009 14:02:49 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <80E70011-64A7-4C09-8810-0026ECE0C405@nokia.com> From: Lars Eggert To: Marshall Eubanks In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-25-554991370; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 14:02:43 +0300 References: X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Tue, 16 Jun 2009 14:02:49 +0300 (EEST) Cc: Greg Shepherd , "homegate@ietf.org" , Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 11:04:16 -0000 --Apple-Mail-25-554991370 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2009-6-16, at 13:27, Marshall Eubanks wrote: > P.S. Can I also suggest that what is basically a text file BOF charter > should be served as a text file in the usual fashion ? Feel free to also use the TSV area wiki: http://trac.tools.ietf.org/area/tsv/trac/wiki I've created an empty page for you at http://trac.tools.ietf.org/area/tsv/trac/wiki/HOMEGATE Lars --Apple-Mail-25-554991370 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA2MTYxMTAyNDRaMCMGCSqGSIb3DQEJBDEWBBSQrCdEc6Hbg93m I/O7HGIsblo+XDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAfwojf/6vTEwdeWAeQ9QTeDjK/qFyU2yZPL/6DstI779I1VICOM3j KgjufYHnaZeUEnOszCYlePHvA2Mhl9tLVhFKyC3mOLQQL/ZCB58xYWpZ6dBVLACQMZfaRYp61rl0 3zk/fBVhtuL7HV7VXx7IffUcguytSwp7tcM1p92FexAiB5lRnozarjzgxdkGIQYIhVdVUnCbVVc6 GWYBKLLjp0uSqRfNar6QtF0fkiVgX+EUt04wncY2H+oP5wRMRsnTJ+k2lgDHXwRKMdAU7LHhoIJd Y8dqeHCDXI73bkwRjijE4U8OLvBXkGcNYCnWogMnl7+3nNSSePE+O+yUfBzPyQAAAAAAAA== --Apple-Mail-25-554991370-- From wbeebee@cisco.com Tue Jun 16 06:30: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 305723A6AEC for ; Tue, 16 Jun 2009 06:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 MuGIjjgvMsPT for ; Tue, 16 Jun 2009 06:30:03 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3C0A53A6945 for ; Tue, 16 Jun 2009 06:30:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,228,1243814400"; d="scan'208";a="81097836" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 16 Jun 2009 13:29:43 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5GDTheD031082; Tue, 16 Jun 2009 06:29:43 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5GDTckK006015; Tue, 16 Jun 2009 13:29:42 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 09:29:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 09:29:38 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] PDF of BoF Proposal Thread-Index: AcntvY3IJI7GRqqKRyS0ATiRYbfBbgAOUxbgABIoduAAEP5gIA== References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com><4A3182AE.9040508@swin.edu.au><4A31FCB3.7080607@unifr.ch><20090612133220.70c3094c.dgerow@afflictions.org><20090615133048.GA38531@shinkuro.com> From: "Wes Beebee (wbeebee)" To: "Richard Bennett" , "Heather Kirksey" , X-OriginalArrivalTime: 16 Jun 2009 13:29:39.0386 (UTC) FILETIME=[7FCBC9A0:01C9EE86] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5370; t=1245158983; x=1246022983; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20[homegate]=20PDF=20of=20BoF=20Proposal |Sender:=20; bh=DS2Q/GdtEW9af2f8pCN5x7LIvmYOz9rpqm+KoyQQnXw=; b=AZMWswqXj077Ou6M1N/6/3XE2atzEGCj1FZAC8SboSvhx2Djg122N+qa2a sA8rPG6JyuhJcr+szSKEX9oMXNZaqJYettfubx1TNmJr3PEZ8VYAoK0D9aVf rMfXrtR7O3; Authentication-Results: sj-dkim-4; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [homegate] PDF of BoF Proposal 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, 16 Jun 2009 13:30:05 -0000 CableLabs also has the eRouter specification, which was published at: http://www.cablelabs.com/specifications/CM-SP-eRouter-I03-070518.pdf All of these specifications make a large number of very specific = mandatory requirements (lots of MUSTs) and were developed very quickly = by a small number of people without any external review for a very = limited and specific set of deployment patterns. They are built with = compliance in mind, and have organizations that have a history of = testing products "to the spec". They tend to have very little, if any, = written justification for the requirements and don't have enough = tutorial background material for developers to be able to make wise = implementation choices or for those new to the area to understand where = the protocols come from. They have noticable, glaring holes and flaws = that are no doubt a result of the time pressure and limited review. What the IETF can do in this space is specifically not go the same route = as these specifications and compete with them. We can provide the = missing background material in a simple, easy-to-understand, tutorial = way. We can fill in the holes and correct the flaws. We can avoid = being tied to any particular deployment pattern so as to remain relevant = to all of them. We can use the time we have and the broad review = capabilities of the IETF to "get it right". We can use MUST only when = we have a good explanation for why it has to be there - and provide the = explanation in the document(s). - Wes -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On = Behalf Of Richard Bennett Sent: Tuesday, June 16, 2009 1:05 AM To: 'Heather Kirksey'; homegate@ietf.org Subject: Re: [homegate] PDF of BoF Proposal These two documents are very informative regarding the state of the art = regarding Internet protocol knowledge among gateway vendors, and I = recommend reading them. What you'll likely find most interesting is not = what they say as what they don't; there are enormous holes in both of = them. Search for "ECN" and you'll get no hits, for example.=20 >From my experience, Broadband Forum has an international membership with = a North American bias, while HGI has a more European membership, FWIW.=20 Richard Bennett -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On = Behalf Of Heather Kirksey Sent: Monday, June 15, 2009 1:58 PM To: homegate@ietf.org Subject: Re: [homegate] PDF of BoF Proposal Andrew, If you're considering ISPs using this work to enforce requirements on = their vendors, it might be worth checking out some work that's already = gone on in this area: Broadband Forum TR-124 defines a set of modular functional requirements = for broadband residential gateways: http://www.broadband-forum.org/technical/download/TR-124.pdf. The Home Gateway Initiative also has a Home Gateway Requirements: Residential Profile document: http://www.homegatewayinitiative.org/publis/HGI_V1.01_Residential.pdf. In addition, Broadband Forum has a work-in-progress document called = PD-192 that deals with the functional IPv6 requirements for gateways in = the home based on current operator plans for migration and deployment. = BBF was already planning to liaise the PD-192 document in the relatively = near future to get feedback on it. Thanks, Heather Heather Kirksey Motive Product Division Alcatel-Lucent hkirksey@motive.com +1.512.531.1126 (office) +1.512.917.7938 (mobile) =A0 -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On = Behalf Of Andrew Sullivan Sent: Monday, June 15, 2009 8:31 AM To: homegate@ietf.org Subject: Re: [homegate] PDF of BoF Proposal On Sat, Jun 13, 2009 at 08:40:42AM +0200, Lars Eggert wrote: > it's not clear that the consumer of this effort would be the end user=20 > - few IETF specifications are. In my mind, this was mostly about=20 > giving guidelines to vendors and operators. > The IETF isn't doing standards certification, and there are good=20 > reasons [[HRK]]=20 > for that. But nothing stops an outside entity to run a conformance=20 > test program based on IETF specs, and I agree that for the end users,=20 > some sort of easily identified distinguisher on the box would be = helpful. In my view, the above should be a key factor in our thinking. IETF = standards get "enforced" by contracts. Large numbers of these gateway = devices are sold or otherwise provided to end users by ISPs. So if ISPs = have something to which they can require vendors to conform as part of = the ISPs' purchase of the devices or recommendation of them to end = customers, that will probably be enough market pressure to achieve the = desired result. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. _______________________________________________ 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 _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate From kirk.erichsen@twcable.com Tue Jun 16 07: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 DB2613A6922 for ; Tue, 16 Jun 2009 07:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.446 X-Spam-Level: X-Spam-Status: No, score=-0.446 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 B2Q25cq-R4Xw for ; Tue, 16 Jun 2009 07:09:05 -0700 (PDT) Received: from pblpas01.twcable.com (pblpas01.twcable.com [204.235.121.149]) by core3.amsl.com (Postfix) with ESMTP id 725CF3A68A0 for ; Tue, 16 Jun 2009 07:09:05 -0700 (PDT) X-SENDER-IP: 10.157.247.212 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,228,1243828800"; d="scan'208";a="423592951" Received: from unknown (HELO prvpmailconn2.corp.twcable.com) ([10.157.247.212]) by pblpas01.twcable.com with ESMTP; 16 Jun 2009 10:07:08 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn2.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 10:07:08 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Jun 2009 10:02:25 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Homegate and Multicast thread-index: AcnubS8ZOLUW9CjfRtu4HzJmNN3EZwAHeSvo References: From: "Erichsen, Kirk" To: "Marshall Eubanks" , X-OriginalArrivalTime: 16 Jun 2009 14:07:08.0339 (UTC) FILETIME=[BC46C830:01C9EE8B] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: Greg Shepherd , Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 14:09:06 -0000 U3BlYWtpbmcgZnJvbSBleHBlcmllbmNlIHdpdGggcmVnYXJkcyB0byBlUm91dGVyLCB3aGlsZSB3 ZSBoYWQgInNvbWUiIHVzZSBjYXNlcyB0byBpbmNvcnBvcmF0ZSBTU00gbXVsdGljYXN0IGludG8g ZVJvdXRlcnYxLjAsIHdlIGRpZG4ndCBoYXZlIHRoZSB1c2UgY2FzZXMgdGhhdCBoYXZlIGVtZXJn ZWQgbW9yZSByZWNlbnRseS4gSSdkIGFncmVlIHRoYXQgd2UgbmVlZCB0byBkZWZpbmUgbXVsdGlj YXN0IG1lY2hhbmlzbXMgKElHTVAgYW5kIE1MRCkgYW5kIGNvdWxkIHJlZmVyZW5jZSBleGlzdGlu ZyBzcGVjaWZpY2F0aW9ucyBmb3IgdGhpcyBlZmZvcnQsIGJ1dCB3ZSdsbCBuZWVkIHRvIHRoaW5r IGZpcnN0IG9uIHRoZSBhZm9yZW1lbnRpb25lZCB1c2UgY2FzZXMgbG9uZyBhbmQgaGFyZC4gV2hp bGUgSVAgdmlkZW8gY29udGVudCBkZWxpdmVyeSBpcyBhbiBlbWVyZ2luZyB0ZWNobm9sb2d5IHdp dGggbWFueSBhZHZvY2F0ZXMgYW5kIGludGVyZXN0ZWQgcGFydGllcywgaXQgY2FuIGJlIGRpZmZp Y3VsdCB0byBzb3J0IHRocm91Z2ggd2hpY2ggdXNlIGNhc2VzIGFyZSByZWFsaXN0aWMgYW5kIHdo aWNoIGFyZSBvbmx5IGV4ZXJjaXNlcyBpbiB0aGVvcnkuCiAKLUtFIAoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KCkZyb206IGhvbWVnYXRlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo YWxmIG9mIE1hcnNoYWxsIEV1YmFua3MKU2VudDogVHVlIDYvMTYvMjAwOSA0OjI3IEFNClRvOiBo b21lZ2F0ZUBpZXRmLm9yZwpDYzogR3JlZyBTaGVwaGVyZDsgTGVvbmFyZCBHaXVsaWFubwpTdWJq ZWN0OiBbaG9tZWdhdGVdIEhvbWVnYXRlIGFuZCBNdWx0aWNhc3QKCgoKSSBoYXZlIGJlZW4gd2Fk aW5nIHRocm91Z2ggYWxsIG9mIHRoaXMsIGFuZCB3YXMgc3VycHJpc2VkIHRvIHNlZSBubyAKbWVu dGlvbgpvZiBtdWx0aWNhc3QgaW4KCjxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ib2YvdHJh Yy9yYXctYXR0YWNobWVudC93aWtpL1dpa2lTdGFydC9Ib21lR2F0ZSUyMEJvRiUyMFByb3Bvc2Fs JTIwLSUyMElFVEYlMjA3NSUyMC0lMjB2Ny5wZGYgCiA+CgpBIGJsb3cgdG8gdGhlIGZpcnN0IHJv dW5kIG9mIG11bHRpY2FzdCBkZXBsb3ltZW50cyAoYWxtb3N0IGEgZGVjYWRlIAphZ28gbm93ISkg d2FzIHRoZSBpbmFiaWxpdHkgb2YKbW9zdCBvZiB0aGUgdGhlbiBjdXJyZW50IGhvbWUgcm91dGVy cyB0byBzdXBwb3J0IHRoaW5ncyBzdWNoIGFzIElHTVAgCnByb3h5aW5nLiBJZiB0aGUgSUVURiBp cyBnb2luZyB0byBzcGVjaWZ5IGEKbmV3IGVmZm9ydCB0byBzcGVjaWZ5IGhvbWUgZ2F0ZXdheXMs IHRoZW4gaW4gbXkgb3BpbmlvbiB0aGlzIApzcGVjaWZpY2F0aW9uIHNob3VsZCBzdXBwb3J0IGF0 IGxlYXN0IFNTTSBtdWx0aWNhc3QgcmVjZXB0aW9uIHByb3Blcmx5LgoKU3VwcG9ydGluZyBtdWx0 aWNhc3QgaW4gdGhlIGhvbWUgZW52aXJvbm1lbnQgaXMgYmVjb21pbmcgY29tbW9uIGluIAp2aWRl byBkZXBsb3ltZW50cywgYnV0IHRoZSBlbmQgdXNlciB0eXBpY2FsbHkKZG9lcyBub3Qgc2VlIHRo aXMgb24gdGhlaXIgaG9tZSBuZXR3b3JrIGFuZCB0aGVyZSBpcyB2ZXJ5IGxpdHRsZSAKbXVsdGlj YXN0IHN1cHBvcnQgdG8gdGhlIGVuZCB1c2VyIChpbnN0ZWFkIG9mIGp1c3QgdG8gdGhlaXIgc2V0 IHRvcCAKYm94ZXMpLiBIb3dldmVyLAp0aGUgdHJlbmQgaW4gdGhlIGluZHVzdHJ5IGlzIHRvd2Fy ZHMgbWVyZ2luZyB0aGUgcmVjZXB0aW9uIG9mCkludGVybmV0LXRyYW5zcG9ydGVkIHZpZGVvIGFu ZCBwcm92aWRlci10cmFuc3BvcnRlZCB2aWRlbyBpbnRvIGNvbW1vbiAKaGFyZHdhcmUgcGxhdGZv cm1zLiBJbnRlcm5ldCB2aWRlbwp3b3VsZCBjZXJ0YWlubHkgYmVuZWZpdCBmcm9tIHN1cHBvcnQg b2YgbXVsdGljYXN0IHJlY2VwdGlvbiwgYW5kIHRoZXJlIApzZWVtcyB0byBiZSBhIHJlY29nbml0 aW9uIG9mIHRoYXQgaW4gdGhlIGluZHVzdHJ5LiBUaGUgQ2FibGVMYWJzIApkb2N1bWVudCAiSVB2 NCBhbmQgSVB2NiBlUm91dGVyIFNwZWNpZmljYXRpb24iCmh0dHA6Ly93d3cuY2FibGVsYWJzLmNv bS9zcGVjaWZpY2F0aW9ucy9DTS1TUC1lUm91dGVyLUkwMy0wNzA1MTgucGRmCgpzdGF0ZXMgYXMg dGhlaXIgZ29hbCA6CgpUaGUgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEpIENQRSBwcm92aXNpb25p bmcgd2l0aCBJUHY0IGFuZCBJUHY2IAphZGRyZXNzZXMsIGIpIElQdjQgZGF0YSBmb3J3YXJkaW5n IHdpdGggTkFQVAphbmQgSVB2NiBkYXRhIGZvcndhcmRpbmcsIGMpIEFiaWxpdHkgdG8gZm9yd2Fy ZCBJUCBNdWx0aWNhc3QgdHJhZmZpYyAKYW5kIGQpIFByZXNlcnZpbmcgSVAgUW9TIG1hcmtpbmdz IG9uIElQIGRhdGEKdG8gYW5kIGZyb20gdGhlIENQRSBkZXZpY2VzLgoKYW5kIGluY2x1ZGVzIHNl Y3Rpb25zIG9uIElHTVAgcHJveGluZyBhcyB3ZWxsIGFzIHY0IGFuZCB2NiBtdWx0aWNhc3QgCnN1 cHBvcnQuIFRoZSBvdGhlciB0d28gZG9jdW1lbnRzIG1lbnRpb25lZCBhcwpwYXJhbGxlbCBlZmZv cnRzIDoKCkJyb2FkYmFuZCBGb3J1bSBUUi0xMjQgZGVmaW5lcyBhIHNldCBvZiBtb2R1bGFyIGZ1 bmN0aW9uYWwgCnJlcXVpcmVtZW50cyBmb3IgYnJvYWRiYW5kIHJlc2lkZW50aWFsIGdhdGV3YXlz Omh0dHA6Ly93d3cuYnJvYWRiYW5kLWZvcnVtLm9yZy90ZWNobmljYWwvZG93bmxvYWQvVFItMTI0 LnBkZgouCgpUaGUgSG9tZSBHYXRld2F5IEluaXRpYXRpdmUgYWxzbyBoYXMgYSBIb21lIEdhdGV3 YXkgUmVxdWlyZW1lbnRzOiAKUmVzaWRlbnRpYWwgUHJvZmlsZSBkb2N1bWVudDpodHRwOi8vd3d3 LmhvbWVnYXRld2F5aW5pdGlhdGl2ZS5vcmcvcHVibGlzL0hHSV9WMS4wMV9SZXNpZGVudGlhbC5w ZGYKLgoKYWxzbyBpbmNsdWRlIG11bHRpY2FzdCBzdXBwb3J0LgoKU28sIHdoaWxlIEkgc3VwcG9y dCB0aGlzIGVmZm9ydCwgSSB3b3VsZCBsaWtlIHRvIHNlZSBtdWx0aWNhc3QgU1NNIAphZGRlZCB0 byBUaGVtZSAxLgoKUmVnYXJkcwpNYXJzaGFsbAoKUC5TLiBDYW4gSSBhbHNvIHN1Z2dlc3QgdGhh dCB3aGF0IGlzIGJhc2ljYWxseSBhIHRleHQgZmlsZSBCT0YgY2hhcnRlciAKc2hvdWxkIGJlIHNl cnZlZCBhcyBhIHRleHQgZmlsZSBpbiB0aGUgdXN1YWwKZmFzaGlvbiA/CgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpob21lZ2F0ZSBtYWlsaW5nIGxpc3QK aG9tZWdhdGVAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9o b21lZ2F0ZQoKCgpQIEdvIEdyZWVuISBQcmludCB0aGlzIGVtYWlsIG9ubHkgd2hlbiBuZWNlc3Nh cnkuIFRoYW5rIHlvdSBmb3IgaGVscGluZyBUaW1lIFdhcm5lciBDYWJsZSBiZSBlbnZpcm9ubWVu dGFsbHkgcmVzcG9uc2libGUuCiAKIApUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lcgpDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlv biwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLApvciBzdWJqZWN0IHRvIGNvcHly aWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsCmlzIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hp Y2gKaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 IG9mIHRoaXMKRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1p bmF0aW9uLApkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlv biB0byB0aGUgY29udGVudHMKb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZQp1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkKdGhlIHNlbmRlciBpbW1lZGlh dGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55CmNvcHkgb2Yg dGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4K From iljitsch@muada.com Tue Jun 16 07:14:52 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 9D3BF3A6B73 for ; Tue, 16 Jun 2009 07:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 PlM4sOc9rAAc for ; Tue, 16 Jun 2009 07:14:51 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 61A1E3A69C4 for ; Tue, 16 Jun 2009 07:14:51 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.219]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n5GECVGU085057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Jun 2009 16:12:31 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: "Erichsen, Kirk" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 16:11:59 +0200 References: X-Mailer: Apple Mail (2.935.3) Cc: homegate@ietf.org, Greg Shepherd , Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 14:14:52 -0000 On 16 jun 2009, at 16:02, Erichsen, Kirk wrote: > While IP video content delivery is an emerging technology with many > advocates and interested parties, it can be difficult to sort > through which use cases are realistic and which are only exercises > in theory. Speaking of that: multicast streaming doesn't work over wifi. A lot of home gateways talk to the local hosts over wifi. How do we solve this? From shemant@cisco.com Tue Jun 16 07:16: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 EBB613A6B73 for ; Tue, 16 Jun 2009 07:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 5Lsci+kazpwC for ; Tue, 16 Jun 2009 07:16:04 -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 98A473A6915 for ; Tue, 16 Jun 2009 07:16:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,228,1243814400"; d="scan'208";a="200740581" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 16 Jun 2009 14:15:04 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5GEF5kX004959; Tue, 16 Jun 2009 07:15:05 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n5GEF4Jo007608; Tue, 16 Jun 2009 14:15:04 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 10:15:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 10:15:02 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Homegate and Multicast Thread-Index: AcnubS8ZOLUW9CjfRtu4HzJmNN3EZwAHeSvoAABcGQA= References: From: "Hemant Singh (shemant)" To: "Erichsen, Kirk" , "Marshall Eubanks" , X-OriginalArrivalTime: 16 Jun 2009 14:15:04.0106 (UTC) FILETIME=[D7DB10A0:01C9EE8C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4958; t=1245161705; x=1246025705; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20[homegate]=20Homegate=20and=20Multicast |Sender:=20; bh=Nzx1WQksv1xrrvxO8kWRyczJlZnysuyVBGXno4pGK9k=; b=QuVVQHEEDH5fPpVJ5mmgn6z4CjwmsW8bN+ibmUY18EPZbVg4Up7GFXleXP a7YkXIS/EFbApBrporCCpNJ2bbFMkcf4Q4BC5dNPXlvaLa1xpPGt9cVNYNNK LKSPtbUpMc; Authentication-Results: sj-dkim-4; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Greg Shepherd , Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 14:16:06 -0000 If one is discussing IPv6 mcast, see section 7.2 for mcast specification in the IETF v6ops IPv6 CPE Router document at the URL below. Sorry, I didn't get time yet to catch up with all the emails yet. http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-cpe-router-00. txt Hemant -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behalf Of Erichsen, Kirk Sent: Tuesday, June 16, 2009 10:02 AM To: Marshall Eubanks; homegate@ietf.org Cc: Greg Shepherd; Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast Speaking from experience with regards to eRouter, while we had "some" use cases to incorporate SSM multicast into eRouterv1.0, we didn't have the use cases that have emerged more recently. I'd agree that we need to define multicast mechanisms (IGMP and MLD) and could reference existing specifications for this effort, but we'll need to think first on the aforementioned use cases long and hard. While IP video content delivery is an emerging technology with many advocates and interested parties, it can be difficult to sort through which use cases are realistic and which are only exercises in theory. =20 -KE=20 ________________________________ From: homegate-bounces@ietf.org on behalf of Marshall Eubanks Sent: Tue 6/16/2009 4:27 AM To: homegate@ietf.org Cc: Greg Shepherd; Leonard Giuliano Subject: [homegate] Homegate and Multicast I have been wading through all of this, and was surprised to see no=20 mention of multicast in A blow to the first round of multicast deployments (almost a decade=20 ago now!) was the inability of most of the then current home routers to support things such as IGMP=20 proxying. If the IETF is going to specify a new effort to specify home gateways, then in my opinion this=20 specification should support at least SSM multicast reception properly. Supporting multicast in the home environment is becoming common in=20 video deployments, but the end user typically does not see this on their home network and there is very little=20 multicast support to the end user (instead of just to their set top=20 boxes). However, the trend in the industry is towards merging the reception of Internet-transported video and provider-transported video into common=20 hardware platforms. Internet video would certainly benefit from support of multicast reception, and there=20 seems to be a recognition of that in the industry. The CableLabs=20 document "IPv4 and IPv6 eRouter Specification" http://www.cablelabs.com/specifications/CM-SP-eRouter-I03-070518.pdf states as their goal : The specification defines a) CPE provisioning with IPv4 and IPv6=20 addresses, b) IPv4 data forwarding with NAPT and IPv6 data forwarding, c) Ability to forward IP Multicast traffic=20 and d) Preserving IP QoS markings on IP data to and from the CPE devices. and includes sections on IGMP proxing as well as v4 and v6 multicast=20 support. The other two documents mentioned as parallel efforts : Broadband Forum TR-124 defines a set of modular functional=20 requirements for broadband residential gateways:http://www.broadband-forum.org/technical/download/TR-124.pdf . The Home Gateway Initiative also has a Home Gateway Requirements:=20 Residential Profile document:http://www.homegatewayinitiative.org/publis/HGI_V1.01_Residenti al.pdf . also include multicast support. So, while I support this effort, I would like to see multicast SSM=20 added to Theme 1. Regards Marshall P.S. Can I also suggest that what is basically a text file BOF charter=20 should be served as a text file in the usual fashion ? _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible. =20 =20 This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate From tme@americafree.tv Tue Jun 16 07:29: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 BCA7D3A6D7A for ; Tue, 16 Jun 2009 07:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[AWL=-0.098, 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 r8k7bpAWzrcp for ; Tue, 16 Jun 2009 07:29:50 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 03D073A6BA4 for ; Tue, 16 Jun 2009 07:29:50 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 96B6B40729F4; Tue, 16 Jun 2009 10:20:53 -0400 (EDT) Message-Id: <59227417-B06C-46FF-9AAC-D4990EF2AC6D@americafree.tv> From: Marshall Eubanks To: Lars Eggert In-Reply-To: <80E70011-64A7-4C09-8810-0026ECE0C405@nokia.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 10:20:53 -0400 References: <80E70011-64A7-4C09-8810-0026ECE0C405@nokia.com> X-Mailer: Apple Mail (2.935.3) Cc: Greg Shepherd , "homegate@ietf.org" , Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 14:29:50 -0000 On Jun 16, 2009, at 7:02 AM, Lars Eggert wrote: > On 2009-6-16, at 13:27, Marshall Eubanks wrote: >> P.S. Can I also suggest that what is basically a text file BOF >> charter >> should be served as a text file in the usual fashion ? > > Feel free to also use the TSV area wiki: http://trac.tools.ietf.org/area/tsv/trac/wiki > > I've created an empty page for you at http://trac.tools.ietf.org/area/tsv/trac/wiki/HOMEGATE > That's fine, but what I was really suggesting was that charter revisions should be sent to the list as text. Regards Marshall > Lars From tme@americafree.tv Tue Jun 16 07:29:51 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 C750228C183 for ; Tue, 16 Jun 2009 07:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=-0.096, 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 5QmxCs5PwA09 for ; Tue, 16 Jun 2009 07:29:50 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 3F0B13A6D67 for ; Tue, 16 Jun 2009 07:29:50 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id B8E6A407287E; Tue, 16 Jun 2009 10:17:34 -0400 (EDT) Message-Id: From: Marshall Eubanks To: "Erichsen, Kirk" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 10:17:33 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: Greg Shepherd , homegate@ietf.org, Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 14:29:51 -0000 On Jun 16, 2009, at 10:02 AM, Erichsen, Kirk wrote: > Speaking from experience with regards to eRouter, while we had > "some" use cases to incorporate SSM multicast into eRouterv1.0, we > didn't have the use cases that have emerged more recently. I'd agree > that we need to define multicast mechanisms (IGMP and MLD) and could > reference existing specifications for this effort, but we'll need to > think first on the aforementioned use cases long and hard. While IP > video content delivery is an emerging technology with many advocates > and interested parties, it can be difficult to sort through which > use cases are realistic and which are only exercises in theory. > I fully agree. Note that many home uses have a 802.11 WLAN on the "home" side of the gateway, and many home 802.11 access points do not do multicast well, or at all. Of course, if the gateway hardware does not support it, all use cases are likely to remain academic. Regards Marshall > -KE > > ________________________________ > > From: homegate-bounces@ietf.org on behalf of Marshall Eubanks > Sent: Tue 6/16/2009 4:27 AM > To: homegate@ietf.org > Cc: Greg Shepherd; Leonard Giuliano > Subject: [homegate] Homegate and Multicast > > > > I have been wading through all of this, and was surprised to see no > mention > of multicast in > > > > > A blow to the first round of multicast deployments (almost a decade > ago now!) was the inability of > most of the then current home routers to support things such as IGMP > proxying. If the IETF is going to specify a > new effort to specify home gateways, then in my opinion this > specification should support at least SSM multicast reception > properly. > > Supporting multicast in the home environment is becoming common in > video deployments, but the end user typically > does not see this on their home network and there is very little > multicast support to the end user (instead of just to their set top > boxes). However, > the trend in the industry is towards merging the reception of > Internet-transported video and provider-transported video into common > hardware platforms. Internet video > would certainly benefit from support of multicast reception, and there > seems to be a recognition of that in the industry. The CableLabs > document "IPv4 and IPv6 eRouter Specification" > http://www.cablelabs.com/specifications/CM-SP-eRouter-I03-070518.pdf > > states as their goal : > > The specification defines a) CPE provisioning with IPv4 and IPv6 > addresses, b) IPv4 data forwarding with NAPT > and IPv6 data forwarding, c) Ability to forward IP Multicast traffic > and d) Preserving IP QoS markings on IP data > to and from the CPE devices. > > and includes sections on IGMP proxing as well as v4 and v6 multicast > support. The other two documents mentioned as > parallel efforts : > > Broadband Forum TR-124 defines a set of modular functional > requirements for broadband residential gateways:http://www.broadband-forum.org/technical/download/TR-124.pdf > . > > The Home Gateway Initiative also has a Home Gateway Requirements: > Residential Profile document:http://www.homegatewayinitiative.org/publis/HGI_V1.01_Residential.pdf > . > > also include multicast support. > > So, while I support this effort, I would like to see multicast SSM > added to Theme 1. > > Regards > Marshall > > P.S. Can I also suggest that what is basically a text file BOF charter > should be served as a text file in the usual > fashion ? > > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate > > > > P Go Green! Print this email only when necessary. Thank you for > helping Time Warner Cable be environmentally responsible. > > > This E-mail and any of its attachments may contain Time Warner > Cable proprietary information, which is privileged, confidential, > or subject to copyright belonging to Time Warner Cable. This E-mail > is intended solely for the use of the individual or entity to which > it is addressed. If you are not the intended recipient of this > E-mail, you are hereby notified that any dissemination, > distribution, copying, or action taken in relation to the contents > of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. From tme@americafree.tv Tue Jun 16 07:35:07 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 A16AB3A69A9 for ; Tue, 16 Jun 2009 07:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=-0.093, 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 A+hTDUJ6t+D5 for ; Tue, 16 Jun 2009 07:35:06 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id B31843A6D74 for ; Tue, 16 Jun 2009 07:35:06 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 93BB14072FA1; Tue, 16 Jun 2009 10:34:38 -0400 (EDT) Message-Id: <7E6E35CE-AB91-400D-BD22-4BD6E1BD6986@americafree.tv> From: Marshall Eubanks To: Iljitsch van Beijnum In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 10:34:37 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: Greg Shepherd , homegate@ietf.org, Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 14:35:07 -0000 On Jun 16, 2009, at 10:11 AM, Iljitsch van Beijnum wrote: > On 16 jun 2009, at 16:02, Erichsen, Kirk wrote: > >> While IP video content delivery is an emerging technology with many >> advocates and interested parties, it can be difficult to sort >> through which use cases are realistic and which are only exercises >> in theory. > > Speaking of that: multicast streaming doesn't work over wifi. A lot > of home gateways talk to the local hosts over wifi. How do we solve > this? Multicast does work over 802.11. The trouble is that many access points don't do IGMP/MLD, so any multicast present on the wireline side of the LAN is flooded to the wireless. In an enterprise environment (with a faster LAN than WLAN, and potentially lots of multicast users), this has the risk to totally flood the 802 WLAN with unintended traffic. As a result, a lot of access points limit or block multicast by default. It is not clear to me that that is as much of an issue in a home environment (where the WLAN is much faster than the link to the outside, and it is unlikely that there is also a wireline LAN with a lot of multicast traffic on it). Saying that the Gateway should run IGMP/MLD might be enough to resolve this. Regards Marshall > > From kirk.erichsen@twcable.com Tue Jun 16 07:36: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 BB6283A6B78 for ; Tue, 16 Jun 2009 07:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.447 X-Spam-Level: X-Spam-Status: No, score=-0.447 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 Sjt9qLhqUtHP for ; Tue, 16 Jun 2009 07:36:49 -0700 (PDT) Received: from pblpas02.twcable.com (pblpas02.twcable.com [204.235.121.150]) by core3.amsl.com (Postfix) with ESMTP id 344AA3A69A9 for ; Tue, 16 Jun 2009 07:36:49 -0700 (PDT) X-SENDER-IP: 10.157.247.213 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,229,1243828800"; d="scan'208";a="422732196" Received: from unknown (HELO prvpmailconn3.corp.twcable.com) ([10.157.247.213]) by pblpas02.twcable.com with ESMTP; 16 Jun 2009 10:33:41 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 10:33:41 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Jun 2009 10:29:11 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] PDF of BoF Proposal thread-index: AcntvY3IJI7GRqqKRyS0ATiRYbfBbgAOUxbgABIoduAAEP5gIAAC1tt9 References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com><4A3182AE.9040508@swin.edu.au><4A31FCB3.7080607@unifr.ch><20090612133220.70c3094c.dgerow@afflictions.org><20090615133048.GA38531@shinkuro.com> From: "Erichsen, Kirk" To: "Wes Beebee \(wbeebee\)" , "Richard Bennett" , "Heather Kirksey" , X-OriginalArrivalTime: 16 Jun 2009 14:33:41.0264 (UTC) FILETIME=[71BBD900:01C9EE8F] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: Re: [homegate] PDF of BoF Proposal 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, 16 Jun 2009 14:36:50 -0000 QWxsIHRydWUgd2l0aCByZWdhcmRzIHRvIGVSb3V0ZXIuIEl0J3MgZm9yIHRoYXQgcmVhc29uIEkn ZCBwcmVmZXIgdG8gdXNlIGEgcmVxdWlyZW1lbnRzIGV4dHJhY3Rpb24gb24gdGhpcyBhbmQgb3Ro ZXIgc3BlY2lmaWNhdGlvbnMgd2UgbWlnaHQgcmV2aWV3IChwbHVzIGFkZGl0aW9uYWwgcmVxcyBh cyBkZWVtZWQgbmVjZXNzYXJ5IHZpYSB1c2UgY2FzZSBzY2VuYXJpbyByZXZpZXcpLiBJJ2QgcHJl ZmVyIHRvIHN0YXJ0IGJ5IGRlZmluaW5nIHNvbWUgb2YgdGhlIHVzZSBjYXNlcyBhbmQgbWFwIHRo ZXNlIGludG8gdGhlIHZhcmlvdXMgZ2F0ZXdheSBzcGVjaWZpY2F0aW9ucyBhbHJlYWR5IGluIGV4 aXN0ZW5jZS4gV2UgY291bGQgYWxzbyB0YWtlIGZyb20gdGhlIHVzZSBjYXNlIHNjZW5hcmlvcyBz b21lIG9mIHRoZSB0ZXh0IHdlIGRldmVsb3AgaW4gb3JkZXIgdG8gcHJvdmlkZSB0aGUgY3J1Y2lh bCBidXQgb2Z0ZW4gbWlzc2luZyBleGFtcGxlcyBzbyBvZnRlbiBsYWNraW5nIGZyb20gdGhlIGN1 cnJlbnQgY3JvcCBvZiBzcGVjcy4gCiAKLUtFCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwoKRnJvbTogaG9tZWdhdGUtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgV2VzIEJl ZWJlZSAod2JlZWJlZSkKU2VudDogVHVlIDYvMTYvMjAwOSA3OjI5IEFNClRvOiBSaWNoYXJkIEJl bm5ldHQ7IEhlYXRoZXIgS2lya3NleTsgaG9tZWdhdGVAaWV0Zi5vcmcKU3ViamVjdDogUmU6IFto b21lZ2F0ZV0gUERGIG9mIEJvRiBQcm9wb3NhbAoKCgpDYWJsZUxhYnMgYWxzbyBoYXMgdGhlIGVS b3V0ZXIgc3BlY2lmaWNhdGlvbiwgd2hpY2ggd2FzIHB1Ymxpc2hlZCBhdDoKCmh0dHA6Ly93d3cu Y2FibGVsYWJzLmNvbS9zcGVjaWZpY2F0aW9ucy9DTS1TUC1lUm91dGVyLUkwMy0wNzA1MTgucGRm CgpBbGwgb2YgdGhlc2Ugc3BlY2lmaWNhdGlvbnMgbWFrZSBhIGxhcmdlIG51bWJlciBvZiB2ZXJ5 IHNwZWNpZmljIG1hbmRhdG9yeSByZXF1aXJlbWVudHMgKGxvdHMgb2YgTVVTVHMpIGFuZCB3ZXJl IGRldmVsb3BlZCB2ZXJ5IHF1aWNrbHkgYnkgYSBzbWFsbCBudW1iZXIgb2YgcGVvcGxlIHdpdGhv dXQgYW55IGV4dGVybmFsIHJldmlldyBmb3IgYSB2ZXJ5IGxpbWl0ZWQgYW5kIHNwZWNpZmljIHNl dCBvZiBkZXBsb3ltZW50IHBhdHRlcm5zLiAgVGhleSBhcmUgYnVpbHQgd2l0aCBjb21wbGlhbmNl IGluIG1pbmQsIGFuZCBoYXZlIG9yZ2FuaXphdGlvbnMgdGhhdCBoYXZlIGEgaGlzdG9yeSBvZiB0 ZXN0aW5nIHByb2R1Y3RzICJ0byB0aGUgc3BlYyIuICBUaGV5IHRlbmQgdG8gaGF2ZSB2ZXJ5IGxp dHRsZSwgaWYgYW55LCB3cml0dGVuIGp1c3RpZmljYXRpb24gZm9yIHRoZSByZXF1aXJlbWVudHMg YW5kIGRvbid0IGhhdmUgZW5vdWdoIHR1dG9yaWFsIGJhY2tncm91bmQgbWF0ZXJpYWwgZm9yIGRl dmVsb3BlcnMgdG8gYmUgYWJsZSB0byBtYWtlIHdpc2UgaW1wbGVtZW50YXRpb24gY2hvaWNlcyBv ciBmb3IgdGhvc2UgbmV3IHRvIHRoZSBhcmVhIHRvIHVuZGVyc3RhbmQgd2hlcmUgdGhlIHByb3Rv Y29scyBjb21lIGZyb20uICBUaGV5IGhhdmUgbm90aWNhYmxlLCBnbGFyaW5nIGhvbGVzIGFuZCBm bGF3cyB0aGF0IGFyZSBubyBkb3VidCBhIHJlc3VsdCBvZiB0aGUgdGltZSBwcmVzc3VyZSBhbmQg bGltaXRlZCByZXZpZXcuCgpXaGF0IHRoZSBJRVRGIGNhbiBkbyBpbiB0aGlzIHNwYWNlIGlzIHNw ZWNpZmljYWxseSBub3QgZ28gdGhlIHNhbWUgcm91dGUgYXMgdGhlc2Ugc3BlY2lmaWNhdGlvbnMg YW5kIGNvbXBldGUgd2l0aCB0aGVtLiAgV2UgY2FuIHByb3ZpZGUgdGhlIG1pc3NpbmcgYmFja2dy b3VuZCBtYXRlcmlhbCBpbiBhIHNpbXBsZSwgZWFzeS10by11bmRlcnN0YW5kLCB0dXRvcmlhbCB3 YXkuICBXZSBjYW4gZmlsbCBpbiB0aGUgaG9sZXMgYW5kIGNvcnJlY3QgdGhlIGZsYXdzLiAgV2Ug Y2FuIGF2b2lkIGJlaW5nIHRpZWQgdG8gYW55IHBhcnRpY3VsYXIgZGVwbG95bWVudCBwYXR0ZXJu IHNvIGFzIHRvIHJlbWFpbiByZWxldmFudCB0byBhbGwgb2YgdGhlbS4gIFdlIGNhbiB1c2UgdGhl IHRpbWUgd2UgaGF2ZSBhbmQgdGhlIGJyb2FkIHJldmlldyBjYXBhYmlsaXRpZXMgb2YgdGhlIElF VEYgdG8gImdldCBpdCByaWdodCIuICBXZSBjYW4gdXNlIE1VU1Qgb25seSB3aGVuIHdlIGhhdmUg YSBnb29kIGV4cGxhbmF0aW9uIGZvciB3aHkgaXQgaGFzIHRvIGJlIHRoZXJlIC0gYW5kIHByb3Zp ZGUgdGhlIGV4cGxhbmF0aW9uIGluIHRoZSBkb2N1bWVudChzKS4KCi0gV2VzCgoKUCBHbyBHcmVl biEgUHJpbnQgdGhpcyBlbWFpbCBvbmx5IHdoZW4gbmVjZXNzYXJ5LiBUaGFuayB5b3UgZm9yIGhl bHBpbmcgVGltZSBXYXJuZXIgQ2FibGUgYmUgZW52aXJvbm1lbnRhbGx5IHJlc3BvbnNpYmxlLgog CiAKLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogaG9tZWdhdGUtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmhvbWVnYXRlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSaWNo YXJkIEJlbm5ldHQKU2VudDogVHVlc2RheSwgSnVuZSAxNiwgMjAwOSAxOjA1IEFNClRvOiAnSGVh dGhlciBLaXJrc2V5JzsgaG9tZWdhdGVAaWV0Zi5vcmcKU3ViamVjdDogUmU6IFtob21lZ2F0ZV0g UERGIG9mIEJvRiBQcm9wb3NhbAoKVGhlc2UgdHdvIGRvY3VtZW50cyBhcmUgdmVyeSBpbmZvcm1h dGl2ZSByZWdhcmRpbmcgdGhlIHN0YXRlIG9mIHRoZSBhcnQgcmVnYXJkaW5nIEludGVybmV0IHBy b3RvY29sIGtub3dsZWRnZSBhbW9uZyBnYXRld2F5IHZlbmRvcnMsIGFuZCBJIHJlY29tbWVuZCBy ZWFkaW5nIHRoZW0uIFdoYXQgeW91J2xsIGxpa2VseSBmaW5kIG1vc3QgaW50ZXJlc3RpbmcgaXMg bm90IHdoYXQgdGhleSBzYXkgYXMgd2hhdCB0aGV5IGRvbid0OyB0aGVyZSBhcmUgZW5vcm1vdXMg aG9sZXMgaW4gYm90aCBvZiB0aGVtLiBTZWFyY2ggZm9yICJFQ04iIGFuZCB5b3UnbGwgZ2V0IG5v IGhpdHMsIGZvciBleGFtcGxlLgoKRnJvbSBteSBleHBlcmllbmNlLCBCcm9hZGJhbmQgRm9ydW0g aGFzIGFuIGludGVybmF0aW9uYWwgbWVtYmVyc2hpcCB3aXRoIGEgTm9ydGggQW1lcmljYW4gYmlh cywgd2hpbGUgSEdJIGhhcyBhIG1vcmUgRXVyb3BlYW4gbWVtYmVyc2hpcCwgRldJVy4KClJpY2hh cmQgQmVubmV0dAotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpGcm9tOiBob21lZ2F0ZS1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86aG9tZWdhdGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEhlYXRoZXIgS2lya3NleQpTZW50OiBNb25kYXksIEp1bmUgMTUsIDIwMDkgMTo1OCBQTQpU bzogaG9tZWdhdGVAaWV0Zi5vcmcKU3ViamVjdDogUmU6IFtob21lZ2F0ZV0gUERGIG9mIEJvRiBQ cm9wb3NhbAoKQW5kcmV3LAoKSWYgeW91J3JlIGNvbnNpZGVyaW5nIElTUHMgdXNpbmcgdGhpcyB3 b3JrIHRvIGVuZm9yY2UgcmVxdWlyZW1lbnRzIG9uIHRoZWlyIHZlbmRvcnMsIGl0IG1pZ2h0IGJl IHdvcnRoIGNoZWNraW5nIG91dCBzb21lIHdvcmsgdGhhdCdzIGFscmVhZHkgZ29uZSBvbiBpbiB0 aGlzIGFyZWE6CgpCcm9hZGJhbmQgRm9ydW0gVFItMTI0IGRlZmluZXMgYSBzZXQgb2YgbW9kdWxh ciBmdW5jdGlvbmFsIHJlcXVpcmVtZW50cyBmb3IgYnJvYWRiYW5kIHJlc2lkZW50aWFsIGdhdGV3 YXlzOgpodHRwOi8vd3d3LmJyb2FkYmFuZC1mb3J1bS5vcmcvdGVjaG5pY2FsL2Rvd25sb2FkL1RS LTEyNC5wZGYuCgoKVGhlIEhvbWUgR2F0ZXdheSBJbml0aWF0aXZlIGFsc28gaGFzIGEgSG9tZSBH YXRld2F5IFJlcXVpcmVtZW50czoKUmVzaWRlbnRpYWwgUHJvZmlsZSBkb2N1bWVudDoKaHR0cDov L3d3dy5ob21lZ2F0ZXdheWluaXRpYXRpdmUub3JnL3B1Ymxpcy9IR0lfVjEuMDFfUmVzaWRlbnRp YWwucGRmLgoKSW4gYWRkaXRpb24sIEJyb2FkYmFuZCBGb3J1bSBoYXMgYSB3b3JrLWluLXByb2dy ZXNzIGRvY3VtZW50IGNhbGxlZCBQRC0xOTIgdGhhdCBkZWFscyB3aXRoIHRoZSBmdW5jdGlvbmFs IElQdjYgcmVxdWlyZW1lbnRzIGZvciBnYXRld2F5cyBpbiB0aGUgaG9tZSBiYXNlZCBvbiBjdXJy ZW50IG9wZXJhdG9yIHBsYW5zIGZvciBtaWdyYXRpb24gYW5kIGRlcGxveW1lbnQuICBCQkYgd2Fz IGFscmVhZHkgcGxhbm5pbmcgdG8gbGlhaXNlIHRoZSBQRC0xOTIgZG9jdW1lbnQgaW4gdGhlIHJl bGF0aXZlbHkgbmVhciBmdXR1cmUgdG8gZ2V0IGZlZWRiYWNrIG9uIGl0LgoKVGhhbmtzLApIZWF0 aGVyCgoKSGVhdGhlciBLaXJrc2V5Ck1vdGl2ZSBQcm9kdWN0IERpdmlzaW9uCkFsY2F0ZWwtTHVj ZW50CmhraXJrc2V5QG1vdGl2ZS5jb20KKzEuNTEyLjUzMS4xMTI2IChvZmZpY2UpCisxLjUxMi45 MTcuNzkzOCAobW9iaWxlKQogCgoKCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCkZyb206IGhv bWVnYXRlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpob21lZ2F0ZS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgQW5kcmV3IFN1bGxpdmFuClNlbnQ6IE1vbmRheSwgSnVuZSAxNSwgMjAw OSA4OjMxIEFNClRvOiBob21lZ2F0ZUBpZXRmLm9yZwpTdWJqZWN0OiBSZTogW2hvbWVnYXRlXSBQ REYgb2YgQm9GIFByb3Bvc2FsCgpPbiBTYXQsIEp1biAxMywgMjAwOSBhdCAwODo0MDo0MkFNICsw MjAwLCBMYXJzIEVnZ2VydCB3cm90ZToKCj4gaXQncyBub3QgY2xlYXIgdGhhdCB0aGUgY29uc3Vt ZXIgb2YgdGhpcyBlZmZvcnQgd291bGQgYmUgdGhlIGVuZCB1c2VyCj4gLSBmZXcgSUVURiBzcGVj aWZpY2F0aW9ucyBhcmUuIEluIG15IG1pbmQsIHRoaXMgd2FzIG1vc3RseSBhYm91dAo+IGdpdmlu ZyBndWlkZWxpbmVzIHRvIHZlbmRvcnMgYW5kIG9wZXJhdG9ycy4KCj4gVGhlIElFVEYgaXNuJ3Qg ZG9pbmcgc3RhbmRhcmRzIGNlcnRpZmljYXRpb24sIGFuZCB0aGVyZSBhcmUgZ29vZAo+IHJlYXNv bnMKW1tIUktdXQo+IGZvciB0aGF0LiBCdXQgbm90aGluZyBzdG9wcyBhbiBvdXRzaWRlIGVudGl0 eSB0byBydW4gYSBjb25mb3JtYW5jZQo+IHRlc3QgcHJvZ3JhbSBiYXNlZCBvbiBJRVRGIHNwZWNz LCBhbmQgSSBhZ3JlZSB0aGF0IGZvciB0aGUgZW5kIHVzZXJzLAo+IHNvbWUgc29ydCBvZiBlYXNp bHkgaWRlbnRpZmllZCBkaXN0aW5ndWlzaGVyIG9uIHRoZSBib3ggd291bGQgYmUgaGVscGZ1bC4K CkluIG15IHZpZXcsIHRoZSBhYm92ZSBzaG91bGQgYmUgYSBrZXkgZmFjdG9yIGluIG91ciB0aGlu a2luZy4gIElFVEYgc3RhbmRhcmRzIGdldCAiZW5mb3JjZWQiIGJ5IGNvbnRyYWN0cy4gIExhcmdl IG51bWJlcnMgb2YgdGhlc2UgZ2F0ZXdheSBkZXZpY2VzIGFyZSBzb2xkIG9yIG90aGVyd2lzZSBw cm92aWRlZCB0byBlbmQgdXNlcnMgYnkgSVNQcy4gIFNvIGlmIElTUHMgaGF2ZSBzb21ldGhpbmcg dG8gd2hpY2ggdGhleSBjYW4gcmVxdWlyZSB2ZW5kb3JzIHRvIGNvbmZvcm0gYXMgcGFydCBvZiB0 aGUgSVNQcycgcHVyY2hhc2Ugb2YgdGhlIGRldmljZXMgb3IgcmVjb21tZW5kYXRpb24gb2YgdGhl bSB0byBlbmQgY3VzdG9tZXJzLCB0aGF0IHdpbGwgcHJvYmFibHkgYmUgZW5vdWdoIG1hcmtldCBw cmVzc3VyZSB0byBhY2hpZXZlIHRoZSBkZXNpcmVkIHJlc3VsdC4KCkEKCi0tCkFuZHJldyBTdWxs aXZhbgphanNAc2hpbmt1cm8uY29tClNoaW5rdXJvLCBJbmMuCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCmhvbWVnYXRlIG1haWxpbmcgbGlzdApob21lZ2F0 ZUBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2hvbWVnYXRl Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmhvbWVnYXRl IG1haWxpbmcgbGlzdApob21lZ2F0ZUBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2hvbWVnYXRlCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwpob21lZ2F0ZSBtYWlsaW5nIGxpc3QKaG9tZWdhdGVAaWV0Zi5vcmcKaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ob21lZ2F0ZQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpob21lZ2F0ZSBtYWlsaW5nIGxpc3QK aG9tZWdhdGVAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9o b21lZ2F0ZQoKClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIFRpbWUgV2FybmVyCkNhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBw cml2aWxlZ2VkLCBjb25maWRlbnRpYWwsCm9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2lu ZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwKaXMgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaAppdCBpcyBhZGRy ZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcwpFLW1h aWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sCmRpc3Ry aWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250 ZW50cwpvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGli aXRlZCBhbmQgbWF5IGJlCnVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeQp0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJt YW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkKY29weSBvZiB0aGlzIEUtbWFpbCBh bmQgYW55IHByaW50b3V0Lgo= From kirk.erichsen@twcable.com Tue Jun 16 07:37:07 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 ACDD53A6A7D for ; Tue, 16 Jun 2009 07:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.449 X-Spam-Level: X-Spam-Status: No, score=-0.449 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 B+f++ssbOoJ4 for ; Tue, 16 Jun 2009 07:37:07 -0700 (PDT) Received: from pblpas01.twcable.com (pblpas01.twcable.com [204.235.121.149]) by core3.amsl.com (Postfix) with ESMTP id CFA8A3A69A9 for ; Tue, 16 Jun 2009 07:37:06 -0700 (PDT) X-SENDER-IP: 10.157.247.214 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,229,1243828800"; d="scan'208";a="423604596" Received: from unknown (HELO prvpmailconn4.corp.twcable.com) ([10.157.247.214]) by pblpas01.twcable.com with ESMTP; 16 Jun 2009 10:36:18 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn4.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 10:36:17 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Jun 2009 10:34:53 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Homegate and Multicast thread-index: AcnujNqelfhDUvLNTRC85Cx69uhy4gAAsJXV References: From: "Erichsen, Kirk" To: "Iljitsch van Beijnum" X-OriginalArrivalTime: 16 Jun 2009 14:36:17.0294 (UTC) FILETIME=[CEBC22E0:01C9EE8F] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: homegate@ietf.org, Greg Shepherd , Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 14:37:07 -0000 SSBoYXZlbid0IGhlYXJkIHRoYXQuIElzIHRoYXQgYSAic2hvdWxkIHdvcmsiIGJ1dCBkb2Vzbid0 IGR1ZSB0byBjb21tb24gZmxhd3MgaW4gaW1wbGVtZW50YXRpb24sIG9yICJjYW5ub3Qgd29yayIg YmVjYXVzZSBvZiBhIGZsYXcgaW4gdGhlIFdpRmkgc3BlY3M/IEl0IHdvdWxkIGJlIG91dCBvZiBz Y29wZSBpZiBpdCdzIGEgcXVlc3Rpb24gb2YgdGhlIFdpRmkgc3BlYy4KIAotS0UKCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCgpGcm9tOiBJbGppdHNjaCB2YW4gQmVpam51bSBbbWFp bHRvOmlsaml0c2NoQG11YWRhLmNvbV0KU2VudDogVHVlIDYvMTYvMjAwOSA4OjExIEFNClRvOiBF cmljaHNlbiwgS2lyawpDYzogTWFyc2hhbGwgRXViYW5rczsgaG9tZWdhdGVAaWV0Zi5vcmc7IEdy ZWcgU2hlcGhlcmQ7IExlb25hcmQgR2l1bGlhbm8KU3ViamVjdDogUmU6IFtob21lZ2F0ZV0gSG9t ZWdhdGUgYW5kIE11bHRpY2FzdAoKCgpPbiAxNiBqdW4gMjAwOSwgYXQgMTY6MDIsIEVyaWNoc2Vu LCBLaXJrIHdyb3RlOgoKPiBXaGlsZSBJUCB2aWRlbyBjb250ZW50IGRlbGl2ZXJ5IGlzIGFuIGVt ZXJnaW5nIHRlY2hub2xvZ3kgd2l0aCBtYW55IAo+IGFkdm9jYXRlcyBhbmQgaW50ZXJlc3RlZCBw YXJ0aWVzLCBpdCBjYW4gYmUgZGlmZmljdWx0IHRvIHNvcnQgCj4gdGhyb3VnaCB3aGljaCB1c2Ug Y2FzZXMgYXJlIHJlYWxpc3RpYyBhbmQgd2hpY2ggYXJlIG9ubHkgZXhlcmNpc2VzIAo+IGluIHRo ZW9yeS4KClNwZWFraW5nIG9mIHRoYXQ6IG11bHRpY2FzdCBzdHJlYW1pbmcgZG9lc24ndCB3b3Jr IG92ZXIgd2lmaS4gQSBsb3Qgb2YgCmhvbWUgZ2F0ZXdheXMgdGFsayB0byB0aGUgbG9jYWwgaG9z dHMgb3ZlciB3aWZpLiBIb3cgZG8gd2Ugc29sdmUgdGhpcz8KCgoKUCBHbyBHcmVlbiEgUHJpbnQg dGhpcyBlbWFpbCBvbmx5IHdoZW4gbmVjZXNzYXJ5LiBUaGFuayB5b3UgZm9yIGhlbHBpbmcgVGlt ZSBXYXJuZXIgQ2FibGUgYmUgZW52aXJvbm1lbnRhbGx5IHJlc3BvbnNpYmxlLgogCiAKVGhpcyBF LW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIK Q2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZp ZGVudGlhbCwKb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVy IENhYmxlLiBUaGlzIEUtbWFpbAppcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhl IGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoCml0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzCkUtbWFpbCwgeW91IGFyZSBoZXJl Ynkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwKZGlzdHJpYnV0aW9uLCBjb3B5aW5n LCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzCm9mIGFuZCBhdHRh Y2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUK dW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5CnRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0 aGUgb3JpZ2luYWwgYW5kIGFueQpjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQu Cg== From tme@americafree.tv Tue Jun 16 07:41:32 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 031A63A69A9 for ; Tue, 16 Jun 2009 07:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 YZLaQ-EPHqvs for ; Tue, 16 Jun 2009 07:41:31 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 1F2573A6D74 for ; Tue, 16 Jun 2009 07:41:31 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 71E774073245; Tue, 16 Jun 2009 10:40:45 -0400 (EDT) Message-Id: <36805ECA-926B-4956-8CA0-F667B2366DBE@americafree.tv> From: Marshall Eubanks To: "Erichsen, Kirk" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 10:40:45 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: Greg Shepherd , homegate@ietf.org, Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 14:41:32 -0000 On Jun 16, 2009, at 10:34 AM, Erichsen, Kirk wrote: > I haven't heard that. Is that a "should work" but doesn't due to > common flaws in implementation, or "cannot work" because of a flaw > in the WiFi specs? It would be out of scope if it's a question of > the WiFi spec. > No, it works fine, it's just that most Access Points have to flood the traffic, so many (most?) limit or block it by default. (Apple Airports used to limit multicast to 1 Mbps out of the box, for example, but of course you could change it if you wanted to.) Of course, when you are talking about home deployments, anything that requires people to change default settings on their gateways to do something will eliminate 95% or more of the market. See my other message on this for more details. Regards Marshall > -KE > > ________________________________ > > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Tue 6/16/2009 8:11 AM > To: Erichsen, Kirk > Cc: Marshall Eubanks; homegate@ietf.org; Greg Shepherd; Leonard > Giuliano > Subject: Re: [homegate] Homegate and Multicast > > > > On 16 jun 2009, at 16:02, Erichsen, Kirk wrote: > >> While IP video content delivery is an emerging technology with many >> advocates and interested parties, it can be difficult to sort >> through which use cases are realistic and which are only exercises >> in theory. > > Speaking of that: multicast streaming doesn't work over wifi. A lot of > home gateways talk to the local hosts over wifi. How do we solve this? > > > > P Go Green! Print this email only when necessary. Thank you for > helping Time Warner Cable be environmentally responsible. > > > This E-mail and any of its attachments may contain Time Warner > Cable proprietary information, which is privileged, confidential, > or subject to copyright belonging to Time Warner Cable. This E-mail > is intended solely for the use of the individual or entity to which > it is addressed. If you are not the intended recipient of this > E-mail, you are hereby notified that any dissemination, > distribution, copying, or action taken in relation to the contents > of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. From shemant@cisco.com Tue Jun 16 07:45:41 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 69D5E28C186 for ; Tue, 16 Jun 2009 07:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ocDmqASm+q-Q for ; Tue, 16 Jun 2009 07:45:40 -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 309173A6915 for ; Tue, 16 Jun 2009 07:45:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,229,1243814400"; d="scan'208";a="47543755" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Jun 2009 14:43:39 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5GEhdFE013242; Tue, 16 Jun 2009 10:43:39 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5GEhdvC011309; Tue, 16 Jun 2009 14:43:39 GMT Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 10:43:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 10:43:38 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Homegate and Multicast Thread-Index: AcnujNqelfhDUvLNTRC85Cx69uhy4gAAsJXVAAAcljA= References: From: "Hemant Singh (shemant)" To: "Erichsen, Kirk" , "Iljitsch van Beijnum" X-OriginalArrivalTime: 16 Jun 2009 14:43:39.0513 (UTC) FILETIME=[D6516690:01C9EE90] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1017; t=1245163419; x=1246027419; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20 |Subject:=20RE=3A=20[homegate]=20Homegate=20and=20Multicast |Sender:=20 |To:=20=22Erichsen,=20Kirk=22=20 ,=0A=20=20=20=20=20=20=20=20=22Iljitsch=20van=20Beijnum=22=2 0; bh=7zE9InMNbaYM6BEcxKQB+cXfYkT44Ayw+9MxB6tb9F0=; b=bozq9DVNP77kgQCFxpP55A9629RAN6Bve39pm4vBom1qLkhWyjt6S2KDgl 8raNuFW9gQWawii6LsAOdeSwHfbxrwPwaQuGbxK4Yet/y7sN8IFc9zAWg8mn MsNe5lhIq4; Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Greg Shepherd , homegate@ietf.org, Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 14:45:41 -0000 Some more thought has to be given to video over WiF because WiFi spans my neighbor's home too and if the home router is not well secured and managed, my video over WiFi goes to the neighbor's home as well. The video delivery has to be planned too because if cable operators send broadcast quality TV video to a home, the video channel is encrypted and theft safe. Such encryption mechanisms may not exist with IPTV or local video running in home including over wireless.=20 Hemant -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behalf Of Erichsen, Kirk Sent: Tuesday, June 16, 2009 10:35 AM To: Iljitsch van Beijnum Cc: homegate@ietf.org; Greg Shepherd; Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast I haven't heard that. Is that a "should work" but doesn't due to common flaws in implementation, or "cannot work" because of a flaw in the WiFi specs? It would be out of scope if it's a question of the WiFi spec. =20 -KE From kirk.erichsen@twcable.com Tue Jun 16 07:46: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 A24483A6A2F for ; Tue, 16 Jun 2009 07:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.45 X-Spam-Level: X-Spam-Status: No, score=-0.45 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 KoPwTRsmpUx9 for ; Tue, 16 Jun 2009 07:46:55 -0700 (PDT) Received: from pblpas01.twcable.com (pblpas01.twcable.com [204.235.121.149]) by core3.amsl.com (Postfix) with ESMTP id 948643A6915 for ; Tue, 16 Jun 2009 07:46:55 -0700 (PDT) X-SENDER-IP: 10.157.247.213 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,229,1243828800"; d="scan'208";a="423608102" Received: from unknown (HELO prvpmailconn3.corp.twcable.com) ([10.157.247.213]) by pblpas01.twcable.com with ESMTP; 16 Jun 2009 10:45:32 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 10:45:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Jun 2009 10:41:47 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Homegate and Multicast Thread-Index: AcnukG86OpKv2PGBRTG9slmIgQLs7wAACQRG References: <36805ECA-926B-4956-8CA0-F667B2366DBE@americafree.tv> From: "Erichsen, Kirk" To: "Marshall Eubanks" X-OriginalArrivalTime: 16 Jun 2009 14:45:31.0311 (UTC) FILETIME=[18F46BF0:01C9EE91] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: Greg Shepherd , homegate@ietf.org, Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 14:46:56 -0000 Marshall, =20 I caught up with your multicast thread. This looks thoroughly resolvable wi= th a modicum of explicit behavioral definition and should apply, as you've = stated below and elsewhere, regardless of the LAN side interface the mcast = will traverse. On the important point of "defaults," we should define these= such that we do not require extensive reconfiguration by the professional = installer or end user/customer, consistent with the view that all such chan= ges to advanced functionality tend to incur user error (which can be worse = than not working at all) or at the very least limit the use of the function= ality substantially.=20 =20 -KE ________________________________ From: Marshall Eubanks [mailto:tme@americafree.tv] Sent: Tue 6/16/2009 8:40 AM To: Erichsen, Kirk Cc: Iljitsch van Beijnum; homegate@ietf.org; Greg Shepherd; Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast On Jun 16, 2009, at 10:34 AM, Erichsen, Kirk wrote: > I haven't heard that. Is that a "should work" but doesn't due to=20 > common flaws in implementation, or "cannot work" because of a flaw=20 > in the WiFi specs? It would be out of scope if it's a question of=20 > the WiFi spec. > No, it works fine, it's just that most Access Points have to flood the=20 traffic, so many (most?) limit or block it by default. (Apple Airports used to limit multicast to 1 Mbps=20 out of the box, for example, but of course you could change it if you wanted to.) Of course, when you are talking about home deployments, anything that=20 requires people to change default settings on their gateways to do something will eliminate 95% or more=20 of the market. See my other message on this for more details. Regards Marshall > -KE > > ________________________________ > > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Tue 6/16/2009 8:11 AM > To: Erichsen, Kirk > Cc: Marshall Eubanks; homegate@ietf.org; Greg Shepherd; Leonard=20 > Giuliano > Subject: Re: [homegate] Homegate and Multicast > > > > On 16 jun 2009, at 16:02, Erichsen, Kirk wrote: > >> While IP video content delivery is an emerging technology with many >> advocates and interested parties, it can be difficult to sort >> through which use cases are realistic and which are only exercises >> in theory. > > Speaking of that: multicast streaming doesn't work over wifi. A lot of > home gateways talk to the local hosts over wifi. How do we solve this? > > > > P Go Green! Print this email only when necessary. Thank you for=20 > helping Time Warner Cable be environmentally responsible. > > > This E-mail and any of its attachments may contain Time Warner > Cable proprietary information, which is privileged, confidential, > or subject to copyright belonging to Time Warner Cable. This E-mail > is intended solely for the use of the individual or entity to which > it is addressed. If you are not the intended recipient of this > E-mail, you are hereby notified that any dissemination, > distribution, copying, or action taken in relation to the contents > of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From tme@americafree.tv Tue Jun 16 07:59: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 415C23A6ADA for ; Tue, 16 Jun 2009 07:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[AWL=-0.089, 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 z-jlkASkkrag for ; Tue, 16 Jun 2009 07:59:42 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 62E2B3A69C4 for ; Tue, 16 Jun 2009 07:59:42 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id E3344407399C; Tue, 16 Jun 2009 10:58:48 -0400 (EDT) Message-Id: <1B324B7B-B655-49E8-B054-E42D858654B0@americafree.tv> From: Marshall Eubanks To: "Hemant Singh (shemant)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 10:58:48 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: Greg Shepherd , homegate@ietf.org, Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 14:59:43 -0000 On Jun 16, 2009, at 10:43 AM, Hemant Singh (shemant) wrote: > Some more thought has to be given to video over WiF because WiFi spans > my neighbor's home too and if the home router is not well secured and > managed, my video over WiFi goes to the neighbor's home as well. The > video delivery has to be planned too because if cable operators send > broadcast quality TV video to a home, the video channel is encrypted > and > theft safe. Such encryption mechanisms may not exist with IPTV or > local > video running in home including over wireless. > Such encryption mechanisms do not and will not in general exist with Internet video. (I am talking about content encryption, not protection of the 802.11 itself.) In the case of IPTV, if the provider is providing "network" television, then (at least in the USA) they do insist on encryption and other protections of the streams. In many cases this extends to requiring use of approved hardware/ software solutions and even bringing engineers on-site for certification, which suggests that, if network television is ever going to be unbundled in the US (as I think it will), then the home gateway effort would have to worry about this. Regards Marshall P.S. If you are interested, I can recommend the IPTV-Users list at iptv-users@puck.nether.net > Hemant > > -----Original Message----- > From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On > Behalf Of Erichsen, Kirk > Sent: Tuesday, June 16, 2009 10:35 AM > To: Iljitsch van Beijnum > Cc: homegate@ietf.org; Greg Shepherd; Leonard Giuliano > Subject: Re: [homegate] Homegate and Multicast > > I haven't heard that. Is that a "should work" but doesn't due to > common > flaws in implementation, or "cannot work" because of a flaw in the > WiFi > specs? It would be out of scope if it's a question of the WiFi spec. > > -KE > > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate > From kirk.erichsen@twcable.com Tue Jun 16 08:01:41 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 208383A6D7D for ; Tue, 16 Jun 2009 08:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.451 X-Spam-Level: X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 yE78SUtHp4ir for ; Tue, 16 Jun 2009 08:01:40 -0700 (PDT) Received: from pblpas02.twcable.com (pblpas02.twcable.com [204.235.121.150]) by core3.amsl.com (Postfix) with ESMTP id ED3C53A69C4 for ; Tue, 16 Jun 2009 08:01:39 -0700 (PDT) X-SENDER-IP: 10.157.247.211 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,229,1243828800"; d="scan'208";a="422739572" Received: from unknown (HELO prvpmailconn1.corp.twcable.com) ([10.157.247.211]) by pblpas02.twcable.com with ESMTP; 16 Jun 2009 10:52:50 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn1.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 10:52:50 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Jun 2009 10:52:49 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Homegate and Multicast thread-index: AcnujNqelfhDUvLNTRC85Cx69uhy4gAAsJXVAAAcljAAAE24gw== References: From: "Erichsen, Kirk" To: "Hemant Singh \(shemant\)" , "Iljitsch van Beijnum" X-OriginalArrivalTime: 16 Jun 2009 14:52:50.0781 (UTC) FILETIME=[1EE638D0:01C9EE92] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: Greg Shepherd , homegate@ietf.org, Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 15:01:41 -0000 VGhlcmUgd2lsbCBiZSBhIGxvdCBvZiBkZXRhaWwgdGhhdCBoYXMgdG8gZ28gaW50byB0aGUgdXNl IGNhc2VzLiBFeGFtcGxlcyB0aHJvd24gYXJvdW5kIHNvIGZhciBoYXZlIGluY2x1ZGVkIHNlcGFy YXRlIERSTSBzdHJhdGVnaWVzIGRlcGVuZGluZyBvbiB3aGV0aGVyIHRoZSBlbmQgZGV2aWNlIGlz IGEgUEMgb3IgYW4gSVAgU1RCIGFuZCB0aG9zZSB0aGF0IHJlbHkgbW9yZSBvbiB3aXJlbGluZSBz ZWN1cml0eSBhbmQgbGVzcyBvbiBhcHBsaWNhdGlvbiBsYXllciBzZWN1cml0eSAoaS5lLiBEUk0p LiBOZWl0aGVyIGlzIGZ1bGwgcHJvb2YuIFRvIGdldCB0aGUgY29uc2VudCBvZiBjb250ZW50IHBy b3ZpZGVycywgaXQgbWF5IGJlIG5lY2Vzc2FyeSAob3IgYXQgbGVhc3QgdG8gYW50aWNpcGF0ZSkg ZG9pbmcgYSBiaXQgb2YgYm90aC4gVGhlIGNvbnRlbnQgcHJvdmlkZXJzIGFyZSB3ZWxsIGF3YXJl IHRoYXQgdGhlaXIgdmFsdWUgY291bGQgYmUgc2FwcGVkIGF3YXkgYnkgYSBwb29ybHkgaW1wbGVt ZW50ZWQvcG9vcmx5IGRlcGxveWVkIGN1c3RvbWVyIGdhdGV3YXkgdGhhdCBsZXRzIGV2ZXJ5b25l IGluIHRoZSBuZWlnaGJvcmhvb2QgZ2V0IGFjY2VzcyB0byBzdHJlYW1zIHRoYXQgY291bGQgcG90 ZW50aWFsbHkgZmluZCB0aGVpciB3YXkgaW50byB0aGUgcm91Z2UgUDJQIGRpc3RyaWJ1dGlvbiBu ZXRzLgogClRoZSBpc3N1ZSB3aXRoIGRvdmV0YWlsaW5nIGFueSBJUFRWIHN0cmF0ZWd5IGludG8g dGhpcyBnYXRld2F5IGVmZm9ydCBhcmUgdGhlIGhpZ2ggcmlzayB0aGF0IHdlIHdpbGwgbm90IGhh dmUgYnJvYWQgaW5kdXN0cnkgY29uc2Vuc3VzIHdpdGggcmVnYXJkcyB0byBwcm90b2NvbHMsIGFy Y2hpdGVjdHVyZSwgZXRjLiBhbmQgdGhhdCB3aWxsIGxlYXZlIHRoZXNlIGFuc3dlcnMgaGFsZiBh bnN3ZXJlZC4gV2hpbGUgaXQgaXMgaW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCwgd2Ugd2lsbCBo YXZlIHRvIG1vbml0b3Igb3RoZXIgZ3JvdXBzIGZvciBhY3Rpdml0eSB0byBkZXRlcm1pbmUgd2hh dCB3ZSBjYW4gYm9ycm93IGZyb20gYW5kIHdoYXQgbmVlZHMgbG9uZ2VyIHRvIHdvcmsgaXRzZWxm IG91dC4gQXMgd2UgcHJvZ3Jlc3MgYW5kIHByb2plY3RzIGRldmVsb3Agd2UgY291bGQgYm9ycm93 IGZyb20gZW1lcmdlLCBwZXJoYXBzIHdlIGNvdWxkIGxpYWlzb24gaW50byB0aGF0IGdyb3VwIChv ciBncm91cHMpLiBVbnRpbCB0aGVuIGl0J3MgcHJvYmFibHkgZ29pbmcgdG8gYmUgYW4gZXhlcmNp c2UgaW4gZnJ1c3RyYXRpb24gYW5kIGNvdWxkIGVhc2lseSBzbG93IG91ciBwcm9ncmVzcyBpZiB3 ZSB0cnkgdG8gZnVsbHkgaW5jb3Jwb3JhdGUgdGhlIHNjb3BlIElQVFYgZGVsaXZlcnkgb3ZlciBh IGdhdGV3YXkgd2l0aCBhbGwgdGhlIG51dHMgYW5kIGJvbHRzIHdvdWxkIGVudGFpbC4KIAotS0UK Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpGcm9tOiBIZW1hbnQgU2luZ2ggKHNo ZW1hbnQpIFttYWlsdG86c2hlbWFudEBjaXNjby5jb21dClNlbnQ6IFR1ZSA2LzE2LzIwMDkgODo0 MyBBTQpUbzogRXJpY2hzZW4sIEtpcms7IElsaml0c2NoIHZhbiBCZWlqbnVtCkNjOiBob21lZ2F0 ZUBpZXRmLm9yZzsgR3JlZyBTaGVwaGVyZDsgTGVvbmFyZCBHaXVsaWFubwpTdWJqZWN0OiBSRTog W2hvbWVnYXRlXSBIb21lZ2F0ZSBhbmQgTXVsdGljYXN0CgoKClNvbWUgbW9yZSB0aG91Z2h0IGhh cyB0byBiZSBnaXZlbiB0byB2aWRlbyBvdmVyIFdpRiBiZWNhdXNlIFdpRmkgc3BhbnMKbXkgbmVp Z2hib3IncyBob21lIHRvbyBhbmQgaWYgdGhlIGhvbWUgcm91dGVyIGlzIG5vdCB3ZWxsIHNlY3Vy ZWQgYW5kCm1hbmFnZWQsIG15IHZpZGVvIG92ZXIgV2lGaSBnb2VzIHRvIHRoZSBuZWlnaGJvcidz IGhvbWUgYXMgd2VsbC4gIFRoZQp2aWRlbyBkZWxpdmVyeSBoYXMgdG8gYmUgcGxhbm5lZCB0b28g YmVjYXVzZSBpZiBjYWJsZSBvcGVyYXRvcnMgc2VuZApicm9hZGNhc3QgcXVhbGl0eSBUViB2aWRl byB0byBhIGhvbWUsIHRoZSB2aWRlbyBjaGFubmVsIGlzIGVuY3J5cHRlZCBhbmQKdGhlZnQgc2Fm ZS4gIFN1Y2ggZW5jcnlwdGlvbiBtZWNoYW5pc21zIG1heSBub3QgZXhpc3Qgd2l0aCBJUFRWIG9y IGxvY2FsCnZpZGVvIHJ1bm5pbmcgaW4gaG9tZSBpbmNsdWRpbmcgb3ZlciB3aXJlbGVzcy4KCkhl bWFudAoKClAgR28gR3JlZW4hIFByaW50IHRoaXMgZW1haWwgb25seSB3aGVuIG5lY2Vzc2FyeS4g VGhhbmsgeW91IGZvciBoZWxwaW5nIFRpbWUgV2FybmVyIENhYmxlIGJlIGVudmlyb25tZW50YWxs eSByZXNwb25zaWJsZS4KIAogCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCkZyb206IGhvbWVn YXRlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpob21lZ2F0ZS1ib3VuY2VzQGlldGYub3JnXSBP bgpCZWhhbGYgT2YgRXJpY2hzZW4sIEtpcmsKU2VudDogVHVlc2RheSwgSnVuZSAxNiwgMjAwOSAx MDozNSBBTQpUbzogSWxqaXRzY2ggdmFuIEJlaWpudW0KQ2M6IGhvbWVnYXRlQGlldGYub3JnOyBH cmVnIFNoZXBoZXJkOyBMZW9uYXJkIEdpdWxpYW5vClN1YmplY3Q6IFJlOiBbaG9tZWdhdGVdIEhv bWVnYXRlIGFuZCBNdWx0aWNhc3QKCkkgaGF2ZW4ndCBoZWFyZCB0aGF0LiBJcyB0aGF0IGEgInNo b3VsZCB3b3JrIiBidXQgZG9lc24ndCBkdWUgdG8gY29tbW9uCmZsYXdzIGluIGltcGxlbWVudGF0 aW9uLCBvciAiY2Fubm90IHdvcmsiIGJlY2F1c2Ugb2YgYSBmbGF3IGluIHRoZSBXaUZpCnNwZWNz PyBJdCB3b3VsZCBiZSBvdXQgb2Ygc2NvcGUgaWYgaXQncyBhIHF1ZXN0aW9uIG9mIHRoZSBXaUZp IHNwZWMuCgotS0UKCgoKVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5 IGNvbnRhaW4gVGltZSBXYXJuZXIKQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNo IGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwKb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVs b25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbAppcyBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoCml0IGlz IGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlz CkUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwK ZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhl IGNvbnRlbnRzCm9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBw cm9oaWJpdGVkIGFuZCBtYXkgYmUKdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg RS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5CnRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5k IHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueQpjb3B5IG9mIHRoaXMgRS1t YWlsIGFuZCBhbnkgcHJpbnRvdXQuCg== From jf.mule@cablelabs.com Tue Jun 16 08:06: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 894063A6D69 for ; Tue, 16 Jun 2009 08:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 zfPfolLplVLe for ; Tue, 16 Jun 2009 08:06:24 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 70FF33A68A0 for ; Tue, 16 Jun 2009 08:06:24 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n5GF0eaM008679; Tue, 16 Jun 2009 09:00:40 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 16 Jun 2009 09:00:40 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 09:00:13 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601EED236@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] PDF of BoF Proposal Thread-Index: AcntvY3IJI7GRqqKRyS0ATiRYbfBbgAOUxbgABIoduAAEP5gIAADbB1Q References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com><4A3182AE.9040508@swin.edu.au><4A31FCB3.7080607@unifr.ch><20090612133220.70c3094c.dgerow@afflictions.org><20090615133048.GA38531@shinkuro.com> From: "Jean-Francois Mule" To: "Wes Beebee (wbeebee)" , "Richard Bennett" , "Heather Kirksey" , X-Approved: ondar Subject: Re: [homegate] PDF of BoF Proposal 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, 16 Jun 2009 15:06:25 -0000 Wes wrote: > -----Original Message----- > From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] > On Behalf Of Wes Beebee (wbeebee) > Sent: Tuesday, June 16, 2009 7:30 AM > To: Richard Bennett; Heather Kirksey; homegate@ietf.org > Subject: Re: [homegate] PDF of BoF Proposal >=20 > CableLabs also has the eRouter specification, which was published > at: >=20 > http://www.cablelabs.com/specifications/CM-SP-eRouter-I03- > 070518.pdf As a side note, this is a 4-year old document that emerged from an initiative that started in 2005, the doc was last updated in May 2007. > All of these specifications make a large number of very specific > mandatory requirements (lots of MUSTs) and were developed very > quickly by a small number of people without any external review for The people who helped write the documents & requirements are acknowledged inside. > a very limited and specific set of deployment patterns. They are > built with compliance in mind, and have organizations that have a > history of testing products "to the spec". They tend to have very > little, if any, written justification for the requirements and > don't have enough tutorial background material for developers to be > able to make wise implementation choices or for those new to the > area to understand where the protocols come from. They have > noticable, glaring holes and flaws that are no doubt a result of > the time pressure and limited review. Sure, getting something out to test it and realize what does not work is always a plus. Correcting flaws is good when you have products to test with. >=20 > What the IETF can do in this space is specifically not go the same > route as these specifications and compete with them. =20 There is no competition really. The IETF is an SDO and it is where the expertise is, driven by end-user needs and e2e models (not solely driven by a service provider model, even if it counts for some). There are other organizations that need to be consulted like BBWF, UPnP Forum, HGI, CableLabs, etc. But what we all collectively need is to collaborate to come up with requirements that home gateway vendors can implement for multiple markets. The IETF is a natural place to do some of what needed there. > We can > provide the missing background material in a simple, easy-to- > understand, tutorial way. =20 To me, we've past the stage of tutorials. We need specifications that vendors can build to and the smaller set of requirements the better. > We can fill in the holes and correct the > flaws. We can avoid being tied to any particular deployment > pattern so as to remain relevant to all of them. We can use the > time we have and the broad review capabilities of the IETF to "get > it right". We can use MUST only when we have a good explanation > for why it has to be there - and provide the explanation in the > document(s). That would be ok. Vendors can decide to implement SHOULDs and MAYs on their own; some organizations will make those tighter by transforming SHOULD into MUST to build compliance to specific scenarios. But if we all have a common base from IETF, it sure helps get there faster and with scale, and with support for various user and service provider deployment models. >=20 > - Wes Jean-Francois jfm@cablelabs.com From tme@americafree.tv Tue Jun 16 08:21: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 A92E23A6B6A for ; Tue, 16 Jun 2009 08:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[AWL=-0.086, 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 9qXcQoh290v8 for ; Tue, 16 Jun 2009 08:21:33 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id A8B663A695F for ; Tue, 16 Jun 2009 08:21:33 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 0CEA64074284; Tue, 16 Jun 2009 11:20:37 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Iljitsch van Beijnum In-Reply-To: <3AF41F51-4411-4D34-B74A-4FA625B3B314@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 11:20:36 -0400 References: <7E6E35CE-AB91-400D-BD22-4BD6E1BD6986@americafree.tv> <3AF41F51-4411-4D34-B74A-4FA625B3B314@muada.com> X-Mailer: Apple Mail (2.935.3) Cc: homegate@ietf.org Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 15:21:34 -0000 On Jun 16, 2009, at 10:43 AM, Iljitsch van Beijnum wrote: > On 16 jun 2009, at 16:34, Marshall Eubanks wrote: > >>> Speaking of that: multicast streaming doesn't work over wifi. A >>> lot of home gateways talk to the local hosts over wifi. How do we >>> solve this? > >> Multicast does work over 802.11. > > Of course, otherwise ARP or ND wouldn't work and IP over 802.11 > would be impossible. > > However, multicast _streaming_ doesn't work. > Sure it does. I have done this professionally, to distribute video at shows. You need to pay attention to your SNR, RFI, etc. >> The trouble is that many access points don't do IGMP/MLD, so any >> multicast present on the wireline side of the LAN is flooded to the >> wireless. In an enterprise environment (with a faster LAN than >> WLAN, and potentially lots of multicast users), this has the risk >> to totally flood the 802 WLAN with unintended traffic. As a result, >> a lot of access points limit or block multicast by default. > > I've seen multicast rate limiting and the other issues that you > mention may also be a factor. However, the real problem is that > wireless is unreliable, and because there are presumably many > listeners, the normal ACK/retransmission mechanism isn't used for > broadcasts/multicasts on 802.11. So you lose many packets. Another > problem is that in order to make multicasts for management protocols > work those packets are sent at very low bitrates (1 - 6 Mbps) so > even a few Mbps of multicast traffic saturates the wireless channel. > 802.11b will indeed saturate at something like 6 Mbps IIRC. Whether that is a very low bit rate is a matter of debate. In many instances, this is hard to tell. (If the bandwidth to the Internet is, say, 2 Mbps, a 6 Mbps limit is hard to detect.) Clearly, as home Internet bandwidths increase, home LAN and WLAN speeds need to keep up. The home use case is different from, say, the needs of the IETF meeting network and I frankly doubt a "one size fits all" solution is attainable. FEC would be very useful for 802.11 multicasts, but I don't that Homegate should deal with Layer 3 FEC of wireless traffic. That should be provided by operators, streaming servers, etc. It occurs to me as I write this that P2P is also an important home use, and Homegate should also be aware of whatever comes from the ALTO / PPSP / LEDBAT efforts. Regards Marshall > (BTW the 1 Mbps thing that you mention about Apple base stations > isn't a rate limit but the rate at which multicasts are sent AFAIK. > With an older Apple base station I had the situation that after > three or so multicasts in quick succession multicasts would be block > for a short time. With the newer AEBS that doesn't seem to be the > case anymore but I haven't extensively tested this.) > From iljitsch@muada.com Tue Jun 16 08:49: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 27A893A6969 for ; Tue, 16 Jun 2009 08:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 Fqttiuh1I50x for ; Tue, 16 Jun 2009 08:49:45 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 0F80428C18F for ; Tue, 16 Jun 2009 08:49:44 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.219]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n5GEi0nO085275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Jun 2009 16:44:01 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <3AF41F51-4411-4D34-B74A-4FA625B3B314@muada.com> From: Iljitsch van Beijnum To: Marshall Eubanks In-Reply-To: <7E6E35CE-AB91-400D-BD22-4BD6E1BD6986@americafree.tv> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 16:43:29 +0200 References: <7E6E35CE-AB91-400D-BD22-4BD6E1BD6986@americafree.tv> X-Mailer: Apple Mail (2.935.3) Cc: homegate@ietf.org Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 15:49:46 -0000 On 16 jun 2009, at 16:34, Marshall Eubanks wrote: >> Speaking of that: multicast streaming doesn't work over wifi. A lot >> of home gateways talk to the local hosts over wifi. How do we solve >> this? > Multicast does work over 802.11. Of course, otherwise ARP or ND wouldn't work and IP over 802.11 would be impossible. However, multicast _streaming_ doesn't work. > The trouble is that many access points don't do IGMP/MLD, so any > multicast present on the wireline side of the LAN is flooded to the > wireless. In an enterprise environment (with a faster LAN than WLAN, > and potentially lots of multicast users), this has the risk to > totally flood the 802 WLAN with unintended traffic. As a result, a > lot of access points limit or block multicast by default. I've seen multicast rate limiting and the other issues that you mention may also be a factor. However, the real problem is that wireless is unreliable, and because there are presumably many listeners, the normal ACK/retransmission mechanism isn't used for broadcasts/multicasts on 802.11. So you lose many packets. Another problem is that in order to make multicasts for management protocols work those packets are sent at very low bitrates (1 - 6 Mbps) so even a few Mbps of multicast traffic saturates the wireless channel. (BTW the 1 Mbps thing that you mention about Apple base stations isn't a rate limit but the rate at which multicasts are sent AFAIK. With an older Apple base station I had the situation that after three or so multicasts in quick succession multicasts would be block for a short time. With the newer AEBS that doesn't seem to be the case anymore but I haven't extensively tested this.) From joe@grey.uoregon.edu Tue Jun 16 08:53: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 528163A6D88 for ; Tue, 16 Jun 2009 08:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=1.110, 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 FueQFHd69B5D for ; Tue, 16 Jun 2009 08:53:24 -0700 (PDT) Received: from grey.uoregon.edu (grey.uoregon.edu [128.223.214.89]) by core3.amsl.com (Postfix) with SMTP id 2C8493A6D82 for ; Tue, 16 Jun 2009 08:53:24 -0700 (PDT) Received: by grey.uoregon.edu for homegate@ietf.org; Tue, 16 Jun 2009 08:19:27 -0700 Date: Tue, 16 Jun 2009 08:19:27 -0700 From: Joe St Sauver To: homegate@ietf.org Message-Id: <09061608192773.8189d.1310962750@oregon.uoregon.edu> Subject: [homegate] Jumbo frames X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: joe@oregon.uoregon.edu List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 15:53:25 -0000 Hi, As DOCSIS 3.0 and the like boost the speeds which will available to consumers, I'd love to see home gateway devices support 9K MTUs (aka "jumbo frames"). Without home gateway support for jumbo frames, our chances of ever getting the Internet's end-to-end MTU to be greater than 1500 bytes, and thus our chances of broadly improving single stream TCP performance, appear rather bleak. I'd also note that jumbo frame support is the classic "third leg" of the "advanced protocol triad," the other two bits being IPv6 and IP multicast. (e.g., see http://dc-2.grnoc.iu.edu/vn/analysis/connector-tech.html ) It would be a shame to do two of the three, only to miss the third. Regards, Joe St Sauver (joe@oregon.uoregon.edu) http://www.uoregon.edu/~joe/ Disclaimer: all opinions expressed are strictly my own From tme@americafree.tv Tue Jun 16 08:53:44 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 76F0628C163 for ; Tue, 16 Jun 2009 08:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.683 X-Spam-Level: X-Spam-Status: No, score=-2.683 tagged_above=-999 required=5 tests=[AWL=-0.084, 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 BxvA2wQy2lcK for ; Tue, 16 Jun 2009 08:53:43 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 4A00C3A6969 for ; Tue, 16 Jun 2009 08:53:43 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id B634E4074C62; Tue, 16 Jun 2009 11:44:39 -0400 (EDT) Message-Id: From: Marshall Eubanks To: "Erichsen, Kirk" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 11:44:39 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: Greg Shepherd , homegate@ietf.org, Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 15:53:44 -0000 Dear Kirk; On Jun 16, 2009, at 10:52 AM, Erichsen, Kirk wrote: > There will be a lot of detail that has to go into the use cases. > Examples thrown around so far have included separate DRM strategies > depending on whether the end device is a PC or an IP STB and those > that rely more on wireline security and less on application layer > security (i.e. DRM). Neither is full proof. To get the consent of > content providers, it may be necessary (or at least to anticipate) > doing a bit of both. The content providers are Some content providers, if you please. In this context you need to keep in mind that there are other parties at the table, many of whom do not view DRM as essential to their business model. > well aware that their value could be sapped away by a poorly > implemented/poorly deployed customer gateway that lets everyone in > the neighborhood get access to streams that could potentially find > their way into the rouge P2P distribution nets. > > The issue with dovetailing any IPTV strategy into this gateway > effort are the high risk that we will not have broad industry > consensus with regards to protocols, architecture, etc. and that > will leave these answers half answered. While it is important to > keep in mind, we will have to monitor other groups for activity to > determine what we can borrow from and what needs longer to work > itself out. I would certainly not advocate re-inventing any of these wheels. From what I can tell, there are a number of groups, such as the VSF/SMPTE one, making rapid progress on open IPTV protocols. (Open standards, not generally open source.) To the extent that these get industry acceptance, they could ride on top of the Homegate effort. I am not aware of much, except for the support of multicast, that Homegate would have to do to support these protocols. The end user might need to buy a box or a NIC card, but if the gateway does not need to worry about what's going on the wire, I don't think it should. Regards Marshall > As we progress and projects develop we could borrow from emerge, > perhaps we could liaison into that group (or groups). Until then > it's probably going to be an exercise in frustration and could > easily slow our progress if we try to fully incorporate the scope > IPTV delivery over a gateway with all the nuts and bolts would entail. > > -KE > > ________________________________ > > From: Hemant Singh (shemant) [mailto:shemant@cisco.com] > Sent: Tue 6/16/2009 8:43 AM > To: Erichsen, Kirk; Iljitsch van Beijnum > Cc: homegate@ietf.org; Greg Shepherd; Leonard Giuliano > Subject: RE: [homegate] Homegate and Multicast > > > > Some more thought has to be given to video over WiF because WiFi spans > my neighbor's home too and if the home router is not well secured and > managed, my video over WiFi goes to the neighbor's home as well. The > video delivery has to be planned too because if cable operators send > broadcast quality TV video to a home, the video channel is encrypted > and > theft safe. Such encryption mechanisms may not exist with IPTV or > local > video running in home including over wireless. > > Hemant > > > P Go Green! Print this email only when necessary. Thank you for > helping Time Warner Cable be environmentally responsible. > > > -----Original Message----- > From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On > Behalf Of Erichsen, Kirk > Sent: Tuesday, June 16, 2009 10:35 AM > To: Iljitsch van Beijnum > Cc: homegate@ietf.org; Greg Shepherd; Leonard Giuliano > Subject: Re: [homegate] Homegate and Multicast > > I haven't heard that. Is that a "should work" but doesn't due to > common > flaws in implementation, or "cannot work" because of a flaw in the > WiFi > specs? It would be out of scope if it's a question of the WiFi spec. > > -KE > > > > This E-mail and any of its attachments may contain Time Warner > Cable proprietary information, which is privileged, confidential, > or subject to copyright belonging to Time Warner Cable. This E-mail > is intended solely for the use of the individual or entity to which > it is addressed. If you are not the intended recipient of this > E-mail, you are hereby notified that any dissemination, > distribution, copying, or action taken in relation to the contents > of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate > From kirk.erichsen@twcable.com Tue Jun 16 09:44:54 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 3D6463A6AC1 for ; Tue, 16 Jun 2009 09:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 HLJmACZ-IJBL for ; Tue, 16 Jun 2009 09:44:53 -0700 (PDT) Received: from pblpas02.twcable.com (pblpas02.twcable.com [204.235.121.150]) by core3.amsl.com (Postfix) with ESMTP id 347633A694E for ; Tue, 16 Jun 2009 09:44:52 -0700 (PDT) X-SENDER-IP: 10.157.247.211 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,230,1243828800"; d="scan'208";a="422788979" Received: from unknown (HELO prvpmailconn1.corp.twcable.com) ([10.157.247.211]) by pblpas02.twcable.com with ESMTP; 16 Jun 2009 12:44:48 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn1.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 12:44:48 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Jun 2009 12:42:50 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Jumbo frames thread-index: AcnumqibGqhHNb7oRmWQpcHxRIu5PAABtQG1 References: <09061608192773.8189d.1310962750@oregon.uoregon.edu> From: "Erichsen, Kirk" To: , X-OriginalArrivalTime: 16 Jun 2009 16:44:48.0210 (UTC) FILETIME=[C2CC8B20:01C9EEA1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: Re: [homegate] Jumbo frames 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, 16 Jun 2009 16:44:54 -0000 RE9DU0lTIDMuMCBzdGlsbCB1c2VzIDE1MTggb2N0ZXQgZnJhbWluZywgbm8ganVtYm8gc3VwcG9y dC4gV2l0aG91dCBnaXZpbmcgb3V0IGFsbCB0aGUgc2VjcmV0cywgc3BlZWQgYm9vc3QgaXMgYSB0 b2tlbiBidWNrZXQgc2NoZW1lIHdoaWNoIGlzIHN1cHBsZW1lbnRlZCB3aXRoIFBDTU0gZHluYW1p YyBnYXRlIGNvbnRyb2wuIFRoZSBib29zdCBjb21lcyBmcm9tIGEgZGlmZmVyZW50IHN1Yi1sYXll ciB0aGFuIHRoZSBvbmUgeW91IG1heSBiZSB0aGlua2luZyBvZi4gIAoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KCkZyb206IGhvbWVnYXRlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo YWxmIG9mIEpvZSBTdCBTYXV2ZXIKU2VudDogVHVlIDYvMTYvMjAwOSA5OjE5IEFNClRvOiBob21l Z2F0ZUBpZXRmLm9yZwpTdWJqZWN0OiBbaG9tZWdhdGVdIEp1bWJvIGZyYW1lcwoKCgpIaSwKCkFz IERPQ1NJUyAzLjAgYW5kIHRoZSBsaWtlIGJvb3N0IHRoZSBzcGVlZHMgd2hpY2ggd2lsbCBhdmFp bGFibGUgdG8KY29uc3VtZXJzLCBJJ2QgbG92ZSB0byBzZWUgaG9tZSBnYXRld2F5IGRldmljZXMg c3VwcG9ydCA5SyBNVFVzIChha2EKImp1bWJvIGZyYW1lcyIpLiBXaXRob3V0IGhvbWUgZ2F0ZXdh eSBzdXBwb3J0IGZvciBqdW1ibyBmcmFtZXMsIG91cgpjaGFuY2VzIG9mIGV2ZXIgZ2V0dGluZyB0 aGUgSW50ZXJuZXQncyBlbmQtdG8tZW5kIE1UVSB0byBiZSBncmVhdGVyCnRoYW4gMTUwMCBieXRl cywgYW5kIHRodXMgb3VyIGNoYW5jZXMgb2YgYnJvYWRseSBpbXByb3Zpbmcgc2luZ2xlCnN0cmVh bSBUQ1AgcGVyZm9ybWFuY2UsIGFwcGVhciByYXRoZXIgYmxlYWsuCgpJJ2QgYWxzbyBub3RlIHRo YXQganVtYm8gZnJhbWUgc3VwcG9ydCBpcyB0aGUgY2xhc3NpYyAidGhpcmQgbGVnIiBvZiB0aGUK ImFkdmFuY2VkIHByb3RvY29sIHRyaWFkLCIgdGhlIG90aGVyIHR3byBiaXRzIGJlaW5nIElQdjYg YW5kIElQIG11bHRpY2FzdC4KKGUuZy4sIHNlZSBodHRwOi8vZGMtMi5ncm5vYy5pdS5lZHUvdm4v YW5hbHlzaXMvY29ubmVjdG9yLXRlY2guaHRtbCApCgpJdCB3b3VsZCBiZSBhIHNoYW1lIHRvIGRv IHR3byBvZiB0aGUgdGhyZWUsIG9ubHkgdG8gbWlzcyB0aGUgdGhpcmQuCgpSZWdhcmRzLAoKSm9l IFN0IFNhdXZlciAoam9lQG9yZWdvbi51b3JlZ29uLmVkdSkKaHR0cDovL3d3dy51b3JlZ29uLmVk dS9+am9lLwpEaXNjbGFpbWVyOiBhbGwgb3BpbmlvbnMgZXhwcmVzc2VkIGFyZSBzdHJpY3RseSBt eSBvd24KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KaG9t ZWdhdGUgbWFpbGluZyBsaXN0CmhvbWVnYXRlQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaG9tZWdhdGUKCgoKUCBHbyBHcmVlbiEgUHJpbnQgdGhpcyBlbWFp bCBvbmx5IHdoZW4gbmVjZXNzYXJ5LiBUaGFuayB5b3UgZm9yIGhlbHBpbmcgVGltZSBXYXJuZXIg Q2FibGUgYmUgZW52aXJvbm1lbnRhbGx5IHJlc3BvbnNpYmxlLgogCiAKVGhpcyBFLW1haWwgYW5k IGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIKQ2FibGUgcHJv cHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwK b3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBU aGlzIEUtbWFpbAppcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwgb3IgZW50aXR5IHRvIHdoaWNoCml0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzCkUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZp ZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwKZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rp b24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzCm9mIGFuZCBhdHRhY2htZW50cyB0 byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUKdW5sYXdmdWwu IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 CnRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2lu YWwgYW5kIGFueQpjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuCg== From mbaugher@cisco.com Tue Jun 16 10:08: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 6236028C18E for ; Tue, 16 Jun 2009 10:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 5sgRA6Zaf1c2 for ; Tue, 16 Jun 2009 10:08:38 -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 49D113A6DA0 for ; Tue, 16 Jun 2009 10:08:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,230,1243814400"; d="scan'208";a="176944455" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 16 Jun 2009 17:08:49 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5GH8nHx014670; Tue, 16 Jun 2009 10:08:49 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n5GH8ne0023302; Tue, 16 Jun 2009 17:08:49 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, 16 Jun 2009 10:08:49 -0700 Received: from sjc-mbaugher-8712.cisco.com ([10.19.93.35]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 10:08:48 -0700 Message-Id: <70DE1C24-910C-4102-AF0D-94A24AAFA6A7@cisco.com> From: Mark Baugher To: Marshall Eubanks In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 16 Jun 2009 10:08:48 -0700 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Jun 2009 17:08:48.0739 (UTC) FILETIME=[1D6BD330:01C9EEA5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2888; t=1245172129; x=1246036129; 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=20and=20Multicast |Sender:=20; bh=oxb1jA8lzFL3PT5yFagY6eBzd5HF4rPhTabq9jsi8U8=; b=nAOpwmyBNRr7ep7RCJ/8o8D7x3e9ylJYJipjX8d4CPnKwB5NRC51Lj3eUq Ds2QkW+diG8fBvZg9Xprt4gSz6rCyPrpUPiHv64+h1Cqd0Qt+35wUDhwCwzb 5bf4y7RACb; Authentication-Results: sj-dkim-3; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Greg Shepherd , homegate@ietf.org, Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 17:08:39 -0000 I don't think it's true that multicast video is becoming common on home networks since it doesn't work too well on many home networks. It's really useful for control traffic, for things like discovery. Mark On 16/06/2009, at 3:27 AM, Marshall Eubanks wrote: > I have been wading through all of this, and was surprised to see no > mention > of multicast in > > > > > A blow to the first round of multicast deployments (almost a decade > ago now!) was the inability of > most of the then current home routers to support things such as IGMP > proxying. If the IETF is going to specify a > new effort to specify home gateways, then in my opinion this > specification should support at least SSM multicast reception > properly. > > Supporting multicast in the home environment is becoming common in > video deployments, but the end user typically > does not see this on their home network and there is very little > multicast support to the end user (instead of just to their set top > boxes). However, > the trend in the industry is towards merging the reception of > Internet-transported video and provider-transported video into > common hardware platforms. Internet video > would certainly benefit from support of multicast reception, and > there seems to be a recognition of that in the industry. The > CableLabs document "IPv4 and IPv6 eRouter Specification" > http://www.cablelabs.com/specifications/CM-SP-eRouter-I03-070518.pdf > > states as their goal : > > The specification defines a) CPE provisioning with IPv4 and IPv6 > addresses, b) IPv4 data forwarding with NAPT > and IPv6 data forwarding, c) Ability to forward IP Multicast traffic > and d) Preserving IP QoS markings on IP data > to and from the CPE devices. > > and includes sections on IGMP proxing as well as v4 and v6 multicast > support. The other two documents mentioned as > parallel efforts : > > Broadband Forum TR-124 defines a set of modular functional > requirements for broadband residential gateways:http://www.broadband-forum.org/technical/download/TR-124.pdf > . > > The Home Gateway Initiative also has a Home Gateway Requirements: > Residential Profile document:http://www.homegatewayinitiative.org/publis/HGI_V1.01_Residential.pdf > . > > also include multicast support. > > So, while I support this effort, I would like to see multicast SSM > added to Theme 1. > > Regards > Marshall > > P.S. Can I also suggest that what is basically a text file BOF > charter should be served as a text file in the usual > fashion ? > > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate From joe@grey.uoregon.edu Tue Jun 16 10:20: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 4BB663A6D8A for ; Tue, 16 Jun 2009 10:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 9KTJ4huAf1Be for ; Tue, 16 Jun 2009 10:20:38 -0700 (PDT) Received: from grey.uoregon.edu (grey.uoregon.edu [128.223.214.89]) by core3.amsl.com (Postfix) with SMTP id 771323A6A61 for ; Tue, 16 Jun 2009 10:20:38 -0700 (PDT) Received: by grey.uoregon.edu; Tue, 16 Jun 2009 10:18:12 -0700 Date: Tue, 16 Jun 2009 10:18:12 -0700 From: Joe St Sauver To: kirk.erichsen@twcable.com Message-Id: <09061610181221.8189d.1311610534@oregon.uoregon.edu> Cc: homegate@ietf.org Subject: Re: [homegate] Jumbo frames X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: joe@oregon.uoregon.edu List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:20:39 -0000 Kirk mentioned: #DOCSIS 3.0 still uses 1518 octet framing, no jumbo support. Without giving #out all the secrets, speed boost is a token bucket scheme which is #supplemented with PCMM dynamic gate control. The boost comes from a #different sub-layer than the one you may be thinking of. Stipulated (virtually all home connectivity is still 1.5K MTU); I'd like to make sure we're correctly positioned for future revs where that may no longer be the case for all least some subset of home connectivity. If not, some years down the line we'll hear, "Well, we could take the WAN transport to 9K frames, but none of the home gateways will support it," just as the comment now is/might hypothetically be, "Well, we could take the home gateways to 9K framess, but none of the WAN transport supports it." Classic chicken/egg deployment deadlock I suppose. Nonetheless, if the home gateway device is conceptualized as including a multiport 10/100/1000 switch as well as whatever else may be present, sure like to at least see at least optional jumbo frame support for those integrated gig-capable ports. Regards, Joe From tme@americafree.tv Tue Jun 16 10:23: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 05ADE3A6BEF for ; Tue, 16 Jun 2009 10:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-0.081, 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 rbZsvx0Zbx-A for ; Tue, 16 Jun 2009 10:23:01 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id A491B3A6A61 for ; Tue, 16 Jun 2009 10:23:01 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id ABCEC407739A; Tue, 16 Jun 2009 13:23:12 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Mark Baugher In-Reply-To: <70DE1C24-910C-4102-AF0D-94A24AAFA6A7@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 13:23:12 -0400 References: <70DE1C24-910C-4102-AF0D-94A24AAFA6A7@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: Greg Shepherd , homegate@ietf.org, Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 17:23:03 -0000 On Jun 16, 2009, at 1:08 PM, Mark Baugher wrote: > I don't think it's true that multicast video is becoming common on > home networks I didn't say that. I said that "multicast in the home environment is becoming common in video deployments." Multicast is indeed common in IPTV and "switched digital video", at least outside of the US, but it is generally not offered to the user directly, at least in the systems I am familiar with. (Some of the University IPTV deployments don't separate the video and user networks, and so do offer multicast to the end user.) Part of the reason for that is the inability of NATs and gateways to support it, which this effort could do something about. It would seem to me to be logical for the Homegate to support IPTV standards based on IP. Whether that requires extra work on the part of the gateway is what's not clear, at least to me. Regards Marshall > since it doesn't work too well on many home networks. It's really > useful for control traffic, for things like discovery. > > Mark > On 16/06/2009, at 3:27 AM, Marshall Eubanks wrote: > >> I have been wading through all of this, and was surprised to see no >> mention >> of multicast in >> >> > > >> >> A blow to the first round of multicast deployments (almost a decade >> ago now!) was the inability of >> most of the then current home routers to support things such as >> IGMP proxying. If the IETF is going to specify a >> new effort to specify home gateways, then in my opinion this >> specification should support at least SSM multicast reception >> properly. >> >> Supporting multicast in the home environment is becoming common in >> video deployments, but the end user typically >> does not see this on their home network and there is very little >> multicast support to the end user (instead of just to their set top >> boxes). However, >> the trend in the industry is towards merging the reception of >> Internet-transported video and provider-transported video into >> common hardware platforms. Internet video >> would certainly benefit from support of multicast reception, and >> there seems to be a recognition of that in the industry. The >> CableLabs document "IPv4 and IPv6 eRouter Specification" >> http://www.cablelabs.com/specifications/CM-SP-eRouter-I03-070518.pdf >> >> states as their goal : >> >> The specification defines a) CPE provisioning with IPv4 and IPv6 >> addresses, b) IPv4 data forwarding with NAPT >> and IPv6 data forwarding, c) Ability to forward IP Multicast >> traffic and d) Preserving IP QoS markings on IP data >> to and from the CPE devices. >> >> and includes sections on IGMP proxing as well as v4 and v6 >> multicast support. The other two documents mentioned as >> parallel efforts : >> >> Broadband Forum TR-124 defines a set of modular functional >> requirements for broadband residential gateways:http://www.broadband-forum.org/technical/download/TR-124.pdf >> . >> >> The Home Gateway Initiative also has a Home Gateway Requirements: >> Residential Profile document:http://www.homegatewayinitiative.org/publis/HGI_V1.01_Residential.pdf >> . >> >> also include multicast support. >> >> So, while I support this effort, I would like to see multicast SSM >> added to Theme 1. >> >> Regards >> Marshall >> >> P.S. Can I also suggest that what is basically a text file BOF >> charter should be served as a text file in the usual >> fashion ? >> >> _______________________________________________ >> homegate mailing list >> homegate@ietf.org >> https://www.ietf.org/mailman/listinfo/homegate > > From kirk.erichsen@twcable.com Tue Jun 16 10:24: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 CF50D28C19A for ; Tue, 16 Jun 2009 10:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 aLvHQXm1UQTW for ; Tue, 16 Jun 2009 10:24:43 -0700 (PDT) Received: from pblpas02.twcable.com (pblpas02.twcable.com [204.235.121.150]) by core3.amsl.com (Postfix) with ESMTP id DD6FC28C193 for ; Tue, 16 Jun 2009 10:24:42 -0700 (PDT) X-SENDER-IP: 10.157.247.211 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,230,1243828800"; d="scan'208";a="422803135" Received: from unknown (HELO prvpmailconn1.corp.twcable.com) ([10.157.247.211]) by pblpas02.twcable.com with ESMTP; 16 Jun 2009 13:24:51 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn1.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 13:24:51 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Jun 2009 13:23:33 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Jumbo frames thread-index: AcnupsvywyDbhDltTdikd4vGk0THNAAAGD6n References: <09061610181221.8189d.1311610534@oregon.uoregon.edu> From: "Erichsen, Kirk" To: X-OriginalArrivalTime: 16 Jun 2009 17:24:51.0788 (UTC) FILETIME=[5B7170C0:01C9EEA7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: homegate@ietf.org Subject: Re: [homegate] Jumbo frames 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, 16 Jun 2009 17:24:43 -0000 UG9pbnQgdGFrZW4gb24geW91ciBjaGlja2VuIGFuZCBlZ2cgcHJvYmxlbS4gQnV0IGlmIHlvdSBh cmUgZ29pbmcgdG8gZG8ganVtYm8gZnJhbWVzLCB3aHkgc3RvcCBhdCA5Sz8gRm9yIGEgdmVuZG9y IGJ1aWxkaW5nIGEgZ2F0ZXdheSB3aXRoIG9mZiB0aGUgc2hlbGYgY29tcG9uZW50cywgMTJLIGNh cGFiaWxpdHkgaXMgcmVhc29uYWJseSBjb21tb24sIHRob3VnaCBpdCBtYXkgYmUgbG9ja2VkIG91 dCBpbiB0aGUgc29mdHdhcmUgYnVpbGQgdGhhdCBvcGVyYXRlcyB0aGUgTUFDLgogCi1LRQoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkZyb206IEpvZSBTdCBTYXV2ZXIgW21haWx0 bzpqb2VAb3JlZ29uLnVvcmVnb24uZWR1XQpTZW50OiBUdWUgNi8xNi8yMDA5IDExOjE4IEFNClRv OiBFcmljaHNlbiwgS2lyawpDYzogaG9tZWdhdGVAaWV0Zi5vcmcKU3ViamVjdDogUkU6IFtob21l Z2F0ZV0gSnVtYm8gZnJhbWVzCgoKCktpcmsgbWVudGlvbmVkOgoKI0RPQ1NJUyAzLjAgc3RpbGwg dXNlcyAxNTE4IG9jdGV0IGZyYW1pbmcsIG5vIGp1bWJvIHN1cHBvcnQuIFdpdGhvdXQgZ2l2aW5n CiNvdXQgYWxsIHRoZSBzZWNyZXRzLCBzcGVlZCBib29zdCBpcyBhIHRva2VuIGJ1Y2tldCBzY2hl bWUgd2hpY2ggaXMKI3N1cHBsZW1lbnRlZCB3aXRoIFBDTU0gZHluYW1pYyBnYXRlIGNvbnRyb2wu IFRoZSBib29zdCBjb21lcyBmcm9tIGEKI2RpZmZlcmVudCBzdWItbGF5ZXIgdGhhbiB0aGUgb25l IHlvdSBtYXkgYmUgdGhpbmtpbmcgb2YuCgpTdGlwdWxhdGVkICh2aXJ0dWFsbHkgYWxsIGhvbWUg Y29ubmVjdGl2aXR5IGlzIHN0aWxsIDEuNUsgTVRVKTsgSSdkIGxpa2UKdG8gbWFrZSBzdXJlIHdl J3JlIGNvcnJlY3RseSBwb3NpdGlvbmVkIGZvciBmdXR1cmUgcmV2cyB3aGVyZSB0aGF0IG1heQpu byBsb25nZXIgYmUgdGhlIGNhc2UgZm9yIGFsbCBsZWFzdCBzb21lIHN1YnNldCBvZiBob21lIGNv bm5lY3Rpdml0eS4KCklmIG5vdCwgc29tZSB5ZWFycyBkb3duIHRoZSBsaW5lIHdlJ2xsIGhlYXIs ICJXZWxsLCB3ZSBjb3VsZCB0YWtlIHRoZSBXQU4KdHJhbnNwb3J0IHRvIDlLIGZyYW1lcywgYnV0 IG5vbmUgb2YgdGhlIGhvbWUgZ2F0ZXdheXMgd2lsbCBzdXBwb3J0IGl0LCIKanVzdCBhcyB0aGUg Y29tbWVudCBub3cgaXMvbWlnaHQgaHlwb3RoZXRpY2FsbHkgYmUsICJXZWxsLCB3ZSBjb3VsZCB0 YWtlCnRoZSBob21lIGdhdGV3YXlzIHRvIDlLIGZyYW1lc3MsIGJ1dCBub25lIG9mIHRoZSBXQU4g dHJhbnNwb3J0IHN1cHBvcnRzCml0LiIgQ2xhc3NpYyBjaGlja2VuL2VnZyBkZXBsb3ltZW50IGRl YWRsb2NrIEkgc3VwcG9zZS4KCk5vbmV0aGVsZXNzLCBpZiB0aGUgaG9tZSBnYXRld2F5IGRldmlj ZSBpcyBjb25jZXB0dWFsaXplZCBhcyBpbmNsdWRpbmcKYSBtdWx0aXBvcnQgMTAvMTAwLzEwMDAg c3dpdGNoIGFzIHdlbGwgYXMgd2hhdGV2ZXIgZWxzZSBtYXkgYmUgcHJlc2VudCwKc3VyZSBsaWtl IHRvIGF0IGxlYXN0IHNlZSBhdCBsZWFzdCBvcHRpb25hbCBqdW1ibyBmcmFtZSBzdXBwb3J0IGZv cgp0aG9zZSBpbnRlZ3JhdGVkIGdpZy1jYXBhYmxlIHBvcnRzLgoKUmVnYXJkcywKCkpvZQoKCgpQ IEdvIEdyZWVuISBQcmludCB0aGlzIGVtYWlsIG9ubHkgd2hlbiBuZWNlc3NhcnkuIFRoYW5rIHlv dSBmb3IgaGVscGluZyBUaW1lIFdhcm5lciBDYWJsZSBiZSBlbnZpcm9ubWVudGFsbHkgcmVzcG9u c2libGUuCiAKIApUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBUaW1lIFdhcm5lcgpDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMg cHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLApvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdp bmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsCmlzIGludGVuZGVkIHNvbGVseSBm b3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2gKaXQgaXMgYWRk cmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMKRS1t YWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLApkaXN0 cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29u dGVudHMKb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQgYW5kIG1heSBiZQp1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkKdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVy bWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55CmNvcHkgb2YgdGhpcyBFLW1haWwg YW5kIGFueSBwcmludG91dC4K From tme@americafree.tv Tue Jun 16 10:27:30 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 231F43A68BC for ; Tue, 16 Jun 2009 10:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.678 X-Spam-Level: X-Spam-Status: No, score=-2.678 tagged_above=-999 required=5 tests=[AWL=-0.079, 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 veY8ytRs0NES for ; Tue, 16 Jun 2009 10:27:25 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id B6EAF3A6D9F for ; Tue, 16 Jun 2009 10:27:24 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id B1A644077567; Tue, 16 Jun 2009 13:27:26 -0400 (EDT) Message-Id: <644FF747-797D-434B-8A07-20D84F4FDC4A@americafree.tv> From: Marshall Eubanks To: joe@oregon.uoregon.edu In-Reply-To: <09061610181221.8189d.1311610534@oregon.uoregon.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 13:27:26 -0400 References: <09061610181221.8189d.1311610534@oregon.uoregon.edu> X-Mailer: Apple Mail (2.935.3) Cc: homegate@ietf.org Subject: Re: [homegate] Jumbo frames 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, 16 Jun 2009 17:27:30 -0000 Dear Joe; Is there a definition yet for Jumbo frames ? I thought that IEEE had said no to this. Without a SDO-supported definition, I think that wide deployment and interoperation are problematic. Your own web site, http://darkwing.uoregon.edu/~joe/jumbo-clean-gear.html shows what a mess this is in the absence of a standard. Regards Marshall On Jun 16, 2009, at 1:18 PM, Joe St Sauver wrote: > Kirk mentioned: > > #DOCSIS 3.0 still uses 1518 octet framing, no jumbo support. Without > giving > #out all the secrets, speed boost is a token bucket scheme which is > #supplemented with PCMM dynamic gate control. The boost comes from a > #different sub-layer than the one you may be thinking of. > > Stipulated (virtually all home connectivity is still 1.5K MTU); I'd > like > to make sure we're correctly positioned for future revs where that may > no longer be the case for all least some subset of home connectivity. > > If not, some years down the line we'll hear, "Well, we could take > the WAN > transport to 9K frames, but none of the home gateways will support > it," > just as the comment now is/might hypothetically be, "Well, we could > take > the home gateways to 9K framess, but none of the WAN transport > supports > it." Classic chicken/egg deployment deadlock I suppose. > > Nonetheless, if the home gateway device is conceptualized as including > a multiport 10/100/1000 switch as well as whatever else may be > present, > sure like to at least see at least optional jumbo frame support for > those integrated gig-capable ports. > > Regards, > > Joe > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate > From mbaugher@cisco.com Tue Jun 16 10:30: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 4123E28C194 for ; Tue, 16 Jun 2009 10:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 CfC4INcLoMcG for ; Tue, 16 Jun 2009 10:30:22 -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 A70903A6D77 for ; Tue, 16 Jun 2009 10:30:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,230,1243814400"; d="scan'208";a="325154817" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 16 Jun 2009 17:30:22 +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 n5GHUM5N028177; Tue, 16 Jun 2009 10:30:22 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n5GHUMZw022962; Tue, 16 Jun 2009 17:30:22 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, 16 Jun 2009 10:30:22 -0700 Received: from sjc-mbaugher-8712.cisco.com ([10.19.93.35]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 10:30:21 -0700 Message-Id: From: Mark Baugher To: Marshall Eubanks In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 16 Jun 2009 10:30:20 -0700 References: <70DE1C24-910C-4102-AF0D-94A24AAFA6A7@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Jun 2009 17:30:21.0465 (UTC) FILETIME=[1FF22890:01C9EEA8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4158; t=1245173422; x=1246037422; c=relaxed/simple; s=sjdkim2002; 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=20and=20Multicast |Sender:=20; bh=ZRfj8cxB+601gKmG6KgNnNECTu1WCZxS4Zqpg3CKbk8=; b=tmcHPNjbvar+TjTADoRDks7D4GYj9Rq6arbLWN7MMSnYrUUoYgBTXgGhUe X53SG2pDvCH+j64HmBm2tjHnxvlwf63mBJoDUh4TfbAEkfOBQorvSX8Mfiyp z7RTwuT7m9; Authentication-Results: sj-dkim-2; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Greg Shepherd , homegate@ietf.org, Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 17:30:24 -0000 IPTV or not, the common use of multicast on home networks is for control not video, and it's not clear to me that this can be fixed in the gateway. Mark On 16/06/2009, at 10:23 AM, Marshall Eubanks wrote: > > On Jun 16, 2009, at 1:08 PM, Mark Baugher wrote: > >> I don't think it's true that multicast video is becoming common on >> home networks > > I didn't say that. I said that "multicast in the home environment is > becoming common in video deployments." > Multicast is indeed common in IPTV and "switched digital video", at > least outside of the US, but it is generally > not offered to the user directly, at least in the systems I am > familiar with. (Some of the University IPTV deployments don't > separate the video and user networks, and so do offer multicast to > the end user.) Part of the > reason for that is the inability of NATs and gateways to support it, > which this effort could do something about. > > It would seem to me to be logical for the Homegate to support IPTV > standards based on IP. Whether that requires extra work on the part > of the gateway is what's not clear, at least to me. > > Regards > Marshall > >> since it doesn't work too well on many home networks. It's really >> useful for control traffic, for things like discovery. >> >> Mark >> On 16/06/2009, at 3:27 AM, Marshall Eubanks wrote: >> >>> I have been wading through all of this, and was surprised to see >>> no mention >>> of multicast in >>> >>> >> > >>> >>> A blow to the first round of multicast deployments (almost a >>> decade ago now!) was the inability of >>> most of the then current home routers to support things such as >>> IGMP proxying. If the IETF is going to specify a >>> new effort to specify home gateways, then in my opinion this >>> specification should support at least SSM multicast reception >>> properly. >>> >>> Supporting multicast in the home environment is becoming common in >>> video deployments, but the end user typically >>> does not see this on their home network and there is very little >>> multicast support to the end user (instead of just to their set >>> top boxes). However, >>> the trend in the industry is towards merging the reception of >>> Internet-transported video and provider-transported video into >>> common hardware platforms. Internet video >>> would certainly benefit from support of multicast reception, and >>> there seems to be a recognition of that in the industry. The >>> CableLabs document "IPv4 and IPv6 eRouter Specification" >>> http://www.cablelabs.com/specifications/CM-SP-eRouter-I03-070518.pdf >>> >>> states as their goal : >>> >>> The specification defines a) CPE provisioning with IPv4 and IPv6 >>> addresses, b) IPv4 data forwarding with NAPT >>> and IPv6 data forwarding, c) Ability to forward IP Multicast >>> traffic and d) Preserving IP QoS markings on IP data >>> to and from the CPE devices. >>> >>> and includes sections on IGMP proxing as well as v4 and v6 >>> multicast support. The other two documents mentioned as >>> parallel efforts : >>> >>> Broadband Forum TR-124 defines a set of modular functional >>> requirements for broadband residential gateways:http://www.broadband-forum.org/technical/download/TR-124.pdf >>> . >>> >>> The Home Gateway Initiative also has a Home Gateway Requirements: >>> Residential Profile document:http://www.homegatewayinitiative.org/publis/HGI_V1.01_Residential.pdf >>> . >>> >>> also include multicast support. >>> >>> So, while I support this effort, I would like to see multicast SSM >>> added to Theme 1. >>> >>> Regards >>> Marshall >>> >>> P.S. Can I also suggest that what is basically a text file BOF >>> charter should be served as a text file in the usual >>> fashion ? >>> >>> _______________________________________________ >>> homegate mailing list >>> homegate@ietf.org >>> https://www.ietf.org/mailman/listinfo/homegate >> >> > From jhw@apple.com Tue Jun 16 10:32: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 E8A8D28C19D for ; Tue, 16 Jun 2009 10:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, 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 A54+cAPecN6J for ; Tue, 16 Jun 2009 10:32:20 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id E92453A6BDA for ; Tue, 16 Jun 2009 10:32:20 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id 53304689E6B1 for ; Tue, 16 Jun 2009 10:32:19 -0700 (PDT) Received: from relay15.apple.com (unknown [127.0.0.1]) by relay15.apple.com (Symantec Brightmail Gateway) with ESMTP id 439C95A0002 for ; Tue, 16 Jun 2009 10:32:19 -0700 (PDT) X-AuditID: 11807136-a6cfdbb00000447e-d9-4a37d723257d Received: from il0602f-dhcp237.apple.com (il0602f-dhcp237.apple.com [17.206.50.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay15.apple.com (Apple SCV relay) with ESMTP id 225AA558003 for ; Tue, 16 Jun 2009 10:32:19 -0700 (PDT) Message-Id: <54A266FB-B81A-4C3F-8C7D-56CBDB6180DA@apple.com> From: james woodyatt To: homegate@ietf.org In-Reply-To: <70DE1C24-910C-4102-AF0D-94A24AAFA6A7@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 10:32:18 -0700 References: <70DE1C24-910C-4102-AF0D-94A24AAFA6A7@cisco.com> X-Mailer: Apple Mail (2.935.3) X-Brightmail-Tracker: AAAAAA== Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 17:32:22 -0000 On Jun 16, 2009, at 10:08, Mark Baugher wrote: > I don't think it's true that multicast video is becoming common on > home networks since it doesn't work too well on many home networks. > It's really useful for control traffic, for things like discovery. It would be very nice if people would stop assuming that the only interesting application of non-local scope multicast is to send live A/ V content efficiently. Multicast is really only worth thinking about for A/V transport when the content is valuable only when it's *live*, because otherwise store-and-forward is more efficient, and it flows much better over unicast transports, e.g. TCP, SCTP, etc. The truth is we really don't know what the interesting applications of non-local scope multicast will be until we have an Internet that can route it. Sadly, we don't have one yet, and one of the reasons for that is that residential gateways, by and large, don't implement multicast routing protocols. Because residential service providers won't route multicast transit. The IPv6Ready phase-2 certification doesn't even yet require support for a multicast routing protocol. I don't actually think multicast is a pressing need right now or in the near future. I see it becoming a pressing need in the foreseeable but somewhat distant future, when we have residential networks with zero-configuration routed subnetworks and we need non-local scope multicast for unmanaged service discovery, among other things. -- james woodyatt member of technical staff, communications engineering From joe@grey.uoregon.edu Tue Jun 16 10:38:18 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 168F63A6D86 for ; Tue, 16 Jun 2009 10:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 j2klQdk7-M47 for ; Tue, 16 Jun 2009 10:38:16 -0700 (PDT) Received: from grey.uoregon.edu (grey.uoregon.edu [128.223.214.89]) by core3.amsl.com (Postfix) with SMTP id 0D1073A68BC for ; Tue, 16 Jun 2009 10:38:16 -0700 (PDT) Received: by grey.uoregon.edu; Tue, 16 Jun 2009 10:36:05 -0700 Date: Tue, 16 Jun 2009 10:36:05 -0700 From: Joe St Sauver To: kirk.erichsen@twcable.com Message-Id: <09061610360508.8189d.1311731165@oregon.uoregon.edu> Cc: homegate@ietf.org Subject: Re: [homegate] Jumbo frames X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: joe@oregon.uoregon.edu List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:38:18 -0000 Kirk commented: #Point taken on your chicken and egg problem. But if you are going to do #jumbo frames, why stop at 9K? For a vendor building a gateway with off #the shelf components, 12K capability is reasonably common, though it #may be locked out in the software build that operates the MAC. Indeed, my colleague Matt Mathis at PSC makes a persuasive case for what some call "super jumbo frames" for very high speed links, (e.g., see http://staff.psc.edu/mathis/MTU/#pushing ) however my MTU ambitions are a bit more incremental. No arguments with Matt's fine work, I'd just get where he wants to go more gradually. (And 9K is a value that's currently widely supported on at least much of the wide area R&E infrastructure, so that's a target that I'd be most comfortable with for the time being) Regards, Joe From gjshep@gmail.com Tue Jun 16 07:19: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 CAC3C3A6CFC for ; Tue, 16 Jun 2009 07:19:21 -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 qErctvZy-eyS for ; Tue, 16 Jun 2009 07:19:21 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id E559E3A69C4 for ; Tue, 16 Jun 2009 07:19:20 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so2115994ywj.49 for ; Tue, 16 Jun 2009 07:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eRV2h/jsEwzJI3S/oPWOAKuAFqBbvl/bIlZExVmXUiU=; b=J6OQRdPSCxZAwYY+KtKn0ViKqXhZfolVIEm6VnO1HXiQE07TKMu+VxmaVqsM/ocYoV HeUd4scnvpAGYAm1VEA6DXCBY/mly7o3qxbLMwa/psJO5DTv/PpAbQErhi5R3xi7DMbo +UEq48wOwsndjmZRt98fqIxxkwHvc6Nyuf0fI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=gUPcQeGB47utemK0s4HAYlyvWvQ0hWkDLvZl1y3NezJoCqWqvserfRTDYfw+o+rikA vUigF5aRh4B7EJ9kapQDuJIjveqecnmdWffT4Cwoq68R+PytrPhFQ9vjlETKLC7wf8XJ MOC02mepXcWM4o2Z4m2eSHMsTcZ+hZLIcu+yw= MIME-Version: 1.0 Received: by 10.100.11.1 with SMTP id 1mr10573519ank.104.1245161875182; Tue, 16 Jun 2009 07:17:55 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Jun 2009 07:17:55 -0700 Message-ID: <38c19b540906160717od128766gf73d6fbbe1a0ce74@mail.gmail.com> From: Greg Shepherd To: Iljitsch van Beijnum Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 16 Jun 2009 11:10:20 -0700 Cc: homegate@ietf.org, Leonard Giuliano Subject: Re: [homegate] Homegate and Multicast X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 14:19:21 -0000 On Tue, Jun 16, 2009 at 7:11 AM, Iljitsch van Beijnum wrote: > On 16 jun 2009, at 16:02, Erichsen, Kirk wrote: > >> While IP video content delivery is an emerging technology with many >> advocates and interested parties, it can be difficult to sort through which >> use cases are realistic and which are only exercises in theory. > > Speaking of that: multicast streaming doesn't work over wifi. A lot of home > gateways talk to the local hosts over wifi. How do we solve this? Perhaps AMT Relay/Gateway services could be incorporated into the home gateway. It could provide AMT tunnel services to the hosts over wifi, and additionally connect as a gateway to an upstream AMT relay in deployments where the multicast radius does not extend down to the home. http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast-09 Greg From jegoodwi@cisco.com Tue Jun 16 06:06: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 CC2623A689E for ; Tue, 16 Jun 2009 06:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 YfydrBCuPHTr for ; Tue, 16 Jun 2009 06:06:56 -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 B5B963A6A2E for ; Tue, 16 Jun 2009 06:06:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,228,1243814400"; d="scan'208";a="324953949" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 16 Jun 2009 13:05:32 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5GD5W3b003652; Tue, 16 Jun 2009 06:05:32 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5GD5WFC009428; Tue, 16 Jun 2009 13:05:32 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 06:05:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 06:05:49 -0700 Message-ID: <2AB1DCE354761449A2E270681CC0429808AF119C@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] PDF of BoF Proposal Thread-Index: Acnugyt+PunclETyTFyQTegi3QkFlQ== References: <922BA6F4-A3B6-46AD-8144-B8715E46F783@nokia.com><4A3182AE.9040508@swin.edu.au><4A31FCB3.7080607@unifr.ch><20090612133220.70c3094c.dgerow@afflictions.org><20090615133048.GA38531@shinkuro.com> From: "Jeff Goodwin (jegoodwi)" To: "Heather Kirksey" , X-OriginalArrivalTime: 16 Jun 2009 13:05:32.0338 (UTC) FILETIME=[2149C920:01C9EE83] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3366; t=1245157532; x=1246021532; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jegoodwi@cisco.com; z=From:=20=22Jeff=20Goodwin=20(jegoodwi)=22=20 |Subject:=20RE=3A=20[homegate]=20PDF=20of=20BoF=20Proposal |Sender:=20; bh=E/qNDBVSpmSzZBKVZptDiC6Gnd8yrgTpiY5nya19Y8M=; b=psDA9jjAcbXsTilJPfAgaGD4ve8p5LiGSKDNqK+eKF1z5rTumru/YqlUR3 rOgl5Mdup1HkO2LJRsx3YRXWPAoo/KmeVtEDDpKJ5dUEwb9QhKZe1LU6U0rx X0sJweZ8RS; Authentication-Results: sj-dkim-3; header.From=jegoodwi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Mailman-Approved-At: Tue, 16 Jun 2009 11:10:34 -0700 Subject: Re: [homegate] PDF of BoF Proposal 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, 16 Jun 2009 13:18:02 -0000 Heather, Andrew, For service providers (e.g., Telco's v.s. MSO's), it would be great to = have some standardization of management protocols as part of this = initiative. =20 The issue being that TR-069 is more Telco centric, and MSO's having more = SNMP centric or proprietary methods of handling XML based data models. We are seeing some sentiment from MSO's to use TR-069 related protocols = to handle statistics for example, where more proprietary methods for XML = or SNMP based methods of managing residential gateway functions is still = well engrained. It would be good to have involvement from someone at CableLabs. Best regards, Jeff -----Original Message----- From: Heather Kirksey [mailto:hkirksey@motive.com]=20 Sent: Monday, June 15, 2009 4:58 PM To: homegate@ietf.org Subject: Re: [homegate] PDF of BoF Proposal Andrew, If you're considering ISPs using this work to enforce requirements on = their vendors, it might be worth checking out some work that's already = gone on in this area: Broadband Forum TR-124 defines a set of modular functional requirements = for broadband residential gateways: = http://www.broadband-forum.org/technical/download/TR-124.pdf. The Home Gateway Initiative also has a Home Gateway Requirements: = Residential Profile document: = http://www.homegatewayinitiative.org/publis/HGI_V1.01_Residential.pdf. In addition, Broadband Forum has a work-in-progress document called = PD-192 that deals with the functional IPv6 requirements for gateways in = the home based on current operator plans for migration and deployment. = BBF was already planning to liaise the PD-192 document in the relatively = near future to get feedback on it. Thanks, Heather Heather Kirksey Motive Product Division Alcatel-Lucent hkirksey@motive.com +1.512.531.1126 (office) +1.512.917.7938 (mobile) =A0 -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On = Behalf Of Andrew Sullivan Sent: Monday, June 15, 2009 8:31 AM To: homegate@ietf.org Subject: Re: [homegate] PDF of BoF Proposal On Sat, Jun 13, 2009 at 08:40:42AM +0200, Lars Eggert wrote: > it's not clear that the consumer of this effort would be the end user = -=20 > few IETF specifications are. In my mind, this was mostly about giving=20 > guidelines to vendors and operators. > The IETF isn't doing standards certification, and there are good = reasons [[HRK]]=20 > for that. But nothing stops an outside entity to run a conformance = test=20 > program based on IETF specs, and I agree that for the end users, some=20 > sort of easily identified distinguisher on the box would be helpful. In my view, the above should be a key factor in our thinking. IETF standards get "enforced" by contracts. Large numbers of these gateway devices are sold or otherwise provided to end users by ISPs. So if ISPs have something to which they can require vendors to conform as part of the ISPs' purchase of the devices or recommendation of them to end customers, that will probably be enough market pressure to achieve the desired result. A --=20 Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate From joe@grey.uoregon.edu Tue Jun 16 11:15: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 0F38428C1A6 for ; Tue, 16 Jun 2009 11:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=0.277, 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 7n9mlTxEI1Yu for ; Tue, 16 Jun 2009 11:15:23 -0700 (PDT) Received: from grey.uoregon.edu (grey.uoregon.edu [128.223.214.89]) by core3.amsl.com (Postfix) with SMTP id 10A9E28C1A4 for ; Tue, 16 Jun 2009 11:15:23 -0700 (PDT) Received: by grey.uoregon.edu; Tue, 16 Jun 2009 11:13:27 -0700 Date: Tue, 16 Jun 2009 11:13:27 -0700 From: Joe St Sauver To: tme@americafree.tv Message-Id: <09061611132741.884a3.1311932638@oregon.uoregon.edu> Cc: homegate@ietf.org Subject: Re: [homegate] Jumbo frames X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: joe@oregon.uoregon.edu List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 18:15:25 -0000 Marshall commented: #Is there a definition yet for Jumbo frames ? I thought that IEEE had #said no to this. I believe you are correct, and yet 9K (or better) is broadly supported by the vendor community and widely deployed (at least in the R&E community). For example, the Large Scale Networking (LSN) Joint Engineering Team (JET), (see http://www.nitrd.gov/subcommittee/lsn/jet/ ) has endorsed 9000 byte MTUs, see http://www.nitrd.gov/subcommittee/lsn/jet/9000_mtu_statement.pdf #Your own web site, http://darkwing.uoregon.edu/~joe/jumbo-clean-gear.html #shows what a mess this is in the absence of a standard. You know me, I'm just eager to be able to add home gateway devices somewhere on that already messy page. :-; (And FWIW, I do think that 9000 is the defacto standard for jumbo frames in practice, even if, unfortunately, not in the IEEE paperwork) But I truly don't mean to side track this broader discussion. I'm just hoping that we DO NOT end up with a specification which says that home gateway devices "MUST NOT [or SHOULD NOT] support MTUs greater than 1500 bytes" Rather, I'd hope that we DO end up with a statement that reads "SHOULD [or at least MAY] support MTUs of at least 9000 bytes" instead. Regards, Joe From dwing@cisco.com Tue Jun 16 12:30:44 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 3A7393A6BF0 for ; Tue, 16 Jun 2009 12:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.327 X-Spam-Level: X-Spam-Status: No, score=-6.327 tagged_above=-999 required=5 tests=[AWL=0.272, 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 Mc5L0A+7sitB for ; Tue, 16 Jun 2009 12:30:43 -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 0A5183A6B92 for ; Tue, 16 Jun 2009 12:30:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,231,1243814400"; d="scan'208";a="177010297" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 16 Jun 2009 19:30:33 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5GJUXLH000975; Tue, 16 Jun 2009 12:30:33 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5GJUXxr006061; Tue, 16 Jun 2009 19:30:33 GMT From: "Dan Wing" To: "'Marshall Eubanks'" References: Date: Tue, 16 Jun 2009 12:30:32 -0700 Message-ID: <077601c9eeb8$ea5d8380$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcnubToTtm0XKuYFRPasbUZJJTJcoQAS52gA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3020; t=1245180633; x=1246044633; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[homegate]=20Homegate=20and=20Multicast |Sender:=20; bh=/B+hJMycBZ3/3dUKSfu2x8RWsVYkWpw9yVern5lwbAw=; b=p8B/NG5gEiyHMT7x+jrAG0kX4vHjXC/LRhiJQRemlNNwVSOzCIt0VMv4sh nYJwt7cUzbIRRmj3r3czdjv2bjor7uQjueiuAk5z1IU4VNV0YMmDnsJPTdhy OV3N4r7rpZ; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'Greg Shepherd' , 'Leonard Giuliano' , homegate@ietf.org Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 19:30:44 -0000 BEHAVE took a stab at this, http://tools.ietf.org/html/rfc5135 -d > -----Original Message----- > From: homegate-bounces@ietf.org > [mailto:homegate-bounces@ietf.org] On Behalf Of Marshall Eubanks > Sent: Tuesday, June 16, 2009 3:28 AM > To: homegate@ietf.org > Cc: Greg Shepherd; Leonard Giuliano > Subject: [homegate] Homegate and Multicast > > I have been wading through all of this, and was surprised to see no > mention > of multicast in > > tart/HomeGate%20BoF%20Proposal%20-%20IETF%2075%20-%20v7.pdf > > > > A blow to the first round of multicast deployments (almost a decade > ago now!) was the inability of > most of the then current home routers to support things such as IGMP > proxying. If the IETF is going to specify a > new effort to specify home gateways, then in my opinion this > specification should support at least SSM multicast reception > properly. > > Supporting multicast in the home environment is becoming common in > video deployments, but the end user typically > does not see this on their home network and there is very little > multicast support to the end user (instead of just to their set top > boxes). However, > the trend in the industry is towards merging the reception of > Internet-transported video and provider-transported video > into common > hardware platforms. Internet video > would certainly benefit from support of multicast reception, > and there > seems to be a recognition of that in the industry. The CableLabs > document "IPv4 and IPv6 eRouter Specification" > http://www.cablelabs.com/specifications/CM-SP-eRouter-I03-070518.pdf > > states as their goal : > > The specification defines a) CPE provisioning with IPv4 and IPv6 > addresses, b) IPv4 data forwarding with NAPT > and IPv6 data forwarding, c) Ability to forward IP Multicast traffic > and d) Preserving IP QoS markings on IP data > to and from the CPE devices. > > and includes sections on IGMP proxing as well as v4 and v6 multicast > support. The other two documents mentioned as > parallel efforts : > > Broadband Forum TR-124 defines a set of modular functional > requirements for broadband residential > gateways:http://www.broadband-forum.org/technical/download/TR-124.pdf > . > > The Home Gateway Initiative also has a Home Gateway Requirements: > Residential Profile > document:http://www.homegatewayinitiative.org/publis/HGI_V1.01 > _Residential.pdf > . > > also include multicast support. > > So, while I support this effort, I would like to see multicast SSM > added to Theme 1. > > Regards > Marshall > > P.S. Can I also suggest that what is basically a text file > BOF charter > should be served as a text file in the usual > fashion ? > > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate From iljitsch@muada.com Tue Jun 16 12:43: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 C44503A68B1 for ; Tue, 16 Jun 2009 12:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218, 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 gwOTaHoOp2qk for ; Tue, 16 Jun 2009 12:43:34 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 6FB913A6DAF for ; Tue, 16 Jun 2009 12:43:34 -0700 (PDT) Received: from [192.168.2.4] (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 n5GJgS9d089406 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Jun 2009 21:42:29 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <2FC0A9D5-F1F4-48F2-8839-300689CA57F8@muada.com> From: Iljitsch van Beijnum To: joe@oregon.uoregon.edu In-Reply-To: <09061611132741.884a3.1311932638@oregon.uoregon.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 21:41:57 +0200 References: <09061611132741.884a3.1311932638@oregon.uoregon.edu> X-Mailer: Apple Mail (2.935.3) Cc: homegate@ietf.org Subject: Re: [homegate] Jumbo frames 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, 16 Jun 2009 19:43:35 -0000 On 16 jun 2009, at 20:13, Joe St Sauver wrote: >> Is there a definition yet for Jumbo frames ? I thought that IEEE >> had said no to this. > I believe you are correct, and yet 9K (or better) is broadly supported > by the vendor community and widely deployed (at least in the R&E > community). Yes, all the vendors that get together at the IEEE and refuse to do 1500+ also happily build products that support larger packet sizes on 802.3. The IEEE's problem is that they need to retain compatibility with older versions of ethernet. So if I hook up my 10GE router to a 10GE switch with a gigabit ethernet port and that port to a cheap 10/100/1000 switch and that switch to a prehistoric half duplex 10baseT NIC, the packets need to be understood by the 10 Mbps system. So they can't be longer than 1500 bytes. I've been working on a draft for a few years that allows IP hosts to negotiate non-standard frame sizes between them: http://tools.ietf.org/html/draft-van-beijnum-multi-mtu-02 Don't spend too much time on this text though, I plan to completely overhaul it for Stockholm. Note that although 9000 bytes is a common jumboframe size, it's far from universal. Some NICs and many hosts and routers support other nonstandard sizes. A lot of cheap switches don't even break the 2k barrier but even a few dozen extra bytes can be useful to allow tunneling without path MTU discovery issues. The point is that we break away from the "1500-only" assumption and get to use MTU sizes that fit the job at hand, not that we replace one limitation with another. The problem with a home gateway is that it potentially has three interfaces: WAN, LAN and WLAN. On the LAN size, a 9000-byte MTU would be nice, but on the WAN side this may not be appropriate. For instance, ATM uses a ~4.5k default MTU and using 9000-byte packets with 128 kbps upstream capacity means that a packet occupies the wire more than half a second. I remember some time reading that 802.11 uses a 4k MTU under the hood but that the wifi alliance requires a 1500- byte MTU for wifi certification. In any event, I've never seen a wifi MTU that was user settable. Also, on high error links such as wifi using very large packets is bad for performance. So a home gateway that supports jumboframes would almost certainly have to manage different MTUs on different interfaces. It would even be a good idea to only send 1500 byte packets on ports that are running at 10 or 100 Mbps because jumboframes are very uncommon with sub-gigabit gear. Now this shouldn't be a problem if the home gateway can generate "packet too big" ICMP/ICMPv6 messages even when it's switching. So two hosts connected to the HGW @ 1000 Mbps could talk 9000-byte packets between them but be limited to 4.5k for packets going out to the service provider and 1500 for packets going to hosts connected to the HGW over wifi. It would still be necessary to set MTU sizes on the different interfaces, though. From mbaugher@cisco.com Tue Jun 16 13:03:12 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 1D35D3A688B for ; Tue, 16 Jun 2009 13:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 xR4hupsee91M for ; Tue, 16 Jun 2009 13:03:11 -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 345303A6B92 for ; Tue, 16 Jun 2009 13:03:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,231,1243814400"; d="scan'208,217";a="200952049" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 16 Jun 2009 19:55:14 +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 n5GJtFpl016788; Tue, 16 Jun 2009 12:55:15 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5GJtFJ7010155; Tue, 16 Jun 2009 19:55:15 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); Tue, 16 Jun 2009 12:55:14 -0700 Received: from sjc-mbaugher-8712.cisco.com ([10.19.93.35]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 12:55:14 -0700 Message-Id: From: Mark Baugher To: james woodyatt In-Reply-To: <54A266FB-B81A-4C3F-8C7D-56CBDB6180DA@apple.com> Content-Type: multipart/alternative; boundary=Apple-Mail-30-586941026 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 16 Jun 2009 12:55:13 -0700 References: <70DE1C24-910C-4102-AF0D-94A24AAFA6A7@cisco.com> <54A266FB-B81A-4C3F-8C7D-56CBDB6180DA@apple.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Jun 2009 19:55:14.0523 (UTC) FILETIME=[5D698AB0:01C9EEBC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2326; t=1245182115; x=1246046115; c=relaxed/simple; s=sjdkim4002; 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=20and=20Multicast |Sender:=20; bh=ab2aR82edKos7qXXnDLP0+8wX1MRYlhSdBbpZ2RU9xM=; b=eIjYwYeWVFtPUwoyff3617wyoeNif8u7q2XWVnswpOkout8ggtxrtIfU/E WSW146YKQjDSRPLR6oNemg+OVuG7a68F13RniBGFyoL8WpxuseC/J8RUniIs GS6H7Xz4FR; Authentication-Results: sj-dkim-4; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: homegate@ietf.org Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 20:03:12 -0000 --Apple-Mail-30-586941026 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 16/06/2009, at 10:32 AM, james woodyatt wrote: > > The truth is we really don't know what the interesting applications > of non-local scope multicast will be until we have an Internet that > can route it. Sadly, we don't have one yet, and one of the reasons > for that is that residential gateways, by and large, don't implement > multicast routing protocols. > I expect we'll have to for IPv6 because we want site-local scope to work (viz. http://www.ietf.org/internet-drafts/draft-bnss-v6ops-upnp-01.txt) . Mark --Apple-Mail-30-586941026 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On 16/06/2009, at = 10:32 AM, james woodyatt wrote:


The truth is we really don't = know what the interesting applications of non-local scope multicast will = be until we have an Internet that can route it.  Sadly, we don't = have one yet, and one of the reasons for that is that residential = gateways, by and large, don't implement multicast routing = protocols.


I expect we'll have = to for IPv6 because we want site-local scope to work (viz. http://www.ietf.org/internet-drafts/draft-bnss-v6ops-upnp-01.txt).

Mark

= --Apple-Mail-30-586941026-- From richard@bennett.com Tue Jun 16 13:17:13 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 AFBCA28C0DC for ; Tue, 16 Jun 2009 13:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.839 X-Spam-Level: X-Spam-Status: No, score=-1.839 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_22=0.6] 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 gXgqHLxZm-CB for ; Tue, 16 Jun 2009 13:17:12 -0700 (PDT) Received: from outbound-mail-120.bluehost.com (outbound-mail-120.bluehost.com [69.89.18.6]) by core3.amsl.com (Postfix) with SMTP id 846B03A6B11 for ; Tue, 16 Jun 2009 13:17:12 -0700 (PDT) Received: (qmail 11838 invoked by uid 0); 16 Jun 2009 20:16:30 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy3.bluehost.com with SMTP; 16 Jun 2009 20:16:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-MimeOLE:Thread-Index:X-Identified-User; b=ir1H7lz98LXhZSpwHaKuz5a6qyrc/59krzkIAI3BdE/y5hcQoC8hFvk+Q+8ryPe2/UlFTBhVKYhQBC/hQl9+VJ+4Jdc6qNI0MH/FEfKWLdJoJAQA58bjg+TvUP1tYG0V; Received: from c-24-5-230-26.hsd1.ca.comcast.net ([24.5.230.26] helo=Honkin) by host46.hostmonster.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MGf53-00024j-Nh; Tue, 16 Jun 2009 14:16:30 -0600 From: "Richard Bennett" To: "'Iljitsch van Beijnum'" , "'Marshall Eubanks'" References: <7E6E35CE-AB91-400D-BD22-4BD6E1BD6986@americafree.tv> <3AF41F51-4411-4D34-B74A-4FA625B3B314@muada.com> In-Reply-To: <3AF41F51-4411-4D34-B74A-4FA625B3B314@muada.com> Date: Tue, 16 Jun 2009 13:16:06 -0700 Message-ID: <3AC8AFEF19E4426487FB01C031D7B5F6@Honkin> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Thread-Index: Acnumhrf5byfF1cVRH6Hh2/XVvTOIwAIv4HQ X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 24.5.230.26 authed with richard+bennett.com} Cc: homegate@ietf.org Subject: Re: [homegate] Homegate and Multicast 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, 16 Jun 2009 20:17:13 -0000 Actually, the "real problem" with multicast over 802.11 is related to acknowledgements, but isn't simply a matter of reliability or the lack thereof. 802.11 is a multi-rate system, and it decides which rate to use for any given association based on successful and unsuccessful transmissions. The ACKs are important because they close a feedback loop, but MAC-level multicast doesn't have any ACKs, so the sender doesn't know how fast to transmit. One of the common ways around this problem - which is really a defect in 802.11 - is to convert each multicast streams into a series of unicasts. So instead of a multicast stream going out at 2 Mb/s, you have two or three unicast streams at 54 (or higher, for 802.11n.) Some of your larger Wi-Fi chip vendors include this capability as a standard feature in their Linux drivers (for use in home gateways.) Converting IP multicast to Wi-Fi unicast is the classic example of a "SHOULD" recommendation. Regarding the problem of jumbo frames, note that Wi=Fi has always supported a larger-than Ethernet MSDU, 2304 bytes, and it also supports fragmentation so it shouldn't care in principle how large your MTU is. The question of Wi-Fi frame sizing for performance is largely moot for higher-level protocols in 802.11e and n, since the aggregation scheme takes care of it, so I wouldn't worry too much about that. Richard Bennett -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behalf Of Iljitsch van Beijnum Sent: Tuesday, June 16, 2009 7:43 AM To: Marshall Eubanks Cc: homegate@ietf.org Subject: Re: [homegate] Homegate and Multicast On 16 jun 2009, at 16:34, Marshall Eubanks wrote: >> Speaking of that: multicast streaming doesn't work over wifi. A lot >> of home gateways talk to the local hosts over wifi. How do we solve >> this? > Multicast does work over 802.11. Of course, otherwise ARP or ND wouldn't work and IP over 802.11 would be impossible. However, multicast _streaming_ doesn't work. > The trouble is that many access points don't do IGMP/MLD, so any > multicast present on the wireline side of the LAN is flooded to the > wireless. In an enterprise environment (with a faster LAN than WLAN, > and potentially lots of multicast users), this has the risk to > totally flood the 802 WLAN with unintended traffic. As a result, a > lot of access points limit or block multicast by default. I've seen multicast rate limiting and the other issues that you mention may also be a factor. However, the real problem is that wireless is unreliable, and because there are presumably many listeners, the normal ACK/retransmission mechanism isn't used for broadcasts/multicasts on 802.11. So you lose many packets. Another problem is that in order to make multicasts for management protocols work those packets are sent at very low bitrates (1 - 6 Mbps) so even a few Mbps of multicast traffic saturates the wireless channel. (BTW the 1 Mbps thing that you mention about Apple base stations isn't a rate limit but the rate at which multicasts are sent AFAIK. With an older Apple base station I had the situation that after three or so multicasts in quick succession multicasts would be block for a short time. With the newer AEBS that doesn't seem to be the case anymore but I haven't extensively tested this.) _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate From Carolin.Latze@swisscom.com Wed Jun 17 00:40:48 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 E335C3A6A2C for ; Wed, 17 Jun 2009 00:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 5KSN2lVk9H9W for ; Wed, 17 Jun 2009 00:40:48 -0700 (PDT) Received: from mail.swisscom.com (outmail20.swisscom.com [138.190.32.10]) by core3.amsl.com (Postfix) with ESMTP id DDD353A67AD for ; Wed, 17 Jun 2009 00:40:47 -0700 (PDT) Received: by mrz.swissptt.ch; Wed, 17 Jun 2009 09:40:56 +0200 (MEST) From: To: Date: Wed, 17 Jun 2009 09:40:52 +0200 Thread-Topic: Smart Metering / M2M Thread-Index: AcnvHvDxpQTIqVC0SBGgrL0KMIsaCA== Message-ID: <7191A9FADFABE74F94A8403B82C57A61015EF975EA@sg000036.corproot.net> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-CH Content-Type: multipart/alternative; boundary="_000_7191A9FADFABE74F94A8403B82C57A61015EF975EAsg000036corpr_" MIME-Version: 1.0 Subject: [homegate] Smart Metering / M2M 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, 17 Jun 2009 07:40:49 -0000 --_000_7191A9FADFABE74F94A8403B82C57A61015EF975EAsg000036corpr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I want to raise another topic which will be important in the future: Starti= ng with smart metering (at least in the EU), M2M applications will become m= ore common also for end-users. Till now there are no standards available de= aling with M2M connectivity, but some activities have started recently (e.g= . in the ETSI). Although we might not be able to take them into account for= the first draft (since they just began), but we should keep in mind, that = there will be some new standards regarding M2M connectivity in the near fut= ure (perhaps very near in the EU because of the smart metering regulations = that force operators and energy utilities to do something), which might/sho= uld be included in the home gateway. If they are not, users would need more= than one, which is uncomfortable. Carolin --_000_7191A9FADFABE74F94A8403B82C57A61015EF975EAsg000036corpr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I want to raise another topic which= will be important in the future: Starting with smart metering (at least in the EU),= M2M applications will become more common also for end-users. Till now there are= no standards available dealing with M2M connectivity, but some activities have started recently (e.g. in the ETSI). Although we might not be able to take = them into account for the first draft (since they just began), but we should kee= p in mind, that there will be some new standards regarding M2M connectivity in t= he near future (perhaps very near in the EU because of the smart metering regulations that force operators and energy utilities to do something), whi= ch might/should be included in the home gateway. If they are not, users would = need more than one, which is uncomfortable.

 

Carolin

--_000_7191A9FADFABE74F94A8403B82C57A61015EF975EAsg000036corpr_-- From Carolin.Latze@swisscom.com Wed Jun 17 00:48:59 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 222DA3A6DDB for ; Wed, 17 Jun 2009 00:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 0I2TB2H8R9QS for ; Wed, 17 Jun 2009 00:48:56 -0700 (PDT) Received: from mail.swisscom.com (outmail21.swisscom.com [138.190.32.11]) by core3.amsl.com (Postfix) with ESMTP id BBD103A6DBA for ; Wed, 17 Jun 2009 00:48:51 -0700 (PDT) Received: by mrp.swissptt.ch; Wed, 17 Jun 2009 09:48:59 +0200 (MEST) Received: from sg000036.corproot.net ([10.92.8.6]) by SG1924Z.corproot.net ([10.185.66.60]) with mapi; Wed, 17 Jun 2009 09:48:47 +0200 From: To: Date: Wed, 17 Jun 2009 09:48:45 +0200 Thread-Topic: Management of the Home Gateway Thread-Index: AcnvIAq2WhoT7J0OSqyTDPQHuMu3GQ== Message-ID: <7191A9FADFABE74F94A8403B82C57A61015EF97608@sg000036.corproot.net> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-CH Content-Type: multipart/alternative; boundary="_000_7191A9FADFABE74F94A8403B82C57A61015EF97608sg000036corpr_" MIME-Version: 1.0 Subject: [homegate] Management of the Home Gateway 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, 17 Jun 2009 07:48:59 -0000 --_000_7191A9FADFABE74F94A8403B82C57A61015EF97608sg000036corpr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi again, Although I managed it already, I want to start a separate discussion about = the management of the home gateway. I think, that might be an important top= ic too. There are several points to discuss: 1) Who manages/ configures such a device? The user? The operator? Does= n't matter? 2) Is it a device, that can also be used for networks, that are not co= nnected to the Internet? (which means, that management/configuration over a= server in the Internet is not possible) 3) Are there at least parts of the device, that cannot be accessed by = the user (the operator can use it for whatever reason, e.g. network specifi= c configurations...)? 4) ... I just think loud :) Maybe we don't want to deal with that, but I think it = could be interesting to take those things in account too. Carolin --_000_7191A9FADFABE74F94A8403B82C57A61015EF97608sg000036corpr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi again,

 

Although I managed it already, I wa= nt to start a separate discussion about the management of the home gateway. I thi= nk, that might be an important topic too. There are several points to discuss:<= o:p>

 

1)      Who manages/ configures s= uch a device? The user? The operator? Doesn’t matter?

2)      Is it a device, that can = also be used for networks, that are not connected to the Internet? (which means, that management/configuration over a server in the Internet is not possible= )

3)      Are there at least parts = of the device, that cannot be accessed by the user (the operator can use it for whatever reason, e.g. network specific configurations…)?

4)      …

 

I just think loud J Maybe we don= 217;t want to deal with that, but I think it could be interesting to take those things= in account too.


Carolin

--_000_7191A9FADFABE74F94A8403B82C57A61015EF97608sg000036corpr_-- From kirk.erichsen@twcable.com Wed Jun 17 07:06:11 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 38BE128C179 for ; Wed, 17 Jun 2009 07:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 Ed1EtyYA1Y8y for ; Wed, 17 Jun 2009 07:06:10 -0700 (PDT) Received: from pblpas01.twcable.com (pblpas01.twcable.com [204.235.121.149]) by core3.amsl.com (Postfix) with ESMTP id DBB2C3A6989 for ; Wed, 17 Jun 2009 07:06:09 -0700 (PDT) X-SENDER-IP: 10.157.247.213 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,236,1243828800"; d="scan'208";a="423990024" Received: from unknown (HELO prvpmailconn3.corp.twcable.com) ([10.157.247.213]) by pblpas01.twcable.com with ESMTP; 17 Jun 2009 10:06:21 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2009 10:06:21 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Jun 2009 10:06:20 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Management of the Home Gateway thread-index: AcnvIAq2WhoT7J0OSqyTDPQHuMu3GQAMhmRv References: <7191A9FADFABE74F94A8403B82C57A61015EF97608@sg000036.corproot.net> From: "Erichsen, Kirk" To: , X-OriginalArrivalTime: 17 Jun 2009 14:06:21.0097 (UTC) FILETIME=[CA87F990:01C9EF54] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: Re: [homegate] Management of the Home Gateway 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, 17 Jun 2009 14:06:11 -0000 Q2Fyb2xpbiwKIApJJ20gYSBiaWcgYmVsaWV2ZXIgaW4gbGltaXRpbmcgdGhlIHNjb3BlLCBhdCBs ZWFzdCBhdCBmaXJzdCwgc28gdGhhdCB3ZSBjYW4gcHJvY2VlZCBtb3JlIHF1aWNrbHkuIE5vdGUg dGhpcyBpcyBqdXN0IG15IG9waW5pb24gYnV0IGl0J3MgYW4gaW5mb3JtZWQgb25lIGFzIGFuIE1T TyB0aGF0IHByb3ZpZGVzIGJvdGggbWFuYWdlZCBhbmQgdW5tYW5hZ2VkIHNlcnZpY2VzOgogCjEp IFdobyBtYW5hZ2VzIHRoZSBkZXZpY2U/IC0gSSBUaGluayBpbiBtb3N0IGNhc2VzLCA5MCUgb2Yg dGhlIHRpbWUgaXQgaXMgdGhlIGN1c3RvbWVyL2VuZCB1c2VyLiBDYWJsZWhvbWUgd2FzIGEgc3Bl Y2lmaWNhdGlvbiB0aGF0IGRldGFpbGVkIGEgcm91dGVyIGZvciBhIHJlc2lkZW50aWFsIG1hbmFn ZWQgc2VydmljZSBhbmQgaXQgcHJldHR5IG11Y2ggZmFpbGVkIG1pc2VyYWJseS4gSXQgcmVhbGx5 IGRvZXMgbWF0dGVyIHdobyBjb250cm9scy9tYW5hZ2VzIHRoZSBkZXZpY2UvZGV2aWNlcyB3aXRo aW4gdGhlIGhvbWUgYXMgdGhlIG1vZGVscyBhcmUgYWxtb3N0IGNvbXBsZXRlbHkgaW5jb21wYXRp YmxlIGF0IGFuIG9wZXJhdGlvbmFsIGxldmVsLiBUaGUgY29zdCBvZiB0aGVzZSBkZXZpY2VzIHdp bGwgZ28gdXAgc2xpZ2h0bHkgd2l0aCBldmVyeSBNSUIsIGV2ZXJ5IGNsaWVudCBjb250cm9sIGFu ZCByZW1vdGUgYWNjZXNzIHdpZGdldCB3ZSBhZGQuIFdlIG5lZWQgdG8gYmUgbWluZGZ1bCBvZiB0 aGF0LgogCjIpIElzIHRoaXMgYSBkZXZpY2UgdGhhdCBjYW4gYWxzbyBiZSB1c2VkIGZvciBuZXR3 b3JrIHRoYXQgYXJlIG5vdCBjb25uZWN0ZWQgdG8gdGhlIEludGVybmV0PyAtIE15IHBvc2l0aW9u IGlzIHRoYXQgdGhlcmUgaXMgYSBkZWdyZWUgb2YgbmVjZXNzYXJ5IGJpYXMgdGhhdCBzYXlzIHRo ZXNlIGRldmljZXMgYXJlIHRhaWxvcmVkIHRvIGEgYnJvYWRiYW5kIHNlcnZpY2Ugb2ZmZXJpbmcg YW5kIHRoYXQgd2hlbiB0aGF0IHNlcnZpY2UgZG9lcyBub3QgZXhpc3QsIHRoZSBkZXZpY2UganVz dCBzaXRzIHRoZXJlIChhdCBsZWFzdCBhcyBhIHNjb3BlIGNvbnN0cmFpbnQgZm9yIHRoaXMgc3Bl YyBlZmZvcnQpLiBUaGF0IHNhaWQsIHRoZXJlIGlzIG5vdGhpbmcgd2Ugd2lsbCB3cml0ZSBpbiB0 aGUgdGV4dCB0byBwcmVjbHVkZSB0aGUgcm91dGVyIGZyb20gb3BlcmF0aW5nIHN0YW5kYWxvbmUg d2hpbGUgc3RpbGwgYmVpbmcgY29tcGxhaW50IHRvIHRoZSBzcGVjLiBBbnkgdmVuZG9yIHdhbnRp bmcgdG8gcHJvdmlkZSBhIHByb2R1Y3QgZGlmZmVyZW50aWF0b3IgY291bGQgd2VsbCBhZGQgdGhl IG5lY2Vzc2FyeSBjb21wb25lbnRzIHRvIG9wZXJhdGUgc3RhbmRhbG9uZSB3aXRob3V0IGEgYnJv YWRiYW5kIHNlcnZpY2UuIEl0J3MgbXkgdmlldyB3ZSBzaG91bGRuJ3QgZXhwZW5kIG91ciBlZmZv cnQvdGltZSBvbiB0aGlzICJwcm9kdWN0IHNwZWMiIGluIHRoZSBpbnRlcmVzdHMgb2YgdGltZSBh bmQgb2YgdGhlIHByaW1hcnkgcHVycG9zZSBmb3IgdGhlc2Ugcm91dGVycyBpbiBhIGJyb2FkYmFu ZCBzZXJ2aWNlLgogCjMpIEFyZSB0aGVyZSBwYXJ0cyBvZiB0aGUgZGV2aWNlIGNvbmZpZ3VyYXRp b24gdGhhdCBtYXkgbm90IGJlIGFjY2Vzc2libGUgdG8gdGhlIGVuZCB1c2VyL2N1c3RvbWVyPyAt IFRoaXMgaXMgcG9zc2libGUsIGJ1dCB3aGVuIHlvdSBnZXQgdGhpcyBmYXIgaW50byB0aGUgZGV2 aWNlIGNvbnRyb2wgKGkuZS4gY29uZmlndXJhdGlvbiBtYW5hZ2VtZW50KSB5b3UgaGF2ZSB0byBz dGFydCBhc3N1bWluZyBtb2RlbHMsIHdoaWNoIHdvdWxkIGJyZWFrIHRoZSBhYm92ZSBzaW1wbGVy IGFzc3VtcHRpb25zIHVubGVzcyB5b3UgZGV0YWlsZWQgbXVsdGlwbGUgc2NlbmFyaW9zLiBJdCBp cyBxdWl0ZSBwb3NzaWJsZSB0byBzaW1wbHkgZGV0YWlsICJzb21lIiBvZiB0aGUgY29uZmlndXJh dGlvbiBtYW5hZ2VtZW50IGFzcGVjdHMgb2YgdGhpcyBkZXZpY2UgYW5kIHN0YXkgb3V0IG9mIG1h a2luZyBhIGZ1bGwgcHJvZHVjdCBzcGVjLCB3aGljaCB3aWxsIHRlbmQgdG8gaW5jbHVkZSB0aGUg ZGV0YWlsZWQgY29uZmlndXJhdGlvbiBtYW5hZ2VtZW50IGFzcGVjdHMgb2YgYSBmdWxseSBpbnRl Z3JhdGVkIGdhdGV3YXkgYXMgcHJvZHVjZWQgYnkgYSB2ZW5kb3IuIFdlIGNhbiBhZmZvcmQgdG8g YmUgbW9yZSB2YWd1ZSBoZXJlLiBGb3IgZXhhbXBsZSwgd2UgY2FuIGRlc2NyaWJlIGhvdyBhIHN0 YXRlbGVzcyBvciBzdGF0ZWZ1bCBESENQIHNlcnZlciBjb3VsZCBiZSBpbXBsZW1lbnRlZCwgcHJv dmlkZSBleGFtcGxlcyBvZiBjb250cm9scyBmb3IgdGhlc2Ugc2VydmljZXMsIGJyaWVmbHkgZGVz Y3JpYmUgdGhlIE5BVCBwcm9jZXNzLCBwYWNrZXQgZmlsdGVyaW5nIGZpcmV3YWxsIGZlYXR1cmUg YW5kIHRoZW4gc3RvcCByaWdodCB0aGVyZS4gV2UgbmVlZCBub3QgbWFuZGF0ZSB0aGF0IHRoZSBy b3V0ZXIgaGF2ZSBhbiBTU0ggYW5kL29yIEhUVFAgcmVtb3RlIG1hbmFnZW1lbnQgaW50ZXJmYWNl LCBvciB1c2UgWE1MIHRvIGRvd25sb2FkIGEgbmV3IGNvbmZpZ3VyYXRpb24gZmlsZSB0aGF0IGlm IGluICJzdGFuZGFsb25lIiB3aWxsIGp1c3QgcHVsbCB1cCBzb21lIGRlZmF1bHQgY29uZmlnIHRo YXQgdGhlIHVzZXIgY2FuIGFsdGVyIHRoZW1zZWx2ZXMuIAogCjQpIC4uLi4uIG90aGVyIHN0dWZm IHJlbGF0ZWQgdG8gbWFuYWdlbWVudCAtIE9uZSBvZiB0aGUgd2F5cyB3ZSBjYW4gaGFuZGxlIHRo aXMgYW5kIGFueSBvdGhlciBmdW5jdGlvbmFsaXR5IHdlIHdhbnQgdG8gYWNjb3VudCBmb3Igd2hl biB3cml0aW5nIGEgbW9yZSBnZW5lcmljIHJvdXRlciBzcGVjIGlzIHRoYXQgdGhlIGxhbmd1YWdl IHlvdSBjaG9vc2Ugc2hvdWxkIG5ldmVyIHByZWNsdWRlIGEgdmVuZG9yL3NlcnZpY2UgcHJvdmlk ZXIgZ29pbmcgZnVydGhlciAodGhlIGFib3ZlIG1lbnRpb25lZCAicHJvZHVjdCBzcGVjaWZpY2F0 aW9uIiB3aGljaCBpcyBhbHdheXMgbW9yZSBkZXRhaWxlZCBhbmQgdGFpbG9yZWQgdG8gYSBzcGVj aWZpYyBzZXJ2aWNlIG9mZmVyaW5nKSBhbmQgc2hvdWxkIGFsbG93IGV2b2x1dGlvbiB3aXRob3V0 IHJlcXVpcmluZyB0aGUgc3BlY2lmaWNhdGlvbiB0byBiZSBzdXBlcmNlZGVkIGEgbG90IHNvb25l ci4gVGhlcmUgaXMgb2Z0ZW4gbm8gaGFybSBkb25lIHRvIHJlbWFpbiBzaWxlbnQgb24gYXJlYXMg b2YgZnVuY3Rpb25hbGl0eSB3aGljaCBmYWxsIG91dHNpZGUgdGhlIGNvcmUgZnVuY3Rpb25hbGl0 eSBvZiBhIHJvdXRlciwgYWxsb3dpbmcgdGhlIHNlcnZpY2UgcHJvdmlkZXIvdmVuZG9yIHRvIGlu bm92YXRlIGluIHRoZXNlIGFyZWFzIGluZGl2aWR1YWxseS4gVGhlIG9ubHkgYmFzaWMgYXNzdW1w dGlvbiBJIHdvdWxkIGxpa2UgdG8gbWFrZSAoYW5kIHRvIHJlZnJhaW4gZnJvbSBnb2luZyBtdWNo IGZ1cnRoZXIgb24gZGV0YWlsaW5nKSBpcyB0aGF0IHRoZSByb3V0ZXIgaXMgYXNzdW1lZCB0byBv cGVyYXRlIHdpdGhpbiBhIHNlcnZpY2UgcHJvdmlkZXJzJyBhY2Nlc3MgbmV0d29yayBmb3IgdGhl IHB1cnBvc2VzIG9mIGJyb2FkYmFuZCBhY2Nlc3MgYW5kIHN0b3AganVzdCBzaG9ydCBvZiB1c2lu ZyB0aGlzIHJvdXRlciBhcyBhIGdlbmVyaWMgcm91dGVyIGluIGEgc3RhbmRhbG9uZSBlbnZpcm9u bWVudC4gTGV0IHRoZSBzZXJ2aWNlIHByb3ZpZGVyL01TTyBhbmQgdGhlaXIgdmVuZG9ycyBjb21l IHVwIHdpdGggdGhlIHByb2R1Y3Qgc3BlYyB0byBkZWxpdmVyIHRoYXQgc3RhbmRhbG9uZSBkZXZp Y2UsIHRoZXkgY2FuIHJlbHkgb24gdGhlIHNwZWMgd2UgZGV2ZWxvcCBhcyB0aGVpciBzdGFydGlu ZyBwb2ludCAoYW5kIHByb2JhYmx5IDgwLTkwJSBvZiB0aGUgcmVxdWlyZW1lbnRzIHdlIHN0aXB1 bGF0ZSBpbiB0aGUgYnJvYWRiYW5kIGRlbGl2ZXJlZCBhc3N1bXB0aW9ucyBmb3IgdGhlIGJhc2lj IHNwZWMgYXJlIHJldGFpbmVkKS4KIApZb3VyIHRoaW5raW5nIG91dCBsb3VkIGlzIGdyZWF0LCBr ZWVwIGl0IHVwIGFuZCBJJ2xsIGRvIHRoZSBzYW1lLgogCi1LRQoKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KCkZyb206IGhvbWVnYXRlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxm IG9mIENhcm9saW4uTGF0emVAc3dpc3Njb20uY29tClNlbnQ6IFdlZCA2LzE3LzIwMDkgMTo0OCBB TQpUbzogaG9tZWdhdGVAaWV0Zi5vcmcKU3ViamVjdDogW2hvbWVnYXRlXSBNYW5hZ2VtZW50IG9m IHRoZSBIb21lIEdhdGV3YXkKCgoKSGkgYWdhaW4sCgogCgpBbHRob3VnaCBJIG1hbmFnZWQgaXQg YWxyZWFkeSwgSSB3YW50IHRvIHN0YXJ0IGEgc2VwYXJhdGUgZGlzY3Vzc2lvbiBhYm91dCB0aGUg bWFuYWdlbWVudCBvZiB0aGUgaG9tZSBnYXRld2F5LiBJIHRoaW5rLCB0aGF0IG1pZ2h0IGJlIGFu IGltcG9ydGFudCB0b3BpYyB0b28uIFRoZXJlIGFyZSBzZXZlcmFsIHBvaW50cyB0byBkaXNjdXNz OgoKIAoKMSkgICAgICBXaG8gbWFuYWdlcy8gY29uZmlndXJlcyBzdWNoIGEgZGV2aWNlPyBUaGUg dXNlcj8gVGhlIG9wZXJhdG9yPyBEb2Vzbid0IG1hdHRlcj8KCjIpICAgICAgSXMgaXQgYSBkZXZp Y2UsIHRoYXQgY2FuIGFsc28gYmUgdXNlZCBmb3IgbmV0d29ya3MsIHRoYXQgYXJlIG5vdCBjb25u ZWN0ZWQgdG8gdGhlIEludGVybmV0PyAod2hpY2ggbWVhbnMsIHRoYXQgbWFuYWdlbWVudC9jb25m aWd1cmF0aW9uIG92ZXIgYSBzZXJ2ZXIgaW4gdGhlIEludGVybmV0IGlzIG5vdCBwb3NzaWJsZSkK CjMpICAgICAgQXJlIHRoZXJlIGF0IGxlYXN0IHBhcnRzIG9mIHRoZSBkZXZpY2UsIHRoYXQgY2Fu bm90IGJlIGFjY2Vzc2VkIGJ5IHRoZSB1c2VyICh0aGUgb3BlcmF0b3IgY2FuIHVzZSBpdCBmb3Ig d2hhdGV2ZXIgcmVhc29uLCBlLmcuIG5ldHdvcmsgc3BlY2lmaWMgY29uZmlndXJhdGlvbnMuLi4p PwoKNCkgICAgICAuLi4gCgogCgpJIGp1c3QgdGhpbmsgbG91ZCBKIE1heWJlIHdlIGRvbid0IHdh bnQgdG8gZGVhbCB3aXRoIHRoYXQsIGJ1dCBJIHRoaW5rIGl0IGNvdWxkIGJlIGludGVyZXN0aW5n IHRvIHRha2UgdGhvc2UgdGhpbmdzIGluIGFjY291bnQgdG9vLiAKCgpDYXJvbGluCgoKUCBHbyBH cmVlbiEgUHJpbnQgdGhpcyBlbWFpbCBvbmx5IHdoZW4gbmVjZXNzYXJ5LiBUaGFuayB5b3UgZm9y IGhlbHBpbmcgVGltZSBXYXJuZXIgQ2FibGUgYmUgZW52aXJvbm1lbnRhbGx5IHJlc3BvbnNpYmxl LgogCiAKVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g VGltZSBXYXJuZXIKQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZp bGVnZWQsIGNvbmZpZGVudGlhbCwKb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRv IFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbAppcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRo ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoCml0IGlzIGFkZHJlc3Nl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzCkUtbWFpbCwg eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwKZGlzdHJpYnV0 aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRz Cm9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVk IGFuZCBtYXkgYmUKdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5CnRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVu dGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueQpjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBh bnkgcHJpbnRvdXQuCg== From stephen.farrell@cs.tcd.ie Wed Jun 17 07:12:41 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 141B128C179 for ; Wed, 17 Jun 2009 07:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.724 X-Spam-Level: X-Spam-Status: No, score=-4.724 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 C0fnZSxS1Gb7 for ; Wed, 17 Jun 2009 07:12:35 -0700 (PDT) Received: from WA4EHSOBE004.bigfish.com (wa4ehsobe004.messaging.microsoft.com [216.32.181.14]) by core3.amsl.com (Postfix) with ESMTP id 9DA243A6C93 for ; Wed, 17 Jun 2009 07:12:35 -0700 (PDT) Received: from mail217-wa4-R.bigfish.com (10.8.14.244) by WA4EHSOBE004.bigfish.com (10.8.40.24) with Microsoft SMTP Server id 8.1.340.0; Wed, 17 Jun 2009 14:12:45 +0000 Received: from mail217-wa4 (localhost.localdomain [127.0.0.1]) by mail217-wa4-R.bigfish.com (Postfix) with ESMTP id 230C79E81BC; Wed, 17 Jun 2009 14:12:45 +0000 (UTC) X-SpamScore: 10 X-BigFish: VPS10(zz98dRzz1202hzzz2dh17ch6bh87il61h) X-Spam-TCS-SCL: 0:0 X-FB-DOMAIN-IP-MATCH: fail Received: by mail217-wa4 (MessageSwitch) id 1245247963964471_6140; Wed, 17 Jun 2009 14:12:43 +0000 (UCT) Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by mail217-wa4.bigfish.com (Postfix) with ESMTP id B803813F0060; Wed, 17 Jun 2009 14:12:43 +0000 (UTC) Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 236E768009; Wed, 17 Jun 2009 15:12:43 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A010611B71F; Wed, 17 Jun 2009 15:12:43 +0100 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id 0500968006; Wed, 17 Jun 2009 15:12:42 +0100 (IST) Message-ID: <4A38F9DB.7020700@cs.tcd.ie> Date: Wed, 17 Jun 2009 15:12:43 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: "Erichsen, Kirk" References: <7191A9FADFABE74F94A8403B82C57A61015EF97608@sg000036.corproot.net> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A110611B71F X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.107.15) Cc: Carolin.Latze@swisscom.com, homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 17 Jun 2009 14:12:41 -0000 Erichsen, Kirk wrote: > 1) Who manages the device? - I Think in most cases, 90% of the time it is the customer/end user. If so, then I think part of any spec here should include some sort of requirement for software/firmware update for the device. While there may not be a specific protocol for that that every vendor would want to use, this activity (if it becomes a WG) might be able to at least set requirements there. Stephen. From iljitsch@muada.com Wed Jun 17 09:26:10 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 138F03A6E8B for ; Wed, 17 Jun 2009 09:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.53 X-Spam-Level: X-Spam-Status: No, score=-5.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 8b5-gaE4FeoO for ; Wed, 17 Jun 2009 09:26:08 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id A2DF33A6E47 for ; Wed, 17 Jun 2009 09:26:08 -0700 (PDT) Received: from [192.168.49.123] (port-212-202-238-178.static.qsc.de [212.202.238.178]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n5HGQIcv096559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Jun 2009 18:26:20 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <49CB4627-0CAF-41D7-BF84-CCAA023CCDE0@muada.com> From: Iljitsch van Beijnum To: Richard Bennett In-Reply-To: <3AC8AFEF19E4426487FB01C031D7B5F6@Honkin> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 11:18:44 +0200 References: <7E6E35CE-AB91-400D-BD22-4BD6E1BD6986@americafree.tv> <3AF41F51-4411-4D34-B74A-4FA625B3B314@muada.com> <3AC8AFEF19E4426487FB01C031D7B5F6@Honkin> X-Mailer: Apple Mail (2.935.3) Cc: homegate@ietf.org Subject: Re: [homegate] Homegate and Multicast 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, 17 Jun 2009 16:26:10 -0000 On 16 jun 2009, at 22:16, Richard Bennett wrote: > One of the common ways around this problem - which is really a > defect in 802.11 - is to convert each multicast streams into a > series of > unicasts. So instead of a multicast stream going out at 2 Mb/s, you > have two > or three unicast streams at 54 (or higher, for 802.11n.) This didn't make sense to me at first, because the host then would see unicast packets. But now I realize that this would simply send an IP multicast packet, and possibly even an ethernet multicast packet, as an 802.11 unicast packet, right? This seems like a useful trick in a home gateway setup where we must assume that there may be significant interference and the number of hosts listening to the same multicast group probably wouldn't be too high. From iljitsch@muada.com Wed Jun 17 09:26: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 05D5D3A6D6B for ; Wed, 17 Jun 2009 09:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.53 X-Spam-Level: X-Spam-Status: No, score=-5.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 ghei5tNAHZtd for ; Wed, 17 Jun 2009 09:26:45 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF9F3A6E92 for ; Wed, 17 Jun 2009 09:26:45 -0700 (PDT) Received: from [192.168.49.123] (port-212-202-238-178.static.qsc.de [212.202.238.178]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n5HGQIcx096559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Jun 2009 18:26:46 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Richard Bennett In-Reply-To: <3AC8AFEF19E4426487FB01C031D7B5F6@Honkin> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 18:26:20 +0200 References: <7E6E35CE-AB91-400D-BD22-4BD6E1BD6986@americafree.tv> <3AF41F51-4411-4D34-B74A-4FA625B3B314@muada.com> <3AC8AFEF19E4426487FB01C031D7B5F6@Honkin> X-Mailer: Apple Mail (2.935.3) Cc: homegate@ietf.org Subject: Re: [homegate] Homegate and Multicast 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, 17 Jun 2009 16:26:46 -0000 On 16 jun 2009, at 22:16, Richard Bennett wrote: > One of the common ways around this problem - which is really a > defect in 802.11 - is to convert each multicast streams into a > series of > unicasts. So instead of a multicast stream going out at 2 Mb/s, you > have two > or three unicast streams at 54 (or higher, for 802.11n.) This didn't make sense to me at first, because the host then would see unicast packets. But now I realize that this would simply send an IP multicast packet, and possibly even an ethernet multicast packet, as an 802.11 unicast packet, right? This seems like a useful trick in a home gateway setup where we must assume that there may be significant interference and the number of hosts listening to the same multicast group probably wouldn't be too high. From mbaugher@cisco.com Wed Jun 17 10:06:31 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 7CF5B3A6E7A for ; Wed, 17 Jun 2009 10:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 RBWBAudBdDg1 for ; Wed, 17 Jun 2009 10:06:30 -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 A7D663A68B5 for ; Wed, 17 Jun 2009 10:06:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,238,1243814400"; d="scan'208";a="201466025" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 17 Jun 2009 16:58:57 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5HGwvZq022987; Wed, 17 Jun 2009 09:58:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5HGwvAV024087; Wed, 17 Jun 2009 16:58:57 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); Wed, 17 Jun 2009 09:58:57 -0700 Received: from sjc-mbaugher-8712.cisco.com ([10.19.93.35]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2009 09:58:56 -0700 Message-Id: <009C8209-1516-42D1-8370-0E002906728D@cisco.com> From: Mark Baugher To: Iljitsch van Beijnum In-Reply-To: <49CB4627-0CAF-41D7-BF84-CCAA023CCDE0@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 17 Jun 2009 09:58:56 -0700 References: <7E6E35CE-AB91-400D-BD22-4BD6E1BD6986@americafree.tv> <3AF41F51-4411-4D34-B74A-4FA625B3B314@muada.com> <3AC8AFEF19E4426487FB01C031D7B5F6@Honkin> <49CB4627-0CAF-41D7-BF84-CCAA023CCDE0@muada.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 17 Jun 2009 16:58:56.0982 (UTC) FILETIME=[E71E9F60:01C9EF6C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1132; t=1245257937; x=1246121937; c=relaxed/simple; s=sjdkim1004; 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=20and=20Multicast |Sender:=20; bh=GafFyxPXrSnYbykS4TLm9Y09hrnFD3VFkWrqP6MJKFY=; b=hITOwlaCyvgACB1eV4UxRS7hhG48rwNNIT5TNTul6eYRwCBf8P5YmIVS2T IktNwzknJJSoKGEBK99HFKBipNZHloiadsRUc/GnuBSxMzHVAgw8GvQzNkw9 v8zHl+xkBst51yOSpfGY+XdURBiLDlZmOSZdEABdX3SHxcev42Wh8=; Authentication-Results: sj-dkim-1; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: homegate@ietf.org Subject: Re: [homegate] Homegate and Multicast 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, 17 Jun 2009 17:06:31 -0000 On 17/06/2009, at 2:18 AM, Iljitsch van Beijnum wrote: > On 16 jun 2009, at 22:16, Richard Bennett wrote: > >> One of the common ways around this problem - which is really a >> defect in 802.11 - is to convert each multicast streams into a >> series of >> unicasts. So instead of a multicast stream going out at 2 Mb/s, you >> have two >> or three unicast streams at 54 (or higher, for 802.11n.) > > This didn't make sense to me at first, because the host then would > see unicast packets. But now I realize that this would simply send > an IP multicast packet, and possibly even an ethernet multicast > packet, as an 802.11 unicast packet, right? > > This seems like a useful trick in a home gateway setup where we must > assume that there may be significant interference and the number of > hosts listening to the same multicast group probably wouldn't be too > high. We don't do that today for setting up home gateways do we? Mark > > > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate From richard@bennett.com Wed Jun 17 13:18: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 7253128C2FA for ; Wed, 17 Jun 2009 13:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 ektqam7Ek2Ue for ; Wed, 17 Jun 2009 13:18:56 -0700 (PDT) Received: from outbound-mail-159.bluehost.com (outbound-mail-159.bluehost.com [67.222.39.39]) by core3.amsl.com (Postfix) with SMTP id 02A8A28C2FC for ; Wed, 17 Jun 2009 13:18:54 -0700 (PDT) Received: (qmail 25544 invoked by uid 0); 17 Jun 2009 20:19:06 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy5.bluehost.com with SMTP; 17 Jun 2009 20:19:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-index:x-mimeole:X-Identified-User; b=s90rFO5soTPNTX89iqPC6Tt8jhZEhgh5CbaARlh2fjIyqiiMUaEaSdW8q6PkOijrTf+Jt4b0ufDxhMJiUbBGtxEgjVpCc0yu4L2JAL6JtMWPww+cvQ7UvWxg3AF9mjPu; Received: from c-24-5-230-26.hsd1.ca.comcast.net ([24.5.230.26] helo=Honkin) by host46.hostmonster.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MH1b8-0004mf-BF; Wed, 17 Jun 2009 14:19:06 -0600 From: "Richard Bennett" To: "'Mark Baugher'" , "'Iljitsch van Beijnum'" References: <7E6E35CE-AB91-400D-BD22-4BD6E1BD6986@americafree.tv> <3AF41F51-4411-4D34-B74A-4FA625B3B314@muada.com> <3AC8AFEF19E4426487FB01C031D7B5F6@Honkin> <49CB4627-0CAF-41D7-BF84-CCAA023CCDE0@muada.com> <009C8209-1516-42D1-8370-0E002906728D@cisco.com> In-Reply-To: <009C8209-1516-42D1-8370-0E002906728D@cisco.com> Date: Wed, 17 Jun 2009 13:18:36 -0700 Message-ID: <716842E6E55E42C0B4DD5F2996BB8D79@Honkin> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-index: AcnvbOocj1gRqCWYTuGphA978D3SDwAG0ovg x-mimeole: Produced By Microsoft MimeOLE V6.0.6002.18005 X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 24.5.230.26 authed with richard+bennett.com} Cc: homegate@ietf.org Subject: Re: [homegate] Homegate and Multicast 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, 17 Jun 2009 20:18:57 -0000 Right, we convert the IP multicast to 802.11 unicast. Similar tricks are done to adapt IP to layer 2 networks that don't support broadcast or multicast addressing. This technique is used in many home gateways today, as well as in most enterprise WLAN switches. Not for doing the "setup," but for streaming to a smallish multicast group. Richard Bennett -----Original Message----- From: Mark Baugher [mailto:mbaugher@cisco.com] Sent: Wednesday, June 17, 2009 9:59 AM To: Iljitsch van Beijnum Cc: Richard Bennett; homegate@ietf.org Subject: Re: [homegate] Homegate and Multicast On 17/06/2009, at 2:18 AM, Iljitsch van Beijnum wrote: > On 16 jun 2009, at 22:16, Richard Bennett wrote: > >> One of the common ways around this problem - which is really a >> defect in 802.11 - is to convert each multicast streams into a >> series of >> unicasts. So instead of a multicast stream going out at 2 Mb/s, you >> have two >> or three unicast streams at 54 (or higher, for 802.11n.) > > This didn't make sense to me at first, because the host then would > see unicast packets. But now I realize that this would simply send > an IP multicast packet, and possibly even an ethernet multicast > packet, as an 802.11 unicast packet, right? > > This seems like a useful trick in a home gateway setup where we must > assume that there may be significant interference and the number of > hosts listening to the same multicast group probably wouldn't be too > high. We don't do that today for setting up home gateways do we? Mark > > > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate From mail@sabahattin-gucukoglu.com Thu Jun 18 02:04: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 DF1053A6C9E for ; Thu, 18 Jun 2009 02:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.603, 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 GZ1KylukQCuI for ; Thu, 18 Jun 2009 02:04:56 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id DFC933A69A1 for ; Thu, 18 Jun 2009 02:04:55 -0700 (PDT) Received: by ewy6 with SMTP id 6so1322041ewy.37 for ; Thu, 18 Jun 2009 02:05:04 -0700 (PDT) Received: by 10.216.29.80 with SMTP id h58mr343001wea.159.1245315904414; Thu, 18 Jun 2009 02:05:04 -0700 (PDT) Received: from ?192.168.1.3? (62-30-111-115.cable.ubr07.dals.blueyonder.co.uk [62.30.111.115]) by mx.google.com with ESMTPS id i34sm3991176gve.13.2009.06.18.02.05.02 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Jun 2009 02:05:03 -0700 (PDT) Message-Id: From: Sabahattin Gucukoglu To: homegate@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 18 Jun 2009 10:05:01 +0100 References: <7191A9FADFABE74F94A8403B82C57A61015EF97608@sg000036.corproot.net> X-Mailer: Apple Mail (2.935.3) Subject: Re: [homegate] Management of the Home Gateway 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, 18 Jun 2009 09:04:57 -0000 Here are my thoughts: The device does not necessarily have to be a home gateway. By way of example, look at Apple's Airport Express, and the numerous ways it can be used: as NAT box, as WAP/bridge, as extender, simply as print server and audio receiver ... I don't think, in a sentence, that it's right to deliberately constrain devices when there's no reason. Right now it's hard enough separating out layer 2 upstream from residential gateway, especially for DSL, since a lot of messing about has to happen to make a DSL modem that emulates a cable modem (because PPP brings the need to do things like layer 3 proxying of DHCP, for instance). I wonder Apple gets much sale at all - the real benefitiary of their products are cable modem users, or maybe PPPoE over anything users. In the meantime many DSL boxes already do NAT and we have a lot of double- natted subnetworks where consumers have tried to make a "Router" work with a "DSL modem". Of course, I don't say integrated devices are bad. But utilitarianism is what I believe in fundamentally, however simple the process is. Cheers, Sabahattin From jason_livingood@cable.comcast.com Thu Jun 18 12:57:01 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 D4DB53A69AE for ; Thu, 18 Jun 2009 12:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.097 X-Spam-Level: X-Spam-Status: No, score=-0.097 tagged_above=-999 required=5 tests=[AWL=-1.702, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 U3p6g3l+yGw2 for ; Thu, 18 Jun 2009 12:57:01 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 014883A6A37 for ; Thu, 18 Jun 2009 12:57:00 -0700 (PDT) Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.63760802; Thu, 18 Jun 2009 15:56:50 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Jun 2009 15:56:06 -0400 Received: from 147.191.227.143 ([147.191.227.143]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Thu, 18 Jun 2009 19:56:05 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 18 Jun 2009 15:56:01 -0400 From: "Livingood, Jason" To: Stephen Farrell , "Erichsen, Kirk" Message-ID: Thread-Topic: [homegate] Management of the Home Gateway Thread-Index: AcnwTs3wW7J6+O9yb0eRW8e2IgBNOA== In-Reply-To: <4A38F9DB.7020700@cs.tcd.ie> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Jun 2009 19:56:06.0420 (UTC) FILETIME=[D12BE540:01C9F04E] Cc: Carolin.Latze@swisscom.com, homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 18 Jun 2009 19:57:01 -0000 On 6/17/09 10:12 AM, "Stephen Farrell" wrote: > Erichsen, Kirk wrote: >> 1) Who manages the device? - I Think in most cases, 90% of the time it is the >> customer/end user. > > If so, then I think part of any spec here should include some sort > of requirement for software/firmware update for the device. While > there may not be a specific protocol for that that every vendor > would want to use, this activity (if it becomes a WG) might be > able to at least set requirements there. Firmware update methods were a topic of discussion when a few parties met to discuss the problem space in Philadelphia months ago. One of the issues is related to why web browsers and operating systems now perform automatic checks for updates. Today, this generally does not happen, though in some cases it can be prompted by the user savvy enough to visit the local device management web page periodically. In any case, there are regular security fixes which are made available and without recommendations on how updates should occur (user intervention, automatically downloaded, automatically applied, etc.) many devices leave this to the users -- and probably 90%+ of the user base will never upgrade the firmware on the device. Jason From kirk.erichsen@twcable.com Thu Jun 18 13:34:11 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 5077C3A6825 for ; Thu, 18 Jun 2009 13:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.454 X-Spam-Level: X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 SHQ2j+AgG7c0 for ; Thu, 18 Jun 2009 13:34:10 -0700 (PDT) Received: from pblpas01.twcable.com (pblpas01.twcable.com [204.235.121.149]) by core3.amsl.com (Postfix) with ESMTP id 3AB933A69AE for ; Thu, 18 Jun 2009 13:34:10 -0700 (PDT) X-SENDER-IP: 10.157.247.212 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,246,1243828800"; d="scan'208";a="424557144" Received: from unknown (HELO prvpmailconn2.corp.twcable.com) ([10.157.247.212]) by pblpas01.twcable.com with ESMTP; 18 Jun 2009 16:34:18 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn2.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Jun 2009 16:34:18 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Jun 2009 16:34:17 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Management of the Home Gateway thread-index: AcnwTs3wW7J6+O9yb0eRW8e2IgBNOAAAqErr References: From: "Erichsen, Kirk" To: "Livingood, Jason" , "Stephen Farrell" X-OriginalArrivalTime: 18 Jun 2009 20:34:18.0250 (UTC) FILETIME=[273566A0:01C9F054] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: Carolin.Latze@swisscom.com, homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 18 Jun 2009 20:34:11 -0000 CkFyZSB3ZSBvbmx5IGludGVyZXN0ZWQgaW4gYSBnZW5lcmljIHNvZnR3YXJlIG1lY2hhbmlzbSAo ImhvdyIpIHRoYXQgYmUgc3RhbmRhcmRpemVkLCB3aXRob3V0IHJlYWxseSB3b3JyeWluZyBhYm91 dCB0aGUgbWFuYWdlbWVudCBtb2RlbCAodGhlICJ3aG8iKT8KCgoKUCBHbyBHcmVlbiEgUHJpbnQg dGhpcyBlbWFpbCBvbmx5IHdoZW4gbmVjZXNzYXJ5LiBUaGFuayB5b3UgZm9yIGhlbHBpbmcgVGlt ZSBXYXJuZXIgQ2FibGUgYmUgZW52aXJvbm1lbnRhbGx5IHJlc3BvbnNpYmxlLgogCiAKLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogTGl2aW5nb29kLCBKYXNvbiBbbWFpbHRvOkphc29u X0xpdmluZ29vZEBjYWJsZS5jb21jYXN0LmNvbV0KU2VudDogVGh1IDYvMTgvMjAwOSAxOjU2IFBN ClRvOiBTdGVwaGVuIEZhcnJlbGw7IEVyaWNoc2VuLCBLaXJrCkNjOiBDYXJvbGluLkxhdHplQHN3 aXNzY29tLmNvbTsgaG9tZWdhdGVAaWV0Zi5vcmcKU3ViamVjdDogUmU6IFtob21lZ2F0ZV0gTWFu YWdlbWVudCBvZiB0aGUgSG9tZSBHYXRld2F5CiAKT24gNi8xNy8wOSAxMDoxMiBBTSwgIlN0ZXBo ZW4gRmFycmVsbCIgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+IHdyb3RlOgo+IEVyaWNoc2Vu LCBLaXJrIHdyb3RlOgo+PiAxKSBXaG8gbWFuYWdlcyB0aGUgZGV2aWNlPyAtIEkgVGhpbmsgaW4g bW9zdCBjYXNlcywgOTAlIG9mIHRoZSB0aW1lIGl0IGlzIHRoZQo+PiBjdXN0b21lci9lbmQgdXNl ci4KPiAKPiBJZiBzbywgdGhlbiBJIHRoaW5rIHBhcnQgb2YgYW55IHNwZWMgaGVyZSBzaG91bGQg aW5jbHVkZSBzb21lIHNvcnQKPiBvZiByZXF1aXJlbWVudCBmb3Igc29mdHdhcmUvZmlybXdhcmUg dXBkYXRlIGZvciB0aGUgZGV2aWNlLiBXaGlsZQo+IHRoZXJlIG1heSBub3QgYmUgYSBzcGVjaWZp YyBwcm90b2NvbCBmb3IgdGhhdCB0aGF0IGV2ZXJ5IHZlbmRvcgo+IHdvdWxkIHdhbnQgdG8gdXNl LCB0aGlzIGFjdGl2aXR5IChpZiBpdCBiZWNvbWVzIGEgV0cpIG1pZ2h0IGJlCj4gYWJsZSB0byBh dCBsZWFzdCBzZXQgcmVxdWlyZW1lbnRzIHRoZXJlLgoKRmlybXdhcmUgdXBkYXRlIG1ldGhvZHMg d2VyZSBhIHRvcGljIG9mIGRpc2N1c3Npb24gd2hlbiBhIGZldyBwYXJ0aWVzIG1ldCB0bwpkaXNj dXNzIHRoZSBwcm9ibGVtIHNwYWNlIGluIFBoaWxhZGVscGhpYSBtb250aHMgYWdvLiAgT25lIG9m IHRoZSBpc3N1ZXMgaXMKcmVsYXRlZCB0byB3aHkgd2ViIGJyb3dzZXJzIGFuZCBvcGVyYXRpbmcg c3lzdGVtcyBub3cgcGVyZm9ybSBhdXRvbWF0aWMKY2hlY2tzIGZvciB1cGRhdGVzLiAgVG9kYXks IHRoaXMgZ2VuZXJhbGx5IGRvZXMgbm90IGhhcHBlbiwgdGhvdWdoIGluIHNvbWUKY2FzZXMgaXQg Y2FuIGJlIHByb21wdGVkIGJ5IHRoZSB1c2VyIHNhdnZ5IGVub3VnaCB0byB2aXNpdCB0aGUgbG9j YWwgZGV2aWNlCm1hbmFnZW1lbnQgd2ViIHBhZ2UgcGVyaW9kaWNhbGx5LiAgSW4gYW55IGNhc2Us IHRoZXJlIGFyZSByZWd1bGFyIHNlY3VyaXR5CmZpeGVzIHdoaWNoIGFyZSBtYWRlIGF2YWlsYWJs ZSBhbmQgd2l0aG91dCByZWNvbW1lbmRhdGlvbnMgb24gaG93IHVwZGF0ZXMKc2hvdWxkIG9jY3Vy ICh1c2VyIGludGVydmVudGlvbiwgYXV0b21hdGljYWxseSBkb3dubG9hZGVkLCBhdXRvbWF0aWNh bGx5CmFwcGxpZWQsIGV0Yy4pIG1hbnkgZGV2aWNlcyBsZWF2ZSB0aGlzIHRvIHRoZSB1c2VycyAt LSBhbmQgcHJvYmFibHkgOTAlKyBvZgp0aGUgdXNlciBiYXNlIHdpbGwgbmV2ZXIgdXBncmFkZSB0 aGUgZmlybXdhcmUgb24gdGhlIGRldmljZS4KCkphc29uCgoKClRoaXMgRS1tYWlsIGFuZCBhbnkg b2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyCkNhYmxlIHByb3ByaWV0 YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsCm9yIHN1 YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBF LW1haWwKaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9y IGVudGl0eSB0byB3aGljaAppdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQgb2YgdGhpcwpFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRo YXQgYW55IGRpc3NlbWluYXRpb24sCmRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRh a2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cwpvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhp cyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlCnVubGF3ZnVsLiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeQp0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFu ZCBhbnkKY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lgo= From richard@bennett.com Thu Jun 18 18:57:30 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 D71333A67F1 for ; Thu, 18 Jun 2009 18:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 QT+PX8zyPO8Y for ; Thu, 18 Jun 2009 18:57:29 -0700 (PDT) Received: from outbound-mail-307.bluehost.com (outbound-mail-307.bluehost.com [67.222.53.253]) by core3.amsl.com (Postfix) with SMTP id A12E93A67A1 for ; Thu, 18 Jun 2009 18:57:29 -0700 (PDT) Received: (qmail 9048 invoked by uid 0); 19 Jun 2009 01:57:42 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy6.bluehost.com with SMTP; 19 Jun 2009 01:57:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:X-MimeOLE:X-Identified-User; b=OektVamup7qZBBNM19MGAFxleemmexzcBn9gPXtEgAeMU/Go1G0x2KAAaqQfgQB4Owe9BI6dvb/rt/EwsU+bU6jhACbMGRbglUqCik2CD+ZnCJ691gCR8oIloun8ghH1; Received: from c-24-5-230-26.hsd1.ca.comcast.net ([24.5.230.26] helo=Honkin) by host46.hostmonster.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MHTML-0002T9-QK; Thu, 18 Jun 2009 19:57:41 -0600 From: "Richard Bennett" To: "'Erichsen, Kirk'" , "'Livingood, Jason'" , "'Stephen Farrell'" References: In-Reply-To: Date: Thu, 18 Jun 2009 18:57:40 -0700 Organization: ITIF Message-ID: <043B361632634A649D357F73DB54F63D@Honkin> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnwTs3wW7J6+O9yb0eRW8e2IgBNOAAAqErrAAvUBSA= X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 24.5.230.26 authed with richard+bennett.com} Cc: Carolin.Latze@swisscom.com, homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: richard@bennett.com List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 01:57:31 -0000 The telco-deployed gateways are managed as CPE, using the TR stuff for firmware upgrades, but for the retail product about all we can do is advise customers to periodically apply upgrades the hard way. In a perfect world, I suppose there would be a single web site where both customers and support people could go to see what the latest revision is for every gateway, but this isn't such a world. Another option is to declare it a BCP to have an easy "check for upgrade" button on the first page of the gateway's GUI or something similar. Richard Bennett -----Original Message----- From: Erichsen, Kirk [mailto:kirk.erichsen@twcable.com] Sent: Thursday, June 18, 2009 1:34 PM To: Livingood, Jason; Stephen Farrell Cc: Carolin.Latze@swisscom.com; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway Are we only interested in a generic software mechanism ("how") that be standardized, without really worrying about the management model (the "who")? P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible. -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Sent: Thu 6/18/2009 1:56 PM To: Stephen Farrell; Erichsen, Kirk Cc: Carolin.Latze@swisscom.com; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway On 6/17/09 10:12 AM, "Stephen Farrell" wrote: > Erichsen, Kirk wrote: >> 1) Who manages the device? - I Think in most cases, 90% of the time it is the >> customer/end user. > > If so, then I think part of any spec here should include some sort > of requirement for software/firmware update for the device. While > there may not be a specific protocol for that that every vendor > would want to use, this activity (if it becomes a WG) might be > able to at least set requirements there. Firmware update methods were a topic of discussion when a few parties met to discuss the problem space in Philadelphia months ago. One of the issues is related to why web browsers and operating systems now perform automatic checks for updates. Today, this generally does not happen, though in some cases it can be prompted by the user savvy enough to visit the local device management web page periodically. In any case, there are regular security fixes which are made available and without recommendations on how updates should occur (user intervention, automatically downloaded, automatically applied, etc.) many devices leave this to the users -- and probably 90%+ of the user base will never upgrade the firmware on the device. Jason This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate From richard@bennett.com Fri Jun 19 01:10: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 4D2463A6A29 for ; Fri, 19 Jun 2009 01:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 pX0-XiayCqXj for ; Fri, 19 Jun 2009 01:10:02 -0700 (PDT) Received: from outbound-mail-310.bluehost.com (outbound-mail-310.bluehost.com [67.222.54.3]) by core3.amsl.com (Postfix) with SMTP id 38B553A6960 for ; Fri, 19 Jun 2009 01:10:02 -0700 (PDT) Received: (qmail 10788 invoked by uid 0); 19 Jun 2009 08:10:12 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy6.bluehost.com with SMTP; 19 Jun 2009 08:10:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-MimeOLE:Thread-Index:X-Identified-User; b=poO9O7pN+NxJImXoLqTVEHLV6Ki/8UKx1yCpahQ3+1Spsbj6itRhC7tMji/hNPOc7+GtpY2ZzNZQLk2gxpik9RnR0fj48V1l7x4wpbGrqhLc4lfTsFjl972wS0bfKjDO; Received: from c-24-5-230-26.hsd1.ca.comcast.net ([24.5.230.26] helo=RichardLaptop) by host46.hostmonster.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MHZAp-0006NI-HH; Fri, 19 Jun 2009 02:10:11 -0600 From: "Richard Bennett" To: , "'Erichsen, Kirk'" , "'Livingood, Jason'" , "'Stephen Farrell'" References: <043B361632634A649D357F73DB54F63D@Honkin> In-Reply-To: <043B361632634A649D357F73DB54F63D@Honkin> Date: Fri, 19 Jun 2009 01:10:09 -0700 Organization: Broadband Politics Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Thread-Index: AcnwTs3wW7J6+O9yb0eRW8e2IgBNOAAAqErrAAvUBSAADRJSsA== X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 24.5.230.26 authed with richard+bennett.com} Cc: Carolin.Latze@swisscom.com, homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 19 Jun 2009 08:10:03 -0000 Or even better, we can recommend that the gateway automatically check an ftp archive for updates and apply them like Windows does with patches. Vendors could allow this feature to be turned off by the skilled user, but by default it should be on. RB > -----Original Message----- > From: Richard Bennett [mailto:richard@bennett.com] > Sent: Thursday, June 18, 2009 6:58 PM > To: 'Erichsen, Kirk'; 'Livingood, Jason'; 'Stephen Farrell' > Cc: Carolin.Latze@swisscom.com; homegate@ietf.org > Subject: Re: [homegate] Management of the Home Gateway > > The telco-deployed gateways are managed as CPE, using the TR stuff for > firmware upgrades, but for the retail product about all we can do is > advise > customers to periodically apply upgrades the hard way. In a perfect world, > I > suppose there would be a single web site where both customers and support > people could go to see what the latest revision is for every gateway, but > this isn't such a world. > > Another option is to declare it a BCP to have an easy "check for upgrade" > button on the first page of the gateway's GUI or something similar. > > Richard Bennett > > -----Original Message----- > From: Erichsen, Kirk [mailto:kirk.erichsen@twcable.com] > Sent: Thursday, June 18, 2009 1:34 PM > To: Livingood, Jason; Stephen Farrell > Cc: Carolin.Latze@swisscom.com; homegate@ietf.org > Subject: Re: [homegate] Management of the Home Gateway > > > Are we only interested in a generic software mechanism ("how") that be > standardized, without really worrying about the management model (the > "who")? > > > > P Go Green! Print this email only when necessary. Thank you for helping > Time > Warner Cable be environmentally responsible. > > > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Thu 6/18/2009 1:56 PM > To: Stephen Farrell; Erichsen, Kirk > Cc: Carolin.Latze@swisscom.com; homegate@ietf.org > Subject: Re: [homegate] Management of the Home Gateway > > On 6/17/09 10:12 AM, "Stephen Farrell" wrote: > > Erichsen, Kirk wrote: > >> 1) Who manages the device? - I Think in most cases, 90% of the time it > is > the > >> customer/end user. > > > > If so, then I think part of any spec here should include some sort > > of requirement for software/firmware update for the device. While > > there may not be a specific protocol for that that every vendor > > would want to use, this activity (if it becomes a WG) might be > > able to at least set requirements there. > > Firmware update methods were a topic of discussion when a few parties met > to > discuss the problem space in Philadelphia months ago. One of the issues > is > related to why web browsers and operating systems now perform automatic > checks for updates. Today, this generally does not happen, though in some > cases it can be prompted by the user savvy enough to visit the local > device > management web page periodically. In any case, there are regular security > fixes which are made available and without recommendations on how updates > should occur (user intervention, automatically downloaded, automatically > applied, etc.) many devices leave this to the users -- and probably 90%+ > of > the user base will never upgrade the firmware on the device. > > Jason > > > > This E-mail and any of its attachments may contain Time Warner > Cable proprietary information, which is privileged, confidential, > or subject to copyright belonging to Time Warner Cable. This E-mail > is intended solely for the use of the individual or entity to which > it is addressed. If you are not the intended recipient of this > E-mail, you are hereby notified that any dissemination, > distribution, copying, or action taken in relation to the contents > of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. > _______________________________________________ > 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 stephen.farrell@cs.tcd.ie Fri Jun 19 03:39: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 DAA6D3A694D for ; Fri, 19 Jun 2009 03:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.293 X-Spam-Level: X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1] 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 EotTw2vS846U for ; Fri, 19 Jun 2009 03:39:05 -0700 (PDT) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id 5250828C0DE for ; Fri, 19 Jun 2009 03:39:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id B3C9E1003F549; Fri, 19 Jun 2009 11:39:12 +0100 (IST) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-WcEB79w-nH; Fri, 19 Jun 2009 11:39:11 +0100 (IST) Received: from [192.168.3.171] (unknown [192.168.3.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id 032BB1003F512; Fri, 19 Jun 2009 11:39:10 +0100 (IST) Message-ID: <4A3B6AD2.1000702@cs.tcd.ie> Date: Fri, 19 Jun 2009 11:39:14 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: Richard Bennett References: <043B361632634A649D357F73DB54F63D@Honkin> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'Livingood, Jason'" , Carolin.Latze@swisscom.com, homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 19 Jun 2009 10:39:06 -0000 Well, I'm not sure that all vendors would want to use the same protocol - I think pretty much everything in the desktop space that gets used is proprietary, so I think that we'd be more in the business of stating requirements, e.g. that there must be an auto-update that can be easily turned off and on, that the update protocol must strongly authenticate the source of updates, that updates must not have to happen on a single connection (trickle-updates) etc. I don't think there'd be too much work to get that done, so I could envisage a nice short RFC that'd be useful to vendors who were designing their own update schemes. OTOH, if there were a sufficient number of folks that wanted to define an IETF s/w update protocol that might be worthwhile, but I've not seen that demand. I guess the main argument for the IETF being involved in that would be to make it easier for vendors to just pick up something that's high quality, rather than making e.g. the security mistakes that might otherwise happen. However, it seems to me that that might need a WG all of its own, for which I doubt the interest exists. I still think it'd be useful for this group to specify update requirements since as others said, this is an area where embedded devices are sadly lacking. S. Richard Bennett wrote: > Or even better, we can recommend that the gateway automatically check an ftp > archive for updates and apply them like Windows does with patches. Vendors > could allow this feature to be turned off by the skilled user, but by > default it should be on. > > RB > >> -----Original Message----- >> From: Richard Bennett [mailto:richard@bennett.com] >> Sent: Thursday, June 18, 2009 6:58 PM >> To: 'Erichsen, Kirk'; 'Livingood, Jason'; 'Stephen Farrell' >> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >> Subject: Re: [homegate] Management of the Home Gateway >> >> The telco-deployed gateways are managed as CPE, using the TR stuff for >> firmware upgrades, but for the retail product about all we can do is >> advise >> customers to periodically apply upgrades the hard way. In a perfect world, >> I >> suppose there would be a single web site where both customers and support >> people could go to see what the latest revision is for every gateway, but >> this isn't such a world. >> >> Another option is to declare it a BCP to have an easy "check for upgrade" >> button on the first page of the gateway's GUI or something similar. >> >> Richard Bennett >> >> -----Original Message----- >> From: Erichsen, Kirk [mailto:kirk.erichsen@twcable.com] >> Sent: Thursday, June 18, 2009 1:34 PM >> To: Livingood, Jason; Stephen Farrell >> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >> Subject: Re: [homegate] Management of the Home Gateway >> >> >> Are we only interested in a generic software mechanism ("how") that be >> standardized, without really worrying about the management model (the >> "who")? >> >> >> >> P Go Green! Print this email only when necessary. Thank you for helping >> Time >> Warner Cable be environmentally responsible. >> >> >> -----Original Message----- >> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] >> Sent: Thu 6/18/2009 1:56 PM >> To: Stephen Farrell; Erichsen, Kirk >> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >> Subject: Re: [homegate] Management of the Home Gateway >> >> On 6/17/09 10:12 AM, "Stephen Farrell" wrote: >>> Erichsen, Kirk wrote: >>>> 1) Who manages the device? - I Think in most cases, 90% of the time it >> is >> the >>>> customer/end user. >>> If so, then I think part of any spec here should include some sort >>> of requirement for software/firmware update for the device. While >>> there may not be a specific protocol for that that every vendor >>> would want to use, this activity (if it becomes a WG) might be >>> able to at least set requirements there. >> Firmware update methods were a topic of discussion when a few parties met >> to >> discuss the problem space in Philadelphia months ago. One of the issues >> is >> related to why web browsers and operating systems now perform automatic >> checks for updates. Today, this generally does not happen, though in some >> cases it can be prompted by the user savvy enough to visit the local >> device >> management web page periodically. In any case, there are regular security >> fixes which are made available and without recommendations on how updates >> should occur (user intervention, automatically downloaded, automatically >> applied, etc.) many devices leave this to the users -- and probably 90%+ >> of >> the user base will never upgrade the firmware on the device. >> >> Jason >> >> >> >> This E-mail and any of its attachments may contain Time Warner >> Cable proprietary information, which is privileged, confidential, >> or subject to copyright belonging to Time Warner Cable. This E-mail >> is intended solely for the use of the individual or entity to which >> it is addressed. If you are not the intended recipient of this >> E-mail, you are hereby notified that any dissemination, >> distribution, copying, or action taken in relation to the contents >> of and attachments to this E-mail is strictly prohibited and may be >> unlawful. If you have received this E-mail in error, please notify >> the sender immediately and permanently delete the original and any >> copy of this E-mail and any printout. >> _______________________________________________ >> 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 kirk.erichsen@twcable.com Fri Jun 19 10:18:26 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 790343A684A for ; Fri, 19 Jun 2009 10:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.454 X-Spam-Level: X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 s6-xikPyWPXv for ; Fri, 19 Jun 2009 10:18:25 -0700 (PDT) Received: from pblpas01.twcable.com (pblpas01.twcable.com [204.235.121.149]) by core3.amsl.com (Postfix) with ESMTP id CB9813A6833 for ; Fri, 19 Jun 2009 10:18:24 -0700 (PDT) X-SENDER-IP: 10.157.247.213 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,254,1243828800"; d="scan'208";a="424841130" Received: from unknown (HELO prvpmailconn3.corp.twcable.com) ([10.157.247.213]) by pblpas01.twcable.com with ESMTP; 19 Jun 2009 13:18:37 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jun 2009 13:18:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Jun 2009 13:17:39 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Management of the Home Gateway Thread-Index: AcnwyjC2xWwknyddQHmSPP9WxN3DLQAN6hN9 References: <043B361632634A649D357F73DB54F63D@Honkin> <4A3B6AD2.1000702@cs.tcd.ie> From: "Erichsen, Kirk" To: "Stephen Farrell" , "Richard Bennett" X-OriginalArrivalTime: 19 Jun 2009 17:18:37.0662 (UTC) FILETIME=[FBAF97E0:01C9F101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: Carolin.Latze@swisscom.com, "Livingood, Jason" , homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 19 Jun 2009 17:18:26 -0000 I concur. Don't get hung up on the protocols, just keep the functions clear= and concise. Given the disparity in management models, this could easily b= ecome a time-sink without much value to the end product. =20 -KE ________________________________ From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Fri 6/19/2009 4:39 AM To: Richard Bennett Cc: Erichsen, Kirk; 'Livingood, Jason'; Carolin.Latze@swisscom.com; homegat= e@ietf.org Subject: Re: [homegate] Management of the Home Gateway Well, I'm not sure that all vendors would want to use the same protocol - I think pretty much everything in the desktop space that gets used is proprietary, so I think that we'd be more in the business of stating requirements, e.g. that there must be an auto-update that can be easily turned off and on, that the update protocol must strongly authenticate the source of updates, that updates must not have to happen on a single connection (trickle-updates) etc. I don't think there'd be too much work to get that done, so I could envisage a nice short RFC that'd be useful to vendors who were designing their own update schemes. OTOH, if there were a sufficient number of folks that wanted to define an IETF s/w update protocol that might be worthwhile, but I've not seen that demand. I guess the main argument for the IETF being involved in that would be to make it easier for vendors to just pick up something that's high quality, rather than making e.g. the security mistakes that might otherwise happen. However, it seems to me that that might need a WG all of its own, for which I doubt the interest exists. I still think it'd be useful for this group to specify update requirements since as others said, this is an area where embedded devices are sadly lacking. S. Richard Bennett wrote: > Or even better, we can recommend that the gateway automatically check an = ftp > archive for updates and apply them like Windows does with patches. Vendors > could allow this feature to be turned off by the skilled user, but by > default it should be on. > > RB > >> -----Original Message----- >> From: Richard Bennett [mailto:richard@bennett.com] >> Sent: Thursday, June 18, 2009 6:58 PM >> To: 'Erichsen, Kirk'; 'Livingood, Jason'; 'Stephen Farrell' >> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >> Subject: Re: [homegate] Management of the Home Gateway >> >> The telco-deployed gateways are managed as CPE, using the TR stuff for >> firmware upgrades, but for the retail product about all we can do is >> advise >> customers to periodically apply upgrades the hard way. In a perfect worl= d, >> I >> suppose there would be a single web site where both customers and support >> people could go to see what the latest revision is for every gateway, but >> this isn't such a world. >> >> Another option is to declare it a BCP to have an easy "check for upgrade" >> button on the first page of the gateway's GUI or something similar. >> >> Richard Bennett >> >> -----Original Message----- >> From: Erichsen, Kirk [mailto:kirk.erichsen@twcable.com] >> Sent: Thursday, June 18, 2009 1:34 PM >> To: Livingood, Jason; Stephen Farrell >> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >> Subject: Re: [homegate] Management of the Home Gateway >> >> >> Are we only interested in a generic software mechanism ("how") that be >> standardized, without really worrying about the management model (the >> "who")? >> >> >> >> P Go Green! Print this email only when necessary. Thank you for helping >> Time >> Warner Cable be environmentally responsible. >> >> >> -----Original Message----- >> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] >> Sent: Thu 6/18/2009 1:56 PM >> To: Stephen Farrell; Erichsen, Kirk >> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >> Subject: Re: [homegate] Management of the Home Gateway >> >> On 6/17/09 10:12 AM, "Stephen Farrell" wrote: >>> Erichsen, Kirk wrote: >>>> 1) Who manages the device? - I Think in most cases, 90% of the time it >> is >> the >>>> customer/end user. >>> If so, then I think part of any spec here should include some sort >>> of requirement for software/firmware update for the device. While >>> there may not be a specific protocol for that that every vendor >>> would want to use, this activity (if it becomes a WG) might be >>> able to at least set requirements there. >> Firmware update methods were a topic of discussion when a few parties met >> to >> discuss the problem space in Philadelphia months ago. One of the issues >> is >> related to why web browsers and operating systems now perform automatic >> checks for updates. Today, this generally does not happen, though in so= me >> cases it can be prompted by the user savvy enough to visit the local >> device >> management web page periodically. In any case, there are regular securi= ty >> fixes which are made available and without recommendations on how updates >> should occur (user intervention, automatically downloaded, automatically >> applied, etc.) many devices leave this to the users -- and probably 90%+ >> of >> the user base will never upgrade the firmware on the device. >> >> Jason >> >> >> >> This E-mail and any of its attachments may contain Time Warner >> Cable proprietary information, which is privileged, confidential, >> or subject to copyright belonging to Time Warner Cable. This E-mail >> is intended solely for the use of the individual or entity to which >> it is addressed. If you are not the intended recipient of this >> E-mail, you are hereby notified that any dissemination, >> distribution, copying, or action taken in relation to the contents >> of and attachments to this E-mail is strictly prohibited and may be >> unlawful. If you have received this E-mail in error, please notify >> the sender immediately and permanently delete the original and any >> copy of this E-mail and any printout. >> _______________________________________________ >> 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 > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From richard@bennett.com Fri Jun 19 11:57: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 DBBCA3A68D7 for ; Fri, 19 Jun 2009 11:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 jgKiH-XU5hkt for ; Fri, 19 Jun 2009 11:57:33 -0700 (PDT) Received: from outbound-mail-136.bluehost.com (outbound-mail-136.bluehost.com [67.222.39.26]) by core3.amsl.com (Postfix) with SMTP id 8F39A3A684A for ; Fri, 19 Jun 2009 11:57:33 -0700 (PDT) Received: (qmail 26283 invoked by uid 0); 19 Jun 2009 18:57:45 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy4.bluehost.com with SMTP; 19 Jun 2009 18:57:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:X-MimeOLE:X-Identified-User; b=EGqgjk3B1v+SDLxNIfn3lJpjcp1CE5FTZFmEWmCl/Ox4rzVTaqPW6GjoEigw6K+A37q5rloMfbYdqeCW3fT93znJaIRs1qlioby3rU77IIqKrwvPvuCt7so8YM1PVzFG; Received: from c-24-5-230-26.hsd1.ca.comcast.net ([24.5.230.26] helo=Honkin) by host46.hostmonster.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MHjHV-0006lQ-8P; Fri, 19 Jun 2009 12:57:45 -0600 From: "Richard Bennett" To: "'Erichsen, Kirk'" , "'Stephen Farrell'" References: <043B361632634A649D357F73DB54F63D@Honkin> <4A3B6AD2.1000702@cs.tcd.ie> In-Reply-To: Date: Fri, 19 Jun 2009 11:57:39 -0700 Organization: ITIF Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnwyjC2xWwknyddQHmSPP9WxN3DLQAN6hN9AAN2GaA= X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 24.5.230.26 authed with richard+bennett.com} Cc: Carolin.Latze@swisscom.com, "'Livingood, Jason'" , homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: richard@bennett.com List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 18:57:34 -0000 I agree it's the function that matters, not the means. Take my reference to ftp below as a "for example." Richard Bennett -----Original Message----- From: Erichsen, Kirk [mailto:kirk.erichsen@twcable.com] Sent: Friday, June 19, 2009 10:18 AM To: Stephen Farrell; Richard Bennett Cc: Livingood, Jason; Carolin.Latze@swisscom.com; homegate@ietf.org Subject: RE: [homegate] Management of the Home Gateway I concur. Don't get hung up on the protocols, just keep the functions clear and concise. Given the disparity in management models, this could easily become a time-sink without much value to the end product. -KE ________________________________ From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Fri 6/19/2009 4:39 AM To: Richard Bennett Cc: Erichsen, Kirk; 'Livingood, Jason'; Carolin.Latze@swisscom.com; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway Well, I'm not sure that all vendors would want to use the same protocol - I think pretty much everything in the desktop space that gets used is proprietary, so I think that we'd be more in the business of stating requirements, e.g. that there must be an auto-update that can be easily turned off and on, that the update protocol must strongly authenticate the source of updates, that updates must not have to happen on a single connection (trickle-updates) etc. I don't think there'd be too much work to get that done, so I could envisage a nice short RFC that'd be useful to vendors who were designing their own update schemes. OTOH, if there were a sufficient number of folks that wanted to define an IETF s/w update protocol that might be worthwhile, but I've not seen that demand. I guess the main argument for the IETF being involved in that would be to make it easier for vendors to just pick up something that's high quality, rather than making e.g. the security mistakes that might otherwise happen. However, it seems to me that that might need a WG all of its own, for which I doubt the interest exists. I still think it'd be useful for this group to specify update requirements since as others said, this is an area where embedded devices are sadly lacking. S. Richard Bennett wrote: > Or even better, we can recommend that the gateway automatically check an ftp > archive for updates and apply them like Windows does with patches. Vendors > could allow this feature to be turned off by the skilled user, but by > default it should be on. > > RB > >> -----Original Message----- >> From: Richard Bennett [mailto:richard@bennett.com] >> Sent: Thursday, June 18, 2009 6:58 PM >> To: 'Erichsen, Kirk'; 'Livingood, Jason'; 'Stephen Farrell' >> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >> Subject: Re: [homegate] Management of the Home Gateway >> >> The telco-deployed gateways are managed as CPE, using the TR stuff for >> firmware upgrades, but for the retail product about all we can do is >> advise >> customers to periodically apply upgrades the hard way. In a perfect world, >> I >> suppose there would be a single web site where both customers and support >> people could go to see what the latest revision is for every gateway, but >> this isn't such a world. >> >> Another option is to declare it a BCP to have an easy "check for upgrade" >> button on the first page of the gateway's GUI or something similar. >> >> Richard Bennett >> >> -----Original Message----- >> From: Erichsen, Kirk [mailto:kirk.erichsen@twcable.com] >> Sent: Thursday, June 18, 2009 1:34 PM >> To: Livingood, Jason; Stephen Farrell >> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >> Subject: Re: [homegate] Management of the Home Gateway >> >> >> Are we only interested in a generic software mechanism ("how") that be >> standardized, without really worrying about the management model (the >> "who")? >> >> >> >> P Go Green! Print this email only when necessary. Thank you for helping >> Time >> Warner Cable be environmentally responsible. >> >> >> -----Original Message----- >> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] >> Sent: Thu 6/18/2009 1:56 PM >> To: Stephen Farrell; Erichsen, Kirk >> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >> Subject: Re: [homegate] Management of the Home Gateway >> >> On 6/17/09 10:12 AM, "Stephen Farrell" wrote: >>> Erichsen, Kirk wrote: >>>> 1) Who manages the device? - I Think in most cases, 90% of the time it >> is >> the >>>> customer/end user. >>> If so, then I think part of any spec here should include some sort >>> of requirement for software/firmware update for the device. While >>> there may not be a specific protocol for that that every vendor >>> would want to use, this activity (if it becomes a WG) might be >>> able to at least set requirements there. >> Firmware update methods were a topic of discussion when a few parties met >> to >> discuss the problem space in Philadelphia months ago. One of the issues >> is >> related to why web browsers and operating systems now perform automatic >> checks for updates. Today, this generally does not happen, though in some >> cases it can be prompted by the user savvy enough to visit the local >> device >> management web page periodically. In any case, there are regular security >> fixes which are made available and without recommendations on how updates >> should occur (user intervention, automatically downloaded, automatically >> applied, etc.) many devices leave this to the users -- and probably 90%+ >> of >> the user base will never upgrade the firmware on the device. >> >> Jason >> >> >> >> This E-mail and any of its attachments may contain Time Warner >> Cable proprietary information, which is privileged, confidential, >> or subject to copyright belonging to Time Warner Cable. This E-mail >> is intended solely for the use of the individual or entity to which >> it is addressed. If you are not the intended recipient of this >> E-mail, you are hereby notified that any dissemination, >> distribution, copying, or action taken in relation to the contents >> of and attachments to this E-mail is strictly prohibited and may be >> unlawful. If you have received this E-mail in error, please notify >> the sender immediately and permanently delete the original and any >> copy of this E-mail and any printout. >> _______________________________________________ >> 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 > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From kirk.erichsen@twcable.com Fri Jun 19 12:02: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 843863A6A02 for ; Fri, 19 Jun 2009 12:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 VpfAfea-pKrC for ; Fri, 19 Jun 2009 12:02:23 -0700 (PDT) Received: from pblpas02.twcable.com (pblpas02.twcable.com [204.235.121.150]) by core3.amsl.com (Postfix) with ESMTP id 2978D3A6969 for ; Fri, 19 Jun 2009 12:02:23 -0700 (PDT) X-SENDER-IP: 10.157.247.211 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,255,1243828800"; d="scan'208";a="424010922" Received: from unknown (HELO prvpmailconn1.corp.twcable.com) ([10.157.247.211]) by pblpas02.twcable.com with ESMTP; 19 Jun 2009 15:02:30 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn1.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jun 2009 15:02:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Jun 2009 15:02:09 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Management of the Home Gateway Thread-Index: AcnwyjC2xWwknyddQHmSPP9WxN3DLQAN6hN9AAN2GaAAADAuMA== References: <043B361632634A649D357F73DB54F63D@Honkin> <4A3B6AD2.1000702@cs.tcd.ie> From: "Erichsen, Kirk" To: , "Stephen Farrell" X-OriginalArrivalTime: 19 Jun 2009 19:02:30.0219 (UTC) FILETIME=[7E9451B0:01C9F110] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: Carolin.Latze@swisscom.com, "Livingood, Jason" , homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 19 Jun 2009 19:02:24 -0000 Richard, =20 That was how I interpreted it. :) =20 -KE ________________________________ From: Richard Bennett [mailto:richard@bennett.com] Sent: Fri 6/19/2009 12:57 PM To: Erichsen, Kirk; 'Stephen Farrell' Cc: 'Livingood, Jason'; Carolin.Latze@swisscom.com; homegate@ietf.org Subject: RE: [homegate] Management of the Home Gateway I agree it's the function that matters, not the means. Take my reference to ftp below as a "for example." Richard Bennett -----Original Message----- From: Erichsen, Kirk [mailto:kirk.erichsen@twcable.com] Sent: Friday, June 19, 2009 10:18 AM To: Stephen Farrell; Richard Bennett Cc: Livingood, Jason; Carolin.Latze@swisscom.com; homegate@ietf.org Subject: RE: [homegate] Management of the Home Gateway I concur. Don't get hung up on the protocols, just keep the functions clear and concise. Given the disparity in management models, this could easily become a time-sink without much value to the end product. -KE ________________________________ From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Fri 6/19/2009 4:39 AM To: Richard Bennett Cc: Erichsen, Kirk; 'Livingood, Jason'; Carolin.Latze@swisscom.com; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway Well, I'm not sure that all vendors would want to use the same protocol - I think pretty much everything in the desktop space that gets used is proprietary, so I think that we'd be more in the business of stating requirements, e.g. that there must be an auto-update that can be easily turned off and on, that the update protocol must strongly authenticate the source of updates, that updates must not have to happen on a single connection (trickle-updates) etc. I don't think there'd be too much work to get that done, so I could envisage a nice short RFC that'd be useful to vendors who were designing their own update schemes. OTOH, if there were a sufficient number of folks that wanted to define an IETF s/w update protocol that might be worthwhile, but I've not seen that demand. I guess the main argument for the IETF being involved in that would be to make it easier for vendors to just pick up something that's high quality, rather than making e.g. the security mistakes that might otherwise happen. However, it seems to me that that might need a WG all of its own, for which I doubt the interest exists. I still think it'd be useful for this group to specify update requirements since as others said, this is an area where embedded devices are sadly lacking. S. Richard Bennett wrote: > Or even better, we can recommend that the gateway automatically check an ftp > archive for updates and apply them like Windows does with patches. Vendors > could allow this feature to be turned off by the skilled user, but by > default it should be on. > > RB > >> -----Original Message----- >> From: Richard Bennett [mailto:richard@bennett.com] >> Sent: Thursday, June 18, 2009 6:58 PM >> To: 'Erichsen, Kirk'; 'Livingood, Jason'; 'Stephen Farrell' >> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >> Subject: Re: [homegate] Management of the Home Gateway >> >> The telco-deployed gateways are managed as CPE, using the TR stuff for >> firmware upgrades, but for the retail product about all we can do is >> advise >> customers to periodically apply upgrades the hard way. In a perfect world, >> I >> suppose there would be a single web site where both customers and support >> people could go to see what the latest revision is for every gateway, but >> this isn't such a world. >> >> Another option is to declare it a BCP to have an easy "check for upgrade" >> button on the first page of the gateway's GUI or something similar. >> >> Richard Bennett >> >> -----Original Message----- >> From: Erichsen, Kirk [mailto:kirk.erichsen@twcable.com] >> Sent: Thursday, June 18, 2009 1:34 PM >> To: Livingood, Jason; Stephen Farrell >> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >> Subject: Re: [homegate] Management of the Home Gateway >> >> >> Are we only interested in a generic software mechanism ("how") that be >> standardized, without really worrying about the management model (the >> "who")? >> >> >> >> P Go Green! Print this email only when necessary. Thank you for helping >> Time >> Warner Cable be environmentally responsible. >> >> >> -----Original Message----- >> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] >> Sent: Thu 6/18/2009 1:56 PM >> To: Stephen Farrell; Erichsen, Kirk >> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >> Subject: Re: [homegate] Management of the Home Gateway >> >> On 6/17/09 10:12 AM, "Stephen Farrell" wrote: >>> Erichsen, Kirk wrote: >>>> 1) Who manages the device? - I Think in most cases, 90% of the time it >> is >> the >>>> customer/end user. >>> If so, then I think part of any spec here should include some sort >>> of requirement for software/firmware update for the device. While >>> there may not be a specific protocol for that that every vendor >>> would want to use, this activity (if it becomes a WG) might be >>> able to at least set requirements there. >> Firmware update methods were a topic of discussion when a few parties met >> to >> discuss the problem space in Philadelphia months ago. One of the issues >> is >> related to why web browsers and operating systems now perform automatic >> checks for updates. Today, this generally does not happen, though in some >> cases it can be prompted by the user savvy enough to visit the local >> device >> management web page periodically. In any case, there are regular security >> fixes which are made available and without recommendations on how updates >> should occur (user intervention, automatically downloaded, automatically >> applied, etc.) many devices leave this to the users -- and probably 90%+ >> of >> the user base will never upgrade the firmware on the device. >> >> Jason >> >> >> >> This E-mail and any of its attachments may contain Time Warner >> Cable proprietary information, which is privileged, confidential, >> or subject to copyright belonging to Time Warner Cable. This E-mail >> is intended solely for the use of the individual or entity to which >> it is addressed. If you are not the intended recipient of this >> E-mail, you are hereby notified that any dissemination, >> distribution, copying, or action taken in relation to the contents >> of and attachments to this E-mail is strictly prohibited and may be >> unlawful. If you have received this E-mail in error, please notify >> the sender immediately and permanently delete the original and any >> copy of this E-mail and any printout. >> _______________________________________________ >> 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 > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From iljitsch@muada.com Fri Jun 19 16:32:48 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 432083A6A4E for ; Fri, 19 Jun 2009 16:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.92 X-Spam-Level: X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 UXAflwfJBPr6 for ; Fri, 19 Jun 2009 16:32:47 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 4130F3A693E for ; Fri, 19 Jun 2009 16:32:47 -0700 (PDT) Received: from [192.168.2.4] (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 n5JNWw6J015316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 20 Jun 2009 01:33:01 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <60A57350-253F-4E50-B635-BF85B51ED72B@muada.com> From: Iljitsch van Beijnum To: In-Reply-To: <7191A9FADFABE74F94A8403B82C57A61015EF975EA@sg000036.corproot.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 19 Jun 2009 17:22:10 +0200 References: <7191A9FADFABE74F94A8403B82C57A61015EF975EA@sg000036.corproot.net> X-Mailer: Apple Mail (2.935.3) Cc: homegate@ietf.org Subject: Re: [homegate] Smart Metering / M2M 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, 19 Jun 2009 23:32:48 -0000 On 17 jun 2009, at 9:40, wrote: > with smart metering (at least in the EU), M2M applications will > become more common also for end-users. > Don't know what M2M means... In the case of smart metering, where a service provider that isn't the _internet_ service provider wants connectivity to devices in the home, things get interesting. For instance, what if the utility company wants to borrow some capacity on my internet connection for smart metering but I don't have one? I guess this is often/usually solved by installing their own connectivity, which would be effective but wasteful. I can envision a situation where utility companies etc get to use a little bandwidth (at an extra-low traffic class) on through _any_ home gateway that they can connect to (over wifi or maybe through IP-over-electricity grid) regardless of whether this home gateway belongs to the exact same customer as the meter in question. Of course there are some authentication/authorization issues here. One of the issues that I as a home user have is that my internal network is kept safe from devices that I have little control over, such as utility meters, IP refrigirators and so on, which the utility company or refrigiration service provider or what have you, or, more likely, anyone who manages to hack into these devices, could use to spy on my local traffic. From richard@bennett.com Fri Jun 19 16:41:52 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 1FFCD3A6A4E for ; Fri, 19 Jun 2009 16:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 E74fwtchJ6D0 for ; Fri, 19 Jun 2009 16:41:51 -0700 (PDT) Received: from outbound-mail-318.bluehost.com (outbound-mail-318.bluehost.com [67.222.54.250]) by core3.amsl.com (Postfix) with SMTP id 518AA3A693E for ; Fri, 19 Jun 2009 16:41:51 -0700 (PDT) Received: (qmail 8639 invoked by uid 0); 19 Jun 2009 23:42:04 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy6.bluehost.com with SMTP; 19 Jun 2009 23:42:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:X-MimeOLE:X-Identified-User; b=UwG/OghLYA0Frb6Zk2Y1cw1my/kYXKTd3+I9CGHfoNATp7oSvebYXCBhGnuB2wCKVPFaymY0p8lZg11O+v65lUlWm6ViWfWx05/ftLGRQbEcJB7qFyAZM/HqHuU8M+KQ; Received: from c-24-5-230-26.hsd1.ca.comcast.net ([24.5.230.26] helo=Honkin) by host46.hostmonster.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MHnie-000711-E5; Fri, 19 Jun 2009 17:42:04 -0600 From: "Richard Bennett" To: "'Iljitsch van Beijnum'" , References: <7191A9FADFABE74F94A8403B82C57A61015EF975EA@sg000036.corproot.net> <60A57350-253F-4E50-B635-BF85B51ED72B@muada.com> In-Reply-To: <60A57350-253F-4E50-B635-BF85B51ED72B@muada.com> Date: Fri, 19 Jun 2009 16:41:57 -0700 Organization: ITIF Message-ID: <66E7DC0CCC5643979CA5D787DBDC74FA@Honkin> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnxNktD9CKOo5SMQYy83LmeTII8ggAALujA X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 24.5.230.26 authed with richard+bennett.com} Cc: homegate@ietf.org Subject: Re: [homegate] Smart Metering / M2M X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: richard@bennett.com List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 23:41:52 -0000 I don't think we're anywhere close to being able to write specific BCPs for smartgrid monitoring and control. Regarding the question of grabbing other people's bandwidth, you're likely to run afoul of the law in many jurisdictions if you want to do that. The Homeplug networking folks (LAN over home power lines) ran into a problem simply trying to coordinate beacons in neighboring houses because it would have required deliberately sending an unsolicited message. It seems to me that we can draw a bright line between current, well-understood practices and things that someone might want to do in the future. This activity needs to have a here-and-now focus. Richard Bennett -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] Sent: Friday, June 19, 2009 8:22 AM To: Carolin.Latze@swisscom.com Cc: homegate@ietf.org Subject: Re: [homegate] Smart Metering / M2M On 17 jun 2009, at 9:40, wrote: > with smart metering (at least in the EU), M2M applications will > become more common also for end-users. > Don't know what M2M means... In the case of smart metering, where a service provider that isn't the _internet_ service provider wants connectivity to devices in the home, things get interesting. For instance, what if the utility company wants to borrow some capacity on my internet connection for smart metering but I don't have one? I guess this is often/usually solved by installing their own connectivity, which would be effective but wasteful. I can envision a situation where utility companies etc get to use a little bandwidth (at an extra-low traffic class) on through _any_ home gateway that they can connect to (over wifi or maybe through IP-over-electricity grid) regardless of whether this home gateway belongs to the exact same customer as the meter in question. Of course there are some authentication/authorization issues here. One of the issues that I as a home user have is that my internal network is kept safe from devices that I have little control over, such as utility meters, IP refrigirators and so on, which the utility company or refrigiration service provider or what have you, or, more likely, anyone who manages to hack into these devices, could use to spy on my local traffic. _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate From mail@sabahattin-gucukoglu.com Sat Jun 20 01:44: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 5EBF23A6B48 for ; Sat, 20 Jun 2009 01:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=0.469, 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 3TvxVgy9WsdV for ; Sat, 20 Jun 2009 01:44:39 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 196253A6816 for ; Sat, 20 Jun 2009 01:44:37 -0700 (PDT) Received: by ewy6 with SMTP id 6so3233595ewy.37 for ; Sat, 20 Jun 2009 01:44:48 -0700 (PDT) Received: by 10.216.21.205 with SMTP id r55mr1403008wer.175.1245487488701; Sat, 20 Jun 2009 01:44:48 -0700 (PDT) Received: from ?192.168.1.3? (62-30-111-115.cable.ubr07.dals.blueyonder.co.uk [62.30.111.115]) by mx.google.com with ESMTPS id t12sm9985841gvd.21.2009.06.20.01.44.47 (version=SSLv3 cipher=RC4-MD5); Sat, 20 Jun 2009 01:44:47 -0700 (PDT) Message-Id: <79BEDD96-B3D8-426E-A2A1-FB2F3F5D6C51@sabahattin-gucukoglu.com> From: Sabahattin Gucukoglu To: homegate@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 20 Jun 2009 09:44:45 +0100 References: <043B361632634A649D357F73DB54F63D@Honkin> X-Mailer: Apple Mail (2.935.3) Subject: Re: [homegate] Management of the Home Gateway 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: Sat, 20 Jun 2009 08:44:40 -0000 On 19 Jun 2009, at 09:10, Richard Bennett wrote: > Or even better, we can recommend that the gateway automatically > check an ftp > archive for updates and apply them like Windows does with patches. > Vendors > could allow this feature to be turned off by the skilled user, but by > default it should be on. There'll be screams of cold bloody murder if this sort of thing gets used for evil purposes like interception and/or monitoring. Some people like the control over installed software. Windows, with its multitude of unwanted critical patches, goes for example. As a general rule I doubt most people will care but I think users should probably be notified in advance that their gateway has a will of its own. Cheers, Sabahattin From mail@sabahattin-gucukoglu.com Sat Jun 20 06:24: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 905063A6CF3 for ; Sat, 20 Jun 2009 06:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.422, 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 PFwWkoUE7Iri for ; Sat, 20 Jun 2009 06:24:25 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 976123A6CED for ; Sat, 20 Jun 2009 06:24:24 -0700 (PDT) Received: by bwz9 with SMTP id 9so2243515bwz.37 for ; Sat, 20 Jun 2009 06:24:35 -0700 (PDT) Received: by 10.216.53.83 with SMTP id f61mr1478620wec.33.1245504273644; Sat, 20 Jun 2009 06:24:33 -0700 (PDT) Received: from ?192.168.1.3? ([62.30.111.115]) by mx.google.com with ESMTPS id p37sm10727521gvf.12.2009.06.20.06.24.30 (version=SSLv3 cipher=RC4-MD5); Sat, 20 Jun 2009 06:24:32 -0700 (PDT) Message-Id: From: Sabahattin Gucukoglu To: homegate@ietf.org In-Reply-To: <60A57350-253F-4E50-B635-BF85B51ED72B@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 20 Jun 2009 14:24:29 +0100 References: <7191A9FADFABE74F94A8403B82C57A61015EF975EA@sg000036.corproot.net> <60A57350-253F-4E50-B635-BF85B51ED72B@muada.com> X-Mailer: Apple Mail (2.935.3) Subject: Re: [homegate] Smart Metering / M2M 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: Sat, 20 Jun 2009 13:24:25 -0000 On 19 Jun 2009, at 16:22, Iljitsch van Beijnum wrote: > For instance, what if the utility company wants to borrow some > capacity on my internet connection for smart metering but I don't > have one? On a related note, for appliances needed to gain utilities like for instance VoIP, a service provider often wants his box between yours and your main pipe in order to gain the necessary QoS. (Presumably, there is a case to be made for getting working QoS markings supported by homegates.) I'm not in favour of either needing alternative connectivity for utilities, nor particularly of tampering with the network. I should, and consumers should, be able to just plug it in and make it work (trademark, patent applied for). Cheers, Sabahattin From Carolin.Latze@swisscom.com Sun Jun 21 23:59:12 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 AB6BE28C0F5 for ; Sun, 21 Jun 2009 23:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 8CZdpfsSp2yS for ; Sun, 21 Jun 2009 23:59:11 -0700 (PDT) Received: from mail.swisscom.com (outmail21.swisscom.com [138.190.32.11]) by core3.amsl.com (Postfix) with ESMTP id 8DB553A6835 for ; Sun, 21 Jun 2009 23:59:10 -0700 (PDT) Received: by mrp.swissptt.ch; Mon, 22 Jun 2009 08:59:23 +0200 (MEST) From: To: , Date: Mon, 22 Jun 2009 08:59:14 +0200 Thread-Topic: [homegate] Management of the Home Gateway Thread-Index: Acnxg3kaShvPJgE0Q++6OUpMvNr2OgBgtIiw Message-ID: <7191A9FADFABE74F94A8403B82C57A61015F243060@sg000036.corproot.net> References: <043B361632634A649D357F73DB54F63D@Honkin> <79BEDD96-B3D8-426E-A2A1-FB2F3F5D6C51@sabahattin-gucukoglu.com> In-Reply-To: <79BEDD96-B3D8-426E-A2A1-FB2F3F5D6C51@sabahattin-gucukoglu.com> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-CH Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homegate] Management of the Home Gateway 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, 22 Jun 2009 06:59:12 -0000 I agree, that people *should* be notified, but it is not necessarily the ca= se today. My (ISP) DSL router for instances updates itself from time to tim= e. There is nothing I can do about it. One of the updates moved the wireles= s configuration to my ISP's server (not really sure why but I have a theory= that might make sense) and even if I - as an experienced and skilled user = - do not want that, I have to accept that or install an additional AP. So, = probably we should try to find a trade-off between what we - as techies - w= ould like to have and what a normal user needs/ requests. As you said, most= of the people won't care (even if they should :( ) Carolin -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behal= f Of Sabahattin Gucukoglu Sent: Samstag, 20. Juni 2009 10:45 To: homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway On 19 Jun 2009, at 09:10, Richard Bennett wrote: > Or even better, we can recommend that the gateway automatically =20 > check an ftp > archive for updates and apply them like Windows does with patches. =20 > Vendors > could allow this feature to be turned off by the skilled user, but by > default it should be on. There'll be screams of cold bloody murder if this sort of thing gets =20 used for evil purposes like interception and/or monitoring. Some =20 people like the control over installed software. Windows, with its =20 multitude of unwanted critical patches, goes for example. As a =20 general rule I doubt most people will care but I think users should =20 probably be notified in advance that their gateway has a will of its =20 own. Cheers, Sabahattin _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate From iljitsch@muada.com Mon Jun 22 06:15: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 B30363A6A05 for ; Mon, 22 Jun 2009 06:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 9WOC-wibEwGc for ; Mon, 22 Jun 2009 06:15:29 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id BEE3D28C1B9 for ; Mon, 22 Jun 2009 06:15:28 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n5MDEFku036527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Jun 2009 15:14:15 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Richard Bennett In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 22 Jun 2009 15:13:47 +0200 References: <043B361632634A649D357F73DB54F63D@Honkin> X-Mailer: Apple Mail (2.935.3) Cc: "'Livingood, Jason'" , Carolin.Latze@swisscom.com, homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 22 Jun 2009 13:15:29 -0000 On 19 jun 2009, at 10:10, Richard Bennett wrote: > Or even better, we can recommend that the gateway automatically > check an ftp > archive for updates and apply them like Windows does with patches. > Vendors > could allow this feature to be turned off by the skilled user, but by > default it should be on. No, it shouldn't be. Updates often cause just as many problems as they solve. Having a home gateway that worked just fine break because someone decided to push out an update is completely unacceptable. Especially because update procedures are often lengthy, may render the device unusable if interrupted, and if the device ends up in a non- working state there is no recovery because there is no internet connection. From iiarmar@upvnet.upv.es Mon Jun 22 06:53: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 D20FC3A689D for ; Mon, 22 Jun 2009 06:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.115 X-Spam-Level: X-Spam-Status: No, score=0.115 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_8BIT_HEADER=0.3] 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 iD3rdn164sss for ; Mon, 22 Jun 2009 06:53:43 -0700 (PDT) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.21]) by core3.amsl.com (Postfix) with ESMTP id A9FC23A6862 for ; Mon, 22 Jun 2009 06:53:41 -0700 (PDT) Received: from pop.upv.es (deneb.cc.upv.es [158.42.3.51]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id n5MDrsP4026262 for ; Mon, 22 Jun 2009 15:53:54 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by pop.upv.es (8.11.3/8.11.3) with ESMTP id n5MDrso27136; Mon, 22 Jun 2009 15:53:54 +0200 (METDST) Received: from [127.0.0.1] (vera2g14-105.wi-fi.upv.es [158.42.14.105]) by smtp.upv.es (8.13.6/8.13.6) with ESMTP id n5MDrrTu005177 for ; Mon, 22 Jun 2009 15:53:54 +0200 Message-ID: <4A3F8CE7.3060300@upvnet.upv.es> Date: Mon, 22 Jun 2009 15:53:43 +0200 From: =?ISO-8859-1?Q?I=F1igo_Artundo?= User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: homegate@ietf.org References: <043B361632634A649D357F73DB54F63D@Honkin> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090621-0, 21/06/2009), Outbound message X-Antivirus-Status: Clean Subject: Re: [homegate] Management of the Home Gateway 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, 22 Jun 2009 13:53:43 -0000 Totally agree, if an update renders the gateway offline, the ISP will have thousands of angry users knocking at its door with a brick on their hands. It's true that firmware upgrading is easier and less risky than operating system or other software updates, as the hardware is (supposedly) all the same. But still, for such a critical device on the home network, I would be very careful and leave the updating to the user, maybe reminded by an applet on the GUI of the gateway. Iñigo Iljitsch van Beijnum wrote: > On 19 jun 2009, at 10:10, Richard Bennett wrote: > >> Or even better, we can recommend that the gateway automatically check >> an ftp >> archive for updates and apply them like Windows does with patches. >> Vendors >> could allow this feature to be turned off by the skilled user, but by >> default it should be on. > > No, it shouldn't be. Updates often cause just as many problems as they > solve. Having a home gateway that worked just fine break because someone > decided to push out an update is completely unacceptable. Especially > because update procedures are often lengthy, may render the device > unusable if interrupted, and if the device ends up in a non-working > state there is no recovery because there is no internet connection. > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate > -- Iñigo Artundo, PhD iTEAM - Grupo de Comunicaciones Opticas Universidad Politecnica de Valencia (UPV) http://www.iteam.upv.es From wbeebee@cisco.com Mon Jun 22 07:18:12 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 3C9EE28C1BE for ; Mon, 22 Jun 2009 07:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 LmZDM2S7T5SP for ; Mon, 22 Jun 2009 07:18:11 -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 145B528C1E9 for ; Mon, 22 Jun 2009 07:18:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,268,1243814400"; d="scan'208";a="48184903" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 22 Jun 2009 14:18:26 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5MEIPND005765; Mon, 22 Jun 2009 10:18:25 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5MEIGsF028277; Mon, 22 Jun 2009 14:18:25 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Jun 2009 10:18:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Jun 2009 10:18:20 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Management of the Home Gateway Thread-Index: AcnzO4+oBbX6S28eT3iCGA3i0HBKYwAB/H+Q References: <043B361632634A649D357F73DB54F63D@Honkin> From: "Wes Beebee (wbeebee)" To: "Iljitsch van Beijnum" , "Richard Bennett" X-OriginalArrivalTime: 22 Jun 2009 14:18:20.0911 (UTC) FILETIME=[4BA39FF0:01C9F344] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1855; t=1245680306; x=1246544306; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20[homegate]=20Management=20of=20the=20Ho me=20Gateway |Sender:=20 |To:=20=22Iljitsch=20van=20Beijnum=22=20,=0A=20=20=20=20=20=20=20=20=22Richard=20Bennett=22=20; bh=oh6IBj/d7SJd759t8HuCBoiu7yebmxvJXfoBvHEArPs=; b=rV61dL/KBH+eX1orlKQ3oXXOn7tqYpK4n6YmPCx4/h+ZllseTrlP5I/C4u o1wFa7Crdl9LhCk1ze5k7dJGVbDkZEKy7XkFWwMqHnz8DWl9SBE1UGM+gkyq M4+rWvER6B; Authentication-Results: rtp-dkim-1; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Carolin.Latze@swisscom.com, "Livingood, Jason" , homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 22 Jun 2009 14:18:12 -0000 In order for this to work, you would have to have basic connectivity without the firmware upgrade. Something like ROMMON on Cisco routers would do the trick: a very basic OS with just the capability of contacting the server and downloading upgrades, and then boot the main OS, which would be upgraded. Then you would also need to have enough regression done on updates to be sure that there won't be a deployment problem - something like the regression scripts that Debian runs for upgrades may do the trick. The question is: with the razor-thin margins on this device, could vendors afford to provide this capability? - Wes -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behalf Of Iljitsch van Beijnum Sent: Monday, June 22, 2009 9:14 AM To: Richard Bennett Cc: 'Livingood, Jason'; Carolin.Latze@swisscom.com; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway On 19 jun 2009, at 10:10, Richard Bennett wrote: > Or even better, we can recommend that the gateway automatically check=20 > an ftp archive for updates and apply them like Windows does with=20 > patches. > Vendors > could allow this feature to be turned off by the skilled user, but by=20 > default it should be on. No, it shouldn't be. Updates often cause just as many problems as they solve. Having a home gateway that worked just fine break because someone decided to push out an update is completely unacceptable. =20 Especially because update procedures are often lengthy, may render the device unusable if interrupted, and if the device ends up in a non- working state there is no recovery because there is no internet connection. _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate From Mikejt@broadcom.com Mon Jun 22 11:25:13 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 67DAC3A67DF for ; Mon, 22 Jun 2009 11:25:13 -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 hPM8JUqIWpvv for ; Mon, 22 Jun 2009 11:25:11 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 877553A67D9 for ; Mon, 22 Jun 2009 11:25:11 -0700 (PDT) Received: from [10.9.200.131] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 22 Jun 2009 11:25:15 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Mon, 22 Jun 2009 11:25:15 -0700 From: "Michael Johas Teener" To: "Iljitsch van Beijnum" , "joe@oregon.uoregon.edu" Date: Mon, 22 Jun 2009 11:25:14 -0700 Thread-Topic: [homegate] Jumbo frames Thread-Index: AcnzZsjtWJMtw1oOX0mSoaWAAslvTg== Message-ID: In-Reply-To: <2FC0A9D5-F1F4-48F2-8839-300689CA57F8@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.081218 acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6621130138419950031-01-01 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "homegate@ietf.org" Subject: Re: [homegate] Jumbo frames 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, 22 Jun 2009 18:25:13 -0000 Um ... As one of those IEEE 802 people, and as a contributor to Broadcom's significant Ethernet and switch expertise, I *do* have an opinion on larger-than-standard MTUs. They are, in general, a bad idea in any network that includes less than gigabit links (which will likely be the case for a very, very long time). The problem is that a 1500 byte packet occupies the wire for a good 120us o= r so at 100Mbit/s. This is just barely tolerable when there are various classes of real-time traffic that have to be multiplexed together. We are just now finish a set of standards within 802.1 that will provide assured delays on the order of 2ms through 7 bridges (switches) using 100baseT. 2ms is a magic number in the audio biz, since that is the maximum network delay for live music (the actual acceptable "hit the drum, hear the sound" delay is 10ms, but that includes processing delays and the speed of sound from monitor speakers to the drummer's ears). 100baseT is the baseline for all use models in this space because it is "free" and the bandwidth is more tha= n adequate. Anyway, that 120us wiretime introduces an equivalent head-of-queue delay in all egress ports, so we are already up to 8*120us =3D 960us just because th= e existing packets can be 1500 bytes. There is only another 130us per egress port that we can allow before we violate our starting requirement ... Which goes towards shared delays between other realtime streams as well as wire and pipeline delays. There are some other traffic management concerns about longer MTUs, frequently related to link round-trip delays. Waiting around for jumbo frames introduces extra delays in any control loop, and should be avoided. Finally, I think there is no reason to be concerned about the 1500 byte limit for MTUs w/r/t TCP performance over Ethernet as long as a reasonably modern NIC is used. The really cheap 1G and 100M NICs that we currently shi= p have automatic IP packetizing (load up a DMA buffer with 32k bytes and the NIC will break it into the appropriately formatted and sized TCP frames). All of our competitors can do the same (with the possible exception of the Intel chipsets). The resulting packet stream is within a few percent as efficient as a jumbo frame, without interfering with the QoS of other streams On 6/16/09 3:41 PM, "Iljitsch van Beijnum" wrote: > Yes, all the vendors that get together at the IEEE and refuse to do > 1500+ also happily build products that support larger packet sizes on > 802.3. >=20 > The IEEE's problem is that they need to retain compatibility with > older versions of ethernet. So if I hook up my 10GE router to a 10GE > switch with a gigabit ethernet port and that port to a cheap > 10/100/1000 switch and that switch to a prehistoric half duplex > 10baseT NIC, the packets need to be understood by the 10 Mbps system. > So they can't be longer than 1500 bytes. -- =20 Michael D. Johas Teener =8B mikejt@broadcom.com / mike@johasteener.com office +1-408-922-7542 cell +1-831-247-9666 fax +1-206-339-6331 http://xri.net/=3DMichael.Johas.Teener - PGP ID 0x3179D202 From joe@grey.uoregon.edu Mon Jun 22 12:11:32 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 768083A6A57 for ; Mon, 22 Jun 2009 12:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 qXBrNXY6so-l for ; Mon, 22 Jun 2009 12:11:31 -0700 (PDT) Received: from grey.uoregon.edu (grey.uoregon.edu [128.223.214.89]) by core3.amsl.com (Postfix) with SMTP id 534BB3A68A5 for ; Mon, 22 Jun 2009 12:11:31 -0700 (PDT) Received: by grey.uoregon.edu; Mon, 22 Jun 2009 12:09:50 -0700 Date: Mon, 22 Jun 2009 12:09:50 -0700 From: Joe St Sauver To: Mikejt@broadcom.com Message-Id: <09062212095028.8189d.1339457132@oregon.uoregon.edu> Cc: homegate@ietf.org Subject: Re: [homegate] Jumbo frames X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: joe@oregon.uoregon.edu List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 19:11:32 -0000 Hi Mike, You mentioned: #100baseT is the baseline for all use models in this space because it is #"free" and the bandwidth is more than adequate. By "free" I assume you mean "is bundled with shipping products by default." If I've interpreted that correctly, note that even systems as modest as Apple's Mac Mini (a ~$600-class box) now support gigabit ethernet, and if a PC ships without a gig NIC, adding one is a <$30 correction (if not less, checking www.pricewatch.com/browse/networking/gigabit_adapter/ ) I thus don't think it is safe to assume that customers will only have 10/100-capable hosts any more, and I think it would be a mistake to fail to acknowledge the market reality of 1000/100/10baseT NICs in a growing number of consumer-class systems. And when it comes to the adequacy of 100Mbps worth of bandwidth, I think that applications like the network backup of increasingly disk-heavy systems to cheap TB-class external disks will drive demand for better-than-fast-ethernet speeds (assuming users don't abandon ethernet entirely for those sort of external disk systems). #Finally, I think there is no reason to be concerned about the 1500 byte #limit for MTUs w/r/t TCP performance over Ethernet as long as a reasonably #modern NIC is used. The really cheap 1G and 100M NICs that we currently #ship have automatic IP packetizing (load up a DMA buffer with 32k bytes #and the NIC will break it into the appropriately formatted and sized TCP #frames). The problem is that we just don't see people getting the throughput they "should," even when running on high bandwidth and zero loss networks. See, for example http://netflow.internet2.edu/weekly/20090615/#select -- the 50th %-ile for bulk file transfers is only 3.6Mbps -- the 99th %-ile for bulk file transfers is only 68.2Mbps We can discuss why that may be true, and believe me, many folks have, but the reality is that if your performance focus is on single stream high throughput TCP flows (rather than low jitter), we really need all the help we can get, and that includes jumbo frame support for gig links. Failing that, I think we'll increasingly see a lot of fairly ugly things, like large numbers of parallel TCP flows in an effort to increase their throughput to what it "should be." Regards, Joe St Sauver (joe@oregon.uoregon.edu) http://www.uoregon.edu/~joe/ Disclaimer: all opinions strictly my own From iljitsch@muada.com Mon Jun 22 12:26:22 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 D97453A6C0F for ; Mon, 22 Jun 2009 12:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=0.416, 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 S5rmo9kvAbgy for ; Mon, 22 Jun 2009 12:26:19 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id E9E083A684A for ; Mon, 22 Jun 2009 12:26:18 -0700 (PDT) Received: from [192.168.2.4] (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 n5MJQcTe038666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Jun 2009 21:26:39 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <8239FE40-6544-4304-9C38-F08317CD3598@muada.com> From: Iljitsch van Beijnum To: "Michael Johas Teener" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 22 Jun 2009 21:26:11 +0200 References: X-Mailer: Apple Mail (2.935.3) Cc: "homegate@ietf.org" Subject: Re: [homegate] Jumbo frames 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, 22 Jun 2009 19:26:22 -0000 On 22 jun 2009, at 20:25, Michael Johas Teener wrote: > Um ... As one of those IEEE 802 people, and as a contributor to > Broadcom's > significant Ethernet and switch expertise, I *do* have an opinion on > larger-than-standard MTUs. They are, in general, a bad idea in any > network > that includes less than gigabit links (which will likely be the case > for a > very, very long time). Ok, I can go along with that for the most part. Not sure though if it's reasonable to expect the networking stack to know the speed at which the interface is operating at any given time... > 100baseT is the baseline for all > use models in this space because it is "free" and the bandwidth is > more than > adequate. Right. At 100 Mbps we don't really need jumboframes yet so there shouldn't be a conflict between our respective goals. > Anyway, that 120us wiretime introduces an equivalent head-of-queue > delay in > all egress ports, so we are already up to 8*120us = 960us just > because the > existing packets can be 1500 bytes. There is only another 130us per > egress > port that we can allow before we violate our starting > requirement ... Which > goes towards shared delays between other realtime streams as well as > wire > and pipeline delays. With ethernet we have a 32-bit CRC that has a hamming distance of 3 upto 11454 byte packets. So going to 11455 bytes increases the potential for undetected errors quite significantly. So I don't see gigabit ethernet vendors going beyond that, which means your serialization delay would be some 91 us for 11k packets on gigabit ethernet vs 120 for 1.5k packets on fast ethernet. > Finally, I think there is no reason to be concerned about the 1500 > byte > limit for MTUs w/r/t TCP performance over Ethernet as long as a > reasonably > modern NIC is used. Unfortunately, the NIC is only part of the story. Between to MacBook Pros (which I don't think offload anything to the NIC except the checksum) I can do 86 MB/s with regular packets and 116 MB/s with jumboframes. Routers and switches may need more power in order to switch larger numbers of packets for the same amount of data. Another issue is that there is a packet size dependency in the TCP algorithms which means that for a given loss probability you're going to run much faster with larger packets. > The really cheap 1G and 100M NICs that we currently ship > have automatic IP packetizing (load up a DMA buffer with 32k bytes > and the > NIC will break it into the appropriately formatted and sized TCP > frames). But they don't put them back together again on the receiving side. :-) From tme@americafree.tv Mon Jun 22 12:41:08 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 188783A695F for ; Mon, 22 Jun 2009 12:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 fYN2s6BrTY1H for ; Mon, 22 Jun 2009 12:41:07 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 0F72E3A684A for ; Mon, 22 Jun 2009 12:41:07 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id D416E41287FF; Mon, 22 Jun 2009 15:41:20 -0400 (EDT) Message-Id: <69E254EE-C489-41C5-AA6B-6857B9EC8C56@americafree.tv> From: Marshall Eubanks To: Iljitsch van Beijnum In-Reply-To: <8239FE40-6544-4304-9C38-F08317CD3598@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 22 Jun 2009 15:41:17 -0400 References: <8239FE40-6544-4304-9C38-F08317CD3598@muada.com> X-Mailer: Apple Mail (2.935.3) Cc: Michael Johas Teener , "homegate@ietf.org" Subject: Re: [homegate] Jumbo frames 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, 22 Jun 2009 19:41:08 -0000 On Jun 22, 2009, at 3:26 PM, Iljitsch van Beijnum wrote: > On 22 jun 2009, at 20:25, Michael Johas Teener wrote: > >> Um ... As one of those IEEE 802 people, and as a contributor to >> Broadcom's >> significant Ethernet and switch expertise, I *do* have an opinion on >> larger-than-standard MTUs. They are, in general, a bad idea in any >> network >> that includes less than gigabit links (which will likely be the >> case for a >> very, very long time). > > Ok, I can go along with that for the most part. > > Not sure though if it's reasonable to expect the networking stack to > know the speed at which the interface is operating at any given > time... > >> 100baseT is the baseline for all >> use models in this space because it is "free" and the bandwidth is >> more than >> adequate. > > Right. At 100 Mbps we don't really need jumboframes yet so there > shouldn't be a conflict between our respective goals. I disagree (about the Fast Ethernet, not the jumboframes). Anything we do will be for the 2011 and after time frame. By that point, I would expect Gig-E to be routine in SOHO use, at least, if not in home use as well. Anyone who is doing home video work, for example, is likely to be on Gig-E already. I would also dare say that many people running Gig-E in the home don't know it. My personal feeling is to stay away from jumbo, but I would suggest not doing anything to forestall fast LANs. Regards Marshall > > >> Anyway, that 120us wiretime introduces an equivalent head-of-queue >> delay in >> all egress ports, so we are already up to 8*120us = 960us just >> because the >> existing packets can be 1500 bytes. There is only another 130us per >> egress >> port that we can allow before we violate our starting >> requirement ... Which >> goes towards shared delays between other realtime streams as well >> as wire >> and pipeline delays. > > With ethernet we have a 32-bit CRC that has a hamming distance of 3 > upto 11454 byte packets. So going to 11455 bytes increases the > potential for undetected errors quite significantly. So I don't see > gigabit ethernet vendors going beyond that, which means your > serialization delay would be some 91 us for 11k packets on gigabit > ethernet vs 120 for 1.5k packets on fast ethernet. > >> Finally, I think there is no reason to be concerned about the 1500 >> byte >> limit for MTUs w/r/t TCP performance over Ethernet as long as a >> reasonably >> modern NIC is used. > > Unfortunately, the NIC is only part of the story. Between to MacBook > Pros (which I don't think offload anything to the NIC except the > checksum) I can do 86 MB/s with regular packets and 116 MB/s with > jumboframes. > > Routers and switches may need more power in order to switch larger > numbers of packets for the same amount of data. > > Another issue is that there is a packet size dependency in the TCP > algorithms which means that for a given loss probability you're > going to run much faster with larger packets. > >> The really cheap 1G and 100M NICs that we currently ship >> have automatic IP packetizing (load up a DMA buffer with 32k bytes >> and the >> NIC will break it into the appropriately formatted and sized TCP >> frames). > > But they don't put them back together again on the receiving > side. :-) > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate > From iljitsch@muada.com Mon Jun 22 12:44:55 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 B50263A6BA1 for ; Mon, 22 Jun 2009 12:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.252 X-Spam-Level: X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[AWL=0.347, 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 mYhqH7cqvVeu for ; Mon, 22 Jun 2009 12:44:55 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id B8E293A68D8 for ; Mon, 22 Jun 2009 12:44:54 -0700 (PDT) Received: from [192.168.2.4] (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 n5MJj9ZT038849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Jun 2009 21:45:09 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <4F3B2C7A-AA49-43C8-8571-2807B9C339E9@muada.com> From: Iljitsch van Beijnum To: Marshall Eubanks In-Reply-To: <69E254EE-C489-41C5-AA6B-6857B9EC8C56@americafree.tv> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 22 Jun 2009 21:44:41 +0200 References: <8239FE40-6544-4304-9C38-F08317CD3598@muada.com> <69E254EE-C489-41C5-AA6B-6857B9EC8C56@americafree.tv> X-Mailer: Apple Mail (2.935.3) Cc: Michael Johas Teener , "homegate@ietf.org" Subject: Re: [homegate] Jumbo frames 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, 22 Jun 2009 19:44:55 -0000 On 22 jun 2009, at 21:41, Marshall Eubanks wrote: >> Right. At 100 Mbps we don't really need jumboframes yet so there >> shouldn't be a conflict between our respective goals. > I disagree (about the Fast Ethernet, not the jumboframes). I don't understand what you're disagreeing with. Do you want jumboframes on fast ethernet too? Do you NOT want jumboframes on gigabit ethernet either? Why? From mail@sabahattin-gucukoglu.com Mon Jun 22 13:15:11 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 78F113A6B6A for ; Mon, 22 Jun 2009 13:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.384, 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 nqYm3s-eYPZy for ; Mon, 22 Jun 2009 13:15:10 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id A8DA83A6D47 for ; Mon, 22 Jun 2009 13:14:39 -0700 (PDT) Received: by ewy6 with SMTP id 6so5002483ewy.37 for ; Mon, 22 Jun 2009 13:14:49 -0700 (PDT) Received: by 10.216.13.209 with SMTP id b59mr2321707web.44.1245701689427; Mon, 22 Jun 2009 13:14:49 -0700 (PDT) Received: from ?192.168.1.3? (62-30-111-115.cable.ubr07.dals.blueyonder.co.uk [62.30.111.115]) by mx.google.com with ESMTPS id t2sm18866054gve.0.2009.06.22.13.14.48 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Jun 2009 13:14:48 -0700 (PDT) Message-Id: <2D89E494-9A0F-49B0-BD1A-50DC116A01FC@sabahattin-gucukoglu.com> From: Sabahattin Gucukoglu To: homegate@ietf.org In-Reply-To: <7191A9FADFABE74F94A8403B82C57A61015F243060@sg000036.corproot.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 22 Jun 2009 21:14:46 +0100 References: <043B361632634A649D357F73DB54F63D@Honkin> <79BEDD96-B3D8-426E-A2A1-FB2F3F5D6C51@sabahattin-gucukoglu.com> <7191A9FADFABE74F94A8403B82C57A61015F243060@sg000036.corproot.net> X-Mailer: Apple Mail (2.935.3) Subject: Re: [homegate] Management of the Home Gateway 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, 22 Jun 2009 20:15:11 -0000 My cable company provides updates to my cable modem. Fine; if they break it, it's their fault, and they lose. But my home gateway is mine, and it merely flashes it's status light (which, being blind, I can't see) to indicate update availability. Perhaps this is good enough for Joe Consumer. For cable there are generally better possibilities for delivering updates in an automatic and side-channel process. The same can't be said for DSL because, as somebody mentioned, the primary lin *is* the update delivery method, and if you bust the brick, you've lost a customer and probably broken his network too. Cheers, Sabahattin From tme@americafree.tv Mon Jun 22 13:15:12 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 8EE713A6DE2 for ; Mon, 22 Jun 2009 13:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 pWqRtnr5MZ0j for ; Mon, 22 Jun 2009 13:15:11 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 093FE3A6DEA for ; Mon, 22 Jun 2009 13:14:48 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id BF474412956C; Mon, 22 Jun 2009 16:15:02 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Iljitsch van Beijnum In-Reply-To: <4F3B2C7A-AA49-43C8-8571-2807B9C339E9@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 22 Jun 2009 16:14:59 -0400 References: <8239FE40-6544-4304-9C38-F08317CD3598@muada.com> <69E254EE-C489-41C5-AA6B-6857B9EC8C56@americafree.tv> <4F3B2C7A-AA49-43C8-8571-2807B9C339E9@muada.com> X-Mailer: Apple Mail (2.935.3) Cc: Michael Johas Teener , "homegate@ietf.org" Subject: Re: [homegate] Jumbo frames 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, 22 Jun 2009 20:15:12 -0000 On Jun 22, 2009, at 3:44 PM, Iljitsch van Beijnum wrote: > On 22 jun 2009, at 21:41, Marshall Eubanks wrote: > >>> Right. At 100 Mbps we don't really need jumboframes yet so there >>> shouldn't be a conflict between our respective goals. > >> I disagree (about the Fast Ethernet, not the jumboframes). > > I don't understand what you're disagreeing with. > > Do you want jumboframes on fast ethernet too? > > Do you NOT want jumboframes on gigabit ethernet either? I want this effort to support Gig-E and even 10Gig-E. I do not want decisions to be taken strictly assuming Fast-Ethernet. (There might not be any other issues besides jumboframes, but if there are ...). I personally would like jumboframe support IF that can be done in a sane fashion. I don't see how you can define jumboframe support at the present without defining jumboframes, and I am not sure that this is within scope for the present effort. There is a SDO failure here - there are many jumboframes in use because IEEE won't define one. It seems to me that some group will step up and create a definition that will stick, probably as a consequence of some other standard that needs jumboframes. I am just not sure that this should be that group. Regards Marshall > > > Why? > From ole-martin.eide@telenor.com Mon Jun 22 13:23: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 A45A23A6B84 for ; Mon, 22 Jun 2009 13:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1] 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 PqP300eftE0d for ; Mon, 22 Jun 2009 13:23:34 -0700 (PDT) Received: from hermod.telenor.net (virus-out-st.online.no [193.212.240.200]) by core3.amsl.com (Postfix) with ESMTP id E3CBC3A67C0 for ; Mon, 22 Jun 2009 13:23:33 -0700 (PDT) Received: from tns-fbu-22-249.corp.telenor.no ([134.47.162.189] [134.47.162.189]) by hermod.telenor.net with ESMTPS id BT-MMP-1264686; Mon, 22 Jun 2009 22:23:46 +0200 Received: from TNS-FBU-2E-015.corp.telenor.no ([134.47.162.74]) by tns-fbu-22-249.corp.telenor.no ([134.47.162.189]) with mapi; Mon, 22 Jun 2009 22:23:46 +0200 From: To: , , , Date: Mon, 22 Jun 2009 22:23:43 +0200 Thread-Topic: [homegate] Management of the Home Gateway Thread-Index: AcnwTs3wW7J6+O9yb0eRW8e2IgBNOAAAqErrAAvUBSAAurhzwA== Message-ID: References: <043B361632634A649D357F73DB54F63D@Honkin> In-Reply-To: <043B361632634A649D357F73DB54F63D@Honkin> Accept-Language: nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nb-NO Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Carolin.Latze@swisscom.com, homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 22 Jun 2009 20:23:35 -0000 Hi, I think there is a need for common management, and functionality that the u= ser can relate to besides the branding on the carton. The average user is b= ecoming very aware of the technologies in use, still most CPEs is sold with= little-to-nothing about what dark magic it supports and how it can be mana= ged, besides the logos. Document (3) could act as a baseline, if you are pl= anning on specifying more than just management, also functionality. Management (1) and the data models to go with it standardize a way for oper= ators to manage the CPE and devices behind it. I think that at some point t= his has been considered, at least how to separate users that want to manage= this them selves. The table on page 20 (2) specifies a attribute named "Up= gradesManaged" that an CWMP ACS should relate to, that states if the ACS sh= ould manage firmware or not. For our part, notification of firmware upgrade= s will in the future be done through walled garden. =20 A complicating factor of firmware management is that physical interoperabil= ity is at best intricate; we spend a great deal of time making this work fo= r every single release. In some countries this is at such a level that comp= etition within the CPE marked is non existent. This is a thing to keep in m= ind. At the same time I think most ISPs are becoming aware of the fact that the = CPE terminating the access line is becoming an important part of their netw= ork, since they are now delivering services deep within the customer's netw= ork (IPTV, SIP, alarms, power readings, backup, you name it). In other word= s I suspect that the box in charge of terminating the line for the customer= in a much larger degree will have to be owned and/or managed by the ISP. T= his in turn leads to reports, documents, standards that define management o= f devices in the home network as seen from the Broadband Forum. I'm not saying that retail products (CPE), but I think we must consider the= implications of such a standard and be careful :-) For a layer 3 device de= ep within the network, these kind of considerations does not apply. Still f= irmware upgrade (or what I would like to call firmware change, since it is = not always per se an 'UPgrade') is a tedious process, many considerations f= or how this can be done as safe as possible is outlined in the different Br= oadband Forum documents. References: 1) "TR-069 Amendment 1 and 2, CPE WAN Management Protocol" http://broadband-forum.org/technical/download/TR-069Amendment1.pdf http://broadband-forum.org/technical/download/TR-069Amendment2.pdf 2) "TR-098 Amendment 2, Internet Gateway Device Data Model for TR-069" http://www.broadband-forum.org/technical/download/TR-98_Amendment_2.pdf 3) "TR-124, Functional Requirements for Broadband Residential Gateway Devic= es" http://broadband-forum.org/technical/download/TR-124.pdf Thanks, Ole Martin -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behal= f Of Richard Bennett Sent: 19. juni 2009 03:58 To: 'Erichsen, Kirk'; 'Livingood, Jason'; 'Stephen Farrell' Cc: Carolin.Latze@swisscom.com; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway The telco-deployed gateways are managed as CPE, using the TR stuff for firmware upgrades, but for the retail product about all we can do is advise customers to periodically apply upgrades the hard way. In a perfect world, = I suppose there would be a single web site where both customers and support people could go to see what the latest revision is for every gateway, but this isn't such a world. Another option is to declare it a BCP to have an easy "check for upgrade" button on the first page of the gateway's GUI or something similar. Richard Bennett -----Original Message----- From: Erichsen, Kirk [mailto:kirk.erichsen@twcable.com]=20 Sent: Thursday, June 18, 2009 1:34 PM To: Livingood, Jason; Stephen Farrell Cc: Carolin.Latze@swisscom.com; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway Are we only interested in a generic software mechanism ("how") that be standardized, without really worrying about the management model (the "who")? P Go Green! Print this email only when necessary. Thank you for helping Tim= e Warner Cable be environmentally responsible. =20 =20 -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Sent: Thu 6/18/2009 1:56 PM To: Stephen Farrell; Erichsen, Kirk Cc: Carolin.Latze@swisscom.com; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway =20 On 6/17/09 10:12 AM, "Stephen Farrell" wrote: > Erichsen, Kirk wrote: >> 1) Who manages the device? - I Think in most cases, 90% of the time it i= s the >> customer/end user. >=20 > If so, then I think part of any spec here should include some sort > of requirement for software/firmware update for the device. While > there may not be a specific protocol for that that every vendor > would want to use, this activity (if it becomes a WG) might be > able to at least set requirements there. Firmware update methods were a topic of discussion when a few parties met t= o discuss the problem space in Philadelphia months ago. One of the issues is related to why web browsers and operating systems now perform automatic checks for updates. Today, this generally does not happen, though in some cases it can be prompted by the user savvy enough to visit the local device management web page periodically. In any case, there are regular security fixes which are made available and without recommendations on how updates should occur (user intervention, automatically downloaded, automatically applied, etc.) many devices leave this to the users -- and probably 90%+ of the user base will never upgrade the firmware on the device. Jason This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ 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 iljitsch@muada.com Mon Jun 22 13:48:55 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 2EA813A6BFD for ; Mon, 22 Jun 2009 13:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.302 X-Spam-Level: X-Spam-Status: No, score=-6.302 tagged_above=-999 required=5 tests=[AWL=0.297, 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 Sz7LcyQdXpwP for ; Mon, 22 Jun 2009 13:48:54 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id F1C9C3A6ACB for ; Mon, 22 Jun 2009 13:48:49 -0700 (PDT) Received: from [192.168.2.4] (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 n5MKn4WS039276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Jun 2009 22:49:09 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <6DF7ABCE-8DED-48B8-B545-DE383A4AB115@muada.com> From: Iljitsch van Beijnum To: Marshall Eubanks In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 22 Jun 2009 22:48:37 +0200 References: <8239FE40-6544-4304-9C38-F08317CD3598@muada.com> <69E254EE-C489-41C5-AA6B-6857B9EC8C56@americafree.tv> <4F3B2C7A-AA49-43C8-8571-2807B9C339E9@muada.com> X-Mailer: Apple Mail (2.935.3) Cc: Michael Johas Teener , "homegate@ietf.org" Subject: Re: [homegate] Jumbo frames 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, 22 Jun 2009 20:48:55 -0000 On 22 jun 2009, at 22:14, Marshall Eubanks wrote: > I want this effort to support Gig-E Is anyone saying it shouldn't? Michael mentioned fast ethernet because it's basically the minimum installed base currently, 10 Mbps ethernet stuff is getting pretty scarce. Although gigabit ethernet is becoming very common, you can't really assume that it's universally available in the home at this point. 10/100 switches are still a lot cheaper than 10/100/1000 ones and cheap boxes like home gateways etc usually don't do gigabit, probably because their CPUs aren't up to the task anyway. > and even 10Gig-E. :-) I got to play with a Mac with a 10GE card in it a few years ago. Pretty sweet. Used 16k jumboframes, BTW. > I do not want decisions to be taken strictly assuming Fast-Ethernet. Ethernet is ethernet, it's all compatible. I'm sure more and more vendors will build in gigabit the coming years and I don't think anyone on this list is opposed to that or has anything that would get in the way of that. What I'm assuming is that if we can, we'll probably want to use jumboframes on gigabit ports and disable jumboframes on ports running at 10 or 100 Mbps. > I personally would like jumboframe support IF that can be done in a > sane fashion. I don't see how you can define > jumboframe support at the present without defining jumboframes You mean a size? That's exactly the wrong thing to do. We have 30 years of 1500 byte installed base. So we need to be able to determine whether we're talking to someone who can do 1500 or someone who can do larger than 1500. We can of course make this a one bit decision between 1500 or 9000 or some such, but if we're going to do all this work we really don't want to have to do it again when someone builds a NIC that can do 12000. So rather than 1 bit for jumbo yes/no we should use 32 bits that can hold the exact packet size that's supported even when we grow beyond 64k. (Note that I've personally worked with ethernet gear that supported 9000, 9216, 16384 and 64000. Looking at vendor documentation I came up with at least a dozen other sizes. Trying to standardize a jumboframe size is going to be very hard.) > and I am not sure that this is within scope for the present effort. Right. I suggest that those interested in this go to the intarea list, I'm going to post an update of my draft there later this week. From richard@bennett.com Mon Jun 22 14:09:20 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 BF3F63A68D6 for ; Mon, 22 Jun 2009 14:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 RGprxifvs6Pw for ; Mon, 22 Jun 2009 14:09:19 -0700 (PDT) Received: from outbound-mail-133.bluehost.com (outbound-mail-133.bluehost.com [67.222.39.23]) by core3.amsl.com (Postfix) with SMTP id B3E703A689D for ; Mon, 22 Jun 2009 14:09:19 -0700 (PDT) Received: (qmail 24151 invoked by uid 0); 22 Jun 2009 21:09:35 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy4.bluehost.com with SMTP; 22 Jun 2009 21:09:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-MimeOLE:Thread-Index:X-Identified-User; b=qZghE0yebTdgVLF51Pug1Cp5dTHp6EZfHEt4g8frZ8xu6zwKn9Xd+h79ew0oaUKLerJ+odeLcg4gANqxCi8z5lclcP41LnNK6DBcE37dNkNOiiklWf542+F+A+jZVtT4; Received: from c-24-5-230-26.hsd1.ca.comcast.net ([24.5.230.26] helo=Honkin) by host46.hostmonster.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MIqli-0006Lu-N1; Mon, 22 Jun 2009 15:09:35 -0600 From: "Richard Bennett" To: "'Iljitsch van Beijnum'" , "'Marshall Eubanks'" References: <8239FE40-6544-4304-9C38-F08317CD3598@muada.com><69E254EE-C489-41C5-AA6B-6857B9EC8C56@americafree.tv><4F3B2C7A-AA49-43C8-8571-2807B9C339E9@muada.com> <6DF7ABCE-8DED-48B8-B545-DE383A4AB115@muada.com> In-Reply-To: <6DF7ABCE-8DED-48B8-B545-DE383A4AB115@muada.com> Date: Mon, 22 Jun 2009 14:09:12 -0700 Organization: ITIF Message-ID: <362FBC643A9148A28FC5B1E9F7D9B567@Honkin> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Thread-Index: Acnzeu+1AEjw5/i7ShSKmVU2JM4+IQAAmoAg X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 24.5.230.26 authed with richard+bennett.com} Cc: 'Michael Johas Teener' , homegate@ietf.org Subject: Re: [homegate] Jumbo frames X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: richard@bennett.com List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 21:09:20 -0000 I'd like to remind people that frame size is a MAC protocol issue, and not something that the IETF needs to have a specific opinion about, beyond "be conservative in what you send and liberal in what you accept." If 802 permits or mandates support for jumbo frames, it will happen, and if they don't it probably won't. Richard Bennett -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] Sent: Monday, June 22, 2009 1:49 PM To: Marshall Eubanks Cc: Michael Johas Teener; homegate@ietf.org Subject: Re: [homegate] Jumbo frames On 22 jun 2009, at 22:14, Marshall Eubanks wrote: > I want this effort to support Gig-E Is anyone saying it shouldn't? Michael mentioned fast ethernet because it's basically the minimum installed base currently, 10 Mbps ethernet stuff is getting pretty scarce. Although gigabit ethernet is becoming very common, you can't really assume that it's universally available in the home at this point. 10/100 switches are still a lot cheaper than 10/100/1000 ones and cheap boxes like home gateways etc usually don't do gigabit, probably because their CPUs aren't up to the task anyway. > and even 10Gig-E. :-) I got to play with a Mac with a 10GE card in it a few years ago. Pretty sweet. Used 16k jumboframes, BTW. > I do not want decisions to be taken strictly assuming Fast-Ethernet. Ethernet is ethernet, it's all compatible. I'm sure more and more vendors will build in gigabit the coming years and I don't think anyone on this list is opposed to that or has anything that would get in the way of that. What I'm assuming is that if we can, we'll probably want to use jumboframes on gigabit ports and disable jumboframes on ports running at 10 or 100 Mbps. > I personally would like jumboframe support IF that can be done in a > sane fashion. I don't see how you can define > jumboframe support at the present without defining jumboframes You mean a size? That's exactly the wrong thing to do. We have 30 years of 1500 byte installed base. So we need to be able to determine whether we're talking to someone who can do 1500 or someone who can do larger than 1500. We can of course make this a one bit decision between 1500 or 9000 or some such, but if we're going to do all this work we really don't want to have to do it again when someone builds a NIC that can do 12000. So rather than 1 bit for jumbo yes/no we should use 32 bits that can hold the exact packet size that's supported even when we grow beyond 64k. (Note that I've personally worked with ethernet gear that supported 9000, 9216, 16384 and 64000. Looking at vendor documentation I came up with at least a dozen other sizes. Trying to standardize a jumboframe size is going to be very hard.) > and I am not sure that this is within scope for the present effort. Right. I suggest that those interested in this go to the intarea list, I'm going to post an update of my draft there later this week. _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate From richard@bennett.com Mon Jun 22 14:14: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 E15713A6BC5 for ; Mon, 22 Jun 2009 14:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 BKlfjDGtE3Fw for ; Mon, 22 Jun 2009 14:14:05 -0700 (PDT) Received: from outbound-mail-38.bluehost.com (outbound-mail-38.bluehost.com [69.89.20.192]) by core3.amsl.com (Postfix) with SMTP id 03E513A6840 for ; Mon, 22 Jun 2009 14:13:37 -0700 (PDT) Received: (qmail 9902 invoked by uid 0); 22 Jun 2009 21:13:53 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy2.bluehost.com with SMTP; 22 Jun 2009 21:13:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-MimeOLE:Thread-Index:X-Identified-User; b=Km4+7JpHcX/geTh47VSYdrLFas6NbCjvlI8TWteCVuDniUin4zdhO2iSDa2JJ6u/w8AXAS4TGFi6LwFrThsh7fW1CsteH5e1WJ3h+H26tQj4IT4ooXCwlq7HS36t1+Ec; Received: from c-24-5-230-26.hsd1.ca.comcast.net ([24.5.230.26] helo=Honkin) by host46.hostmonster.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MIqpt-0008FE-Ft; Mon, 22 Jun 2009 15:13:53 -0600 From: "Richard Bennett" To: "'Wes Beebee \(wbeebee\)'" , "'Iljitsch van Beijnum'" References: <043B361632634A649D357F73DB54F63D@Honkin> In-Reply-To: Date: Mon, 22 Jun 2009 14:13:30 -0700 Organization: ITIF Message-ID: <5120D6493514464EAEB7A846D0C1DC80@Honkin> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Thread-Index: AcnzO4+oBbX6S28eT3iCGA3i0HBKYwAB/H+QAA6PPSA= X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 24.5.230.26 authed with richard+bennett.com} Cc: Carolin.Latze@swisscom.com, "'Livingood, Jason'" , homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: richard@bennett.com List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 21:14:07 -0000 The fact of the matter is that the telco home gateways already support automated firmware updates, with the appropriate failsafes and recovery mechanisms to deal with the odd case of a failed update. So the question is whether the retail home gateways should strive for a similar level of functionality. It seems to me that automated firmware updates are the only way to ensure that updates will ever be applied in most cases, as the typical user probably never uses the management GUI and would therefore never be able to force an update via manual means. While there's some element of risk in any action, the risk of updating firmware in the process that's well-specified for authentication and recovery is less than the risk of never updating and therefore exposing the Internet to the consequences of bad code. Richard Bennett -----Original Message----- From: Wes Beebee (wbeebee) [mailto:wbeebee@cisco.com] Sent: Monday, June 22, 2009 7:18 AM To: Iljitsch van Beijnum; Richard Bennett Cc: Livingood, Jason; Carolin.Latze@swisscom.com; homegate@ietf.org Subject: RE: [homegate] Management of the Home Gateway In order for this to work, you would have to have basic connectivity without the firmware upgrade. Something like ROMMON on Cisco routers would do the trick: a very basic OS with just the capability of contacting the server and downloading upgrades, and then boot the main OS, which would be upgraded. Then you would also need to have enough regression done on updates to be sure that there won't be a deployment problem - something like the regression scripts that Debian runs for upgrades may do the trick. The question is: with the razor-thin margins on this device, could vendors afford to provide this capability? - Wes -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behalf Of Iljitsch van Beijnum Sent: Monday, June 22, 2009 9:14 AM To: Richard Bennett Cc: 'Livingood, Jason'; Carolin.Latze@swisscom.com; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway On 19 jun 2009, at 10:10, Richard Bennett wrote: > Or even better, we can recommend that the gateway automatically check > an ftp archive for updates and apply them like Windows does with > patches. > Vendors > could allow this feature to be turned off by the skilled user, but by > default it should be on. No, it shouldn't be. Updates often cause just as many problems as they solve. Having a home gateway that worked just fine break because someone decided to push out an update is completely unacceptable. Especially because update procedures are often lengthy, may render the device unusable if interrupted, and if the device ends up in a non- working state there is no recovery because there is no internet connection. _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate From iljitsch@muada.com Mon Jun 22 14:20: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 6E6D528C217 for ; Mon, 22 Jun 2009 14:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 PBBKoNFBOrqV for ; Mon, 22 Jun 2009 14:20:36 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 6084B28C220 for ; Mon, 22 Jun 2009 14:20:35 -0700 (PDT) Received: from [192.168.2.4] (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 n5MLKos2039534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Jun 2009 23:20:51 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: In-Reply-To: <362FBC643A9148A28FC5B1E9F7D9B567@Honkin> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 22 Jun 2009 23:20:23 +0200 References: <8239FE40-6544-4304-9C38-F08317CD3598@muada.com><69E254EE-C489-41C5-AA6B-6857B9EC8C56@americafree.tv><4F3B2C7A-AA49-43C8-8571-2807B9C339E9@muada.com> <6DF7ABCE-8DED-48B8-B545-DE383A4AB115@muada.com> <362FBC643A9148A28FC5B1E9F7D9B567@Honkin> X-Mailer: Apple Mail (2.935.3) Cc: 'Michael Johas Teener' , homegate@ietf.org Subject: Re: [homegate] Jumbo frames 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, 22 Jun 2009 21:20:37 -0000 On 22 jun 2009, at 23:09, Richard Bennett wrote: > I'd like to remind people that frame size is a MAC protocol issue, > and not > something that the IETF needs to have a specific opinion about, > beyond "be > conservative in what you send and liberal in what you accept." The problem is that IP assumes that every subnet has a fixed MTU. Since obviously the 1500-byte stuff isn't going anywhere, the addition of jumboframe-capable hardware creates a problem, because now we have systems with two (or more) different MTUs on a subnet, which doesn't work in the general case although the TCP MSS option hides a multitude of sins. (Not the sin of having a 1500-byte switch sit between all the jumbo-capable systems, though.) ((I keep telling people that RFC 894 (IP over ethernet) is an april fools day RFC, published on april 1 1984, and we shouldn't take it seriously but nobody listens.)) > If 802 > permits or mandates support for jumbo frames, it will happen, and if > they > don't it probably won't. Also not exactly true. Like I wrote before, the same vendors that make up IEEE 802.3 also build products that ignore the 1500-byte MTU limit in 802.3. From richard@bennett.com Mon Jun 22 14:32:10 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 AD33D3A6C40 for ; Mon, 22 Jun 2009 14:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 SdwqokVSW2tR for ; Mon, 22 Jun 2009 14:32:09 -0700 (PDT) Received: from outbound-mail-20.bluehost.com (outbound-mail-20.bluehost.com [69.89.20.235]) by core3.amsl.com (Postfix) with SMTP id B8A303A6971 for ; Mon, 22 Jun 2009 14:32:09 -0700 (PDT) Received: (qmail 14644 invoked by uid 0); 22 Jun 2009 21:32:25 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy1.bluehost.com with SMTP; 22 Jun 2009 21:32:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-MimeOLE:Thread-Index:X-Identified-User; b=tQA0jMf3UsphT2ZIgfuHJXZ4US7qkyR3MuoVK3HAmFzf4aHtOvrzlABEGdnY1Obi0OVUpbjCepMo6cUyQduze4mPsWtqmj23zHSylv5GtkYmCQd4c0ge3Zf4Eg8ndwyv; Received: from c-24-5-230-26.hsd1.ca.comcast.net ([24.5.230.26] helo=Honkin) by host46.hostmonster.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MIr7p-000852-1C; Mon, 22 Jun 2009 15:32:25 -0600 From: "Richard Bennett" To: "'Iljitsch van Beijnum'" References: <8239FE40-6544-4304-9C38-F08317CD3598@muada.com><69E254EE-C489-41C5-AA6B-6857B9EC8C56@americafree.tv><4F3B2C7A-AA49-43C8-8571-2807B9C339E9@muada.com> <6DF7ABCE-8DED-48B8-B545-DE383A4AB115@muada.com> <362FBC643A9148A28FC5B1E9F7D9B567@Honkin> In-Reply-To: Date: Mon, 22 Jun 2009 14:32:02 -0700 Organization: ITIF Message-ID: <4DC73880499B49FD801AFFA654A9BFB6@Honkin> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Thread-Index: Acnzf0fuge2UOAOlQFW2aklF7NQFqAAAQeow X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 24.5.230.26 authed with richard+bennett.com} Cc: 'Michael Johas Teener' , homegate@ietf.org Subject: Re: [homegate] Jumbo frames X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: richard@bennett.com List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 21:32:10 -0000 Aren't jumbo frames generally used within the LAN? When they are, there's no need for fragmentation. When they pass through the NAT toward the Internet, it's a different story, of course, but we don't have so many Gigagbit WAN connections today, outside of high-end consumers in Japan. Richard Bennett -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] Sent: Monday, June 22, 2009 2:20 PM To: richard@bennett.com Cc: 'Marshall Eubanks'; 'Michael Johas Teener'; homegate@ietf.org Subject: Re: [homegate] Jumbo frames On 22 jun 2009, at 23:09, Richard Bennett wrote: > I'd like to remind people that frame size is a MAC protocol issue, > and not > something that the IETF needs to have a specific opinion about, > beyond "be > conservative in what you send and liberal in what you accept." The problem is that IP assumes that every subnet has a fixed MTU. Since obviously the 1500-byte stuff isn't going anywhere, the addition of jumboframe-capable hardware creates a problem, because now we have systems with two (or more) different MTUs on a subnet, which doesn't work in the general case although the TCP MSS option hides a multitude of sins. (Not the sin of having a 1500-byte switch sit between all the jumbo-capable systems, though.) ((I keep telling people that RFC 894 (IP over ethernet) is an april fools day RFC, published on april 1 1984, and we shouldn't take it seriously but nobody listens.)) > If 802 > permits or mandates support for jumbo frames, it will happen, and if > they > don't it probably won't. Also not exactly true. Like I wrote before, the same vendors that make up IEEE 802.3 also build products that ignore the 1500-byte MTU limit in 802.3. From kirk.erichsen@twcable.com Mon Jun 22 14:37:09 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 8CAE43A6C53 for ; Mon, 22 Jun 2009 14:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 KaAj9XTAQDLI for ; Mon, 22 Jun 2009 14:37:08 -0700 (PDT) Received: from pblpas02.twcable.com (pblpas02.twcable.com [204.235.121.150]) by core3.amsl.com (Postfix) with ESMTP id E6E533A6971 for ; Mon, 22 Jun 2009 14:37:07 -0700 (PDT) X-SENDER-IP: 10.157.247.212 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,271,1243828800"; d="scan'208";a="424753549" Received: from unknown (HELO prvpmailconn2.corp.twcable.com) ([10.157.247.212]) by pblpas02.twcable.com with ESMTP; 22 Jun 2009 17:37:22 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn2.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Jun 2009 17:37:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 Jun 2009 17:37:20 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Management of the Home Gateway Thread-Index: AcnwTs3wW7J6+O9yb0eRW8e2IgBNOAAAqErrAAvUBSAAurhzwAAE4Vu7 References: <043B361632634A649D357F73DB54F63D@Honkin> From: "Erichsen, Kirk" To: , , , X-OriginalArrivalTime: 22 Jun 2009 21:37:22.0035 (UTC) FILETIME=[A02C2C30:01C9F381] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: Carolin.Latze@swisscom.com, homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 22 Jun 2009 21:37:09 -0000 Ole, =20 While I'd agree we could perhaps come up with a framework for how features = (mandatory and vendor defined) "should" be supported within the gateway fro= m a UI/management perspective, I think this may get too far into product sp= ecification grounds and away from a spec that is basically about features/f= unctions unless we very carefully map out the expectations here.=20 =20 With regards to management, I quote your thread from below: "Management (1)= and the data models to go with it standardize a way for operators to manag= e the CPE and devices behind it." =20 This is a sore spot in cable. We had a magnificent specification developed = to do just that. It produced a very complex, very expensive box that lacked= alignment with trends towards more and more user managed gateways. It is f= or that reason I would agree that some effort to craft text around user-man= agement expectations should be included in the document. However, it's my v= iew we need to resist the temptation to over-specify low level functionalit= y/look and feel with regards to management and should de-emphasize service = providers ownership of the device management. If we can agree, for example,= on a set of user-management functions, what might those be? Here is an exa= mple of a few, in no particular order and open to debate: =20 1) a Web based UI exposing configuration management of features defined els= ewhere in the document=20 2) a "return to default" configuration option to ensure that any meddling d= one by the user that causes unexpected behavior can be neutralized with a r= eset to default option and a reboot of the device. This option is applicabl= e to a push-pin, a software-only method or some other method. There may be = some value in standardizing down to one or two approaches, though if these = devices aren't managed by the service provider (customer care doesn't have = to keep a sheet of all potential methods for every model router) this may n= ot be necessary. 3) A method of backing up/restoring configurations so that configurations c= an be restored when new configurations are tried. The simplest way to do th= is is allow the user's PC to store the configs and back/restore "off board"= of the router itself (reduce the need for the router to be able to discern= one config over another to boot from). For example, the user could "test" = a configuration change and if odd behavior occurs, revert. This is in addit= ion to a reset to defaults since the defaults may have features disabled or= configured differently than the customer requires. As the number of featur= es and the interactions among features increases, odd behavior is bound to = pop up with a bad configuration choice. This could manifest as decreased pa= cket forwarding performance, or other telltales that only occur when using = certain applications. =20 =20 -KE =20 ________________________________ From: ole-martin.eide@telenor.com [mailto:ole-martin.eide@telenor.com] Sent: Mon 6/22/2009 2:23 PM To: richard@bennett.com; Erichsen, Kirk; Jason_Livingood@cable.comcast.com;= stephen.farrell@cs.tcd.ie Cc: Carolin.Latze@swisscom.com; homegate@ietf.org Subject: RE: [homegate] Management of the Home Gateway Hi, I think there is a need for common management, and functionality that the u= ser can relate to besides the branding on the carton. The average user is b= ecoming very aware of the technologies in use, still most CPEs is sold with= little-to-nothing about what dark magic it supports and how it can be mana= ged, besides the logos. Document (3) could act as a baseline, if you are pl= anning on specifying more than just management, also functionality. Management (1) and the data models to go with it standardize a way for oper= ators to manage the CPE and devices behind it. I think that at some point t= his has been considered, at least how to separate users that want to manage= this them selves. The table on page 20 (2) specifies a attribute named "Up= gradesManaged" that an CWMP ACS should relate to, that states if the ACS sh= ould manage firmware or not. For our part, notification of firmware upgrade= s will in the future be done through walled garden. A complicating factor of firmware management is that physical interoperabil= ity is at best intricate; we spend a great deal of time making this work fo= r every single release. In some countries this is at such a level that comp= etition within the CPE marked is non existent. This is a thing to keep in m= ind. At the same time I think most ISPs are becoming aware of the fact that the = CPE terminating the access line is becoming an important part of their netw= ork, since they are now delivering services deep within the customer's netw= ork (IPTV, SIP, alarms, power readings, backup, you name it). In other word= s I suspect that the box in charge of terminating the line for the customer= in a much larger degree will have to be owned and/or managed by the ISP. T= his in turn leads to reports, documents, standards that define management o= f devices in the home network as seen from the Broadband Forum. I'm not saying that retail products (CPE), but I think we must consider the= implications of such a standard and be careful :-) For a layer 3 device de= ep within the network, these kind of considerations does not apply. Still f= irmware upgrade (or what I would like to call firmware change, since it is = not always per se an 'UPgrade') is a tedious process, many considerations f= or how this can be done as safe as possible is outlined in the different Br= oadband Forum documents. References: 1) "TR-069 Amendment 1 and 2, CPE WAN Management Protocol" http://broadband-forum.org/technical/download/TR-069Amendment1.pdf http://broadband-forum.org/technical/download/TR-069Amendment2.pdf 2) "TR-098 Amendment 2, Internet Gateway Device Data Model for TR-069" http://www.broadband-forum.org/technical/download/TR-98_Amendment_2.pdf 3) "TR-124, Functional Requirements for Broadband Residential Gateway Devic= es" http://broadband-forum.org/technical/download/TR-124.pdf Thanks, Ole Martin -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behal= f Of Richard Bennett Sent: 19. juni 2009 03:58 To: 'Erichsen, Kirk'; 'Livingood, Jason'; 'Stephen Farrell' Cc: Carolin.Latze@swisscom.com; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway The telco-deployed gateways are managed as CPE, using the TR stuff for firmware upgrades, but for the retail product about all we can do is advise customers to periodically apply upgrades the hard way. In a perfect world, I suppose there would be a single web site where both customers and support people could go to see what the latest revision is for every gateway, but this isn't such a world. Another option is to declare it a BCP to have an easy "check for upgrade" button on the first page of the gateway's GUI or something similar. Richard Bennett -----Original Message----- From: Erichsen, Kirk [mailto:kirk.erichsen@twcable.com] Sent: Thursday, June 18, 2009 1:34 PM To: Livingood, Jason; Stephen Farrell Cc: Carolin.Latze@swisscom.com; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway Are we only interested in a generic software mechanism ("how") that be standardized, without really worrying about the management model (the "who")? P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible. -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Sent: Thu 6/18/2009 1:56 PM To: Stephen Farrell; Erichsen, Kirk Cc: Carolin.Latze@swisscom.com; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway On 6/17/09 10:12 AM, "Stephen Farrell" wrote: > Erichsen, Kirk wrote: >> 1) Who manages the device? - I Think in most cases, 90% of the time it is the >> customer/end user. > > If so, then I think part of any spec here should include some sort > of requirement for software/firmware update for the device. While > there may not be a specific protocol for that that every vendor > would want to use, this activity (if it becomes a WG) might be > able to at least set requirements there. Firmware update methods were a topic of discussion when a few parties met to discuss the problem space in Philadelphia months ago. One of the issues is related to why web browsers and operating systems now perform automatic checks for updates. Today, this generally does not happen, though in some cases it can be prompted by the user savvy enough to visit the local device management web page periodically. In any case, there are regular security fixes which are made available and without recommendations on how updates should occur (user intervention, automatically downloaded, automatically applied, etc.) many devices leave this to the users -- and probably 90%+ of the user base will never upgrade the firmware on the device. Jason This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ 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 This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From kirk.erichsen@twcable.com Mon Jun 22 17:29:16 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 41DCF3A68AB for ; Mon, 22 Jun 2009 17:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 GUk20tWVLIOT for ; Mon, 22 Jun 2009 17:29:15 -0700 (PDT) Received: from pblpas02.twcable.com (pblpas02.twcable.com [204.235.121.150]) by core3.amsl.com (Postfix) with ESMTP id C12363A6452 for ; Mon, 22 Jun 2009 17:29:14 -0700 (PDT) X-SENDER-IP: 10.157.247.212 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,272,1243828800"; d="scan'208";a="424794824" Received: from unknown (HELO prvpmailconn2.corp.twcable.com) ([10.157.247.212]) by pblpas02.twcable.com with ESMTP; 22 Jun 2009 20:29:30 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn2.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Jun 2009 20:29:30 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 Jun 2009 20:29:29 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Management of the Home Gateway thread-index: AcnzO4+oBbX6S28eT3iCGA3i0HBKYwAB/H+QAA6PPSAAASrEyw== References: <043B361632634A649D357F73DB54F63D@Honkin> <5120D6493514464EAEB7A846D0C1DC80@Honkin> From: "Erichsen, Kirk" To: , "Wes Beebee \(wbeebee\)" , "Iljitsch van Beijnum" X-OriginalArrivalTime: 23 Jun 2009 00:29:30.0343 (UTC) FILETIME=[AC52E770:01C9F399] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: Carolin.Latze@swisscom.com, "Livingood, Jason" , homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 23 Jun 2009 00:29:16 -0000 QWxsLAogCkknZCBiZSB3aWxsaW5nIHRvIGNvbmNlZGUgb24gdGhlIGlzc3VlIG9mIGF1dG9tYXRp YyB1cGRhdGVzIHNvIGxvbmcgYXMgd2UgYXJlIGNsZWFyIHdoYXQgdGhpcyBtZWFucyBpbiBzcGVj IHRlcm1zIGFuZCB0aGF0IHdlIGFyZSB3aWxsaW5nIHRvIGp1c3RpZnkgdGhlIHRpbWUgbmVjZXNz YXJ5IHRvIGRvIGl0IHByb3Blcmx5LiBBbHNvLCB3aGF0IHByb2JsZW0gYXJlIHdlIHRyeWluZyB0 byBzb2x2ZSB3aXRoIGF1dG9tYXRpYyBzb2Z0d2FyZSB1cGRhdGVzIHRoYXQgZGlyZWN0bHkgYWZm ZWN0IHRoZSBvdGhlciBmZWF0dXJlcyB3ZSB3YW50PyBJcyB0aGlzICJjb3JlIiBmdW5jdGlvbmFs aXR5LCBvciBpdCBpcyBzb21ldGhpbmcgZWxzZT8gCiAKRm9yIGV4YW1wbGUsIGlmIHRoZSB0ZXh0 IHRlbGxzIHlvdSAiaG93IiB0aGUgYXV0b21hdGljIHVwZGF0ZXMgY291bGQgYmUgYWNjb21wbGlz aGVkLCB3aXRob3V0IG1hbmRhdGluZyB0aGF0IHRoZSByb3V0ZXIgbXVzdCBiZSBhdXRvbWF0aWNh bGx5IHVwZGF0ZWQgKHZzLiBtYW51YWwsIGV0Yy4pIGFuZCB0aGVuIHJlbmRlciB0aGUgYWN0dWFs IG1lY2hhbmlzbXMgb3B0aW9uYWwsIEkgdGhpbmsgd2UnZCBoYXZlIGEgZmFpciBjb21wcm9taXNl LiBGcm9tIGEgdmVuZG9yIHBlcnNwZWN0aXZlLCB0aGlzIHdvdWxkIG1lYW4gdGhhdCBpZiB0aGUg ZmVhdHVyZSBpcyBpbXBsZW1lbnRlZCBpbiB0aGUgcm91dGVyLCBpdCBtdXN0IGZvbGxvdyB0aGUg c3BlYyB0ZXh0LiBXaXRoIHJlZ2FyZHMgdG8gdGhlIGRldGFpbHMgd2l0aGluIHRoZSAiaG93IiBJ IHRoaW5rIHdlIGhhdmUgdG8gY2xhcmlmeSB0aGF0IHRoZXJlIG1heSBiZSBkaWZmZXJlbmNlcyBp biBhICJzdGFuZGFsb25lIiByb3V0ZXIgdnMuIG9uZSB3aGljaCBoYXMgYW4gZW1iZWRkZWQgY2Fi bGUgbW9kZW0gb3IgRFNMIG1vZGVtLiAgV2hlcmUgYSBEU0wgb3IgY2FibGUgbW9kZW0gbWF5IGJl IGVtYmVkZGVkLCBJIHN1Z2dlc3Qgd2UgcmVmZXJlbmNlIHRoZSBhcmNoaXRlY3R1cmUtZGVwZW5k ZW50IHBhcnRzIGJhY2sgaW50byB0aG9zZSBzdGFuZGFyZCBib2RpZXMgKHRoaXMgYXBwbGllcyB0 byBhIGhvc3Qgb2Ygb3RoZXIgZmVhdHVyZXMgdGhhdCB3aWxsIGNvbWUgdXApIGFzIHRoZXkgYWxy ZWFkeSBjb3ZlciB0aGVzZSBpc3N1ZXMgd2l0aGluIHRoZXNlIHJlc3BlY3RpdmUgc3BlY3MgcXVp dGUgd2VsbC4gSW4gY2FibGUsIHdlIHJlbHkgdXBvbiB0aGUgZURPQ1NJUyBtb2RlbCB3aGVyZXZl ciBhIENNIGlzIGVtYmVkZGVkIHdpdGggYW5vdGhlciBkZXZpY2UgKGxpa2UgYSByb3V0ZXIpIGFu ZCB0aGUgRE9DU0lTIHNvZnR3YXJlIGRvd25sb2FkIGZyYW1ld29yayBmb3Igc29mdHdhcmUgZG93 bmxvYWQgcmVxdWlyZW1lbnRzLiAgIAogCkJ5IGFzc3VtaW5nIHRoYXQgd2UgaGF2ZSBlaXRoZXIg YSBzdGFuZGFsb25lIGRldmljZSAodGhlICJnZW5lcmljIiBjYXNlKSBvciBhbiBlbWJlZGRlZCBk ZXZpY2Ugd2l0aCBzb21lIGZvcm0gb2YgbW9kZW0gKERTTCwgY2FibGUpIHdlIGNhbiBiaS1maWNh dGUgaW50byBoYW5kbGluZyB0aGUgaXNzdWVzIHNlcGFyYXRlbHkuIEZvciB0aGUgZ2VuZXJpYyBz dGFuZGFsb25lIGNhc2UsIHdlIGNvdWxkIHN0cmlwIGRvd24gbWFueSBvZiB0aGUgZnVuY3Rpb25z IGFuZCBiZWhhdmlvcnMsIG9yIHJlbHkgb24gYW4gZXhpc3RpbmcgZnJhbWV3b3JrIHNwZWMuCiAK T3BlcmF0aW9uYWxseSwgc29mdHdhcmUgZG93bmxvYWQgaXMgbm9uLXRyaXZpYWwgYW5kIGFzIGhh cyBiZWVuIG1lbnRpb25lZCwgd2l0aG91dCBRQSB0ZXN0aW5nIHRvIG1ha2Ugc3VyZSB0aGUgY29k ZSBiZWhhdmVzIGFwcHJvcHJpYXRlbHkgeW91IG1pZ2h0IGdldCAibmV3ZXIiIGNvZGUgd2l0aCBt b3JlIHdyb25nIHRoYW4gcmlnaHQgd2l0aCBpdC4gR2l2ZW4gdGhlIHJhem9yIHRoaW4gbWFyZ2lu cyBjb21tb24gdG8gdGhlc2UgcGxhdGZvcm1zLCB3aGF0IGdldHMgYWRkZWQgaXMgdXN1YWxseSBm ZWF0dXJlcyB0aGF0IHdlcmUgYWR2ZXJ0aXNlZCwgYnV0IHdlcmUgbWlzc2luZyBmcm9tIHRoZSBv cmlnaW5hbCBidWlsZHMgb3IgbWFqb3IvbWlub3IgYnVnIGZpeGVzIHRvIGV4aXN0aW5nIGZ1bmN0 aW9uYWxpdHkgdGhhdCBoYXZlIGJlZW4gbm90aWNlZCBhZnRlciB0aGUgZmlyc3QgcmVsZWFzZS4g SXQgd291bGQgbm90IGJlIHVucmVhc29uYWJsZSB0byBleHBlY3QgdGhhdCB2ZXJ5IGZldyBzb2Z0 d2FyZSB1cGRhdGVzIGFjdHVhbGx5IGNvbWUgb3V0IGZvciBhIGdpdmVuIHByb2R1Y3QgdGhlc2Ug ZGF5cyAoZnJvbSBhIGJ1c2luZXNzIHBlcnNwZWN0aXZlLCBpdCdzIGEgYmlnIGNvc3Qgc2luayB0 byBhIHZlbmRvciBhbmQgaXMgb25seSBkb25lIHdoZW4gaXQgbXVzdCBiZSkuIE9uZSB2ZXJ5IGdv b2QgcmVhc29uIGZvciBrZWVwaW5nIHRoZSBmZWF0dXJlIGxpc3QgdGlnaHQgaXMgdGhhdCB0aGlz IHdpbGwgY29udHJvbCBjb2RlIGJsb2F0IGFuZCBpbnZhcmlhYmx5IGNvZGUgZGVmZWN0cyB0aGF0 IHByb21wdCBvbmUgdG8gdXBkYXRlIHRoZSBzb2Z0d2FyZSBvbiB0aGUgcm91dGVyIGluIHRoZSBm aXJzdCBwbGFjZS4gCiAKU29tZSBvZiB0aGUgcmF0aGVyIGlja3kgaXNzdWVzIHdlIHdvdWxkIGNv bmZyb250IGZvciB0aGUgZ2VuZXJpYyBzdGFuZGFsb25lIGNhc2UgaW5jbHVkZSBvbmUgdGhhdCBt YXkgbm90IGJlIHNvIG9idmlvdXM6IElmIHRoZSBDTSBvciBEU0wgbW9kZW0gaXMgdXBkYXRpbmcg YW5kIHJlYm9vdHMsIGNhbiB0aGUgYmFja2dyb3VuZCBkYXRhIHRyYW5zZmVyIGZvciB0aGUgc3Rh bmRhbG9uZSByb3V0ZXIncyBvd24gc29mdHdhcmUgZG93bmxvYWQsIGlmIGhhcHBlbmluZyBjb25j dXJyZW50bHksIGJlIGFmZmVjdGVkPyBJbiB0aGlzIHNjZW5hcmlvLCBwZXJoYXBzIHRoZSB1c2Vy IGhhcyBhIHZlcnkgbG93IHVwcGVyIHRyYW5zZmVyIHJhdGUgZm9yIHNvZnR3YXJlIGRvd25sb2Fk cyBzZXQgKG9yIGl0IGNvdWxkIGV2ZW4gYmUgdGhlIGRlZmF1bHQgY29uZmlndXJhdGlvbikgd2hp Y2ggbWF5IGJlIGF0IGEgdHJhbnNmZXIgcmF0ZSB0b28gbG93IGZvciB0aGUgbW9kZW0gdG8gZGVm ZXIgaXQncyBvd24gcmVib290IGZvciwgb3Igbm8gb25lIGJvdGhlcmVkIHRvIGNoZWNrIHRoZSBh Y3Rpdml0eSBiZWZvcmUgZm9yY2luZyB0aGUgcmVib290LiAKIApXaGF0IGFmZmVjdCBtaWdodCBh biBpbnRlcnJ1cHRlZCBzb2Z0d2FyZSBkb3dubG9hZCBoYXZlIG9uIHRoZSBzdGFuZGFsb25lIHJv dXRlciAoaXQgcHJvYmFibHkgc2hvdWxkbid0IG1hdHRlciB3aGF0IGNhdXNlZCBpdCk/IFdpbGwg dGhlIHRyYW5zZmVyIG5lZWQgdG8gcmVzdW1lIHdoZXJlIGl0IGxlZnQgb2ZmIHdoZW4gdGhlIG1v ZGVtIGNvbWVzIGJhY2sgdXAgYW5kIGJyaWRnaW5nIHByb2NlZWRzLCBvciBqdXN0IHN0YXJ0IG92 ZXIgYWdhaW4/IEFyZSB0aGVyZSByZXRyaWVzLCBiYWtlb2ZmcyBvciBJQ01QIG1lc3NhZ2VzIHRo YXQgdGhlIHJvdXRlciBuZWVkcyB0byBwYXkgYXR0ZW50aW9uIHRvIHdpdGggcmVnYXJkcyB0byBz b2Z0d2FyZSBkb3dubG9hZD8gRG9lcyB0aGUgcm91dGVyIG5lZWQgdG8gY2hlY2sgYWN0aXZpdHkg b24gaXQncyBvd24gaW50ZXJmYWNlcyBvciBzeXN0ZW0gY291bnRlcnMgYmVmb3JlIGluaXRpYXRp bmcgdGhlIGVpdGhlciBhIGRvd25sb2FkIG9yIHJlYm9vdGluZyB3aXRoIGEgbmV3IHNvZnR3YXJl IGltYWdlPyBDYW4geW91IHNhZmVseSBkZXRlcm1pbmUgd2hlbiB0byByZWJvb3QgdGhlIGRldmlj ZSB3aXRob3V0IHN1ZGRlbmx5IGJlaW5nIG9ibGlnYXRlZCB0byBhZGQgY291bnRlciBvYmplY3Rz IHRvIG1vbml0b3Igc3lzdGVtL2ludGVyZmFjZSBzdGF0aXN0aWNzPyBJZiBpdCByZWFsbHkgaXMg YSB1c2VyLW1hbmFnZWQgZ2F0ZXdheSwgd2UgcmVtb3ZlIG1hbnkgb2YgdGhlc2UgY29uY2VybnMs IHRob3VnaCBpZiB0aGV5IGFyZSAiZnVsbHkiIGF1dG9tYXRpYyBpbiB0aGUgZG93bmxvYWQsIHRo ZXkgYXJlIHByb2JhYmx5IGdvaW5nIHRvIGhhdmUgdG8gZG8gc29tZSBjaGVja2luZyB0byBkZWNp ZGUgd2hlbiBvciBldmVuIGlmIHRvIGF1dG9tYXRpY2FsbHkgcmVib290IHRvIHVzZSB0aGF0IG5l dyBzb2Z0d2FyZSBpbWFnZS4KIApJbiB0aGUgY2FzZSBvZiBhIGNhYmxlIG1vZGVtLCB3ZSBoYXZl IGFjY2VzcyB0byB0aGUgQ00ncyBjb3VudGVycyBhbmQgd2UgY2FuIHN3ZWVwIHRocm91Z2ggZGV2 aWNlcyBvZiB0aGUgc2FtZSBzeXNEZXNjIGZvciBoYXJkd2FyZS9zb2Z0d2FyZSByZXYgYW5kIGRl dGVybWluZSB0aGUgY29ycmVjdCBpbWFnZSB0byBkb3dubG9hZCwgdGhlbiB2ZXJpZnkgd2hlbiBh Y3Rpdml0eSBpcyBsb3cgZW5vdWdoIHRoYXQgd2UgY2FuIHNhZmVseSByZWJvb3QgdGhlIENNLiBF dmVyeSBET0NTSVMgQ00gY2FuIHN1cHBvcnQgdHdvIHNvZnR3YXJlIGxvYWRzIGluIGZsYXNoIGlu IGNhc2UgdGhlIG5ldyBsb2FkIGZhaWxzIGZvciBvbmUgcmVhc29uIG9yIGFub3RoZXIuCiAKVGhl cmUgYXJlIHNvbWUgb3RoZXIgb2RkaXRpZXMgeW91IGhhdmUgdG8gcGxvZCB0aHJvdWdoLCBsaWtl IG11bHRpLWxldmVsIHNvZnR3YXJlIHVwZ3JhZGVzIGFuZCB3aGV0aGVyIHlvdSBzdXBwb3J0IHNv bWV0aGluZyBvdGhlciB0aGFuIG9uZSBiaWcgYmluYXJ5IGJsb2IgY29taW5nIGRvd24gdGhlIHBp cGUuIFlvdSBtYXkgZmluZCB5b3UgaGF2ZSBvbGQgc29mdHdhcmUgdmVyc2lvbnMgb3V0IHRoZXJl IHRoYXQgYSB2ZW5kb3Igd2FudHMgdG8gdXBkYXRlIGZyb20gMi4wIHRvIDQuMWEuIEhvd2V2ZXIs IHRvIGdldCBmcm9tIDIuMCB0byA0LjFhLCB5b3UgbWF5IGhhdmUgdG8gdXBncmFkZSB0byBhIGJy ZWFrLXBvaW50IHZlcnNpb24gbGlrZSAzLjEgKHNheSBpZiB0aGUgbmV3IHNvZnR3YXJlIGNoYW5n ZXMgdGhlIG9yZ2FuaXphdGlvbiBvciBmb3JtYXQgb2YgdGhlIGZsYXNoIGRldmljZSwgZXRjKS4g IAoKVGhlc2UgYXJlIGp1c3QgZXhhbXBsZXMgb2Ygc29tZSBvZiB0aGUgaXNzdWVzIHdlIHdpbGwg bmVlZCB0byBjb25mcm9udC4gQmVzdCB0byBnbyBpbiB3aXRoIGV5ZXMgd2lkZSBvcGVuLgogClJl Z2FyZHMsCiAKLUtFCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKRnJvbTogaG9t ZWdhdGUtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgUmljaGFyZCBCZW5uZXR0ClNlbnQ6 IE1vbiA2LzIyLzIwMDkgMzoxMyBQTQpUbzogJ1dlcyBCZWViZWUgKHdiZWViZWUpJzsgJ0lsaml0 c2NoIHZhbiBCZWlqbnVtJwpDYzogQ2Fyb2xpbi5MYXR6ZUBzd2lzc2NvbS5jb207ICdMaXZpbmdv b2QsSmFzb24nOyBob21lZ2F0ZUBpZXRmLm9yZwpTdWJqZWN0OiBSZTogW2hvbWVnYXRlXSBNYW5h Z2VtZW50IG9mIHRoZSBIb21lIEdhdGV3YXkKCgoKVGhlIGZhY3Qgb2YgdGhlIG1hdHRlciBpcyB0 aGF0IHRoZSB0ZWxjbyBob21lIGdhdGV3YXlzIGFscmVhZHkgc3VwcG9ydAphdXRvbWF0ZWQgZmly bXdhcmUgdXBkYXRlcywgd2l0aCB0aGUgYXBwcm9wcmlhdGUgZmFpbHNhZmVzIGFuZCByZWNvdmVy eQptZWNoYW5pc21zIHRvIGRlYWwgd2l0aCB0aGUgb2RkIGNhc2Ugb2YgYSBmYWlsZWQgdXBkYXRl LiBTbyB0aGUgcXVlc3Rpb24gaXMKd2hldGhlciB0aGUgcmV0YWlsIGhvbWUgZ2F0ZXdheXMgc2hv dWxkIHN0cml2ZSBmb3IgYSBzaW1pbGFyIGxldmVsIG9mCmZ1bmN0aW9uYWxpdHkuIEl0IHNlZW1z IHRvIG1lIHRoYXQgYXV0b21hdGVkIGZpcm13YXJlIHVwZGF0ZXMgYXJlIHRoZSBvbmx5CndheSB0 byBlbnN1cmUgdGhhdCB1cGRhdGVzIHdpbGwgZXZlciBiZSBhcHBsaWVkIGluIG1vc3QgY2FzZXMs IGFzIHRoZQp0eXBpY2FsIHVzZXIgcHJvYmFibHkgbmV2ZXIgdXNlcyB0aGUgbWFuYWdlbWVudCBH VUkgYW5kIHdvdWxkIHRoZXJlZm9yZQpuZXZlciBiZSBhYmxlIHRvIGZvcmNlIGFuIHVwZGF0ZSB2 aWEgbWFudWFsIG1lYW5zLgoKV2hpbGUgdGhlcmUncyBzb21lIGVsZW1lbnQgb2YgcmlzayBpbiBh bnkgYWN0aW9uLCB0aGUgcmlzayBvZiB1cGRhdGluZwpmaXJtd2FyZSBpbiB0aGUgcHJvY2VzcyB0 aGF0J3Mgd2VsbC1zcGVjaWZpZWQgZm9yIGF1dGhlbnRpY2F0aW9uIGFuZApyZWNvdmVyeSBpcyBs ZXNzIHRoYW4gdGhlIHJpc2sgb2YgbmV2ZXIgdXBkYXRpbmcgYW5kIHRoZXJlZm9yZSBleHBvc2lu ZyB0aGUKSW50ZXJuZXQgdG8gdGhlIGNvbnNlcXVlbmNlcyBvZiBiYWQgY29kZS4KClJpY2hhcmQg QmVubmV0dAoKClAgR28gR3JlZW4hIFByaW50IHRoaXMgZW1haWwgb25seSB3aGVuIG5lY2Vzc2Fy eS4gVGhhbmsgeW91IGZvciBoZWxwaW5nIFRpbWUgV2FybmVyIENhYmxlIGJlIGVudmlyb25tZW50 YWxseSByZXNwb25zaWJsZS4KIAogCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCkZyb206IFdl cyBCZWViZWUgKHdiZWViZWUpIFttYWlsdG86d2JlZWJlZUBjaXNjby5jb21dClNlbnQ6IE1vbmRh eSwgSnVuZSAyMiwgMjAwOSA3OjE4IEFNClRvOiBJbGppdHNjaCB2YW4gQmVpam51bTsgUmljaGFy ZCBCZW5uZXR0CkNjOiBMaXZpbmdvb2QsIEphc29uOyBDYXJvbGluLkxhdHplQHN3aXNzY29tLmNv bTsgaG9tZWdhdGVAaWV0Zi5vcmcKU3ViamVjdDogUkU6IFtob21lZ2F0ZV0gTWFuYWdlbWVudCBv ZiB0aGUgSG9tZSBHYXRld2F5CgpJbiBvcmRlciBmb3IgdGhpcyB0byB3b3JrLCB5b3Ugd291bGQg aGF2ZSB0byBoYXZlIGJhc2ljIGNvbm5lY3Rpdml0eQp3aXRob3V0IHRoZSBmaXJtd2FyZSB1cGdy YWRlLiAgU29tZXRoaW5nIGxpa2UgUk9NTU9OIG9uIENpc2NvIHJvdXRlcnMKd291bGQgZG8gdGhl IHRyaWNrOiBhIHZlcnkgYmFzaWMgT1Mgd2l0aCBqdXN0IHRoZSBjYXBhYmlsaXR5IG9mCmNvbnRh Y3RpbmcgdGhlIHNlcnZlciBhbmQgZG93bmxvYWRpbmcgdXBncmFkZXMsIGFuZCB0aGVuIGJvb3Qg dGhlIG1haW4KT1MsIHdoaWNoIHdvdWxkIGJlIHVwZ3JhZGVkLiAgVGhlbiB5b3Ugd291bGQgYWxz byBuZWVkIHRvIGhhdmUgZW5vdWdoCnJlZ3Jlc3Npb24gZG9uZSBvbiB1cGRhdGVzIHRvIGJlIHN1 cmUgdGhhdCB0aGVyZSB3b24ndCBiZSBhIGRlcGxveW1lbnQKcHJvYmxlbSAtIHNvbWV0aGluZyBs aWtlIHRoZSByZWdyZXNzaW9uIHNjcmlwdHMgdGhhdCBEZWJpYW4gcnVucyBmb3IKdXBncmFkZXMg bWF5IGRvIHRoZSB0cmljay4gIFRoZSBxdWVzdGlvbiBpczogd2l0aCB0aGUgcmF6b3ItdGhpbiBt YXJnaW5zCm9uIHRoaXMgZGV2aWNlLCBjb3VsZCB2ZW5kb3JzIGFmZm9yZCB0byBwcm92aWRlIHRo aXMgY2FwYWJpbGl0eT8KCi0gV2VzCgotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpGcm9tOiBo b21lZ2F0ZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aG9tZWdhdGUtYm91bmNlc0BpZXRmLm9y Z10gT24KQmVoYWxmIE9mIElsaml0c2NoIHZhbiBCZWlqbnVtClNlbnQ6IE1vbmRheSwgSnVuZSAy MiwgMjAwOSA5OjE0IEFNClRvOiBSaWNoYXJkIEJlbm5ldHQKQ2M6ICdMaXZpbmdvb2QsIEphc29u JzsgQ2Fyb2xpbi5MYXR6ZUBzd2lzc2NvbS5jb207IGhvbWVnYXRlQGlldGYub3JnClN1YmplY3Q6 IFJlOiBbaG9tZWdhdGVdIE1hbmFnZW1lbnQgb2YgdGhlIEhvbWUgR2F0ZXdheQoKT24gMTkganVu IDIwMDksIGF0IDEwOjEwLCBSaWNoYXJkIEJlbm5ldHQgd3JvdGU6Cgo+IE9yIGV2ZW4gYmV0dGVy LCB3ZSBjYW4gcmVjb21tZW5kIHRoYXQgdGhlIGdhdGV3YXkgYXV0b21hdGljYWxseSBjaGVjawo+ IGFuIGZ0cCBhcmNoaXZlIGZvciB1cGRhdGVzIGFuZCBhcHBseSB0aGVtIGxpa2UgV2luZG93cyBk b2VzIHdpdGgKPiBwYXRjaGVzLgo+IFZlbmRvcnMKPiBjb3VsZCBhbGxvdyB0aGlzIGZlYXR1cmUg dG8gYmUgdHVybmVkIG9mZiBieSB0aGUgc2tpbGxlZCB1c2VyLCBidXQgYnkKPiBkZWZhdWx0IGl0 IHNob3VsZCBiZSBvbi4KCk5vLCBpdCBzaG91bGRuJ3QgYmUuIFVwZGF0ZXMgb2Z0ZW4gY2F1c2Ug anVzdCBhcyBtYW55IHByb2JsZW1zIGFzIHRoZXkKc29sdmUuIEhhdmluZyBhIGhvbWUgZ2F0ZXdh eSB0aGF0IHdvcmtlZCBqdXN0IGZpbmUgYnJlYWsgYmVjYXVzZSBzb21lb25lCmRlY2lkZWQgdG8g cHVzaCBvdXQgYW4gdXBkYXRlIGlzIGNvbXBsZXRlbHkgdW5hY2NlcHRhYmxlLiAKRXNwZWNpYWxs eSBiZWNhdXNlIHVwZGF0ZSBwcm9jZWR1cmVzIGFyZSBvZnRlbiBsZW5ndGh5LCBtYXkgcmVuZGVy IHRoZQpkZXZpY2UgdW51c2FibGUgaWYgaW50ZXJydXB0ZWQsIGFuZCBpZiB0aGUgZGV2aWNlIGVu ZHMgdXAgaW4gYSBub24tCndvcmtpbmcgc3RhdGUgdGhlcmUgaXMgbm8gcmVjb3ZlcnkgYmVjYXVz ZSB0aGVyZSBpcyBubyBpbnRlcm5ldApjb25uZWN0aW9uLgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpob21lZ2F0ZSBtYWlsaW5nIGxpc3QKaG9tZWdhdGVA aWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ob21lZ2F0ZQoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KaG9tZWdhdGUg bWFpbGluZyBsaXN0CmhvbWVnYXRlQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaG9tZWdhdGUKCgpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lcgpDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlv biwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLApvciBzdWJqZWN0IHRvIGNvcHly aWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsCmlzIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hp Y2gKaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 IG9mIHRoaXMKRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1p bmF0aW9uLApkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlv biB0byB0aGUgY29udGVudHMKb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZQp1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkKdGhlIHNlbmRlciBpbW1lZGlh dGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55CmNvcHkgb2Yg dGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4K From lars.eggert@nokia.com Tue Jun 23 02:25: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 DDCBC3A6E50 for ; Tue, 23 Jun 2009 02:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 GTKEIJE-lNKd for ; Tue, 23 Jun 2009 02:25:34 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 3563D3A6C74 for ; Tue, 23 Jun 2009 02:25:33 -0700 (PDT) Received: from [192.168.0.198] (wlan.fit.nokia.com [195.148.124.254]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n5N9Pe5u097283 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 23 Jun 2009 12:25:40 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <3CA5D540-0C29-4D9E-901E-C23C7DA07725@nokia.com> From: Lars Eggert To: Michael Johas Teener In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-17--993520555; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 23 Jun 2009 12:25:35 +0300 References: X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Tue, 23 Jun 2009 12:25:41 +0300 (EEST) Cc: "homegate@ietf.org" Subject: [homegate] TSO (was: Re: Jumbo frames) 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, 23 Jun 2009 09:25:34 -0000 --Apple-Mail-17--993520555 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2009-6-22, at 21:25, Michael Johas Teener wrote: > Finally, I think there is no reason to be concerned about the 1500 > byte > limit for MTUs w/r/t TCP performance over Ethernet as long as a > reasonably > modern NIC is used. The really cheap 1G and 100M NICs that we > currently ship > have automatic IP packetizing (load up a DMA buffer with 32k bytes > and the > NIC will break it into the appropriately formatted and sized TCP > frames). > All of our competitors can do the same (with the possible exception > of the > Intel chipsets). The resulting packet stream is within a few percent > as > efficient as a jumbo frame, without interfering with the QoS of other > streams As an aside, existing hardware mechanisms for TCP segmentation offloading may stop working if TCP changes in a major way. (The Multipath TCP BOF in Stockholm - if successful - could eventually lead to such TCP changes.) Lars --Apple-Mail-17--993520555 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA2MjMwOTI1MzVaMCMGCSqGSIb3DQEJBDEWBBRWNGTEDcF1moqy V4ltxZbpu1hRCzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAEt8pVpkZdMghCELFODCQysdW0rHmtmAbSHwvB42Nnxxnuil7uXJB VldwkIoc2qCJFYxBSAxRHVAfW9rdZZ4030cXw3UCbOfoS3Eis0MvwXwAZdRhJkDvQT8VyZaP9+gA 8C44w1JyUsYDwjUtfP7g7raO/o2vhZmXXaWwV1QEnC97FWO5SiqBcfrpC/xchd673cifNKzaZ0Gc QPI9/bSGHekQi4OVvL8Tcpnpk4PcjWkwFa+2OyMZ5viTPkFzmDCnYuXgXA1ku0QIjQpSPL38676o Ef6irO+3nmntG0wG/pD0uDhW4LvfQejLruSymlmBRu1V2ovKKdJHSO/BlFq9JQAAAAAAAA== --Apple-Mail-17--993520555-- From iiarmar@upvnet.upv.es Tue Jun 23 02:26: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 08D843A6E65 for ; Tue, 23 Jun 2009 02:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 vhA1termPyZH for ; Tue, 23 Jun 2009 02:26:00 -0700 (PDT) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.21]) by core3.amsl.com (Postfix) with ESMTP id 7A0C93A6E61 for ; Tue, 23 Jun 2009 02:26:00 -0700 (PDT) Received: from pop.upv.es (deneb.cc.upv.es [158.42.3.51]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id n5N9QEea002344 for ; Tue, 23 Jun 2009 11:26:14 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by pop.upv.es (8.11.3/8.11.3) with ESMTP id n5N9QDS20816; Tue, 23 Jun 2009 11:26:13 +0200 (METDST) Received: from [127.0.0.1] (vera2g14-105.wi-fi.upv.es [158.42.14.105]) by smtp.upv.es (8.13.6/8.13.6) with ESMTP id n5N9QCTN006518 for ; Tue, 23 Jun 2009 11:26:12 +0200 Message-ID: <4A409FA9.9070807@upvnet.upv.es> Date: Tue, 23 Jun 2009 11:26:01 +0200 From: =?ISO-8859-1?Q?I=F1igo_Artundo?= User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: homegate@ietf.org References: <8239FE40-6544-4304-9C38-F08317CD3598@muada.com><69E254EE-C489-41C5-AA6B-6857B9EC8C56@americafree.tv><4F3B2C7A-AA49-43C8-8571-2807B9C339E9@muada.com> <6DF7ABCE-8DED-48B8-B545-DE383A4AB115@muada.com> <362FBC643A9148A28FC5B1E9F7D9B567@Honkin> <4DC73880499B49FD801AFFA654A9BFB6@Honkin> In-Reply-To: <4DC73880499B49FD801AFFA654A9BFB6@Honkin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090621-0, 21/06/2009), Outbound message X-Antivirus-Status: Clean Subject: Re: [homegate] Jumbo frames 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, 23 Jun 2009 09:26:03 -0000 Related to Gb WANs and the use of 10/100/1000 Ethernet ports in computers and network equipment, please remember as someone already said, that all the thinking being done here is for a midterm future, not for the current market, which means that technologies that now are not mainstream, it may very well be in a 5-8 years timeframe. Think ahead. And I agree that the discussion about jumboframes should be taken out from this homegate list to other more relevant wg. Iñigo Richard Bennett wrote: > Aren't jumbo frames generally used within the LAN? When they are, there's no > need for fragmentation. When they pass through the NAT toward the Internet, > it's a different story, of course, but we don't have so many Gigagbit WAN > connections today, outside of high-end consumers in Japan. > > Richard Bennett > > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Monday, June 22, 2009 2:20 PM > To: richard@bennett.com > Cc: 'Marshall Eubanks'; 'Michael Johas Teener'; homegate@ietf.org > Subject: Re: [homegate] Jumbo frames > > On 22 jun 2009, at 23:09, Richard Bennett wrote: > >> I'd like to remind people that frame size is a MAC protocol issue, >> and not >> something that the IETF needs to have a specific opinion about, >> beyond "be >> conservative in what you send and liberal in what you accept." > > The problem is that IP assumes that every subnet has a fixed MTU. > Since obviously the 1500-byte stuff isn't going anywhere, the addition > of jumboframe-capable hardware creates a problem, because now we have > systems with two (or more) different MTUs on a subnet, which doesn't > work in the general case although the TCP MSS option hides a multitude > of sins. (Not the sin of having a 1500-byte switch sit between all the > jumbo-capable systems, though.) > > ((I keep telling people that RFC 894 (IP over ethernet) is an april > fools day RFC, published on april 1 1984, and we shouldn't take it > seriously but nobody listens.)) > >> If 802 >> permits or mandates support for jumbo frames, it will happen, and if >> they >> don't it probably won't. > > Also not exactly true. Like I wrote before, the same vendors that make > up IEEE 802.3 also build products that ignore the 1500-byte MTU limit > in 802.3. > > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate > -- Iñigo Artundo, PhD iTEAM - Grupo de Comunicaciones Opticas Universidad Politecnica de Valencia (UPV) http://www.iteam.upv.es From stephen.farrell@cs.tcd.ie Tue Jun 23 04:45:09 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 EFF393A6E7B for ; Tue, 23 Jun 2009 04:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.293 X-Spam-Level: X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1] 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 boNcHPorg3x3 for ; Tue, 23 Jun 2009 04:45:09 -0700 (PDT) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id 2D9D03A6E67 for ; Tue, 23 Jun 2009 04:45:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 9271E1003F504; Tue, 23 Jun 2009 12:45:23 +0100 (IST) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48kJEa+aHLNf; Tue, 23 Jun 2009 12:45:23 +0100 (IST) Received: from [192.168.3.171] (unknown [192.168.3.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id A81271003F4B0; Tue, 23 Jun 2009 12:45:22 +0100 (IST) Message-ID: <4A40C053.7010401@cs.tcd.ie> Date: Tue, 23 Jun 2009 12:45:23 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: richard@bennett.com References: <043B361632634A649D357F73DB54F63D@Honkin> <5120D6493514464EAEB7A846D0C1DC80@Honkin> In-Reply-To: <5120D6493514464EAEB7A846D0C1DC80@Honkin> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'Livingood, Jason'" , homegate@ietf.org, Carolin.Latze@swisscom.com Subject: Re: [homegate] Management of the Home Gateway 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, 23 Jun 2009 11:45:10 -0000 Richard Bennett wrote: > The fact of the matter is that the telco home gateways already support > automated firmware updates, with the appropriate failsafes and recovery > mechanisms to deal with the odd case of a failed update. So the question is > whether the retail home gateways should strive for a similar level of > functionality. It seems to me that automated firmware updates are the only > way to ensure that updates will ever be applied in most cases, as the > typical user probably never uses the management GUI and would therefore > never be able to force an update via manual means. > > While there's some element of risk in any action, the risk of updating > firmware in the process that's well-specified for authentication and > recovery is less than the risk of never updating and therefore exposing the > Internet to the consequences of bad code. +1 to that. Stephen. From jason_livingood@cable.comcast.com Tue Jun 23 06:17:01 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 6851728C323 for ; Tue, 23 Jun 2009 06:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[AWL=4.699, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 qplM+qGejyK0 for ; Tue, 23 Jun 2009 06:17:00 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 2F62328C322 for ; Tue, 23 Jun 2009 06:17:00 -0700 (PDT) Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.42787925; Tue, 23 Jun 2009 09:16:59 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Jun 2009 09:16:59 -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, 23 Jun 2009 13:16:09 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 23 Jun 2009 09:16:06 -0400 From: "Livingood, Jason" To: Richard Bennett , "'Erichsen, Kirk'" , 'Stephen Farrell' Message-ID: Thread-Topic: [homegate] Management of the Home Gateway Thread-Index: AcnwTs3wW7J6+O9yb0eRW8e2IgBNOAAAqErrAAvUBSAADRJSsADT7tpE In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Jun 2009 13:16:59.0531 (UTC) FILETIME=[E3C75DB0:01C9F404] Cc: Carolin.Latze@swisscom.com, homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 23 Jun 2009 13:17:01 -0000 This is precisely what I was getting at. It seems bad hygiene to expect that a user will update their software automatically - it just does not happen in reality. The box runs, so why update it? As OS vendors have learned, you have to automate this for the user. So something along the lines of: A software (firmware) update function must be present, which periodically and without user intervention, checks for and downloads firmware updates. Optionally, a software installation function may apply these automatically-downloaded firmware updates on the device on either (1) an immediate basis or (2) a pre-scheduled basis. All of the above settings should be pre-configured and defaulted on/active by the device maker, and users should have the ability to modify such settings. [We may also need to provide some text about a security mechanism to verify that the firmware updates is properly signed/trust-verified.] Jason On 6/19/09 4:10 AM, "Richard Bennett" wrote: > Or even better, we can recommend that the gateway automatically check an ftp > archive for updates and apply them like Windows does with patches. Vendors > could allow this feature to be turned off by the skilled user, but by > default it should be on. > > RB > >> -----Original Message----- >> From: Richard Bennett [mailto:richard@bennett.com] >> Sent: Thursday, June 18, 2009 6:58 PM >> To: 'Erichsen, Kirk'; 'Livingood, Jason'; 'Stephen Farrell' >> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >> Subject: Re: [homegate] Management of the Home Gateway >> >> The telco-deployed gateways are managed as CPE, using the TR stuff for >> firmware upgrades, but for the retail product about all we can do is >> advise >> customers to periodically apply upgrades the hard way. In a perfect world, >> I >> suppose there would be a single web site where both customers and support >> people could go to see what the latest revision is for every gateway, but >> this isn't such a world. >> >> Another option is to declare it a BCP to have an easy "check for upgrade" >> button on the first page of the gateway's GUI or something similar. >> >> Richard Bennett >> >> -----Original Message----- >> From: Erichsen, Kirk [mailto:kirk.erichsen@twcable.com] >> Sent: Thursday, June 18, 2009 1:34 PM >> To: Livingood, Jason; Stephen Farrell >> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >> Subject: Re: [homegate] Management of the Home Gateway >> >> >> Are we only interested in a generic software mechanism ("how") that be >> standardized, without really worrying about the management model (the >> "who")? >> >> >> >> P Go Green! Print this email only when necessary. Thank you for helping >> Time >> Warner Cable be environmentally responsible. >> >> >> -----Original Message----- >> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] >> Sent: Thu 6/18/2009 1:56 PM >> To: Stephen Farrell; Erichsen, Kirk >> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >> Subject: Re: [homegate] Management of the Home Gateway >> >> On 6/17/09 10:12 AM, "Stephen Farrell" wrote: >>> Erichsen, Kirk wrote: >>>> 1) Who manages the device? - I Think in most cases, 90% of the time it >> is >> the >>>> customer/end user. >>> >>> If so, then I think part of any spec here should include some sort >>> of requirement for software/firmware update for the device. While >>> there may not be a specific protocol for that that every vendor >>> would want to use, this activity (if it becomes a WG) might be >>> able to at least set requirements there. >> >> Firmware update methods were a topic of discussion when a few parties met >> to >> discuss the problem space in Philadelphia months ago. One of the issues >> is >> related to why web browsers and operating systems now perform automatic >> checks for updates. Today, this generally does not happen, though in some >> cases it can be prompted by the user savvy enough to visit the local >> device >> management web page periodically. In any case, there are regular security >> fixes which are made available and without recommendations on how updates >> should occur (user intervention, automatically downloaded, automatically >> applied, etc.) many devices leave this to the users -- and probably 90%+ >> of >> the user base will never upgrade the firmware on the device. >> >> Jason >> >> >> >> This E-mail and any of its attachments may contain Time Warner >> Cable proprietary information, which is privileged, confidential, >> or subject to copyright belonging to Time Warner Cable. This E-mail >> is intended solely for the use of the individual or entity to which >> it is addressed. If you are not the intended recipient of this >> E-mail, you are hereby notified that any dissemination, >> distribution, copying, or action taken in relation to the contents >> of and attachments to this E-mail is strictly prohibited and may be >> unlawful. If you have received this E-mail in error, please notify >> the sender immediately and permanently delete the original and any >> copy of this E-mail and any printout. >> _______________________________________________ >> 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 jegoodwi@cisco.com Tue Jun 23 06:20:12 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 A34F928C333 for ; Tue, 23 Jun 2009 06:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 SYzCgbXBlcqZ for ; Tue, 23 Jun 2009 06:20:11 -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 1E5AF3A6A2C for ; Tue, 23 Jun 2009 06:20:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,275,1243814400"; d="scan'208";a="330077009" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 23 Jun 2009 13:20:27 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5NDKRo7023419; Tue, 23 Jun 2009 06:20:27 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n5NDKRwg024388; Tue, 23 Jun 2009 13:20:27 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Jun 2009 06:20:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jun 2009 06:20:53 -0700 Message-ID: <2AB1DCE354761449A2E270681CC0429808B87F35@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Management of the Home Gateway Thread-Index: Acn0BW7wFF4XAmz5TkGJTOWEKVGwBA== References: <043B361632634A649D357F73DB54F63D@Honkin><5120D6493514464EAEB7A846D0C1DC80@Honkin> From: "Jeff Goodwin (jegoodwi)" To: "Erichsen, Kirk" , , "Wes Beebee (wbeebee)" , "Iljitsch van Beijnum" X-OriginalArrivalTime: 23 Jun 2009 13:20:27.0176 (UTC) FILETIME=[5F8B7A80:01C9F405] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11101; t=1245763227; x=1246627227; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jegoodwi@cisco.com; z=From:=20=22Jeff=20Goodwin=20(jegoodwi)=22=20 |Subject:=20RE=3A=20[homegate]=20Management=20of=20the=20Ho me=20Gateway |Sender:=20; bh=BZTbjN1B9hAoi16GIUT+XMxByPp/x4TtZIIQb97fdj8=; b=tS7r6N3R6RZxCgTlxpKTKXuzoCzGOylmK2NmVtCEDxYXjfxSlAeuLCBX5A 7oX9M7rwPgHgd39kXUAddQyaWw71B4Rcn5AMQub6yQE92hvYeZYgM2fkTwy+ xwwYt+SFLm; Authentication-Results: sj-dkim-4; header.From=jegoodwi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Carolin.Latze@swisscom.com, "Livingood, Jason" , homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 23 Jun 2009 13:20:12 -0000 Kirk, ALL,=20 One of the major differences between "retail" CPE, and "Service Provider routers" layer 2 related components in the service provider network. Examples of this include CMTS/DSLAM, SoftSwitch. However, layer 3 components such as IMS, and emerging categories like self-healing support systems could be considered common. It would be useful to allow the CPE to register & receive notifications of network components that go through SW upgrades. A software framework which embodies this, while allowing differences in protocol implementation (e.g., TR--069, v.s. HTTP/SOAP/XML, HNAP, SNMP, CLI, WEB, etc..) would be ideal from our perspective. Having an XML schema to represent the data model would serve as a good point of reference. There is also a need to register network elements for logging, self-healing, and corrective action to be taken based on events happening in the network or on the device (including possible SW upgrades). Note that the ability to extend the framework by allowing registration of other devices in the internal network, would improve the ability to automate problem resolution in home networking. Best regards, Jeff Product Management & Engineering Cable Home Networking Business Unit Cisco Systems, Inc. -----Original Message----- From: Erichsen, Kirk [mailto:kirk.erichsen@twcable.com]=20 Sent: Monday, June 22, 2009 8:29 PM To: richard@bennett.com; Wes Beebee (wbeebee); Iljitsch van Beijnum Cc: Carolin.Latze@swisscom.com; Livingood,Jason; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway All, =20 I'd be willing to concede on the issue of automatic updates so long as we are clear what this means in spec terms and that we are willing to justify the time necessary to do it properly. Also, what problem are we trying to solve with automatic software updates that directly affect the other features we want? Is this "core" functionality, or it is something else?=20 =20 For example, if the text tells you "how" the automatic updates could be accomplished, without mandating that the router must be automatically updated (vs. manual, etc.) and then render the actual mechanisms optional, I think we'd have a fair compromise. From a vendor perspective, this would mean that if the feature is implemented in the router, it must follow the spec text. With regards to the details within the "how" I think we have to clarify that there may be differences in a "standalone" router vs. one which has an embedded cable modem or DSL modem. Where a DSL or cable modem may be embedded, I suggest we reference the architecture-dependent parts back into those standard bodies (this applies to a host of other features that will come up) as they already cover these issues within these respective specs quite well. In cable, we rely upon the eDOCSIS model wherever a CM is embedded with another device (like a router) and the DOCSIS software download framework for software download requirements. =20 =20 By assuming that we have either a standalone device (the "generic" case) or an embedded device with some form of modem (DSL, cable) we can bi-ficate into handling the issues separately. For the generic standalone case, we could strip down many of the functions and behaviors, or rely on an existing framework spec. =20 Operationally, software download is non-trivial and as has been mentioned, without QA testing to make sure the code behaves appropriately you might get "newer" code with more wrong than right with it. Given the razor thin margins common to these platforms, what gets added is usually features that were advertised, but were missing from the original builds or major/minor bug fixes to existing functionality that have been noticed after the first release. It would not be unreasonable to expect that very few software updates actually come out for a given product these days (from a business perspective, it's a big cost sink to a vendor and is only done when it must be). One very good reason for keeping the feature list tight is that this will control code bloat and invariably code defects that prompt one to update the software on the router in the first place.=20 =20 Some of the rather icky issues we would confront for the generic standalone case include one that may not be so obvious: If the CM or DSL modem is updating and reboots, can the background data transfer for the standalone router's own software download, if happening concurrently, be affected? In this scenario, perhaps the user has a very low upper transfer rate for software downloads set (or it could even be the default configuration) which may be at a transfer rate too low for the modem to defer it's own reboot for, or no one bothered to check the activity before forcing the reboot.=20 =20 What affect might an interrupted software download have on the standalone router (it probably shouldn't matter what caused it)? Will the transfer need to resume where it left off when the modem comes back up and bridging proceeds, or just start over again? Are there retries, bakeoffs or ICMP messages that the router needs to pay attention to with regards to software download? Does the router need to check activity on it's own interfaces or system counters before initiating the either a download or rebooting with a new software image? Can you safely determine when to reboot the device without suddenly being obligated to add counter objects to monitor system/interface statistics? If it really is a user-managed gateway, we remove many of these concerns, though if they are "fully" automatic in the download, they are probably going to have to do some checking to decide when or even if to automatically reboot to use that new software image. =20 In the case of a cable modem, we have access to the CM's counters and we can sweep through devices of the same sysDesc for hardware/software rev and determine the correct image to download, then verify when activity is low enough that we can safely reboot the CM. Every DOCSIS CM can support two software loads in flash in case the new load fails for one reason or another. =20 There are some other oddities you have to plod through, like multi-level software upgrades and whether you support something other than one big binary blob coming down the pipe. You may find you have old software versions out there that a vendor wants to update from 2.0 to 4.1a. However, to get from 2.0 to 4.1a, you may have to upgrade to a break-point version like 3.1 (say if the new software changes the organization or format of the flash device, etc). =20 These are just examples of some of the issues we will need to confront. Best to go in with eyes wide open. =20 Regards, =20 -KE ________________________________ From: homegate-bounces@ietf.org on behalf of Richard Bennett Sent: Mon 6/22/2009 3:13 PM To: 'Wes Beebee (wbeebee)'; 'Iljitsch van Beijnum' Cc: Carolin.Latze@swisscom.com; 'Livingood,Jason'; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway The fact of the matter is that the telco home gateways already support automated firmware updates, with the appropriate failsafes and recovery mechanisms to deal with the odd case of a failed update. So the question is whether the retail home gateways should strive for a similar level of functionality. It seems to me that automated firmware updates are the only way to ensure that updates will ever be applied in most cases, as the typical user probably never uses the management GUI and would therefore never be able to force an update via manual means. While there's some element of risk in any action, the risk of updating firmware in the process that's well-specified for authentication and recovery is less than the risk of never updating and therefore exposing the Internet to the consequences of bad code. Richard Bennett P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible. =20 =20 -----Original Message----- From: Wes Beebee (wbeebee) [mailto:wbeebee@cisco.com] Sent: Monday, June 22, 2009 7:18 AM To: Iljitsch van Beijnum; Richard Bennett Cc: Livingood, Jason; Carolin.Latze@swisscom.com; homegate@ietf.org Subject: RE: [homegate] Management of the Home Gateway In order for this to work, you would have to have basic connectivity without the firmware upgrade. Something like ROMMON on Cisco routers would do the trick: a very basic OS with just the capability of contacting the server and downloading upgrades, and then boot the main OS, which would be upgraded. Then you would also need to have enough regression done on updates to be sure that there won't be a deployment problem - something like the regression scripts that Debian runs for upgrades may do the trick. The question is: with the razor-thin margins on this device, could vendors afford to provide this capability? - Wes -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behalf Of Iljitsch van Beijnum Sent: Monday, June 22, 2009 9:14 AM To: Richard Bennett Cc: 'Livingood, Jason'; Carolin.Latze@swisscom.com; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway On 19 jun 2009, at 10:10, Richard Bennett wrote: > Or even better, we can recommend that the gateway automatically check > an ftp archive for updates and apply them like Windows does with > patches. > Vendors > could allow this feature to be turned off by the skilled user, but by > default it should be on. No, it shouldn't be. Updates often cause just as many problems as they solve. Having a home gateway that worked just fine break because someone decided to push out an update is completely unacceptable.=20 Especially because update procedures are often lengthy, may render the device unusable if interrupted, and if the device ends up in a non- working state there is no recovery because there is no internet connection. _______________________________________________ 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 This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From iljitsch@muada.com Tue Jun 23 06:24:07 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 540C728C337 for ; Tue, 23 Jun 2009 06:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 In9-a5m5fJL6 for ; Tue, 23 Jun 2009 06:24:06 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 022B83A6AC0 for ; Tue, 23 Jun 2009 06:23:58 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n5NDNhXf043891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Jun 2009 15:23:44 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: "Livingood, Jason" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 23 Jun 2009 15:23:16 +0200 References: X-Mailer: Apple Mail (2.935.3) Cc: homegate@ietf.org, Carolin.Latze@swisscom.com Subject: Re: [homegate] Management of the Home Gateway 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, 23 Jun 2009 13:24:07 -0000 On 23 jun 2009, at 15:16, Livingood, Jason wrote: > A software (firmware) update function must be present, which > periodically > and without user intervention, checks for and downloads firmware > updates. I have to very strongly object to the above. Your assumption is that upgrading is necessary, even if the user doesn't want to. That is a flawed assumption unless you're speaking from personal involvement in creating firmware that is so bad that this is true. Updates frequently introduce new bugs, so the hesitation on many user's part to upgrade is often quite reasonable. The service interruption involved may be unacceptable on its own. I don't think vendors want to include double the flash memory for this purpose, either. A much better way to upgrade would be to download the new firmware to a local system which also has a copy of the currently running firmware, and then perform the update over the local network when the user chooses to do so. From tme@americafree.tv Tue Jun 23 06:36: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 7188428C331 for ; Tue, 23 Jun 2009 06:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 c3EMX1DrSBqI for ; Tue, 23 Jun 2009 06:36:41 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 5BBCE28C32C for ; Tue, 23 Jun 2009 06:36:41 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 6CBAA413F223; Tue, 23 Jun 2009 09:36:57 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Iljitsch van Beijnum In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 23 Jun 2009 09:36:57 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: Carolin.Latze@swisscom.com, "Livingood, Jason" , homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 23 Jun 2009 13:36:43 -0000 On Jun 23, 2009, at 9:23 AM, Iljitsch van Beijnum wrote: > On 23 jun 2009, at 15:16, Livingood, Jason wrote: > >> A software (firmware) update function must be present, which >> periodically >> and without user intervention, checks for and downloads firmware >> updates. > > I have to very strongly object to the above. +1 from me. Marshall > > > Your assumption is that upgrading is necessary, even if the user > doesn't want to. That is a flawed assumption unless you're speaking > from personal involvement in creating firmware that is so bad that > this is true. > > Updates frequently introduce new bugs, so the hesitation on many > user's part to upgrade is often quite reasonable. > > The service interruption involved may be unacceptable on its own. > > I don't think vendors want to include double the flash memory for > this purpose, either. > > A much better way to upgrade would be to download the new firmware > to a local system which also has a copy of the currently running > firmware, and then perform the update over the local network when > the user chooses to do so. > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate > From stephen.farrell@cs.tcd.ie Tue Jun 23 07:35:02 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 354B63A6E59 for ; Tue, 23 Jun 2009 07:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.293 X-Spam-Level: X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1] 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 k-ZW2J7N72Gg for ; Tue, 23 Jun 2009 07:35:01 -0700 (PDT) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id 2E7643A6D1D for ; Tue, 23 Jun 2009 07:35:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 08BE51003F52E; Tue, 23 Jun 2009 15:35:16 +0100 (IST) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkrqprsmyrWp; Tue, 23 Jun 2009 15:35:15 +0100 (IST) Received: from [192.168.3.171] (unknown [192.168.3.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id 468A81003F4B0; Tue, 23 Jun 2009 15:35:15 +0100 (IST) Message-ID: <4A40E824.6090709@cs.tcd.ie> Date: Tue, 23 Jun 2009 15:35:16 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: Iljitsch van Beijnum References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Livingood, Jason" , homegate@ietf.org, Carolin.Latze@swisscom.com Subject: Re: [homegate] Management of the Home Gateway 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, 23 Jun 2009 14:35:02 -0000 Iljitsch van Beijnum wrote: > On 23 jun 2009, at 15:16, Livingood, Jason wrote: > >> A software (firmware) update function must be present, which periodically >> and without user intervention, checks for and downloads firmware updates. > > I have to very strongly object to the above. > > Your assumption is that upgrading is necessary, even if the user doesn't > want to. That is a flawed assumption unless you're speaking from > personal involvement in creating firmware that is so bad that this is true. I think that's overstated somewhat. There are times when pushing out fixes is the right thing. I guess security patches would be the prime example there. > Updates frequently introduce new bugs, so the hesitation on many user's > part to upgrade is often quite reasonable. Fair point. I think everyone seems to agree that if anything is done here, that the user must be able to override whatever is the default setting. > The service interruption involved may be unacceptable on its own. > > I don't think vendors want to include double the flash memory for this > purpose, either. > > A much better way to upgrade would be to download the new firmware to a > local system which also has a copy of the currently running firmware, > and then perform the update over the local network when the user chooses > to do so. Right. But the problem there is that most users just aren't aware of any of this and so never upgrade/patch. I guess the question for me is whether its better to have a default of automatically updating or a default where the user chooses when to update. I don't claim to know the right answer, but I do think that savvy users are a minority that are more likely to want to control when updates happen, and that the majority of users never do anything and hence never get anything except automatic updates. To me that implies that the better default is to automatically update. However, that's really just a hunch - does anyone have any data on this that they could share? S. From tme@americafree.tv Tue Jun 23 07:49:10 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 188F63A6CB7 for ; Tue, 23 Jun 2009 07:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 Zqsq3zz0bePb for ; Tue, 23 Jun 2009 07:49:09 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 9A91F28C16D for ; Tue, 23 Jun 2009 07:49:07 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id DDD3F4140E6A; Tue, 23 Jun 2009 10:49:19 -0400 (EDT) Message-Id: <3B59A5CF-B8B2-4832-985F-182597439ECF@americafree.tv> From: Marshall Eubanks To: "Livingood, Jason" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 23 Jun 2009 10:49:19 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: homegate@ietf.org, Carolin.Latze@swisscom.com Subject: Re: [homegate] Management of the Home Gateway 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, 23 Jun 2009 14:49:10 -0000 On Jun 23, 2009, at 9:16 AM, Livingood, Jason wrote: > This is precisely what I was getting at. It seems bad hygiene to > expect > that a user will update their software automatically - it just does > not > happen in reality. The box runs, so why update it? As OS vendors > have > learned, you have to automate this for the user. > The OS's I use do not do this by default, and I only know of one which does. That is different from informing the user that upgrades are available or needed. There is to me another issue here. Most home users, in my experience, know (or remember) nothing of the various GUI interfaces for their devices. A SOHO network might easily have a cable modem, a wireless router, and a wireline switch from different vendors, all with completely different GUI's for fairly similar functions. Very few users will deal with this unless forced to. That is one advantage an OS vendor has - the power to put a dialog box in front of the user. Would it be in scope to describe some sort of ZeroConf type mechanism for doing this ? My printer complains when it needs ink, why shouldn't my router be able to complain when it needs an update ? Regards Marshall > So something along the lines of: > A software (firmware) update function must be present, which > periodically > and without user intervention, checks for and downloads firmware > updates. > Optionally, a software installation function may apply these > automatically-downloaded firmware updates on the device on either > (1) an > immediate basis or (2) a pre-scheduled basis. All of the above > settings > should be pre-configured and defaulted on/active by the device > maker, and > users should have the ability to modify such settings. [We may also > need to > provide some text about a security mechanism to verify that the > firmware > updates is properly signed/trust-verified.] > > Jason > > > On 6/19/09 4:10 AM, "Richard Bennett" wrote: > >> Or even better, we can recommend that the gateway automatically >> check an ftp >> archive for updates and apply them like Windows does with patches. >> Vendors >> could allow this feature to be turned off by the skilled user, but by >> default it should be on. >> >> RB >> >>> -----Original Message----- >>> From: Richard Bennett [mailto:richard@bennett.com] >>> Sent: Thursday, June 18, 2009 6:58 PM >>> To: 'Erichsen, Kirk'; 'Livingood, Jason'; 'Stephen Farrell' >>> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >>> Subject: Re: [homegate] Management of the Home Gateway >>> >>> The telco-deployed gateways are managed as CPE, using the TR stuff >>> for >>> firmware upgrades, but for the retail product about all we can do is >>> advise >>> customers to periodically apply upgrades the hard way. In a >>> perfect world, >>> I >>> suppose there would be a single web site where both customers and >>> support >>> people could go to see what the latest revision is for every >>> gateway, but >>> this isn't such a world. >>> >>> Another option is to declare it a BCP to have an easy "check for >>> upgrade" >>> button on the first page of the gateway's GUI or something similar. >>> >>> Richard Bennett >>> >>> -----Original Message----- >>> From: Erichsen, Kirk [mailto:kirk.erichsen@twcable.com] >>> Sent: Thursday, June 18, 2009 1:34 PM >>> To: Livingood, Jason; Stephen Farrell >>> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >>> Subject: Re: [homegate] Management of the Home Gateway >>> >>> >>> Are we only interested in a generic software mechanism ("how") >>> that be >>> standardized, without really worrying about the management model >>> (the >>> "who")? >>> >>> >>> >>> P Go Green! Print this email only when necessary. Thank you for >>> helping >>> Time >>> Warner Cable be environmentally responsible. >>> >>> >>> -----Original Message----- >>> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] >>> Sent: Thu 6/18/2009 1:56 PM >>> To: Stephen Farrell; Erichsen, Kirk >>> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >>> Subject: Re: [homegate] Management of the Home Gateway >>> >>> On 6/17/09 10:12 AM, "Stephen Farrell" >>> wrote: >>>> Erichsen, Kirk wrote: >>>>> 1) Who manages the device? - I Think in most cases, 90% of the >>>>> time it >>> is >>> the >>>>> customer/end user. >>>> >>>> If so, then I think part of any spec here should include some sort >>>> of requirement for software/firmware update for the device. While >>>> there may not be a specific protocol for that that every vendor >>>> would want to use, this activity (if it becomes a WG) might be >>>> able to at least set requirements there. >>> >>> Firmware update methods were a topic of discussion when a few >>> parties met >>> to >>> discuss the problem space in Philadelphia months ago. One of the >>> issues >>> is >>> related to why web browsers and operating systems now perform >>> automatic >>> checks for updates. Today, this generally does not happen, though >>> in some >>> cases it can be prompted by the user savvy enough to visit the local >>> device >>> management web page periodically. In any case, there are regular >>> security >>> fixes which are made available and without recommendations on how >>> updates >>> should occur (user intervention, automatically downloaded, >>> automatically >>> applied, etc.) many devices leave this to the users -- and >>> probably 90%+ >>> of >>> the user base will never upgrade the firmware on the device. >>> >>> Jason >>> >>> >>> >>> This E-mail and any of its attachments may contain Time Warner >>> Cable proprietary information, which is privileged, confidential, >>> or subject to copyright belonging to Time Warner Cable. This E-mail >>> is intended solely for the use of the individual or entity to which >>> it is addressed. If you are not the intended recipient of this >>> E-mail, you are hereby notified that any dissemination, >>> distribution, copying, or action taken in relation to the contents >>> of and attachments to this E-mail is strictly prohibited and may be >>> unlawful. If you have received this E-mail in error, please notify >>> the sender immediately and permanently delete the original and any >>> copy of this E-mail and any printout. >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate > From bcarrick@finepoint.com Tue Jun 23 08:01:41 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 86B573A6B73 for ; Tue, 23 Jun 2009 08:01:41 -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 ki5Yo360BFz4 for ; Tue, 23 Jun 2009 08:01:40 -0700 (PDT) Received: from mail-relay.finepoint.com (mail-relay.finepoint.com [38.96.173.11]) by core3.amsl.com (Postfix) with ESMTP id 471C13A6E9E for ; Tue, 23 Jun 2009 08:01:39 -0700 (PDT) Received: from uss-republic.finepoint.com (uss-republic.finepoint.com [38.96.173.4]) by mail-relay.finepoint.com (8.12.11.20060308/8.12.11) with ESMTP id n5NF1sf6019825 for ; Tue, 23 Jun 2009 11:01:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jun 2009 11:01:54 -0400 Message-ID: In-Reply-To: <3B59A5CF-B8B2-4832-985F-182597439ECF@americafree.tv> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Management of the Home Gateway thread-index: Acn0Ef2SLt9QibVyTr+zzgxzRAzk2QAAHlUA References: <3B59A5CF-B8B2-4832-985F-182597439ECF@americafree.tv> From: "Bob Carrick" To: X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 38.96.173.11 Subject: Re: [homegate] Management of the Home Gateway 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, 23 Jun 2009 15:01:41 -0000 Just a quick chime in on this thread guys. There is a remote management standard, TR-069, for all broadband types (currently minus the Cable forums though, but is Wimax, DSL, Femto, IPTV, VoIP, Fiber and their respective forums, etc) that answers most if not all of these questions for you that have been brought up in this thread, or at least the vendors of those solutions do. With many TR-069 solutions you can do hands free provisioning (remote) and simple things such as scheduled remote upgrades via a simple unified interface for remote management of all those above mentioned device types. This allows firmware revs to be signed off on by you and rolled out across all the supported devices. This way bugs are introduced etc. You could also automatically roll your users back to your "supported" firmware if you know bugs are in newer versions (or older) that you don't want to support, etc. You can also provide that unified interface to your customer in a portal of types and let them upgrade or manage their own CPE. I could go on and try to touch on each point raised in the thread, but it is a long thread. Bob Carrick Director - Broadband Products Fine Point Technologies, Inc. 75 Broad Street, Suite 300 New York, NY 10004 email: bcarrick@finepoint.com phone: +1.212.962.7410 x62 fax: +1.212.962.7404 web: http://www.finepoint.com > -----Original Message----- > From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On > Behalf Of Marshall Eubanks > Sent: Tuesday, June 23, 2009 10:49 AM > To: Livingood, Jason > Cc: homegate@ietf.org; Carolin.Latze@swisscom.com > Subject: Re: [homegate] Management of the Home Gateway >=20 >=20 > On Jun 23, 2009, at 9:16 AM, Livingood, Jason wrote: >=20 > > This is precisely what I was getting at. It seems bad hygiene to > > expect > > that a user will update their software automatically - it just does > > not > > happen in reality. The box runs, so why update it? As OS vendors > > have > > learned, you have to automate this for the user. > > >=20 > The OS's I use do not do this by default, and I only know of one which > does. That is different from > informing the user that upgrades are available or needed. >=20 > There is to me another issue here. Most home users, in my experience, > know (or remember) nothing of the various GUI > interfaces for their devices. A SOHO network might easily have a cable > modem, a wireless router, and a wireline switch from different > vendors, all with completely different GUI's for fairly similar > functions. Very few users will deal with this unless forced to. That > is one advantage an OS vendor has - the power to put a dialog box in > front of the user. >=20 > Would it be in scope to describe some sort of ZeroConf type mechanism > for doing this ? My printer complains when it needs ink, why shouldn't > my router be able to complain when it needs an update ? >=20 > Regards > Marshall >=20 >=20 > > So something along the lines of: > > A software (firmware) update function must be present, which > > periodically > > and without user intervention, checks for and downloads firmware > > updates. > > Optionally, a software installation function may apply these > > automatically-downloaded firmware updates on the device on either > > (1) an > > immediate basis or (2) a pre-scheduled basis. All of the above > > settings > > should be pre-configured and defaulted on/active by the device > > maker, and > > users should have the ability to modify such settings. [We may also > > need to > > provide some text about a security mechanism to verify that the > > firmware > > updates is properly signed/trust-verified.] > > > > Jason > > > > > > On 6/19/09 4:10 AM, "Richard Bennett" wrote: > > > >> Or even better, we can recommend that the gateway automatically > >> check an ftp > >> archive for updates and apply them like Windows does with patches. > >> Vendors > >> could allow this feature to be turned off by the skilled user, but > by > >> default it should be on. > >> > >> RB > >> > >>> -----Original Message----- > >>> From: Richard Bennett [mailto:richard@bennett.com] > >>> Sent: Thursday, June 18, 2009 6:58 PM > >>> To: 'Erichsen, Kirk'; 'Livingood, Jason'; 'Stephen Farrell' > >>> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org > >>> Subject: Re: [homegate] Management of the Home Gateway > >>> > >>> The telco-deployed gateways are managed as CPE, using the TR stuff > >>> for > >>> firmware upgrades, but for the retail product about all we can do > is > >>> advise > >>> customers to periodically apply upgrades the hard way. In a > >>> perfect world, > >>> I > >>> suppose there would be a single web site where both customers and > >>> support > >>> people could go to see what the latest revision is for every > >>> gateway, but > >>> this isn't such a world. > >>> > >>> Another option is to declare it a BCP to have an easy "check for > >>> upgrade" > >>> button on the first page of the gateway's GUI or something similar. > >>> > >>> Richard Bennett > >>> > >>> -----Original Message----- > >>> From: Erichsen, Kirk [mailto:kirk.erichsen@twcable.com] > >>> Sent: Thursday, June 18, 2009 1:34 PM > >>> To: Livingood, Jason; Stephen Farrell > >>> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org > >>> Subject: Re: [homegate] Management of the Home Gateway > >>> > >>> > >>> Are we only interested in a generic software mechanism ("how") > >>> that be > >>> standardized, without really worrying about the management model > >>> (the > >>> "who")? > >>> > >>> > >>> > >>> P Go Green! Print this email only when necessary. Thank you for > >>> helping > >>> Time > >>> Warner Cable be environmentally responsible. > >>> > >>> > >>> -----Original Message----- > >>> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > >>> Sent: Thu 6/18/2009 1:56 PM > >>> To: Stephen Farrell; Erichsen, Kirk > >>> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org > >>> Subject: Re: [homegate] Management of the Home Gateway > >>> > >>> On 6/17/09 10:12 AM, "Stephen Farrell" > >>> wrote: > >>>> Erichsen, Kirk wrote: > >>>>> 1) Who manages the device? - I Think in most cases, 90% of the > >>>>> time it > >>> is > >>> the > >>>>> customer/end user. > >>>> > >>>> If so, then I think part of any spec here should include some sort > >>>> of requirement for software/firmware update for the device. While > >>>> there may not be a specific protocol for that that every vendor > >>>> would want to use, this activity (if it becomes a WG) might be > >>>> able to at least set requirements there. > >>> > >>> Firmware update methods were a topic of discussion when a few > >>> parties met > >>> to > >>> discuss the problem space in Philadelphia months ago. One of the > >>> issues > >>> is > >>> related to why web browsers and operating systems now perform > >>> automatic > >>> checks for updates. Today, this generally does not happen, though > >>> in some > >>> cases it can be prompted by the user savvy enough to visit the > local > >>> device > >>> management web page periodically. In any case, there are regular > >>> security > >>> fixes which are made available and without recommendations on how > >>> updates > >>> should occur (user intervention, automatically downloaded, > >>> automatically > >>> applied, etc.) many devices leave this to the users -- and > >>> probably 90%+ > >>> of > >>> the user base will never upgrade the firmware on the device. > >>> > >>> Jason > >>> > >>> > >>> > >>> This E-mail and any of its attachments may contain Time Warner > >>> Cable proprietary information, which is privileged, confidential, > >>> or subject to copyright belonging to Time Warner Cable. This E-mail > >>> is intended solely for the use of the individual or entity to which > >>> it is addressed. If you are not the intended recipient of this > >>> E-mail, you are hereby notified that any dissemination, > >>> distribution, copying, or action taken in relation to the contents > >>> of and attachments to this E-mail is strictly prohibited and may be > >>> unlawful. If you have received this E-mail in error, please notify > >>> the sender immediately and permanently delete the original and any > >>> copy of this E-mail and any printout. > >>> _______________________________________________ > >>> 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 > >> > >> > > > > _______________________________________________ > > homegate mailing list > > homegate@ietf.org > > https://www.ietf.org/mailman/listinfo/homegate > > >=20 > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate From Ray.Bellis@nominet.org.uk Tue Jun 23 08:20:10 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 4130F28C331; Tue, 23 Jun 2009 08:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.891 X-Spam-Level: X-Spam-Status: No, score=-5.891 tagged_above=-999 required=5 tests=[AWL=0.707, 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 PCgGjRfz6m9x; Tue, 23 Jun 2009 08:20:09 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id DC8E228C2FC; Tue, 23 Jun 2009 08:20:08 -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=pFoQRopo2xaBSZ1S9/0iaKO2Z3QgrqaPOkhDlXQ/+YWFlfGjBtr+5uSl fdy3+CGVYLKtmVRW1e9u56IzwchdxLAqSt5QiY24GS1EWSM1+5Z94qH+W TekmWTiK2/ngKQT; 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=1245770425; x=1277306425; 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]=20Management=20of=20the=20Home=20Gateway|Date:=20Tu e,=2023=20Jun=202009=2016:20:15=20+0100|Message-ID:=20|To:=20"Bob=20Carrick"=20|Cc:=20homegate@ietf.org,=0D=0A=09homegate-bounces@ ietf.org|MIME-Version:=201.0|In-Reply-To:=20 |References:=20=09<3B59A5CF-B8B2-4832-985F-182597439ECF@americafr ee.tv>=20; bh=RAt3v4sPt7gV/+7Pjeimfc9d72C6rZliBDo0KfCFypE=; b=SYg/6vKKGk501lwcdRcQXSonNLPMc8t8+LU/TPiEgSoy9Av5WZJX7dzR dE14DCgZUSC9fDoBcwIF6Lm7PN9l4uLRxkDyWA5IjTzgW4n9qQlVF61cF sBw5EtWrZmPdrXE; X-IronPort-AV: E=Sophos;i="4.42,276,1243810800"; d="scan'208";a="15064480" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 23 Jun 2009 16:20:22 +0100 In-Reply-To: References: <3B59A5CF-B8B2-4832-985F-182597439ECF@americafree.tv> To: "Bob Carrick" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 23 Jun 2009 16:20:15 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 23/06/2009 04:20:23 PM, Serialize complete at 23/06/2009 04:20:23 PM Content-Type: multipart/alternative; boundary="=_alternative 00544088802575DE_=" Cc: homegate-bounces@ietf.org, homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 23 Jun 2009 15:20:10 -0000 This is a multipart message in MIME format. --=_alternative 00544088802575DE_= Content-Type: text/plain; charset="US-ASCII" Personally, I would rather see this group concentrate on developing BCPs for ensuring *correct* implementation of current IETF *protocol* standards, and not working to develop new protocols, mechanisms, update systems, etc. Ray --=_alternative 00544088802575DE_= Content-Type: text/html; charset="US-ASCII" Personally, I would rather see this group concentrate on developing BCPs for ensuring *correct* implementation of current IETF *protocol* standards, and not working to develop new protocols, mechanisms, update systems, etc.

Ray

--=_alternative 00544088802575DE_=-- From kirk.erichsen@twcable.com Tue Jun 23 08:43:26 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 133E028C389 for ; Tue, 23 Jun 2009 08:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 SJRZqdhaTTqC for ; Tue, 23 Jun 2009 08:43:24 -0700 (PDT) Received: from pblpas02.twcable.com (pblpas02.twcable.com [204.235.121.150]) by core3.amsl.com (Postfix) with ESMTP id A02A03A6CFC for ; Tue, 23 Jun 2009 08:43:24 -0700 (PDT) X-SENDER-IP: 10.157.247.214 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,276,1243828800"; d="scan'208";a="424978081" Received: from unknown (HELO prvpmailconn4.corp.twcable.com) ([10.157.247.214]) by pblpas02.twcable.com with ESMTP; 23 Jun 2009 11:43:40 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn4.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Jun 2009 11:43:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 Jun 2009 11:43:39 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Management of the Home Gateway Thread-Index: Acn0Eem/81wY4WnLRaGdiNygFCXqCQABhFwh References: <3B59A5CF-B8B2-4832-985F-182597439ECF@americafree.tv> From: "Erichsen, Kirk" To: "Marshall Eubanks" , "Livingood, Jason" X-OriginalArrivalTime: 23 Jun 2009 15:43:40.0168 (UTC) FILETIME=[615E0080:01C9F419] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: homegate@ietf.org, Carolin.Latze@swisscom.com Subject: Re: [homegate] Management of the Home Gateway 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, 23 Jun 2009 15:43:26 -0000 All, =20 Keep in mind there is a difference between a general purpose OS and an embe= dded system when it comes to frequency of updates. Active ongoing developme= nt after the initial release is pretty rare and most of the time that code = comes from the reference design vendor, not the router manufacturers themse= lves. It's been my experience residential focused embedded systems do not (= and indeed for the price, should not) do not get a lot of software updates= after the fact. A typical number might be one or two updates a year and on= ly as a consequence of some major new feature addition and/or major bug fix= es. Collapsing minor bug fixes into a one or twice a year schedule for up t= o three years is common. The vendors usually move on to the next platform a= nd the focus is there for software development.=20 =20 Lets set expectations realistically around the profile of embedded systems,= where not a lot of development is likely to continue for these types of pr= oducts. =20 =20 -KE ________________________________ From: Marshall Eubanks [mailto:tme@americafree.tv] Sent: Tue 6/23/2009 8:49 AM To: Livingood, Jason Cc: Richard Bennett; Erichsen, Kirk; 'Stephen Farrell'; Carolin.Latze@swiss= com.com; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway On Jun 23, 2009, at 9:16 AM, Livingood, Jason wrote: > This is precisely what I was getting at. It seems bad hygiene to=20 > expect > that a user will update their software automatically - it just does=20 > not > happen in reality. The box runs, so why update it? As OS vendors=20 > have > learned, you have to automate this for the user. > The OS's I use do not do this by default, and I only know of one which=20 does. That is different from informing the user that upgrades are available or needed. There is to me another issue here. Most home users, in my experience,=20 know (or remember) nothing of the various GUI interfaces for their devices. A SOHO network might easily have a cable=20 modem, a wireless router, and a wireline switch from different=20 vendors, all with completely different GUI's for fairly similar=20 functions. Very few users will deal with this unless forced to. That=20 is one advantage an OS vendor has - the power to put a dialog box in=20 front of the user. Would it be in scope to describe some sort of ZeroConf type mechanism=20 for doing this ? My printer complains when it needs ink, why shouldn't=20 my router be able to complain when it needs an update ? Regards Marshall > So something along the lines of: > A software (firmware) update function must be present, which=20 > periodically > and without user intervention, checks for and downloads firmware=20 > updates. > Optionally, a software installation function may apply these > automatically-downloaded firmware updates on the device on either=20 > (1) an > immediate basis or (2) a pre-scheduled basis. All of the above=20 > settings > should be pre-configured and defaulted on/active by the device=20 > maker, and > users should have the ability to modify such settings. [We may also=20 > need to > provide some text about a security mechanism to verify that the=20 > firmware > updates is properly signed/trust-verified.] > > Jason > > > On 6/19/09 4:10 AM, "Richard Bennett" wrote: > >> Or even better, we can recommend that the gateway automatically=20 >> check an ftp >> archive for updates and apply them like Windows does with patches.=20 >> Vendors >> could allow this feature to be turned off by the skilled user, but by >> default it should be on. >> >> RB >> >>> -----Original Message----- >>> From: Richard Bennett [mailto:richard@bennett.com] >>> Sent: Thursday, June 18, 2009 6:58 PM >>> To: 'Erichsen, Kirk'; 'Livingood, Jason'; 'Stephen Farrell' >>> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >>> Subject: Re: [homegate] Management of the Home Gateway >>> >>> The telco-deployed gateways are managed as CPE, using the TR stuff=20 >>> for >>> firmware upgrades, but for the retail product about all we can do is >>> advise >>> customers to periodically apply upgrades the hard way. In a=20 >>> perfect world, >>> I >>> suppose there would be a single web site where both customers and=20 >>> support >>> people could go to see what the latest revision is for every=20 >>> gateway, but >>> this isn't such a world. >>> >>> Another option is to declare it a BCP to have an easy "check for=20 >>> upgrade" >>> button on the first page of the gateway's GUI or something similar. >>> >>> Richard Bennett >>> >>> -----Original Message----- >>> From: Erichsen, Kirk [mailto:kirk.erichsen@twcable.com] >>> Sent: Thursday, June 18, 2009 1:34 PM >>> To: Livingood, Jason; Stephen Farrell >>> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >>> Subject: Re: [homegate] Management of the Home Gateway >>> >>> >>> Are we only interested in a generic software mechanism ("how")=20 >>> that be >>> standardized, without really worrying about the management model=20 >>> (the >>> "who")? >>> >>> >>> >>> P Go Green! Print this email only when necessary. Thank you for=20 >>> helping >>> Time >>> Warner Cable be environmentally responsible. >>> >>> >>> -----Original Message----- >>> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] >>> Sent: Thu 6/18/2009 1:56 PM >>> To: Stephen Farrell; Erichsen, Kirk >>> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org >>> Subject: Re: [homegate] Management of the Home Gateway >>> >>> On 6/17/09 10:12 AM, "Stephen Farrell" =20 >>> wrote: >>>> Erichsen, Kirk wrote: >>>>> 1) Who manages the device? - I Think in most cases, 90% of the=20 >>>>> time it >>> is >>> the >>>>> customer/end user. >>>> >>>> If so, then I think part of any spec here should include some sort >>>> of requirement for software/firmware update for the device. While >>>> there may not be a specific protocol for that that every vendor >>>> would want to use, this activity (if it becomes a WG) might be >>>> able to at least set requirements there. >>> >>> Firmware update methods were a topic of discussion when a few=20 >>> parties met >>> to >>> discuss the problem space in Philadelphia months ago. One of the=20 >>> issues >>> is >>> related to why web browsers and operating systems now perform=20 >>> automatic >>> checks for updates. Today, this generally does not happen, though=20 >>> in some >>> cases it can be prompted by the user savvy enough to visit the local >>> device >>> management web page periodically. In any case, there are regular=20 >>> security >>> fixes which are made available and without recommendations on how=20 >>> updates >>> should occur (user intervention, automatically downloaded,=20 >>> automatically >>> applied, etc.) many devices leave this to the users -- and=20 >>> probably 90%+ >>> of >>> the user base will never upgrade the firmware on the device. >>> >>> Jason >>> >>> >>> >>> This E-mail and any of its attachments may contain Time Warner >>> Cable proprietary information, which is privileged, confidential, >>> or subject to copyright belonging to Time Warner Cable. This E-mail >>> is intended solely for the use of the individual or entity to which >>> it is addressed. If you are not the intended recipient of this >>> E-mail, you are hereby notified that any dissemination, >>> distribution, copying, or action taken in relation to the contents >>> of and attachments to this E-mail is strictly prohibited and may be >>> unlawful. If you have received this E-mail in error, please notify >>> the sender immediately and permanently delete the original and any >>> copy of this E-mail and any printout. >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From kirk.erichsen@twcable.com Tue Jun 23 08:54:22 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 6A0C628C38C for ; Tue, 23 Jun 2009 08:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 4p1cUqnCvrqo for ; Tue, 23 Jun 2009 08:54:20 -0700 (PDT) Received: from pblpas01.twcable.com (pblpas01.twcable.com [204.235.121.149]) by core3.amsl.com (Postfix) with ESMTP id 8A7D628C397 for ; Tue, 23 Jun 2009 08:53:39 -0700 (PDT) X-SENDER-IP: 10.157.247.211 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,276,1243828800"; d="scan'208";a="425867313" Received: from unknown (HELO prvpmailconn1.corp.twcable.com) ([10.157.247.211]) by pblpas01.twcable.com with ESMTP; 23 Jun 2009 11:53:55 -0400 Received: from PRVPVSMAIL10.corp.twcable.com ([10.157.194.199]) by prvpmailconn1.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Jun 2009 11:53:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 Jun 2009 11:53:54 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Management of the Home Gateway Thread-Index: Acn0Ef2SLt9QibVyTr+zzgxzRAzk2QAAHlUAAAHJG00= References: <3B59A5CF-B8B2-4832-985F-182597439ECF@americafree.tv> From: "Erichsen, Kirk" To: "Bob Carrick" , X-OriginalArrivalTime: 23 Jun 2009 15:53:54.0762 (UTC) FILETIME=[CFB19AA0:01C9F41A] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [homegate] Management of the Home Gateway 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, 23 Jun 2009 15:54:22 -0000 Cable has it's own method defined in the DOCSIS software download framework= . As mentioned before, this group has two rather nice, already complete spe= cs to work from. I'd suggest in the case of an embedded routing device with= a DSL CM, point to TR069 and for an embedded router with a cable modem, po= int into the CableLabs specs. We can do a requirements extract on both spec= s to come up with what might be a dramatically stripped down list.=20 ________________________________ From: homegate-bounces@ietf.org on behalf of Bob Carrick Sent: Tue 6/23/2009 9:01 AM To: homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway Just a quick chime in on this thread guys. There is a remote management standard, TR-069, for all broadband types (currently minus the Cable forums though, but is Wimax, DSL, Femto, IPTV, VoIP, Fiber and their respective forums, etc) that answers most if not all of these questions for you that have been brought up in this thread, or at least the vendors of those solutions do. With many TR-069 solutions you can do hands free provisioning (remote) and simple things such as scheduled remote upgrades via a simple unified interface for remote management of all those above mentioned device types. This allows firmware revs to be signed off on by you and rolled out across all the supported devices. This way bugs are introduced etc. You could also automatically roll your users back to your "supported" firmware if you know bugs are in newer versions (or older) that you don't want to support, etc. You can also provide that unified interface to your customer in a portal of types and let them upgrade or manage their own CPE. I could go on and try to touch on each point raised in the thread, but it is a long thread. Bob Carrick Director - Broadband Products Fine Point Technologies, Inc. 75 Broad Street, Suite 300 New York, NY 10004 email: bcarrick@finepoint.com phone: +1.212.962.7410 x62 fax: +1.212.962.7404 web: http://www.finepoint.com =20 > -----Original Message----- > From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On > Behalf Of Marshall Eubanks > Sent: Tuesday, June 23, 2009 10:49 AM > To: Livingood, Jason > Cc: homegate@ietf.org; Carolin.Latze@swisscom.com > Subject: Re: [homegate] Management of the Home Gateway > > > On Jun 23, 2009, at 9:16 AM, Livingood, Jason wrote: > > > This is precisely what I was getting at. It seems bad hygiene to > > expect > > that a user will update their software automatically - it just does > > not > > happen in reality. The box runs, so why update it? As OS vendors > > have > > learned, you have to automate this for the user. > > > > The OS's I use do not do this by default, and I only know of one which > does. That is different from > informing the user that upgrades are available or needed. > > There is to me another issue here. Most home users, in my experience, > know (or remember) nothing of the various GUI > interfaces for their devices. A SOHO network might easily have a cable > modem, a wireless router, and a wireline switch from different > vendors, all with completely different GUI's for fairly similar > functions. Very few users will deal with this unless forced to. That > is one advantage an OS vendor has - the power to put a dialog box in > front of the user. > > Would it be in scope to describe some sort of ZeroConf type mechanism > for doing this ? My printer complains when it needs ink, why shouldn't > my router be able to complain when it needs an update ? > > Regards > Marshall > > > > So something along the lines of: > > A software (firmware) update function must be present, which > > periodically > > and without user intervention, checks for and downloads firmware > > updates. > > Optionally, a software installation function may apply these > > automatically-downloaded firmware updates on the device on either > > (1) an > > immediate basis or (2) a pre-scheduled basis. All of the above > > settings > > should be pre-configured and defaulted on/active by the device > > maker, and > > users should have the ability to modify such settings. [We may also > > need to > > provide some text about a security mechanism to verify that the > > firmware > > updates is properly signed/trust-verified.] > > > > Jason > > > > > > On 6/19/09 4:10 AM, "Richard Bennett" wrote: > > > >> Or even better, we can recommend that the gateway automatically > >> check an ftp > >> archive for updates and apply them like Windows does with patches. > >> Vendors > >> could allow this feature to be turned off by the skilled user, but > by > >> default it should be on. > >> > >> RB > >> > >>> -----Original Message----- > >>> From: Richard Bennett [mailto:richard@bennett.com] > >>> Sent: Thursday, June 18, 2009 6:58 PM > >>> To: 'Erichsen, Kirk'; 'Livingood, Jason'; 'Stephen Farrell' > >>> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org > >>> Subject: Re: [homegate] Management of the Home Gateway > >>> > >>> The telco-deployed gateways are managed as CPE, using the TR stuff > >>> for > >>> firmware upgrades, but for the retail product about all we can do > is > >>> advise > >>> customers to periodically apply upgrades the hard way. In a > >>> perfect world, > >>> I > >>> suppose there would be a single web site where both customers and > >>> support > >>> people could go to see what the latest revision is for every > >>> gateway, but > >>> this isn't such a world. > >>> > >>> Another option is to declare it a BCP to have an easy "check for > >>> upgrade" > >>> button on the first page of the gateway's GUI or something similar. > >>> > >>> Richard Bennett > >>> > >>> -----Original Message----- > >>> From: Erichsen, Kirk [mailto:kirk.erichsen@twcable.com] > >>> Sent: Thursday, June 18, 2009 1:34 PM > >>> To: Livingood, Jason; Stephen Farrell > >>> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org > >>> Subject: Re: [homegate] Management of the Home Gateway > >>> > >>> > >>> Are we only interested in a generic software mechanism ("how") > >>> that be > >>> standardized, without really worrying about the management model > >>> (the > >>> "who")? > >>> > >>> > >>> > >>> P Go Green! Print this email only when necessary. Thank you for > >>> helping > >>> Time > >>> Warner Cable be environmentally responsible. > >>> > >>> > >>> -----Original Message----- > >>> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > >>> Sent: Thu 6/18/2009 1:56 PM > >>> To: Stephen Farrell; Erichsen, Kirk > >>> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org > >>> Subject: Re: [homegate] Management of the Home Gateway > >>> > >>> On 6/17/09 10:12 AM, "Stephen Farrell" > >>> wrote: > >>>> Erichsen, Kirk wrote: > >>>>> 1) Who manages the device? - I Think in most cases, 90% of the > >>>>> time it > >>> is > >>> the > >>>>> customer/end user. > >>>> > >>>> If so, then I think part of any spec here should include some sort > >>>> of requirement for software/firmware update for the device. While > >>>> there may not be a specific protocol for that that every vendor > >>>> would want to use, this activity (if it becomes a WG) might be > >>>> able to at least set requirements there. > >>> > >>> Firmware update methods were a topic of discussion when a few > >>> parties met > >>> to > >>> discuss the problem space in Philadelphia months ago. One of the > >>> issues > >>> is > >>> related to why web browsers and operating systems now perform > >>> automatic > >>> checks for updates. Today, this generally does not happen, though > >>> in some > >>> cases it can be prompted by the user savvy enough to visit the > local > >>> device > >>> management web page periodically. In any case, there are regular > >>> security > >>> fixes which are made available and without recommendations on how > >>> updates > >>> should occur (user intervention, automatically downloaded, > >>> automatically > >>> applied, etc.) many devices leave this to the users -- and > >>> probably 90%+ > >>> of > >>> the user base will never upgrade the firmware on the device. > >>> > >>> Jason > >>> > >>> > >>> > >>> This E-mail and any of its attachments may contain Time Warner > >>> Cable proprietary information, which is privileged, confidential, > >>> or subject to copyright belonging to Time Warner Cable. This E-mail > >>> is intended solely for the use of the individual or entity to which > >>> it is addressed. If you are not the intended recipient of this > >>> E-mail, you are hereby notified that any dissemination, > >>> distribution, copying, or action taken in relation to the contents > >>> of and attachments to this E-mail is strictly prohibited and may be > >>> unlawful. If you have received this E-mail in error, please notify > >>> the sender immediately and permanently delete the original and any > >>> copy of this E-mail and any printout. > >>> _______________________________________________ > >>> 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 > >> > >> > > > > _______________________________________________ > > 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 _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From Dirk.VandePoel@thomson.net Tue Jun 23 23:45:12 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 0426E28C45E for ; Tue, 23 Jun 2009 23:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 gnnuvvZngbrW for ; Tue, 23 Jun 2009 23:45:10 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with SMTP id 91A2928C45D for ; Tue, 23 Jun 2009 23:45:09 -0700 (PDT) Received: from source ([141.11.234.72]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSkHLbnyCzzQx7SXF7foxRj5WSbwCVWWp@postini.com; Tue, 23 Jun 2009 23:45:27 PDT Received: from boulvss3.eu.thmulti.com (unknown [141.11.234.56]) by dmzraw4.extranet.thmulti.com (Postfix) with ESMTP id A5FCD4AF7 for ; Wed, 24 Jun 2009 06:45:00 +0000 (GMT) Received: from boulsmailfe02.eu.thmulti.com (boulasmtp.eu.thmulti.com [141.11.196.14]) by boulvss3.eu.thmulti.com (Postfix) with ESMTP id EB6A111D1 for ; Wed, 24 Jun 2009 06:45:39 +0000 (GMT) Received: from edgmsmail02.eu.thmulti.com ([141.11.248.31]) by boulsmailfe02.eu.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jun 2009 08:45:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jun 2009 08:44:58 +0200 Message-ID: <1AD100E707F1F34290BBFB0464754A24953950@edgmsmail02.eu.thmulti.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Management of the Home Gateway Thread-Index: Acn0Ef2SLt9QibVyTr+zzgxzRAzk2QAAHlUAAAHJG00AHs1BsA== References: <3B59A5CF-B8B2-4832-985F-182597439ECF@americafree.tv> From: "Van de Poel Dirk" To: X-OriginalArrivalTime: 24 Jun 2009 06:45:00.0743 (UTC) FILETIME=[4BE6DD70:01C9F497] Subject: Re: [homegate] Management of the Home Gateway 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, 24 Jun 2009 06:45:12 -0000 Gentlemen, What is the scope of HomeGate? >From the discussion around this topic I get the impression the scope would only be covering retail devices that don't embed DSL, Cable or other access technology modems? >From a DSL home gateway perspective we so see a significant number of deployments where the service provider managed home gateway is combined with external modems/NTs. Also in this case the home gateway is key is triple play service delivery (multicast/QoS/VoIP) and is partly managed by the operator (network settings, QoS, VoIP...) using a remote management protocol and partly by the end-user (NAT portmaps...) using a device embedded GUI. Aspects like remote firmware upgrade are today covered in BBF TR-69 and CableLabs specs.=20 Does HomeGate intend to define requirements beyond the existing standards for operator managed gateways (with or without embedded modem)? Does it intend to only define firmware upgrade requirements for retail home routers? For other aspects such as multicast, Jumbo frames, DNSSEC would HomeGate define requirements for service provider managed gateways or only retail home routers? Thanks, Dirk -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behalf Of Erichsen, Kirk Sent: dinsdag 23 juni 2009 17:54 To: Bob Carrick; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway Cable has it's own method defined in the DOCSIS software download framework. As mentioned before, this group has two rather nice, already complete specs to work from. I'd suggest in the case of an embedded routing device with a DSL CM, point to TR069 and for an embedded router with a cable modem, point into the CableLabs specs. We can do a requirements extract on both specs to come up with what might be a dramatically stripped down list.=20 ________________________________ From: homegate-bounces@ietf.org on behalf of Bob Carrick Sent: Tue 6/23/2009 9:01 AM To: homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway Just a quick chime in on this thread guys. There is a remote management standard, TR-069, for all broadband types (currently minus the Cable forums though, but is Wimax, DSL, Femto, IPTV, VoIP, Fiber and their respective forums, etc) that answers most if not all of these questions for you that have been brought up in this thread, or at least the vendors of those solutions do. With many TR-069 solutions you can do hands free provisioning (remote) and simple things such as scheduled remote upgrades via a simple unified interface for remote management of all those above mentioned device types. This allows firmware revs to be signed off on by you and rolled out across all the supported devices. This way bugs are introduced etc. You could also automatically roll your users back to your "supported" firmware if you know bugs are in newer versions (or older) that you don't want to support, etc. You can also provide that unified interface to your customer in a portal of types and let them upgrade or manage their own CPE. I could go on and try to touch on each point raised in the thread, but it is a long thread. Bob Carrick Director - Broadband Products Fine Point Technologies, Inc. 75 Broad Street, Suite 300 New York, NY 10004 email: bcarrick@finepoint.com phone: +1.212.962.7410 x62 fax: +1.212.962.7404 web: http://www.finepoint.com =20 > -----Original Message----- > From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On > Behalf Of Marshall Eubanks > Sent: Tuesday, June 23, 2009 10:49 AM > To: Livingood, Jason > Cc: homegate@ietf.org; Carolin.Latze@swisscom.com > Subject: Re: [homegate] Management of the Home Gateway > > > On Jun 23, 2009, at 9:16 AM, Livingood, Jason wrote: > > > This is precisely what I was getting at. It seems bad hygiene to > > expect > > that a user will update their software automatically - it just does > > not > > happen in reality. The box runs, so why update it? As OS vendors > > have > > learned, you have to automate this for the user. > > > > The OS's I use do not do this by default, and I only know of one which > does. That is different from > informing the user that upgrades are available or needed. > > There is to me another issue here. Most home users, in my experience, > know (or remember) nothing of the various GUI > interfaces for their devices. A SOHO network might easily have a cable > modem, a wireless router, and a wireline switch from different > vendors, all with completely different GUI's for fairly similar > functions. Very few users will deal with this unless forced to. That > is one advantage an OS vendor has - the power to put a dialog box in > front of the user. > > Would it be in scope to describe some sort of ZeroConf type mechanism > for doing this ? My printer complains when it needs ink, why shouldn't > my router be able to complain when it needs an update ? > > Regards > Marshall > > > > So something along the lines of: > > A software (firmware) update function must be present, which > > periodically > > and without user intervention, checks for and downloads firmware > > updates. > > Optionally, a software installation function may apply these > > automatically-downloaded firmware updates on the device on either > > (1) an > > immediate basis or (2) a pre-scheduled basis. All of the above > > settings > > should be pre-configured and defaulted on/active by the device > > maker, and > > users should have the ability to modify such settings. [We may also > > need to > > provide some text about a security mechanism to verify that the > > firmware > > updates is properly signed/trust-verified.] > > > > Jason > > > > > > On 6/19/09 4:10 AM, "Richard Bennett" wrote: > > > >> Or even better, we can recommend that the gateway automatically > >> check an ftp > >> archive for updates and apply them like Windows does with patches. > >> Vendors > >> could allow this feature to be turned off by the skilled user, but > by > >> default it should be on. > >> > >> RB > >> > >>> -----Original Message----- > >>> From: Richard Bennett [mailto:richard@bennett.com] > >>> Sent: Thursday, June 18, 2009 6:58 PM > >>> To: 'Erichsen, Kirk'; 'Livingood, Jason'; 'Stephen Farrell' > >>> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org > >>> Subject: Re: [homegate] Management of the Home Gateway > >>> > >>> The telco-deployed gateways are managed as CPE, using the TR stuff > >>> for > >>> firmware upgrades, but for the retail product about all we can do > is > >>> advise > >>> customers to periodically apply upgrades the hard way. In a > >>> perfect world, > >>> I > >>> suppose there would be a single web site where both customers and > >>> support > >>> people could go to see what the latest revision is for every > >>> gateway, but > >>> this isn't such a world. > >>> > >>> Another option is to declare it a BCP to have an easy "check for > >>> upgrade" > >>> button on the first page of the gateway's GUI or something similar. > >>> > >>> Richard Bennett > >>> > >>> -----Original Message----- > >>> From: Erichsen, Kirk [mailto:kirk.erichsen@twcable.com] > >>> Sent: Thursday, June 18, 2009 1:34 PM > >>> To: Livingood, Jason; Stephen Farrell > >>> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org > >>> Subject: Re: [homegate] Management of the Home Gateway > >>> > >>> > >>> Are we only interested in a generic software mechanism ("how") > >>> that be > >>> standardized, without really worrying about the management model > >>> (the > >>> "who")? > >>> > >>> > >>> > >>> P Go Green! Print this email only when necessary. Thank you for > >>> helping > >>> Time > >>> Warner Cable be environmentally responsible. > >>> > >>> > >>> -----Original Message----- > >>> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > >>> Sent: Thu 6/18/2009 1:56 PM > >>> To: Stephen Farrell; Erichsen, Kirk > >>> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org > >>> Subject: Re: [homegate] Management of the Home Gateway > >>> > >>> On 6/17/09 10:12 AM, "Stephen Farrell" > >>> wrote: > >>>> Erichsen, Kirk wrote: > >>>>> 1) Who manages the device? - I Think in most cases, 90% of the > >>>>> time it > >>> is > >>> the > >>>>> customer/end user. > >>>> > >>>> If so, then I think part of any spec here should include some sort > >>>> of requirement for software/firmware update for the device. While > >>>> there may not be a specific protocol for that that every vendor > >>>> would want to use, this activity (if it becomes a WG) might be > >>>> able to at least set requirements there. > >>> > >>> Firmware update methods were a topic of discussion when a few > >>> parties met > >>> to > >>> discuss the problem space in Philadelphia months ago. One of the > >>> issues > >>> is > >>> related to why web browsers and operating systems now perform > >>> automatic > >>> checks for updates. Today, this generally does not happen, though > >>> in some > >>> cases it can be prompted by the user savvy enough to visit the > local > >>> device > >>> management web page periodically. In any case, there are regular > >>> security > >>> fixes which are made available and without recommendations on how > >>> updates > >>> should occur (user intervention, automatically downloaded, > >>> automatically > >>> applied, etc.) many devices leave this to the users -- and > >>> probably 90%+ > >>> of > >>> the user base will never upgrade the firmware on the device. > >>> > >>> Jason > >>> > >>> > >>> > >>> This E-mail and any of its attachments may contain Time Warner > >>> Cable proprietary information, which is privileged, confidential, > >>> or subject to copyright belonging to Time Warner Cable. This E-mail > >>> is intended solely for the use of the individual or entity to which > >>> it is addressed. If you are not the intended recipient of this > >>> E-mail, you are hereby notified that any dissemination, > >>> distribution, copying, or action taken in relation to the contents > >>> of and attachments to this E-mail is strictly prohibited and may be > >>> unlawful. If you have received this E-mail in error, please notify > >>> the sender immediately and permanently delete the original and any > >>> copy of this E-mail and any printout. > >>> _______________________________________________ > >>> 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 > >> > >> > > > > _______________________________________________ > > 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 _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate From erik.taraldsen@telenor.com Wed Jun 24 01:52:59 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 A2D7728C3B1 for ; Wed, 24 Jun 2009 01:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1] 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 eobhmUolwnVH for ; Wed, 24 Jun 2009 01:52:58 -0700 (PDT) Received: from hermod.telenor.net (virus-out-st.online.no [193.212.240.200]) by core3.amsl.com (Postfix) with ESMTP id 834E928C438 for ; Wed, 24 Jun 2009 01:52:57 -0700 (PDT) Received: from tns-fbu-22-250.corp.telenor.no ([134.47.162.19] [134.47.162.19]) by hermod.telenor.net with ESMTPS id BT-MMP-1347021 for homegate@ietf.org; Wed, 24 Jun 2009 10:53:11 +0200 Received: from TNS-FBU-2E-016.corp.telenor.no ([134.47.163.219]) by tns-fbu-22-250.corp.telenor.no ([134.47.162.19]) with mapi; Wed, 24 Jun 2009 10:53:10 +0200 From: To: Date: Wed, 24 Jun 2009 10:53:07 +0200 Thread-Topic: [homegate] Management of the Home Gateway Thread-Index: Acn0BfD7zKCbc34qTniWido0vDTaMgAoX4Gg Message-ID: <6A141C5EC2D26E47B3128814D5F695921183CDF51C@TNS-FBU-2E-016.corp.telenor.no> References: In-Reply-To: Accept-Language: nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nb-NO Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homegate] Management of the Home Gateway 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, 24 Jun 2009 08:52:59 -0000 > > A software (firmware) update function must be present, which =20 > > periodically > > and without user intervention, checks for and downloads firmware =20 > > updates. >=20 > I have to very strongly object to the above. > > Your assumption is that upgrading is necessary, even if the user =20 > doesn't want to. That is a flawed assumption unless you're speaking =20 > from personal involvement in creating firmware that is so bad that =20 > this is true. Speeking as a service provider I think periodic updates is a good thing.=20 Most end users will not touch their network equpment unless forced to do so= . A couple of years back when migrating from adsl to adsl2+ we sendt a mail=20 (the kind with a stamp on, not email) to 10.000 customers which had non=20 adsl2+ equipment. All they had to do was to respond by sms, phone, mail an= d they would recive a new adsl2+ device free of charge and double speed. 17 responded.=20 My suggestion is that per default the device should update itself, but with a "opt out" choice for the paranoid, and a experimental for the curios. NB: These are comments for the service provider devices, retail I do not ha= ve an opinion for. -Erik Taraldsen Telenor From iljitsch@muada.com Wed Jun 24 02:26:31 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 4E3D33A6A71 for ; Wed, 24 Jun 2009 02:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 jq+ZPkLA4fnF for ; Wed, 24 Jun 2009 02:26:30 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id BC4E03A6F5D for ; Wed, 24 Jun 2009 02:26:29 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n5O9OgUh050105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Jun 2009 11:24:49 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: In-Reply-To: <6A141C5EC2D26E47B3128814D5F695921183CDF51C@TNS-FBU-2E-016.corp.telenor.no> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 24 Jun 2009 11:24:16 +0200 References: <6A141C5EC2D26E47B3128814D5F695921183CDF51C@TNS-FBU-2E-016.corp.telenor.no> X-Mailer: Apple Mail (2.935.3) Cc: homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 24 Jun 2009 09:26:31 -0000 On 24 jun 2009, at 10:53, wrote: > Speeking as a service provider I think periodic updates is a good > thing. I do understand that if you depend on the user to initiate any action, very little will happen. Still not sure why this is important enough to incur the risks. Are there often CPE updates that are critical? Doesn't seem that way to me. > NB: These are comments for the service provider devices, retail I do > not have > an opinion for. Which brings up the question: what exactly are we trying to solve on this list? If it's devices delivered to users as part of the service, then obviously any and all issues can be negotiated between the vendor and the service provider so there isn't much need to discuss them in the IETF. (Although it would probably be helpful to come up with a more standardized way to interact on the LAN side.) The case where the CPE is obtained by the user separately from the service is much more complex and more inline with the IETF's mission and I don't think it's even possible to come up with a working scenario for pushing out updates there. From richard@bennett.com Wed Jun 24 03:16: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 4EA5C3A6A3D for ; Wed, 24 Jun 2009 03:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 EFZq2domYuZG for ; Wed, 24 Jun 2009 03:16:52 -0700 (PDT) Received: from outbound-mail-37.bluehost.com (outbound-mail-37.bluehost.com [69.89.20.191]) by core3.amsl.com (Postfix) with SMTP id 6912D3A6B16 for ; Wed, 24 Jun 2009 03:16:52 -0700 (PDT) Received: (qmail 8299 invoked by uid 0); 24 Jun 2009 10:16:56 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy2.bluehost.com with SMTP; 24 Jun 2009 10:16:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-MimeOLE:Thread-Index:X-Identified-User; b=Hz9T66jUOW8QUVpVLZ/oqOEw1TtKEJQaWn3x+F40mXiFhDIrjRd7HRJfvqTan3N+oV7r9tLlmSEOqYOsoGk6ktLMjKIK0mGGeAdV2JuBs2y5GBHAGfqnhFz8t6LCyRrX; Received: from c-24-5-230-26.hsd1.ca.comcast.net ([24.5.230.26] helo=Honkin) by host46.hostmonster.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MJPXE-0000GY-20; Wed, 24 Jun 2009 04:16:56 -0600 From: "Richard Bennett" To: "'Iljitsch van Beijnum'" , References: <6A141C5EC2D26E47B3128814D5F695921183CDF51C@TNS-FBU-2E-016.corp.telenor.no> In-Reply-To: Date: Wed, 24 Jun 2009 03:16:25 -0700 Organization: ITIF Message-ID: <40046F9C76174ADBA41E16A87121DE2D@Honkin> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Thread-Index: Acn0recR5kFl/UzkRwCmbEjPArQSNQABo52Q X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 24.5.230.26 authed with richard+bennett.com} Cc: homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: richard@bennett.com List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 10:16:53 -0000 In my experience, code often has bugs in it, sometimes critical ones, and they need to be patched. Perhaps a larger issue is that IETF protocols tend to evolve, so it's good for devices to catch up with the current standards. This is all practical nuts and bolts stuff, not advanced networking theory and dissertation material. Richard Bennett -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] Sent: Wednesday, June 24, 2009 2:24 AM To: erik.taraldsen@telenor.com Cc: homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway On 24 jun 2009, at 10:53, wrote: > Speeking as a service provider I think periodic updates is a good > thing. I do understand that if you depend on the user to initiate any action, very little will happen. Still not sure why this is important enough to incur the risks. Are there often CPE updates that are critical? Doesn't seem that way to me. > NB: These are comments for the service provider devices, retail I do > not have > an opinion for. Which brings up the question: what exactly are we trying to solve on this list? If it's devices delivered to users as part of the service, then obviously any and all issues can be negotiated between the vendor and the service provider so there isn't much need to discuss them in the IETF. (Although it would probably be helpful to come up with a more standardized way to interact on the LAN side.) The case where the CPE is obtained by the user separately from the service is much more complex and more inline with the IETF's mission and I don't think it's even possible to come up with a working scenario for pushing out updates there. _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate From richard@bennett.com Wed Jun 24 03:22:54 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 E98D03A6F66 for ; Wed, 24 Jun 2009 03:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 X7DzLL1l5-2S for ; Wed, 24 Jun 2009 03:22:53 -0700 (PDT) Received: from outbound-mail-37.bluehost.com (outbound-mail-37.bluehost.com [69.89.20.191]) by core3.amsl.com (Postfix) with SMTP id 375853A6B57 for ; Wed, 24 Jun 2009 03:22:53 -0700 (PDT) Received: (qmail 17835 invoked by uid 0); 24 Jun 2009 10:23:05 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy2.bluehost.com with SMTP; 24 Jun 2009 10:23:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:Reply-To:From:To:References:In-Reply-To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-MimeOLE:Thread-Index:X-Identified-User; b=F0JWwIoLN3wXiLcT3AG3SfvYZm9FPpyLEjFzdKval/CA1RMJOaW3h4mW2EMm1soBxraSlE+SDg/7P/2UuaZJSMEMD4JMyv+yvC7gmEBCKBl4IaV3xcT5CCuReV0DLeWx; Received: from c-24-5-230-26.hsd1.ca.comcast.net ([24.5.230.26] helo=Honkin) by host46.hostmonster.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MJPdB-00030V-Ej; Wed, 24 Jun 2009 04:23:05 -0600 From: "Richard Bennett" To: "'Van de Poel Dirk'" , References: <3B59A5CF-B8B2-4832-985F-182597439ECF@americafree.tv> <1AD100E707F1F34290BBFB0464754A24953950@edgmsmail02.eu.thmulti.com> In-Reply-To: <1AD100E707F1F34290BBFB0464754A24953950@edgmsmail02.eu.thmulti.com> Date: Wed, 24 Jun 2009 03:22:35 -0700 Organization: ITIF Message-ID: <7954B1FEFF74473AA3ED89BF33BE2659@Honkin> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Thread-Index: Acn0Ef2SLt9QibVyTr+zzgxzRAzk2QAAHlUAAAHJG00AHs1BsAAIAeoQ X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 24.5.230.26 authed with richard+bennett.com} Subject: Re: [homegate] Management of the Home Gateway X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: richard@bennett.com List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 10:22:55 -0000 I don't know that the scope has been defined yet, actually. We're just having a discussion around what the major issues with home gateways and the stability/functionality of IP networks might be. It seems that there's a desire to specify some BCPs more than anything, not invent new protocols. I don't see any desire to limit the scope to CPE, the retail stuff has perhaps greater needs since it's not tended by TR69 and has interoperability issues of its own. I think of HOMEGATE as a supplement to TR69 and DLNA, not a replacement (except where the other guys screwed up.) Richard Bennett -----Original Message----- From: Van de Poel Dirk [mailto:Dirk.VandePoel@thomson.net] Sent: Tuesday, June 23, 2009 11:45 PM To: homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway Gentlemen, What is the scope of HomeGate? >From the discussion around this topic I get the impression the scope would only be covering retail devices that don't embed DSL, Cable or other access technology modems? >From a DSL home gateway perspective we so see a significant number of deployments where the service provider managed home gateway is combined with external modems/NTs. Also in this case the home gateway is key is triple play service delivery (multicast/QoS/VoIP) and is partly managed by the operator (network settings, QoS, VoIP...) using a remote management protocol and partly by the end-user (NAT portmaps...) using a device embedded GUI. Aspects like remote firmware upgrade are today covered in BBF TR-69 and CableLabs specs. Does HomeGate intend to define requirements beyond the existing standards for operator managed gateways (with or without embedded modem)? Does it intend to only define firmware upgrade requirements for retail home routers? For other aspects such as multicast, Jumbo frames, DNSSEC would HomeGate define requirements for service provider managed gateways or only retail home routers? Thanks, Dirk -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behalf Of Erichsen, Kirk Sent: dinsdag 23 juni 2009 17:54 To: Bob Carrick; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway Cable has it's own method defined in the DOCSIS software download framework. As mentioned before, this group has two rather nice, already complete specs to work from. I'd suggest in the case of an embedded routing device with a DSL CM, point to TR069 and for an embedded router with a cable modem, point into the CableLabs specs. We can do a requirements extract on both specs to come up with what might be a dramatically stripped down list. ________________________________ From: homegate-bounces@ietf.org on behalf of Bob Carrick Sent: Tue 6/23/2009 9:01 AM To: homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway Just a quick chime in on this thread guys. There is a remote management standard, TR-069, for all broadband types (currently minus the Cable forums though, but is Wimax, DSL, Femto, IPTV, VoIP, Fiber and their respective forums, etc) that answers most if not all of these questions for you that have been brought up in this thread, or at least the vendors of those solutions do. With many TR-069 solutions you can do hands free provisioning (remote) and simple things such as scheduled remote upgrades via a simple unified interface for remote management of all those above mentioned device types. This allows firmware revs to be signed off on by you and rolled out across all the supported devices. This way bugs are introduced etc. You could also automatically roll your users back to your "supported" firmware if you know bugs are in newer versions (or older) that you don't want to support, etc. You can also provide that unified interface to your customer in a portal of types and let them upgrade or manage their own CPE. I could go on and try to touch on each point raised in the thread, but it is a long thread. Bob Carrick Director - Broadband Products Fine Point Technologies, Inc. 75 Broad Street, Suite 300 New York, NY 10004 email: bcarrick@finepoint.com phone: +1.212.962.7410 x62 fax: +1.212.962.7404 web: http://www.finepoint.com > -----Original Message----- > From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On > Behalf Of Marshall Eubanks > Sent: Tuesday, June 23, 2009 10:49 AM > To: Livingood, Jason > Cc: homegate@ietf.org; Carolin.Latze@swisscom.com > Subject: Re: [homegate] Management of the Home Gateway > > > On Jun 23, 2009, at 9:16 AM, Livingood, Jason wrote: > > > This is precisely what I was getting at. It seems bad hygiene to > > expect > > that a user will update their software automatically - it just does > > not > > happen in reality. The box runs, so why update it? As OS vendors > > have > > learned, you have to automate this for the user. > > > > The OS's I use do not do this by default, and I only know of one which > does. That is different from > informing the user that upgrades are available or needed. > > There is to me another issue here. Most home users, in my experience, > know (or remember) nothing of the various GUI > interfaces for their devices. A SOHO network might easily have a cable > modem, a wireless router, and a wireline switch from different > vendors, all with completely different GUI's for fairly similar > functions. Very few users will deal with this unless forced to. That > is one advantage an OS vendor has - the power to put a dialog box in > front of the user. > > Would it be in scope to describe some sort of ZeroConf type mechanism > for doing this ? My printer complains when it needs ink, why shouldn't > my router be able to complain when it needs an update ? > > Regards > Marshall > > > > So something along the lines of: > > A software (firmware) update function must be present, which > > periodically > > and without user intervention, checks for and downloads firmware > > updates. > > Optionally, a software installation function may apply these > > automatically-downloaded firmware updates on the device on either > > (1) an > > immediate basis or (2) a pre-scheduled basis. All of the above > > settings > > should be pre-configured and defaulted on/active by the device > > maker, and > > users should have the ability to modify such settings. [We may also > > need to > > provide some text about a security mechanism to verify that the > > firmware > > updates is properly signed/trust-verified.] > > > > Jason > > > > > > On 6/19/09 4:10 AM, "Richard Bennett" wrote: > > > >> Or even better, we can recommend that the gateway automatically > >> check an ftp > >> archive for updates and apply them like Windows does with patches. > >> Vendors > >> could allow this feature to be turned off by the skilled user, but > by > >> default it should be on. > >> > >> RB > >> > >>> -----Original Message----- > >>> From: Richard Bennett [mailto:richard@bennett.com] > >>> Sent: Thursday, June 18, 2009 6:58 PM > >>> To: 'Erichsen, Kirk'; 'Livingood, Jason'; 'Stephen Farrell' > >>> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org > >>> Subject: Re: [homegate] Management of the Home Gateway > >>> > >>> The telco-deployed gateways are managed as CPE, using the TR stuff > >>> for > >>> firmware upgrades, but for the retail product about all we can do > is > >>> advise > >>> customers to periodically apply upgrades the hard way. In a > >>> perfect world, > >>> I > >>> suppose there would be a single web site where both customers and > >>> support > >>> people could go to see what the latest revision is for every > >>> gateway, but > >>> this isn't such a world. > >>> > >>> Another option is to declare it a BCP to have an easy "check for > >>> upgrade" > >>> button on the first page of the gateway's GUI or something similar. > >>> > >>> Richard Bennett > >>> > >>> -----Original Message----- > >>> From: Erichsen, Kirk [mailto:kirk.erichsen@twcable.com] > >>> Sent: Thursday, June 18, 2009 1:34 PM > >>> To: Livingood, Jason; Stephen Farrell > >>> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org > >>> Subject: Re: [homegate] Management of the Home Gateway > >>> > >>> > >>> Are we only interested in a generic software mechanism ("how") > >>> that be > >>> standardized, without really worrying about the management model > >>> (the > >>> "who")? > >>> > >>> > >>> > >>> P Go Green! Print this email only when necessary. Thank you for > >>> helping > >>> Time > >>> Warner Cable be environmentally responsible. > >>> > >>> > >>> -----Original Message----- > >>> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > >>> Sent: Thu 6/18/2009 1:56 PM > >>> To: Stephen Farrell; Erichsen, Kirk > >>> Cc: Carolin.Latze@swisscom.com; homegate@ietf.org > >>> Subject: Re: [homegate] Management of the Home Gateway > >>> > >>> On 6/17/09 10:12 AM, "Stephen Farrell" > >>> wrote: > >>>> Erichsen, Kirk wrote: > >>>>> 1) Who manages the device? - I Think in most cases, 90% of the > >>>>> time it > >>> is > >>> the > >>>>> customer/end user. > >>>> > >>>> If so, then I think part of any spec here should include some sort > >>>> of requirement for software/firmware update for the device. While > >>>> there may not be a specific protocol for that that every vendor > >>>> would want to use, this activity (if it becomes a WG) might be > >>>> able to at least set requirements there. > >>> > >>> Firmware update methods were a topic of discussion when a few > >>> parties met > >>> to > >>> discuss the problem space in Philadelphia months ago. One of the > >>> issues > >>> is > >>> related to why web browsers and operating systems now perform > >>> automatic > >>> checks for updates. Today, this generally does not happen, though > >>> in some > >>> cases it can be prompted by the user savvy enough to visit the > local > >>> device > >>> management web page periodically. In any case, there are regular > >>> security > >>> fixes which are made available and without recommendations on how > >>> updates > >>> should occur (user intervention, automatically downloaded, > >>> automatically > >>> applied, etc.) many devices leave this to the users -- and > >>> probably 90%+ > >>> of > >>> the user base will never upgrade the firmware on the device. > >>> > >>> Jason > >>> > >>> > >>> > >>> This E-mail and any of its attachments may contain Time Warner > >>> Cable proprietary information, which is privileged, confidential, > >>> or subject to copyright belonging to Time Warner Cable. This E-mail > >>> is intended solely for the use of the individual or entity to which > >>> it is addressed. If you are not the intended recipient of this > >>> E-mail, you are hereby notified that any dissemination, > >>> distribution, copying, or action taken in relation to the contents > >>> of and attachments to this E-mail is strictly prohibited and may be > >>> unlawful. If you have received this E-mail in error, please notify > >>> the sender immediately and permanently delete the original and any > >>> copy of this E-mail and any printout. > >>> _______________________________________________ > >>> 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 > >> > >> > > > > _______________________________________________ > > 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 _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ 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 Carolin.Latze@swisscom.com Wed Jun 24 09:14:45 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 DFF7D28C4AB for ; Wed, 24 Jun 2009 09:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 CeJAix9UMZYQ for ; Wed, 24 Jun 2009 09:14:45 -0700 (PDT) Received: from mail.swisscom.com (outmail21.swisscom.com [138.190.32.11]) by core3.amsl.com (Postfix) with ESMTP id BCA8528C4A9 for ; Wed, 24 Jun 2009 09:14:43 -0700 (PDT) Received: by mrp.swissptt.ch; Wed, 24 Jun 2009 18:14:30 +0200 (MEST) From: To: , Date: Wed, 24 Jun 2009 18:14:27 +0200 Thread-Topic: [homegate] Management of the Home Gateway Thread-Index: Acn0rev87bI4nZqLTaqytvqaefhO0gAOAl+g Message-ID: <7191A9FADFABE74F94A8403B82C57A61015F52F0A9@sg000036.corproot.net> References: <6A141C5EC2D26E47B3128814D5F695921183CDF51C@TNS-FBU-2E-016.corp.telenor.no> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-CH Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 24 Jun 2009 16:14:46 -0000 Hi, >=20 > > Speeking as a service provider I think periodic updates is a good > > thing. >=20 > I do understand that if you depend on the user to initiate any action, > very little will happen. Still not sure why this is important enough > to incur the risks. Are there often CPE updates that are critical? > Doesn't seem that way to me. For me it sounds like we have to find a trade-off between security (or othe= r) problems caused by buggy updates and the problem caused by not updated d= evices... it is not easy to decide which way is right and depends perhaps o= n the use case. If the gateway includes the modem I would support automatic= updates, but if users have to have a separate modem, I am not sure ... >=20 > > NB: These are comments for the service provider devices, retail I do > > not have > > an opinion for. >=20 > Which brings up the question: what exactly are we trying to solve on > this list? If it's devices delivered to users as part of the service, > then obviously any and all issues can be negotiated between the vendor > and the service provider so there isn't much need to discuss them in > the IETF. (Although it would probably be helpful to come up with a > more standardized way to interact on the LAN side.) Service Providers are interested in open standards too since they reduce co= sts. So it is very interesting for a service provider to have an IETF speci= fied home gateway. >=20 > The case where the CPE is obtained by the user separately from the > service is much more complex and more inline with the IETF's mission Depends on what most users have at home... Do they buy their own gateway or= do they only have the one that came with the service? I think, it is 50-50= . Some users are happy the provider's box, other buy their own and place it= behind the provider's box, using the ISP's box only as modem. I think, we = should address both as far as possible. Carolin From william.howard@twcable.com Wed Jun 24 11:12:20 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 578EE28C18A for ; Wed, 24 Jun 2009 11:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 k26Y6hKtBWeY for ; Wed, 24 Jun 2009 11:12:19 -0700 (PDT) Received: from pblpas01.twcable.com (pblpas01.twcable.com [204.235.121.149]) by core3.amsl.com (Postfix) with ESMTP id 46D3F3A6A8E for ; Wed, 24 Jun 2009 11:12:19 -0700 (PDT) X-SENDER-IP: 10.157.247.212 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,284,1243828800"; d="scan'208";a="426292599" Received: from unknown (HELO prvpmailconn2.corp.twcable.com) ([10.157.247.212]) by pblpas01.twcable.com with ESMTP; 24 Jun 2009 14:11:15 -0400 Received: from PRVPVSMAIL07.corp.twcable.com ([10.157.247.204]) by prvpmailconn2.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2009 14:11:15 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 24 Jun 2009 14:11:13 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] Management of the Home Gateway thread-index: Acn0refMTFpE6flxRGKHZQzT4nnKLAAR6mbg References: <6A141C5EC2D26E47B3128814D5F695921183CDF51C@TNS-FBU-2E-016.corp.telenor.no> From: "Howard, Lee" To: "Iljitsch van Beijnum" , X-OriginalArrivalTime: 24 Jun 2009 18:11:15.0145 (UTC) FILETIME=[29C20390:01C9F4F7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Mailman-Approved-At: Wed, 24 Jun 2009 11:55:03 -0700 Cc: homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 24 Jun 2009 18:12:20 -0000 Cgo+IApQIEdvIEdyZWVuISBQcmludCB0aGlzIGVtYWlsIG9ubHkgd2hlbiBuZWNlc3NhcnkuIFRo YW5rIHlvdSBmb3IgaGVscGluZyBUaW1lIFdhcm5lciBDYWJsZSBiZSBlbnZpcm9ubWVudGFsbHkg cmVzcG9uc2libGUuCiAKIAotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+IEZyb206IGhvbWVn YXRlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpob21lZ2F0ZS1ib3VuY2VzQGlldGYub3JnXSBP bgpCZWhhbGYgT2YKPiBJbGppdHNjaCB2YW4gQmVpam51bQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVu ZSAyNCwgMjAwOSA1OjI0IEFNCj4gVG86IGVyaWsudGFyYWxkc2VuQHRlbGVub3IuY29tCj4gQ2M6 IGhvbWVnYXRlQGlldGYub3JnCj4gU3ViamVjdDogUmU6IFtob21lZ2F0ZV0gTWFuYWdlbWVudCBv ZiB0aGUgSG9tZSBHYXRld2F5Cj4gCj4gT24gMjQganVuIDIwMDksIGF0IDEwOjUzLCA8ZXJpay50 YXJhbGRzZW5AdGVsZW5vci5jb20+IHdyb3RlOgo+IAo+ID4gU3BlZWtpbmcgYXMgYSBzZXJ2aWNl IHByb3ZpZGVyIEkgdGhpbmsgcGVyaW9kaWMgdXBkYXRlcyBpcyBhIGdvb2QKPiA+IHRoaW5nLgo+ IAo+IEkgZG8gdW5kZXJzdGFuZCB0aGF0IGlmIHlvdSBkZXBlbmQgb24gdGhlIHVzZXIgdG8gaW5p dGlhdGUgYW55IGFjdGlvbiwKPiB2ZXJ5IGxpdHRsZSB3aWxsIGhhcHBlbi4gU3RpbGwgbm90IHN1 cmUgd2h5IHRoaXMgaXMgaW1wb3J0YW50IGVub3VnaAo+IHRvIGluY3VyIHRoZSByaXNrcy4gQXJl IHRoZXJlIG9mdGVuIENQRSB1cGRhdGVzIHRoYXQgYXJlIGNyaXRpY2FsPwo+IERvZXNuJ3Qgc2Vl bSB0aGF0IHdheSB0byBtZS4KCk1ha2UgaXQgYSBTSE9VTEQgd2l0aCB1c2VyLW92ZXJyaWRlLCBv ciBtYXliZSB3ZSBjYW4gd29yayBvdXQgYQpwcm92aWRlci1vdmVycmlkZSAoaS5lLiwgSVNQIEEg d2FudHMgYXV0by1wdXNoIGFuZCBpcyB3aWxsaW5nIHRvIGFjY2VwdApyZXNwb25zaWJpbGl0eSBm b3Igb3V0YWdlcywgSVNQIEIgZG9lc24ndDsgbmVnb3RpYXRlZCBjYXBhYmlsaXR5KS4gIAoKPiA+ IE5COiBUaGVzZSBhcmUgY29tbWVudHMgZm9yIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIGRldmljZXMs IHJldGFpbCBJIGRvCj4gPiBub3QgaGF2ZQo+ID4gYW4gb3BpbmlvbiBmb3IuCj4gCj4gV2hpY2gg YnJpbmdzIHVwIHRoZSBxdWVzdGlvbjogd2hhdCBleGFjdGx5IGFyZSB3ZSB0cnlpbmcgdG8gc29s dmUgb24KPiB0aGlzIGxpc3Q/IElmIGl0J3MgZGV2aWNlcyBkZWxpdmVyZWQgdG8gdXNlcnMgYXMg cGFydCBvZiB0aGUgc2VydmljZSwKPiB0aGVuIG9idmlvdXNseSBhbnkgYW5kIGFsbCBpc3N1ZXMg Y2FuIGJlIG5lZ290aWF0ZWQgYmV0d2VlbiB0aGUgdmVuZG9yCj4gYW5kIHRoZSBzZXJ2aWNlIHBy b3ZpZGVyIHNvIHRoZXJlIGlzbid0IG11Y2ggbmVlZCB0byBkaXNjdXNzIHRoZW0gaW4KPiB0aGUg SUVURi4gKEFsdGhvdWdoIGl0IHdvdWxkIHByb2JhYmx5IGJlIGhlbHBmdWwgdG8gY29tZSB1cCB3 aXRoIGEKPiBtb3JlIHN0YW5kYXJkaXplZCB3YXkgdG8gaW50ZXJhY3Qgb24gdGhlIExBTiBzaWRl LikKPiAKPiBUaGUgY2FzZSB3aGVyZSB0aGUgQ1BFIGlzIG9idGFpbmVkIGJ5IHRoZSB1c2VyIHNl cGFyYXRlbHkgZnJvbSB0aGUKPiBzZXJ2aWNlIGlzIG11Y2ggbW9yZSBjb21wbGV4IGFuZCBtb3Jl IGlubGluZSB3aXRoIHRoZSBJRVRGJ3MgbWlzc2lvbgo+IGFuZCBJIGRvbid0IHRoaW5rIGl0J3Mg ZXZlbiBwb3NzaWJsZSB0byBjb21lIHVwIHdpdGggYSB3b3JraW5nCj4gc2NlbmFyaW8gZm9yIHB1 c2hpbmcgb3V0IHVwZGF0ZXMgdGhlcmUuCgpJcyAid2hvIG93bnMgdGhlIGJveD8iIHJlYWxseSB0 aGUgcXVlc3Rpb24/ICAgU2VlbXMgdG8gbWUgd2UncmUgbG9va2luZyAKdG8gaW50ZXJuZXR3b3Jr IHR3byBraW5kcyBvZiBuZXR3b3Jrcywgb25lIG9mIHdoaWNoICh0aGUgcmVzaWRlbmNlKSAKbmVl ZHMgYmV0dGVyIHN0YW5kYXJkaXphdGlvbi4gICBJZiB3ZSBjYW4gcHJvdmlkZSBjb21tb24gZXhw ZWN0YXRpb25zLApyZWdhcmRsZXNzIG9mIHRoZSBsYXllciAyIHByb3RvY29scyAoRXRoZXJuZXQs IERTTCBvciBjYWJsZSkgd2UgY2FuCnJlZHVjZSBjb21wbGV4aXR5LiAgCgoKTGVlCgpUaGlzIEUt bWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lcgpD YWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlk ZW50aWFsLApvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIg Q2FibGUuIFRoaXMgRS1tYWlsCmlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUg aW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2gKaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMKRS1tYWlsLCB5b3UgYXJlIGhlcmVi eSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLApkaXN0cmlidXRpb24sIGNvcHlpbmcs IG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMKb2YgYW5kIGF0dGFj aG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZQp1 bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkKdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRo ZSBvcmlnaW5hbCBhbmQgYW55CmNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4K From Mika.Saaranen@nokia.com Thu Jun 25 01:07:32 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 65AE628C0DE; Thu, 25 Jun 2009 01:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 SGSMoSwvZVko; Thu, 25 Jun 2009 01:07:30 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 7437E3A6359; Thu, 25 Jun 2009 01:07:30 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5P83XI8018391; Thu, 25 Jun 2009 03:03:56 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 11:03:29 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 11:03:29 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 11:03:24 +0300 Received: from NOK-EUMSG-04.mgdnok.nokia.com ([65.54.30.89]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 25 Jun 2009 10:03:23 +0200 From: To: , Date: Thu, 25 Jun 2009 10:03:19 +0200 Thread-Topic: [homegate] Management of the Home Gateway Thread-Index: Acn0Fi56HqRwv/1KQAGNcCSxEmgtHABUa6vg Message-ID: References: <3B59A5CF-B8B2-4832-985F-182597439ECF@americafree.tv> 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_A442CE0DDEE9E54589264FF96B513A4B489791D768NOKEUMSG04mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Jun 2009 08:03:24.0301 (UTC) FILETIME=[69DA9BD0:01C9F56B] X-Nokia-AV: Clean Cc: homegate-bounces@ietf.org, homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 25 Jun 2009 08:07:32 -0000 --_000_A442CE0DDEE9E54589264FF96B513A4B489791D768NOKEUMSG04mgd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I would agree on this approach. I think that we need to first look what oth= ers have done and what is missing. I am not sure if markets would agree on = some certain device management scheme as there are many already existing, b= ut I think that IETf could recommend certain approaches. Other issue would = be looking what other SDOs have defined and if it is something that has bee= n really deployed and if it overlaps homegate way and how. I have been work= ing with DLNA and UPnP, so I know that area somewhat. DLNA as an organizati= on is focused on creating interoperability with certification test tool tha= n creating new protocols. DLNA has not really defined any home gateways, bu= t its guidelines does address full protocol stack, so there are guidelines = for IETF protocols too. UPnP forum does have its gateway committee that has defined Internet gatew= ay speciifications and works for the next version. UPnP IGD is not a holist= ic definition what is a gateway and how it should work, but it provides API= s to mostly IETF or de facto standards on layer 2 and layer 3 (possibly eve= n to application level) protocols. What definetely lacks from that specific= ation family is how to implement IETF protocols in detail. For instance, de= tails and options for DNS, DHCP etc are not defined. Current UPnP gateway w= ork for now expands from NAT traversal, IPv6 firewall control to security s= olution, so from UPnP perspective this home gateway would touch only partia= lly the area and vice versa. Also, how many other groups in IETF actually d= efine stuff that is really part of this home gateway initiative. Maybe we should take following topics into discussion and eventually to the= charter: * Model what is a home gateway, what it does, does it have variations? * Device management aspects, and if the solution defined would have real ch= ance to be widely deployed * BCPs for IETF protocols in gateways * what APIs and protocol definitions other SDOs have done, missing things, = whats wrong, would these SDOs take input. I am not sure if the list broadba= nd forum, HGI, OSGI, UPnP, cablelabs best regards, Mika ________________________________ From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behal= f Of ext Ray.Bellis@nominet.org.uk Sent: 23. kes=E4kuuta 2009 18:20 To: Bob Carrick Cc: homegate-bounces@ietf.org; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway Personally, I would rather see this group concentrate on developing BCPs fo= r ensuring *correct* implementation of current IETF *protocol* standards, a= nd not working to develop new protocols, mechanisms, update systems, etc. Ray --_000_A442CE0DDEE9E54589264FF96B513A4B489791D768NOKEUMSG04mgd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I would agree on this approach. I think that we ne= ed to=20 first look what others have done and what is missing. I am not sure if mark= ets=20 would agree on some certain device management scheme as there are many alre= ady=20 existing, but I think that IETf could recommend certain approaches. Other i= ssue=20 would be looking what other SDOs have defined and if it is something that h= as=20 been really deployed and if it overlaps homegate way and how. I have b= een=20 working with DLNA and UPnP, so I know that area somewhat. DLNA as an=20 organization is focused on creating interoperability with certification tes= t=20 tool than creating new protocols. DLNA has not really defined any home gate= ways,=20 but its guidelines does address full protocol stack, so there are=20 guidelines for IETF protocols too. 
 
 UPnP forum does have its gateway committee t= hat has=20 defined Internet gateway speciifications and works for the next=20 version. UPnP IGD is not a holistic definition what is a gateway = and=20 how it should work, but it provides APIs to mostly IETF or de facto standar= ds on=20 layer 2 and layer 3 (possibly even to application level) protocols. What=20 definetely lacks from that specification family is how to implement IETF=20 protocols in detail. For instance, details and options for DNS, DHCP etc ar= e not=20 defined. Current UPnP gateway work for now expands from NAT traversal,= IPv6=20 firewall control to security solution, so from UPnP perspective this home=20 gateway would touch only partially the area and vice versa. Also, how many = other=20 groups in IETF actually define stuff that is really part of this home gatew= ay=20 initiative.
 
Maybe we should take following topics into discuss= ion and=20 eventually to the charter:
* Model what is a home gateway, what it does, does= it have=20 variations?
* Device management aspects, and if the solution d= efined=20 would have real chance to be widely deployed
* BCPs for IETF protocols in gateways
* what APIs and protocol definitions other SDOs ha= ve done,=20 missing things, whats wrong, would these SDOs take input. I am not sure if = the=20 list broadband forum, HGI, OSGI, UPnP, cablelabs
 
best=20 regards,
    Mika

 
From: homegate-bounces@ietf.org=20 [mailto:homegate-bounces@ietf.org] On Behalf Of ext=20 Ray.Bellis@nominet.org.uk
Sent: 23. kes=E4kuuta 2009 18:20
= To:=20 Bob Carrick
Cc: homegate-bounces@ietf.org;=20 homegate@ietf.org
Subject: Re: [homegate] Management of the Home= =20 Gateway

Personally, I would rather see this group=20 concentrate on developing BCPs for ensuring *correct* implementation of cur= rent=20 IETF *protocol* standards, and not working to develop new protocols, mechan= isms,=20 update systems, etc.

Ray= =20

--_000_A442CE0DDEE9E54589264FF96B513A4B489791D768NOKEUMSG04mgd_-- From Carolin.Latze@swisscom.com Thu Jun 25 02:09:12 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 E0E963A69FD; Thu, 25 Jun 2009 02:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 wZpHdOKf3U8X; Thu, 25 Jun 2009 02:09:11 -0700 (PDT) Received: from mail.swisscom.com (outmail21.swisscom.com [138.190.32.11]) by core3.amsl.com (Postfix) with ESMTP id 2A6CB3A6AF7; Thu, 25 Jun 2009 02:08:50 -0700 (PDT) Received: by mrp.swissptt.ch; Thu, 25 Jun 2009 10:18:47 +0200 (MEST) From: To: , , Date: Thu, 25 Jun 2009 10:18:34 +0200 Thread-Topic: [homegate] Management of the Home Gateway Thread-Index: Acn0Fi56HqRwv/1KQAGNcCSxEmgtHABUa6vgAAFdOLA= Message-ID: <7191A9FADFABE74F94A8403B82C57A61015F52F2EB@sg000036.corproot.net> References: <3B59A5CF-B8B2-4832-985F-182597439ECF@americafree.tv> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-CH Content-Type: multipart/alternative; boundary="_000_7191A9FADFABE74F94A8403B82C57A61015F52F2EBsg000036corpr_" MIME-Version: 1.0 Cc: homegate-bounces@ietf.org, homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway 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, 25 Jun 2009 09:09:13 -0000 --_000_7191A9FADFABE74F94A8403B82C57A61015F52F2EBsg000036corpr_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 Carolin From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behal= f Of Mika.Saaranen@nokia.com Sent: Donnerstag, 25. Juni 2009 10:03 To: Ray.Bellis@nominet.org.uk; bcarrick@finepoint.com Cc: homegate-bounces@ietf.org; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway Hi, I would agree on this approach. I think that we need to first look what oth= ers have done and what is missing. I am not sure if markets would agree on = some certain device management scheme as there are many already existing, b= ut I think that IETf could recommend certain approaches. Other issue would = be looking what other SDOs have defined and if it is something that has bee= n really deployed and if it overlaps homegate way and how. I have been work= ing with DLNA and UPnP, so I know that area somewhat. DLNA as an organizati= on is focused on creating interoperability with certification test tool tha= n creating new protocols. DLNA has not really defined any home gateways, bu= t its guidelines does address full protocol stack, so there are guidelines = for IETF protocols too. UPnP forum does have its gateway committee that has defined Internet gatew= ay speciifications and works for the next version. UPnP IGD is not a holist= ic definition what is a gateway and how it should work, but it provides API= s to mostly IETF or de facto standards on layer 2 and layer 3 (possibly eve= n to application level) protocols. What definetely lacks from that specific= ation family is how to implement IETF protocols in detail. For instance, de= tails and options for DNS, DHCP etc are not defined. Current UPnP gateway w= ork for now expands from NAT traversal, IPv6 firewall control to security s= olution, so from UPnP perspective this home gateway would touch only partia= lly the area and vice versa. Also, how many other groups in IETF actually d= efine stuff that is really part of this home gateway initiative. Maybe we should take following topics into discussion and eventually to the= charter: * Model what is a home gateway, what it does, does it have variations? * Device management aspects, and if the solution defined would have real ch= ance to be widely deployed * BCPs for IETF protocols in gateways * what APIs and protocol definitions other SDOs have done, missing things, = whats wrong, would these SDOs take input. I am not sure if the list broadba= nd forum, HGI, OSGI, UPnP, cablelabs best regards, Mika ________________________________ From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behal= f Of ext Ray.Bellis@nominet.org.uk Sent: 23. kes=E4kuuta 2009 18:20 To: Bob Carrick Cc: homegate-bounces@ietf.org; homegate@ietf.org Subject: Re: [homegate] Management of the Home Gateway Personally, I would rather see this group concentrate on developing BCPs fo= r ensuring *correct* implementation of current IETF *protocol* standards, a= nd not working to develop new protocols, mechanisms, update systems, etc. Ray --_000_7191A9FADFABE74F94A8403B82C57A61015F52F2EBsg000036corpr_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+1


Carolin

 

From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behalf Of Mika.Saaranen@nokia.= com
Sent: Donnerstag, 25. Juni 2009 10:03
To: Ray.Bellis@nominet.org.uk; bcarrick@finepoint.com
Cc: homegate-bounces@ietf.org; homegate@ietf.org
Subject: Re: [homegate] Management of the Home Gateway

 

Hi,

 

I would agree on this approach. I think that we need to first l= ook what others have done and what is missing. I am not sure if markets would a= gree on some certain device management scheme as there are many already existing= , but I think that IETf could recommend certain approaches. Other issue would= be looking what other SDOs have defined and if it is something that has been really deployed and if it overlaps homegate way and how. I have been working with DLNA and UPnP, so I know that area somewhat. DLNA as an organization is focused on creating interoperability with certification tes= t tool than creating new protocols. DLNA has not really defined any home gateways, but its guidelines does address full protocol stack, so ther= e are guidelines for IETF protocols too. 

 

 UPnP forum does have its gateway committee that has defin= ed Internet gateway speciifications and works for the next version. UPnP IGD is not a holistic definition what is a gateway and how it should w= ork, but it provides APIs to mostly IETF or de facto standards on layer 2 and la= yer 3 (possibly even to application level) protocols. What definetely lacks fro= m that specification family is how to implement IETF protocols in detail. For instance, details and options for DNS, DHCP etc are not defined. Curre= nt UPnP gateway work for now expands from NAT traversal, IPv6 firewall control= to security solution, so from UPnP perspective this home gateway would touch o= nly partially the area and vice versa. Also, how many other groups in IETF actu= ally define stuff that is really part of this home gateway initiative.

 

Maybe we should take following topics into discussion and eventually to the charter:

* Model what is a home gateway, what it does, does it have variations?

* Device management aspects, and if the solution defined would = have real chance to be widely deployed

* BCPs for IETF protocols in gateways

* what APIs and protocol definitions other SDOs have done, miss= ing things, whats wrong, would these SDOs take input. I am not sure if the list broadband forum, HGI, OSGI, UPnP, cablelabs

 

best regards,

    Mika


 

From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behalf O= f ext Ray.Bellis@nominet.org.uk
Sent: 23. kes=E4kuuta 2009 18:20
To: Bob Carrick
Cc: homegate-bounces@ietf.org; homegate@ietf.org
Subject: Re: [homegate] Management of the Home Gateway

Personally, I would rather see this group concentrate on developing BCPs for ensuring *correct* implementation of current IETF *protocol* standards, and not working to develop new protocols, mechanisms, update systems, etc.

Ray

--_000_7191A9FADFABE74F94A8403B82C57A61015F52F2EBsg000036corpr_-- From mail@sabahattin-gucukoglu.com Thu Jun 25 03:21:09 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 A23C43A69E8 for ; Thu, 25 Jun 2009 03:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=0.352, 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 j1pwwmecy9mz for ; Thu, 25 Jun 2009 03:21:08 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 959EA3A68E0 for ; Thu, 25 Jun 2009 03:21:08 -0700 (PDT) Received: by ewy6 with SMTP id 6so2066339ewy.37 for ; Thu, 25 Jun 2009 03:20:58 -0700 (PDT) Received: by 10.216.47.71 with SMTP id s49mr729059web.129.1245925258760; Thu, 25 Jun 2009 03:20:58 -0700 (PDT) Received: from ?192.168.1.3? (62-30-111-115.cable.ubr07.dals.blueyonder.co.uk [62.30.111.115]) by mx.google.com with ESMTPS id q9sm5252188gve.17.2009.06.25.03.20.57 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Jun 2009 03:20:57 -0700 (PDT) Message-Id: From: Sabahattin Gucukoglu To: homegate@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 25 Jun 2009 11:20:55 +0100 X-Mailer: Apple Mail (2.935.3) Subject: [homegate] What's a "Home Gateway"? 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, 25 Jun 2009 10:21:09 -0000 Can we start with a definition of a homegate-compliant home gateway that avoids lots of the issues we're discussing here, like who gets to own it? Here's my shot at it (in very rough): that device or part of a device which is between the user's connection to the wider Internet and his local network infrastructure, and provides a means of reaching or of being reached from the Internet on a typically exclusive basis. Now it's easy to define where are work is guided: toward the LAN side. We can say things like, "We want conformance in the gateway part, but you can do what you like to your modem part" or whatever satisfies both camps. It means we can easily distinguish a DSL "Router" from a cable modem, since the former incorporates a home gateway and the latter clearly doesn't. And we can now leave everybody in the broadband SIGs of the world to continue doing horrible things to their infrastructure just so long as we get ECN and working multicast. Consumers can now be left with a to-the-door connection and buy their own gateway, or can be given one and can understand that using a second gateway is bad without the necessary bridging treatment (or whatever). Cheers, Sabahattin From erik.taraldsen@telenor.com Thu Jun 25 05:01: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 8AE8728C18E for ; Thu, 25 Jun 2009 05:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1] 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 JQCkUivnANJU for ; Thu, 25 Jun 2009 05:01:34 -0700 (PDT) Received: from idun.telenor.net (virus-out-st.online.no [193.212.240.200]) by core3.amsl.com (Postfix) with ESMTP id 6053628C142 for ; Thu, 25 Jun 2009 05:01:34 -0700 (PDT) Received: from tns-fbu-22-249.corp.telenor.no ([134.47.162.189] [134.47.162.189]) by idun.telenor.net with ESMTPS id BT-MMP-1333091 for homegate@ietf.org; Thu, 25 Jun 2009 14:00:51 +0200 Received: from TNS-FBU-2E-016.corp.telenor.no ([134.47.163.219]) by tns-fbu-22-249.corp.telenor.no ([134.47.162.189]) with mapi; Thu, 25 Jun 2009 14:00:50 +0200 From: To: Date: Thu, 25 Jun 2009 14:00:49 +0200 Thread-Topic: [homegate] Management of the Home Gateway Thread-Index: Acn0rehzAJcI960YT5urSj8vuQaQFAA21bsQ Message-ID: <6A141C5EC2D26E47B3128814D5F695921183D466C1@TNS-FBU-2E-016.corp.telenor.no> References: <6A141C5EC2D26E47B3128814D5F695921183CDF51C@TNS-FBU-2E-016.corp.telenor.no> In-Reply-To: Accept-Language: nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nb-NO Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homegate] Management of the Home Gateway 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, 25 Jun 2009 12:01:35 -0000 > I do understand that if you depend on the user to initiate any action, =20 > very little will happen. Still not sure why this is important enough =20 > to incur the risks. Are there often CPE updates that are critical? =20 > Doesn't seem that way to me. Approx once a year pr HW device. As mentioned elsewhere on this list there = is sometimes security holes which needs to be patched. Most often though t= here is compatibility, stability and evovling standards which are the reaso= ns for upgrading. ADSL is still evolving. A device we are upgrading this s= ummer will have approx 20% increase in dsl sync rate, 20% longer reach and = reduce resync problems to nearly zero for long reach lines. The increased = dsl performance is not a poor implementation originaly, but the adsl standa= rd has continiualy refined over the years. =20 There are also cases where major operating system vendors introduce bugs in= their network stack where the CPE vendors have to introduce bug compatebil= ity. I also expect introduction of features like IPv6 and vdsl2 will need a lot = of upgrades since we all are learning there. -Erik Taraldsen Telenor From wbeebee@cisco.com Thu Jun 25 06:29: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 EF7023A6B0C for ; Thu, 25 Jun 2009 06:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 FgV3Tlnnj8Um for ; Thu, 25 Jun 2009 06:29:42 -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 A7CE83A6D6B for ; Thu, 25 Jun 2009 06:29:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,290,1243814400"; d="scan'208";a="331599987" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 25 Jun 2009 13:28:32 +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 n5PDSXc3031603; Thu, 25 Jun 2009 06:28:33 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n5PDSWAF004896; Thu, 25 Jun 2009 13:28:32 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 09:28:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 09:28:31 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] What's a "Home Gateway"? Thread-Index: Acn1frYH9t+g7/ZlTJCwmJMKq38iagAGF3/g References: From: "Wes Beebee (wbeebee)" To: "Sabahattin Gucukoglu" , X-OriginalArrivalTime: 25 Jun 2009 13:28:32.0226 (UTC) FILETIME=[D57BBC20:01C9F598] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2963; t=1245936513; x=1246800513; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20[homegate]=20What's=20a=20=22Home=20Gat eway=22? |Sender:=20; bh=URFCErho5NZh5+d5p33c1ZVBQ8/Pz3v7BNJ17PQK44k=; b=O/ZM5zj7eh1zq9ajsb0am+TGMUEVDb7IOeDSdsJRgXEeAJTLQO+ey1yKNL pNAg3UK68GNsrPnaXtF6Vx5eCAZgCu+pID4h+Z6tmBK+Z45tgK+b2Unu2Pgw lLDuYGYZtQu7mHskrB66P3Mm5E/CfCh+rPwEQ/DwTEDKyNEV9qozo=; Authentication-Results: sj-dkim-1; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [homegate] What's a "Home Gateway"? 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, 25 Jun 2009 13:29:44 -0000 Regarding second gateways, the problem is that there's a trust boundary between that which the service provider manages and that which the home user manages - and neither can completely trust the other... Consider the following scenario: A service provider provides a gateway integrated into a cable modem that the service providers manages (say following the CableLabs eRouter specification) to protect the service provider network from malicious users. However, this gateway can operate in routing mode or bridging mode, but the end customer has absolutely no way of detecting whether the gateway is a router or a bridge. Now the customer has sensitive documents (like tax records) on a local network drive, and tries to access them across the network. Since the customer has no way of knowing whether the eRouter is in router or bridge mode, he doesn't know whether copies of the sensitive documents are being sent across the service provider's network. To protect himself, he installs a second gateway behind the first gateway - a gateway that he manages - and can be assured that routed traffic (like the sensitive documents) is not being copied on the service provider network. All of a sudden, you have the possibility of two gateway/routers on the same network - one behind the other - at the trust boundary. - Wes -----Original Message----- From: homegate-bounces@ietf.org [mailto:homegate-bounces@ietf.org] On Behalf Of Sabahattin Gucukoglu Sent: Thursday, June 25, 2009 6:21 AM To: homegate@ietf.org Subject: [homegate] What's a "Home Gateway"? Can we start with a definition of a homegate-compliant home gateway that avoids lots of the issues we're discussing here, like who gets to own it? Here's my shot at it (in very rough): that device or part of a device which is between the user's connection to the wider Internet and his local network infrastructure, and provides a means of reaching or of being reached from the Internet on a typically exclusive basis. Now it's easy to define where are work is guided: toward the LAN side. We can say things like, "We want conformance in the gateway part, but you can do what you like to your modem part" or whatever satisfies both camps. It means we can easily distinguish a DSL "Router" from a cable modem, since the former incorporates a home gateway and the latter clearly doesn't. And we can now leave everybody in the broadband SIGs of the world to continue doing horrible things to their infrastructure just so long as we get ECN and working multicast. Consumers can now be left with a to-the-door connection and buy their own gateway, or can be given one and can understand that using a second gateway is bad without the necessary bridging treatment (or whatever). Cheers, Sabahattin _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate From iljitsch@muada.com Thu Jun 25 07:44: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 68ADC3A6862 for ; Thu, 25 Jun 2009 07:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 FRD4ZQM4Eorg for ; Thu, 25 Jun 2009 07:44:14 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 7981A3A68C8 for ; Thu, 25 Jun 2009 07:44:14 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n5PEgXXP064692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Jun 2009 16:42:34 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <0EFB19E5-C8EA-4A7B-931D-0F41DF262ADC@muada.com> From: Iljitsch van Beijnum To: "Wes Beebee (wbeebee)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 25 Jun 2009 16:42:08 +0200 References: X-Mailer: Apple Mail (2.935.3) Cc: homegate@ietf.org Subject: Re: [homegate] What's a "Home Gateway"? 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, 25 Jun 2009 14:44:15 -0000 On 25 jun 2009, at 15:28, Wes Beebee (wbeebee) wrote: > All of a sudden, you have the possibility of two gateway/routers on > the > same network - one behind the other - at the trust boundary. Seems that we need to require that any and all boxes provided by service providers be able to function in a modem-only mode, where the user provides the actual home gateway themselves. From wbeebee@cisco.com Thu Jun 25 08:36: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 A8EDD3A6C11 for ; Thu, 25 Jun 2009 08:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 YvvFdLwoh6oX for ; Thu, 25 Jun 2009 08:36:38 -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 A99A63A691C for ; Thu, 25 Jun 2009 08:36:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,290,1243814400"; d="scan'208";a="205593526" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 25 Jun 2009 15:36:12 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5PFaC2k009767; Thu, 25 Jun 2009 08:36:12 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n5PFa6Qe024661; Thu, 25 Jun 2009 15:36:12 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 11:36:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 11:36:10 -0400 Message-ID: In-Reply-To: <0EFB19E5-C8EA-4A7B-931D-0F41DF262ADC@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] What's a "Home Gateway"? Thread-Index: Acn1ozdstZRAoAXMQ1+WdLeviODZMQABjwww References: <0EFB19E5-C8EA-4A7B-931D-0F41DF262ADC@muada.com> From: "Wes Beebee (wbeebee)" To: "Iljitsch van Beijnum" X-OriginalArrivalTime: 25 Jun 2009 15:36:11.0513 (UTC) FILETIME=[AAC62E90:01C9F5AA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=793; t=1245944172; x=1246808172; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20[homegate]=20What's=20a=20=22Home=20Gat eway=22? |Sender:=20; bh=5VjtQq5YK7zvEI2inZX7oYO+9OoXcucY3VKL9BgFLJQ=; b=lQRwxpkS6+99gPgUN/pQjHnazbdoyQgEcaqsVruEJwo7tt7qHHlkyma+XD FNeZfY/VPnify7WoTJTBJZml/3EqB+CdDOgpx8AmDiEQUC3Kx+AUn2NuE/NZ Kjv5hgXez2; Authentication-Results: sj-dkim-3; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: homegate@ietf.org Subject: Re: [homegate] What's a "Home Gateway"? 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, 25 Jun 2009 15:36:39 -0000 >On 25 jun 2009, at 15:28, Wes Beebee (wbeebee) wrote: >> All of a sudden, you have the possibility of two gateway/routers on=20 >> the same network - one behind the other - at the trust boundary. > Seems that we need to require that any and all boxes provided by service providers be able to function in a=20 > modem-only mode, where the user provides the actual home gateway themselves. If you want to enforce the "one router in the home" rule, then you need to explicitly tell the service provider that when there is a router provided by the user, then the box provided by the service provider MUST be operating in bridge mode. I'm not sure that all service providers that deploy eRouters will trust that the users have configured their home router properly... - Wes From mail@sabahattin-gucukoglu.com Thu Jun 25 09:05:13 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 6F9EE3A6839 for ; Thu, 25 Jun 2009 09:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.422, 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 ouJ449uP3EeL for ; Thu, 25 Jun 2009 09:05:12 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 65B003A6967 for ; Thu, 25 Jun 2009 09:05:12 -0700 (PDT) Received: by ewy6 with SMTP id 6so2409921ewy.37 for ; Thu, 25 Jun 2009 09:03:55 -0700 (PDT) Received: by 10.216.36.79 with SMTP id v57mr825018wea.19.1245945833404; Thu, 25 Jun 2009 09:03:53 -0700 (PDT) Received: from ?192.168.1.3? ([62.30.111.115]) by mx.google.com with ESMTPS id f13sm2295586gvd.8.2009.06.25.09.03.51 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Jun 2009 09:03:52 -0700 (PDT) Message-Id: <623B8945-7ECE-41EE-A5A5-23532FF3A4FB@sabahattin-gucukoglu.com> From: Sabahattin Gucukoglu To: homegate@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 25 Jun 2009 17:03:50 +0100 References: X-Mailer: Apple Mail (2.935.3) Subject: Re: [homegate] What's a "Home Gateway"? 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, 25 Jun 2009 16:05:13 -0000 On 25 Jun 2009, at 14:28, Wes Beebee (wbeebee) wrote: > Regarding second gateways, the problem is that there's a trust > boundary > between that which the service provider manages and that which the > home > user manages - and neither can completely trust the other... [...] > All of a sudden, you have the possibility of two gateway/routers on > the > same network - one behind the other - at the trust boundary. We choose to standardise the gateway (LAN) part, and make it a requirement that the part be distinct, whether physically or by design of the software inside a single box. That's all. We can disclaim responsibility for ISP management of the non-gateway bits. In fact, consumers can grow used to purchasing two-part appliances whose one half is on their side and whose other isn't. We recognise the two parts independently, treat them independently. We can now set more reasonable goals, and establish principles and policies applicable to consumer-focused applications, including that of for instance being conservative about updates, if we feel that way, without regard to ISP needs. Simple as. Or we can go v6/e6 and ethernet, and suddenly we don't need gateways anymore because the ISP rules all. :-) It occurs to me that all our glorious work will come to nothing if this happens, and that it will all seem a bit overmuch in light of such an obvious inevitability. Cheers, Sabahattin From richard_woundy@cable.comcast.com Thu Jun 25 09:09:14 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 D8B073A6CB0 for ; Thu, 25 Jun 2009 09:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8] 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 4BlX3-M3s8rH for ; Thu, 25 Jun 2009 09:09:14 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id D766F3A69CF for ; Thu, 25 Jun 2009 09:09:13 -0700 (PDT) Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.43185591; Thu, 25 Jun 2009 11:47:21 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 11:47:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 25 Jun 2009 11:47:11 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] What's a "Home Gateway"? Thread-Index: Acn1ozdstZRAoAXMQ1+WdLeviODZMQABjwwwAACwH0Y= From: "Woundy, Richard" To: , X-OriginalArrivalTime: 25 Jun 2009 15:47:22.0814 (UTC) FILETIME=[3AE695E0:01C9F5AC] Cc: homegate@ietf.org Subject: Re: [homegate] What's a "Home Gateway"? 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, 25 Jun 2009 16:09:14 -0000 V2hhdCBwcm9ibGVtIGFyZSB3ZSB0cnlpbmcgdG8gYXZvaWQgaGVyZT8gU29tZSBjdXN0b21lcnMg YWxyZWFkeSBydW4gbXVsdGlwbGUgY2FzY2FkaW5nIHJvdXRlcnMgaW4gdGhlIGhvbWUgb24gdGhl aXIgb3duLg0KDQpXaGF0IGlmIHRoZSBJU1Agcm91dGVyIGluIHRoZSBob21lIHN1cHBvcnRzIElQ djQgYW5kIElQdjYgcm91dGluZywgYnV0IHRoZSBjb25zdW1lciByb3V0ZXIgc3VwcG9ydHMgSVB2 NCByb3V0aW5nIGFuZCBJUHY2IGJyaWRnaW5nPyBJdCBzZWVtcyBsaWtlIHRoZXJlIGNvdWxkIGJl IGEgbnVtYmVyIG9mIGNvcm5lciBjYXNlcyBpbiB3aGljaCB0d28gcm91dGVycyBtYXkgbWFrZSBz ZW5zZS4NCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBob21lZ2F0ZS1i b3VuY2VzQGlldGYub3JnIDxob21lZ2F0ZS1ib3VuY2VzQGlldGYub3JnPg0KVG86IElsaml0c2No IHZhbiBCZWlqbnVtIDxpbGppdHNjaEBtdWFkYS5jb20+DQpDYzogaG9tZWdhdGVAaWV0Zi5vcmcg PGhvbWVnYXRlQGlldGYub3JnPg0KU2VudDogVGh1IEp1biAyNSAxMTozNjoxMCAyMDA5DQpTdWJq ZWN0OiBSZTogW2hvbWVnYXRlXSBXaGF0J3MgYSAiSG9tZSBHYXRld2F5Ij8NCg0KPk9uIDI1IGp1 biAyMDA5LCBhdCAxNToyOCwgV2VzIEJlZWJlZSAod2JlZWJlZSkgd3JvdGU6DQoNCj4+IEFsbCBv ZiBhIHN1ZGRlbiwgeW91IGhhdmUgdGhlIHBvc3NpYmlsaXR5IG9mIHR3byBnYXRld2F5L3JvdXRl cnMgb24gDQo+PiB0aGUgc2FtZSBuZXR3b3JrIC0gb25lIGJlaGluZCB0aGUgb3RoZXIgLSBhdCB0 aGUgdHJ1c3QgYm91bmRhcnkuDQoNCj4gU2VlbXMgdGhhdCB3ZSBuZWVkIHRvIHJlcXVpcmUgdGhh dCBhbnkgYW5kIGFsbCBib3hlcyBwcm92aWRlZCBieQ0Kc2VydmljZSBwcm92aWRlcnMgYmUgYWJs ZSB0byBmdW5jdGlvbiBpbiBhIA0KPiBtb2RlbS1vbmx5IG1vZGUsIHdoZXJlIHRoZSB1c2VyIHBy b3ZpZGVzIHRoZSBhY3R1YWwgaG9tZSBnYXRld2F5DQp0aGVtc2VsdmVzLg0KDQpJZiB5b3Ugd2Fu dCB0byBlbmZvcmNlIHRoZSAib25lIHJvdXRlciBpbiB0aGUgaG9tZSIgcnVsZSwgdGhlbiB5b3Ug bmVlZA0KdG8gZXhwbGljaXRseSB0ZWxsIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIHRoYXQgd2hlbiB0 aGVyZSBpcyBhIHJvdXRlcg0KcHJvdmlkZWQgYnkgdGhlIHVzZXIsIHRoZW4gdGhlIGJveCBwcm92 aWRlZCBieSB0aGUgc2VydmljZSBwcm92aWRlciBNVVNUDQpiZSBvcGVyYXRpbmcgaW4gYnJpZGdl IG1vZGUuICBJJ20gbm90IHN1cmUgdGhhdCBhbGwgc2VydmljZSBwcm92aWRlcnMNCnRoYXQgZGVw bG95IGVSb3V0ZXJzIHdpbGwgdHJ1c3QgdGhhdCB0aGUgdXNlcnMgaGF2ZSBjb25maWd1cmVkIHRo ZWlyDQpob21lIHJvdXRlciBwcm9wZXJseS4uLg0KDQotIFdlcw0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmhvbWVnYXRlIG1haWxpbmcgbGlzdA0KaG9t ZWdhdGVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaG9t ZWdhdGUNCg== From wbeebee@cisco.com Thu Jun 25 09:12:47 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 68A443A69F7 for ; Thu, 25 Jun 2009 09:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 eds9cupHsQdc for ; Thu, 25 Jun 2009 09:12:46 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 50DFD3A6967 for ; Thu, 25 Jun 2009 09:12:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,290,1243814400"; d="scan'208";a="82907674" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 25 Jun 2009 16:11:43 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5PGBgEL027914; Thu, 25 Jun 2009 12:11:42 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5PGBgw0002177; Thu, 25 Jun 2009 16:11:42 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 12:11:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 12:11:41 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] What's a "Home Gateway"? Thread-Index: Acn1ozdstZRAoAXMQ1+WdLeviODZMQABjwwwAACwH0YAAMIpgA== References: From: "Wes Beebee (wbeebee)" To: "Woundy, Richard" , X-OriginalArrivalTime: 25 Jun 2009 16:11:42.0700 (UTC) FILETIME=[A10F82C0:01C9F5AF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2050; t=1245946302; x=1246810302; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20[homegate]=20What's=20a=20=22Home=20Gat eway=22? |Sender:=20 |To:=20=22Woundy,=20Richard=22=20,=20; bh=pxiE6bRx/mWrVjB3jLS9z0w389n7KByCECf52+ECASQ=; b=sOSy37KBy4hTGMQUfvlztmlqNgJ3Hx6hVV35uo9Xu1+RBp7HIw7OqqN6eT y3emvCqw0BDXTLPUTMh0dfFtmDyqynyPnvhvXJ6uUfSeXlydGcX3h+z9iFGx 9/jQ09bZgJ; Authentication-Results: rtp-dkim-2; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: homegate@ietf.org Subject: Re: [homegate] What's a "Home Gateway"? 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, 25 Jun 2009 16:12:47 -0000 And that would exactly be my point - we have to design protocols in IETF and come up with a set of requirements for home gateways that does not preclude the possibility of having two or more cascaded routers in the home. - Wes=20 -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]=20 Sent: Thursday, June 25, 2009 11:47 AM To: Wes Beebee (wbeebee); iljitsch@muada.com Cc: homegate@ietf.org Subject: Re: [homegate] What's a "Home Gateway"? What problem are we trying to avoid here? Some customers already run multiple cascading routers in the home on their own. What if the ISP router in the home supports IPv4 and IPv6 routing, but the consumer router supports IPv4 routing and IPv6 bridging? It seems like there could be a number of corner cases in which two routers may make sense. ----- Original Message ----- From: homegate-bounces@ietf.org To: Iljitsch van Beijnum Cc: homegate@ietf.org Sent: Thu Jun 25 11:36:10 2009 Subject: Re: [homegate] What's a "Home Gateway"? >On 25 jun 2009, at 15:28, Wes Beebee (wbeebee) wrote: >> All of a sudden, you have the possibility of two gateway/routers on=20 >> the same network - one behind the other - at the trust boundary. > Seems that we need to require that any and all boxes provided by service providers be able to function in a=20 > modem-only mode, where the user provides the actual home gateway themselves. If you want to enforce the "one router in the home" rule, then you need to explicitly tell the service provider that when there is a router provided by the user, then the box provided by the service provider MUST be operating in bridge mode. I'm not sure that all service providers that deploy eRouters will trust that the users have configured their home router properly... - Wes _______________________________________________ homegate mailing list homegate@ietf.org https://www.ietf.org/mailman/listinfo/homegate From oran@cisco.com Fri Jun 26 12:08: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 66FC13A6BFB for ; Fri, 26 Jun 2009 12:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 QBTi2MTwPDqi for ; Fri, 26 Jun 2009 12:08:34 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6DEA33A6BE5 for ; Fri, 26 Jun 2009 12:08:34 -0700 (PDT) X-Files: PGP.sig : 195 X-IronPort-AV: E=Sophos;i="4.42,297,1243814400"; d="sig'?scan'208";a="48636745" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 26 Jun 2009 19:08:42 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5QJ8g1j020772 for ; Fri, 26 Jun 2009 15:08:42 -0400 Received: from dhcp-161-44-173-229.cisco.com (dhcp-161-44-173-229.cisco.com [161.44.173.229]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n5QJ8WwC029739 for ; Fri, 26 Jun 2009 19:08:42 GMT Received: from [127.0.0.1] by dhcp-161-44-173-229.cisco.com (PGP Universal service); Fri, 26 Jun 2009 15:08:42 -0400 X-PGP-Universal: processed; by dhcp-161-44-173-229.cisco.com on Fri, 26 Jun 2009 15:08:42 -0400 Message-Id: From: David R Oran To: Iljitsch van Beijnum In-Reply-To: Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 26 Jun 2009 15:08:27 -0400 References: <8239FE40-6544-4304-9C38-F08317CD3598@muada.com><69E254EE-C489-41C5-AA6B-6857B9EC8C56@americafree.tv><4F3B2C7A-AA49-43C8-8571-2807B9C339E9@muada.com> <6DF7ABCE-8DED-48B8-B545-DE383A4AB115@muada.com> <362FBC643A9148A28FC5B1E9F7D9B567@Honkin> X-Mailer: Apple Mail (2.935.3) X-PGP-Encoding-Format: MIME X-PGP-Encoding-Version: 2.0.2 Content-Type: multipart/signed; boundary="PGP_Universal_50C6CBFB_E6910DB0_965406B4_F0176E47"; protocol="application/pgp-signature"; micalg="pgp-sha1" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2195; t=1246043322; x=1246907322; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[homegate]=20Jumbo=20frames |Sender:=20 |To:=20Iljitsch=20van=20Beijnum=20; bh=958HJW/wNuTUJzlQp/TQOlNzAQjQj+MfiIeaP+omoCU=; b=Yvhmj99/EY5Vr2lcGNbU1B+fBks0cXXaKY7axoGNctpocOFbQ0WPNkJi8B CVUvp6G7NyjHaeesSuimH4dSotPggebA6QfTAbUIGswrfFcBN8l8nQOCz12O ZqaOqIrsXG; Authentication-Results: rtp-dkim-1; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 'Michael Johas Teener' , homegate@ietf.org Subject: Re: [homegate] Jumbo frames 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, 26 Jun 2009 19:08:35 -0000 --PGP_Universal_50C6CBFB_E6910DB0_965406B4_F0176E47 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jun 22, 2009, at 5:20 PM, Iljitsch van Beijnum wrote: > On 22 jun 2009, at 23:09, Richard Bennett wrote: > >> I'd like to remind people that frame size is a MAC protocol issue, >> and not >> something that the IETF needs to have a specific opinion about, >> beyond "be >> conservative in what you send and liberal in what you accept." > > The problem is that IP assumes that every subnet has a fixed MTU. > Since obviously the 1500-byte stuff isn't going anywhere, the > addition of jumboframe-capable hardware creates a problem, because > now we have systems with two (or more) different MTUs on a subnet, > which doesn't work in the general case although the TCP MSS option > hides a multitude of sins. (Not the sin of having a 1500-byte switch > sit between all the jumbo-capable systems, though.) > Which is one among many reasons we should be designing for multiple subnets on a single home network, instead of assuming the network is a single sea of L2 connectivity. > ((I keep telling people that RFC 894 (IP over ethernet) is an april > fools day RFC, published on april 1 1984, and we shouldn't take it > seriously but nobody listens.)) > >> If 802 >> permits or mandates support for jumbo frames, it will happen, and >> if they >> don't it probably won't. > > Also not exactly true. Like I wrote before, the same vendors that > make up IEEE 802.3 also build products that ignore the 1500-byte MTU > limit in 802.3. > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate --PGP_Universal_50C6CBFB_E6910DB0_965406B4_F0176E47 Content-Type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig Content-Disposition: attachment; filename=PGP.sig -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.10.0 (Build 500) iQA/AwUBSkUctI1mhLZU3SrmEQKYEgCgxgW5bdSvR3M7FoV3y7NV7ZZ9MTQAn1s+ DKUBN7DoYVkxqRoc5M8z/Wlk =SMiR -----END PGP SIGNATURE----- --PGP_Universal_50C6CBFB_E6910DB0_965406B4_F0176E47-- From richard@bennett.com Fri Jun 26 12:14:19 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 A50CB3A6949 for ; Fri, 26 Jun 2009 12:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 oe5aW870Xkkx for ; Fri, 26 Jun 2009 12:14:18 -0700 (PDT) Received: from outbound-mail-25.bluehost.com (outbound-mail-25.bluehost.com [69.89.21.20]) by core3.amsl.com (Postfix) with SMTP id BF7C63A6B00 for ; Fri, 26 Jun 2009 12:14:18 -0700 (PDT) Received: (qmail 12860 invoked by uid 0); 26 Jun 2009 19:14:15 -0000 Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy2.bluehost.com with SMTP; 26 Jun 2009 19:14:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:X-MimeOLE:X-Identified-User; b=hPs8htylLLx+yt4my/h8R5/G5Xynb3ANIWtbOVjB4DCHhEP5LxKLqgIgNiJOF17xluFJe/sesh7QsJvQmzfCYGXFnFn6XvHiyPwsXOIGEBYktUTJb5XYgRRUwfJ+6nfg; Received: from c-24-5-230-26.hsd1.ca.comcast.net ([24.5.230.26] helo=Honkin) by host46.hostmonster.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MKGsI-0001sq-RX; Fri, 26 Jun 2009 13:14:14 -0600 From: "Richard Bennett" To: "'David R Oran'" , "'Iljitsch van Beijnum'" References: <8239FE40-6544-4304-9C38-F08317CD3598@muada.com><69E254EE-C489-41C5-AA6B-6857B9EC8C56@americafree.tv><4F3B2C7A-AA49-43C8-8571-2807B9C339E9@muada.com> <6DF7ABCE-8DED-48B8-B545-DE383A4AB115@muada.com> <362FBC643A9148A28FC5B1E9F7D9B567@Honkin> In-Reply-To: Date: Fri, 26 Jun 2009 12:13:30 -0700 Organization: ITIF Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acn2kYbb404gCqBkQ1mQ3eT45j2usgAAKP1Q X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 24.5.230.26 authed with richard+bennett.com} Cc: 'Michael Johas Teener' , homegate@ietf.org Subject: Re: [homegate] Jumbo frames X-BeenThere: homegate@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: richard@bennett.com List-Id: Broadband Home Gateway Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 19:14:19 -0000 Good point. Richard Bennett -----Original Message----- From: David R Oran [mailto:oran@cisco.com] Sent: Friday, June 26, 2009 12:08 PM To: Iljitsch van Beijnum Cc: richard@bennett.com; 'Michael Johas Teener'; homegate@ietf.org Subject: Re: [homegate] Jumbo frames On Jun 22, 2009, at 5:20 PM, Iljitsch van Beijnum wrote: > On 22 jun 2009, at 23:09, Richard Bennett wrote: > >> I'd like to remind people that frame size is a MAC protocol issue, >> and not >> something that the IETF needs to have a specific opinion about, >> beyond "be >> conservative in what you send and liberal in what you accept." > > The problem is that IP assumes that every subnet has a fixed MTU. > Since obviously the 1500-byte stuff isn't going anywhere, the > addition of jumboframe-capable hardware creates a problem, because > now we have systems with two (or more) different MTUs on a subnet, > which doesn't work in the general case although the TCP MSS option > hides a multitude of sins. (Not the sin of having a 1500-byte switch > sit between all the jumbo-capable systems, though.) > Which is one among many reasons we should be designing for multiple subnets on a single home network, instead of assuming the network is a single sea of L2 connectivity. > ((I keep telling people that RFC 894 (IP over ethernet) is an april > fools day RFC, published on april 1 1984, and we shouldn't take it > seriously but nobody listens.)) > >> If 802 >> permits or mandates support for jumbo frames, it will happen, and >> if they >> don't it probably won't. > > Also not exactly true. Like I wrote before, the same vendors that > make up IEEE 802.3 also build products that ignore the 1500-byte MTU > limit in 802.3. > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate From iljitsch@muada.com Sun Jun 28 07:34:13 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 8BDB03A67AF for ; Sun, 28 Jun 2009 07:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 VZ9w13S4rKDc for ; Sun, 28 Jun 2009 07:34:12 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 919783A67AD for ; Sun, 28 Jun 2009 07:34:12 -0700 (PDT) Received: from [192.168.2.4] (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 n5SEY03m085572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Jun 2009 16:34:00 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <5F7D12CD-6AAA-4538-AADA-761DBA3BDCCE@muada.com> From: Iljitsch van Beijnum To: "Woundy, Richard" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 28 Jun 2009 16:33:35 +0200 References: X-Mailer: Apple Mail (2.935.3) Cc: homegate@ietf.org Subject: Re: [homegate] What's a "Home Gateway"? 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, 28 Jun 2009 14:34:13 -0000 On 25 jun 2009, at 17:47, Woundy, Richard wrote: > What problem are we trying to avoid here? Some customers already run > multiple cascading routers in the home on their own. The trouble with that is that if the ISP-provided gateway performs NAT this prevents the customer gateway from doing some useful things, such as opening up incoming ports or running 6to4. > What if the ISP router in the home supports IPv4 and IPv6 routing, > but the consumer router supports IPv4 routing and IPv6 bridging? It > seems like there could be a number of corner cases in which two > routers may make sense. It would be a completely legitimate choice to put the customer gateway in bridge mode. With IPv6, you could also have multiple cascading routers, for instance, one for an office network and one for visitors or some such. With IPv4 this is harder because the additional NAT layers can create problems. But the point is that ISPs provide cheap gateways, if the user chooses to invest in a better one it would be rather annyoing that this doesn't improve things because the limitations of the cheap gateway don't go away. From wbeebee@cisco.com Mon Jun 29 07:59:12 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 702873A67B5 for ; Mon, 29 Jun 2009 07:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 DGiT4XtFzxWR for ; Mon, 29 Jun 2009 07:59:11 -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 AC18328C0FD for ; Mon, 29 Jun 2009 07:58:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,309,1243814400"; d="scan'208";a="207044412" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 29 Jun 2009 14:59:05 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5TEx5e0025051; Mon, 29 Jun 2009 07:59:05 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5TEwj1H029189; Mon, 29 Jun 2009 14:59:05 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 10:59:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Jun 2009 10:59:04 -0400 Message-ID: In-Reply-To: <5F7D12CD-6AAA-4538-AADA-761DBA3BDCCE@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homegate] What's a "Home Gateway"? Thread-Index: Acn3/X4roF51t/i7QJKRapDF4ozIswAy1gVw References: <5F7D12CD-6AAA-4538-AADA-761DBA3BDCCE@muada.com> From: "Wes Beebee (wbeebee)" To: "Iljitsch van Beijnum" , "Woundy, Richard" X-OriginalArrivalTime: 29 Jun 2009 14:59:05.0461 (UTC) FILETIME=[25989A50:01C9F8CA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2353; t=1246287545; x=1247151545; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20 |Subject:=20RE=3A=20[homegate]=20What's=20a=20=22Home=20Gat eway=22? |Sender:=20; bh=Zy8L/I4q9f6dH+ax7ju0/1kcd+BEsuuUifK8t3hAFmI=; b=nxlwehKJV8oE5lK9m25GxlIr/OEbE8pyg68AcknYpN3RiPf1wdD09dblb+ xFDNtwwSGKJRSrGxW0lRoywhyXdUNOSncJI3Ygig+LkfLgYbTZeb8KxWlBxB WoR3wJElMIikpnK1xpNFF+dx83PzWSz5qC40JX5Xv2EwHtDoFIVmI=; Authentication-Results: sj-dkim-1; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: homegate@ietf.org Subject: Re: [homegate] What's a "Home Gateway"? 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, 29 Jun 2009 14:59:12 -0000 For instance, I recently debugged a family member's network that had a DSL NAT box with a DNS proxy and a gateway address of 192.168.1.1. A Wireless Access Point was put behind it, and also had a gateway address of 192.168.1.1, but had no DNS proxy. Since the name-server address was set to 192.168.1.1 by the DNS proxy, hosts behind both NAT boxes attempted to use 192.168.1.1 as the name server, and all DNS lookups went to the box without the DNS proxy, and failed. Therefore, they were unable to use DNS and therefore, could not browse the web. I solved the problem by assigning a different address to the inner NAT than the outer NAT - and all works well. Regarding other problems with additional NAT layers, we could design protocols that would allow the NATs to communicate to each other better to resolve difficulties. In other words, the problems can be solved without automatically turning one box into a bridge. - Wes -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 Sent: Sunday, June 28, 2009 10:34 AM To: Woundy, Richard Cc: Wes Beebee (wbeebee); homegate@ietf.org Subject: Re: [homegate] What's a "Home Gateway"? On 25 jun 2009, at 17:47, Woundy, Richard wrote: > What problem are we trying to avoid here? Some customers already run=20 > multiple cascading routers in the home on their own. The trouble with that is that if the ISP-provided gateway performs NAT this prevents the customer gateway from doing some useful things, such as opening up incoming ports or running 6to4. > What if the ISP router in the home supports IPv4 and IPv6 routing, but > the consumer router supports IPv4 routing and IPv6 bridging? It seems=20 > like there could be a number of corner cases in which two routers may=20 > make sense. It would be a completely legitimate choice to put the customer gateway in bridge mode. With IPv6, you could also have multiple cascading routers, for instance, one for an office network and one for visitors or some such. With IPv4 this is harder because the additional NAT layers can create problems. But the point is that ISPs provide cheap gateways, if the user chooses to invest in a better one it would be rather annyoing that this doesn't improve things because the limitations of the cheap gateway don't go away. From iljitsch@muada.com Mon Jun 29 08:02: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 F1CDB3A6774 for ; Mon, 29 Jun 2009 08:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 3jl3TSXz0xU7 for ; Mon, 29 Jun 2009 08:02:29 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id DA3E53A67B5 for ; Mon, 29 Jun 2009 08:02:28 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n5TF2YXN092466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Jun 2009 17:02:35 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <8423F865-6324-4B5B-93B2-86AF213158CF@muada.com> From: Iljitsch van Beijnum To: "Wes Beebee (wbeebee)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 29 Jun 2009 17:02:11 +0200 References: <5F7D12CD-6AAA-4538-AADA-761DBA3BDCCE@muada.com> X-Mailer: Apple Mail (2.935.3) Cc: "Woundy, Richard" , homegate@ietf.org Subject: Re: [homegate] What's a "Home Gateway"? 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, 29 Jun 2009 15:02:30 -0000 On 29 jun 2009, at 16:59, Wes Beebee (wbeebee) wrote: > In other words, the problems can be solved without automatically > turning > one box into a bridge. But why design new protocols while bridging has been around for a decade or two?