From naiming@cisco.com Fri Mar 2 11:54:35 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5AA21F84E7 for ; Fri, 2 Mar 2012 11:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.565 X-Spam-Level: X-Spam-Status: No, score=-8.565 tagged_above=-999 required=5 tests=[AWL=2.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 dzYUwRkuS2ru for ; Fri, 2 Mar 2012 11:54:34 -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 34C3521F84E6 for ; Fri, 2 Mar 2012 11:54:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=naiming@cisco.com; l=8006; q=dns/txt; s=iport; t=1330718074; x=1331927674; h=from:mime-version:date:subject:references:to:message-id; bh=DT+qgm7Dy8Xl6E6kbobvzxu9ee5sW9fx7nsg/R2KaE8=; b=Iz1exdo0woPa90rkS888OOPm3LQxcKrFV8C0Yi8xVCaJWO/G3aLm7QFV MphDAtSQ9txVUc7jQWV6Mk3HhFArlE1TBSBaCmqdHm+CdFBbj6IgfnAoD lngF3QlSaSgxvSjoOE44Z/yMfLFidQpehK9UJFOQcepEEDx6Hl9P0moLZ k=; X-IronPort-AV: E=Sophos;i="4.73,519,1325462400"; d="scan'208,217";a="34022061" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 02 Mar 2012 19:54:34 +0000 Received: from [10.155.34.37] ([10.155.34.37]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q22JsYDZ007861; Fri, 2 Mar 2012 19:54:34 GMT From: Naiming Shen Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4-223555734 Date: Fri, 2 Mar 2012 11:54:33 -0800 References: <20120227213938.20370.68711.idtracker@ietfa.amsl.com> To: int-area@ietf.org Message-Id: <9C0C873C-D52F-4EC8-939C-FD2373FDC9ED@cisco.com> X-Mailer: Apple Mail (2.1084) Subject: [Int-area] Fwd: I-D Action: draft-shen-traceroute-ping-ext-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 19:54:35 -0000 --Apple-Mail-4-223555734 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, this is a new version of traneroute-ping-ext(-04) draft posted. there were many discussions of this draft(-03) on this list, and the = main concern was the scalability of the extension on the Internet and I think we got that. this new version has a couple of major changes: - a well-known UDP/TCP port and ID for icmp is added for this extension - the extension structure now starts at a fixed location in data field - added discussion section for design/impl/config part of this = extension please review and comment. thanks. - Naiming Begin forwarded message: > From: internet-drafts@ietf.org > Date: February 27, 2012 1:39:38 PM PST > To: i-d-announce@ietf.org > Subject: I-D Action: draft-shen-traceroute-ping-ext-04.txt > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Traceroute and Ping Message Extension > Author(s) : Naiming Shen > Carlos Pignataro > Rajiv Asati > Enke Chen > Alia K. Atlas > Filename : draft-shen-traceroute-ping-ext-04.txt > Pages : 12 > Date : 2012-02-27 >=20 > This document specifies extensions to traceroute and ping techniques > to convey additional application information to be carried in UDP, > TCP and ICMP traceroute probe messages and ICMP echo request and > reply messages. The extensions are backward compatible. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-shen-traceroute-ping-ext-04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-shen-traceroute-ping-ext-04.txt >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-4-223555734 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Date: February 27, 2012 1:39:38 PM PST
Subject: I-D Action: = draft-shen-traceroute-ping-ext-04.txt
Reply-To: internet-drafts@ietf.org
<= /span>


A New Internet-Draft is available from the = on-line Internet-Drafts directories.

Title =           : Traceroute = and Ping Message Extension
Author(s) =       : Naiming Shen
=             &n= bsp;           &nbs= p;Carlos Pignataro
=             &n= bsp;           &nbs= p;Rajiv Asati
=             &n= bsp;           &nbs= p;Enke Chen
=             &n= bsp;           &nbs= p;Alia K. Atlas
Filename =        : = draft-shen-traceroute-ping-ext-04.txt
Pages =           : = 12
= Date =            : = 2012-02-27

  This document specifies extensions to = traceroute and ping techniques
  to convey additional = application information to be carried in UDP,
  TCP and = ICMP traceroute probe messages and ICMP echo request and
=   reply messages.  The extensions are backward = compatible.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shen-traceroute-ping-ex= t-04.txt

Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft = can be retrieved = at:
ftp://ftp.ietf.org/internet-drafts/draft-shen-traceroute-ping-ext-0= 4.txt

_______________________________________________
I-D-Announ= ce mailing = list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

= = --Apple-Mail-4-223555734-- From lars@netapp.com Sat Mar 3 00:56:03 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B7521F86F0 for ; Sat, 3 Mar 2012 00:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.377 X-Spam-Level: X-Spam-Status: No, score=-10.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 l+TMlgrCkt3w for ; Sat, 3 Mar 2012 00:56:03 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5B621F86EF for ; Sat, 3 Mar 2012 00:56:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,525,1325491200"; d="p7s'?scan'208";a="630374755" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 03 Mar 2012 00:55:46 -0800 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q238tkp7012432; Sat, 3 Mar 2012 00:55:46 -0800 (PST) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.92]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0247.003; Sat, 3 Mar 2012 00:54:53 -0800 From: "Eggert, Lars" To: Naiming Shen Thread-Topic: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-04.txt Thread-Index: AQHM+Rtrgvojn5f6E0aFnPeUKN41pQ== Date: Sat, 3 Mar 2012 08:55:45 +0000 Message-ID: <709D93F8-C6C0-4F7D-A823-35540D683EE6@netapp.com> References: <20120227213938.20370.68711.idtracker@ietfa.amsl.com> <9C0C873C-D52F-4EC8-939C-FD2373FDC9ED@cisco.com> In-Reply-To: <9C0C873C-D52F-4EC8-939C-FD2373FDC9ED@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/signed; boundary="Apple-Mail=_F6582E1C-3217-4CFB-BCF8-FCBBE1355B74"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 08:56:03 -0000 --Apple-Mail=_F6582E1C-3217-4CFB-BCF8-FCBBE1355B74 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > 8. IANA Considerations >=20 > The IANA is requested to assign a well-known port number, = Trace-Ping > Port, for the UDP and TCP of this Trace-Ping extensions. I'm curious why you think you need a port number for this ping = extension. Ping is a diagnostic procedure that can be used with any = port, and placing payload into the packet sent to elicit the ICMP = response doesn't change that. In other words, ping isn't a protocol. Also, with regards to TCP ping, do you envision your payload data to be = placed inside the SYN? Lars= --Apple-Mail=_F6582E1C-3217-4CFB-BCF8-FCBBE1355B74 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMwMzA4NTU0NVowIwYJKoZIhvcNAQkEMRYEFBH9 1s6sQ7aNAWYJmBOX62RMWqGOMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAEknoxW1 G7AbEp5yOti39kPk5e9f/s97XoSkuzsei6gXk8TUE6m3h9+i5zHWMMhUIqHPmkLhWHueYdicQD3o 2cTllXmlAcQpL0zSrrJJWeGWX5RtOmOlTiUDvMzuRmtI/xF5GoNQgwaf7JejwCeWXKUdk8lacAkR yOi8DhI2Hc8rOahq2wm/jgM/A0cr4dsRtMIysOcFaMLAoSkc6vyls+NobnB52tZvT8WsoIMpYFyg KpBGdrmCuw3X20W4XDj+le2L1X42FxdY8+QpuSWQb2cu1Wb7rv7T8T9Im+Dk3Af2aRjETrxckILI mEV5wjTOf7FbEbSH87CVDBnkR2SgOMsAAAAAAAA= --Apple-Mail=_F6582E1C-3217-4CFB-BCF8-FCBBE1355B74-- From naiming@cisco.com Mon Mar 5 14:31:46 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C5F21E8050 for ; Mon, 5 Mar 2012 14:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.373 X-Spam-Level: X-Spam-Status: No, score=-8.373 tagged_above=-999 required=5 tests=[AWL=1.626, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] 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 ccHmd4O4y0of for ; Mon, 5 Mar 2012 14:31:46 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 12CAA21E804E for ; Mon, 5 Mar 2012 14:31:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=naiming@cisco.com; l=1060; q=dns/txt; s=iport; t=1330986706; x=1332196306; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=rDBCTr4Jh0K2egsYBGHL/bd9g/XDQ2gY/iQmwHBRMEY=; b=bwuD6EWjDSs2AfUAuBN8y10rXlGFaV9Y9U/F93gLjoFmLP+b7MF26Igw 6iSYnX76gUr0VJ5r6Lf3O/oeI33pMAa92H8TMKVv4rnOCnIjLbZoCZA+0 E1S9r2srO4j14qZ7qxTIamZYIuOFRVqnKgHuVW5DEXfny58gzb2OI7Ooj 8=; X-IronPort-AV: E=Sophos;i="4.73,536,1325462400"; d="scan'208";a="34668122" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 05 Mar 2012 22:31:46 +0000 Received: from [10.155.34.37] ([10.155.34.37]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q25MVj2R002770; Mon, 5 Mar 2012 22:31:45 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Naiming Shen In-Reply-To: <709D93F8-C6C0-4F7D-A823-35540D683EE6@netapp.com> Date: Mon, 5 Mar 2012 14:31:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4705AE0F-CAE1-46D9-84D5-AF6D11BD35BC@cisco.com> References: <20120227213938.20370.68711.idtracker@ietfa.amsl.com> <9C0C873C-D52F-4EC8-939C-FD2373FDC9ED@cisco.com> <709D93F8-C6C0-4F7D-A823-35540D683EE6@netapp.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.1084) Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 22:31:47 -0000 Hi Lars, On Mar 3, 2012, at 12:55 AM, Eggert, Lars wrote: > Hi, >=20 >> 8. IANA Considerations >>=20 >> The IANA is requested to assign a well-known port number, = Trace-Ping >> Port, for the UDP and TCP of this Trace-Ping extensions. >=20 > I'm curious why you think you need a port number for this ping = extension. Ping is a diagnostic procedure that can be used with any = port, and placing payload into the packet sent to elicit the ICMP = response doesn't change that. Yes, I understand Ping can use any port(or Identifier as in this draft). = But it's rate-limited also randomly by routers on the Internet. This well-known port/id can = signal a new service for the network, and can be subject to different filtering profile. >=20 > In other words, ping isn't a protocol. >=20 > Also, with regards to TCP ping, do you envision your payload data to = be placed inside the SYN? Yes for syn or ack. The tcp server should not care about the length = being zero or not though. thanks. - Naiming >=20 > Lars From lars@netapp.com Mon Mar 5 22:50:59 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5224021F86E0 for ; Mon, 5 Mar 2012 22:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.074 X-Spam-Level: X-Spam-Status: No, score=-10.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] 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 kNnnJSbwJCWG for ; Mon, 5 Mar 2012 22:50:58 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id C528E21F86D1 for ; Mon, 5 Mar 2012 22:50:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,538,1325491200"; d="p7s'?scan'208";a="631004388" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 05 Mar 2012 22:50:58 -0800 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q266owLB027925; Mon, 5 Mar 2012 22:50:58 -0800 (PST) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.92]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0247.003; Mon, 5 Mar 2012 22:50:57 -0800 From: "Eggert, Lars" To: Naiming Shen Thread-Topic: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-04.txt Thread-Index: AQHM+Rtrgvojn5f6E0aFnPeUKN41pZZc02KAgACLeQA= Date: Tue, 6 Mar 2012 06:50:57 +0000 Message-ID: <2C2F2761-E2BD-4E55-97F3-4E5B3155A3BB@netapp.com> References: <20120227213938.20370.68711.idtracker@ietfa.amsl.com> <9C0C873C-D52F-4EC8-939C-FD2373FDC9ED@cisco.com> <709D93F8-C6C0-4F7D-A823-35540D683EE6@netapp.com> <4705AE0F-CAE1-46D9-84D5-AF6D11BD35BC@cisco.com> In-Reply-To: <4705AE0F-CAE1-46D9-84D5-AF6D11BD35BC@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/signed; boundary="Apple-Mail=_9B0CEF49-F3D6-4B45-AADC-051F693CFB3D"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 06:50:59 -0000 --Apple-Mail=_9B0CEF49-F3D6-4B45-AADC-051F693CFB3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On Mar 5, 2012, at 23:31, Naiming Shen wrote: > On Mar 3, 2012, at 12:55 AM, Eggert, Lars wrote: >>> 8. IANA Considerations >>>=20 >>> The IANA is requested to assign a well-known port number, = Trace-Ping >>> Port, for the UDP and TCP of this Trace-Ping extensions. >>=20 >> I'm curious why you think you need a port number for this ping = extension. Ping is a diagnostic procedure that can be used with any = port, and placing payload into the packet sent to elicit the ICMP = response doesn't change that. >=20 > Yes, I understand Ping can use any port(or Identifier as in this = draft). But it's rate-limited > also randomly by routers on the Internet. This well-known port/id can = signal a new service > for the network, and can be subject to different filtering profile. Clarification: you mean that the *generation* of ICMP messages at = routers is rate-limited, correct? And the hope is that if the packets = eliciting ICMP responses contained a transport packet with a certain = source or destination port, the router would apply a more lenient rate = limit when generating ICMP responses for those packets. Is this realistic? I'm not a router guy, but I thought routers = rate-limit the generation of ICMP messages because it involves slow-path = processing. In your scheme, a router would need to further DPI packets = that may cause ICMP responses in order to determine what rate limit to = apply, requiring even more processing. Doesn't that kind of defeat the = purpose? In addition, eyeball ISPs would need to filter that port at the boundary = to prevent the clients from using it, too, which again complicates = things. Because once you set up more lenient rate limits for ICMPs for a = given port, you can be sure that clients would start using that port, = too. >> Also, with regards to TCP ping, do you envision your payload data to = be placed inside the SYN? >=20 > Yes for syn or ack. The tcp server should not care about the length = being zero or not though. I don't understand what you mean by "length being zero." Could you = elaborate? Thanks, Lars= --Apple-Mail=_9B0CEF49-F3D6-4B45-AADC-051F693CFB3D 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMwNjA2NTA1N1owIwYJKoZIhvcNAQkEMRYEFPIA 3UOgDHveEbeEIFivq2JoVPTyMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBADxkOYNr i5pGxn3lspEmMa+f/cguK66VhKenRYK9pKMytnpwhOVdieaiipuE0sQZE6OH85eMoyCFS8SU5bEp mC243wkl3E7XqdBcVhWUCZAxu+/+sFLEm8Gno9bPkrDy2cAvj7sAdj4icN9zfaeWjnqUUqZK6jOU JutyYxqXOgJKcBYoTqs9vhkQOK4+gFCITCsPDS7Z9GsrSRsaWlteijZFgy/XpNxohkmDoi/HzMkr IEq8kNoTwhNU9TKVOAi+WZLjE215hkCg85vPDRWxuEh8dijBIPjwk+SEGatWaQnEoG0JrRDrhEo6 vJKCtGMPat8Re6t+/a7ItTAZYPUI3AwAAAAAAAA= --Apple-Mail=_9B0CEF49-F3D6-4B45-AADC-051F693CFB3D-- From naiming@cisco.com Mon Mar 5 23:46:31 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AAD21F85E4 for ; Mon, 5 Mar 2012 23:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.854 X-Spam-Level: X-Spam-Status: No, score=-7.854 tagged_above=-999 required=5 tests=[AWL=0.945, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] 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 XJ2mEFk2FQeF for ; Mon, 5 Mar 2012 23:46:31 -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 1A88C21F85BB for ; Mon, 5 Mar 2012 23:46:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=naiming@cisco.com; l=3923; q=dns/txt; s=iport; t=1331019991; x=1332229591; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tIfv7tp2XOI1pZENISn65wcaHfMndSLmNA8XwXGcboo=; b=eCYiAPVQCN94KB8wbyV1zpEsUOBH++hxhCwgDK6UaQLKnb8l/tJJ8MaA Sxx6PCdyw8yhH1xvjiohyDwbefI61AGd8SRsAm/oL4+ZWgcXXPYiMKKWZ SMQmQjmcpuolUHkVE5bgl7XHlX0yjUNOU8UHBUcq2EaKHaIElJZKkK0GH o=; X-IronPort-AV: E=Sophos;i="4.73,539,1325462400"; d="scan'208";a="34610716" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 06 Mar 2012 07:46:30 +0000 Received: from sjc-vpn3-470.cisco.com (sjc-vpn3-470.cisco.com [10.21.65.214]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q267kUua009602; Tue, 6 Mar 2012 07:46:30 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Naiming Shen In-Reply-To: <2C2F2761-E2BD-4E55-97F3-4E5B3155A3BB@netapp.com> Date: Mon, 5 Mar 2012 23:46:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120227213938.20370.68711.idtracker@ietfa.amsl.com> <9C0C873C-D52F-4EC8-939C-FD2373FDC9ED@cisco.com> <709D93F8-C6C0-4F7D-A823-35540D683EE6@netapp.com> <4705AE0F-CAE1-46D9-84D5-AF6D11BD35BC@cisco.com> <2C2F2761-E2BD-4E55-97F3-4E5B3155A3BB@netapp.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.1084) Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 07:46:32 -0000 Hi Lars, On Mar 5, 2012, at 10:50 PM, Eggert, Lars wrote: > Hi, >=20 > On Mar 5, 2012, at 23:31, Naiming Shen wrote: >> On Mar 3, 2012, at 12:55 AM, Eggert, Lars wrote: >>>> 8. IANA Considerations >>>>=20 >>>> The IANA is requested to assign a well-known port number, = Trace-Ping >>>> Port, for the UDP and TCP of this Trace-Ping extensions. >>>=20 >>> I'm curious why you think you need a port number for this ping = extension. Ping is a diagnostic procedure that can be used with any = port, and placing payload into the packet sent to elicit the ICMP = response doesn't change that. >>=20 >> Yes, I understand Ping can use any port(or Identifier as in this = draft). But it's rate-limited >> also randomly by routers on the Internet. This well-known port/id can = signal a new service >> for the network, and can be subject to different filtering profile. >=20 > Clarification: you mean that the *generation* of ICMP messages at = routers is rate-limited, correct? And the hope is that if the packets = eliciting ICMP responses contained a transport packet with a certain = source or destination port, the router would apply a more lenient rate = limit when generating ICMP responses for those packets. The previous version of this draft didn't have this well-known port = defined, and we got many comments on how to distinguish the packets with new features from = the general traceroute/ping packets on the Internet, as you mentioned below, it = needs more deeper packet inspection. With this well-known port, a provider's internal use = of certain feature with this extension can be more easily sort out from normal trace/ping = packets (before the deeper packet inspection). >=20 > Is this realistic? I'm not a router guy, but I thought routers = rate-limit the generation of ICMP messages because it involves slow-path = processing. In your scheme, a router would need to further DPI packets = that may cause ICMP responses in order to determine what rate limit to = apply, requiring even more processing. Doesn't that kind of defeat the = purpose? It requires more processing since if there is a new service using this = extension, then the packets need more processing. But those extra processing will not be imposed on the "normal" = trace/ping packets. The well-known port here is to distinguish those two types. rate-limit is just an example of implementation related to this. icmp or = trace ratelimit is to protect the slow path, or even when the replies are done on the LC(fast path), they are = normally rate-limited. If this extension for example, at the router inbound it detects the packet with this = well-known port, it can hand it to that feature processing to run through an ACL (e.g. the configure requires the features only be = allowed from their mgmt station subnets), if all is well, then punt the packet to the feature = handling(the slow path) with its own rate-limit. >=20 > In addition, eyeball ISPs would need to filter that port at the = boundary to prevent the clients from using it, too, which again = complicates things. Because once you set up more lenient rate limits for = ICMPs for a given port, you can be sure that clients would start using = that port, too. I agree. This draft also has a section on the scalability of = implementation and configuration. Usually the features should be enabled with configuration and also = filtering along with it. >=20 >>> Also, with regards to TCP ping, do you envision your payload data to = be placed inside the SYN? >>=20 >> Yes for syn or ack. The tcp server should not care about the length = being zero or not though. >=20 > I don't understand what you mean by "length being zero." Could you = elaborate? I meant the TCP payload length of the SYN packet doesn't have to be = zero. thanks. - Naiming >=20 > Thanks, > Lars From internet-drafts@ietf.org Tue Mar 6 06:38:22 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B77C21F8939; Tue, 6 Mar 2012 06:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, 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 FsEnWsi5Luiy; Tue, 6 Mar 2012 06:38:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F7721F8864; Tue, 6 Mar 2012 06:37:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120306143757.1843.17345.idtracker@ietfa.amsl.com> Date: Tue, 06 Mar 2012 06:37:57 -0800 Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-01.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 14:38:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Area Working Group Working G= roup of the IETF. Title : Analysis of Solution Candidates to Reveal a Host Identif= ier in Shared Address Deployments Author(s) : Mohamed Boucadair Joe Touch Pierre Levis Reinaldo Penno Filename : draft-ietf-intarea-nat-reveal-analysis-01.txt Pages : 20 Date : 2012-03-06 This document analyzes a set of solution candidates to mitigate some of the issues encountered when address sharing is used. In particular, this document focuses on means to reveal a host identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier must be unique to each host under the same shared IP address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-intarea-nat-reveal-analysis-= 01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-intarea-nat-reveal-analysis-0= 1.txt From mohamed.boucadair@orange.com Tue Mar 6 06:46:02 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62CA21F8826 for ; Tue, 6 Mar 2012 06:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 Go6ZKBFhH0T1 for ; Tue, 6 Mar 2012 06:46:02 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 314D621F886F for ; Tue, 6 Mar 2012 06:46:02 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id F1E6F3B4435 for ; Tue, 6 Mar 2012 15:46:00 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 9457227C095 for ; Tue, 6 Mar 2012 15:46:00 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Tue, 6 Mar 2012 15:46:00 +0100 From: To: "int-area@ietf.org" Date: Tue, 6 Mar 2012 15:45:58 +0100 Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-01.txt Thread-Index: Acz7ps0MeKpNytpDSFiIKu6bAfXgKQAAI3kw Message-ID: <94C682931C08B048B7A8645303FDC9F36748838228@PUEXCB1B.nanterre.francetelecom.fr> References: <20120306143757.1843.17345.idtracker@ietfa.amsl.com> In-Reply-To: <20120306143757.1843.17345.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.6.121218 Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-01.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 14:46:03 -0000 Dear WG, Changes since -00 are:=20 * Add a reference to RFC6462 as requested by S. Brim * Add a new section describing a ICMP-based proposal * Update the comparison table A diff is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-int= area-nat-reveal-analysis-01 Cheers, Med =20 > -----Message d'origine----- > De : int-area-bounces@ietf.org=20 > [mailto:int-area-bounces@ietf.org] De la part de=20 > internet-drafts@ietf.org > Envoy=E9 : mardi 6 mars 2012 15:38 > =C0 : i-d-announce@ietf.org > Cc : int-area@ietf.org > Objet : [Int-area] I-D Action:=20 > draft-ietf-intarea-nat-reveal-analysis-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. This draft is a work item of the=20 > Internet Area Working Group Working Group of the IETF. >=20 > Title : Analysis of Solution Candidates to=20 > Reveal a Host Identifier in Shared Address Deployments > Author(s) : Mohamed Boucadair > Joe Touch > Pierre Levis > Reinaldo Penno > Filename : draft-ietf-intarea-nat-reveal-analysis-01.txt > Pages : 20 > Date : 2012-03-06 >=20 > This document analyzes a set of solution candidates to=20 > mitigate some > of the issues encountered when address sharing is used. In > particular, this document focuses on means to reveal a host > identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application > proxies are involved in the path. This host identifier must be > unique to each host under the same shared IP address. >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-intarea-nat-rev > eal-analysis-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-intarea-nat-reve > al-analysis-01.txt >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > = From sarikaya2012@gmail.com Tue Mar 6 08:57:49 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1283D21F8751 for ; Tue, 6 Mar 2012 08:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 QjaHQ8pMZ4Jc for ; Tue, 6 Mar 2012 08:57:48 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 78F9B21F85F3 for ; Tue, 6 Mar 2012 08:57:48 -0800 (PST) Received: by ggmi1 with SMTP id i1so2645904ggm.31 for ; Tue, 06 Mar 2012 08:57:48 -0800 (PST) Received-SPF: pass (google.com: domain of sarikaya2012@gmail.com designates 10.101.6.38 as permitted sender) client-ip=10.101.6.38; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sarikaya2012@gmail.com designates 10.101.6.38 as permitted sender) smtp.mail=sarikaya2012@gmail.com; dkim=pass header.i=sarikaya2012@gmail.com Received: from mr.google.com ([10.101.6.38]) by 10.101.6.38 with SMTP id j38mr10642539ani.11.1331053068163 (num_hops = 1); Tue, 06 Mar 2012 08:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=iehNE+GF8iPG/hiRnP5UCuXh+rSpFdgbSWv2GGFpUy4=; b=zM2N3MVHeJ0p/oP65XpHnA/7YZcAfvRb6zYi3vScndgvlEaFO9nfuNtLro71YtOCjN LKViHdvB2OPgug9lNVlFTwkPngx2CzzFmdV46Hu4E6Ty45ktNzcyvbRVGxdkz1t29FU7 Ma5jW4quLZI8J05phQd18di6qLc2Pu0rOfwD5a2w7fdyQkar4v+rl+99vYIyPFZ86VV6 tQFURjrn4XfhoUUv7QMQ4gK1tqUym2nYqYgfhELxXD5oryF3Pb0LRb1YkkeKyj/cFfec d0PKDB+L5pEoNsT7tWE4Spi7jvFwQlqEnp/W1EgFUu3wR9CMC20qkGO0crcx6b5Kxq5C eabg== MIME-Version: 1.0 Received: by 10.101.6.38 with SMTP id j38mr8428996ani.11.1331053068104; Tue, 06 Mar 2012 08:57:48 -0800 (PST) Received: by 10.236.9.73 with HTTP; Tue, 6 Mar 2012 08:57:48 -0800 (PST) Date: Tue, 6 Mar 2012 10:57:48 -0600 Message-ID: From: Behcet Sarikaya To: Internet Area Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dirk.von-Hugo@telekom.de Subject: [Int-area] FMC PS Draft and Bar BoF X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:57:49 -0000 Hi all, FMC Problem Statement draft draft-xue-intarea-fmc-ps-00.txt has been submitted as below. We also requested a slot for holding FMC Bar Bof tentatively on Tuesday, March 28 at 19:30. If you have a presentation to make please drop a note to us. Regards, Behcet & Dirk A new version of I-D, draft-xue-intarea-fmc-ps-00.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-xue-intarea-fmc-ps Revision: =A0 =A0 =A0 =A000 Title: =A0 =A0 =A0 =A0 =A0 Problem Statement for Fixed Mobile Convergence Creation date: =A0 2012-03-02 WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission Number of pages: 20 Abstract: =A0 The purpose of this document is to analyze the issues that have =A0 arisen so far and then to propose a set of requirements for the Fixed =A0 Mobile Convergence. =A0The term Fixed Mobile Convergence spans several =A0 scenarios from true integration of fixed and mobile terminals, =A0 services, and network infrastructure on both technical and management =A0 level down to pure interworking between fixed and mobile networks in =A0 serving access for multi-interface terminals like todays' =A0 smartphones. =A0In the interworking scenario, the mobile network passes =A0 on the mobile subscribers policies to the fixed broadband network in =A0 order to maintain the end-to-end service level agreement and to =A0 support remote terminal and access network management. =A0Explicitly, =A0 the fixed broadband network must have partnership with the mobile =A0 network in Fixed Mobile Convergence interworking scenario. =A0This =A0 document gives a brief overview of the assumed Fixed Mobile =A0 Convergence architecture and related works and then introduces =A0 several requirements based on the partnership in Fixed Mobile =A0 Convergence architecture, such as User Equipment identification and =A0 authentication, Femto Access Point management, device type =A0 identification and mobility considerations. The IETF Secretariat From richard.kelsey@ember.com Wed Mar 7 08:25:38 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD03F21F8637 for ; Wed, 7 Mar 2012 08:25:38 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDux9LQlmBwT for ; Wed, 7 Mar 2012 08:25:38 -0800 (PST) Received: from p01c11o143.mxlogic.net (p01c11o143.mxlogic.net [208.65.144.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE6D21F8636 for ; Wed, 7 Mar 2012 08:25:38 -0800 (PST) Received: from unknown [216.236.254.3] (EHLO p01c11o143.mxlogic.net) by p01c11o143.mxlogic.net(mxl_mta-6.13.0-2) with ESMTP id 20c875f4.6c777940.116457.00-563.263527.p01c11o143.mxlogic.net (envelope-from ); Wed, 07 Mar 2012 09:25:38 -0700 (MST) X-MXL-Hash: 4f578c02185daf99-a6666084ca09b52168d725ffba2cad19c07949f4 Received: from unknown [216.236.254.3] (EHLO usmail.ember.com) by p01c11o143.mxlogic.net(mxl_mta-6.13.0-2) over TLS secured channel with ESMTP id efb875f4.0.116431.00-295.263458.p01c11o143.mxlogic.net (envelope-from ); Wed, 07 Mar 2012 09:25:37 -0700 (MST) X-MXL-Hash: 4f578c014b709a28-e07fa6fa50f0a40e0fe184ff1220ff887f99e2ce Received: from kelsey-ws.hq.ember.com (192.168.81.75) by usmail.ember.com (192.168.80.105) with Microsoft SMTP Server id 14.1.355.2; Wed, 7 Mar 2012 11:26:09 -0500 Date: Wed, 7 Mar 2012 11:27:14 -0500 Message-ID: <87ipigwf4t.fsf@kelsey-ws.hq.ember.com> To: Suresh Krishnan In-Reply-To: <4F443861.8050708@ericsson.com> (message from Suresh Krishnan on Tue, 21 Feb 2012 19:35:45 -0500) From: Richard Kelsey X-Auto-Response-Suppress: DR, OOF, AutoReply References: <4F443861.8050708@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [192.168.81.75] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [216.236.254.3] X-AnalysisOut: [v=1.0 c=1 a=u0NvnAFnSA0A:10 a=LJGLfXLATLkA:10 a=saA6nF2ZJa] X-AnalysisOut: [AA:10 a=BLceEmwcHowA:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=0F] X-AnalysisOut: [D05c-RAAAA:8 a=YlVTAMxIAAAA:8 a=48vgC7mUAAAA:8 a=OErdhiOsz] X-AnalysisOut: [-wJu-rSXHsA:9 a=a7tKqvDWXLfARyQzYG4A:7 a=kkUMZHjH4KkA:10 a] X-AnalysisOut: [=f7GxY0FH8QIA:10 a=lZB815dzVvQA:10] Cc: int-area@ietf.org Subject: Re: [Int-area] Call for agenda items X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:25:39 -0000 Hello, I would like request a slot to present draft-kelsey-intarea-mesh-link-establishment. The draft describes a protocol for dynamically configuring links in an ad hoc wireless mesh network. The protocol bridges a gap between link layer standards, which typically deal with individual links, and IETF protocols, which assume that the links are up and running. The draft does not fit the charter of any active working group. I would like to present it to the intarea group in order to get a more thorough review that it would otherwise receive. This draft has not been presented to any other WG and will not be presented to any other WG at IETF 83. -Richard Kelsey > Date: Tue, 21 Feb 2012 19:35:45 -0500 > From: Suresh Krishnan > Received-SPF: Pass (p01c12m097.mxlogic.net: domain of ietf.org designates 12.22.58.30 as permitted sender) > > Hi all, > The intarea WG will be meeting in Paris (we have requested a 2 hour > slot) and we are in the process of setting the agenda. Please send us > your request for slots detailing > > * Name of the draft > * Short description of why you think the item needs to be discussed in > the intarea meeting > * Whether the draft has already been presented or will be presented in > some other wg/bof. > > Thanks > Julien and Suresh > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From touch@isi.edu Wed Mar 7 17:30:46 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E9821E8014 for ; Wed, 7 Mar 2012 17:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.948 X-Spam-Level: X-Spam-Status: No, score=-102.948 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, 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 k3E0QaGk69ac for ; Wed, 7 Mar 2012 17:30:45 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id D6AD421E8011 for ; Wed, 7 Mar 2012 17:30:45 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q281Tx6E022759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Mar 2012 17:29:59 -0800 (PST) Message-ID: <4F580B97.1070401@isi.edu> Date: Wed, 07 Mar 2012 17:29:59 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Naiming Shen References: <20120227213938.20370.68711.idtracker@ietfa.amsl.com> <9C0C873C-D52F-4EC8-939C-FD2373FDC9ED@cisco.com> <709D93F8-C6C0-4F7D-A823-35540D683EE6@netapp.com> <4705AE0F-CAE1-46D9-84D5-AF6D11BD35BC@cisco.com> <2C2F2761-E2BD-4E55-97F3-4E5B3155A3BB@netapp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 01:30:46 -0000 Hi, all, On 3/5/2012 11:46 PM, Naiming Shen wrote: ... > The previous version of this draft didn't have this well-known port defined, and we got > many comments on how to distinguish the packets with new features from the general > traceroute/ping packets on the Internet, as you mentioned below, it needs more deeper > packet inspection. With this well-known port, a provider's internal use of certain feature with > this extension can be more easily sort out from normal trace/ping packets (before the deeper > packet inspection). A ping (ICMP echo request) message has no port. It has an Identifier field that is used "like a port in TCP or UDP to identify a session" [RFC792], but it identifies a session not a protocol. I.e., it should change for subsequent echo requests, so this should not be fixed at a specific value. Traceroute uses ICMP with varying TTLs, so a port number is equally meaningless there. Sec 5 of this doc redefines how ping works - when it reaches the valid destination, an echo response is sent back. That's how ping knows it works, and how traceroute knows to stop. If you intend on using these inside UDP or TCP segments, you need to be much more specific about what you mean by 'traceroute/ping' - notably, citing an RFC or other spec on the variant you're using. However, it would be important to first make the case that this information is relevant for those protocols. However, why would you then want to limit those protocols to a specific UDP or TCP port number? their value is in being used to test various port numbers that are blocked (or not) along various paths - e.g., to find out that HTTP isn't blocked all the way to a destination, or if so on what hop. Joe From ulrich@herberg.name Wed Mar 7 19:10:48 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0802F21E8029 for ; Wed, 7 Mar 2012 19:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 twzV+MnjDnLt for ; Wed, 7 Mar 2012 19:10:47 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 143D121E800F for ; Wed, 7 Mar 2012 19:10:47 -0800 (PST) Received: by pbbrq13 with SMTP id rq13so1189843pbb.31 for ; Wed, 07 Mar 2012 19:10:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S3KPEaIQSOuh5jMaWVCfKkCKxStg2JC/cWK7AIhze7Y=; b=FQBmt7E3SAaLJuLighmZlboLuut/UBxCDkXSNxeJaTUgDYSNEq7FRjuKbtFuU0stMm fKXPfx5UaqY98a0pJO/mRCXb1X8zhB4uY5+Fx8bfzo+MjxsLOltsGR+o8A6ePTAK2SEz DG5nTP1LmZJsoFd9rMEvYZ+9GkDI2ckj9yi68= MIME-Version: 1.0 Received: by 10.68.225.73 with SMTP id ri9mr6919420pbc.70.1331176246684; Wed, 07 Mar 2012 19:10:46 -0800 (PST) Received: by 10.68.43.105 with HTTP; Wed, 7 Mar 2012 19:10:46 -0800 (PST) In-Reply-To: <87ipigwf4t.fsf@kelsey-ws.hq.ember.com> References: <4F443861.8050708@ericsson.com> <87ipigwf4t.fsf@kelsey-ws.hq.ember.com> Date: Wed, 7 Mar 2012 19:10:46 -0800 Message-ID: From: Ulrich Herberg To: Richard Kelsey Content-Type: multipart/alternative; boundary=e89a8ff2437d512c0504bab29f7a X-Gm-Message-State: ALoCoQmCCHsrwOlfPStovYEs5aL8zI7TBKmvAxxbZvs6r0cYfqACwc9x+cU6C9r3v7OlKl7jYKKG Cc: int-area@ietf.org Subject: Re: [Int-area] Call for agenda items X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 03:10:48 -0000 --e89a8ff2437d512c0504bab29f7a Content-Type: text/plain; charset=ISO-8859-1 Hi, I would like to request a slot for a document which is also related to mesh networks based on 802.15.4 (lowpan) http://tools.ietf.org/html/draft-cardenas-dff-04 Abstract This document describes the Depth-First Forwarding (DFF) protocol for IPv6 networks based on the LoWPAN adaptation layer. The protocol is a mesh-under data forwarding mechanism that increases reliability of data delivery. DFF forwards data frames using a network-wide "depth-first search" for the Final Destination of the frame. DFF may be used in conjunction with a mesh-under routing protocol, which provides "hints" for DFF in which order to try to send the frame to the neighbors discovered by the neighborhood discovery mechanism. As we have not yet found a home for the draft, I will (also) present it at the RtgWG. If the chairs believe the draft could be appropriate for the IntArea WG, then I would like to present it. Best regards Ulrich On Wed, Mar 7, 2012 at 8:27 AM, Richard Kelsey wrote: > Hello, > > I would like request a slot to present > draft-kelsey-intarea-mesh-link-establishment. > > The draft describes a protocol for dynamically configuring links > in an ad hoc wireless mesh network. The protocol bridges a gap > between link layer standards, which typically deal with individual > links, and IETF protocols, which assume that the links are up and > running. > > The draft does not fit the charter of any active working group. > I would like to present it to the intarea group in order to get a > more thorough review that it would otherwise receive. > > This draft has not been presented to any other WG and will not be > presented to any other WG at IETF 83. > > -Richard Kelsey > > > > Date: Tue, 21 Feb 2012 19:35:45 -0500 > > From: Suresh Krishnan > > Received-SPF: Pass (p01c12m097.mxlogic.net: domain of ietf.orgdesignates 12.22.58.30 as permitted sender) > > > > Hi all, > > The intarea WG will be meeting in Paris (we have requested a 2 hour > > slot) and we are in the process of setting the agenda. Please send us > > your request for slots detailing > > > > * Name of the draft > > * Short description of why you think the item needs to be discussed in > > the intarea meeting > > * Whether the draft has already been presented or will be presented in > > some other wg/bof. > > > > Thanks > > Julien and Suresh > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > --e89a8ff2437d512c0504bab29f7a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I would like to request a slot for a document which is also rela= ted to mesh networks based on 802.15.4 (lowpan)
http://tools.ietf.org/html/draft-carde= nas-dff-04

Abstract

   This document describes the Depth-First Forwarding (DFF) protocol for
   IPv6 networks based on the LoWPAN adaptation layer.  The protocol is
   a mesh-under data forwarding mechanism that increases reliability of
   data delivery.

   DFF forwards data frames using a network-wide "depth-first search&q=
uot;
   for the Final Destination of the frame.  DFF may be used in
   conjunction with a mesh-under routing protocol, which provides
   "hints" for DFF in which order to try to send the frame to the
   neighbors discovered by the neighborhood discovery mechanism. 

= As we have not yet found a home for the draft, I will (also) present it at = the RtgWG. If the chairs believe the draft could be appropriate for the Int= Area WG, then I would like to present it.

Best regards
Ulrich

On Wed, Mar 7,= 2012 at 8:27 AM, Richard Kelsey <richard.kelsey@ember.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Hello,

I would like request a slot to present
draft-kelsey-intarea-mesh-link-establishment.

The draft describes a protocol for dynamically configuring links
in an ad hoc wireless mesh network. =A0The protocol bridges a gap
between link layer standards, which typically deal with individual
links, and IETF protocols, which assume that the links are up and
running.

The draft does not fit the charter of any active working group.
I would like to present it to the intarea group in order to get a
more thorough review that it would otherwise receive.

This draft has not been presented to any other WG and will not be
presented to any other WG at IETF 83.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-Richar= d Kelsey


> Date: Tue, 21 Feb 2012 19:35:45 -0500
> From: Suresh Krishnan <suresh.krishnan@ericsson.com>
> Received-SPF: Pass (p01c12m097.mxlogic.net: domain of ietf.org designates 12.22.58.30 as permitted sende= r)
>
> Hi all,
> =A0 =A0The intarea WG will be meeting in Paris (we have requested a 2 = hour
> slot) and we are in the process of setting the agenda. Please send us<= br> > your request for slots detailing
>
> * Name of the draft
> * Short description of why you think the item needs to be discussed in=
> the intarea meeting
> * Whether the draft has already been presented or will be presented in=
> some other wg/bof.
>
> Thanks
> Julien and Suresh
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

--e89a8ff2437d512c0504bab29f7a-- From naiming@cisco.com Thu Mar 8 16:04:01 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6968721F85E0 for ; Thu, 8 Mar 2012 16:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.799 X-Spam-Level: X-Spam-Status: No, score=-8.799 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 zkOjPe7Pv5FR for ; Thu, 8 Mar 2012 16:04:00 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFCC21F85DB for ; Thu, 8 Mar 2012 16:04:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=naiming@cisco.com; l=3416; q=dns/txt; s=iport; t=1331251440; x=1332461040; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=BjJ3JvFoxOR0lJyLU8yW7B7EWXn/jyfCp4MwYsV2gV8=; b=moxP/4bP0bRtAqYHGyEnugHcQXK9CNNneMzyu9XgzO8hEu7zegYI74G4 Ir8Ovxk3+AvQ4I/HNnzRg1UaO6j3eCCyE2+sFJDDiWaTO4LBlqmCwAs/K opE+dka47vePLSzYPwyOvXbMKC6vrV1gAY9BmcW7h81LkCj1MoeRD/uvQ U=; X-IronPort-AV: E=Sophos;i="4.73,554,1325462400"; d="scan'208";a="35240610" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 09 Mar 2012 00:04:00 +0000 Received: from [10.155.34.37] ([10.155.34.37]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q29040q3006803; Fri, 9 Mar 2012 00:04:00 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Naiming Shen In-Reply-To: <4F580B97.1070401@isi.edu> Date: Thu, 8 Mar 2012 16:04:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3E7B0D03-60CF-4711-8CEC-A6DC887C2675@cisco.com> References: <20120227213938.20370.68711.idtracker@ietfa.amsl.com> <9C0C873C-D52F-4EC8-939C-FD2373FDC9ED@cisco.com> <709D93F8-C6C0-4F7D-A823-35540D683EE6@netapp.com> <4705AE0F-CAE1-46D9-84D5-AF6D11BD35BC@cisco.com> <2C2F2761-E2BD-4E55-97F3-4E5B3155A3BB@netapp.com> <4F580B97.1070401@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1084) Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 00:04:01 -0000 Hi Joe, some replies inline, On Mar 7, 2012, at 5:29 PM, Joe Touch wrote: > Hi, all, >=20 > On 3/5/2012 11:46 PM, Naiming Shen wrote: > ... >> The previous version of this draft didn't have this well-known port = defined, and we got >> many comments on how to distinguish the packets with new features = from the general >> traceroute/ping packets on the Internet, as you mentioned below, it = needs more deeper >> packet inspection. With this well-known port, a provider's internal = use of certain feature with >> this extension can be more easily sort out from normal trace/ping = packets (before the deeper >> packet inspection). >=20 > A ping (ICMP echo request) message has no port. It has an Identifier = field that is used "like a port in TCP or UDP to identify a session" = [RFC792], but it identifies a session not a protocol. I.e., it should = change for subsequent echo requests, so this should not be fixed at a = specific value. Actually the current implementations I have looked, this ID of ICMP echo = request is used to identify a ping process in a multi-threaded system such as = linux/bsd. It is fixed during the session, which the "Sequence number" field changes = with each packet. In this draft, we suggest if the implementation uses this fixed = ID in the ICMP echo-request, the multi-thread process-id information can be moved = to the firest 64 octets, which is reserved for private use. >=20 > Traceroute uses ICMP with varying TTLs, so a port number is equally = meaningless there. For traceroute application, it's the same usage for the ID field as = above. >=20 > Sec 5 of this doc redefines how ping works - when it reaches the valid = destination, an echo response is sent back. That's how ping knows it = works, and how traceroute knows to stop. That is true. But for udp traceroute stops or udp ping reaches the = destination, it uses the property of either the destination port is not open, or the = port is open but the source address of the udp packet does not match with any of the = socket. Here in this draft is a little different, the port is a well-known, and = is intended to receive this ping or traceroute packet, thus we just emphasis that so = there is no confusion. >=20 > If you intend on using these inside UDP or TCP segments, you need to = be much more specific about what you mean by 'traceroute/ping' - = notably, citing an RFC or other spec on the variant you're using. = However, it would be important to first make the case that this = information is relevant for those protocols. This is only applied to traceroute/ping type of the applications. = Although there is no specific RFCs to cover those applications, we can certainly add more = text to describe them more clearly. >=20 > However, why would you then want to limit those protocols to a = specific UDP or TCP port number? their value is in being used to test = various port numbers that are blocked (or not) along various paths - = e.g., to find out that HTTP isn't blocked all the way to a destination, = or if so on what hop. It's just an option offered by this extension, it's not a must. As = mentioned above, this is for providers to distinguish new services using this extension = from the trace and ping packets of legacy usage. thanks. - Naiming >=20 > Joe >=20 >=20 >=20 >=20 From touch@isi.edu Thu Mar 8 16:10:49 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A90B21E8042 for ; Thu, 8 Mar 2012 16:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 rpV85xVMCgS2 for ; Thu, 8 Mar 2012 16:10:48 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id A189121E801B for ; Thu, 8 Mar 2012 16:10:48 -0800 (PST) Received: from [75.217.171.213] (213.sub-75-217-171.myvzw.com [75.217.171.213]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q290ABCX020207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Mar 2012 16:10:21 -0800 (PST) Message-ID: <4F594A63.1060506@isi.edu> Date: Thu, 08 Mar 2012 16:10:11 -0800 From: Joe Touch 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: Naiming Shen References: <20120227213938.20370.68711.idtracker@ietfa.amsl.com> <9C0C873C-D52F-4EC8-939C-FD2373FDC9ED@cisco.com> <709D93F8-C6C0-4F7D-A823-35540D683EE6@netapp.com> <4705AE0F-CAE1-46D9-84D5-AF6D11BD35BC@cisco.com> <2C2F2761-E2BD-4E55-97F3-4E5B3155A3BB@netapp.com> <4F580B97.1070401@isi.edu> <3E7B0D03-60CF-4711-8CEC-A6DC887C2675@cisco.com> In-Reply-To: <3E7B0D03-60CF-4711-8CEC-A6DC887C2675@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 00:10:49 -0000 I remain confused. ICMP doesn't use ports; it uses IDs, and the ID space is not registered by IANA, so there's no meaning to a reserved ICMP echo ID value. As I noted, there is a specific value - not legacy, but current utility - in sending TCP or UDP packets to specific ports to test reachability. I don't see any value in reserving a port here. Joe On 3/8/2012 4:04 PM, Naiming Shen wrote: > > Hi Joe, > > some replies inline, > > On Mar 7, 2012, at 5:29 PM, Joe Touch wrote: > >> Hi, all, >> >> On 3/5/2012 11:46 PM, Naiming Shen wrote: >> ... >>> The previous version of this draft didn't have this well-known port defined, and we got >>> many comments on how to distinguish the packets with new features from the general >>> traceroute/ping packets on the Internet, as you mentioned below, it needs more deeper >>> packet inspection. With this well-known port, a provider's internal use of certain feature with >>> this extension can be more easily sort out from normal trace/ping packets (before the deeper >>> packet inspection). >> >> A ping (ICMP echo request) message has no port. It has an Identifier field that is used "like a port in TCP or UDP to identify a session" [RFC792], but it identifies a session not a protocol. I.e., it should change for subsequent echo requests, so this should not be fixed at a specific value. > > Actually the current implementations I have looked, this ID of ICMP echo request > is used to identify a ping process in a multi-threaded system such as linux/bsd. It > is fixed during the session, which the "Sequence number" field changes with each > packet. In this draft, we suggest if the implementation uses this fixed ID in the > ICMP echo-request, the multi-thread process-id information can be moved to the > firest 64 octets, which is reserved for private use. > >> >> Traceroute uses ICMP with varying TTLs, so a port number is equally meaningless there. > > For traceroute application, it's the same usage for the ID field as above. > >> >> Sec 5 of this doc redefines how ping works - when it reaches the valid destination, an echo response is sent back. That's how ping knows it works, and how traceroute knows to stop. > > That is true. But for udp traceroute stops or udp ping reaches the destination, > it uses the property of either the destination port is not open, or the port is open > but the source address of the udp packet does not match with any of the socket. > Here in this draft is a little different, the port is a well-known, and is intended to > receive this ping or traceroute packet, thus we just emphasis that so there is no > confusion. > >> >> If you intend on using these inside UDP or TCP segments, you need to be much more specific about what you mean by 'traceroute/ping' - notably, citing an RFC or other spec on the variant you're using. However, it would be important to first make the case that this information is relevant for those protocols. > > This is only applied to traceroute/ping type of the applications. Although there is no > specific RFCs to cover those applications, we can certainly add more text to describe > them more clearly. > >> >> However, why would you then want to limit those protocols to a specific UDP or TCP port number? their value is in being used to test various port numbers that are blocked (or not) along various paths - e.g., to find out that HTTP isn't blocked all the way to a destination, or if so on what hop. > > It's just an option offered by this extension, it's not a must. As mentioned above, > this is for providers to distinguish new services using this extension from the trace > and ping packets of legacy usage. > > thanks. > - Naiming > >> >> Joe >> >> >> >> > From naiming@cisco.com Thu Mar 8 19:04:10 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D50021F859F for ; Thu, 8 Mar 2012 19:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.881 X-Spam-Level: X-Spam-Status: No, score=-8.881 tagged_above=-999 required=5 tests=[AWL=1.718, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 WVyT7dswu8r9 for ; Thu, 8 Mar 2012 19:04:09 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4147A21F8592 for ; Thu, 8 Mar 2012 19:04:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=naiming@cisco.com; l=4355; q=dns/txt; s=iport; t=1331262249; x=1332471849; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=rAmyA86ZVt0f85YWs3D+N0GvRJ/ADaf7i33Rh3mUkcE=; b=LnMkLjhD+Kx2EgttV+jbPwmr1jEnCHkXOqwQjqXDlBAoOmfEHH85j5BC 9SxTaPiyCSwqmhXgCqve4UMWNwzmQa2LBBUerfsuHTE9FkK/6U4eVMEE4 PPD+1F4ttfqlTEOr6SQ+sqi+yS1TIs+ZPQ6am7rdDPbAXDB2ihutr8C6E k=; X-IronPort-AV: E=Sophos;i="4.73,555,1325462400"; d="scan'208";a="35262931" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 09 Mar 2012 03:04:09 +0000 Received: from sjc-vpn2-49.cisco.com (sjc-vpn2-49.cisco.com [10.21.112.49]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q293488Z029305; Fri, 9 Mar 2012 03:04:08 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Naiming Shen In-Reply-To: <4F594A63.1060506@isi.edu> Date: Thu, 8 Mar 2012 19:04:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5F06A352-AE71-4DFB-8B19-2DA80076406F@cisco.com> References: <20120227213938.20370.68711.idtracker@ietfa.amsl.com> <9C0C873C-D52F-4EC8-939C-FD2373FDC9ED@cisco.com> <709D93F8-C6C0-4F7D-A823-35540D683EE6@netapp.com> <4705AE0F-CAE1-46D9-84D5-AF6D11BD35BC@cisco.com> <2C2F2761-E2BD-4E55-97F3-4E5B3155A3BB@netapp.com> <4F580B97.1070401@isi.edu> <3E7B0D03-60CF-4711-8CEC-A6DC887C2675@cisco.com> <4F594A63.1060506@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1084) Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 03:04:10 -0000 Ok, if IANA does not reserve non-"port" items, we'll remove this from = the IANA consideration section then. By legacy I only meant the default or everyday usage of = traceroute or ping. thanks for the note. - Naiming On Mar 8, 2012, at 4:10 PM, Joe Touch wrote: > I remain confused. >=20 > ICMP doesn't use ports; it uses IDs, and the ID space is not = registered by IANA, so there's no meaning to a reserved ICMP echo ID = value. >=20 > As I noted, there is a specific value - not legacy, but current = utility - in sending TCP or UDP packets to specific ports to test = reachability. >=20 > I don't see any value in reserving a port here. >=20 > Joe >=20 > On 3/8/2012 4:04 PM, Naiming Shen wrote: >>=20 >> Hi Joe, >>=20 >> some replies inline, >>=20 >> On Mar 7, 2012, at 5:29 PM, Joe Touch wrote: >>=20 >>> Hi, all, >>>=20 >>> On 3/5/2012 11:46 PM, Naiming Shen wrote: >>> ... >>>> The previous version of this draft didn't have this well-known port = defined, and we got >>>> many comments on how to distinguish the packets with new features = from the general >>>> traceroute/ping packets on the Internet, as you mentioned below, it = needs more deeper >>>> packet inspection. With this well-known port, a provider's internal = use of certain feature with >>>> this extension can be more easily sort out from normal trace/ping = packets (before the deeper >>>> packet inspection). >>>=20 >>> A ping (ICMP echo request) message has no port. It has an Identifier = field that is used "like a port in TCP or UDP to identify a session" = [RFC792], but it identifies a session not a protocol. I.e., it should = change for subsequent echo requests, so this should not be fixed at a = specific value. >>=20 >> Actually the current implementations I have looked, this ID of ICMP = echo request >> is used to identify a ping process in a multi-threaded system such as = linux/bsd. It >> is fixed during the session, which the "Sequence number" field = changes with each >> packet. In this draft, we suggest if the implementation uses this = fixed ID in the >> ICMP echo-request, the multi-thread process-id information can be = moved to the >> firest 64 octets, which is reserved for private use. >>=20 >>>=20 >>> Traceroute uses ICMP with varying TTLs, so a port number is equally = meaningless there. >>=20 >> For traceroute application, it's the same usage for the ID field as = above. >>=20 >>>=20 >>> Sec 5 of this doc redefines how ping works - when it reaches the = valid destination, an echo response is sent back. That's how ping knows = it works, and how traceroute knows to stop. >>=20 >> That is true. But for udp traceroute stops or udp ping reaches the = destination, >> it uses the property of either the destination port is not open, or = the port is open >> but the source address of the udp packet does not match with any of = the socket. >> Here in this draft is a little different, the port is a well-known, = and is intended to >> receive this ping or traceroute packet, thus we just emphasis that so = there is no >> confusion. >>=20 >>>=20 >>> If you intend on using these inside UDP or TCP segments, you need to = be much more specific about what you mean by 'traceroute/ping' - = notably, citing an RFC or other spec on the variant you're using. = However, it would be important to first make the case that this = information is relevant for those protocols. >>=20 >> This is only applied to traceroute/ping type of the applications. = Although there is no >> specific RFCs to cover those applications, we can certainly add more = text to describe >> them more clearly. >>=20 >>>=20 >>> However, why would you then want to limit those protocols to a = specific UDP or TCP port number? their value is in being used to test = various port numbers that are blocked (or not) along various paths - = e.g., to find out that HTTP isn't blocked all the way to a destination, = or if so on what hop. >>=20 >> It's just an option offered by this extension, it's not a must. As = mentioned above, >> this is for providers to distinguish new services using this = extension from the trace >> and ping packets of legacy usage. >>=20 >> thanks. >> - Naiming >>=20 >>>=20 >>> Joe >>>=20 >>>=20 >>>=20 >>>=20 >>=20 From touch@isi.edu Thu Mar 8 22:12:54 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DDE21F85E1 for ; Thu, 8 Mar 2012 22:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=-1.198, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 nmU+GWfc1M9P for ; Thu, 8 Mar 2012 22:12:53 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id B291C21F85D4 for ; Thu, 8 Mar 2012 22:12:53 -0800 (PST) Received: from [192.168.1.89] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q296CLZQ007237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 8 Mar 2012 22:12:25 -0800 (PST) References: <20120227213938.20370.68711.idtracker@ietfa.amsl.com> <9C0C873C-D52F-4EC8-939C-FD2373FDC9ED@cisco.com> <709D93F8-C6C0-4F7D-A823-35540D683EE6@netapp.com> <4705AE0F-CAE1-46D9-84D5-AF6D11BD35BC@cisco.com> <2C2F2761-E2BD-4E55-97F3-4E5B3155A3BB@netapp.com> <4F580B97.1070401@isi.edu> <3E7B0D03-60CF-4711-8CEC-A6DC887C2675@cisco.com> <4F594A63.1060506@isi.edu> <5F06A352-AE71-4DFB-8B19-2DA80076406F@cisco.com> In-Reply-To: <5F06A352-AE71-4DFB-8B19-2DA80076406F@cisco.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (9B176) From: Joe Touch Date: Thu, 8 Mar 2012 22:12:24 -0800 To: Naiming Shen X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 06:12:54 -0000 IANA reserves many things besides ports, just not ICMP IDs, FYI.=20 "Legacy" usually means an old use that may be supported but is no longer com= mon, too.=20 Joe=20 On Mar 8, 2012, at 7:04 PM, Naiming Shen wrote: >=20 > Ok, if IANA does not reserve non-"port" items, we'll remove this from the I= ANA consideration > section then. By legacy I only meant the default or everyday usage of trac= eroute or ping. >=20 > thanks for the note. >=20 > - Naiming >=20 > On Mar 8, 2012, at 4:10 PM, Joe Touch wrote: >=20 >> I remain confused. >>=20 >> ICMP doesn't use ports; it uses IDs, and the ID space is not registered b= y IANA, so there's no meaning to a reserved ICMP echo ID value. >>=20 >> As I noted, there is a specific value - not legacy, but current utility -= in sending TCP or UDP packets to specific ports to test reachability. >>=20 >> I don't see any value in reserving a port here. >>=20 >> Joe >>=20 >> On 3/8/2012 4:04 PM, Naiming Shen wrote: >>>=20 >>> Hi Joe, >>>=20 >>> some replies inline, >>>=20 >>> On Mar 7, 2012, at 5:29 PM, Joe Touch wrote: >>>=20 >>>> Hi, all, >>>>=20 >>>> On 3/5/2012 11:46 PM, Naiming Shen wrote: >>>> ... >>>>> The previous version of this draft didn't have this well-known port de= fined, and we got >>>>> many comments on how to distinguish the packets with new features from= the general >>>>> traceroute/ping packets on the Internet, as you mentioned below, it ne= eds more deeper >>>>> packet inspection. With this well-known port, a provider's internal us= e of certain feature with >>>>> this extension can be more easily sort out from normal trace/ping pack= ets (before the deeper >>>>> packet inspection). >>>>=20 >>>> A ping (ICMP echo request) message has no port. It has an Identifier fi= eld that is used "like a port in TCP or UDP to identify a session" [RFC792],= but it identifies a session not a protocol. I.e., it should change for subs= equent echo requests, so this should not be fixed at a specific value. >>>=20 >>> Actually the current implementations I have looked, this ID of ICMP echo= request >>> is used to identify a ping process in a multi-threaded system such as li= nux/bsd. It >>> is fixed during the session, which the "Sequence number" field changes w= ith each >>> packet. In this draft, we suggest if the implementation uses this fixed I= D in the >>> ICMP echo-request, the multi-thread process-id information can be moved t= o the >>> firest 64 octets, which is reserved for private use. >>>=20 >>>>=20 >>>> Traceroute uses ICMP with varying TTLs, so a port number is equally mea= ningless there. >>>=20 >>> For traceroute application, it's the same usage for the ID field as abov= e. >>>=20 >>>>=20 >>>> Sec 5 of this doc redefines how ping works - when it reaches the valid d= estination, an echo response is sent back. That's how ping knows it works, a= nd how traceroute knows to stop. >>>=20 >>> That is true. But for udp traceroute stops or udp ping reaches the desti= nation, >>> it uses the property of either the destination port is not open, or the p= ort is open >>> but the source address of the udp packet does not match with any of the s= ocket. >>> Here in this draft is a little different, the port is a well-known, and i= s intended to >>> receive this ping or traceroute packet, thus we just emphasis that so th= ere is no >>> confusion. >>>=20 >>>>=20 >>>> If you intend on using these inside UDP or TCP segments, you need to be= much more specific about what you mean by 'traceroute/ping' - notably, citi= ng an RFC or other spec on the variant you're using. However, it would be im= portant to first make the case that this information is relevant for those p= rotocols. >>>=20 >>> This is only applied to traceroute/ping type of the applications. Althou= gh there is no >>> specific RFCs to cover those applications, we can certainly add more tex= t to describe >>> them more clearly. >>>=20 >>>>=20 >>>> However, why would you then want to limit those protocols to a specific= UDP or TCP port number? their value is in being used to test various port n= umbers that are blocked (or not) along various paths - e.g., to find out tha= t HTTP isn't blocked all the way to a destination, or if so on what hop. >>>=20 >>> It's just an option offered by this extension, it's not a must. As menti= oned above, >>> this is for providers to distinguish new services using this extension f= rom the trace >>> and ping packets of legacy usage. >>>=20 >>> thanks. >>> - Naiming >>>=20 >>>>=20 >>>> Joe >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >=20 From Olaf.Bonness@telekom.de Mon Mar 12 01:31:17 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFF121F86EB for ; Mon, 12 Mar 2012 01:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 spSYuWpuaR+j for ; Mon, 12 Mar 2012 01:31:17 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 71F5C21F86E5 for ; Mon, 12 Mar 2012 01:31:16 -0700 (PDT) Received: from he113415.emea1.cds.t-internal.com ([10.125.65.81]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 12 Mar 2012 09:31:08 +0100 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.56]) by HE113415.emea1.cds.t-internal.com ([2002:7cd:4151::7cd:4151]) with mapi; Mon, 12 Mar 2012 09:31:06 +0100 From: To: Date: Mon, 12 Mar 2012 09:31:06 +0100 Thread-Topic: New Version Notification for draft-fleischhauer-ipv4-addr-saving-02.txt - Feedback wanted Thread-Index: Ac0AKneoSAuFgJihQ9iwOZXFHr0PkQ== Message-ID: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Int-area] New Version Notification for draft-fleischhauer-ipv4-addr-saving-02.txt - Feedback wanted X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 08:31:17 -0000 Hi folks About 1 week ago we've released version 02 of the I-D draft-fleischhauer-i= pv4-addr-saving-02.txt as you can see from the IETF message below. The basic Idea of this I-D is to de-couple IPCP and IPCPv6 within a Dual-St= ack PPP session in order to be more flexible with the needed resources espe= cially for the IPCP part of the PPP session. The I-D tries to explain some = uses cases and also the gains for such an approach especially from a servic= e provider point of view. Besides that it sketches how the IPCP message flo= w for releasing and requesting the IPv4 parameters in a Dual-Stack PPP sess= ion can work independently of the existing IPCPv6 connection. We know that there is a huge amount of stuff to read before the IETF meetin= gs, but it would be very helpful for us to get your feedback in order to ex= tent / improve this I-D. Already your basic opinion would help us a lot.=20 (This I-D "- Makes sense" or "Is not needed from my point of view" or "I do= n't care" or "Bring it to another working group (where?)"). Thanks a lot in advance. Regards Karsten and Olaf > -----Urspr=FCngliche Nachricht----- > Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Gesendet: Dienstag, 28. Februar 2012 21:39 > An: Fleischhauer, Karsten > Cc: Bonne=DF, Olaf > Betreff: New Version Notification for=20 > draft-fleischhauer-ipv4-addr-saving-02.txt >=20 > A new version of I-D, > draft-fleischhauer-ipv4-addr-saving-02.txt has been successfully=20 > submitted by Karsten Fleischhauer and posted to the IETF repository. >=20 > Filename: draft-fleischhauer-ipv4-addr-saving > Revision: 02 > Title: On demand IPv4 address provisioning in=20 > Dual-Stack PPP deployment scenarios > Creation date: 2012-02-28 > WG ID: Individual Submission > Number of pages: 18 >=20 > Abstract: > Today the Dual-Stack approach is the most straightforward and the most= common way for introducing IPv6 into existing systems and > networks. However a typical drawback of implementing Dual-Stack is th= at each node will still require at least one IPv4 address. =20 > Hence, solely deploying Dual-Stack does not provide a sufficient solut= ion to the IPv4 address exhaustion problem. Assuming a situation where=20 > most of the IP communication (e.g. always-on, VoIP etc.) can be provide= d via IPv6, the usage of public IPv4 addresses can significantly be > reduced and the unused public IPv4 addresses can under certain circums= tances be returned to the public IPv4 address pool of the > service provider. New Dual-Stack enabled services can be introduced w= ithout increasing the public IPv4 address demand, when > IPv6 will be the preferred network layer protocol. This document descr= ibes such a solution in a Dual-Stack PPP session network scenario and expla= ins > the protocol mechanisms which are used. >=20 > The IETF Secretariat >=20 From samita.chakrabarti@ericsson.com Mon Mar 12 18:36:27 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5119321F888E; Mon, 12 Mar 2012 18:36:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WixE86siSuWB; Mon, 12 Mar 2012 18:36:26 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 28BED21F885F; Mon, 12 Mar 2012 18:36:26 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q2D1aPiQ002438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Mar 2012 20:36:25 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.2.76]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 12 Mar 2012 21:36:24 -0400 From: Samita Chakrabarti To: 6man Mailing List , "int-area@ietf.org" Date: Mon, 12 Mar 2012 21:36:22 -0400 Thread-Topic: draft-chakrabarti-nordmark-energy-aware-nd-02.txt Thread-Index: Ac0AqzZ6GqXlCyK9SASIyLAz+Cyl8QAB5DhAAAEsgUA= Message-ID: <16D60F43CA0B724F8052D7E9323565D72AAFFD9169@EUSAACMS0715.eamcs.ericsson.se> 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 Subject: [Int-area] FW: draft-chakrabarti-nordmark-energy-aware-nd-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 01:36:27 -0000 =20 Hello: =20 A draft on the efficient ipv6 neighbor discovery has been submitted with ed= itorial modification to address some of the comments from last IETF. We exp= ect to have another revision right after IETF to change the name from 'ener= gy-aware' to 'efficient'. In version 02: * Fixed the abstract to focus on the optimization * Applicability section mentions that the optimization is for IPv6 ND messa= ging and further optimization for energy-saving is possible at the upper la= yers * Added a section (section 17) to discuss its relationship with DNA solutio= n and that it does not affect nodes joining musticast groups and does not a= ffect multicast traffic and queries in the network. The authors of this draft request a review and comments from the wg members= . We presented the draft in last IETFs (@Taiwan+QC) and had many positive f= eedbacks from Data Center networking and ipv6 mobile-handset representative= s.=20 http://tools.ietf.org/html/draft-chakrabarti-nordmark-energy-aware-nd-02 Thanks, -Samita -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, March 12, 2012 4:52 PM To: Samita Chakrabarti Cc: mrw@lilacglade.org; nordmark@cisco.com Subject: New Version Notification for draft-chakrabarti-nordmark-energy-awa= re-nd-02.txt A new version of I-D, draft-chakrabarti-nordmark-energy-aware-nd-02.txt has= been successfully submitted by Samita Chakrabarti and posted to the IETF r= epository. Filename: draft-chakrabarti-nordmark-energy-aware-nd Revision: 02 Title: Energy Aware IPv6 Neighbor Discovery Optimizations Creation date: 2012-03-13 WG ID: Individual Submission Number of pages: 23 Abstract: IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for neighbor's address resolution, unreachability detection, address autoconfiguration, router advertisement and solicitation. With the progress of Internet adoption on various industries including home, wireless and machine-to-machine communications, there is a desire for optimizing legacy IPv6 Neighbor Discovery protocol to be more efficient in terms of number of signaling messages in the network. Efficient IPv6 Neighbor Discovery is useful for energy-efficient networks and as well for overlay networks such as VLANs with large number of nodes. This document describes a method of optimizations by reducing periodic multicast messages, frequent Neighbor Solicitation messages and discusses interoperability with legacy IPv6 nodes. It also addresses the ND denial of service issues by introducing node Registration procedure. = =20 The IETF Secretariat _______________________________________________ eriietf mailing list eriietf@mailman.lmera.ericsson.se http://mailman.lmera.ericsson.se/mailman/listinfo/eriietf From sarikaya2012@gmail.com Wed Mar 14 10:32:00 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B23C21E8024; Wed, 14 Mar 2012 10:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Cv8NqWwIYFmc; Wed, 14 Mar 2012 10:31:58 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B3C5721F876F; Wed, 14 Mar 2012 10:31:57 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1225066eaa.31 for ; Wed, 14 Mar 2012 10:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=HN2j7MaT2UlhlkYtMZWKHrnueNcLQKQ9zKss7lre2so=; b=NgH+gXNtD/Cg45cNUrn6ivsWAORjHvPIDdXpequ7PMreQwNLssGAFZK2nTwvtXgURo JT1lm7G40itiG213prFJ4qVsEwcnYnWCIbCHNx5m/+2tDp0JIocR+X2i3eXKzfOv79eZ ++Uk5BsOzu4WpraYOlNSzQ2gS0UqQ0SJQ16tjpJ7elc9nOn7yFXYBzpfQXAtjrvW0zkJ PTL+av72T6VxTBygp9aHfm7J6i4lUkYUgDkxUmkvY524KNot2t8dm75eawCAShUxVRBH GYASltmRnqGCSUhfL4b07NLidPLBsJo9ST7LknQE5OyJV8ZKxuVKp5I7AB+ll7MoLMiB Y5PQ== MIME-Version: 1.0 Received: by 10.50.193.131 with SMTP id ho3mr12922385igc.55.1331746315934; Wed, 14 Mar 2012 10:31:55 -0700 (PDT) Received: by 10.231.179.71 with HTTP; Wed, 14 Mar 2012 10:31:55 -0700 (PDT) Date: Wed, 14 Mar 2012 12:31:55 -0500 Message-ID: From: Behcet Sarikaya To: Internet Area , dmm@ietf.org, netext@ietf.org, mip4@ietf.org, multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Dirk.von-Hugo@telekom.de Subject: [Int-area] FMC Bar Bof Date Correction X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 17:32:00 -0000 Hi all, Our previous mail on March 6 announcing FMC Bar Bof had by mistake the date as March 28. Tuesday March 27 at 19:30 or 7:30pm is the correct one. We are going to send another mail once this is confirmed by IETF. Sorry for the confusion and thanks to Wassim, Med, Sophie for waking us up :-). Behcet ------------------------------------------------------------------------------------------------------------------------------ Hi all, FMC Problem Statement draft draft-xue-intarea-fmc-ps-00.txt has been submitted as below. We also requested a slot for holding FMC Bar Bof tentatively on Tuesday, March 28 at 19:30. If you have a presentation to make please drop a note to us. Regards, Behcet & Dirk From Olaf.Bonness@telekom.de Thu Mar 15 05:31:55 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C209521F8584 for ; Thu, 15 Mar 2012 05:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 X8GsunDCdwwq for ; Thu, 15 Mar 2012 05:31:54 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 120B321F8581 for ; Thu, 15 Mar 2012 05:31:51 -0700 (PDT) Received: from he111297.emea1.cds.t-internal.com ([10.125.90.15]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 15 Mar 2012 13:31:35 +0100 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.56]) by HE111297.EMEA1.CDS.T-INTERNAL.COM ([fe80::9835:b110:c489:6d64%16]) with mapi; Thu, 15 Mar 2012 13:31:35 +0100 From: To: Date: Thu, 15 Mar 2012 13:31:34 +0100 Thread-Topic: [Int-area] Call for agenda items Thread-Index: Ac0Cp3qLQ6hi2HJNQOiVA5tbDryh0w== Message-ID: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF4024FD73BACF0HE111541eme_" MIME-Version: 1.0 Subject: Re: [Int-area] Call for agenda items X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 12:31:55 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF4024FD73BACF0HE111541eme_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi folks, chairs If it is still possible, I would like to ask for a slot of about 10' at the= next IETF IntArea Meeting in Paris, in order to present the latest version= 02 of the I-D draft-fleischhauer-ipv4-addr-saving-02. (We've presented ver= sion 00 already a few IETFs ago.) Nevertheless, I think that another presentation of the now extended version= of this draft could help to highlight the rationale of this approach (Sepa= ration of establishment / tear-down of IPCP and IPCPv6 within a Dual-Stack = PPP session in order to allow network providers to produce different custom= er connections (Single, Double, Triple play, etc.) very efficiently and be = also very efficient with restricted network resources (e.g. IPv4 addresses)= .) Thanks a lot and kind regards Olaf > Date: Tue, 21 Feb 2012 19:35:45 -0500 > From: Suresh Krishnan > > Received-SPF: Pass (p01c12m097.mxlogic.net= : domain of ietf.org designates 12.22.58.30 as permitted s= ender) > > Hi all, > The intarea WG will be meeting in Paris (we have requested a 2 hour > slot) and we are in the process of setting the agenda. Please send us > your request for slots detailing > > * Name of the draft > * Short description of why you think the item needs to be discussed in > the intarea meeting > * Whether the draft has already been presented or will be presented in > some other wg/bof. > > Thanks > Julien and Suresh > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area --_000_CE8995AB5D178F44A2154F5C9A97CAF4024FD73BACF0HE111541eme_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi folks, chairs

 

= If it is still possible, I would like to ask for a slot of about 10‘ = at the next IETF IntArea Meeting in Paris, in order to present the latest v= ersion 02 of the I-D draft-fleischhauer-ipv4-addr-saving-02. (We’ve p= resented version 00 already a few IETFs ago.)

Nevertheless, I think that another present= ation of the now extended version of this draft could help to highlight the= rationale of this approach (Separation of establishment / tear-down of IPC= P and IPCPv6 within a Dual-Stack PPP session in order to allow network prov= iders to produce different customer connections (Single, Double, Triple pla= y, etc.) very efficiently and be also very efficient with restricted networ= k resources (e.g. IPv4 addresses).)

 

Thanks a lot and kind regards
= Olaf



> Date: Tue, 21 Feb 2012 19:35:45 -0500> From: Suresh Krishnan <
suresh.krishnan@ericsson.com>
> Received-SPF: Pass (p01c12m097.mxlog= ic.net: domain of ietf.org designates 12.22.58.30 as permitted sender)
>
> Hi al= l,
>    The intarea WG will be meeting in Paris (we have re= quested a 2 hour
> slot) and we are in the process of setting the age= nda.
Please send us
> your request for slots detailing
>=
> * Name of the draft
> * Short description of why you think t= he item needs to be discussed in
> the intarea meeting
> * Whet= her the draft has already been presented or will be presented in
> so= me other wg/bof.
>
> Thanks
> Julien and Suresh
>> _______________________________________________
> Int-area mai= ling list
> Int-area@ietf.org
>
https://www.ietf.org/mailman/listinfo/int-area
>
_= ______________________________________________
Int-area mailing list
= Int-area@ietf.org
https://www= .ietf.org/mailman/listinfo/int-area

 

= --_000_CE8995AB5D178F44A2154F5C9A97CAF4024FD73BACF0HE111541eme_-- From victor.kuarsingh@gmail.com Thu Mar 15 16:42:11 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E3821E800F for ; Thu, 15 Mar 2012 16:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 QQGAUUv76yCj for ; Thu, 15 Mar 2012 16:42:10 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA1D221E8048 for ; Thu, 15 Mar 2012 16:42:10 -0700 (PDT) Received: by iazz13 with SMTP id z13so5285567iaz.31 for ; Thu, 15 Mar 2012 16:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=ys1aGXhlMdc8xjc36PsWagxa4/3CY8zywyS7rKONZOU=; b=yntxRt2xVKUiicUHLma+WDvnuPTcfWk2OvVvunQ/cO/uQNMCmS3boemxza408PS52R EouP+aQHUUFcathJMRJ2XJMw9adXo5FlwLao6pfIp24R+RKrOqYByEw9vvwhJGw7mXMy Lu39aRPoza1MEubtmE2rmKfmHAB0u0SsY0xdByYEvxsp4Em0Hlxo02lPUk4wTCSFOvzr tEXqUUfbeSYHioRGCgAAEwOIOsedOYq20S+qmWExU3Bo3raltC/pjYlXUy1UvLiwROR8 uCmMvF0oBByjWM1mSqM0I4m09KFPUFOj9gc0rRCTc4/1NAhsDOr5KEL3/RQzbUnwAtgq yIZw== Received: by 10.50.17.234 with SMTP id r10mr11716799igd.9.1331854930242; Thu, 15 Mar 2012 16:42:10 -0700 (PDT) Received: from [192.168.0.17] (CPE0026f32688b8-CM0026f32688b5.cpe.net.cable.rogers.com. [99.229.223.187]) by mx.google.com with ESMTPS id rd7sm2437264igb.14.2012.03.15.16.42.01 (version=SSLv3 cipher=OTHER); Thu, 15 Mar 2012 16:42:08 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 15 Mar 2012 19:41:56 -0400 From: Victor Kuarsingh To: Joe Touch , Warren Kumari Message-ID: Thread-Topic: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt In-Reply-To: <4DF80CCE.6070005@isi.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "Howard, Lee" , "int-area@ietf.org" , "cdl@asgaard.org" Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 23:42:11 -0000 I also support the adoption of this draft. I will supply me with the hammer I need. Regards, Victor Kuarsingh On 11-06-14 9:37 PM, "Joe Touch" wrote: >+1 > >On 6/2/2011 10:17 AM, Warren Kumari wrote: >> >> On Jun 1, 2011, at 10:47 AM, George, Wesley wrote: >> >>> After the discussion of this draft in Prague and with the WG chairs >>>and ADs, we have updated it to address a few comments, but primarily to >>>remove the language directing IETF action. This limits the draft to >>>simply requiring IPv6 for IP-capable devices, and should address the >>>concern about whether it interferes with existing WG actions as well as >>>the recommendation that normally IETF action directions are done via >>>BCP rather than standards-track documents. >>> >>> We would like to ask for formal WG adoption of this draft, as well as >>>reviews to see if it can soon be made ready for WGLC (assuming WG >>>adoption is successful). >> >> I firmly support adoption of this draft.... >> >> (I don't necessarily think it is going to change things much, but I >>believe that it is worth adopting and giving it try...) >> >> W >> >> >>> http://tools.ietf.org/html/draft-george-ipv6-required-02 >>> >>> Any discussion about IETF's response to this draft (in terms of how >>>WGs operate, their charters, etc) will be issued in a separate BCP >>>draft. Right now, we want to focus on getting this draft out so that it >>>can provide guidance to IPv6 implementors. >>> >>> Thanks! >>> >>> Wes George and co-authors. >>> >>> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Wednesday, June 01, 2011 10:30 AM >>> To: George, Wesley >>> Cc: Howard, Lee; Donley, Chris (Cable Labs); George, Wesley; >>>cdl@asgaard.org >>> Subject: New Version Notification for draft-george-ipv6-required-02.txt >>> >>> A new version of I-D, draft-george-ipv6-required-02.txt has been >>>successfully submitted by Wesley George and posted to the IETF >>>repository. >>> >>> Filename: draft-george-ipv6-required >>> Revision: 02 >>> Title: IPv6 Support Required for all IP-capable nodes >>> Creation date: 2011-06-01 >>> WG ID: Individual Submission >>> Number of pages: 7 >>> >>> Abstract: >>> Given the global lack of available IPv4 space, and limitations in >>> IPv4 extension and transition technologies, this document deprecates >>> the concept that an IP-capable node MAY support IPv4 _only_, and >>> redefines an IP-capable node as one which supports either IPv6 >>>_only_ >>> or IPv4/IPv6 dual-stack. This document updates RFC1812, 1122 and >>> 4084 to reflect the change in requirements. >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> 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. >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >>> >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area From julien.ietf@gmail.com Fri Mar 16 07:37:02 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6811321F8714 for ; Fri, 16 Mar 2012 07:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 fOlL+E6d5bmf for ; Fri, 16 Mar 2012 07:37:01 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62BDE21F8703 for ; Fri, 16 Mar 2012 07:37:01 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so5291918vcb.31 for ; Fri, 16 Mar 2012 07:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hGG1ZiugFS7rxuo6E4UjCl3xxGjav6qtgiqTj/2sZOs=; b=w8Q0oucJOG4FDoi+x7w6kCFBcboGf/HNWvOY/spw2/ouyFGAT0hWKA0SbKxFOwiV5C 9AsRQkz2xJCriCONAJLvxVYgZqzzy88pN3q2BX/vS191X76fvTBlsbDZpeZZ0g69CuQe ZayB6i6oqCte3SV+0BA2URGGd5y41TAF367t+LpUCzLNhw5/Bdfu4scMnSY5tzdg9NCd mHgsVtOUlUrTy8qEvKEx27DsC4Kmk7DCrZ79Qu3wuqtd6ArPayIQyXTY8OUrQhZC1+0H zP+MuzFOXd3M7XcmQTHNs4agXBYKTdjE6+zymGuvDj7g5jo/4iK211NTQ6u2nE2uK+v3 8eFA== MIME-Version: 1.0 Received: by 10.52.25.39 with SMTP id z7mr1615599vdf.24.1331908620833; Fri, 16 Mar 2012 07:37:00 -0700 (PDT) Received: by 10.220.91.66 with HTTP; Fri, 16 Mar 2012 07:37:00 -0700 (PDT) In-Reply-To: References: <4DF80CCE.6070005@isi.edu> Date: Fri, 16 Mar 2012 07:37:00 -0700 Message-ID: From: Julien Laganier To: Victor Kuarsingh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Howard, Lee" , "int-area@ietf.org" , "cdl@asgaard.org" Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 14:37:02 -0000 Victor, The draft has been approved for publication by IESG some time ago and is now in the RFC Editor Queue. It should be published soon. Regards, --julien On Thu, Mar 15, 2012 at 4:41 PM, Victor Kuarsingh wrote: > I also support the adoption of this draft. =A0I will supply me with the > hammer I need. > > Regards, > > Victor Kuarsingh > > On 11-06-14 9:37 PM, "Joe Touch" wrote: > >>+1 >> >>On 6/2/2011 10:17 AM, Warren Kumari wrote: >>> >>> On Jun 1, 2011, at 10:47 AM, George, Wesley wrote: >>> >>>> After the discussion of this draft in Prague and with the WG chairs >>>>and ADs, we have updated it to address a few comments, but primarily to >>>>remove the language directing IETF action. This limits the draft to >>>>simply requiring IPv6 for IP-capable devices, and should address the >>>>concern about whether it interferes with existing WG actions as well as >>>>the recommendation that normally IETF action directions are done via >>>>BCP rather than standards-track documents. >>>> >>>> We would like to ask for formal WG adoption of this draft, as well as >>>>reviews to see if it can soon be made ready for WGLC (assuming WG >>>>adoption is successful). >>> >>> I firmly support adoption of this draft.... >>> >>> (I don't necessarily think it is going to change things much, but I >>>believe that it is worth adopting and giving it try...) >>> >>> W >>> >>> >>>> http://tools.ietf.org/html/draft-george-ipv6-required-02 >>>> >>>> Any discussion about IETF's response to this draft (in terms of how >>>>WGs operate, their charters, etc) will be issued in a separate BCP >>>>draft. Right now, we want to focus on getting this draft out so that it >>>>can provide guidance to IPv6 implementors. >>>> >>>> Thanks! >>>> >>>> Wes George and co-authors. >>>> >>>> >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>> Sent: Wednesday, June 01, 2011 10:30 AM >>>> To: George, Wesley >>>> Cc: Howard, Lee; Donley, Chris (Cable Labs); George, Wesley; >>>>cdl@asgaard.org >>>> Subject: New Version Notification for draft-george-ipv6-required-02.tx= t >>>> >>>> A new version of I-D, draft-george-ipv6-required-02.txt has been >>>>successfully submitted by Wesley George and posted to the IETF >>>>repository. >>>> >>>> Filename: =A0 =A0 =A0 =A0draft-george-ipv6-required >>>> Revision: =A0 =A0 =A0 =A002 >>>> Title: =A0 =A0 =A0 =A0 =A0 IPv6 Support Required for all IP-capable no= des >>>> Creation date: =A0 2011-06-01 >>>> WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission >>>> Number of pages: 7 >>>> >>>> Abstract: >>>> =A0 =A0Given the global lack of available IPv4 space, and limitations = in >>>> =A0 =A0IPv4 extension and transition technologies, this document depre= cates >>>> =A0 =A0the concept that an IP-capable node MAY support IPv4 _only_, an= d >>>> =A0 =A0redefines an IP-capable node as one which supports either IPv6 >>>>_only_ >>>> =A0 =A0or IPv4/IPv6 dual-stack. =A0This document updates RFC1812, 1122= and >>>> =A0 =A04084 to reflect the change in requirements. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>>> 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. >>>> _______________________________________________ >>>> Int-area mailing list >>>> Int-area@ietf.org >>>> https://www.ietf.org/mailman/listinfo/int-area >>>> >>> >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >>_______________________________________________ >>Int-area mailing list >>Int-area@ietf.org >>https://www.ietf.org/mailman/listinfo/int-area > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From denghui02@gmail.com Wed Mar 21 18:49:54 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359B821E8015; Wed, 21 Mar 2012 18:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.37 X-Spam-Level: X-Spam-Status: No, score=-103.37 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 LeuIIPQTwqCg; Wed, 21 Mar 2012 18:49:53 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACBC21E800C; Wed, 21 Mar 2012 18:49:53 -0700 (PDT) Received: by yenm5 with SMTP id m5so1618625yen.31 for ; Wed, 21 Mar 2012 18:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=j5dWFsWs95m5VbEDQPgAQLeC7hO7tS6sD+ItVuJ8w8c=; b=pTRphpzZk8lS55R1Ur6dn+CQKFpClkKzYKAx3NZA1n+q9iaErblLsfpVTAu5+G8U77 fE7Lq7kPs+EnwbXwcD1Pfi/e8C3smgepYuUbzhRD1r9Z5/hcxMuRvWCX4+iWGtVdV9vm x2i2DP3yTIKU5CHeG59QmiScDeKnUz2WXJb90ITlXHRdGXK+tmctg3EdSMblzj+y/trn j9G+YnXVYyVwECvJStHcrRyF7ecnoLZMyDw2uK74OvHzCwS9RZCGpR76+LFUuDJ5EDYy rAeabZPuoy63lVEM7/fFmLzYR3VdPnSPLQsE+FUS+T+XrvQEQZqBC0SXRSh7Zepeebqx IZUg== MIME-Version: 1.0 Received: by 10.101.128.14 with SMTP id f14mr1886430ann.21.1332380992977; Wed, 21 Mar 2012 18:49:52 -0700 (PDT) Received: by 10.147.112.1 with HTTP; Wed, 21 Mar 2012 18:49:52 -0700 (PDT) Date: Thu, 22 Mar 2012 09:49:52 +0800 Message-ID: From: Hui Deng To: MIF Mailing List , IETF Discussion , Internet Area Content-Type: multipart/alternative; boundary=001636c597a3cabbcb04bbcb1f26 Subject: [Int-area] OMA IETF MIF API Workshop X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 01:49:54 -0000 --001636c597a3cabbcb04bbcb1f26 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable OMA IETF MIF API Workshop Time: Tuesday: 18:10-20:00 Location: TBD 1) Program 1.1) OMA OpenCMAPI activity (Thierry) 1.2) IETF MIF API Design (Ted Lemon) 1.3) IETF API related work (TBD) 1.4) OMA API Program (OMA Member) 1.5) Vendor's today implementation (Maybe) 1.6) Next step between IETF and OMA (Thierry and Hui) 2) Purpose 2.1) From IETF, this workshop would help to explain the API related topic, and clarify what is recommended and not recommended to do and standardized, if possible, either publish a information document or adding word into the current MIF api draft about how to use those MIF API for Internet developer= . and some current practices information how today smart terminal is doing. 2.2) From OMA perspective, to socialize OMA=92s published specifications an= d current ongoing standards activities in the area of APIs. To make sure that the standards landscape for APIs is coordinated and harmonized. To solicit feedback about OMA=92s specification for Authorization4APIs, which is built on IETF OAuth as well as OpenCMAPI. 3) Outcomes: 3.1) Future work about how to use those MIF API in an IETF information document or inside current MIF API documentfor Internet developers. 3.2) Outcomes OMA: Improved understanding of each others=92 activities, and a coordinated approach going forward 3.3) Better mutual understanding of the work of both organizations, and how to cooperate in the future. --001636c597a3cabbcb04bbcb1f26 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable OMA IETF MIF API Workshop
=A0
Time: Tuesday: 18:10-20:00
Location:= TBD
=A0
1) Program
1.1) OMA OpenCMAPI activity (Thierry)
1.2= ) IETF MIF API Design (Ted Lemon)
1.3) IETF API related work (TBD)
1= .4) OMA API Program (OMA Member)
1.5) Vendor's today implementation (Maybe)
1.6) Next step between IE= TF and OMA (Thierry and Hui)
=A0
2) Purpose
2.1) From IETF, this w= orkshop would help to explain the API related topic,
and clarify what is= recommended and not recommended to do and standardized,
if possible, either publish a information document or adding word into the =
current MIF api draft about how to use those MIF API for Internet devel= oper.
and some current practices information how today smart terminal is= doing.
=A0
2.2) From OMA perspective, to socialize OMA=92s published specificat= ions and
current ongoing standards activities in the area of APIs. To m= ake sure that
the standards landscape for APIs is coordinated and harmo= nized. To solicit
feedback about OMA=92s specification for Authorization4APIs, which is built=
on IETF OAuth as well as OpenCMAPI.
=A0
3) Outcomes:
3.1) Fut= ure work about how to use those MIF API in an IETF information
=A0docum= ent or inside current MIF API documentfor Internet developers.

3.2) Outcomes OMA: Improved understanding of each others=92 activities,=
=A0and a coordinated approach going forward

3.3) Better mutual u= nderstanding of the work of both organizations,
=A0and how to cooperate= in the future. --001636c597a3cabbcb04bbcb1f26-- From sarikaya2012@gmail.com Fri Mar 23 08:55:36 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8AF21F8597; Fri, 23 Mar 2012 08:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 npiY2egdMBc1; Fri, 23 Mar 2012 08:55:32 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0E621F857A; Fri, 23 Mar 2012 08:55:32 -0700 (PDT) Received: by iazz13 with SMTP id z13so5679491iaz.31 for ; Fri, 23 Mar 2012 08:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=y3PclEIu+XdLv3VPjFNOHZs0r8+OsImn+z/SUtUDkkk=; b=XH5ViN806RBefSL8L5PQ8PCtSglJEuQl0NHbJ05XcBGVWqc8mGNT8IpYuAUsVP1Gbf 5dvjV86/n9TJQf8iL7PIwYqVDprwRIIZUlR7pNEZB1Bu6rZvtdaL1ZXw1bb118aPD2qk XR98i/FeeLcC+caOm41cDCLC/f0s92PiJ9lxDoo1/NOMs8AnvYmLAl9tsEz2fV5ssWgE /CnWX1ySzquhrTEh+70ikPYy7enOht3K6KwLR+FFWlB8ySEg8saH72JxEMV+jfN+Zk4W qnhJmlsi5Da+WJGDYW6JqbiNbP9nBT3cLj3fHNw3Dy8yznbKVqYnJf6RfodndN4dazXP AUlw== MIME-Version: 1.0 Received: by 10.50.189.129 with SMTP id gi1mr2551299igc.16.1332518131809; Fri, 23 Mar 2012 08:55:31 -0700 (PDT) Received: by 10.231.179.71 with HTTP; Fri, 23 Mar 2012 08:55:31 -0700 (PDT) Date: Fri, 23 Mar 2012 10:55:31 -0500 Message-ID: From: Behcet Sarikaya To: Internet Area Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org, mip4@ietf.org, multimob@ietf.org, dmm@ietf.org, Dirk.von-Hugo@telekom.de Subject: [Int-area] FMC Side Meeting Announcement X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 15:55:36 -0000 Side meeting on Fixed Mobile Convergence will take place on Thursday March 29, 2012 from 18:10 to 20:00 at room 212-213. The agenda and materials are posted at: http://www-etud.iro.umontreal.ca/~sarikaya/fmc/fmc.html Come and join us in this meeting. Behcet & Dirk From sarikaya2012@gmail.com Sun Mar 25 13:41:09 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBCE21E801B; Sun, 25 Mar 2012 13:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 gD7Ca-8Az6OK; Sun, 25 Mar 2012 13:41:09 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A91E321E801A; Sun, 25 Mar 2012 13:41:08 -0700 (PDT) Received: by iazz13 with SMTP id z13so8527345iaz.31 for ; Sun, 25 Mar 2012 13:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=rm5Ri9JI8gtkv5QlDwhU9Y8LU4mFzLqS4ANJdv+qAF4=; b=ZHSaz6+K0+qNKZJ6spN0cPIL5q+Ghg+Wf4N19NKGD+G+eDYA5c0dj/qTyk6VY+VuhJ LZg/sbCQVOO9au0Au6tmmRjbi4Gm8CTZzOo1G0Rxuh87OYvDzJXKScdUQmjZ2AjLlA/z umk49ryUg0jEbtm17kpKrDYH7TaHJZYvPrcn1XK4s5VWnnOQKSrj3kla/lIhjjJ9dC/8 RhHZ0RdvcRuegH+Cok+IGlKxikBMMugC3i39VPB1j106MCZOivpeJW8ul2cFH2yfDnYf O1Z9/XLJGWCmb9EzlAg7cQoM8898XvxkWr9wON5Co24R2xRrEKjTXAsk49NEBpoa+667 6I0w== MIME-Version: 1.0 Received: by 10.50.203.99 with SMTP id kp3mr3951191igc.16.1332708068305; Sun, 25 Mar 2012 13:41:08 -0700 (PDT) Received: by 10.231.179.71 with HTTP; Sun, 25 Mar 2012 13:41:08 -0700 (PDT) Date: Sun, 25 Mar 2012 15:41:08 -0500 Message-ID: From: Behcet Sarikaya To: Internet Area Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org, mip4@ietf.org, multimob@ietf.org, dmm@ietf.org, Dirk.von-Hugo@telekom.de Subject: [Int-area] FMC Final Date & Time: Tuesday X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 20:41:09 -0000 IETF could not find us an appropriate room so as a result we will hold FMC meeting at the original time. Details are below: Tuesday March 27 at 19:30 or 7:30 Meet at Hotel Concorde Lobby Take a look at the materials at the link given below. On Fri, Mar 23, 2012 at 10:55 AM, Behcet Sarikaya wrote: > Side meeting on Fixed Mobile Convergence will take place on Thursday > March 29, 2012 > from 18:10 to 20:00 at room 212-213. > > The agenda and materials are posted at: > http://www-etud.iro.umontreal.ca/~sarikaya/fmc/fmc.html > > Come and join us in this meeting. Behcet & Dirk From denghui02@gmail.com Mon Mar 26 10:28:52 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512C221E80BC; Mon, 26 Mar 2012 10:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.381 X-Spam-Level: X-Spam-Status: No, score=-103.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 H3zeu6uB39Xu; Mon, 26 Mar 2012 10:28:51 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E40DD21E80E5; Mon, 26 Mar 2012 10:28:50 -0700 (PDT) Received: by yenm5 with SMTP id m5so4465469yen.31 for ; Mon, 26 Mar 2012 10:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=E/RzDaHuekNZWCc1VMUlQY/8x40p/ArRb4iArllNmIg=; b=Pp5LSlX2DP7rIwDrKzJx6/xdoWrR6XGneLrVVavgd1/WWDtucQpp7KgITFlERkMQBd Vsx0BGRcPcXOrEBE/J90mkcAt+gWBPJik+ubUAXTpMSEi1xOROO3WJkiJUkFuENRzvN+ 1KAwUQncqfvlVYxyp6kMvY6ojvd7fpX0mVkSFJmN2LZShoPbYEkn4bvF2nz3dSmuTV4a 4n3heGZDa8XSky7OBhu9WrNhCt/I3PfRa34H1/5T+HXBcf7rd7cQGA+FJYdAxYuVSdqN 2EwDaOjHexvLgN/1ZlpGrfeNLh0MikvnRyYCQxITTBFIA0HP98Gb29bnqHXnpL7GzdD/ xM8w== MIME-Version: 1.0 Received: by 10.236.46.232 with SMTP id r68mr23062351yhb.80.1332782930398; Mon, 26 Mar 2012 10:28:50 -0700 (PDT) Received: by 10.146.20.14 with HTTP; Mon, 26 Mar 2012 10:28:50 -0700 (PDT) Date: Mon, 26 Mar 2012 19:28:50 +0200 Message-ID: From: Hui Deng To: MIF Mailing List , Internet Area , IETF Discussion Content-Type: multipart/alternative; boundary=20cf303bfe24210f7f04bc28b539 Cc: thierry.berisot@telekom.de, jerry.shih@att.com, liliana.dinale@ericsson.com, Ralph Droms , msk@cloudmark.com Subject: [Int-area] OMA IETF MIF API Workshop - Room info X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 17:28:52 -0000 --20cf303bfe24210f7f04bc28b539 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable OMA IETF MIF API Workshop Time: Tuesday: 18:10-20:00 Location: room 212/213 1) Program 1.1) OMA OpenCMAPI activity (Thierry Berisot, OMA) 1.2) IETF MIF API Design (Ted Lemon, IETF) 1.3) IETF API related consideration (TBD) 1.4) OMA API Program (Liliana Dinale, OMA) 1.5) Vendor's today implementation (Maybe) 1.6) Next step between IETF and OMA (Thierry, Margaret, and Hui) 2) Purpose 2.1) From IETF, this workshop would help to explain the API related topic, and clarify what is recommended and not recommended to do and standardized, if possible, either publish a information document or adding word into the current MIF api draft about how to use those MIF API for Internet developer= . and some current practices information how today smart terminal is doing. 2.2) From OMA perspective, to socialize OMA=92s published specifications an= d current ongoing standards activities in the area of APIs. To make sure that the standards landscape for APIs is coordinated and harmonized. To solicit feedback about OMA=92s specification for Authorization4APIs, which is built on IETF OAuth as well as OpenCMAPI. 3) Outcomes: 3.1) Future work about how to use those MIF API in an IETF information document or inside current MIF API documentfor Internet developers. 3.2) Outcomes OMA: Improved understanding of each others=92 activities, and a coordinated approach going forward 3.3) Better mutual understanding of the work of both organizations, and how to cooperate in the future. --20cf303bfe24210f7f04bc28b539 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

OMA IETF MIF API Workshop
=A0
Time: Tuesday: 18:10-20:00
Locati= on: room 212/213
=A0
1) Program
1.1) OMA OpenCMAPI activity (Thier= ry Berisot, OMA)
1.2) IETF MIF API Design (Ted Lemon, IETF)
1.3) IET= F API related consideration (TBD)
1.4) OMA API Program (Liliana Dinale, OMA)
1.5) Vendor's today impl= ementation (Maybe)
1.6) Next step between IETF and OMA (Thierry, Margare= t, and Hui)
=A0
2) Purpose
2.1) From IETF, this workshop would hel= p to explain the API related topic,
and clarify what is recommended and not recommended to do and standardized,=
if possible, either publish a information document or adding word into= the
current MIF api draft about how to use those MIF API for Internet = developer.
and some current practices information how today smart terminal is doing. <= br>=A0
2.2) From OMA perspective, to socialize OMA=92s published specifi= cations and
current ongoing standards activities in the area of APIs. T= o make sure that
the standards landscape for APIs is coordinated and harmonized. To solicit =
feedback about OMA=92s specification for Authorization4APIs, which is b= uilt
on IETF OAuth as well as OpenCMAPI.
=A0
3) Outcomes:
3.1)= Future work about how to use those MIF API in an IETF information
=A0document or inside current MIF API documentfor Internet developers.

3.2) Outcomes OMA: Improved understanding of each others=92 activities,<= br>=A0and a coordinated approach going forward

3.3) Better mutual understanding of the work of both organizations,
= =A0and how to cooperate in the future.

--20cf303bfe24210f7f04bc28b539-- From cjbc@it.uc3m.es Tue Mar 27 08:36:32 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09C821E822F for ; Tue, 27 Mar 2012 08:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.505 X-Spam-Level: X-Spam-Status: No, score=-5.505 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 eG8Jn9KEwbmK for ; Tue, 27 Mar 2012 08:36:30 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFD521E8239 for ; Tue, 27 Mar 2012 08:36:29 -0700 (PDT) X-uc3m-safe: yes Received: from [130.129.83.185] (dhcp-53b9.meeting.ietf.org [130.129.83.185]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id EEBA49CB601 for ; Tue, 27 Mar 2012 17:36:27 +0200 (CEST) Message-ID: <1332862587.5725.147.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Internet Area Date: Tue, 27 Mar 2012 17:36:27 +0200 Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-5Ag5fOs8gv0V+83hrJ91" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18802.000 Subject: [Int-area] [Fwd: [DMM] Network-based DMM demo (Thu 15:30 room 251)] X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:36:32 -0000 --=-5Ag5fOs8gv0V+83hrJ91 Content-Type: multipart/mixed; boundary="=-CRF6uLTW222CC7C7BiK4" --=-CRF6uLTW222CC7C7BiK4 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable FYI --=20 Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-CRF6uLTW222CC7C7BiK4 Content-Disposition: inline Content-Description: Forwarded message - [DMM] Network-based DMM demo (Thu 15:30 room 251) Content-Type: message/rfc822 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on antispam.uc3m.es X-Spam-Level: X-Spam-Status: No, score=-100.7 required=3.0 tests=AWL,BAYES_00,UC3M_SAFE autolearn=unavailable version=3.1.7-deb X-Original-To: cjbc@it.uc3m.es Delivered-To: cjbc@correo03.uc3m.es Received: from smtp02.uc3m.es (pip-L01.uc3m.es [163.117.176.61]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by correo03.uc3m.es (Postfix) with ESMTPS id C498FE010; Tue, 27 Mar 2012 17:35:21 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by smtp02.uc3m.es (Postfix) with ESMTP id 83074716230; Tue, 27 Mar 2012 17:35:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1332862512; bh=EZAvF66V2cdWomZpObQ9dLGaGLMJpspGB0IMXb48A2I=; h=Message-ID:From:To:Date:Mime-Version:Cc:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=D9spb1pxShZKocOxDPlcbLLm9Szlqrc1u/RUS27j9FUblRtoncrXSMr9rmZA7Xklw Ya/ToK7jyeLL3yLwZ2HaAGby3/idHIAJZDVwk83p+3kojawG5IjDo5n+E13m5sy6mP oNJOYFT0zAvLM0KkT9b3qTo/B1hbKAUUF1QldAZE= X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE6421E81F5; Tue, 27 Mar 2012 08:35:00 -0700 (PDT) X-uc3m-safe: yes Received: from [130.129.83.185] (dhcp-53b9.meeting.ietf.org [130.129.83.185]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 2950E75A3BC; Tue, 27 Mar 2012 17:34:56 +0200 (CEST) Message-ID: <1332862493.5725.146.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: dmm@ietf.org, netext@ietf.org Date: Tue, 27 Mar 2012 17:34:53 +0200 Organization: Universidad Carlos III de Madrid X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18802.000 Cc: Telemaco Melia Subject: [DMM] Network-based DMM demo (Thu 15:30 room 251) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7829640300332790095==" Sender: dmm-bounces@ietf.org Errors-To: dmm-bounces@ietf.org --===============7829640300332790095== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-iuAzEUYlIORnzoDwq0/v" --=-iuAzEUYlIORnzoDwq0/v Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi all, We'd like to announce that our network-based DMM demo will take place on Thursday at 15:30 in room 251. The demo will show a Linux-based prototype based on [1] and [2] running on a live setup. The setup is composed of three "anchor routers", a "centralized LMA" for control plane, a couple of correspondent nodes (a netbook and an IPv6 camera) and a legacy IPv6 mobile node (a netbook). Looking forward to seeing you there and getting your feedback. Thanks, Carlos, Telemaco and Juan Carlos [1] http://tools.ietf.org/html/draft-bernardos-dmm-pmip-01 [2] http://tools.ietf.org/html/draft-bernardos-dmm-distributed-anchoring-00 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-iuAzEUYlIORnzoDwq0/v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk9x3h0ACgkQNdy6TdFwT2c0RwCgiROija/bDtjmdupZdbHZpO+a wTAAn1JgCe7c8OjI1iUsfOhHN5h2CoCI =O6Ui -----END PGP SIGNATURE----- --=-iuAzEUYlIORnzoDwq0/v-- --===============7829640300332790095== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --===============7829640300332790095==-- --=-CRF6uLTW222CC7C7BiK4-- --=-5Ag5fOs8gv0V+83hrJ91 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk9x3nsACgkQNdy6TdFwT2cUBwCeOCoxseX9tDNohbR4Hsl6xyu7 8NUAoKeGH7cj5c52qR7RYn3W0/GLpjvo =elB+ -----END PGP SIGNATURE----- --=-5Ag5fOs8gv0V+83hrJ91-- From Francis.Dupont@fdupont.fr Thu Mar 29 04:53:14 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD2C21F88FB for ; Thu, 29 Mar 2012 04:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 qSrOAPBGKPQd for ; Thu, 29 Mar 2012 04:53:14 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id C163821F8870 for ; Thu, 29 Mar 2012 04:53:13 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2TBr60p098774 for ; Thu, 29 Mar 2012 13:53:06 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203291153.q2TBr60p098774@givry.fdupont.fr> From: Francis Dupont To: int-area@ietf.org Date: Thu, 29 Mar 2012 13:53:06 +0200 Sender: Francis.Dupont@fdupont.fr Subject: [Int-area] about draft-ietf-intarea-nat-reveal-analysis-01.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:53:14 -0000 I still deeply dislike the reveal idea but at least the new version has a decent privacy implication part. As I don't want to get the IETF associated with names like Amesys or Blue Coat, I suggest to use only negative recommendations at the exception of one mechanism so nobody should be able to say we (the IETF) have recommended such a mechanism. Regards Francis.Dupont@fdupont.fr PS: Winston Churchill quote: "It has been said that democracy is the worst form of government except all the others that have been tried." PPS: in the case google was hacked to not help you: amesys lybia (3rd suggestion on amesys, which btw is to be sold :-) bluecoat syria (these prove that an active technology is unfortunately not so needed) From mohamed.boucadair@orange.com Thu Mar 29 07:59:07 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B34321E81B3 for ; Thu, 29 Mar 2012 07:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] 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 y160eYxoUaRQ for ; Thu, 29 Mar 2012 07:59:06 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 35D9121E809C for ; Thu, 29 Mar 2012 07:59:00 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id CFCB93B4554; Thu, 29 Mar 2012 16:58:58 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id B202D27C058; Thu, 29 Mar 2012 16:58:58 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 29 Mar 2012 16:58:58 +0200 From: To: "int-area@ietf.org" Date: Thu, 29 Mar 2012 16:58:57 +0200 Thread-Topic: Request to review Privacy Section of HOST_ID I-D Thread-Index: Ac0NvHeXZZHZXqSGT1ytAEpKOS5qXQ== Message-ID: <94C682931C08B048B7A8645303FDC9F36E28733921@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E28733921PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.21.123317 Cc: LEVIS Pierre RD-BIZZ , Reinaldo Penno Subject: [Int-area] Request to review Privacy Section of HOST_ID I-D X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:59:07 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E28733921PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, As mentioned during the intarea presentation, I would welcome reviews from = the WG regarding the privacy discussion (Section 4): http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-01#sectio= n-4 Text contributions are also more than welcome. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F36E28733921PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D= ear=20 all,
 
A= s mentioned=20 during the intarea presentation, I would welcome reviews from the WG regard= ing=20 the privacy discussion (Section 4):
<= A=20 href=3D"http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-0= 1#section-4">http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analy= sis-01#section-4
 
T= ext=20 contributions are also more than welcome.
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F36E28733921PUEXCB1Bnante_-- From cabo@tzi.org Fri Mar 30 05:43:51 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7069221F853A for ; Fri, 30 Mar 2012 05:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.205 X-Spam-Level: X-Spam-Status: No, score=-106.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 ZuqOANoMas+o for ; Fri, 30 Mar 2012 05:43:50 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC8721F84C9 for ; Fri, 30 Mar 2012 05:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2UChA1d024430 for ; Fri, 30 Mar 2012 14:43:13 +0200 (CEST) Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41481258; Fri, 30 Mar 2012 14:43:06 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1257) From: Carsten Bormann Date: Fri, 30 Mar 2012 14:43:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3A9E203F-588B-4AF2-B2AF-45CFA2D39835@tzi.org> To: int-area@ietf.org X-Mailer: Apple Mail (2.1257) Subject: [Int-area] Fwd: IPv6 over Bluetooth Low-Energy (BT-LE): Please review draft-ietf-6lowpan-btle-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 12:43:51 -0000 From: Carsten Bormann Subject: IPv6 over Bluetooth Low-Energy (BT-LE): Please review = draft-ietf-6lowpan-btle-06.txt Date: March 30, 2012 14:35:37 +0200 To: 6lowpan@ietf.org, intarea@ietf.org draft-ietf-6lowpan-btle has passed working-group last call in the = 6LoWPAN Working Group in January. While preparing IESG submission, I noticed a few more things that needed = to be taken care of. This led to draft-ietf-6lowpan-btle-06.txt, which should have all these = items fixed. However, I believe the draft would benefit from a bit more eyeballs = before I send it on to the IESG. -- could you implement IPv6 over BT-LE from this draft (and its = normative references),=20 or is anything that would be important for interoperability left = unspecified? -- general comments about draft quality and the technical decisions = taken are also welcome. I'm asking for feedback from the intarea working group as well as the = 6lowpan working group. The draft is only 12 pages, so this can be done quickly. Please reply until Friday, April 13, 2012. ( Bluetooth Low-Energy is also known as Bluetooth Smart, a part of = Bluetooth 4. =20 The iPhone 4S has it. Zillions of IPv6 packets will flow over it. So you really want to review this draft! ) Gr=FC=DFe, Carsten