From tireddy@cisco.com Thu Aug 1 00:52:34 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6125D21F9E02 for ; Thu, 1 Aug 2013 00:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 zV7tdqoplLXB for ; Thu, 1 Aug 2013 00:52:29 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0601121F8D6D for ; Thu, 1 Aug 2013 00:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6894; q=dns/txt; s=iport; t=1375343533; x=1376553133; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DV8SpNlkOEZ8TpIEufFno6o2k+9iWjpy03LlCUczbhI=; b=YyPqhwfzLWMYhOYaBHTuZwIr6T3d3zF2Vmg0DlXsw8UU9uG9Ze9yOsFV eFvll2upOOrlCG5dK4f0a4zV3kA2rjFyeKJqOH4vQHEu14fFSduGqoIxc WTQlIOFZcNRarwQLmSvcROMJtL168M3qifqXYm3cLdnShsLxYGDeF7xIl I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAIES+lGtJV2Y/2dsb2JhbABbgwY1UIMQuzwXgQcWdIIkAQEBBAEBASAROgsQAgEIDgMEAQEDAgYODwMCAgIlCxQBCAgCBAENBQiICAynXZFQgSiLX4E4gRcxBwYSgk0zcwOZCJAkgxSBaAcCFyI X-IronPort-AV: E=Sophos;i="4.89,792,1367971200"; d="scan'208";a="241936853" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 01 Aug 2013 07:52:11 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r717qBXe017938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Aug 2013 07:52:11 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 1 Aug 2013 02:52:11 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Justin Uberti , Marc Petit-Huguenin Thread-Topic: [BEHAVE] Comments on the TURN REST Server API presentation Thread-Index: AQHOjiBFpEo4ItDKvEeFioaMwxZH3Jl/+CSw Date: Thu, 1 Aug 2013 07:52:10 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A19009729@xmb-rcd-x10.cisco.com> References: <51F742F8.3070903@acm.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.54.98] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Behave@ietf.org" Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 07:52:34 -0000 PlRoZSBvdGhlcnMgKHJ0Y3dlYiBwYXNzd29yZCBleHBvc3VyZSwgVFVSTiBjcmVkZW50aWFsIERC KSBhcmUgYWRkcmVzc2VkIGJ5IHRoZSBlcGhlbWVyYWwvdG9rZW4gYmFzZWQgYXBwcm9hY2guIFRo ZXJlIHNlZW1zIHRvIGJlIGEgZ2VuZXJhbCBkZXNpcmUgdG8gZG8gPnRoaXMgdGhyb3VnaCBPQXV0 aCwgdXNpbmcgZWl0aGVyIG5vcm1hbCB0b2tlbnMgdGhhdCBhcmUgY2hlY2tlZCBiYWNrIGFnYWlu c3QgdGhlIEFTLCBvciBzZWxmLWNvbnRhaW5lZCB0b2tlbnMgd2hpY2ggY2FuIGJlIGNoZWNrZWQg ZGlyZWN0bHkgYXQgdGhlIFRVUk4gPnNlcnZlciwgc28gSSB3aWxsIGxvb2sgYXQgdXBkYXRpbmcg dGhlIGRyYWZ0IHRvIHVzZSBPQXV0aC4gVGhpcyB3aWxsIGFsc28gcmVzb2x2ZSB0aGUgaXNzdWVz IHJhaXNlZCBhYm91dCBob3cgc2VwYXJhdGUgd2ViIGFuZCBUVVJOIHNlcnZlcnMgY2FuIHNoYXJl IGEgPnNlY3JldC7CoA0KDQpPQXV0aCBSRkMgNjgxOSBkaXNjdXNzZXMgdGhlIHByb3MvY29ucyBv ZiBzZWxmLWNvbnRhaW5lZCB0b2tlbiB2ZXJzZXMgaGFuZGxlIHRva2VuLiANCg0KPlRoZSBtYWlu IHF1ZXN0aW9uIGhlcmUgaXMgd2hldGhlciB0aGlzIHJlcXVpcmVzIGFuIHVwZGF0ZSB0byB0aGUg VFVSTiBwcm90b2NvbCB0byBzcGVjaWZ5IGEgdG9rZW4tYmFzZWQgYXV0aCBtZWNoYW5pc20sIG9y IGlmIGl0IGlzIHBvc3NpYmxlIHRvIG92ZXJsb2FkID50aGUgbG9uZy10ZXJtIGF1dGggbWVjaGFu aXNtLCBzaW5jZSBJIHRoaW5rIHRoZXkgd2lsbCBiZSBmYWlybHkgc2ltaWxhciBpbiBvcGVyYXRp b24uDQoNCklmIGxldCdzIHNheSBzZWxmLWNvbnRhaW5lZC9oYW5kbGUgdG9rZW4gaXMgc2VsZWN0 ZWQgdGhlbiB0aGVyZSBpcyBubyBuZWVkIHRvIHNlbmQgYW55IFVTRVJOQU1FLCBuZXcgU1RVTiBh dHRyaWJ1dGUgdG8gaW5kaWNhdGUgVFVSTiBzZXJ2ZXIgc3VwcG9ydHMgdGhpcyBuZXcgbWVjaGFu aXNtLCBuZXcgU1RVTiBhdHRyaWJ1dGUgdG8gc2VuZCB0aGUgdG9rZW4gdG8gVFVSTiBzZXJ2ZXIg ZXRjLiANClBDUCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aW5nLXBjcC10aGly ZC1wYXJ0eS1hdXRoei0wMCBhbHNvIHVzZXMgc2ltaWxhciB0ZWNobmlxdWUuDQoNCi0tVGlydS4N Cg0KRnJvbTogSnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbV0gDQpTZW50 OiBXZWRuZXNkYXksIEp1bHkgMzEsIDIwMTMgNToyNyBQTQ0KVG86IE1hcmMgUGV0aXQtSHVndWVu aW4NCkNjOiBCZWhhdmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQkVIQVZFXSBDb21tZW50cyBv biB0aGUgVFVSTiBSRVNUIFNlcnZlciBBUEkgcHJlc2VudGF0aW9uDQoNCg0KT24gVHVlLCBKdWwg MzAsIDIwMTMgYXQgNjozNyBBTSwgTWFyYyBQZXRpdC1IdWd1ZW5pbiA8cGV0aXRodWdAYWNtLm9y Zz4gd3JvdGU6DQotLS0tLUJFR0lOIFBHUCBTSUdORUQgTUVTU0FHRS0tLS0tDQpIYXNoOiBTSEEy NTYNCg0KQWJvdXQgdGhpcyBwcmVzZW50YXRpb24sIEkgYWdyZWUgd2l0aCB3aGF0IE1hcnRpbiBU aG9tc29uIHNhaWQgb24gdGhlDQptaWNyb3Bob25lICh0cnlpbmcgdG8gcGFyYXBocmFzZSBmcm9t IG1lbW9yeSBhcyB0aGUgYXVkaW8gcmVjb3JkaW5nIGlzIG5vdA0KYXZhaWxhYmxlIHlldCk6IMKg VGhlcmUgaXMgbm8gbmVlZCB0byBzdGFuZGFyZGl6ZSBhIFJFU1RmdWwgQVBJIGJlY2F1c2UgdGhl DQpzZXJ2ZXIgY2FuIHNlbmQgdGhlIHVzZXJuYW1lL3Bhc3N3b3JkIGluIHRoZSB3ZWIgcGFnZSB0 aGF0IHVzZXMgcnRjd2ViLCBvciBjYW4NCnVzZSBhbnkgcHJvcHJpZXRhcnkgQVBJIGJldHdlZW4g dGhlIGphdmFzY3JpcHQgY2xpZW50IGFuZCB0aGUgc2VydmVyLiDCoFRoZXJlDQppcyBubyBpbnRl cm9wZXJhYmlsaXR5IGlzc3VlIGhlcmUuDQoNCkkgdGhpbmsgcnRjd2ViIChpbmNsdWRpbmcgbm9u LWJyb3dzZXIgY2xpZW50cykgd291bGQgYmVuZWZpdCBmcm9tIGhhdmluZyBhIGNvbW1vbiBpbnRl cmZhY2UgZGVmaW5lZCB0byBnZXQgYWNjZXNzIHRvIFRVUk4gc2VydmVycywgc28gdGhhdCBpdCB3 b3VsZCBiZSBlYXN5IHRvIHVzZSBkaWZmZXJlbnQgcHJvdmlkZXJzLiBCdXQgcGVyaGFwcyB0aGUg SUVURiBpcyBub3QgdGhlIHJpZ2h0IGZvcnVtIGZvciB0aGlzLg0KwqANCg0KU2Vjb25kLCBJIGRv IG5vdCB0aGluayB0aGF0IHRyeWluZyB0byBvdmVybG9hZCB0aGUgbG9uZy10ZXJtIGF1dGhlbnRp Y2F0aW9uDQptZWNoYW5pc20gaXMgd2lzZSAtIGFuZCBJIHRha2UgZXhjZXB0aW9ucyB3aXRoIHRo ZSBwcmV2aW91cyBwcmVzZW50YXRpb24gdGhhdA0KY2hhcmFjdGVyaXplZCBsb25nLXRlcm0gYXV0 aGVudGljYXRpb24gYXMgaGF2aW5nIHByb2JsZW1zLiDCoFRoaXMgaXMgaG93DQpsb25nLXRlcm0g YXV0aGVudGljYXRpb24gd29ya3MsIGFuZCB0aGF0IHNob3VsZCBiZSBsZWZ0IGFsb25lLiDCoElN TyB3aGF0IGlzDQpuZWVkZWQgaXMgdG8gZGVzaWduIGEgdGhpcmQgYXV0aGVudGljYXRpb24gb3B0 aW9uIGZvciBUVVJOIChwcm9iYWJseSB3aXRoIG5ldw0KYXR0cmlidXRlcykgdGhhdCBpcyBkb2lu ZyB0aGUgdXNlcm5hbWUvcGFzc3dvcmQgc3RhdGVsZXNzIHZlcmlmaWNhdGlvbi4gwqBIZXJlDQp0 aGVyZSBpcyBhIG5lZWQgdG8gZGVmaW5lIGhvdyB0aGUgd2ViIHNlcnZlciBhbmQgdGhlIHR1cm4g c2VydmVyIGNhbg0KZ2VuZXJhdGUvdmVyaWZ5IHRoZSBzYW1lIHVzZXJuYW1lL3Bhc3N3b3JkLCBz byBhbiBJLUQgaXMgcmVxdWlyZWQgdG8gZW5zdXJlDQppbnRlcm9wZXJhYmlsaXR5Lg0KDQpJIHRo aW5rIGl0J3MgY2xlYXIgdGhhdCB0aGVyZSBhcmUgbGltaXRhdGlvbnMgdG8gbG9uZy10ZXJtIGF1 dGhlbnRpY2F0aW9uLiBTb21lIChjbGVhcnRleHQgVVNFUk5BTUUsIGRpY3Rpb25hcnkgYXR0YWNr cyBvbiBNLUkpIGNhbiBiZSBsYXJnZWx5IG1pdGlnYXRlZCBpZiB3ZSBhZGQgc3VwcG9ydCBmb3Ig VFVSTiBvdmVyIERUTFMsIHdoaWNoIEkgdGhpbmsgaXMgYSBnb29kIGlkZWEuDQoNClRoZSBvdGhl cnMgKHJ0Y3dlYiBwYXNzd29yZCBleHBvc3VyZSwgVFVSTiBjcmVkZW50aWFsIERCKSBhcmUgYWRk cmVzc2VkIGJ5IHRoZSBlcGhlbWVyYWwvdG9rZW4gYmFzZWQgYXBwcm9hY2guIFRoZXJlIHNlZW1z IHRvIGJlIGEgZ2VuZXJhbCBkZXNpcmUgdG8gZG8gdGhpcyB0aHJvdWdoIE9BdXRoLCB1c2luZyBl aXRoZXIgbm9ybWFsIHRva2VucyB0aGF0IGFyZSBjaGVja2VkIGJhY2sgYWdhaW5zdCB0aGUgQVMs IG9yIHNlbGYtY29udGFpbmVkIHRva2VucyB3aGljaCBjYW4gYmUgY2hlY2tlZCBkaXJlY3RseSBh dCB0aGUgVFVSTiBzZXJ2ZXIsIHNvIEkgd2lsbCBsb29rIGF0IHVwZGF0aW5nIHRoZSBkcmFmdCB0 byB1c2UgT0F1dGguIFRoaXMgd2lsbCBhbHNvIHJlc29sdmUgdGhlIGlzc3VlcyByYWlzZWQgYWJv dXQgaG93IHNlcGFyYXRlIHdlYiBhbmQgVFVSTiBzZXJ2ZXJzIGNhbiBzaGFyZSBhIHNlY3JldC7C oA0KDQpUaGUgbWFpbiBxdWVzdGlvbiBoZXJlIGlzIHdoZXRoZXIgdGhpcyByZXF1aXJlcyBhbiB1 cGRhdGUgdG8gdGhlIFRVUk4gcHJvdG9jb2wgdG8gc3BlY2lmeSBhIHRva2VuLWJhc2VkIGF1dGgg bWVjaGFuaXNtLCBvciBpZiBpdCBpcyBwb3NzaWJsZSB0byBvdmVybG9hZCB0aGUgbG9uZy10ZXJt IGF1dGggbWVjaGFuaXNtLCBzaW5jZSBJIHRoaW5rIHRoZXkgd2lsbCBiZSBmYWlybHkgc2ltaWxh ciBpbiBvcGVyYXRpb24uDQoNCkZpbmFsbHkgYSBzbWFsbCBuaXQ6IMKgSW4gdGhlIHByZXNlbnRh dGlvbiB0aGUgd3Jvbmcgc3ludGF4IHdhcyB1c2VkIGZvciB0aGUNCnR1cm4gdXJpOiDCoHRoZSBw YXJhbWV0ZXIgbmFtZSBpcyB0cmFuc3BvcnQ9LCBub3QgcHJvdG89Lg0KDQpNeSBtaXN0YWtlLiBU aGFua3MuwqANCg0KVGhhbmtzLg0KDQotIC0tDQpNYXJjIFBldGl0LUh1Z3VlbmluDQpFbWFpbDog bWFyY0BwZXRpdC1odWd1ZW5pbi5vcmcNCkJsb2c6IGh0dHA6Ly9ibG9nLm1hcmMucGV0aXQtaHVn dWVuaW4ub3JnDQpQcm9maWxlOiBodHRwOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9wZXRpdGh1Zw0K LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjQuMTQgKEdO VS9MaW51eCkNCg0KaVFJY0JBRUJDQUFHQlFKUjkwTHFBQW9KRUNuRVJaWFdhbjdFb2lNUC9SOTBr aHYxRXorMjY1MnVDUklCak5oUw0KSnlHcG9OTlZzcWFQRlBIbzlqSjVwdkp1MHFZRVVLcnpYd29a dFJuODBVRkZVb2pKSUZzeDBYbXp3a0RsN3FBcQ0KaHN6K3JQeEN2VkwzaVRCdk5HU2VlOEhFWmlM enpTa2JhMzRud0RvSDRxclZFaVdYM25qY0pIMVAxYmZicnJoaw0Kck94Vk1UU29YSzdQMTE4UkZw MGlRWXlmVEFmNVJsSDI5MnU5dnJDUmxqVzJPakU2NDRBUEJOZ1d5RXlvaS9KNQ0KdkpuUFB2QlNy UjVoWWZ0bjBEckNSTHNPbTVQUGMrNmxaMjNCekVhKzB5SmRwMkM0RmV6N1o0dUhUTWh3NGJCUA0K VU9wWGI4OFpwdVVsY0xVamorWFU5Sk1ZbTdWaFArQ0tadytBa1hNR1hBbWlNYTRqYzZSaWExc1Rr ZUNYZFQ4Sg0KY1h5eXhqQmwvQ1l1aHhxTWhNM0h4bTJpZmVWNmpRRVg1YmRrKzV5K1FwOEpnKytj amplTllkL1l0OHVKUFllMw0KbkZ4a0tIQUs0a3I2M05Jd2ZQSkZXZlZFNDROd2J2bXlDc0htVE5j RFhsb3E0REZlV0dLeHNFbm5nV2plU09JRQ0KM0hkZHRLZ2NUdEw4QXROWTlGVmxQWk1sbURJK0xo OWVPK2wrMDVJUklpeklEc0w4dzNXTWxwQ1hpUGZyVXExWA0KU1FjQ3hNQkpIU0FJTnFNR1Q0VTBz dytWQUk2bENUQW5KVzlBUUZaZWJkRG1mMktBc1dEeExHd2tXMEc0Ny95Zw0KcndLR0FaaGkxNE91 TWM4eVk4ZVdJYlUrS1J4UFVrYlMzcDdBV1ZoNXFOaFRYWWRsbFZqekpPUnZaNTg0dnAwSQ0KUmpF d1ZibG9HejVMWU4wQ0NDQmgNCj1MOHFJDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpCZWhhdmUgbWFp bGluZyBsaXN0DQpCZWhhdmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYmVoYXZlDQoNCg== From joelja@bogus.com Thu Aug 1 05:46:15 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3476721E80E5 for ; Thu, 1 Aug 2013 05:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 ohyRscY4XmXK for ; Thu, 1 Aug 2013 05:46:10 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A00AE21E80DE for ; Thu, 1 Aug 2013 05:45:55 -0700 (PDT) Received: from dhcp-6518.meeting.ietf.org (dhcp-6518.meeting.ietf.org [130.129.101.24]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r71Cjn4h002203 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 1 Aug 2013 12:45:52 GMT (envelope-from joelja@bogus.com) Message-ID: <51FA587D.2000700@bogus.com> Date: Thu, 01 Aug 2013 14:45:49 +0200 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: xiechf01 , behave References: <201307301730264218665@gmail.com> In-Reply-To: <201307301730264218665@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 01 Aug 2013 12:45:53 +0000 (UTC) Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:46:15 -0000 On 7/30/13 5:30 PM, xiechf01-Gmail wrote: > > Hi, > > The requirements in draft-sun-behave-v4tov6-00 orginates from the > real experience and expectations of our product network. > > Recently, IPv4 address shortage begin to occour in some data centers, > and we guess that this situation will become worse as the days pass. > Since the IPv4 address owned by a given data center is finite, so > IPv4 address in their hands will run out soon, it is inevitable that > IPv6-only server will apear. Dual-stack services to new ICPs is based > on sufficient IPv4 address provisionging, but this is not the future > for most IDCs. > As a datecenter operator availability of public addressing is a significant consideration. that said that impacts service deployment considerations not in fact host count. Decisions to deploy v6 only hosts vs dual stack in my environment and I suspect most others actually have relatively little to do with my supply of public IPs. I have therefore some issues with your conclusions. > On the other side, although some operators in the world begin to > deploy IPv6 for their broadband users, a great portion of users > worldwide will still be IPv4-only in the long future due to many > well-known factors, we can not assume that all the users will become > dual-stack in a short period. Right now, IPv6 peneration in most > regions is below 10%. > > Combing the 2 factors together, we deem it is necessary to solve 4to6 > acess problem during the long transition period. > > Chongfeng > > > > * /To/: "ajs at anvilwalrusden.com " at anvilwalrusden.com >, "behave at > ietf.org " > * /Subject/: Re: [BEHAVE] Fwd: I-D > Action: draft-sun-behave-v4tov6-00.txt * /From/: Branimir Rajtar > > * > /Date/: Tue, 30 Jul 2013 08:46:19 +0000 * /Accept-language/: en-US * > /Delivered-to/: behave at ietfa.amsl.com > * /In-reply-to/: > <20130730080504.GA52575 at mx1.yitter.info > > * /List-archive/: > * /List-help/: > * /List-id/: mailing > list of BEHAVE IETF WG * /List-post/: > * /List-subscribe/: > , > * > /List-unsubscribe/: , > * /References/: > mail.gmail.com > > > mail.gmail.com > > > mail.gmail.com > > > <20130729134623.GD51737 at mx1.yitter.info > > <51F674D0.3040603 at > viagenie.ca > > <20130729143910.GB51823 at mx1.yitter.info > > > mail.gmail.com > >, > <20130730080504.GA52575 at mx1.yitter.info > > * /Reply-to/: Branimir > Rajtar > * /Thread-index/: > AQHOjNBH7KZnViUbv0K3Et3zbLdQ3Jl8u9YAgAAtDus= * /Thread-topic/: > [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt > > ------------------------- Hi, > > Your argumentation says that everybody needs to have IPv6 access and > I agree completely that would solve all issues. However, we will not > be in that point of time for at least five years. And I think I'm > optimistic - by looking at the current IPv6 deployment percentages, > it might be much more. > > ISPs are not really keen on deploying IPv6, they rather do CGN. NAT46 > would be cheaper and would provide a reason for servers which are > currently IPv4-only to switch to dual-stack and eventually to > IPv6-only. > > I think we could discuss this topic for the next couple of weeks > (which would be quite difficult since I'm writing from my smartphone) > so I suggest to leave the decision on the working group. > > BR, Branimir > > > > > -------- Izvorna poruka -------- Åalje: Andrew Sullivan anvilwalrusden.com> Datum: To: behave at ietf.org Naslov: Re: > [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt > > > Hi, > > I'm already violating my usual rules about over-posting, so I'm > going to endeavour to shut up after this. But there's a subtle but, > in my opinion, mistaken parallelism here, and I want to challenge > it. > > On Tue, Jul 30, 2013 at 10:55:42AM +0800, Qiong wrote: > >> For example, we now have NAT64 and so v6-only client can emerge and >> talk to v4 server. So v6-only clients may be more and more in the >> future. I see nobody argues that if we have NAT64, v4 server may >> live in v4 forever. >> >> Then for v4-to-v6 scenario, this is the same since it will bring >> the ability to support v6-only server to be reachable by v4-only >> clients. Therefore, v6-only server may emerge because they do not >> need to worry about losing v4 clients. So v6-only server maybe more >> and more in the future. This will promote v6-development, rather >> than the opposite one. > > The key reason to have defined NAT64 was because we had a supply > problem. If you were a v6-only node, you couldn't reach servers on > the v4 Internet. But _most_ things were on the v4 Internet. So > NAT64 gave us a way of permitting people to have v6-only > connectivity without paying the cost of losing access to the entire > Internet. > > The argument above turns this on its head, and says that if you are > standing up a service, you are worried about losing the possible > customers on v4-only networks. Therefore, you will go dual stack. > Implicitly, if we say, "New v4 service bad," we think it would be > better that the service be v6-only. So, we should have a mechanism > by which v4-only clients can access the v6 Internet, and this will > in some sense increase v6 use because the service is actually > accessed over v6. > > I think the argument is subtle but wrong. First, it depends on the > premise that there is an interesting population that will > (economically) remain v4-only while v6-only service deployment is in > some sense (likely economically) a reasonable plan. As I already > argued elsewhere in this thread, that premise needs a lot of > supporting argument, because it seems to me to be false. Second, it > confuses the goal of IPv6 deployment in the sense of native use with > a supposed goal of merely carrying traffic over v6. The latter is > not an interesting goal in any sense: if tomorrow we simply > encapsulated all v4 traffic inside v6, I do not think it would be an > interesting advance in v6 deployment. So I reject the claim that > this sort of 4-to-6 NAT is a positive contributor to IPv6 deployment. > The right message is, "If you want to reach this v6-only service, get > a v6 address." If the service is valuable, the customers will come, > since v6 communications are no longer an enormous big deal. > > As for the risk that dual stack everywhere permits v4 to persist: so > what? If v6 is working everywhere, then the v4 network will > gradually wither away because it is not economical to keep that > network interface active. (Lee Howard has done interesting analysis > in this area, and his models at least suggest a pretty significant > changeover incentive once a not very large number of services come up > on IPv6.) The goal is not to make the evil, bad, wrong v4 go away, > any more than the goal was in itself to kill X.25 and dance about on > its grave singing hallelujah. That was just a happy consequence. > >> From the long history of IPv6 development, I think it is clear >> this assumption has never hardly existed. If anyone *ought to be >> able to get a v6 address*, we would have reached the v6-world long >> ago, rather than debating how to transit. > > Surely not. V6 deployment has never been impeded by lack of v6 > addresses. As long as v4 was good enough and it was still possible > to get address space for reasonable cost, there was little incentive > to move to a network technology that seemed like it was still under > development. But we're out of v4 addresses now, the experience is > _not_ good enough, and so one might suppose the incentives have > changed. > > Best, > > A > > -- Andrew Sullivan ajs at anvilwalrusden.com > _______________________________________________ Behave mailing list > Behave at ietf.org https://www.ietf.org/mailman/listinfo/behave > > >

> > IZJAVA O ODRICANJU ODGOVORNOSTI: SadrÅaj ove poruke i eventualno > priloÅenih datoteka je povjerljiv i namijenjen je samo osobama ili > subjektima koji su navedeni u adresi. Ukoliko ste primili ovu poruku > greÅkom, molimo Vas, obavijestite poÅiljatelja, a poruku i sve njene > privitke odmah, bez Äitanja, trajno uklonite s raÄunala. Bilo kakvo > prenoÅenje, kopiranje ili distribucija informacija sadrÅanih u poruci > treÄim osobama je zabranjeno i moÅe biti zakonski kaÅnjivo. SadrÅaj, > stavovi i miÅljenja izneseni u poruci su autorovi i ne predstavljaju > nuÅno stavove HT - Hrvatskih telekomunikacija d.d. HT ne prihvaÄa > nikakvu odgovornost za eventualnu Åtetu nastalu primitkom ove poruke > i priloga sadrÅanih u poruci. > >

> > DISCLAIMER:The contents of this email as well as any files attached > to it are confidential and intended solely for individuals or > entities which they are addressed to. If you have received this email > message in error, please notify the sender and permanently remove the > message and all attached files from the computer. Any disclosure, > copying or distribution of all or a part of information contained > herein to or by third parties is prohibited and may be unlawful. > Please note that any views or opinions presented in this message are > solely those of the author and do not necessarily represent the views > and opinions of Croatian Telecom Inc. Croatian Telecom Inc. accepts > no liability for any potential damage caused by this message and > files attached to it. > >

------------------------- > > * *References*: o *[BEHAVE] Fwd: I-D Action: > draft-sun-behave-v4tov6-00.txt > * > + /From:/ Qiong o *Re: [BEHAVE] Fwd: I-D Action: > draft-sun-behave-v4tov6-00.txt > * > + /From:/ Liu Dapeng o *Re: [BEHAVE] Fwd: I-D Action: > draft-sun-behave-v4tov6-00.txt > * > + /From:/ Qiong o *Re: [BEHAVE] Fwd: I-D Action: > draft-sun-behave-v4tov6-00.txt > * > + /From:/ Andrew Sullivan o *Re: [BEHAVE] Fwd: I-D Action: > draft-sun-behave-v4tov6-00.txt > * > + /From:/ Simon Perreault o *Re: [BEHAVE] Fwd: I-D Action: > draft-sun-behave-v4tov6-00.txt > * > + /From:/ Andrew Sullivan o *Re: [BEHAVE] Fwd: I-D Action: > draft-sun-behave-v4tov6-00.txt > * > + /From:/ Qiong o *Re: [BEHAVE] Fwd: I-D Action: > draft-sun-behave-v4tov6-00.txt > * > + /From:/ Andrew Sullivan > > * Prev by Date: *Re: [BEHAVE] draft-meng-behave-napgt can be met by > PCP port set > * > * Next by Date: *Re: [BEHAVE] draft-meng-behave-napgt can be met by > PCP port set > * > * Previous by thread: *Re: [BEHAVE] Fwd: I-D Action: > draft-sun-behave-v4tov6-00.txt > * > * Next by thread: *Re: [BEHAVE] Fwd: I-D Action: > draft-sun-behave-v4tov6-00.txt > * > * Index(es): o *Date* > > > o *Thread* > > > Note: Messages sent to this list are the opinions of the senders and > do not imply endorsement > > > ------------------------- xiechf01-Gmail > > > _______________________________________________ Behave mailing list > Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From joelja@bogus.com Fri Aug 2 04:12:20 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0325E11E810B for ; Fri, 2 Aug 2013 04:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 xSzOsy0GR1Yt for ; Fri, 2 Aug 2013 04:12:17 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0132911E82B0 for ; Fri, 2 Aug 2013 04:12:03 -0700 (PDT) Received: from dhcp-6518.meeting.ietf.org (dhcp-6518.meeting.ietf.org [130.129.101.24]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r72BBwGu018202 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 2 Aug 2013 11:12:00 GMT (envelope-from joelja@bogus.com) Message-ID: <51FB93FD.2030301@bogus.com> Date: Fri, 02 Aug 2013 13:11:57 +0200 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: xiechf01 , behave References: <201307301730264218665@gmail.com> <51FA587D.2000700@bogus.com> In-Reply-To: <51FA587D.2000700@bogus.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 02 Aug 2013 11:12:01 +0000 (UTC) Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 11:12:20 -0000 On 8/1/13 2:45 PM, joel jaeggli wrote: > On 7/30/13 5:30 PM, xiechf01-Gmail wrote: >> Hi, >> >> The requirements in draft-sun-behave-v4tov6-00 orginates from the >> real experience and expectations of our product network. >> >> Recently, IPv4 address shortage begin to occour in some data centers, >> and we guess that this situation will become worse as the days pass. >> Since the IPv4 address owned by a given data center is finite, so >> IPv4 address in their hands will run out soon, it is inevitable that >> IPv6-only server will apear. Dual-stack services to new ICPs is based >> on sufficient IPv4 address provisionging, but this is not the future >> for most IDCs. >> > As a datecenter operator availability of public addressing is a > significant consideration. that said that impacts service deployment > considerations not in fact host count. > > Decisions to deploy v6 only hosts vs dual stack in my environment and I > suspect most others actually have relatively little to do with my > supply of public IPs. I have therefore some issues with your conclusions. I've been told this is cryptic... Here are some observations. How you number your network and that of your customers is a business decision. your customers will require public ipv4 addresses on some device either owned by them or you in order to service ipv4 customers into the foreseeable future. regarding this assertion: This document is designed for IPv4 Internet to reach IPv6 network. There are several requirements in this design: 1.Considering IPv4 address has been a scarce resource, the amount of public IPv4 addresses consumed by the translator should be less than that the number of IPv6 servers in the IPv6 network. As far as i know it is common practice already that the operators conserve public ip addresses by limiting their use to necessary network components. this is done notwithstanding the choice of technologies e.g. it is done is single stack v4 networks as well. I expect that if/as ipv4 address availability continues to decline that the result will be that operators will reduce what are considered necessary until such point as the only devices with public ipv4 addresses are load balancers nat translators and perhaps select loopbacks. When looking at section 3.1 and section 4 you assert that the client is making a query to the dns46 nameserver. and that the client source address is a consideration in the mapping. In fact the client source address is not seen by the dns46 nameserver, rather the client's recursive nameserver(s) is seen by the dns46 nameserver, likewise for the duration of the ttl on the ipv4 A record the recursive resolvers will not again query the dns46 nameserver on behalf of the client or other clients which they may have. You assert that major feature of the approach you describe is this: 6 . The Dynamic IPv6-converted Address Issue The major feature in the above two approaches is that the IPv6- converted address for destination IPv6 server is now dynamically determined by NAT46. Which is interesting but it requires two conceits that aren't well described. It posits the existance of internet content providers with no or few ipv4 customers such that they don't need an ipv4 address all the time. maybe that exists in the far future but it doesn't seem like an immediate problem. therefore one would expect these to be effectively continuously assigned. It requires that the forward zone for the internet content providers name service be delegated to the operator of the nat46 gateway's dns46 server, either a datacenter operator or an internet service provider (as opposed to either utilizing a third party, or running it themselves). To the extent that I am aware it is a not a common practice. > >> On the other side, although some operators in the world begin to >> deploy IPv6 for their broadband users, a great portion of users >> worldwide will still be IPv4-only in the long future due to many >> well-known factors, we can not assume that all the users will become >> dual-stack in a short period. Right now, IPv6 peneration in most >> regions is below 10%. >> >> Combing the 2 factors together, we deem it is necessary to solve 4to6 >> acess problem during the long transition period. >> >> Chongfeng >> >> >> >> * /To/: "ajs at anvilwalrusden.com " > at anvilwalrusden.com >, "behave at >> ietf.org " > > * /Subject/: Re: [BEHAVE] Fwd: I-D >> Action: draft-sun-behave-v4tov6-00.txt * /From/: Branimir Rajtar >> > * >> /Date/: Tue, 30 Jul 2013 08:46:19 +0000 * /Accept-language/: en-US * >> /Delivered-to/: behave at ietfa.amsl.com >> * /In-reply-to/: >> <20130730080504.GA52575 at mx1.yitter.info >> > * /List-archive/: >> * /List-help/: >> * /List-id/: mailing >> list of BEHAVE IETF WG * /List-post/: >> * /List-subscribe/: >> , >> * >> /List-unsubscribe/: , >> * /References/: >> > mail.gmail.com >> > > >> > mail.gmail.com >> > > >> > mail.gmail.com >> > > >> <20130729134623.GD51737 at mx1.yitter.info >> > <51F674D0.3040603 at >> viagenie.ca > >> <20130729143910.GB51823 at mx1.yitter.info >> > >> > mail.gmail.com >> > >, >> <20130730080504.GA52575 at mx1.yitter.info >> > * /Reply-to/: Branimir >> Rajtar > > * /Thread-index/: >> AQHOjNBH7KZnViUbv0K3Et3zbLdQ3Jl8u9YAgAAtDus= * /Thread-topic/: >> [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt >> >> ------------------------- Hi, >> >> Your argumentation says that everybody needs to have IPv6 access and >> I agree completely that would solve all issues. However, we will not >> be in that point of time for at least five years. And I think I'm >> optimistic - by looking at the current IPv6 deployment percentages, >> it might be much more. >> >> ISPs are not really keen on deploying IPv6, they rather do CGN. NAT46 >> would be cheaper and would provide a reason for servers which are >> currently IPv4-only to switch to dual-stack and eventually to >> IPv6-only. >> >> I think we could discuss this topic for the next couple of weeks >> (which would be quite difficult since I'm writing from my smartphone) >> so I suggest to leave the decision on the working group. >> >> BR, Branimir >> >> >> >> >> -------- Izvorna poruka -------- Åalje: Andrew Sullivan > anvilwalrusden.com> Datum: To: behave at ietf.org Naslov: Re: >> [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt >> >> >> Hi, >> >> I'm already violating my usual rules about over-posting, so I'm >> going to endeavour to shut up after this. But there's a subtle but, >> in my opinion, mistaken parallelism here, and I want to challenge >> it. >> >> On Tue, Jul 30, 2013 at 10:55:42AM +0800, Qiong wrote: >> >>> For example, we now have NAT64 and so v6-only client can emerge and >>> talk to v4 server. So v6-only clients may be more and more in the >>> future. I see nobody argues that if we have NAT64, v4 server may >>> live in v4 forever. >>> >>> Then for v4-to-v6 scenario, this is the same since it will bring >>> the ability to support v6-only server to be reachable by v4-only >>> clients. Therefore, v6-only server may emerge because they do not >>> need to worry about losing v4 clients. So v6-only server maybe more >>> and more in the future. This will promote v6-development, rather >>> than the opposite one. >> The key reason to have defined NAT64 was because we had a supply >> problem. If you were a v6-only node, you couldn't reach servers on >> the v4 Internet. But _most_ things were on the v4 Internet. So >> NAT64 gave us a way of permitting people to have v6-only >> connectivity without paying the cost of losing access to the entire >> Internet. >> >> The argument above turns this on its head, and says that if you are >> standing up a service, you are worried about losing the possible >> customers on v4-only networks. Therefore, you will go dual stack. >> Implicitly, if we say, "New v4 service bad," we think it would be >> better that the service be v6-only. So, we should have a mechanism >> by which v4-only clients can access the v6 Internet, and this will >> in some sense increase v6 use because the service is actually >> accessed over v6. >> >> I think the argument is subtle but wrong. First, it depends on the >> premise that there is an interesting population that will >> (economically) remain v4-only while v6-only service deployment is in >> some sense (likely economically) a reasonable plan. As I already >> argued elsewhere in this thread, that premise needs a lot of >> supporting argument, because it seems to me to be false. Second, it >> confuses the goal of IPv6 deployment in the sense of native use with >> a supposed goal of merely carrying traffic over v6. The latter is >> not an interesting goal in any sense: if tomorrow we simply >> encapsulated all v4 traffic inside v6, I do not think it would be an >> interesting advance in v6 deployment. So I reject the claim that >> this sort of 4-to-6 NAT is a positive contributor to IPv6 deployment. >> The right message is, "If you want to reach this v6-only service, get >> a v6 address." If the service is valuable, the customers will come, >> since v6 communications are no longer an enormous big deal. >> >> As for the risk that dual stack everywhere permits v4 to persist: so >> what? If v6 is working everywhere, then the v4 network will >> gradually wither away because it is not economical to keep that >> network interface active. (Lee Howard has done interesting analysis >> in this area, and his models at least suggest a pretty significant >> changeover incentive once a not very large number of services come up >> on IPv6.) The goal is not to make the evil, bad, wrong v4 go away, >> any more than the goal was in itself to kill X.25 and dance about on >> its grave singing hallelujah. That was just a happy consequence. >> >>> From the long history of IPv6 development, I think it is clear >>> this assumption has never hardly existed. If anyone *ought to be >>> able to get a v6 address*, we would have reached the v6-world long >>> ago, rather than debating how to transit. >> Surely not. V6 deployment has never been impeded by lack of v6 >> addresses. As long as v4 was good enough and it was still possible >> to get address space for reasonable cost, there was little incentive >> to move to a network technology that seemed like it was still under >> development. But we're out of v4 addresses now, the experience is >> _not_ good enough, and so one might suppose the incentives have >> changed. >> >> Best, >> >> A >> >> -- Andrew Sullivan ajs at anvilwalrusden.com >> _______________________________________________ Behave mailing list >> Behave at ietf.org https://www.ietf.org/mailman/listinfo/behave >> >> >>

>> >> IZJAVA O ODRICANJU ODGOVORNOSTI: SadrÅaj ove poruke i eventualno >> priloÅenih datoteka je povjerljiv i namijenjen je samo osobama ili >> subjektima koji su navedeni u adresi. Ukoliko ste primili ovu poruku >> greÅkom, molimo Vas, obavijestite poÅiljatelja, a poruku i sve njene >> privitke odmah, bez Äitanja, trajno uklonite s raÄunala. Bilo kakvo >> prenoÅenje, kopiranje ili distribucija informacija sadrÅanih u poruci >> treÄim osobama je zabranjeno i moÅe biti zakonski kaÅnjivo. SadrÅaj, >> stavovi i miÅljenja izneseni u poruci su autorovi i ne predstavljaju >> nuÅno stavove HT - Hrvatskih telekomunikacija d.d. HT ne prihvaÄa >> nikakvu odgovornost za eventualnu Åtetu nastalu primitkom ove poruke >> i priloga sadrÅanih u poruci. >> >>

>> >> DISCLAIMER:The contents of this email as well as any files attached >> to it are confidential and intended solely for individuals or >> entities which they are addressed to. If you have received this email >> message in error, please notify the sender and permanently remove the >> message and all attached files from the computer. Any disclosure, >> copying or distribution of all or a part of information contained >> herein to or by third parties is prohibited and may be unlawful. >> Please note that any views or opinions presented in this message are >> solely those of the author and do not necessarily represent the views >> and opinions of Croatian Telecom Inc. Croatian Telecom Inc. accepts >> no liability for any potential damage caused by this message and >> files attached to it. >> >>

------------------------- >> >> * *References*: o *[BEHAVE] Fwd: I-D Action: >> draft-sun-behave-v4tov6-00.txt >> * >> + /From:/ Qiong o *Re: [BEHAVE] Fwd: I-D Action: >> draft-sun-behave-v4tov6-00.txt >> * >> + /From:/ Liu Dapeng o *Re: [BEHAVE] Fwd: I-D Action: >> draft-sun-behave-v4tov6-00.txt >> * >> + /From:/ Qiong o *Re: [BEHAVE] Fwd: I-D Action: >> draft-sun-behave-v4tov6-00.txt >> * >> + /From:/ Andrew Sullivan o *Re: [BEHAVE] Fwd: I-D Action: >> draft-sun-behave-v4tov6-00.txt >> * >> + /From:/ Simon Perreault o *Re: [BEHAVE] Fwd: I-D Action: >> draft-sun-behave-v4tov6-00.txt >> * >> + /From:/ Andrew Sullivan o *Re: [BEHAVE] Fwd: I-D Action: >> draft-sun-behave-v4tov6-00.txt >> * >> + /From:/ Qiong o *Re: [BEHAVE] Fwd: I-D Action: >> draft-sun-behave-v4tov6-00.txt >> * >> + /From:/ Andrew Sullivan >> >> * Prev by Date: *Re: [BEHAVE] draft-meng-behave-napgt can be met by >> PCP port set >> * >> * Next by Date: *Re: [BEHAVE] draft-meng-behave-napgt can be met by >> PCP port set >> * >> * Previous by thread: *Re: [BEHAVE] Fwd: I-D Action: >> draft-sun-behave-v4tov6-00.txt >> * >> * Next by thread: *Re: [BEHAVE] Fwd: I-D Action: >> draft-sun-behave-v4tov6-00.txt >> * >> * Index(es): o *Date* >> >> >> > o *Thread* > >> >> Note: Messages sent to this list are the opinions of the senders and >> do not imply endorsement >> >> >> ------------------------- xiechf01-Gmail >> >> >> _______________________________________________ Behave mailing list >> Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave > From ssenthil@cisco.com Fri Aug 2 07:19:16 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5862421E8087; Fri, 2 Aug 2013 07:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 FzBo3ih6Eqt2; Fri, 2 Aug 2013 07:19:11 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 96FBB21E8083; Fri, 2 Aug 2013 07:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9831; q=dns/txt; s=iport; t=1375453151; x=1376662751; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=hvA7mtceuuJT/VP6tDvVogmFa6yfuc99ubsQObKDwl4=; b=b9wMzN3ix8LMY7B7K9IQpocWobVekZzgEQfi2ui+dbEKNLDZScHcnLTt myGyowM87G1jhQo4bpPO8qP3Ig++i36+Gbcw4Mdx0xG8BqQpIUNd4IULZ /eqoFj96WiMOnpq2xPZt37mgj9xVOz9JUbMEhbYcL8vjHEhYt1iNPvNrE Y=; X-IronPort-AV: E=Sophos;i="4.89,801,1367971200"; d="scan'208,217";a="242749888" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 02 Aug 2013 14:19:11 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r72EJBvo000575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Aug 2013 14:19:11 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.80]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Fri, 2 Aug 2013 09:19:10 -0500 From: "Senthil Sivakumar (ssenthil)" To: "Paul Aitken (paitken)" Thread-Topic: review of draft-ietf-behave-ipfix-nat-logging-00 - IPFIX Information Elements for logging NAT Events Thread-Index: AQHOj17eZrQ3EsxpSEynslYVUhXvw5mCCIeA Date: Fri, 2 Aug 2013 14:19:10 +0000 Message-ID: In-Reply-To: <51FB7560.1010605@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.117.198.132] Content-Type: multipart/alternative; boundary="_000_CB1B483277FEC94E9B58357040EE5D023267DBB2xmbrcdx15ciscoc_" MIME-Version: 1.0 Cc: "behave@ietf.org" , IETF IPFIX Working Group Subject: Re: [BEHAVE] review of draft-ietf-behave-ipfix-nat-logging-00 - IPFIX Information Elements for logging NAT Events X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 14:19:16 -0000 --_000_CB1B483277FEC94E9B58357040EE5D023267DBB2xmbrcdx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paul, Thanks for the review, I will incorporate the comments in the next revision= . Thanks Senthil From: "Paul Aitken (paitken)" > Date: Friday, August 2, 2013 5:01 AM To: Senthil Sivakumar > Cc: IETF IPFIX Working Group >, "beha= ve@ietf.org" > Subject: review of draft-ietf-behave-ipfix-nat-logging-00 - IPFIX Informati= on Elements for logging NAT Events [resending due to an apparent IETF email outage?] Senthil, Here's a quick review of your draft from an IPFIX perspective: * The [NAT-EVENT-LOG-IANA] reference is not referenced in the text, and the= URL doesn't exist. If it's not needed, then remove the reference. If it's needed, then fix= the URL :-) * Where the tables include sizes of 1, 2, and 3 digits, the alignment is wr= ong (centralised?). Please right-align all the numbers. * Terminology: define "IE" / "IE's" before section 2. eg, reference the ter= minology from 5101bis. * Please be consistent about your usage of "IE" versus "Information Element= s". * Briefly introduce IPFIX in the Introduction section. eg: The IPFIX Protocol [RFC5101bis] defines a generic push mechanism for exp= orting information and events. The IPFIX Information Model [IANA-IPFIX] defines a set of standard Infor= mation Elements (IEs) which can be carried by the IPFIX protocol. This document details the IPFIX Information Elements that are required f= or logging by a NAT device and all the optional fields. The fields specified in this document are gleaned from [RFC4787] and [RFC5382]. * Note that 5101 and 5102 are both being updated by -bis drafts which are s= oon to be RFCs - so your Informative References should be updated. * [IANA-IPFIX] =3D=3D http://www.iana.org/assignments/ipfix/ipfix.xhtml This is now the definitive reference, rather than 5102 / 5102bis. * Please write "NetFlow v9" rather than "Netflow 9" (ie, with a capital 'F'= and a 'v'). * IANA Considerations: if there are none, then say "there are no IANA consi= derations." P. --_000_CB1B483277FEC94E9B58357040EE5D023267DBB2xmbrcdx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Paul,
Thanks for the review, I will incorporate the comments in the next rev= ision.

Thanks
Senthil

From: "Paul Aitken (paitken)&q= uot; <paitken@cisco.com>
Date: Friday, August 2, 2013 5:01 A= M
To: Senthil Sivakumar <ssenthil@cisco.com>
Cc: IETF IPFIX Working Group <ipfix@ietf.org>, "behave@ietf.org" <behave@ietf.org>
Subject: review of draft-ietf-behav= e-ipfix-nat-logging-00 - IPFIX Information Elements for logging NAT Events<= br>

[resending due to a= n apparent IETF email outage?]


Senthil,

Here's a quick review of yo= ur draft from an IPFIX perspective:

* The [N= AT-EVENT-LOG-IANA] reference is not referenced in the text, and the URL doesn't exist.
    If it's not needed, then remove the reference. If it's n= eeded, then fix the URL :-)

* Where the tables = include sizes of 1, 2, and 3 digits, the alignment is wrong (centralised?).= Please right-align all the numbers.

* Terminology: define= "IE" / "IE's" before section 2. eg, reference the term= inology from 5101bis.

* Please be consisten= t about your usage of "IE" versus "Information Elements"= ;.

* Briefl= y introduce IPFIX in the Introduction section. eg:
   The IPFIX Protocol [RFC5101bis] defines a=
 generic push mechanism for exporting information and events.
   The IPFIX Information Model [IANA-IPFIX] defines a set of standard =
Information Elements (IEs) which can be carried by the IPFIX protocol.
   This document details the IPFIX Information Elements that are required f=
or logging by a NAT device and all the optional fields.
   The fields specified in this document are gleaned from [RFC4787] and [RFC5382].

* Note that 5101 and 5102 are both being updated by -bis drafts which are so= on to be RFCs - so your Informative References should be updated.

* [IANA-IPFIX] =3D=3D http://www.iana.org/assignments/ipfix/ipfix.xhtml
    This is now the definitive reference, rather than 5102 /= 5102bis.

* Please write "NetFlow v9" rather than "Netflow 9" (ie= , with a capital 'F' and a 'v').

* IANA Considerations: if there are none, then say "there are no IANA = considerations."

P.
 --_000_CB1B483277FEC94E9B58357040EE5D023267DBB2xmbrcdx15ciscoc_-- From paitken@cisco.com Thu Aug 1 13:02:18 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804FF21E8238; Thu, 1 Aug 2013 13:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.5 X-Spam-Level: X-Spam-Status: No, score=-10.5 tagged_above=-999 required=5 tests=[AWL=0.098, 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 0-YYG5bPXZgs; Thu, 1 Aug 2013 13:02:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 42D1821E8098; Thu, 1 Aug 2013 13:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7601; q=dns/txt; s=iport; t=1375387333; x=1376596933; h=message-id:date:from:mime-version:to:cc:subject; bh=N+Nf2SwYEz+DSRDgJp8VGpFN9NfXcn+rEBifDY0NNtk=; b=l3P5b8xbbP9KZJP3Rhhn7JLNkv+UWnErRV2eixNXuOmLqRAr0mf6roCc a7lpZQckulamaAGa0wxOhE4bkwmrkgJycX3IskXKVjFhM9EJQd+wmvVqi rVj8LaCusjBF0BxQ4TfYLI1+GephOeo7WD069jwWpKwBcL35L5+WEMZv1 I=; X-IronPort-AV: E=Sophos;i="4.89,796,1367971200"; d="scan'208,217";a="157868856" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 01 Aug 2013 20:02:11 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r71K28k8014234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Aug 2013 20:02:09 GMT Received: from [10.61.98.64] (dhcp-10-61-98-64.cisco.com [10.61.98.64]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r71K27OW029099; Thu, 1 Aug 2013 21:02:08 +0100 (BST) Message-ID: <51FABEBF.1080507@cisco.com> Date: Thu, 01 Aug 2013 21:02:07 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" Content-Type: multipart/alternative; boundary="------------050802090601050604060309" X-Mailman-Approved-At: Fri, 02 Aug 2013 22:18:26 -0700 Cc: behave@ietf.org, IETF IPFIX Working Group Subject: [BEHAVE] review of draft-ietf-behave-ipfix-nat-logging-00 - IPFIX Information Elements for logging NAT Events X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 20:02:18 -0000 This is a multi-part message in MIME format. --------------050802090601050604060309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Senthil, Here's a quick review of your draft from an IPFIX perspective: * The [NAT-EVENT-LOG-IANA] reference is not referenced in the text, and the URL doesn't exist. If it's not needed, then remove the reference. If it's needed, then fix the URL :-) * Where the tables include sizes of 1, 2, and 3 digits, the alignment is wrong (centralised?). Please right-align all the numbers. * Terminology: define "IE" / "IE's" before section 2. eg, reference the terminology from 5101bis. * Please be consistent about your usage of "IE" versus "Information Elements". * Briefly introduce IPFIX in the Introduction section. eg: The IPFIX Protocol [RFC5101bis] defines a generic push mechanism for exporting information and events. The IPFIX Information Model [IANA-IPFIX] defines a set of standard Information Elements (IEs) which can be carried by the IPFIX protocol. This document details the IPFIX Information Elements that are required for logging by a NAT device and all the optional fields. The fields specified in this document are gleaned from [RFC4787 ] and [RFC5382 ]. * Note that 5101 and 5102 are both being updated by -bis drafts which are soon to be RFCs - so your Informative References should be updated. * [IANA-IPFIX] == http://www.iana.org/assignments/ipfix/ipfix.xhtml This is now the definitive reference, rather than 5102 / 5102bis. * Please write "NetFlow v9" rather than "Netflow 9" (ie, with a capital 'F' and a 'v'). * IANA Considerations: if there are none, then say "there are no IANA considerations." P. --------------050802090601050604060309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Senthil,

Here's a quick review of your draft from an IPFIX perspective:

* The [NAT-EVENT-LOG-IANA] reference is not referenced in the text, and the URL doesn't exist.
    If it's not needed, then remove the reference. If it's needed, then fix the URL :-)

* Where the tables include sizes of 1, 2, and 3 digits, the alignment is wrong (centralised?). Please right-align all the numbers.

* Terminology: define "IE" / "IE's" before section 2. eg, reference the terminology from 5101bis.

* Please be consistent about your usage of "IE" versus "Information Elements".

* Briefly introduce IPFIX in the Introduction section. eg:
   The IPFIX Protocol [RFC5101bis] defines a generic push mechanism for exporting information and events.
   The IPFIX Information Model [IANA-IPFIX] defines a set of standard Information Elements (IEs) which can be carried by the IPFIX protocol.
   This document details the IPFIX Information Elements that are required for logging by a NAT device and all the optional fields.
   The fields specified in this document are gleaned from [RFC4787] and [RFC5382].

* Note that 5101 and 5102 are both being updated by -bis drafts which are soon to be RFCs - so your Informative References should be updated.

* [IANA-IPFIX] == http://www.iana.org/assignments/ipfix/ipfix.xhtml
    This is now the definitive reference, rather than 5102 / 5102bis.

* Please write "NetFlow v9" rather than "Netflow 9" (ie, with a capital 'F' and a 'v').

* IANA Considerations: if there are none, then say "there are no IANA considerations."

P.
--------------050802090601050604060309-- From paitken@cisco.com Fri Aug 2 02:08:06 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8EE11E831C; Fri, 2 Aug 2013 02:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.506 X-Spam-Level: X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.092, 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 s20ccWLGaGNK; Fri, 2 Aug 2013 02:07:47 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id AB55B11E8320; Fri, 2 Aug 2013 02:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7749; q=dns/txt; s=iport; t=1375434122; x=1376643722; h=message-id:date:from:mime-version:to:cc:subject; bh=yj5SMFr80wZhoWFLEFj9AM/TkOZCY3FXuXgqgHuLnIo=; b=aIPE3y8rseXxU5x7nWoxPKu+fYmzydO1LAMUVic5RgqePbmbQsSZHK8f D6vJo4FsWCJoOaosfVtjZOE8NEzQJ+G1aBtDHsB84j6ZaYjyORRLeUoy2 QNbisKd7emkG5vscjtib0zq/I/BaQRMEgXKeIBBIrgppyntTvUyMKq4p0 g=; X-IronPort-AV: E=Sophos;i="4.89,800,1367971200"; d="scan'208,217";a="85379333" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 02 Aug 2013 09:01:22 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7291KfW026513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Aug 2013 09:01:20 GMT Received: from [10.61.98.64] (dhcp-10-61-98-64.cisco.com [10.61.98.64]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r7291Jd7001373; Fri, 2 Aug 2013 10:01:19 +0100 (BST) Message-ID: <51FB7560.1010605@cisco.com> Date: Fri, 02 Aug 2013 10:01:20 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" Content-Type: multipart/alternative; boundary="------------060309010008060007090802" X-Mailman-Approved-At: Fri, 02 Aug 2013 22:18:26 -0700 Cc: behave@ietf.org, IETF IPFIX Working Group Subject: [BEHAVE] review of draft-ietf-behave-ipfix-nat-logging-00 - IPFIX Information Elements for logging NAT Events X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 09:08:06 -0000 This is a multi-part message in MIME format. --------------060309010008060007090802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [resending due to an apparent IETF email outage?] Senthil, Here's a quick review of your draft from an IPFIX perspective: * The [NAT-EVENT-LOG-IANA] reference is not referenced in the text, and the URL doesn't exist. If it's not needed, then remove the reference. If it's needed, then fix the URL :-) * Where the tables include sizes of 1, 2, and 3 digits, the alignment is wrong (centralised?). Please right-align all the numbers. * Terminology: define "IE" / "IE's" before section 2. eg, reference the terminology from 5101bis. * Please be consistent about your usage of "IE" versus "Information Elements". * Briefly introduce IPFIX in the Introduction section. eg: The IPFIX Protocol [RFC5101bis] defines a generic push mechanism for exporting information and events. The IPFIX Information Model [IANA-IPFIX] defines a set of standard Information Elements (IEs) which can be carried by the IPFIX protocol. This document details the IPFIX Information Elements that are required for logging by a NAT device and all the optional fields. The fields specified in this document are gleaned from [RFC4787 ] and [RFC5382 ]. * Note that 5101 and 5102 are both being updated by -bis drafts which are soon to be RFCs - so your Informative References should be updated. * [IANA-IPFIX] == http://www.iana.org/assignments/ipfix/ipfix.xhtml This is now the definitive reference, rather than 5102 / 5102bis. * Please write "NetFlow v9" rather than "Netflow 9" (ie, with a capital 'F' and a 'v'). * IANA Considerations: if there are none, then say "there are no IANA considerations." P. --------------060309010008060007090802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
[resending due to an apparent IETF email outage?]


Senthil,

Here's a quick review of your draft from an IPFIX perspective:

* The [NAT-EVENT-LOG-IANA] reference is not referenced in the text, and the URL doesn't exist.
    If it's not needed, then remove the reference. If it's needed, then fix the URL :-)

* Where the tables include sizes of 1, 2, and 3 digits, the alignment is wrong (centralised?). Please right-align all the numbers.

* Terminology: define "IE" / "IE's" before section 2. eg, reference the terminology from 5101bis.

* Please be consistent about your usage of "IE" versus "Information Elements".

* Briefly introduce IPFIX in the Introduction section. eg:
   The IPFIX Protocol [RFC5101bis] defines a generic push mechanism for exporting information and events.
   The IPFIX Information Model [IANA-IPFIX] defines a set of standard Information Elements (IEs) which can be carried by the IPFIX protocol.
   This document details the IPFIX Information Elements that are required for logging by a NAT device and all the optional fields.
   The fields specified in this document are gleaned from [RFC4787] and [RFC5382].

* Note that 5101 and 5102 are both being updated by -bis drafts which are soon to be RFCs - so your Informative References should be updated.

* [IANA-IPFIX] == http://www.iana.org/assignments/ipfix/ipfix.xhtml
    This is now the definitive reference, rather than 5102 / 5102bis.

* Please write "NetFlow v9" rather than "Netflow 9" (ie, with a capital 'F' and a 'v').

* IANA Considerations: if there are none, then say "there are no IANA considerations."

P.
--------------060309010008060007090802-- From andrewf@plixer.com Fri Aug 2 05:12:40 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAE211E833F; Fri, 2 Aug 2013 05:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=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 N4PDIhhnASaV; Fri, 2 Aug 2013 05:12:33 -0700 (PDT) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) by ietfa.amsl.com (Postfix) with ESMTP id 688BF11E8325; Fri, 2 Aug 2013 05:12:31 -0700 (PDT) Received: from [10.11.1.15] (64.140.243.154) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 2 Aug 2013 08:12:30 -0400 Message-ID: <51FBA231.6020802@plixer.com> Date: Fri, 2 Aug 2013 08:12:33 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Paul Aitken References: <51FABEBF.1080507@cisco.com> In-Reply-To: <51FABEBF.1080507@cisco.com> Content-Type: multipart/alternative; boundary="------------030606000106080304020002" X-Mailman-Approved-At: Fri, 02 Aug 2013 22:18:26 -0700 Cc: behave@ietf.org, IETF IPFIX Working Group Subject: Re: [BEHAVE] [IPFIX] review of draft-ietf-behave-ipfix-nat-logging-00 - IPFIX Information Elements for logging NAT Events X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 12:12:40 -0000 --------------030606000106080304020002 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi Paul, On 08/01/2013 04:02 PM, Paul Aitken wrote: > Senthil, [ snip ] > * [IANA-IPFIX] == http://www.iana.org/assignments/ipfix/ipfix.xhtml > This is now the definitive reference, rather than 5102 / 5102bis. Given recent discussion of the ietf list I think the correct link to use is actually http://www.iana.org/assignments/ipfix [ snip ] -Andrew --------------030606000106080304020002 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Hi Paul,

On 08/01/2013 04:02 PM, Paul Aitken wrote:
Senthil,

 [ snip ]
* [IANA-IPFIX] == http://www.iana.org/assignments/ipfix/ipfix.xhtml
    This is now the definitive reference, rather than 5102 / 5102bis.

Given recent discussion of the ietf list I think the correct link to use is actually

http://www.iana.org/assignments/ipfix

 [ snip ]

-Andrew
--------------030606000106080304020002-- From internet-drafts@ietf.org Mon Aug 12 10:10:44 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A95F21F9998; Mon, 12 Aug 2013 10:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 BjlNfMW4F5G8; Mon, 12 Aug 2013 10:10:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D06CB21F83EF; Mon, 12 Aug 2013 09:54:07 -0700 (PDT) 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.70.p1 Message-ID: <20130812165407.18569.85020.idtracker@ietfa.amsl.com> Date: Mon, 12 Aug 2013 09:54:07 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:10:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Avoida= nce Working Group of the IETF. Title : IPFIX Information Elements for logging NAT Events Author(s) : Senthil Sivakumar Renaldo Penno Filename : draft-ietf-behave-ipfix-nat-logging-01.txt Pages : 15 Date : 2013-08-12 Abstract: NAT devices are required to log events like creation and deletion of translations and information about the resources it is managing. The logs are required in many cases to identify an attacker or a host that was used to launch malicious attacks and/or for various other purposes of accounting. Since there is no standard way of logging this information, different NAT devices behave differently and hence it is difficult to expect a consistent behavior. The lack of a consistent way makes it difficult to write the collector applications that would receive this data and process it to present useful information. This document describes the information that is required to be logged by the NAT devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-ipfix-nat-logging There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-ipfix-nat-logging-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ssenthil@cisco.com Mon Aug 12 10:33:24 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79AEC21F96B6; Mon, 12 Aug 2013 10:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 fvly0fVmPbJT; Mon, 12 Aug 2013 10:33:16 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C377521F9B92; Mon, 12 Aug 2013 10:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2253; q=dns/txt; s=iport; t=1376328648; x=1377538248; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=xMnb5buyQzfWXjdPyJESO36T1L17lNNtS81pURY7Bfo=; b=dGcYp6mTLau8xidbFTkvP+3X/YiD4hGupa9Bbbzda3H9mk17OKupr835 vwddyFWHMstBtUx6sUwplouTkoIgqqy7gRmwGpK7eNoFWmelZdpeD8gLb HBAVES1pbq6AatfcR1pLpn7svqkbNLfJmchsl2bOl4Zhdj2Bz5dfTwFMv U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQNAHYaCVKtJV2Z/2dsb2JhbABRCoFxBoEPNUoGvlSBGhZ0giYBBAEBATc0CxIBCCIUNwslAgQBDQUIAYgHBwW2X45zCIEPMQeDG3YDmRCQJYMbgWhC X-IronPort-AV: E=Sophos;i="4.89,863,1367971200"; d="scan'208";a="246358886" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 12 Aug 2013 17:30:45 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7CHUjlu031727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 17:30:45 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.80]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 12:30:44 -0500 From: "Senthil Sivakumar (ssenthil)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-01.txt Thread-Index: AQHOl38N5H8GQxZvg0qarOMbTvDhp5mR5R2A Date: Mon, 12 Aug 2013 17:30:45 +0000 Message-ID: In-Reply-To: <20130812165407.18569.85020.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [64.102.83.125] Content-Type: text/plain; charset="us-ascii" Content-ID: <430A797B11E0444883BEC28977533E33@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:33:24 -0000 This version folds in the comments from Dan Wing and from Paul Aitken. Please review and let me know your comments. Thanks Senthil On 8/12/13 12:54 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Behavior Engineering for Hindrance >Avoidance Working Group of the IETF. > > Title : IPFIX Information Elements for logging NAT Events > Author(s) : Senthil Sivakumar > Renaldo Penno > Filename : draft-ietf-behave-ipfix-nat-logging-01.txt > Pages : 15 > Date : 2013-08-12 > >Abstract: > NAT devices are required to log events like creation and deletion of > translations and information about the resources it is managing. The > logs are required in many cases to identify an attacker or a host > that was used to launch malicious attacks and/or for various other > purposes of accounting. Since there is no standard way of logging > this information, different NAT devices behave differently and hence > it is difficult to expect a consistent behavior. The lack of a > consistent way makes it difficult to write the collector applications > that would receive this data and process it to present useful > information. This document describes the information that is > required to be logged by the NAT devices. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-behave-ipfix-nat-logging > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-ipfix-nat-logging-01 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From kaname@nttv6.jp Tue Aug 13 18:11:15 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8BF11E81CF for ; Tue, 13 Aug 2013 18:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_JP=1.265] 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 sapcDcCZlR+5 for ; Tue, 13 Aug 2013 18:11:10 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:a::4]) by ietfa.amsl.com (Postfix) with ESMTP id 6883711E81CD for ; Tue, 13 Aug 2013 18:11:10 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 9165E4E738; Wed, 14 Aug 2013 10:11:07 +0900 (JST) Received: from [IPv6:::1] (fujiko.nttv6.jp [115.69.228.141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 71CC23B730; Wed, 14 Aug 2013 10:11:07 +0900 (JST) Message-ID: <520AD927.206@nttv6.jp> Date: Wed, 14 Aug 2013 10:11:03 +0900 From: kaname nishizuka User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yutaka Ishizaki References: <20130813.125445.747003470323048065.ishizaki@dti.ad.jp> In-Reply-To: <20130813.125445.747003470323048065.ishizaki@dti.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] ***SPAM*** 6.352 (5) Re: Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 01:11:15 -0000 Ishizaki-san Thanks for your comment and positive feedback. We haven't noticed about GCM's behavior. It's very important information. I will check on it and get back to you. Anyway, we also want to know about detail. Thanks, kaname (2013/08/13 12:54), Yutaka Ishizaki wrote: > Hi Kaname, > > Thanks for published this document. it was a great help to me. > > I have a comment on the sections 6.1. > > http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-00#section-6.1 > this section is described that TCP NAT table time-out value is set to 300sec (5min), > and the setting didn't break the behavior of applications. > > in my experience, it seems not enough to behave the GCM (Google Cloud Messaging). > It seems to need more than 5 minutes. > > I can not find any document about protocol detail of GCM. (keepalive interval, etc) > > Let me know, if somebody knows the details. > > Thank you. > > > -- Yutaka Ishizaki > > > >> Dear all, >> >> I'm kaname from NTT communications in Japan. >> We are testing CGN under the support of Japanese Government. >> Now, we've uploaded a new draft based on the result of our verification. >> The useful information about the average consumption of the ports are available on the document. >> Please look through it, and all kind of feedback are welcome. >> >> By conducting realistic experiment, this draft is answering to "draft-ietf-behave-lsn-requirements-10" which will be the newest RFC \ > very soon. >> The document is *NOT* intended to be Standards Track. It's for Informational. >> The wrong description is just mere mistake, so we'll soon correct it in the next revision. >> >> The full report of our work will be available soon on the Web in English. >> I'll also announce it when it's available to this mailing-list. >> >> Best regards, >> >> kaname >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- ---- Kaname Nishizuka Innovative Architecture Center NTT Communications Corporation +81-50-3812-4704 From dwing@cisco.com Mon Aug 19 17:37:09 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9D711E8192 for ; Mon, 19 Aug 2013 17:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.441 X-Spam-Level: X-Spam-Status: No, score=-110.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYr4su-sTUp2 for ; Mon, 19 Aug 2013 17:37:05 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 775E411E80A2 for ; Mon, 19 Aug 2013 17:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=272; q=dns/txt; s=iport; t=1376959025; x=1378168625; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=t8teF5Zq9RKK7Qx+uxU25wqeuzjHCT8MfoX1N1WAz88=; b=mPMj0x72eiBcpnlClMPN0lP+10L7Qhz1JQixx4bT99ATAyX4HC3/R8s4 hJRzhHBQoawjhSJxKwMrn6WuvFO5rH2ZSv+jipYunbF26Gzrw0gFQ2oJn L9XzpqdMpU3a2EiVdixhsNk6GSDb1KWVS6bUCXyJ/4bFa6yF0EOm7kwgg Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMNALu5ElKrRDoH/2dsb2JhbABagwU1F4MNiUazEgICAgKBJRZtB4JlgX0TCYgGDZEomU6TfncDiS2ON4YpiyyDPBw X-IronPort-AV: E=Sophos;i="4.89,915,1367971200"; d="scan'208";a="89519231" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 20 Aug 2013 00:37:04 +0000 Received: from [10.21.102.166] ([10.21.102.166]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7K0b2r0009807 for ; Tue, 20 Aug 2013 00:37:03 GMT From: Dan Wing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <089AA17C-1BD7-4CE2-8D19-582E3E118D44@cisco.com> Date: Mon, 19 Aug 2013 17:37:02 -0700 To: "behave@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [BEHAVE] IETF87 BEHAVE minutes posted X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 00:37:09 -0000 Minutes from the IETF87 BEHAVE meeting have been posted to = http://www.ietf.org/proceedings/87/minutes/minutes-87-behave. Thanks to = our note takers, Stuart Cheshire and Philip Matthews. Please send additions or corrections to behave-chairs@tools.ietf.org. -d From dwing@cisco.com Wed Aug 28 20:58:08 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419CE11E80D9 for ; Wed, 28 Aug 2013 20:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.514 X-Spam-Level: X-Spam-Status: No, score=-110.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPMcpwnJMXVm for ; Wed, 28 Aug 2013 20:58:01 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B4E1D21F9E47 for ; Wed, 28 Aug 2013 20:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=911; q=dns/txt; s=iport; t=1377748680; x=1378958280; h=mime-version:subject:from:date:cc: content-transfer-encoding:message-id:references:to; bh=BMccTG+jQ/FcSan1dYEZSCjvbowiRTFweXJrxzMeDz8=; b=k7XAmAzkvO1+/gZi5b1sKAndnx9l2slcO+PYMkjgunAlswtTKdd9/M4+ MqG6MWDLbQhn89nFda4e4XzEJAzvxwu4inNoKTQLnErwl4t00p0ckNBoL uETF73hXwEhAOfyi7Ad16jXQ7HNxEZDaSrULgrdHfM5Qoj0lGPrARietq E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoGAJHFHlKrRDoI/2dsb2JhbABagwc1gzG9RoEkFm0HgiQBAQEDAQEBATc0CwULHAMBAg0XCyEGHwcCCAYTCYdmAwkFDa8MDYlqjH6BJhCBOQ2DFn0DiTSMVoFpjDWFL4FjgV0cgTU X-IronPort-AV: E=Sophos;i="4.89,980,1367971200"; d="scan'208";a="87925695" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 29 Aug 2013 03:58:00 +0000 Received: from sjc-vpn7-327.cisco.com (sjc-vpn7-327.cisco.com [10.21.145.71]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7T3vwth019650; Thu, 29 Aug 2013 03:57:58 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing Date: Wed, 28 Aug 2013 20:57:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <839BC95F-CE42-4535-9EC7-AD358054A3D4@cisco.com> References: <20130823194820.25946.44920.idtracker@ietfa.amsl.com> To: "behave@ietf.org" X-Mailer: Apple Mail (2.1508) Cc: "Behave Chairs \(behave-chairs@tools.ietf.org\)" Subject: [BEHAVE] Fwd: New Non-WG Mailing List: pntaw -- Discussion list for practices related to proxies, NATs, TURN, and WebRTC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 03:58:08 -0000 pntaw may be interesting to folks subscribed to BEHAVE. -d Begin forwarded message: > From: IETF Secretariat > Subject: New Non-WG Mailing List: pntaw -- Discussion list for = practices related to proxies, NATs, TURN, and WebRTC > Date: August 23, 2013 12:48:20 PM PDT > To: IETF Announcement List > Cc: , , = , > Reply-To: >=20 > A new IETF non-working group email list has been created. >=20 > List address: pntaw@ietf.org > Archive: http://www.ietf.org/mail-archive/web/pntaw/ > To subscribe: https://www.ietf.org/mailman/listinfo/pntaw >=20 > Purpose: This mailing list will discuss how webrtc clients, proxies, = NATs and TURN servers interact. >=20 > For additional information, please contact the list administrators.