From nobody Wed Sep 24 19:02:17 2014 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744391A6F04 for ; Wed, 24 Sep 2014 19:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.449 X-Spam-Level: * X-Spam-Status: No, score=1.449 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dT_cQpVq9jyj for ; Wed, 24 Sep 2014 19:02:14 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 174941A6ED9 for ; Wed, 24 Sep 2014 19:02:13 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,593,1406606400"; d="scan'208";a="526481892" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 24 Sep 2014 21:58:57 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Wed, 24 Sep 2014 22:02:13 -0400 From: "George, Wes" To: Tom Taylor , "sunset4@ietf.org" Date: Wed, 24 Sep 2014 22:02:18 -0400 Thread-Topic: [sunset4] review of draft-chen-sunset4-cgn-port-allocation Thread-Index: Ac/YZLkBRcokOs/7TrCOLGQz1eTsRA== Message-ID: References: <53EB4E2E.9000506@gmail.com> In-Reply-To: <53EB4E2E.9000506@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sunset4/phSnDFhC1jSV9sxOIfbWajUyKIc Cc: "draft-chen-sunset4-cgn-port-allocation@tools.ietf.org" Subject: Re: [sunset4] review of draft-chen-sunset4-cgn-port-allocation X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 02:02:16 -0000 QXV0aG9ycywgeW91IGhhdmUgYSBkcmFmdCB0aGF0IHdpbGwgZXhwaXJlIGluIGEgZmV3IHdlZWtz LCBhcyB3ZWxsIGFzIG9uZQ0Kb3IgbW9yZSBzdWJzdGFudGl2ZSByZXZpZXdzIHRvIGFkZHJlc3Mu IFBsZWFzZSBwdXNoIGEgcmV2aXNpb24sIGFuZCB0aGVuDQp3ZSB3aWxsIGRvIGFuIGFkb3B0aW9u IGNhbGwgc28gdGhhdCB3ZSBjYW4gZGlzY3VzcyBpdCBmdXJ0aGVyIGFzIGEgV0cNCmRyYWZ0IGR1 cmluZyB0aGUgbWVldGluZyBpbiBob25vbHVsdS4NCg0KDQpUaGFua3MsDQoNCldlcw0KDQoNCg0K T24gOC8xMy8xNCwgNzozOCBBTSwgIlRvbSBUYXlsb3IiIDx0b20udGF5bG9yLnN0ZHNAZ21haWwu Y29tPiB3cm90ZToNCg0KPkxlZSwgdGhhbmsgeW91IGZvciB0aGUgdGltZSB5b3UgcHV0IGludG8g dGhpcy4gSSB3b24ndCBiZSBhYmxlIHRvIGRlYWwNCj53aXRoIGEgbG90IG9mIGl0IHBlcnNvbmFs bHkgYmVjYXVzZSBpdCByZXF1aXJlcyBteSBjby1hdXRob3JzJw0KPmtub3dsZWRnZS4gSG93ZXZl ciwgYmFzZWQgb24gdGhlIElQUiBkaXNjdXNzaW9uIGF0IHRoZSBtZWV0aW5nLCBJIHRoaW5rDQo+ d2Ugd2lsbCBzcGxpdCBvdXQgZGV0ZXJtaW5pc3RpYyBDR04gYW5kIGxldCBpdCBnbyBvbiBpdHMg d2F5IGFzIGFuDQo+aW5kaXZpZHVhbCBkcmFmdC4gSSBjYW4gZG8gdGhhdCBzdGVwIGFuZCByZXNw b25kIHRvIGFzIG11Y2ggb2YgeW91cg0KPnJldmlldyBhcyBJIGNhbi4gTXkgY28tYXV0aG9ycyBj YW4gdGFrZSB0aGUgbmV4dCBzdGVwIG9yIGFkdmlzZSBtZSBvbg0KPnRoZSByZW1haW5pbmcgaXNz dWVzLg0KPg0KPlRvbSBUYXlsb3INCj4NCj5PbiAyNC8wNy8yMDE0IDQ6MDIgUE0sIExlZSBIb3dh cmQgd3JvdGU6DQo+PiBEb2luZyBteSBob21ld29yayBiZWZvcmUgdGhlIFdHIG1lZXRpbmcgdGhp cyBhZnRlcm5vb24gKGFuZCByZS1zZW5kaW5nDQo+PmZyb20NCj4+IHRoZSBjb3JyZWN0IGVtYWls IGFkZHJlc3MpLiAuIC4NCj4+DQo+PiBUaGlzIGRvY3VtZW50IG5lZWRzIHNpZ25pZmljYW50IHdv cmsgYW5kIHJlb3JnYW5pemF0aW9uLg0KPj4NCj4+IDEuIEludHJvZHVjdGlvbg0KPj4gWW91IHNh eToNCj4+IHByb3ZpZGUgdHJhbnNwYXJlbnQgcm91dGluZyB0byBlbmQgaG9zdHMNCj4+IEkgdGhp bmsgaXQgc2hvdWxkIHNheToNCj4+IHByb3ZpZGUgY29ubmVjdGl2aXR5IHRvIGVuZCBob3N0cw0K Pj4NCj4+IElzIGl0IHdvcnRoIGFkZGluZyBhIHNlbnRlbmNlIHRoYXQgdGhlc2UgbWV0aG9kcyBh cmUgb25seSB1c2VmdWwgZm9yDQo+PmFkZHJlc3MNCj4+IHNoYXJpbmcgbWV0aG9kcywgbm90IE5Q VCwgYW5kIG5vdCBlbmNhcHN1bGF0aW9uIG1lY2hhbmlzbXM/ICBJdCBtYXkgbm90DQo+PmJlDQo+ PiBuZWNlc3NhcnkuDQo+PiBCdXQsIGZvciBpbnN0YW5jZSwgdGhpcyBzZW50ZW5jZToNCj4+IFRo ZSBDR04gbWF5IG5vdCBkbyBOZXR3b3JrIEFkZHJlc3MgUG9ydCBUcmFuc2xhdGlvbiAgIChOQVBU KSwgYnV0IG9ubHkNCj4+IE5ldHdvcmsgQWRkcmVzcyBUcmFuc2xhdGlvbiAoTkFUKSBbUkZDMzAy Mg0KPj4gPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMwMjI+IF0uDQo+Pg0KPj4gVEhh dCdzIG5vdCBhbiByZmMyMTE5ICJtYXkgbm90LCIgaXQncyBhIGRlc2NyaXB0aW9uIG9mIG9uZSBz Y2VuYXJpby4gIEkNCj4+aGFkDQo+PiB0byByZWFkIGl0IGZvdXIgdGltZXMgdG8gZmlndXJlIHRo YXQgb3V0OyBtYXliZSBpdCB3b3VsZCBiZSBjbGVhcmVyIGFzOg0KPj4+IFRoZSBDR04gbWlnaHQg ZG8gTmV0d29yayBBZGRyZXNzIFBvcnQgVHJhbnNsYXRpb24NCj4+PiAgICAgKE5BUFQpIHdpdGhv dXQgTmV0d29yayBBZGRyZXNzIFRyYW5zbGF0aW9uIChOQVQpIFtSRkMzMDIyDQo+Pj4gPGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMwMjI+IF0uICBJbg0KPj4+ICAgICB0aGlzIHNjZW5h cmlvLCB0aGVyZSBpcyBubyBjb25jZXJuIGFib3V0IHBvcnQgYXNzaWdubWVudC4gV2hlbg0KPj4+ TkFQVCBpcw0KPj4+IGludm9sdmVkLCDFoA0KPj4gVGhlbiB5b3UgY2FuIGVudW1lcmF0ZSB0aGUg ImRvZXMiIGFuZCAiZG9lcyBub3QiIGNhc2VzLg0KPj4NCj4+IGluZGVwZW5kZW50bHkgb2YgdGhl IHBhcnRpY3VsYXIgZmxhdm91ciBzaG91bGQgYmUgaW5kZXBlbmRlbnQgb2YgdGhlDQo+PiBwYXJ0 aWN1bGFyIGZsYXZvdXINCj4+IFNlY3Rpb24gMi4xIFBvcnQgQ29uc3VtcHRpb24gb24gTkFUNjQN Cj4+DQo+PiBUaGlzIGVkaXRvcmlhbGl6aW5nIGlzIHVubmVjZXNzYXJ5Og0KPj4+IFRoYW5rcyB0 byBpdHMgc2ltcGxpY2l0eSBhbmQgZWZmaWNpZW5jeSwgTkFUNjQgd2lsbCBsaWtlbHkgYmUNCj4+ PiAgICAgZGVwbG95ZWQgd2lkZWx5Lg0KPj4NCj4+IEFsc28sDQo+PiAgIFRoYXQgaXMsIGEgTkFU NDQgd2lsbCBiZSBkZXBsb3llZCBpbiBhbg0KPj4gICAgIElQdjQtb25seSBlbnZpcm9ubWVudC4N Cj4+IE5BVDQ0ICsgTmF0aXZlIElQdjYgaXMgYSBwZXJmZWN0bHkgcmVhc29uYWJsZSBhbmQgbGlr ZWx5IHNjZW5hcmlvLCBzbw0KPj50aGlzDQo+PiBpcyB1bnRydWUuICBCdXQgdGhpcyB3aG9sZSBw YXJhZ3JhcGggcmVhZHMgbGlrZSBhIHNhbGVzIHBpdGNoIGZvcg0KPj5OQVQ2NDogY3V0DQo+PiBp dCBvdXQuDQo+PiBTZWNvbmQgcGFyYWdyYXBoOg0KPj4gT25lIG9mIHRoZSBhdXRob3JzIGRpZCBh IHRlc3QgY29tcGFyaXNvbiBvZiBwb3J0IGNvbnN1bXB0aW9uIG9uIE5BVDY0DQo+PiAgICAgYW5k IE5BVDQ0Lg0KPj4gQ2FuIHlvdSBqdXN0IGNpdGUgdGhlIHN0dWR5PyAgQ2FuIHlvdSBzYXksICJB IHN0dWR5IG9mIHBvcnQgY29uc3VtcHRpb24NCj4+IFtwb3J0c3R1ZHldLiAuIC4iICBUaG91Z2gg YWdhaW4sIHRoaXMgd2hvbGUgc3R1ZHkgaXMgb25seSB0cnVlIHRvIGENCj4+cG9pbnQgaW4NCj4+ IHRpbWUgKHRob3VnaCB3aGF0IHZlcnNpb24gb2YgdGhlIEFsZXhhMTAwIGluY2x1ZGVzIDQzIHNp dGVzIHdpdGggQUFBQSBJDQo+PiBkb24ndCBrbm93KS4NCj4+DQo+PiBOQVQ2NCAicHJvdmlkZXMg ZXZlcnlvbmUgd2l0aCBpbmNlbnRpdmVzIHRvIHVzZSBJUHY2LCINCj4+IFdoYXQgaW5jZW50aXZl cz8gIERvZXMgaXQgYnV5IGljZSBjcmVhbSBmb3IgZXZlcnlvbmUgd2hvIHVzZXMgSVB2Nj8NCj4+ RWl0aGVyDQo+PiBleHBsYWluLCBvciwgc2luY2UgZGVmZW5kaW5nIHRoZSB1c2Ugb2YgTkFUNjQg aXMgb3V0IG9mIHBsYWNlIGluIHRoaXMNCj4+IGRvY3VtZW50LCByZW1vdmUuDQo+Pg0KPj4gW2Fz IHY2IHRyYW5zaXRpb24gcHJvZ3Jlc3NlcyxdIGl0IHdpbGwgYmUgcG9zc2libGUgdG8gcmVsYXgg dGhlDQo+PiAgICAgbXVsdGlwbGV4aW5nIHJhdGlvIG9mIElQdjQgYWRkcmVzcyBzaGFyaW5nLg0K Pj4gVGhpcyBpcyBhIGdvb2QgcG9pbnQuDQo+Pg0KPj4gICBjaGFuZ2Ugb2YgSVB2NCBhZGRyZXNz IHdpbGwgY2F1c2UNCj4+ICAgICByZW51bWJlcmluZyBvZiBJUHY2IGFkZHJlc3Nlcy4NCj4+IEkg ZG9uJ3Qgc2VlIGhvdy4gIEJ1dCBhZ2FpbiwgSSBkb24ndCB0aGluayB0aGlzIGlzIGludGVuZGVk IGFzIGEgTkFUDQo+PiBkaXNjdXNzaW9uIGRvY3VtZW50LCBJIHRob3VnaHQgaXQgd2FzIGp1c3Qg ZXZhbHVhdGluZyBwb3J0IGFsbG9jYXRpb24NCj4+IG1ldGhvZHMuICBDbGVhbiB1cCB0aGF0IHBh cmFncmFwaC4NCj4+DQo+PiBJdCBoYXMgYmVlbiBsZWFybmVkIGZyb20gc3Vic2NyaWJlcnMnDQo+ PiAgICAgICAgICAgIGJlaGF2aW9ycyB0aGF0IHRoZSBhdmVyYWdlIG51bWJlciBvZiBzZXNzaW9u cyBjb25zdW1lZCBieSBvbmUNCj4+ICAgICAgICAgICAgdXNlcidzIGRldmljZSBpcyBhcm91bmQg MjAwIHRvIDMwMCBwb3J0cy4gIFNldmVyYWwgZGV2aWNlcw0KPj5tYXkNCj4+ICAgICAgICAgICAg YXBwZWFyIGJlaGluZCBhIENQRS4gIEFkbWluaXN0cmF0b3JzIG1heSBjb25maWd1cmUgYSByYW5n ZQ0KPj4gICAgICAgICAgICB3aXRoIDEwMDAgcG9ydHMgdG8gZWFjaCBDUEUgaW4gZml4ZWQgbmV0 d29ya3MuDQo+PiBBdm9pZCB0aGUgcGFzc2l2ZSB2b2ljZS4gIENhbiB5b3UgY2l0ZSB0aGUgMjAw LTMwMCBudW1iZXI/ICBJcyB0aGF0DQo+PnRydWUgaW4NCj4+IDIwMTQsIG9yIGZvciBhcyBsb25n IGFzIHRoaXMgZG9jdW1lbnQgaXMgaW50ZW5kZWQgdG8gYmUgdXNlZnVsPyAgWWVzLA0KPj4gYWRt aW5pc3RhdG9ycyBtYXkgY29uZmlndXJlIDEwMDAgcG9ydHMuICBPciAxMDAxLiAgT3IgOTk5LiAg TWF5YmUgd2hhdA0KPj55b3UNCj4+IG1lYW4gaXM6DQo+PiAgIDEwMDAgcG9ydHMgcGVyIHN1YnNj cmliZXIgaG91c2Vob2xkIHdpbGwgcHJvdmlkZSBlbm91Z2ggcm9vbSBmb3INCj4+bXVsdGlwbGUN Cj4+IGFjdGl2ZSB1c2Vycy4gIEFkbWluaXN0cmF0b3JzIHNob3VsZCBtb25pdG9yIHVzYWdlIHRv IGFkanVzdCB0aGlzDQo+Pm51bWJlciBpZg0KPj4gdXNlcnMgYXJlIGJlaW5nIGxpbWl0ZWQgYnkg dGhpcyBudW1iZXIsIG9yIGlmIHVzYWdlIGlzIHNvIGxvdyB0aGF0IGZld2VyDQo+PiBwb3J0cyB3 b3VsZCBiZSBzdWZmaWNpZW50Lg0KPj4NCj4+IG5vbi1jb250aWd1b3VzIHBvcnQgcmFuZ2UgZm9y IHRoZQ0KPj4gICAgICAgIHNha2Ugb2YgYXR0YWNrIGRlZmVuc2UuDQo+PiBJIHRoaW5rIHlvdSBl eHBsYWluIHRoaXMgbGF0ZXIgaW4gdGhlIGRvY3VtZW50LCBidXQgYSByZWZlcmVuY2UgdG8gd2hh dA0KPj55b3UNCj4+IG1lYW4gaGVyZSB3b3VsZCBoZWxwLg0KPj4gQStQIHN0eWxlIFtjaXRhdGlv biBuZWVkZWRdDQo+Pg0KPj4gMi4zLjEgIFVzZSBvZiB0aGUgd29yZCAib2xkZXIiIHNvdW5kcyBw ZXJqb3JhdGl2ZS4gIERvIHlvdSBtZWFuIHRvIGltcGx5DQo+PiB0aGF0IE5BVDY0IGlzIG9ic29s ZXRlPyAgQm90aCBpbiB0aGUgdGl0bGUgYW5kIHRleHQuDQo+PiBTdGVwcGluZyBvdXRzaWRlDQo+ PiAgICAgdGhlIGJvdW5kYXJpZXMgb2YgTkFUNjQgZm9yIHRoZSBtb21lbnQsIERTLUxpdGUgW1JG QzYzMzMNCj4+IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MzMzPiBdIHJlZmVycyB0 bw0KPj4gICAgIHRoZSBjYXV0aW9ucyBpbiBbUkZDNjI2OSA8aHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNjI2OT4gXSBidXQNCj4+ZG9lcw0KPj4gbm90IHNwZWNpZnkgYW55IHBvcnQgYWxs b2NhdGlvbg0KPj4gICAgIG1ldGhvZC4NCj4+IEZpcnN0LCB0aGF0J3MgcHJldHR5IGluZm9ybWFs IGxhbmd1YWdlLiAgU2Vjb25kLCB3aHkgcG9pbnQgdG8gRFMtTGl0ZQ0KPj4gcG9pbnRpbmcgdG8g UkZDNjI2OTsgd2h5IG5vdCBqdXN0IHBvaW50IHRvIFJGQzYyNjk/DQo+PiAyLjMuMiBDdXJyZW50 IFdvcmsgb24gU3RhdGVsZXNzIFRyYW5zaXRpb24gVGVjaG5vbG9naWVzDQo+PiBUaGUgcHJvcG9z YWxzIG1hZGUgaW4gU2VjdGlvbiAzDQo+Pg0KPj48aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtY2hlbi1zdW5zZXQ0LWNnbi1wb3J0LWFsbG9jYXRpb24tMDQjc2VjDQo+PnRpbw0KPj4g bi0zPiAgYW5kIFNlY3Rpb24gNA0KPj4NCj4+PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWNoZW4tc3Vuc2V0NC1jZ24tcG9ydC1hbGxvY2F0aW9uLTA0I3NlYw0KPj50aW8NCj4+IG4t ND4gIGRvIG5vdCBhcHBseQ0KPj4gICAgIHRvIHRoZSBjdXJyZW50IHdvcmsgaW4gcHJvZ3Jlc3Mg YmVjYXVzZSB0aGF0IHdvcmsgaGFzIGdvbmUgaW4NCj4+YW5vdGhlcg0KPj4gICAgIGRpcmVjdGlv bi4gIFRoYXQgd29yayBpbmNsdWRlczoNCj4+IERvIHdlIG5lZWQgdG8gZW51bWVyYXRlIHByb3Rv Y29scyB0aGF0IHRoaXMgd29yayBkb2Vzbid0IGFwcGx5IHRvPyAgSWYNCj4+c28sDQo+PiB0aGVu IEkgdGhpbmsgdGhpcyBkb2N1bWVudCBpcyBtYWtpbmcgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8g dGhvc2UNCj4+cHJvdG9jb2xzDQo+PiAoc2luY2UgdGhlaXIgcG9ydCBhbGxvY2F0aW9uIG1ldGhv ZHMgY291bGQsIHBvdGVudGlhbGx5LCBjaGFuZ2UgdW50aWwNCj4+dGhleQ0KPj4gYXJlIHB1Ymxp c2hlZCksIHdoaWNoIHdpbGwgZGVsYXkgcHVibGljYXRpb24gdW50aWwgbHc0b3ZlcjYsIE1BUC1U LA0KPj5NQVAtRSwNCj4+IDRyZCBoYXZlIGFsbCBiZWVuIHB1Ymxpc2hlZC4gIEhhdmluZyBzYWlk IHRoYXQsIHRoaXMgbWF5IGJlIGEgdXNlZnVsDQo+PiBjb21wYXJpc29uIG9mIHBvc3NpYmxlIG1l dGhvZHMsIGJ1dCBJIHdvdWxkIHRyeSB0byBsaW1pdCBpdCB0byB0aGF0Lg0KPj4gU2VjdGlvbnMg Mi40LjEgYW5kIDIuNC4yIGFyZSBleGNlbGxlbnQuDQo+PiAyLjQuMyBzL2FsbGxvY2F0aW9uL2Fs bG9jYXRpb24NCj4+IDMuMSBVUyBtZWFucyBVLlMuPyAgQW1lcmljYW5zIGhhdmUgaGlnaGVyIHRy YWZmaWMgcHJvZmlsZXM/DQo+PiAzLjIgUmVtb3ZlIHNlbnRlbmNlICJIZXJlIGlzIGhvdyBkeW5h bWljIGFsbG9jYXRpb24gb2YgcG9ydC1yYW5nZXMgd291bGQNCj4+IHdvcmsgaW4gZ3JlYXRlciBk ZXRhaWwuICINCj4+IDMuMyBTZWN0aW9uIDExIG9mIFJGQzYyNjkgcmVmZXJzIHRvIGZyYWdtZW50 YXRpb247IHlvdSBtZWFuIHNlY3Rpb24gMTIuDQo+PiBJcw0KPj4gdGhpcyBzZWN0aW9uIHN1cHBv c2VkIHRvIGJlIGEgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uPw0KPj4gRGlzY292ZXJh YmlsaXR5PyAgSSB0aGluayBpbiB0aGUgZXJhIG9mIFBlcnZhc2l2ZSBTdXJ2ZWlsbGFuY2UsDQo+ PnJlZmVyZW5jZSB0bw0KPj4gb3RoZXIgSUVURiB3b3JrIGlzIG5lZWRlZC4gIEFsc28sIHBsZWFz ZSByZWZlciB0byBSRkM2MzAyLg0KPj4gSSdtIG5vdCBzdXJlLCB0aG91Z2gsIHRoYXQgdGhlIGRp c2N1c3Npb24gb2Ygc2VydmVyIHBvcnQgbG9nZ2luZyBpcw0KPj4gYXBwcm9wcmlhdGUgaW4gYSBk b2N1bWVudCBhYm91dCBob3cgdG8gYWxsb2NhdGUgcG9ydHMgaW4gQ0dOLiAgQQ0KPj5tZW50aW9u IG9mDQo+PiBpdCBtYWtlcyBzZW5zZSwgYnV0IGV2YWx1YXRpbmcgdGhlIGNhcGFiaWxpdHkgb2Yg ZGlmZmVyZW50IHdlYiBzZXJ2ZXJzLA0KPj53aXRoDQo+PiBhIGNvbmZpZyBndWlkZSwgc2VlbXMg b3V0IG9mIHBsYWNlLg0KPj4gVGhlc2UgInRyYWNlYWJpbGl0eSIgaXNzdWVzIGFwcGx5IGVxdWFs bHkgdG8gYWxsIHBvcnQgYWxsb2NhdGlvbg0KPj5tZXRob2RzLA0KPj4gcmlnaHQ/ICBNYXliZSBh IFByaXZhY3kgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBhdCB0aGUgZW5kLg0KPj4gSSBkaWRuJ3Qg cmV2aWV3IHNlY3Rpb24gNCwgYmVjYXVzZSBJJ3ZlIHJldmlld2VkIGl0IGJlZm9yZS4gIEFuZCBJ IHJhbg0KPj5vdXQNCj4+IG9mIHRpbWUuDQo+PiA1LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBu ZWVkcyBhIHJld3JpdGXigLlpdCBjb21wbGV0ZWx5IGlnbm9yZXMNCj4+U2VjdGlvbiA0Lg0KPj4g VGhhdCdzIGFsbCBJIGhhdmUgb24gdGhpcyByb3VuZC4NCj4+IExlZQ0KPj4NCj4+DQo+Pg0KPj4N Cj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+IHN1bnNldDQgbWFpbGluZyBsaXN0DQo+PiBzdW5zZXQ0QGlldGYub3JnDQo+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1bnNldDQNCj4+DQo+DQo+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zdW5zZXQ0IG1haWxp bmcgbGlzdA0KPnN1bnNldDRAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3N1bnNldDQNCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlv biwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHly aWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hp Y2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1p bmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlv biB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2Yg dGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== From nobody Thu Sep 25 02:53:52 2014 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2291A03A8 for ; Thu, 25 Sep 2014 02:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrcriVbAAiqy for ; Thu, 25 Sep 2014 02:53:44 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB8C1A1C03 for ; Thu, 25 Sep 2014 02:53:44 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id rd18so8548889iec.2 for ; Thu, 25 Sep 2014 02:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TLMDTxGwWizugZtxvn9D7GSB9PZDHdFUQ+dzJGOGBhA=; b=SxUjhI7zaE8oN6IaPFJ2s1fhWKxUdh41cFDlkO/YMPHXAhDs5FCSYorPUXLNwGWVPI cuV1ETcXGBmLHzGp2ViDB+hCHHCbGUI5lw/niUwjyKE3CMzVcxvQ/jEsMeZ+VaZNEoNb dzF5BHJmXzLPYkWWKGAQ07mKZNbWF833nYbYX3FY1xurg4atw76tX3plCk8FHvkL+3Pw 86vM6UqJnb35fsnh9Z+WOkN77USsSQj+4qBt3W5BrIcfE74pIj6uETepLgNEGrypgZTk qPzmkl49TgHy9Q/tBU+O6SApzRTkzZ5M+9pKzYVFBgSNrg9Sv2kLGxNoAfoga1wlDk4n 1RNg== X-Received: by 10.50.147.38 with SMTP id th6mr3039204igb.31.1411638824062; Thu, 25 Sep 2014 02:53:44 -0700 (PDT) Received: from [192.168.97.188] ([67.210.160.130]) by mx.google.com with ESMTPSA id j2sm6594920igm.21.2014.09.25.02.53.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Sep 2014 02:53:43 -0700 (PDT) Message-ID: <5423E628.7070204@gmail.com> Date: Thu, 25 Sep 2014 05:53:44 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "George, Wes" , "sunset4@ietf.org" References: <53EB4E2E.9000506@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sunset4/5lkiq90ramY2OOZgK_b0axUozmc Cc: "draft-chen-sunset4-cgn-port-allocation@tools.ietf.org" Subject: Re: [sunset4] review of draft-chen-sunset4-cgn-port-allocation X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 09:53:51 -0000 Excellent timing. I've freed myself more or less from some other stuff and can get on this today. I get a new version out, then let my co-authors address those of Lee's comments that I cannot. Tom On 24/09/2014 10:02 PM, George, Wes wrote: > Authors, you have a draft that will expire in a few weeks, as well as one > or more substantive reviews to address. Please push a revision, and then > we will do an adoption call so that we can discuss it further as a WG > draft during the meeting in honolulu. > > > Thanks, > > Wes > > > > On 8/13/14, 7:38 AM, "Tom Taylor" wrote: > >> Lee, thank you for the time you put into this. I won't be able to deal >> with a lot of it personally because it requires my co-authors' >> knowledge. However, based on the IPR discussion at the meeting, I think >> we will split out deterministic CGN and let it go on its way as an >> individual draft. I can do that step and respond to as much of your >> review as I can. My co-authors can take the next step or advise me on >> the remaining issues. >> >> Tom Taylor >> >> On 24/07/2014 4:02 PM, Lee Howard wrote: >>> Doing my homework before the WG meeting this afternoon (and re-sending >>> from >>> the correct email address). . . >>> >>> This document needs significant work and reorganization. >>> >>> 1. Introduction >>> You say: >>> provide transparent routing to end hosts >>> I think it should say: >>> provide connectivity to end hosts >>> >>> Is it worth adding a sentence that these methods are only useful for >>> address >>> sharing methods, not NPT, and not encapsulation mechanisms? It may not >>> be >>> necessary. >>> But, for instance, this sentence: >>> The CGN may not do Network Address Port Translation (NAPT), but only >>> Network Address Translation (NAT) [RFC3022 >>> ]. >>> >>> THat's not an rfc2119 "may not," it's a description of one scenario. I >>> had >>> to read it four times to figure that out; maybe it would be clearer as: >>>> The CGN might do Network Address Port Translation >>>> (NAPT) without Network Address Translation (NAT) [RFC3022 >>>> ]. In >>>> this scenario, there is no concern about port assignment. When >>>> NAPT is >>>> involved, Å  >>> Then you can enumerate the "does" and "does not" cases. >>> >>> independently of the particular flavour should be independent of the >>> particular flavour >>> Section 2.1 Port Consumption on NAT64 >>> >>> This editorializing is unnecessary: >>>> Thanks to its simplicity and efficiency, NAT64 will likely be >>>> deployed widely. >>> >>> Also, >>> That is, a NAT44 will be deployed in an >>> IPv4-only environment. >>> NAT44 + Native IPv6 is a perfectly reasonable and likely scenario, so >>> this >>> is untrue. But this whole paragraph reads like a sales pitch for >>> NAT64: cut >>> it out. >>> Second paragraph: >>> One of the authors did a test comparison of port consumption on NAT64 >>> and NAT44. >>> Can you just cite the study? Can you say, "A study of port consumption >>> [portstudy]. . ." Though again, this whole study is only true to a >>> point in >>> time (though what version of the Alexa100 includes 43 sites with AAAA I >>> don't know). >>> >>> NAT64 "provides everyone with incentives to use IPv6," >>> What incentives? Does it buy ice cream for everyone who uses IPv6? >>> Either >>> explain, or, since defending the use of NAT64 is out of place in this >>> document, remove. >>> >>> [as v6 transition progresses,] it will be possible to relax the >>> multiplexing ratio of IPv4 address sharing. >>> This is a good point. >>> >>> change of IPv4 address will cause >>> renumbering of IPv6 addresses. >>> I don't see how. But again, I don't think this is intended as a NAT >>> discussion document, I thought it was just evaluating port allocation >>> methods. Clean up that paragraph. >>> >>> It has been learned from subscribers' >>> behaviors that the average number of sessions consumed by one >>> user's device is around 200 to 300 ports. Several devices >>> may >>> appear behind a CPE. Administrators may configure a range >>> with 1000 ports to each CPE in fixed networks. >>> Avoid the passive voice. Can you cite the 200-300 number? Is that >>> true in >>> 2014, or for as long as this document is intended to be useful? Yes, >>> administators may configure 1000 ports. Or 1001. Or 999. Maybe what >>> you >>> mean is: >>> 1000 ports per subscriber household will provide enough room for >>> multiple >>> active users. Administrators should monitor usage to adjust this >>> number if >>> users are being limited by this number, or if usage is so low that fewer >>> ports would be sufficient. >>> >>> non-contiguous port range for the >>> sake of attack defense. >>> I think you explain this later in the document, but a reference to what >>> you >>> mean here would help. >>> A+P style [citation needed] >>> >>> 2.3.1 Use of the word "older" sounds perjorative. Do you mean to imply >>> that NAT64 is obsolete? Both in the title and text. >>> Stepping outside >>> the boundaries of NAT64 for the moment, DS-Lite [RFC6333 >>> ] refers to >>> the cautions in [RFC6269 ] but >>> does >>> not specify any port allocation >>> method. >>> First, that's pretty informal language. Second, why point to DS-Lite >>> pointing to RFC6269; why not just point to RFC6269? >>> 2.3.2 Current Work on Stateless Transition Technologies >>> The proposals made in Section 3 >>> >>> >> tio >>> n-3> and Section 4 >>> >>> >> tio >>> n-4> do not apply >>> to the current work in progress because that work has gone in >>> another >>> direction. That work includes: >>> Do we need to enumerate protocols that this work doesn't apply to? If >>> so, >>> then I think this document is making normative references to those >>> protocols >>> (since their port allocation methods could, potentially, change until >>> they >>> are published), which will delay publication until lw4over6, MAP-T, >>> MAP-E, >>> 4rd have all been published. Having said that, this may be a useful >>> comparison of possible methods, but I would try to limit it to that. >>> Sections 2.4.1 and 2.4.2 are excellent. >>> 2.4.3 s/alllocation/allocation >>> 3.1 US means U.S.? Americans have higher traffic profiles? >>> 3.2 Remove sentence "Here is how dynamic allocation of port-ranges would >>> work in greater detail. " >>> 3.3 Section 11 of RFC6269 refers to fragmentation; you mean section 12. >>> Is >>> this section supposed to be a privacy considerations section? >>> Discoverability? I think in the era of Pervasive Surveillance, >>> reference to >>> other IETF work is needed. Also, please refer to RFC6302. >>> I'm not sure, though, that the discussion of server port logging is >>> appropriate in a document about how to allocate ports in CGN. A >>> mention of >>> it makes sense, but evaluating the capability of different web servers, >>> with >>> a config guide, seems out of place. >>> These "traceability" issues apply equally to all port allocation >>> methods, >>> right? Maybe a Privacy Considerations section at the end. >>> I didn't review section 4, because I've reviewed it before. And I ran >>> out >>> of time. >>> 5. Security Considerations needs a rewrite‹it completely ignores >>> Section 4. >>> That's all I have on this round. >>> Lee >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> sunset4 mailing list >>> sunset4@ietf.org >>> https://www.ietf.org/mailman/listinfo/sunset4 >>> >> >> _______________________________________________ >> sunset4 mailing list >> sunset4@ietf.org >> https://www.ietf.org/mailman/listinfo/sunset4 > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > From nobody Mon Sep 29 08:55:49 2014 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DC61A882D for ; Mon, 29 Sep 2014 08:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFeNS5HAe7ze for ; Mon, 29 Sep 2014 08:55:42 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8411A8838 for ; Mon, 29 Sep 2014 08:55:41 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id rp18so1742114iec.16 for ; Mon, 29 Sep 2014 08:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=+XODlls41CJ7tI1qHUYjsIa53v3A8UvzYQVNmHj7A9o=; b=RzDVEFYh2BIQ9+q78I+h2PlwGyqHcYlNXzVUipSyRoJ6/2xT1zyLykfEzTPyZBTGJZ ol29FIAa+i25F7a/vWkGh2rxLO3ZvjGbbmE/gsOu72MVw9zYZhZdx4ce2cs5bINcykAl JtvsSOyYEKRbIrLB7AWZwWMg+antnudknsy2lrGsolK4hG1+V6seQSwnYy0V72bMdPVa +ZNFFanQEeBUI4wDvmHfyLbdSy9Dk43Aim/CUxGq9F4ufCzEPH7oXZsV3wVjRbU7Sgew 3Dj07RIBCbxRXal/Ove+ToKcz9AKFpIXqGKFpUbdBs+tnt5CW83uxSk0cRjNUAClesNc Bi4A== X-Received: by 10.50.138.233 with SMTP id qt9mr35466213igb.30.1412006141289; Mon, 29 Sep 2014 08:55:41 -0700 (PDT) Received: from [192.168.0.103] (dsl-173-206-104-235.tor.primus.ca. [173.206.104.235]) by mx.google.com with ESMTPSA id o8sm10672469igh.12.2014.09.29.08.55.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Sep 2014 08:55:40 -0700 (PDT) Message-ID: <542980FB.6000200@gmail.com> Date: Mon, 29 Sep 2014 11:55:39 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Lee Howard , sunset4@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sunset4/U4y-8sFrTZlLkY34XPrUHB8Q8Z0 Subject: Re: [sunset4] review of draft-chen-sunset4-cgn-port-allocation X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 15:55:47 -0000 Responses marked with [PTT]. Thanks again for doing this review. Tom Taylor On 24/07/2014 4:02 PM, Lee Howard wrote: > Doing my homework before the WG meeting this afternoon (and re-sending from > the correct email address). . . > > This document needs significant work and reorganization. > > 1. Introduction > You say: > provide transparent routing to end hosts > I think it should say: > provide connectivity to end hosts [PTT] Done. > > Is it worth adding a sentence that these methods are only useful for address > sharing methods, not NPT, and not encapsulation mechanisms? It may not be > necessary. > But, for instance, this sentence: > The CGN may not do Network Address Port Translation (NAPT), but only > Network Address Translation (NAT) [RFC3022 > ]. > > THat's not an rfc2119 "may not," it's a description of one scenario. I had > to read it four times to figure that out; maybe it would be clearer as: >> The CGN might do Network Address Port Translation >> (NAPT) without Network Address Translation (NAT) [RFC3022 >> ]. In >> this scenario, there is no concern about port assignment. When NAPT is >> involved, Š > Then you can enumerate the "does" and "does not" cases. [PTT] Rewrote and moved text to new paragraph at end of section: NEW PARA The considerations in this document do not apply where the CGN does only Network Address Translation (NAT) . In this scenario, there is no concern about port assignment. Similarly, this document does not apply where encapsulation rather than translation is used as the IPv6 transition method. > > independently of the particular flavour should be independent of the > particular flavour [PTT] I'll leave that to the RFC Editor. According to the grammar I was taught, "independently" is an adverb modifying the adjective "applicable". > Section 2.1 Port Consumption on NAT64 > > This editorializing is unnecessary: >> Thanks to its simplicity and efficiency, NAT64 will likely be >> deployed widely. > > Also, > That is, a NAT44 will be deployed in an > IPv4-only environment. > NAT44 + Native IPv6 is a perfectly reasonable and likely scenario, so this > is untrue. But this whole paragraph reads like a sales pitch for NAT64: cut > it out. [PTT] Done. > Second paragraph: > One of the authors did a test comparison of port consumption on NAT64 > and NAT44. > Can you just cite the study? Can you say, "A study of port consumption > [portstudy]. . ." Though again, this whole study is only true to a point in > time (though what version of the Alexa100 includes 43 sites with AAAA I > don't know). [PTT] Changed to "China Mobile". If Gang has a published study he can give a reference. > > NAT64 "provides everyone with incentives to use IPv6," > What incentives? Does it buy ice cream for everyone who uses IPv6? Either > explain, or, since defending the use of NAT64 is out of place in this > document, remove. [PTT] Done. > > [as v6 transition progresses,] it will be possible to relax the > multiplexing ratio of IPv4 address sharing. > This is a good point. > > change of IPv4 address will cause > renumbering of IPv6 addresses. > I don't see how. But again, I don't think this is intended as a NAT > discussion document, I thought it was just evaluating port allocation > methods. Clean up that paragraph. [PTT] This is stateless allocation with embedded IPv4 addresses, so yes, when the IPv4 address changes, so does the IPv6 address. > > It has been learned from subscribers' > behaviors that the average number of sessions consumed by one > user's device is around 200 to 300 ports. Several devices may > appear behind a CPE. Administrators may configure a range > with 1000 ports to each CPE in fixed networks. > Avoid the passive voice. Can you cite the 200-300 number? Is that true in > 2014, or for as long as this document is intended to be useful? Yes, > administators may configure 1000 ports. Or 1001. Or 999. Maybe what you > mean is: > 1000 ports per subscriber household will provide enough room for multiple > active users. Administrators should monitor usage to adjust this number if > users are being limited by this number, or if usage is so low that fewer > ports would be sufficient. [PTT] This comes from the China Mobile study. Here is the new text, replacing the existing paragraph from "It has been learned ..." onwards. NEW The China Mobile study mentioned earlier observed that the average number of sessions consumed by one user's device was around 200 to 300 ports. Several devices may appear behind a CPE. Based on this observation, 1000 ports per subscriber household will provide enough room for multiple active users. Administrators should monitor usage to adjust this number if users are being limited by this number, or if usage is so low that fewer ports would be sufficient. > > non-contiguous port range for the > sake of attack defense. > I think you explain this later in the document, but a reference to what you > mean here would help. [PTT] Modified text: The assigned ports can be in either a contiguous port range or a non-contiguous port range for the sake of defence against port-guessing attacks (see ). > A+P style [citation needed] > [PTT] RFC 6346. > 2.3.1 Use of the word "older" sounds perjorative. Do you mean to imply > that NAT64 is obsolete? Both in the title and text. [PTT] Changed to "other". > Stepping outside > the boundaries of NAT64 for the moment, DS-Lite [RFC6333 > ] refers to > the cautions in [RFC6269 ] but does > not specify any port allocation > method. > First, that's pretty informal language. Second, why point to DS-Lite > pointing to RFC6269; why not just point to RFC6269? [PTT] OK, changed "Stepping outside the boundaries" to "Looking beyond". The reason to point to DS-Lite is that it does not specify a port allocation method. That's the main point. > 2.3.2 Current Work on Stateless Transition Technologies > The proposals made in Section 3 > n-3> and Section 4 > n-4> do not apply > to the current work in progress because that work has gone in another > direction. That work includes: > Do we need to enumerate protocols that this work doesn't apply to? If so, > then I think this document is making normative references to those protocols > (since their port allocation methods could, potentially, change until they > are published), which will delay publication until lw4over6, MAP-T, MAP-E, > 4rd have all been published. Having said that, this may be a useful > comparison of possible methods, but I would try to limit it to that. [PTT] Left the summary in, though I don't feel strongly about it. > Sections 2.4.1 and 2.4.2 are excellent. > 2.4.3 s/alllocation/allocation [PTT] Ok > 3.1 US means U.S.? Americans have higher traffic profiles? [PTT] Apparently so, subject to the way CableLabs derived their numbers. > 3.2 Remove sentence "Here is how dynamic allocation of port-ranges would > work in greater detail. " [PTT] OK > 3.3 Section 11 of RFC6269 refers to fragmentation; you mean section 12. [PTT] Fixed Is > this section supposed to be a privacy considerations section? [PTT] Definitely not what we originally had in mind. A separate Privacy Considerations section as you suggest may be the way to go, but RFC 6269 really says it all already.. > Discoverability? I think in the era of Pervasive Surveillance, reference to > other IETF work is needed. Also, please refer to RFC6302. [PTT] Thanks for the 6302 reference. > I'm not sure, though, that the discussion of server port logging is > appropriate in a document about how to allocate ports in CGN. A mention of > it makes sense, but evaluating the capability of different web servers, with > a config guide, seems out of place. [PTT] Removed summary and appendix. > These "traceability" issues apply equally to all port allocation methods, > right? Maybe a Privacy Considerations section at the end. > I didn't review section 4, because I've reviewed it before. And I ran out > of time. > 5. Security Considerations needs a rewrite‹it completely ignores Section 4. [PTT] Section 4 is gone now, based on feedback from Toronto. > That's all I have on this round. > Lee > Thanks again. Tom From nobody Mon Sep 29 09:04:47 2014 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38E21A8822 for ; Mon, 29 Sep 2014 09:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBGgC-zYpdkE for ; Mon, 29 Sep 2014 09:04:44 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38BFA1A883D for ; Mon, 29 Sep 2014 09:04:43 -0700 (PDT) Received: by mail-ig0-f182.google.com with SMTP id hn18so3669035igb.3 for ; Mon, 29 Sep 2014 09:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=1r0ZhDdxOoZRU64twYnKkeaRRygqytIzAeoALdqcoCM=; b=iOSWp8XHSxnasKz7JZ8MdwJHVLU3RV2xsB0Isqwuc6xlOko7VClO83jG5qaO00iZ+t vGvysFsTvkK13ZviNFB3NJodXb39l+GNzBjaHm7X1D2k9I6bz636Idv7fppamSTh3SEy PO1u96EoskFhcqrzTOhMsnl/cnaKvLye2PmW1JbkXxgXsqo76b8mp2t0keeuubR1qTt8 1rcgABJxUjzpnw9ha7qOk8U6RTTnTqi1KE929eC3RQzlB67mChUhT8GXYpFMikXzRFNY 3vDdGNm805VxkdoRiNe80oWQ9uflWk1mS8J0lPdZrSNAFxv3bVtlh4VLIEBGRVzPYOjd lm7g== X-Received: by 10.42.224.65 with SMTP id in1mr48581300icb.21.1412006682590; Mon, 29 Sep 2014 09:04:42 -0700 (PDT) Received: from [192.168.0.103] (dsl-173-206-104-235.tor.primus.ca. [173.206.104.235]) by mx.google.com with ESMTPSA id z2sm10684763igl.16.2014.09.29.09.04.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Sep 2014 09:04:42 -0700 (PDT) Message-ID: <54298319.7010605@gmail.com> Date: Mon, 29 Sep 2014 12:04:41 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "sunset4@ietf.org" References: <20140929155531.9911.46197.idtracker@ietfa.amsl.com> In-Reply-To: <20140929155531.9911.46197.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140929155531.9911.46197.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sunset4/d6V1MaRSQlaz6uBRsBO5_olbR7w Subject: [sunset4] Fwd: New Version Notification for draft-chen-sunset4-cgn-port-allocation-05.txt X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 16:04:45 -0000 Draft has been posted. Detailed changes as described in the response to Lee Howard's review, plus deletion of the section on deterministic CGN as agreed in Toronto. Tom Taylor -------- Original Message -------- Subject: New Version Notification for draft-chen-sunset4-cgn-port-allocation-05.txt Date: Mon, 29 Sep 2014 08:55:31 -0700 From: internet-drafts@ietf.org To: Tom Taylor , Weibo Li , James Huang , Gang Chen , Weibo Li , Tina Tsou , Jing Huang , Tina Tsou , Tom Taylor , Gang Chen A new version of I-D, draft-chen-sunset4-cgn-port-allocation-05.txt has been successfully submitted by Tom Taylor and posted to the IETF repository. Name: draft-chen-sunset4-cgn-port-allocation Revision: 05 Title: Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses Document date: 2014-09-29 Group: Individual Submission Pages: 19 URL: http://www.ietf.org/internet-drafts/draft-chen-sunset4-cgn-port-allocation-05.txt Status: https://datatracker.ietf.org/doc/draft-chen-sunset4-cgn-port-allocation/ Htmlized: http://tools.ietf.org/html/draft-chen-sunset4-cgn-port-allocation-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-chen-sunset4-cgn-port-allocation-05 Abstract: This document enumerates methods of port assignment in Carrier Grade NATs (CGNs), focused particularly on NAT64 environments. A theoretical framework of different NAT port allocation methods is described. The memo is intended to clarify and focus the port allocation discussion and propose an integrated view of the considerations for selection of the port allocation mechanism in a given deployment. 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. The IETF Secretariat From nobody Tue Sep 30 08:24:47 2014 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB3A1A1A15 for ; Tue, 30 Sep 2014 08:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNyfMCK8-x7M for ; Tue, 30 Sep 2014 08:24:41 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 334CE1A1A5C for ; Tue, 30 Sep 2014 08:24:40 -0700 (PDT) Received: from h226.viagenie.ca (h226.viagenie.ca [206.123.31.226]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DEC4C4039A for ; Tue, 30 Sep 2014 11:24:37 -0400 (EDT) From: Marc Blanchet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 30 Sep 2014 11:24:36 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sunset4/avvDrVNYCSyv_qKk7-gc3isX_fE Subject: [sunset4] sunset4 not meeting in Honolulu X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 15:24:42 -0000 Hello, co-chairs have not seen trafic on the mailing list nor updates to the = documents, based on feedback from the previous meeting. So sunset4 will = not meet in Honolulu. We shall see updates to documents to require = meeting time. However, if documents are updated, we could always move = the documents forward or hold virtual interim meetings. Moreover, if people are interested in being editors of documents, please = contact the co-chairs offline (sunset4-chairs@tools.ietf.org). Regards, Marc&Wes= From nobody Tue Sep 30 08:26:42 2014 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11701A19F1 for ; Tue, 30 Sep 2014 06:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYRGHcCZZ3GS for ; Tue, 30 Sep 2014 06:14:55 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE7E1A19EE for ; Tue, 30 Sep 2014 06:14:54 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,626,1406606400"; d="scan'208";a="524200332" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 30 Sep 2014 09:10:56 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 30 Sep 2014 09:14:54 -0400 From: "Howard, Lee" To: "sunset4@ietf.org" Date: Tue, 30 Sep 2014 09:14:51 -0400 Thread-Topic: addition to gap-analysis Thread-Index: Ac/csIWko7n0csyCT4GCPF3PnVpfBw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sunset4/8kboj9KK38LB6aXakGsbeXZlVtU X-Mailman-Approved-At: Tue, 30 Sep 2014 08:26:34 -0700 Subject: [sunset4] addition to gap-analysis X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 13:14:56 -0000 I've been revising draft-george-ipv6-required based on notes from the last IETF meeting and the mailing list. As discussed, I've removed the recommendation to review the previous gap analysis efforts, and as we discussed, that work ought to be included in the sunset4 gap analysis document. Specifically, I think it should be added to section 2 of the gap analysis: 2. Related Work [RFC3789], [RFC3790],[RFC3791], [RFC3792], [RFC3793], [RFC3794], [RFC3795] and [RFC3796] contain surveys of IETF protocols with their IPv4 dependencies. I would add, from draft-george: Additionally, although reviews in RFC's 3789 through RFC3796 ensured that IETF standards then in use could support IPv6, no IETF-wide effort has been undertaken to ensure that the issues identified in those drafts are all addressed, nor to ensure that standards written after RFC3100 (where the previous review efforts stopped) function properly on IPv6-only networks. The IETF needs to ensure that existing standards and protocols have been actively reviewed, and any parity gaps either identified so that they can be fixed, or documented as unnecessary to address because it is unused or superseded by other features. First, the IETF must review RFCs 3789-3796 to ensure that any gaps in specifications identified in these documents and still in active use have been updated as necessary to enable operation in IPv6-only environments (or if no longer in use, are declared historic). Second, the IETF must review documents written after the existing review stopped (according to RFC 3790, this review stopped with approximately RFC 3100) to identify specifications where IPv6-only operation is not possible, and update them as necessary and appropriate, or document why an identified gap is not an issue i.e. not necessary for functional parity with IPv4. This document does not recommend excluding Informational and BCP RFCs as the previous effort did, due to changes in the way that these documents are used and their relative importance in the RFC Series. Instead, any documents that are still active (i.e. not declared historic or obsolete) and the product of IETF consensus (i.e. not a product of the ISE Series) should be included. In addition, the reviews undertaken by RFC 3789-96 were looking for "IPv4 dependency" or "usage of IPv4 addresses in standards". This document recommends a slightly more specific set of criteria for review: review should include consideration of whether the specification can operate in an environment without IPv4. Reviews should include guidance on the use of 32-bit identifiers that are commonly populated by IPv4 addresses. Reviews should include consideration of protocols on which specifications depend or interact, to identify indirect dependencies on IPv4. Finally, reviews should consider how to migrate from an IPv4 environment to an IPv6 environment. I have left out discussion of how to do this work, since it was unclear whether consensus existed to include it in the document. The words are still immortalized in http://tools.ietf.org/html/draft-george-ipv6-support-02 if we need them. I'm happy to help with support in this document, as needed. Lee This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se 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 dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout.