From lars@netapp.com Mon Mar 5 00:11:28 2012 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A594311E8094 for ; Mon, 5 Mar 2012 00:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWe3HZkcqLPl for ; Mon, 5 Mar 2012 00:11:27 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id B3D1011E8076 for ; Mon, 5 Mar 2012 00:11:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,532,1325491200"; d="p7s'?scan'208";a="630699351" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 05 Mar 2012 00:11:11 -0800 Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q258BAIO022489; Mon, 5 Mar 2012 00:11:11 -0800 (PST) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.92]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0247.003; Mon, 5 Mar 2012 00:11:10 -0800 From: "Eggert, Lars" To: "tsv-area@ietf.org" , "iccrg@cs.ucl.ac.uk" Subject: Fwd: [R-C] New Version Notification for draft-jesup-rtp-congestion-reqs-00.txt Thread-Topic: [R-C] New Version Notification for draft-jesup-rtp-congestion-reqs-00.txt Thread-Index: AQHM+qeGMtO1Xnu3hUGcSLhoezi+aw== Date: Mon, 5 Mar 2012 08:11:10 +0000 Message-ID: <13AA967B-CA65-4B41-B938-D36A1B6D7966@netapp.com> References: <4F537A24.5030001@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_21D078F8-5F44-40A3-90C3-FF3CFD34E545"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 08:11:28 -0000 --Apple-Mail=_21D078F8-5F44-40A3-90C3-FF3CFD34E545 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI. I believe this draft is of interest. Begin forwarded message: > From: Harald Alvestrand > Subject: [R-C] Fwd: New Version Notification for = draft-jesup-rtp-congestion-reqs-00.txt > Date: March 4, 2012 15:20:20 GMT+01:00 > To: "rtp-congestion@alvestrand.no" >=20 > And ... it's out! > Thanks for the quick feedback during the weekend! >=20 > Harald >=20 > -------- Original Message -------- > Subject: New Version Notification for = draft-jesup-rtp-congestion-reqs-00.txt > Date: Sun, 04 Mar 2012 06:19:29 -0800 > From: internet-drafts@ietf.org > To: harald@alvestrand.no > CC: randell-ietf@jesup.org >=20 >=20 >=20 > A new version of I-D, draft-jesup-rtp-congestion-reqs-00.txt has been = successfully submitted by Harald Alvestrand and posted to the IETF = repository. >=20 > Filename: draft-jesup-rtp-congestion-reqs > Revision: 00 > Title: Congestion Control Requirements For Real Time = Media > Creation date: 2012-03-04 > WG ID: Individual Submission > Number of pages: 7 >=20 > Abstract: > Congestion control is needed for all data transported across the > Internet, in order to promote fair usage and prevent congestion > collapse. The requirements for interactive, point-to-point real = time > multimedia, which needs by low-delay, semi-reliable data delivery, > are different from the requirements for bulk transfer like FTP or > bursty transfers like Web pages, and the TCP algorithms are not > suitable for this traffic. >=20 > This document attempts to describe a set of requirements that can be > used to evaluate other congestion control mechanisms in order to > figure out their fitness for this purpose. >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > Rtp-congestion mailing list > Rtp-congestion@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtp-congestion --Apple-Mail=_21D078F8-5F44-40A3-90C3-FF3CFD34E545 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMwNTA4MTExMVowIwYJKoZIhvcNAQkEMRYEFLYe tc8WXdsgwoThtYKfmOZtUKsAMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAFU2anrH nrfxfU9kY3UOlKZq/bzsbc1YO8Lk9ArCYfGvK+PiytPD5MG846aH1McJvFfz75YqyzO+tM6LI8sf P2k/GYivHIx6+drZK/nXKuj/TWDQgIkaFgvESYrmL3UAAYX4i6rU//BeYQkdJTMY1E4Zl7ausGBR ANOXZOYMMbTbjoWxcQ7SBtqMroE4MZ+yjp7TBvahTbPppckAUUlA916+AvPNEGxnveKCFa9Z0v/G 3qs6SVQwnF6Ms8sfhqQu6mu2kYtclPg7YTXeKXDHizHRiNii0tUF7ndw9P8cz26evIDYyq4U7qeY MfiXGnUsZsh4N/fi6n2kqG3xH9dtkZMAAAAAAAA= --Apple-Mail=_21D078F8-5F44-40A3-90C3-FF3CFD34E545-- From dwing@cisco.com Tue Mar 6 09:25:09 2012 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E793A21F8789; Tue, 6 Mar 2012 09:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.773 X-Spam-Level: X-Spam-Status: No, score=-108.773 tagged_above=-999 required=5 tests=[AWL=1.526, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYiiJiqFh+rO; Tue, 6 Mar 2012 09:25:08 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id ADF4D21F8733; Tue, 6 Mar 2012 09:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=6709; q=dns/txt; s=iport; t=1331054708; x=1332264308; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=zhTQr6vzhcvHC2g2qe48Q8IOmBkFcLZAbmiCPSH6tAw=; b=HqLfd4J6R8IuPkdJh6ianwOiWZj+q03ufrFALk7LOt02vKXOD6QZO+Pq X7ZStIt8ozXBZ03ffiGmqPvoTfO6IGSLT6oESZE36daqMdKqqcs0iZj+s RZguN7Hl0iExiZknxlNC1QUjWazteS1sUFsU9qiK4SFwXDgWYf+AWnsUC E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAN1HVk+rRDoI/2dsb2JhbABDpQSPaoEHgX0BAQEDAQgKARdPBQcBAwIJDwIEAQEoBxkjCgkIAgQBEgsXh2AEmkUBnxmQXgSIHzOFCpd5gwQ X-IronPort-AV: E=Sophos;i="4.73,540,1325462400"; d="scan'208";a="34678553" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 06 Mar 2012 17:25:08 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q26HP8V9029007; Tue, 6 Mar 2012 17:25:08 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'Alberto_Garc=EDa'?=" , "'IETF discussion list'" References: <023f01ccf756$e4d4a110$ae7de330$@com> <00ab01ccfbbb$7e7d0380$7b770a80$@it.uc3m.es> In-Reply-To: <00ab01ccfbbb$7e7d0380$7b770a80$@it.uc3m.es> Subject: RE: tsv-dir review of draft-garcia-shim6-applicability-03 Date: Tue, 6 Mar 2012 09:25:07 -0800 Message-ID: <07e001ccfbbe$13eaba50$3bc02ef0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQDWY9DRXMH2S1eCM54jIy0w4V/WFZhKmLgQgAAbKlA= Content-Language: en-us Cc: 'marcelo bagnulo braun' , joe.abley@icann.org, tsv-area@ietf.org, 'Transport Directorate' X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 17:25:10 -0000 > -----Original Message----- > From: Alberto Garc=EDa [mailto:alberto@it.uc3m.es] > Sent: Tuesday, March 06, 2012 9:07 AM > To: 'Dan Wing'; 'IETF discussion list' > Cc: 'Transport Directorate'; tsv-area@ietf.org; joe.abley@icann.org; > 'marcelo bagnulo braun' > Subject: RE: tsv-dir review of draft-garcia-shim6-applicability-03 >=20 > Hi Dan, > Thank you very much for your review >=20 > | -----Mensaje original----- > | De: Dan Wing [mailto:dwing@cisco.com] > | Enviado el: jueves, 01 de marzo de 2012 3:56 > | Para: 'IETF discussion list' > | CC: 'Transport Directorate'; tsv-area@ietf.org; = joe.abley@icann.org; > | 'marcelo bagnulo braun'; alberto@it.uc3m.es > | Asunto: tsv-dir review of draft-garcia-shim6-applicability-03 > | > | I have reviewed this document as part of the transport area > directorate's > | ongoing effort to review key IETF documents. These comments were > written > | primarily for the transport area directors, but are copied to the > document's > | authors for their information and to allow them to address any > issues > | raised. When done at the time of IETF Last Call, the authors should > consider > | this review together with any other last-call comments they = receive. > Please > | always CC tsv-dir@ietf.org if you reply to or forward this review. > | > | This draft is basically ready for publication, but has nits that > should > be fixed > | before publication. > | > | > | > | Nits: > | > | Section 1: > | > | Such problems are not specific of Shim6, but > | are suffered by the hosts of any site which is connected to > multiple > | transit providers, and which receives an IPv6 prefix from each = of > the > | providers. > | > | It might be useful to add a non-normative reference to RFC5220 at > the end > | of that sentence. > Ok >=20 > | > | > | Section 3.4: > | > | The use of HBA is more efficient in the sense that addresses > require > | less computation than CGA, involving only hash operations for > both > | the generation and the verification of locator sets. However, > the > | locators of an HBA set are determined during the generation > process, > | and cannot be subsequently changed; the addition of new locators > to > | that initial set is not supported, except by re-generation of = the > | entire set which will in turn cause all addresses to change. > | > | I think that paragraph is too harsh, as it implies the old = addresses > have > to be > | invalidated immediately. I expect existing connections could > continue > with > | the old addresses, and, if the host wanted to, could even have new > | connections use the old addresses. If that is not possible, the > draft > should > | explain why. If that is possible, the draft should probably = explain > it > is > | possible. > | >=20 > I have rewritten the paragraph: >=20 > "The use of HBA is more efficient in the sense that addresses > require > less computation than CGA, involving only hash operations for both > the generation and the verification of locator sets. However, the > locators of an HBA set are determined during the generation = process, > and cannot be subsequently changed; the addition of new locators to > that initial set is not supported. Therefore, a node using an HBA > as > ULID for a Shim6 session can only use the locators associated to > that > HBA for the considered Shim6 session. If the node wants to use a > new > set of locators, it has to generate a new HBA including the = prefixes > of the new locators (which will result with very high probability = in > different addresses to those of the previous set). New sessions > initiated with a ULID belonging to the new HBA address set could = use > the new locators." >=20 > Do you think it is now more clear? Yes, thanks. > | > | Section 4: > | > | In order to configure source and destination address selection, > tools > | such as DHCPv6 can be used to disseminate a [RFC3484] policy > table to > | a host. > | > | It might be useful to add a non-normative reference to draft-ietf- > 6man- > | addr-select-opt. > Sure >=20 > | > | > | Section 4: > | > | The sentence ending with "properties exhibited by REAP." needs a > reference > | to RFC5544, which seems to be the RFC defining REAP. > Ok >=20 > | > | > | > | Section 7.7, "Shim6 and IPv6 NAT", the problem could be overcome by > the > | Shim6 node knowing its IPv6 address after NPTv6 translation. > Probably > not > | worth adjusting the document, though, as NPTv6 is experimental. >=20 > Well, this would not work for HBA, since in this case the addresses = are > fixed once generated. NPTv6 does not change the host portion of the address (it only changes the network portion -- the IPv6 prefix), so HBA should work with NPTv6. > It could work for the CGA, since the Shim6 host could sign dynamically > the > translated address. But in this case a protocol would be needed to > convey > the translated address to the Shim6 node which has to sign it. A = threat > analysis of this operation should be performed, in order not to > introduce > new vulnerabilities in the process... > As you suggest, I think this is not worth. I agree, it can be discussed in a later document, should someone=20 find it useful to have Shim6 work with NPTv6. > | > | > | Section 7.7: > | > | Note that an Application Level Gateway designed to modify the > Shim6 > | control packets would not be able to generate a valid signature, > in > | case a CGA is being used, or a Parameter Data Structure binding > the > | translated locator to the other locators of a node, in case a = HBA > is > | being used. Therefore, the same failure cases described before > would > | remain. > | > | Applications are layer 7, Shim6 is layer 3, so an "Application = Layer > Gateway" > | that modifies Shim6 control packets seems an abuse of terminology. > | Suggest: > | > | OLD: > | Note that an Application Level Gateway designed to modify the > Shim6 > | control packets would not be able to generate a valid signature, > in > | NEW: > | Note that modification of the Shim6 control packets by the IPv6 > NAT > | > .............^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > | ^ > | would not be able to generate a valid signature, in >=20 > Changed. Thanks. -d > Thanks again, > Alberto >=20 > | > | -d > | > | > | > | > | > | > | From alberto@it.uc3m.es Tue Mar 6 09:06:41 2012 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C8D21F8714; Tue, 6 Mar 2012 09:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.069 X-Spam-Level: X-Spam-Status: No, score=-6.069 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4L30BgFCd3R; Tue, 6 Mar 2012 09:06:40 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDD221F8751; Tue, 6 Mar 2012 09:06:39 -0800 (PST) X-uc3m-safe: yes Received: from BOMBO (unknown [163.117.139.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 3CA137581EE; Tue, 6 Mar 2012 18:06:38 +0100 (CET) From: =?iso-8859-1?Q?Alberto_Garc=EDa?= To: "'Dan Wing'" , "'IETF discussion list'" References: <023f01ccf756$e4d4a110$ae7de330$@com> In-Reply-To: <023f01ccf756$e4d4a110$ae7de330$@com> Subject: RE: tsv-dir review of draft-garcia-shim6-applicability-03 Date: Tue, 6 Mar 2012 18:06:38 +0100 Message-ID: <00ab01ccfbbb$7e7d0380$7b770a80$@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDWY9DRXMH2S1eCM54jIy0w4V/WFZhKmLgQ Content-Language: es X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18758.000 X-Mailman-Approved-At: Wed, 07 Mar 2012 08:09:02 -0800 Cc: 'marcelo bagnulo braun' , joe.abley@icann.org, tsv-area@ietf.org, 'Transport Directorate' X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 17:06:41 -0000 Hi Dan, Thank you very much for your review | -----Mensaje original----- | De: Dan Wing [mailto:dwing@cisco.com] | Enviado el: jueves, 01 de marzo de 2012 3:56 | Para: 'IETF discussion list' | CC: 'Transport Directorate'; tsv-area@ietf.org; joe.abley@icann.org; | 'marcelo bagnulo braun'; alberto@it.uc3m.es | Asunto: tsv-dir review of draft-garcia-shim6-applicability-03 | | I have reviewed this document as part of the transport area directorate's | ongoing effort to review key IETF documents. These comments were written | primarily for the transport area directors, but are copied to the document's | authors for their information and to allow them to address any issues | raised. When done at the time of IETF Last Call, the authors should consider | this review together with any other last-call comments they receive. Please | always CC tsv-dir@ietf.org if you reply to or forward this review. | | This draft is basically ready for publication, but has nits that should be fixed | before publication. | | | | Nits: | | Section 1: | | Such problems are not specific of Shim6, but | are suffered by the hosts of any site which is connected to multiple | transit providers, and which receives an IPv6 prefix from each of the | providers. | | It might be useful to add a non-normative reference to RFC5220 at the end | of that sentence. Ok | | | Section 3.4: | | The use of HBA is more efficient in the sense that addresses require | less computation than CGA, involving only hash operations for both | the generation and the verification of locator sets. However, the | locators of an HBA set are determined during the generation process, | and cannot be subsequently changed; the addition of new locators to | that initial set is not supported, except by re-generation of the | entire set which will in turn cause all addresses to change. | | I think that paragraph is too harsh, as it implies the old addresses have to be | invalidated immediately. I expect existing connections could continue with | the old addresses, and, if the host wanted to, could even have new | connections use the old addresses. If that is not possible, the draft should | explain why. If that is possible, the draft should probably explain it is | possible. | I have rewritten the paragraph: "The use of HBA is more efficient in the sense that addresses require less computation than CGA, involving only hash operations for both the generation and the verification of locator sets. However, the locators of an HBA set are determined during the generation process, and cannot be subsequently changed; the addition of new locators to that initial set is not supported. Therefore, a node using an HBA as ULID for a Shim6 session can only use the locators associated to that HBA for the considered Shim6 session. If the node wants to use a new set of locators, it has to generate a new HBA including the prefixes of the new locators (which will result with very high probability in different addresses to those of the previous set). New sessions initiated with a ULID belonging to the new HBA address set could use the new locators." Do you think it is now more clear? | | Section 4: | | In order to configure source and destination address selection, tools | such as DHCPv6 can be used to disseminate a [RFC3484] policy table to | a host. | | It might be useful to add a non-normative reference to draft-ietf-6man- | addr-select-opt. Sure | | | Section 4: | | The sentence ending with "properties exhibited by REAP." needs a reference | to RFC5544, which seems to be the RFC defining REAP. Ok | | | | Section 7.7, "Shim6 and IPv6 NAT", the problem could be overcome by the | Shim6 node knowing its IPv6 address after NPTv6 translation. Probably not | worth adjusting the document, though, as NPTv6 is experimental. Well, this would not work for HBA, since in this case the addresses are fixed once generated. It could work for the CGA, since the Shim6 host could sign dynamically the translated address. But in this case a protocol would be needed to convey the translated address to the Shim6 node which has to sign it. A threat analysis of this operation should be performed, in order not to introduce new vulnerabilities in the process... As you suggest, I think this is not worth. | | | Section 7.7: | | Note that an Application Level Gateway designed to modify the Shim6 | control packets would not be able to generate a valid signature, in | case a CGA is being used, or a Parameter Data Structure binding the | translated locator to the other locators of a node, in case a HBA is | being used. Therefore, the same failure cases described before would | remain. | | Applications are layer 7, Shim6 is layer 3, so an "Application Layer Gateway" | that modifies Shim6 control packets seems an abuse of terminology. | Suggest: | | OLD: | Note that an Application Level Gateway designed to modify the Shim6 | control packets would not be able to generate a valid signature, in | NEW: | Note that modification of the Shim6 control packets by the IPv6 NAT | .............^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ^ | would not be able to generate a valid signature, in Changed. Thanks again, Alberto | | -d | | | | | | | From alberto@it.uc3m.es Wed Mar 7 02:02:23 2012 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C8621F87AD; Wed, 7 Mar 2012 02:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.135 X-Spam-Level: X-Spam-Status: No, score=-6.135 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUnXbeCnZdv7; Wed, 7 Mar 2012 02:02:22 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 6570221F87AB; Wed, 7 Mar 2012 02:02:22 -0800 (PST) X-uc3m-safe: yes Received: from BOMBO (unknown [163.117.139.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 0177EC28659; Wed, 7 Mar 2012 11:02:21 +0100 (CET) From: =?iso-8859-1?Q?Alberto_Garc=EDa?= To: "'Dan Wing'" , "'IETF discussion list'" References: <023f01ccf756$e4d4a110$ae7de330$@com> <00ab01ccfbbb$7e7d0380$7b770a80$@it.uc3m.es> <07e001ccfbbe$13eaba50$3bc02ef0$@com> In-Reply-To: <07e001ccfbbe$13eaba50$3bc02ef0$@com> Subject: RE: tsv-dir review of draft-garcia-shim6-applicability-03 Date: Wed, 7 Mar 2012 11:02:21 +0100 Message-ID: <000001ccfc49$640ae6f0$2c20b4d0$@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDWY9DRXMH2S1eCM54jIy0w4V/WFQFLnuCDAxpINIWYKIQl8A== Content-Language: es X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18758.003 X-Mailman-Approved-At: Wed, 07 Mar 2012 08:09:02 -0800 Cc: 'marcelo bagnulo braun' , joe.abley@icann.org, tsv-area@ietf.org, 'Transport Directorate' X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 10:02:23 -0000 Hi Dan, | > | Section 7.7, "Shim6 and IPv6 NAT", the problem could be overcome by | > the | > | Shim6 node knowing its IPv6 address after NPTv6 translation. | > Probably | > not | > | worth adjusting the document, though, as NPTv6 is experimental. | > | > Well, this would not work for HBA, since in this case the addresses | > are fixed once generated. | | NPTv6 does not change the host portion of the address (it only changes the | network portion -- the IPv6 prefix), so HBA should work with NPTv6. | Well, HBAs are built as a hash of many things, including the different prefixes for which you want to generate an address. Different interface identifiers are generated by changing the order in which the hash is performed. The issue with NPTv6 is that, in order to verify that the locator is a valid HBA, the receiver checks that the prefix of the locator is included in the HBA Parameter Data Structure, and then that the appropriate hash of the Parameter Data Structure corresponds to the interface identifier. If the NPTv6 changes the prefix, the first validation, the one regarding to the prefix, will fail, and HBAs will not work. Regards, Alberto From wes@mti-systems.com Mon Mar 26 00:34:22 2012 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C5721F84D9 for ; Mon, 26 Mar 2012 00:34:22 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wb6hzA3Txm21 for ; Mon, 26 Mar 2012 00:34:22 -0700 (PDT) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by ietfa.amsl.com (Postfix) with ESMTP id E38FA21F8454 for ; Mon, 26 Mar 2012 00:34:07 -0700 (PDT) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q2Q7Y7HN003424 for ; Mon, 26 Mar 2012 03:34:07 -0400 Authentication-Results: cm-omr3 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [94.75.220.77] ([94.75.220.77:45345] helo=[10.6.0.142]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id FA/84-29032-EEB107F4; Mon, 26 Mar 2012 03:34:07 -0400 Message-ID: <4F701BEB.9090400@mti-systems.com> Date: Mon, 26 Mar 2012 03:34:03 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: tsv-area@ietf.org, "tsv-ads@tools.ietf.org" Subject: TSV AD "office hours" @IETF83 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 07:34:22 -0000 We'll be having TSV AD "office hours" on Thursday 3/29 from 0800 - 0900 in Room 233M, in case there are things that you need to discuss with us in person and aren't able to pin us down any other time. -- Wes Eddy MTI Systems