From dthaler@microsoft.com Fri Oct 4 17:43:32 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F4A21F9DFA; Fri, 4 Oct 2013 17:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.531 X-Spam-Level: X-Spam-Status: No, score=-103.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aL7Tbvo9ZpN2; Fri, 4 Oct 2013 17:43:27 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id ADBC521F9D99; Fri, 4 Oct 2013 17:43:22 -0700 (PDT) Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) with Microsoft SMTP Server (TLS) id 15.0.785.10; Sat, 5 Oct 2013 00:43:20 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.62]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.62]) with mapi id 15.00.0785.001; Sat, 5 Oct 2013 00:43:20 +0000 From: Dave Thaler To: "softwires@ietf.org" Thread-Topic: Early MIB doctor review of draft-ietf-softwire-dslite-mib-03 Thread-Index: Ac7BYkvSQL3SrrVPTZSNhm48v5yxIg== Date: Sat, 5 Oct 2013 00:43:19 +0000 Message-ID: <45e71b4ab8434c19bfae92f68572ba75@BY2PR03MB269.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ed43::2] x-forefront-prvs: 0990C54589 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(243025003)(74662001)(19580395003)(74316001)(49866001)(4396001)(83322001)(47736001)(76796001)(31966008)(81342001)(76786001)(50986001)(47446002)(74502001)(85306002)(76176001)(15975445006)(74706001)(56816003)(76576001)(77096001)(83072001)(54316002)(80976001)(74876001)(54356001)(81686001)(81816001)(80022001)(33646001)(53806001)(76482001)(77982001)(19300405004)(79102001)(74366001)(46102001)(69226001)(47976001)(65816001)(81542001)(15202345003)(56776001)(16236675002)(63696002)(59766001)(51856001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB269; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ed43::2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_45e71b4ab8434c19bfae92f68572ba75BY2PR03MB269namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: Benoit Claise , "behave@ietf.org" Subject: [Softwires] Early MIB doctor review of draft-ietf-softwire-dslite-mib-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 00:43:32 -0000 --_000_45e71b4ab8434c19bfae92f68572ba75BY2PR03MB269namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVub2l0IGFza2VkIG1lIHRvIGRvIGFuIGVhcmx5IE1JQiBkb2N0b3IgcmV2aWV3IG9mIHRoaXMg ZG9jdW1lbnQuICBNeQ0KZnVsbCBjb21tZW50cyBhcmUgaW4gdGhlIG1hcmtlZCB1cCBjb3B5IGF0 DQpodHRwOi8vcmVzZWFyY2gubWljcm9zb2Z0LmNvbS9+ZHRoYWxlci9kcmFmdC1pZXRmLXNvZnR3 aXJlLWRzbGl0ZS1taWItMDMucGRmDQoodGhlcmXigJlzIGFsc28gYSAuZG9jeCB2ZXJzaW9uIGlm IHlvdSByZXBsYWNlIHRoZSAucGRmIGV4dGVuc2lvbiB3aXRoIC5kb2N4KQ0KDQpJ4oCZdmUgYWxz byBjY+KAmWVkIHRoZSBiZWhhdmUgV0cgb24gdGhpcyBtYWlsIHNpbmNlIG1hbnkgb2YgbXkgY29t bWVudHMgY29uY2Vybg0KdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGRyYWZ0LWlldGYtYmVoYXZl LW5hdC1taWIgIGFuZCB0aGUgdHJhbnNsYXRpb24gcGFydHMgb2YNCnRoaXMgZHJhZnQuDQoNCkEg c2hvcnQgc3VtbWFyeSBvZiB0aGUgaGlnaCBsZXZlbCBpc3N1ZXMgaW4gbXkgcmV2aWV3IGlzOg0K DQoxKSAgICAgIFRoZSBkb2MgaXMgbm90IGFsaWduZWQgd2l0aCBkcmFmdC1pZXRmLWJlaGF2ZS1u YXQtbWliLiAgSXQgY3VycmVudGx5IGNvbnRpbnVlcw0KDQpzb21lIHByYWN0aWNlcyB0aGF0IHdl 4oCZcmUgdHJ5aW5nIHRvIGRlcHJlY2F0ZSBhcyBkaXNjdXNzZWQgaW4gc2VjdGlvbiAzLjEgb2YN Cg0KZHJhZnQtaWV0Zi1iZWhhdmUtbmF0LW1pYi4NCg0KMikgICAgICBCb2lsZXJwbGF0ZSBuZWVk cyB0byBiZSB1cGRhdGVkIHRvIG1hdGNoIGxhdGVzdCBNSUIgYm9pbGVycGxhdGUgKHNlZSBpbmxp bmUNCg0KY29tbWVudHMgZm9yIHBvaW50ZXJzKS4NCg0KMykgICAgICBBbnkgSW5ldFBvcnROdW1i ZXIgb2JqZWN0IGFsbG93aW5nIDAgbmVlZHMgdG8gZXhwbGFpbiB3aGF0IDAgbWVhbnMgaW4gdGhh dA0KDQpvYmplY3QsIGFzIHJlcXVpcmVkIGJ5IFJGQyA0MDAxLg0KDQo0KSAgICAgIERyYWZ0IGN1 cnJlbnRseSByZXF1aXJlcyB3cml0ZSBzdXBwb3J0IGluIGFsbCBpbXBsZW1lbnRhdGlvbnMuICBS ZWNvbW1lbmQNCg0KaGF2aW5nIGEgcmVhZC1vbmx5IGNvbXBsaWFuY2Ugc3RhdGVtZW50IHNpbmNl IG5vd2FkYXlzIG1hbnkgZm9sa3MgZG9u4oCZdA0KDQp3YW50IHdyaXRlIHN1cHBvcnQgdmlhIE1J QnMuDQoNCg0KLURhdmUNCg0K --_000_45e71b4ab8434c19bfae92f68572ba75BY2PR03MB269namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5n ZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAy IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFu b3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xp c3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eToz NDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206 MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglj b2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsN Cgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMTQ4NTIwOTU7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi05NTU3MTQyNDAgNjc2OTg3MDUgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGww OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4w cHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwx DQoJe21zby1saXN0LWlkOjE4MjM4MTQxNDc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOi0zMjI0MTQ3NTQgLTEzMjE0MTk3NjIgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7 fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpA bGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2Nv bG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZW5vaXQgYXNrZWQgbWUgdG8gZG8gYW4g ZWFybHkgTUlCIGRvY3RvciByZXZpZXcgb2YgdGhpcyBkb2N1bWVudC4mbmJzcDsgTXk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ZnVsbCBjb21tZW50cyBhcmUgaW4gdGhlIG1hcmtlZCB1 cCBjb3B5IGF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vcmVzZWFyY2gubWljcm9z b2Z0LmNvbS9+ZHRoYWxlci9kcmFmdC1pZXRmLXNvZnR3aXJlLWRzbGl0ZS1taWItMDMucGRmIj5o dHRwOi8vcmVzZWFyY2gubWljcm9zb2Z0LmNvbS9+ZHRoYWxlci9kcmFmdC1pZXRmLXNvZnR3aXJl LWRzbGl0ZS1taWItMDMucGRmPC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPih0aGVyZeKAmXMg YWxzbyBhIC5kb2N4IHZlcnNpb24gaWYgeW91IHJlcGxhY2UgdGhlIC5wZGYgZXh0ZW5zaW9uIHdp dGggLmRvY3gpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5J4oCZdmUgYWxzbyBjY+KAmWVkIHRoZSBiZWhhdmUgV0cgb24g dGhpcyBtYWlsIHNpbmNlIG1hbnkgb2YgbXkgY29tbWVudHMgY29uY2VybjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj50aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gZHJhZnQtaWV0Zi1iZWhh dmUtbmF0LW1pYiAmbmJzcDthbmQgdGhlIHRyYW5zbGF0aW9uIHBhcnRzIG9mPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPnRoaXMgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BIHNob3J0IHN1bW1hcnkg b2YgdGhlIGhpZ2ggbGV2ZWwgaXNzdWVzIGluIG15IHJldmlldyBpczo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPjEpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhlIGRvYyBpcyBub3QgYWxpZ25lZCB3aXRoIGRyYWZ0LWlldGYtYmVoYXZlLW5hdC1taWIuJm5i c3A7IEl0IGN1cnJlbnRseSBjb250aW51ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPnNvbWUgcHJhY3RpY2VzIHRoYXQgd2XigJlyZSB0cnlpbmcgdG8gZGVwcmVjYXRlIGFz IGRpc2N1c3NlZCBpbiBzZWN0aW9uIDMuMSBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+ZHJhZnQtaWV0Zi1iZWhhdmUtbmF0LW1pYi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPjIpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Qm9pbGVy cGxhdGUgbmVlZHMgdG8gYmUgdXBkYXRlZCB0byBtYXRjaCBsYXRlc3QgTUlCIGJvaWxlcnBsYXRl IChzZWUgaW5saW5lPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5jb21tZW50 cyBmb3IgcG9pbnRlcnMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBs Zm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Myk8c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbnkgSW5ldFBvcnROdW1iZXIgb2JqZWN0 IGFsbG93aW5nIDAgbmVlZHMgdG8gZXhwbGFpbiB3aGF0IDAgbWVhbnMgaW4gdGhhdDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+b2JqZWN0LCBhcyByZXF1aXJlZCBieSBSRkMg NDAwMS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjQpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+RHJhZnQgY3VycmVudGx5IHJlcXVpcmVzIHdyaXRlIHN1cHBv cnQgaW4gYWxsIGltcGxlbWVudGF0aW9ucy4mbmJzcDsgUmVjb21tZW5kPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5oYXZpbmcgYSByZWFkLW9ubHkgY29tcGxpYW5jZSBzdGF0 ZW1lbnQgc2luY2Ugbm93YWRheXMgbWFueSBmb2xrcyBkb27igJl0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj53YW50IHdyaXRlIHN1cHBvcnQgdmlhIE1JQnMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+LURhdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_45e71b4ab8434c19bfae92f68572ba75BY2PR03MB269namprd03pro_-- From internet-drafts@ietf.org Mon Oct 7 04:59:31 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F5521E8084; Mon, 7 Oct 2013 04:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.042, 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 V6Ee60m4hlAF; Mon, 7 Oct 2013 04:59:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDC221E8186; Mon, 7 Oct 2013 04:59:30 -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.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131007115930.16131.36923.idtracker@ietfa.amsl.com> Date: Mon, 07 Oct 2013 04:59:30 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-multicast-prefix-option-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 11:59:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : DHCPv6 Option for IPv4-Embedded Multicast and Unicast IP= v6 Prefixes Author(s) : Mohamed Boucadair Jacni Qin Tina Tsou Xiaohong Deng Filename : draft-ietf-softwire-multicast-prefix-option-05.txt Pages : 7 Date : 2013-10-07 Abstract: This document defines Dynamic Host Configuration Protocol version 6 (DHCPv6) Option for multicast transition solutions, aiming to convey the IPv6 prefixes to be used to build unicast and multicast IPv4-embedded IPv6 addresses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-multicast-prefix-option There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix-option-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-multicast-prefix-opt= ion-05 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 internet-drafts@ietf.org Mon Oct 7 05:04:55 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FA521F9DFA; Mon, 7 Oct 2013 05:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.042, 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 8T31VHEAYHTP; Mon, 7 Oct 2013 05:04:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B3621F9F21; Mon, 7 Oct 2013 05:04:54 -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.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131007120454.16131.19299.idtracker@ietfa.amsl.com> Date: Mon, 07 Oct 2013 05:04:54 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 12:04:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Delivery of IPv4 Multicast Services to IPv4 Clients over= an IPv6 Multicast Network Author(s) : Jacni Qin Mohamed Boucadair Christian Jacquenet Yiu L. Lee Qian Wang Filename : draft-ietf-softwire-dslite-multicast-06.txt Pages : 19 Date : 2013-10-07 Abstract: This document specifies a solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses the IPv6 multicast distribution tree to deliver IPv4 multicast traffic. The solution is particularly useful for the delivery of multicast service offerings to DS-Lite serviced customers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-dslite-multicast-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-dslite-multicast-06 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 internet-drafts@ietf.org Mon Oct 7 22:38:16 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D923511E818A; Mon, 7 Oct 2013 22:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.035, 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 pIXNYMdISmuE; Mon, 7 Oct 2013 22:38:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86DAA11E818C; Mon, 7 Oct 2013 22:38:15 -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.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131008053815.25649.4567.idtracker@ietfa.amsl.com> Date: Mon, 07 Oct 2013 22:38:15 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-4rd-07.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 05:38:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : IPv4 Residual Deployment via IPv6 - a Stateless Solution= (4rd) Author(s) : Remi Despres Sheng Jiang Reinaldo Penno Yiu Lee Gang Chen Maoke Chen Filename : draft-ietf-softwire-4rd-07.txt Pages : 38 Date : 2013-10-07 Abstract: The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment possible via IPv6 networks without maintaining for this per-customer states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of 6rd). To cope with the IPv4 address shortage, customer sites can be assigned shared public IPv4 addresses with restricted port sets. 4rd can also support the scenarios that customer sites are assigned full public IPv4 addresses or a set of public IPv4 addresses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-4rd-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-4rd-07 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 jiangsheng@huawei.com Wed Oct 9 03:01:47 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB1F21E8122; Wed, 9 Oct 2013 03:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4uzyQpGo0R9; Wed, 9 Oct 2013 03:01:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 12BAD21E8135; Wed, 9 Oct 2013 03:01:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWQ01892; Wed, 09 Oct 2013 10:01:23 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 11:00:50 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 11:01:13 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.191]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0146.000; Wed, 9 Oct 2013 18:01:09 +0800 From: Sheng Jiang To: Dave Thaler , "softwires@ietf.org" Thread-Topic: [Softwires] Early MIB doctor review of draft-ietf-softwire-dslite-mib-03 Thread-Index: Ac7BYkvSQL3SrrVPTZSNhm48v5yxIgDc8gcg Date: Wed, 9 Oct 2013 10:01:08 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AD46676@nkgeml512-mbx.china.huawei.com> References: <45e71b4ab8434c19bfae92f68572ba75@BY2PR03MB269.namprd03.prod.outlook.com> In-Reply-To: <45e71b4ab8434c19bfae92f68572ba75@BY2PR03MB269.namprd03.prod.outlook.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B923AD46676nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Benoit Claise , "behave@ietf.org" Subject: Re: [Softwires] Early MIB doctor review of draft-ietf-softwire-dslite-mib-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 10:01:47 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B923AD46676nkgeml512mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIERhdmUsDQoNClRoYW5rcyBzbyBtdWNoIGZvciB5b3VyIHJldmlldy4gV2UgYXJlIHdvcmtp bmcgb24geW91ciBjb21tZW50cyBhbmQgd2lsbCBtYWtlIGFuIHVwZGF0ZSB2ZXJzaW9uIGluIG9u ZSBvciB0d28gd2VlayB0aW1lLiBXaGVuIHRoZSBuZXcgdmVyc2lvbiByZWFkeSwgd2Ugd2lsbCB3 cml0ZSB0byB5b3UgcHJpdmF0ZWx5IGZvciBjb25maXJtYXRpb24gd2hldGhlciB5b3VyIGNvbW1l bnRzIGhhdmUgYmVlbiBwcm9wZXJseSBhZGRyZXNzZWQuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hl bmcNCg0KRnJvbTogc29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzb2Z0d2lyZXMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhdmUgVGhhbGVyDQpTZW50OiBTYXR1cmRh eSwgT2N0b2JlciAwNSwgMjAxMyA4OjQzIEFNDQpUbzogc29mdHdpcmVzQGlldGYub3JnDQpDYzog QmVub2l0IENsYWlzZTsgYmVoYXZlQGlldGYub3JnDQpTdWJqZWN0OiBbU29mdHdpcmVzXSBFYXJs eSBNSUIgZG9jdG9yIHJldmlldyBvZiBkcmFmdC1pZXRmLXNvZnR3aXJlLWRzbGl0ZS1taWItMDMN Cg0KQmVub2l0IGFza2VkIG1lIHRvIGRvIGFuIGVhcmx5IE1JQiBkb2N0b3IgcmV2aWV3IG9mIHRo aXMgZG9jdW1lbnQuICBNeQ0KZnVsbCBjb21tZW50cyBhcmUgaW4gdGhlIG1hcmtlZCB1cCBjb3B5 IGF0DQpodHRwOi8vcmVzZWFyY2gubWljcm9zb2Z0LmNvbS9+ZHRoYWxlci9kcmFmdC1pZXRmLXNv ZnR3aXJlLWRzbGl0ZS1taWItMDMucGRmDQoodGhlcmXigJlzIGFsc28gYSAuZG9jeCB2ZXJzaW9u IGlmIHlvdSByZXBsYWNlIHRoZSAucGRmIGV4dGVuc2lvbiB3aXRoIC5kb2N4KQ0KDQpJ4oCZdmUg YWxzbyBjY+KAmWVkIHRoZSBiZWhhdmUgV0cgb24gdGhpcyBtYWlsIHNpbmNlIG1hbnkgb2YgbXkg Y29tbWVudHMgY29uY2Vybg0KdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGRyYWZ0LWlldGYtYmVo YXZlLW5hdC1taWIgIGFuZCB0aGUgdHJhbnNsYXRpb24gcGFydHMgb2YNCnRoaXMgZHJhZnQuDQoN CkEgc2hvcnQgc3VtbWFyeSBvZiB0aGUgaGlnaCBsZXZlbCBpc3N1ZXMgaW4gbXkgcmV2aWV3IGlz Og0KDQoxKSAgICAgIFRoZSBkb2MgaXMgbm90IGFsaWduZWQgd2l0aCBkcmFmdC1pZXRmLWJlaGF2 ZS1uYXQtbWliLiAgSXQgY3VycmVudGx5IGNvbnRpbnVlcw0KDQpzb21lIHByYWN0aWNlcyB0aGF0 IHdl4oCZcmUgdHJ5aW5nIHRvIGRlcHJlY2F0ZSBhcyBkaXNjdXNzZWQgaW4gc2VjdGlvbiAzLjEg b2YNCg0KZHJhZnQtaWV0Zi1iZWhhdmUtbmF0LW1pYi4NCg0KMikgICAgICBCb2lsZXJwbGF0ZSBu ZWVkcyB0byBiZSB1cGRhdGVkIHRvIG1hdGNoIGxhdGVzdCBNSUIgYm9pbGVycGxhdGUgKHNlZSBp bmxpbmUNCg0KY29tbWVudHMgZm9yIHBvaW50ZXJzKS4NCg0KMykgICAgICBBbnkgSW5ldFBvcnRO dW1iZXIgb2JqZWN0IGFsbG93aW5nIDAgbmVlZHMgdG8gZXhwbGFpbiB3aGF0IDAgbWVhbnMgaW4g dGhhdA0KDQpvYmplY3QsIGFzIHJlcXVpcmVkIGJ5IFJGQyA0MDAxLg0KDQo0KSAgICAgIERyYWZ0 IGN1cnJlbnRseSByZXF1aXJlcyB3cml0ZSBzdXBwb3J0IGluIGFsbCBpbXBsZW1lbnRhdGlvbnMu ICBSZWNvbW1lbmQNCg0KaGF2aW5nIGEgcmVhZC1vbmx5IGNvbXBsaWFuY2Ugc3RhdGVtZW50IHNp bmNlIG5vd2FkYXlzIG1hbnkgZm9sa3MgZG9u4oCZdA0KDQp3YW50IHdyaXRlIHN1cHBvcnQgdmlh IE1JQnMuDQoNCg0KLURhdmUNCg0K --_000_5D36713D8A4E7348A7E10DF7437A4B923AD46676nkgeml512mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovk vZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L 5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9y OmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIENo YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KcC5IVE1MUHJlZm9ybWF0dGVkLCBs aS5IVE1MUHJlZm9ybWF0dGVkLCBkaXYuSFRNTFByZWZvcm1hdHRlZA0KCXttc28tc3R5bGUtbmFt ZToiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29s b3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRl IiBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSwgRGF2ZSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIHNvIG11Y2ggZm9yIHlvdXIgcmV2aWV3LiBX ZSBhcmUgd29ya2luZyBvbiB5b3VyIGNvbW1lbnRzIGFuZCB3aWxsIG1ha2UgYW4gdXBkYXRlIHZl cnNpb24gaW4gb25lIG9yIHR3byB3ZWVrIHRpbWUuIFdoZW4gdGhlIG5ldyB2ZXJzaW9uIHJlYWR5 LA0KIHdlIHdpbGwgd3JpdGUgdG8geW91IHByaXZhdGVseSBmb3IgY29uZmlybWF0aW9uIHdoZXRo ZXIgeW91ciBjb21tZW50cyBoYXZlIGJlZW4gcHJvcGVybHkgYWRkcmVzc2VkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlNoZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3 aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZw0K IFttYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+ RGF2ZSBUaGFsZXI8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIE9jdG9iZXIgMDUsIDIwMTMg ODo0MyBBTTxicj4NCjxiPlRvOjwvYj4gc29mdHdpcmVzQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9i PiBCZW5vaXQgQ2xhaXNlOyBiZWhhdmVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1Nv ZnR3aXJlc10gRWFybHkgTUlCIGRvY3RvciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1zb2Z0d2lyZS1k c2xpdGUtbWliLTAzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlbm9pdCBhc2tlZCBtZSB0byBkbyBhbiBlYXJs eSBNSUIgZG9jdG9yIHJldmlldyBvZiB0aGlzIGRvY3VtZW50LiZuYnNwOyBNeTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ZnVsbCBjb21tZW50cyBhcmUgaW4gdGhl IG1hcmtlZCB1cCBjb3B5IGF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0i aHR0cDovL3Jlc2VhcmNoLm1pY3Jvc29mdC5jb20vfmR0aGFsZXIvZHJhZnQtaWV0Zi1zb2Z0d2ly ZS1kc2xpdGUtbWliLTAzLnBkZiI+aHR0cDovL3Jlc2VhcmNoLm1pY3Jvc29mdC5jb20vfmR0aGFs ZXIvZHJhZnQtaWV0Zi1zb2Z0d2lyZS1kc2xpdGUtbWliLTAzLnBkZjwvYT48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPih0aGVyZeKAmXMgYWxzbyBhIC5k b2N4IHZlcnNpb24gaWYgeW91IHJlcGxhY2UgdGhlIC5wZGYgZXh0ZW5zaW9uIHdpdGggLmRvY3gp PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJl2ZSBhbHNvIGNj4oCZZWQg dGhlIGJlaGF2ZSBXRyBvbiB0aGlzIG1haWwgc2luY2UgbWFueSBvZiBteSBjb21tZW50cyBjb25j ZXJuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj50aGUgcmVsYXRp b25zaGlwIGJldHdlZW4gZHJhZnQtaWV0Zi1iZWhhdmUtbmF0LW1pYiAmbmJzcDthbmQgdGhlIHRy YW5zbGF0aW9uIHBhcnRzIG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj50aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BIHNo b3J0IHN1bW1hcnkgb2YgdGhlIGhpZ2ggbGV2ZWwgaXNzdWVzIGluIG15IHJldmlldyBpczo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+MSk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGUgZG9jIGlzIG5vdCBhbGlnbmVkIHdpdGggZHJhZnQtaWV0Zi1iZWhhdmUtbmF0 LW1pYi4mbmJzcDsgSXQgY3VycmVudGx5IGNvbnRpbnVlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnNvbWUgcHJhY3RpY2VzIHRoYXQgd2XigJlyZSB0 cnlpbmcgdG8gZGVwcmVjYXRlIGFzIGRpc2N1c3NlZCBpbiBzZWN0aW9uIDMuMSBvZjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmRyYWZ0LWlldGYtYmVo YXZlLW5hdC1taWIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjIpPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Qm9pbGVycGxhdGUgbmVlZHMgdG8gYmUgdXBkYXRlZCB0 byBtYXRjaCBsYXRlc3QgTUlCIGJvaWxlcnBsYXRlIChzZWUgaW5saW5lPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Y29tbWVudHMgZm9yIHBvaW50ZXJz KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9InRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Myk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5BbnkgSW5ldFBvcnROdW1iZXIgb2JqZWN0IGFsbG93aW5nIDAgbmVlZHMg dG8gZXhwbGFpbiB3aGF0IDAgbWVhbnMgaW4gdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPm9iamVjdCwgYXMgcmVxdWlyZWQgYnkgUkZDIDQwMDEu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjQpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+RHJhZnQgY3VycmVudGx5IHJlcXVpcmVzIHdyaXRlIHN1cHBvcnQgaW4gYWxs IGltcGxlbWVudGF0aW9ucy4mbmJzcDsgUmVjb21tZW5kPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+aGF2aW5nIGEgcmVhZC1vbmx5IGNvbXBsaWFuY2Ug c3RhdGVtZW50IHNpbmNlIG5vd2FkYXlzIG1hbnkgZm9sa3MgZG9u4oCZdDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPndhbnQgd3JpdGUgc3VwcG9ydCB2 aWEgTUlCcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1EYXZl PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5D36713D8A4E7348A7E10DF7437A4B923AD46676nkgeml512mbxchi_-- From dthaler@microsoft.com Fri Oct 11 14:34:58 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7192321F9C78 for ; Fri, 11 Oct 2013 14:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.552 X-Spam-Level: X-Spam-Status: No, score=-103.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hg0vYThwyUIA for ; Fri, 11 Oct 2013 14:34:53 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0154.outbound.protection.outlook.com [207.46.163.154]) by ietfa.amsl.com (Postfix) with ESMTP id A0BA721E808F for ; Fri, 11 Oct 2013 14:34:47 -0700 (PDT) Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) with Microsoft SMTP Server (TLS) id 15.0.800.7; Fri, 11 Oct 2013 21:34:44 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.163]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.163]) with mapi id 15.00.0800.005; Fri, 11 Oct 2013 21:34:44 +0000 From: Dave Thaler To: "softwires@ietf.org" Thread-Topic: Early MIB doctor review of draft-ietf-softwire-mesh-mib-04 Thread-Index: Ac7GyHlqmshPI0hBRYqjzR8jEgH0qw== Date: Fri, 11 Oct 2013 21:34:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::3] x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(243025003)(74316001)(76576001)(56816003)(77096001)(81816001)(76176001)(76796001)(76786001)(54356001)(53806001)(81542001)(80022001)(65816001)(19300405004)(51856001)(46102001)(85306002)(16236675002)(33646001)(69226001)(63696002)(80976001)(81342001)(74662001)(74502001)(47976001)(50986001)(47736001)(49866001)(47446002)(76482001)(83322001)(31966008)(81686001)(19580395003)(15202345003)(54316002)(56776001)(79102001)(4396001)(59766001)(77982001)(74876001)(15975445006)(74366001)(74706001)(83072001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB270; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::3; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_ade96465bb8f4eaf8474dbabc07a76e7BY2PR03MB269namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Benoit Claise Subject: [Softwires] Early MIB doctor review of draft-ietf-softwire-mesh-mib-04 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 21:34:59 -0000 --_000_ade96465bb8f4eaf8474dbabc07a76e7BY2PR03MB269namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVub2l0IGFza2VkIG1lIHRvIGRvIGFuIGVhcmx5IE1JQiBkb2N0b3IgcmV2aWV3IG9mIHRoaXMg ZG9jdW1lbnQuICBNeQ0KDQpmdWxsIGNvbW1lbnRzIGFyZSBpbiB0aGUgbWFya2VkIHVwIGNvcHkg YXQNCg0KaHR0cDovL3Jlc2VhcmNoLm1pY3Jvc29mdC5jb20vfmR0aGFsZXIvZHJhZnQtaWV0Zi1z b2Z0d2lyZS1tZXNoLW1pYi0wNC5wZGYNCg0KKHRoZXJl4oCZcyBhbHNvIGEgLmRvY3ggdmVyc2lv biBpZiB5b3UgcmVwbGFjZSB0aGUgLnBkZiBleHRlbnNpb24gd2l0aCAuZG9jeCkNCg0KDQoNClRo ZSBkb2MgaXMgaW4gYSBtdWNoIGJldHRlciBzdGF0ZSB0aGFuIGRyYWZ0LWlldGYtc29mdHdpcmUt ZHNsaXRlLW1pYiBpcywgYW5kDQoNCnNvIHRoaXMgd2FzIGZhaXJseSBlYXN5IHRvIHJldmlldyAo YW5kIG15IHRoYW5rcyB0byB0aGUgYXV0aG9ycyBmb3IgdGhhdCkuDQoNCk5ldmVydGhlbGVzcywg SSBkaWQgZmluZCBhIGZldyBpc3N1ZXMsIGEgc2hvcnQgc3VtbWFyeSBvZiB3aGljaCBpczoNCg0K MSkgICAgICBJdCBkb2VzIG5vdCB5ZXQgbWVldCBhbGwgdGhlIHJlcXVpcmVtZW50cyBmb3IgTUlC cyBpbiBSRkMgNDE4MSwgbW9zdGx5IGFyb3VuZA0KDQptaXNzaW5nIGJvaWxlcnBsYXRlDQoNCjIp ICAgICAgVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gbmVlZHMgKHBlciBSRkMg NDE4MSkgYSBicmllZiBkaXNjdXNzaW9uIG9mDQoNCndoYXQgb2JqZWN0cywgaWYgYW55LCBtaWdo dCBiZSBjb25zaWRlcmVkIHNlbnNpdGl2ZS4gIEZvciBleGFtcGxlLCBvbmUgbWlnaHQNCg0KYXJn dWUgdGhlIHN3bUVuY2Fwc1RhYmxlIG1pZ2h0IHJldmVhbCB0aGluZ3MgYWJvdXQgdGhlIGludGVy bmFsIG5ldHdvcmsNCg0KdG9wb2xvZ3kuDQoNCjMpICAgICAgdGhlIHNtaWxpbnQgTUlCIGNoZWNr ZXIgcmVwb3J0cyBzZXZlcmFsIGVycm9ycy4gIEnigJl2ZSBub3RlZCBpbiBteSBjb21tZW50cw0K DQpob3cgdG8gZml4IHRoZW0uICAoSSB1c2VkIGh0dHA6Ly93d3cuaWJyLmNzLnR1LWJzLmRlL2Jp bi9zbWl0b29scy5jZ2kpDQoNCg0KDQotRGF2ZQ0KDQoNCg== --_000_ade96465bb8f4eaf8474dbabc07a76e7BY2PR03MB269namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWlu VGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9 DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFy YWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWls U3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUt bmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlz dCBsMA0KCXttc28tbGlzdC1pZDoyMTQ4NTIwOTU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi05NTU3MTQyNDAgNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3 MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7 fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5k ZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0K QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxDQoJe21z by1saXN0LWlkOjEzNzk2MjgzMzU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjEyNDc2OTc5OTYgNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3 MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3Qg bDE6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBw dDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6 bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGlu O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5CZW5vaXQgYXNrZWQgbWUgdG8gZG8gYW4gZWFy bHkgTUlCIGRvY3RvciByZXZpZXcgb2YgdGhpcyBkb2N1bWVudC4mbmJzcDsgTXk8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmZ1bGwgY29tbWVudHMgYXJlIGluIHRoZSBt YXJrZWQgdXAgY29weSBhdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PGEgaHJlZj0iaHR0cDovL3Jlc2VhcmNoLm1pY3Jvc29mdC5jb20vfmR0aGFsZXIvZHJhZnQtaWV0 Zi1zb2Z0d2lyZS1tZXNoLW1pYi0wNC5wZGYiPmh0dHA6Ly9yZXNlYXJjaC5taWNyb3NvZnQuY29t L35kdGhhbGVyL2RyYWZ0LWlldGYtc29mdHdpcmUtbWVzaC1taWItMDQucGRmPC9hPg0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4odGhlcmXigJlzIGFsc28gYSAuZG9j eCB2ZXJzaW9uIGlmIHlvdSByZXBsYWNlIHRoZSAucGRmIGV4dGVuc2lvbiB3aXRoIC5kb2N4KTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgZG9jIGlzIGluIGEgbXVjaCBiZXR0ZXIg c3RhdGUgdGhhbiBkcmFmdC1pZXRmLXNvZnR3aXJlLWRzbGl0ZS1taWIgaXMsIGFuZDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+c28gdGhpcyB3YXMgZmFpcmx5IGVhc3kg dG8gcmV2aWV3IChhbmQgbXkgdGhhbmtzIHRvIHRoZSBhdXRob3JzIGZvciB0aGF0KS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk5ldmVydGhlbGVzcywgSSBkaWQgZmlu ZCBhIGZldyBpc3N1ZXMsIGEgc2hvcnQgc3VtbWFyeSBvZiB3aGljaCBpczo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+DQo8IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xKTxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5JdCBkb2VzIG5vdCB5ZXQgbWVldCBhbGwg dGhlIHJlcXVpcmVtZW50cyBmb3IgTUlCcyBpbiBSRkMgNDE4MSwgbW9zdGx5IGFyb3VuZDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPm1pc3NpbmcgYm9pbGVycGxhdGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlz dDpsMSBsZXZlbDEgbGZvMyI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj4yKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT5UaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBuZWVkcyAocGVy IFJGQyA0MTgxKSBhIGJyaWVmIGRpc2N1c3Npb24gb2Y8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj53aGF0IG9iamVjdHMsIGlm IGFueSwgbWlnaHQgYmUgY29uc2lkZXJlZCBzZW5zaXRpdmUuJm5ic3A7IEZvciBleGFtcGxlLCBv bmUgbWlnaHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj5hcmd1ZSB0aGUgc3dtRW5jYXBzVGFibGUgbWlnaHQgcmV2ZWFsIHRo aW5ncyBhYm91dCB0aGUgaW50ZXJuYWwgbmV0d29yazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnRvcG9sb2d5LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47 dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMpPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPnRoZSBzbWlsaW50IE1JQiBjaGVj a2VyIHJlcG9ydHMgc2V2ZXJhbCBlcnJvcnMuJm5ic3A7IEnigJl2ZSBub3RlZCBpbiBteSBjb21t ZW50czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPmhvdyB0byBmaXggdGhlbS4mbmJzcDsgKEkgdXNlZCA8YSBocmVmPSJodHRw Oi8vd3d3Lmlici5jcy50dS1icy5kZS9iaW4vc21pdG9vbHMuY2dpIj4NCmh0dHA6Ly93d3cuaWJy LmNzLnR1LWJzLmRlL2Jpbi9zbWl0b29scy5jZ2k8L2E+KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LURhdmU8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_ade96465bb8f4eaf8474dbabc07a76e7BY2PR03MB269namprd03pro_-- From cuiyong@tsinghua.edu.cn Sat Oct 12 23:02:42 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C992E11E8162 for ; Sat, 12 Oct 2013 23:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 brQdqRgvOEye for ; Sat, 12 Oct 2013 23:02:37 -0700 (PDT) Received: from tsinghua.edu.cn (smtp08.tsinghua.edu.cn [166.111.204.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2E55811E811D for ; Sat, 12 Oct 2013 23:02:33 -0700 (PDT) Received: from [192.168.0.108] (unknown [124.126.216.186]) by app4 (Coremail) with SMTP id DcxvpgD3_+dyN1pSAeoHAA--.1623S2; Sun, 13 Oct 2013 14:02:26 +0800 (CST) From: Yong Cui Content-Type: multipart/alternative; boundary="Apple-Mail=_44722876-320C-4E58-80F1-794B03B7676B" Date: Sun, 13 Oct 2013 14:02:25 +0800 Message-Id: <4E06F8EA-0518-461F-8D41-852D7E0F9AF2@tsinghua.edu.cn> To: softwires@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-CM-TRANSID: DcxvpgD3_+dyN1pSAeoHAA--.1623S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjpl1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E 3s1l8cAvFVAK0II2c7xJM2AIxVAIcxkEcVAq07x20xvEncxIr21lYx0E74AGY7Cv6cx26w 4UJr1UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACjI8F5VA0II8E6IAq YI8I648v4I1l42xK82IYc2Ij64vIr41l42xK82IY6x8ErcxFaVAv8VWkJr1UJwC20s026c 02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_ JF1lIxkGc2Ij64vIr4UvcSsGvfC2KfnxnUUI43ZEXa7VUnj2NtUUUUU== X-CM-SenderInfo: 5fxl50tqj632xlqjx3vdohv3gofq/ Cc: =?utf-8?Q?Cui_=E5=B4=94=E5=8B=87?= Subject: [Softwires] Arrangement on Vancouver meeting X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 06:02:42 -0000 --Apple-Mail=_44722876-320C-4E58-80F1-794B03B7676B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi folks, We will organize the Softwire WG meeting in Vancouver as a purely = working meeting.=20 Please note that there will be no call for agenda items this time. Yong & Suresh --Apple-Mail=_44722876-320C-4E58-80F1-794B03B7676B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi folks,

We will organize the Softwire WG meeting in Vancouver as a purely working meeting. 

Please note that there will be no call for agenda items this time.


Yong & Suresh

--Apple-Mail=_44722876-320C-4E58-80F1-794B03B7676B-- From internet-drafts@ietf.org Tue Oct 15 02:22:29 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30CA11E8179; Tue, 15 Oct 2013 02:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, 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 8HPK8U9fw2MQ; Tue, 15 Oct 2013 02:22:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6786211E8120; Tue, 15 Oct 2013 02:22:29 -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.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131015092229.2100.8382.idtracker@ietfa.amsl.com> Date: Tue, 15 Oct 2013 02:22:29 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-dhcp-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 09:22:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : DHCPv6 Options for configuration of Softwire Address and= Port Mapped Clients Author(s) : Tomasz Mrugalski Ole Troan Wojciech Dec Congxiao Bao Leaf Y. Yeh Xiaohong Deng Filename : draft-ietf-softwire-map-dhcp-05.txt Pages : 16 Date : 2013-10-15 Abstract: This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices. Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address+Port (A+P) for providing IPv4 connectivity across an IPv6 network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-dhcp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-dhcp-05 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 suresh.krishnan@ericsson.com Thu Oct 17 11:43:32 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F09F11E82A2 for ; Thu, 17 Oct 2013 11:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.339 X-Spam-Level: X-Spam-Status: No, score=-101.339 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, SARE_URGBIZ=0.725, URG_BIZ=1.585, 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 XXygyQj3+-mn for ; Thu, 17 Oct 2013 11:43:27 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id BBA6311E82A9 for ; Thu, 17 Oct 2013 11:43:25 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-3b-52602fcc809c Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 15.0D.03458.CCF20625; Thu, 17 Oct 2013 20:43:25 +0200 (CEST) Received: from [142.133.113.185] (147.117.188.134) by smtps-am.internal.ericsson.com (147.117.188.96) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 17 Oct 2013 14:43:24 -0400 Message-ID: <52602F26.5090101@ericsson.com> Date: Thu, 17 Oct 2013 14:40:38 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Softwires WG References: <20131017142434.21877.63746.idtracker@ietfa.amsl.com> In-Reply-To: <20131017142434.21877.63746.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [147.117.188.134] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnluLIzCtJLcpLzFFi42KZXLonQfesfkKQwZJLqhaHl21lcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxv8tc9kLnglWrN32kLmB8QhfFyMnh4SAicTsLVfYIGwxiQv3 1gPZXBxCAkcZJS58/sIO4exklPjV/4Kxi5GDg1dAW2LNYR2QBhYBVYnNW1+zg9hsQIM27PzM BGKLCoRJ3D93CMzmFRCUODnzCQuILQJU/2TnA7BlwgLuEl/ffGQGsYUEHCXuHn/DCmJzCjhJ XPl3lBniIEmJbYuOgc1nFtCUaN3+G8qWl9j+dg5Ur6bE1jXfWSHqlSX+vVvBMoFRaBaS1bOQ tM9C0r6AkXkVI0dpcWpZbrqR4SZGYGAek2Bz3MG44JPlIUZpDhYlcd4vb52DhATSE0tSs1NT C1KL4otKc1KLDzEycXBKNTCyLmKIXv/fzmzvTYaoRWsMPmuemba/TtpBseewL7vgbcPE5cU8 J/cqauVcnZxnconDX+nzbVvh5PSv9/evmD/F13lvxrxLHPzpFd731BxL/hz+ab/nV//B9UYP fBNv/kh7kKjdzrDnZ8CpvoPqjOvvBf66dZMhb8oLB6F9bh/1V1zyrIqLXcqmxFKckWioxVxU nAgA1Ti/6RoCAAA= Subject: [Softwires] Fwd: NOMCOM - Critical shortage of nominees for multiple areas X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 18:43:32 -0000 Hi all, The NomCom is looking for more nominees for the open positions. Please consider volunteering and/or nominating people who you feel are suited for these open positions. Thanks Suresh -------- Original Message -------- Subject: NOMCOM - Critical shortage of nominees for multiple areas Date: Thu, 17 Oct 2013 07:24:34 -0700 From: NomCom Chair 2013 Reply-To: , , , <"2013 To: IETF Announcement List CC: IETF Discuss [Catchier Subject line - apologies to those offended by a duplicate] A critically low number of people have accepted nominations for some of the IESG open positions. There is only one nominee per slot in APP, OPS and TSV, only two in INT and RAI. Many folks have declined nominations. While the Nomcom appreciates that support for two years of intense service is hard to assure, and while we are aware that there is much support for the incumbents who are standing, the IETF should continually be considering which new talent is available for our leadership, and the Nomcom process needs for there to be some review and deliberation. Therefore, we urgently request that more nominees come forward. DEADLINES Nominations - October 18 Questionnaires from nominees - October 25 Not coincidentally, this is a good time to think over and send your comments about the current statements of desired expertise of positions - this is part of the Nomcom's annual review process as well. Send them to nomcom13@ietf.org. Definitive location [*] of the current statements on desired expertise: https://datatracker.ietf.org/nomcom/2013/expertise/ Instructions and details on nomination [**]: https://datatracker.ietf.org/ann/nomcom/60602/ Thanks, everyone, Allison for the Nomcom [*] This year the Nomcom tools were recoded, and also transitioned into the datatracker. Apologies for a number of places where we didn't catch reference errors. [**] Yes, alas, the previous call for nominations used "OAM" instead of "OPS," but we have* corrected this (chair's pilot) error where it occurred in the Nomcom pages. From tom.taylor.stds@gmail.com Fri Oct 18 00:47:36 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F4721F9FD5 for ; Fri, 18 Oct 2013 00:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=0.6] 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 W6cPm-3E037W for ; Fri, 18 Oct 2013 00:47:35 -0700 (PDT) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9289B21F9E39 for ; Fri, 18 Oct 2013 00:47:33 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id 1so1529608qec.27 for ; Fri, 18 Oct 2013 00:47:33 -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 :content-type:content-transfer-encoding; bh=f/11Q0w11JvIPIConIW9HOlvC2eDuiLVGf62MBSQ1Gs=; b=O8whbroJX1mVopptXyTpUWvlojwYlBi++25yw2mqqYkdib8McglN5WKwfI4F2EuAal DlZZh8exPMPR0ymhPqV4I1XoY7TLVFzzQXoMQC2k4DNaOK0mznrPeeazEwTvRqe4ZxT8 YRKjgzEjxp0YMLPcGHERfaFDWXYFW/vPDeGpwegJ4cu+kZNW+xR6bsE6vdWWcDjJHqDh CZxab/kC6k8xwAbMtcJS7Y69lXDzq2MG2gn8jg6LcYTqpRwteiXA3I0EkT5HF9pdU5rV ZQ1snNbv4SMFo/pYH9eir2McRIEEXbgVHRTBgRNCJ5quQPothH40gQqbEFYfbinXTJxR HGxw== X-Received: by 10.49.72.164 with SMTP id e4mr2096094qev.36.1382082452883; Fri, 18 Oct 2013 00:47:32 -0700 (PDT) Received: from [192.168.1.65] ([64.56.240.110]) by mx.google.com with ESMTPSA id u3sm538366qej.8.2013.10.18.00.47.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Oct 2013 00:47:32 -0700 (PDT) Message-ID: <5260E78E.90702@gmail.com> Date: Fri, 18 Oct 2013 03:47:26 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Softwires Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Softwires] Thoughts on provisioning and universal CPE X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 07:47:36 -0000 (Long message) Nothing seems to be happening to the work on the universal CPE draft and provisioning of the various transition methods since last meeting. I wanted to summarize the situation to get things moving again, and I do that below. However, after spending the last day or two reviewing the various documents and trying to think how to factor the configuration data, I've come to the conclusion that MAP configuration is too idiosyncratic to be "unified" with configuration for Public 4o6, LW4o6, or DS-Lite. IMHO the sensible thing is to provide separate provisioning objects for each of these techniques so that, first, the CPE can signal which ones it supports through its entries in the Parameter Request List option, and then DHCP can send back the one AAA says that subscriber should use. Here's what I understand from the Softwires, Sunset4, and DHC Working Group Berlin minutes and the odd bit of list discussion since. Tom Taylor (1) DHCP Provisioning of IPv4 Options ==================================== The conclusion out of Berlin is that the best general solution to provisioning of IPv4 and transition-specific options is to use DHCPv4 over DHCPv6 as documented in draft-ietf-dhc-dhcpv4-over-dhcpv6-01.txt. The authors of draft-ietf-softwire-map-dhcp-05.txt argue that that document is sufficient to meet the needs of MAP, but it is not a general solution and leaves the other techniques uncovered. (2) CPE Considerations ===================== Here is an extract from the Softwires Berlin minutes: Mark: Unified-CPE vendors don't have to do 5 different things. CPEs just do one thing. Suresh: It's not about processing, just DHCP option. Mark: We will have different CPEs Ian: There'are also people who need unified model Simon: Unified-CPE doesn't mean unify everything. compromise will be very ugly Suresh: (to Mark)Do you concern that some people won't implement some options? Mark: Some will only implement some of the options. fragment of CPE. Mark: Problem is that there will be two kinds of CPE, not a unified CPE Suresh: I don't see how the IETF can prevent this (implement a subset of options) from happening. Suggestion? Mark: We start to diverge when we start talking in "modes" Ian: We very carefully picked the word "mode". we can change it if you want. Suresh: Not sure Mark's input is actionable From this I draw the conclusion that partial implementation will happen and it's probably a good idea to accommodate it. (3) 1-1 Mode =========== 1-1 mode is the same for Public v4ov6, LW4o6, and MAP. There's no need to tie it to any particular technology. The IPv4 address should be an option on its own, as Ted suggested in the meeting. Not sure if the last word recorded in the minutes on the MAP-DHCP topic was from Suresh, but it was: "lw4over6 to signal it supports ea=0. we don't want multiple DHCP option draft" Of course, calling out the IPv4 public address option in a Parameter Request List option provides such a signal. (4) Summary of Provisioned Information ===================================== Common to multiple methods -------------------------- Every method requires signalling of the IPv6 tunnel endpoint addresses at the CPE and the BR. It is assumed that this is done as a preliminary step, as illustrated in draft-ietf-softwire-public-4over6-10.txt Figure 2. That document assumes the provisioning of both addresses is done by DHCPv6, if it is done by DHCP at all. Note that RFC 6334 provides the AFTR-Name option, which is an FQDN. The IPv4 public address is also common to all techniques in 1-1 mode. This would be provisioned by DHCPv4overDHCPv6, per the consensus noted in (1) above. Public 4over6 ------------- No additional provisioning beyond public IPv4 address. DS-Lite (RFC 6333) ------------------ The IPv4 address of an IPv4 DNS server can be passed via DHCPv4overDHCPv6. This would require an update to RFC 6333 section 5.5. The B4 would no longer have to act as a DNS proxy. The source IPv4 address used by the B4 needs to be configured if it differs from the default 192.0.0.2. This would most likely be done by static configuration rather than DHCPv4. For multicast operation as described in draft-ietf-softwire-dslite-multicast-06.txt, three IPv6 prefixes have to be provisioned: the any-source and source-specific multicast prefixes mPrefix64 and the unicast prefix uPrefix64. Since these values relate specifically to IPv4 to IPv6 transition, they would be provisioned by DHCPv4overDHCPv6. Light-Weight 4over6 ------------------- An object to specify the assigned port set is required. This would be carried via DHCPv4overDHCPv6. MAP-E ----- The MAP CE is provided with one or more mapping rules for the domain in which it participates. That domain is distinguished by an IPv6 MAP BR address, as discussed above. The components of the rule are: -- the rule IPv6 prefix and length -- the rule IPv4 prefix and length -- the length of the EA bit portion of the rule IPv6 prefix. Mapping rules would be provided by DHCPv4overDHCPv6, since they relate strictly to transition. If multiple mapping rules are provided, mesh mode is implied. If just one mapping rule is provided, the situation is ambiguous, hence an object is required to specify hub-and-spoke versus mesh mode. The 4rd document specifically indicates that mode can vary between domains, so the same assumption is reasonable for MAP-E. 4rd --- 4rd uses similar rules to MAP-E, with the addition of a flag indicating whether well-known ports can be included in the allocated port set. 4rd adds tunnel traffic class and domain PMTU as provisionable values. The only mandatory addition is domain PMTU. This seems like a fragile way to distinguish 4rd support from MAP-E support. As suggested near the beginning of this note, the sensible approach IMHO is to specify technique-specific DHCPv4 container options so the CPE can indicate which transition techniques it implements by requesting them in the Parameter Request List option. Note that 4rd currently assumes DHCPv6 provisioning, but should use DHCPv4overDHCPv6 for most of this information. MAP-T ----- Quoting from the MAP-T document, section 6: The MAP-T CE and BR configuration is the same as for MAP-E described in Section 7 of [I-D.ietf-softwire-map] except for two differences: o Translation mode is used instead of Encapsulation o Use of the BR's IPv6 prefix instead of address Translation mode can be indicated by a MAP-T-specific DHCPv4 container option in line with previous suggestions. The BR IPv6 prefix would be provided by DHCPv6, perhaps as the same option that provides BR IPv6 addresses. From otroan@employees.org Fri Oct 18 02:22:06 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFCB21F9F84 for ; Fri, 18 Oct 2013 02:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=0.6] 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 hpvc5JCndmQ4 for ; Fri, 18 Oct 2013 02:22:05 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 1522A11E8108 for ; Fri, 18 Oct 2013 02:21:55 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 2F9E85F57; Fri, 18 Oct 2013 02:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=bGAiPv7VamiNClQDHqKid 5Sz5Vc=; b=UrAcfYBEfUmvGdp5hQQaYe3smuyvcHQRY28JRF1weVrs/9Ks8O9G6 X5n3N8OevRvaUHMXsK32CLgN15KDFV65yx4YbI44VDdT2Yjmt0RGOwfQLSrTC6Aj NyMe/nngN1Pm+8zNLx6KNy/AUe3PXE/I1M8bHCB7V5U3q9pc4lr5ow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=b6AT5ckmCHlNoEO 928p3UDWhuuwbrUy92H/49fdmxUcPHwGZFgTKMdailDNhJ6UZVhz2+aCe8w7G4gG qzLb1ugUwCADbN2QJf7Q3OzrozklnhGamSyZdBCcXClKFYVVOqoXO0mr2QwH1jXS BHlnCUhuRsCV0LXo5RYS1OyGIHy4= Received: from dhcp-10-61-108-148.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 809F15FFB; Fri, 18 Oct 2013 02:21:53 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_656EFCFA-7ECB-44CB-94DF-5CF8C37C8996"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ole Troan In-Reply-To: <5260E78E.90702@gmail.com> Date: Fri, 18 Oct 2013 11:21:50 +0200 Message-Id: <5FAA929F-3D98-4D8B-8B3C-A82FFDA35F38@employees.org> References: <5260E78E.90702@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1510) Cc: Softwires Subject: Re: [Softwires] Thoughts on provisioning and universal CPE X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 09:22:06 -0000 --Apple-Mail=_656EFCFA-7ECB-44CB-94DF-5CF8C37C8996 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tom, tl;dr. but did you see; http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-05 that I think proposes what you are saying below. 3 separate containers = for LW46,MAP-E and MAP-T. cheers, Ole On Oct 18, 2013, at 9:47 , Tom Taylor wrote: > (Long message) >=20 > Nothing seems to be happening to the work on the universal CPE draft = and provisioning of the various transition methods since last meeting. I = wanted to summarize the situation to get things moving again, and I do = that below. However, after spending the last day or two reviewing the = various documents and trying to think how to factor the configuration = data, I've come to the conclusion that MAP configuration is too = idiosyncratic to be "unified" with configuration for Public 4o6, LW4o6, = or DS-Lite. >=20 > IMHO the sensible thing is to provide separate provisioning objects = for each of these techniques so that, first, the CPE can signal which = ones it supports through its entries in the Parameter Request List = option, and then DHCP can send back the one AAA says that subscriber = should use. >=20 > Here's what I understand from the Softwires, Sunset4, and DHC Working = Group Berlin minutes and the odd bit of list discussion since. >=20 > Tom Taylor >=20 > (1) DHCP Provisioning of IPv4 Options > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The conclusion out of Berlin is that the best general solution to = provisioning of IPv4 and transition-specific options is to use DHCPv4 = over DHCPv6 as documented in draft-ietf-dhc-dhcpv4-over-dhcpv6-01.txt. = The authors of draft-ietf-softwire-map-dhcp-05.txt argue that that = document is sufficient to meet the needs of MAP, but it is not a general = solution and leaves the other techniques uncovered. >=20 > (2) CPE Considerations > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Here is an extract from the Softwires Berlin minutes: >=20 > Mark: Unified-CPE vendors don't have to do 5 different things. CPEs = just do one thing. > Suresh: It's not about processing, just DHCP option. > Mark: We will have different CPEs > Ian: There'are also people who need unified model > Simon: Unified-CPE doesn't mean unify everything. compromise will be = very ugly > Suresh: (to Mark)Do you concern that some people won't implement some = options? > Mark: Some will only implement some of the options. fragment of CPE. > Mark: Problem is that there will be two kinds of CPE, not a unified = CPE > Suresh: I don't see how the IETF can prevent this (implement a subset = of options) from happening. Suggestion? > Mark: We start to diverge when we start talking in "modes" > Ian: We very carefully picked the word "mode". we can change it if you = want. > Suresh: Not sure Mark's input is actionable >=20 > =46rom this I draw the conclusion that partial implementation will = happen and it's probably a good idea to accommodate it. >=20 >=20 > (3) 1-1 Mode > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1-1 mode is the same for Public v4ov6, LW4o6, and MAP. There's no need = to tie it to any particular technology. The IPv4 address should be an = option on its own, as Ted suggested in the meeting. >=20 > Not sure if the last word recorded in the minutes on the MAP-DHCP = topic was from Suresh, but it was: >=20 > "lw4over6 to signal it supports ea=3D0. we don't want multiple DHCP = option draft" >=20 > Of course, calling out the IPv4 public address option in a Parameter = Request List option provides such a signal. >=20 > (4) Summary of Provisioned Information > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Common to multiple methods > -------------------------- >=20 > Every method requires signalling of the IPv6 tunnel endpoint addresses = at the CPE and the BR. It is assumed that this is done as a preliminary = step, as illustrated in draft-ietf-softwire-public-4over6-10.txt Figure = 2. That document assumes the provisioning of both addresses is done by = DHCPv6, if it is done by DHCP at all. >=20 > Note that RFC 6334 provides the AFTR-Name option, which is an FQDN. >=20 > The IPv4 public address is also common to all techniques in 1-1 mode. = This would be provisioned by DHCPv4overDHCPv6, per the consensus noted = in (1) above. >=20 >=20 > Public 4over6 > ------------- >=20 > No additional provisioning beyond public IPv4 address. >=20 > DS-Lite (RFC 6333) > ------------------ >=20 > The IPv4 address of an IPv4 DNS server can be passed via = DHCPv4overDHCPv6. This would require an update to RFC 6333 section 5.5. = The B4 would no longer have to act as a DNS proxy. >=20 > The source IPv4 address used by the B4 needs to be configured if it = differs from the default 192.0.0.2. This would most likely be done by = static configuration rather than DHCPv4. >=20 > For multicast operation as described in = draft-ietf-softwire-dslite-multicast-06.txt, three IPv6 prefixes have to = be provisioned: the any-source and source-specific multicast prefixes = mPrefix64 and the unicast prefix uPrefix64. Since these values relate = specifically to IPv4 to IPv6 transition, they would be provisioned by = DHCPv4overDHCPv6. >=20 > Light-Weight 4over6 > ------------------- >=20 > An object to specify the assigned port set is required. This would be = carried via DHCPv4overDHCPv6. >=20 > MAP-E > ----- >=20 > The MAP CE is provided with one or more mapping rules for the domain = in which it participates. That domain is distinguished by an IPv6 MAP BR = address, as discussed above. The components of the rule are: > -- the rule IPv6 prefix and length > -- the rule IPv4 prefix and length > -- the length of the EA bit portion of the rule IPv6 prefix. >=20 > Mapping rules would be provided by DHCPv4overDHCPv6, since they relate = strictly to transition. >=20 > If multiple mapping rules are provided, mesh mode is implied. If just = one mapping rule is provided, the situation is ambiguous, hence an = object is required to specify hub-and-spoke versus mesh mode. The 4rd = document specifically indicates that mode can vary between domains, so = the same assumption is reasonable for MAP-E. >=20 > 4rd > --- >=20 > 4rd uses similar rules to MAP-E, with the addition of a flag = indicating whether well-known ports can be included in the allocated = port set. >=20 > 4rd adds tunnel traffic class and domain PMTU as provisionable values. >=20 > The only mandatory addition is domain PMTU. This seems like a fragile = way to distinguish 4rd support from MAP-E support. As suggested near the = beginning of this note, the sensible approach IMHO is to specify = technique-specific DHCPv4 container options so the CPE can indicate = which transition techniques it implements by requesting them in the = Parameter Request List option. >=20 > Note that 4rd currently assumes DHCPv6 provisioning, but should use = DHCPv4overDHCPv6 for most of this information. >=20 > MAP-T > ----- >=20 > Quoting from the MAP-T document, section 6: >=20 > The MAP-T CE and BR configuration is the same as for MAP-E described > in Section 7 of [I-D.ietf-softwire-map] except for two differences: >=20 > o Translation mode is used instead of Encapsulation >=20 > o Use of the BR's IPv6 prefix instead of address >=20 > Translation mode can be indicated by a MAP-T-specific DHCPv4 container = option in line with previous suggestions. >=20 > The BR IPv6 prefix would be provided by DHCPv6, perhaps as the same = option that provides BR IPv6 addresses. >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail=_656EFCFA-7ECB-44CB-94DF-5CF8C37C8996 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSYP2uAAoJEFuJXizso86ga2sH/A3lZx38HeSmhPrluPREYPbf +IGOoU3XE9AN7CPVaBcMqaxsKtG0dXFmoer9MihVao3cG0zazo5j8W8wQ3M+Nl/1 SnyA7yAfbfHo7CC+AvKYjZZQ1pMONePZJJR0rnLTQyRpAKM0iaEwG2P48yZ37XJ1 Koru8Ynp6CQoNNvdtExnFt3oc5CeKKx91gJ6x4pJNmtLRi5lSlqiNaoVKIB9wr7K D6naHIuRoEV/0j7gSKjtFGK1aKWBx/QkCeRsg/y5nwl9TUqPEqrUosUD19FM1FZ3 ytXZiHSSNSA1ur9dD3+/XYdltcvaLOA6Vh3YMGl8RDcNar0R4vlovj1RjPIQB3k= =djKi -----END PGP SIGNATURE----- --Apple-Mail=_656EFCFA-7ECB-44CB-94DF-5CF8C37C8996-- From Ted.Lemon@nominum.com Fri Oct 18 09:25:48 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE2A11E8305 for ; Fri, 18 Oct 2013 09:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrcKWOfAkukr for ; Fri, 18 Oct 2013 09:25:41 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id C5D0311E82F9 for ; Fri, 18 Oct 2013 09:25:27 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUmFg9PfnoVICwVxtKo00RifzgyrKYgQB@postini.com; Fri, 18 Oct 2013 09:25:28 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B217F1B82AE for ; Fri, 18 Oct 2013 09:25:24 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9863C190060; Fri, 18 Oct 2013 09:25:24 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Oct 2013 09:25:24 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <5260E78E.90702@gmail.com> Date: Fri, 18 Oct 2013 12:25:23 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <4AB3BC49-99ED-4689-9353-922EE65F0187@nominum.com> References: <5260E78E.90702@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: Softwires Subject: Re: [Softwires] Thoughts on provisioning and universal CPE X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 16:25:48 -0000 On Oct 18, 2013, at 3:47 AM, Tom Taylor = wrote: > IMHO the sensible thing is to provide separate provisioning objects = for each of these techniques so that, first, the CPE can signal which = ones it supports through its entries in the Parameter Request List = option, and then DHCP can send back the one AAA says that subscriber = should use. That still sounds like a unified CPE document. From simon.perreault@viagenie.ca Sun Oct 20 05:20:25 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686F211E81A7 for ; Sun, 20 Oct 2013 05:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 ajtLGXHr-p2G for ; Sun, 20 Oct 2013 05:20:24 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id B389F11E81A3 for ; Sun, 20 Oct 2013 05:20:24 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1BB42401F2 for ; Sun, 20 Oct 2013 08:20:24 -0400 (EDT) Message-ID: <5263CA87.1050904@viagenie.ca> Date: Sun, 20 Oct 2013 14:20:23 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: softwires@ietf.org References: <5260E78E.90702@gmail.com> In-Reply-To: <5260E78E.90702@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] Thoughts on provisioning and universal CPE X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 12:20:25 -0000 Le 2013-10-18 09:47, Tom Taylor a écrit : > Nothing seems to be happening to the work on the universal CPE draft For everyone's information: there were *a lot* of private discussions between the various draft authors. draft-ietf-softwire-map-dhcp-05 is one immediate result. The other result is the start of a common understanding about what the unified CPE draft is supposed to cover. I anticipate much unblocking in Vancouver. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From internet-drafts@ietf.org Mon Oct 21 08:37:51 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5477211E85B8; Mon, 21 Oct 2013 08:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, 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 arjsSlpzv87l; Mon, 21 Oct 2013 08:37:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE4911E83E4; Mon, 21 Oct 2013 08:36:17 -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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021153617.29469.62184.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 08:36:17 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-deployment-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 15:37:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Mapping of Address and Port (MAP) - Deployment Considera= tions Author(s) : Qiong Sun Maoke Chen Gang Chen Tina Tsou Simon Perreault Filename : draft-ietf-softwire-map-deployment-03.txt Pages : 30 Date : 2013-10-21 Abstract: This document describes when and how an operator uses the technique of Mapping of Address and Port (MAP) for the IPv4 residual deployment in the IPv6-dominant domain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-deployment There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-deployment-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-deployment-03 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 gnocuil@gmail.com Tue Oct 22 05:43:36 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785CC11E8383 for ; Tue, 22 Oct 2013 05:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 aKfG2uXdO-fY for ; Tue, 22 Oct 2013 05:43:13 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 245B511E8194 for ; Tue, 22 Oct 2013 05:43:06 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id v2so6263946qcr.6 for ; Tue, 22 Oct 2013 05:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DMIohp6J+wfVh43YzYIhC3wU9A6N1TMPuEKPEU5VVWw=; b=eg+EfnFIoyvbEwn6o183gdzTBqapwa96/dQaERR65WXwHlebqRZP8QIwz7QUHBUwYi t2azJueN4pQA31D42xcvt2Mk8BQ/w08wHCALNQVP5Dme/7iq3i19x/01xRQNwe73vkIP GIZcK6EJcyB+ug4h/RmGw9vB86lz+Vx8te4GIQGZzzTNkNcVzXrx4GQTJPRIwo4SVfwo 5BPrEw6QT6bJ5zxn9z1LAp+apQnlr0xgs42PxIVcTEezl7vEIHNjrq6umDPcgrCIREud YPqHk4GtZBp15py2bjFFUZukJGG15HO+5Xd4IUIH+K5jtb+C51D4vMuTrzl9AU1kRzYO BwEw== X-Received: by 10.224.161.13 with SMTP id p13mr30180916qax.23.1382445784767; Tue, 22 Oct 2013 05:43:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.185.33 with HTTP; Tue, 22 Oct 2013 05:42:44 -0700 (PDT) In-Reply-To: <5260E78E.90702@gmail.com> References: <5260E78E.90702@gmail.com> From: Cong Liu Date: Tue, 22 Oct 2013 20:42:44 +0800 Message-ID: To: Tom Taylor Content-Type: multipart/alternative; boundary=089e0149d166ec237f04e953bda9 Cc: Softwires Subject: Re: [Softwires] Thoughts on provisioning and universal CPE X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 12:43:37 -0000 --089e0149d166ec237f04e953bda9 Content-Type: text/plain; charset=ISO-8859-1 Dear Tom and all, I think this discussion is significant. 2013/10/18 Tom Taylor > (1) DHCP Provisioning of IPv4 Options > ==============================**====== > > The conclusion out of Berlin is that the best general solution to > provisioning of IPv4 and transition-specific options is to use DHCPv4 over > DHCPv6 as documented in draft-ietf-dhc-dhcpv4-over-**dhcpv6-01.txt. The > authors of draft-ietf-softwire-map-dhcp-**05.txt argue that that document > is sufficient to meet the needs of MAP, but it is not a general solution > and leaves the other techniques uncovered. > [Cong] I agree with this conclusion that DHCPv4 over DHCPv6 shoud be used as the IPv4 provisioning protocol in IPv6 network. I think it's clear that DHCPv4 is designed for IPv4 address provisioning, and DHCPv6 is designed for IPv6 address provisioning. I don't understand what the benefit is to use DHCPv6 for IPv4 address provisioning. > (4) Summary of Provisioned Information > ==============================**======= > > Common to multiple methods > -------------------------- > > Every method requires signalling of the IPv6 tunnel endpoint addresses at > the CPE and the BR. It is assumed that this is done as a preliminary step, > as illustrated in draft-ietf-softwire-public-**4over6-10.txt Figure 2. > That document assumes the provisioning of both addresses is done by DHCPv6, > if it is done by DHCP at all. > > Note that RFC 6334 provides the AFTR-Name option, which is an FQDN. > [Cong] map-dhcp-05 defines a new DHCPv6 option OPTION_S46_BR to provide BR/lwAFTR address. The draft requires both MAP-E and lw4o6 to use this option. If a unified tunnel-end option is needed, OPTION_AFTR_NAME in RFC6334 should be used. If this option is not good enough, we should update it. If OPTION_S46_BR is not going to cover DS-Lite, it should not include lw4o6 either. Then we should define seperate options for each mechanism. http://tools.ietf.org/html/draft-sun-softwire-lw4over6-dhcpv6-00 describes such scenario. > Light-Weight 4over6 > ------------------- > > An object to specify the assigned port set is required. This would be > carried via DHCPv4overDHCPv6. > [Cong] I agree and think it's a consensus that the recommended provisioning mechanism for lw4o6 is DHCPv4 over DHCPv6, not DHCPv6. Best Regards, Cong --089e0149d166ec237f04e953bda9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Tom and all,

I think this discussi= on is=A0significant.

2013/10/18 Tom Taylor <tom= .taylor.stds@gmail.com>
(1) DHCP Provis= ioning of IPv4 Options
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The conclusion out of Berlin is that the best general solution to provision= ing of IPv4 and transition-specific options is to use DHCPv4 over DHCPv6 as= documented in draft-ietf-dhc-dhcpv4-over-dhcpv6-01.txt. The authors= of draft-ietf-softwire-map-dhcp-05.txt argue that that document is = sufficient to meet the needs of MAP, but it is not a general solution and l= eaves the other techniques uncovered.

[Cong] I agree with this conclusion that D= HCPv4 over DHCPv6 shoud be used as the IPv4 provisioning protocol in IPv6 n= etwork.
I think it's clear that DHCPv4 is designed for IPv4 a= ddress provisioning, and DHCPv6 is designed for IPv6 address provisioning. = I don't understand what the=A0benefit is to use DHCPv6 for IPv4 address= provisioning.
=A0
(= 4) Summary of Provisioned Information
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Common to multiple methods
--------------------------

Every method requires signalling of the IPv6 tunnel endpoint addresses at t= he CPE and the BR. It is assumed that this is done as a preliminary step, a= s illustrated in draft-ietf-softwire-public-4over6-10.txt Figure 2. = That document assumes the provisioning of both addresses is done by DHCPv6,= if it is done by DHCP at all.

Note that RFC 6334 provides the AFTR-Name option, which is an FQDN.

[Cong] map-dhcp-05 defines a new DHCPv6 option= =A0OPTION_S46_BR to provide = BR/lwAFTR address. The draft requires both MAP-E and lw4o6 to use this opti= on.
If a unified tunnel-end= option is needed, OP= TION_AFTR_NAME in=A0R= FC6334 should be used. If this option is not good enough, we should update = it.
If=A0OPTION_S46_BR is = not going to cover DS-Lite, it should not include lw4o6 either. Then we sho= uld define seperate options for each mechanism.
http://t= ools.ietf.org/html/draft-sun-softwire-lw4over6-dhcpv6-00=A0describes su= ch=A0scenario.=A0


Light-Weight 4over6
-------------------

An object to specify the assigned port set is required. This would be carri= ed via DHCPv4overDHCPv6.

[Cong] I agree= and think it's a consensus that the=A0recommended provisioning mechani= sm for lw4o6 is=A0DHCPv4 over DHCPv6, not DHCPv6.

Best Regards,=A0
Cong
--089e0149d166ec237f04e953bda9-- From ianfarrer@gmx.com Tue Oct 22 07:40:58 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E587411E83A9 for ; Tue, 22 Oct 2013 07:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 MKV562OTRVdg for ; Tue, 22 Oct 2013 07:40:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4F38A11E84AC for ; Tue, 22 Oct 2013 07:40:14 -0700 (PDT) Received: from [141.255.255.229] ([141.255.255.229]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MNIi1-1VfVx60EWX-006zas for ; Tue, 22 Oct 2013 16:40:13 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_0CC545A9-11FC-492D-88E9-2A9ED3AAE333" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ian Farrer In-Reply-To: Date: Tue, 22 Oct 2013 16:40:11 +0200 Message-Id: <093ADC09-279B-4C10-BD5B-D50DA56828DA@gmx.com> References: <5260E78E.90702@gmail.com> To: Cong Liu X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:xNQhkDzvmtl/Pay8J05NmP1UwWNEd8Y5p2iDwmQHNlSoqe60JPz slp+2ZkqU3rEUyHz5ZTzIAR+bAIo9AsVm7Ev8nwNABdhhV3UqhiIF77d3BuhYuvR05QOtVU b2wb2fA+JUvqEDM65qBc/Xfg2FZ9iR9tG5B4xxhubZwpl9pRsPLicWx9ZIHGbuS4xVfBO6A 7DxtKoVpq9LI62EEmqtUQ== Cc: Softwires Subject: Re: [Softwires] Thoughts on provisioning and universal CPE X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 14:40:59 -0000 --Apple-Mail=_0CC545A9-11FC-492D-88E9-2A9ED3AAE333 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Cong, Please see inline. Cheers, Ian On 22 Oct 2013, at 14:42, Cong Liu wrote: > Dear Tom and all, >=20 > I think this discussion is significant. >=20 > 2013/10/18 Tom Taylor > (1) DHCP Provisioning of IPv4 Options > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The conclusion out of Berlin is that the best general solution to = provisioning of IPv4 and transition-specific options is to use DHCPv4 = over DHCPv6 as documented in draft-ietf-dhc-dhcpv4-over-dhcpv6-01.txt. = The authors of draft-ietf-softwire-map-dhcp-05.txt argue that that = document is sufficient to meet the needs of MAP, but it is not a general = solution and leaves the other techniques uncovered. >=20 > [Cong] I agree with this conclusion that DHCPv4 over DHCPv6 shoud be = used as the IPv4 provisioning protocol in IPv6 network. > I think it's clear that DHCPv4 is designed for IPv4 address = provisioning, and DHCPv6 is designed for IPv6 address provisioning. I = don't understand what the benefit is to use DHCPv6 for IPv4 address = provisioning. [ian] =46rom discussions in the DHC WG meetings in Atlanta/Orlando, I = understood that there was general agreement that if ONLY IPv4 address / = port set / MAP rules were necessary, for static reserved addresses, then = provisioning this over DHCPv6 was acceptable. This is from my memory of = the discussions, there was no poll taken. However, the MAP-DHCP draft = covers this case.=20 But, if dynamic v4 addresses or any other DHCPv4 options were necessary, = then DHCPv4 over DHCPv6 would be the way of providing this. The = v4-configuration document evaluates approaches against these = requirements which is why it reaches the conclusion that it does. So, I see that both can co-exist. They are solutions to meet different = requirements and have their own set of limitations. > =20 > (4) Summary of Provisioned Information > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Common to multiple methods > -------------------------- >=20 > Every method requires signalling of the IPv6 tunnel endpoint addresses = at the CPE and the BR. It is assumed that this is done as a preliminary = step, as illustrated in draft-ietf-softwire-public-4over6-10.txt Figure = 2. That document assumes the provisioning of both addresses is done by = DHCPv6, if it is done by DHCP at all. >=20 > Note that RFC 6334 provides the AFTR-Name option, which is an FQDN. >=20 > [Cong] map-dhcp-05 defines a new DHCPv6 option OPTION_S46_BR to = provide BR/lwAFTR address. The draft requires both MAP-E and lw4o6 to = use this option. [ian] map-dhcp-05 only describes a DHCPv6 option for provisioning = MAP/lw4o6. It doesn't make any requirements that clients implement the = option. Any provisioning requirements are the other way round (i.e. the = softwire mechanism draft has a normative reference to the draft that = describes provisioning). > If a unified tunnel-end option is needed, OPTION_AFTR_NAME in RFC6334 = should be used. If this option is not good enough, we should update it. > If OPTION_S46_BR is not going to cover DS-Lite, it should not include = lw4o6 either. Then we should define seperate options for each mechanism. > http://tools.ietf.org/html/draft-sun-softwire-lw4over6-dhcpv6-00 = describes such scenario.=20 >=20 [ian] I don't see a requirement for a unified tunnel-endpoint. Quite the = reverse, in fact. If you have several tunnel endpoints for different = tunnelling methods, then you probably need a way of separating them so = that you can direct client traffic to the right tunnel concentrator. We tried re-using OPTION_AFTR_NAME, but this gives you the problem of = how to identify RFC6333 tunnel clients from other softwire clients so = that you can route their traffic accordingly. An existing DS-Lite client = does not support OPTION_S46_BR and any practical solution for new = softwire mechanisms must be backwards compatible with existing ds-lite = clients. >=20 > Light-Weight 4over6 > ------------------- >=20 > An object to specify the assigned port set is required. This would be = carried via DHCPv4overDHCPv6. >=20 > [Cong] I agree and think it's a consensus that the recommended = provisioning mechanism for lw4o6 is DHCPv4 over DHCPv6, not DHCPv6. >=20 > Best Regards,=20 > Cong > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail=_0CC545A9-11FC-492D-88E9-2A9ED3AAE333 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Cong,

Please see = inline.

Cheers,
Ian

=
On 22 Oct 2013, at 14:42, Cong Liu <gnocuil@gmail.com> = wrote:

Dear Tom and all,

I = think this discussion is significant.

2013/10/18 Tom Taylor <tom.taylor.stds@gmail.com>
(1) DHCP Provisioning of IPv4 Options
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The conclusion out of Berlin is that the best general solution to = provisioning of IPv4 and transition-specific options is to use DHCPv4 = over DHCPv6 as documented in = draft-ietf-dhc-dhcpv4-over-dhcpv6-01.txt. The authors of = draft-ietf-softwire-map-dhcp-05.txt argue that that document is = sufficient to meet the needs of MAP, but it is not a general solution = and leaves the other techniques uncovered.

[Cong] I agree with this conclusion = that DHCPv4 over DHCPv6 shoud be used as the IPv4 provisioning protocol = in IPv6 network.
I think it's clear that DHCPv4 is designed = for IPv4 address provisioning, and DHCPv6 is designed for IPv6 address = provisioning. I don't understand what the benefit is to use DHCPv6 = for IPv4 address = provisioning.

[ian] =46rom discussions in the DHC WG meetings in = Atlanta/Orlando, I understood that there was general agreement that if = ONLY IPv4 address / port set / MAP rules were necessary, for static = reserved addresses, then provisioning this over DHCPv6 was acceptable. = This is from my memory of the discussions, there was no poll taken. = However, the MAP-DHCP draft covers this = case. 

But, if dynamic v4 addresses or any = other DHCPv4 options were necessary, then DHCPv4 over DHCPv6 would be = the way of providing this. The v4-configuration document evaluates = approaches against these requirements which is why it reaches the = conclusion that it does.

So, I see that both = can co-exist. They are solutions to meet different requirements and have = their own set of limitations.


 
(4) Summary of Provisioned Information
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Common to multiple methods
--------------------------

Every method requires signalling of the IPv6 tunnel endpoint addresses = at the CPE and the BR. It is assumed that this is done as a preliminary = step, as illustrated in draft-ietf-softwire-public-4over6-10.txt = Figure 2. That document assumes the provisioning of both addresses is = done by DHCPv6, if it is done by DHCP at all.

Note that RFC 6334 provides the AFTR-Name option, which is an = FQDN.

[Cong] map-dhcp-05 defines a = new DHCPv6 option OPTION_S46_BR to = provide BR/lwAFTR address. The draft requires both MAP-E and lw4o6 to = use this = option.

[ian] map-dhcp-05 only describes a DHCPv6 option for = provisioning MAP/lw4o6. It doesn't make any requirements that clients = implement the option. Any provisioning requirements are the other way = round (i.e. the softwire mechanism draft has a normative reference to = the draft that describes provisioning).

If a unified tunnel-end option is = needed, OPTION_AFTR_NAME = in RFC6334 should be used. = If this option is not good enough, we should update it.
If OPTION_S46_BR is not = going to cover DS-Lite, it should not include lw4o6 either. Then we = should define seperate options for each mechanism.
= http://tools.ietf.org/html/draft-sun-softwire-lw4over6-dhcpv6-00 = describes such 

Light-Weight 4over6
-------------------

An object to specify the assigned port set is required. This would be = carried via DHCPv4overDHCPv6.

[Cong] = I agree and think it's a consensus that the recommended = provisioning mechanism for lw4o6 is DHCPv4 over DHCPv6, not = DHCPv6.

Best = Regards, 
Cong
_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

= = --Apple-Mail=_0CC545A9-11FC-492D-88E9-2A9ED3AAE333-- From sunqi.csnet.thu@gmail.com Tue Oct 22 08:44:27 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866E221E808C for ; Tue, 22 Oct 2013 08:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 SoB51EdZ4Nrk for ; Tue, 22 Oct 2013 08:44:26 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8606611E846A for ; Tue, 22 Oct 2013 08:44:25 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id p10so7026197pdj.39 for ; Tue, 22 Oct 2013 08:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=WCqvowvcdVQrMJkBUuiYcEwWT47QJIInjtvRTUSWyDw=; b=uMgG33/prYV6EbMPwDOc1UjhM2zXi3xtD0jfDVBnDCzHBadt4r1GsQYbSSJOwXJtKa vDQpeUiLot9QRJZGvGtq3YMz/E2X5ZBoRg+USLyxjyqaNG+dsQ82JxpdcW+hzz1b38xp ZL7nXo+DcwQpTs9XYr09H8fcYwlkwNmuxKdeZ2A841cpNvLc55I0qHWGIOH28KTO1eu+ ZuoAPs7v2vJ2vTrBQUHLnaV3IG8He1Kx/GExAC5A+8ra4zdITMQuuuEI++tneLgM8JCR nphRbDAxM8oDMnPBxXsZHoc1xPuND4xi8u6/CZRkQ5YOz+QnVNHGhhlewF+LRbLGqZQb +tOg== X-Received: by 10.68.52.231 with SMTP id w7mr19714413pbo.19.1382456664847; Tue, 22 Oct 2013 08:44:24 -0700 (PDT) Received: from [192.168.43.198] ([117.136.38.108]) by mx.google.com with ESMTPSA id v4sm28367461pbq.31.2013.10.22.08.43.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 08:44:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-55-422461345 From: Qi Sun In-Reply-To: <093ADC09-279B-4C10-BD5B-D50DA56828DA@gmx.com> Date: Tue, 22 Oct 2013 23:43:06 +0800 Message-Id: References: <5260E78E.90702@gmail.com> <093ADC09-279B-4C10-BD5B-D50DA56828DA@gmx.com> To: Ian Farrer X-Mailer: Apple Mail (2.1085) Cc: Softwires Subject: Re: [Softwires] Thoughts on provisioning and universal CPE X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 15:44:27 -0000 --Apple-Mail-55-422461345 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Ian, Please see inline. On 2013-10-22, at =E4=B8=8B=E5=8D=8810:40, Ian Farrer wrote: > Hi Cong, >=20 > Please see inline. >=20 > Cheers, > Ian >=20 > On 22 Oct 2013, at 14:42, Cong Liu wrote: >=20 >> Dear Tom and all, >>=20 >> I think this discussion is significant. >>=20 >> 2013/10/18 Tom Taylor >> (1) DHCP Provisioning of IPv4 Options >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> The conclusion out of Berlin is that the best general solution to = provisioning of IPv4 and transition-specific options is to use DHCPv4 = over DHCPv6 as documented in draft-ietf-dhc-dhcpv4-over-dhcpv6-01.txt. = The authors of draft-ietf-softwire-map-dhcp-05.txt argue that that = document is sufficient to meet the needs of MAP, but it is not a general = solution and leaves the other techniques uncovered. >>=20 >> [Cong] I agree with this conclusion that DHCPv4 over DHCPv6 shoud be = used as the IPv4 provisioning protocol in IPv6 network. >> I think it's clear that DHCPv4 is designed for IPv4 address = provisioning, and DHCPv6 is designed for IPv6 address provisioning. I = don't understand what the benefit is to use DHCPv6 for IPv4 address = provisioning. >=20 > [ian] =46rom discussions in the DHC WG meetings in Atlanta/Orlando, I = understood that there was general agreement that if ONLY IPv4 address / = port set / MAP rules were necessary, for static reserved addresses, then = provisioning this over DHCPv6 was acceptable. This is from my memory of = the discussions, there was no poll taken. [Qi] This should be documented as a statement in the map-dhcp to specify = the case where to use DHCPv6 options for IPv4 allocation or not, if = map-dhcp intends to be a 'Softwire 46 DHCP Options' document. > However, the MAP-DHCP draft covers this case.=20 >=20 > But, if dynamic v4 addresses or any other DHCPv4 options were = necessary, then DHCPv4 over DHCPv6 would be the way of providing this. = The v4-configuration document evaluates approaches against these = requirements which is why it reaches the conclusion that it does. >=20 > So, I see that both can co-exist. They are solutions to meet different = requirements and have their own set of limitations. >=20 >=20 >> =20 >> (4) Summary of Provisioned Information >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Common to multiple methods >> -------------------------- >>=20 >> Every method requires signalling of the IPv6 tunnel endpoint = addresses at the CPE and the BR. It is assumed that this is done as a = preliminary step, as illustrated in = draft-ietf-softwire-public-4over6-10.txt Figure 2. That document assumes = the provisioning of both addresses is done by DHCPv6, if it is done by = DHCP at all. >>=20 >> Note that RFC 6334 provides the AFTR-Name option, which is an FQDN. >>=20 >> [Cong] map-dhcp-05 defines a new DHCPv6 option OPTION_S46_BR to = provide BR/lwAFTR address. The draft requires both MAP-E and lw4o6 to = use this option. >=20 > [ian] map-dhcp-05 only describes a DHCPv6 option for provisioning = MAP/lw4o6. It doesn't make any requirements that clients implement the = option. Any provisioning requirements are the other way round (i.e. the = softwire mechanism draft has a normative reference to the draft that = describes provisioning). >=20 >> If a unified tunnel-end option is needed, OPTION_AFTR_NAME in RFC6334 = should be used. If this option is not good enough, we should update it. >> If OPTION_S46_BR is not going to cover DS-Lite, it should not include = lw4o6 either. Then we should define seperate options for each mechanism. >> http://tools.ietf.org/html/draft-sun-softwire-lw4over6-dhcpv6-00 = describes such scenario.=20 >>=20 > [ian] I don't see a requirement for a unified tunnel-endpoint. Quite = the reverse, in fact. If you have several tunnel endpoints for different = tunnelling methods, then you probably need a way of separating them so = that you can direct client traffic to the right tunnel concentrator. > We tried re-using OPTION_AFTR_NAME, but this gives you the problem of = how to identify RFC6333 tunnel clients from other softwire clients so = that you can route their traffic accordingly. An existing DS-Lite client = does not support OPTION_S46_BR and any practical solution for new = softwire mechanisms must be backwards compatible with existing ds-lite = clients. [Qi] IMO, what you said falls into Cong's second 'if': lw4o6, map-e, = ds-lite are different tunnel mechanisms, so that different DHCPv6 = options for signaling of tunnel concentrator's v6 address are necessary. = Or the client would be not able to identify which tunnel concentrator it = should connect to. Best Regard, Qi >=20 >>=20 >> Light-Weight 4over6 >> ------------------- >>=20 >> An object to specify the assigned port set is required. This would be = carried via DHCPv4overDHCPv6. >>=20 >> [Cong] I agree and think it's a consensus that the recommended = provisioning mechanism for lw4o6 is DHCPv4 over DHCPv6, not DHCPv6. >>=20 >> Best Regards,=20 >> Cong >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-55-422461345 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear = Ian,

Please see = inline.


On 2013-10-22, at =E4=B8=8B=E5=8D=8810:40, = Ian Farrer wrote:

Hi = Cong,

Please see = inline.

Cheers,
Ian

=
On 22 Oct 2013, at 14:42, Cong Liu <gnocuil@gmail.com> = wrote:

Dear Tom and all,

I = think this discussion is significant.

2013/10/18 Tom Taylor <tom.taylor.stds@gmail.com>
(1) DHCP Provisioning of IPv4 Options
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The conclusion out of Berlin is that the best general solution to = provisioning of IPv4 and transition-specific options is to use DHCPv4 = over DHCPv6 as documented in = draft-ietf-dhc-dhcpv4-over-dhcpv6-01.txt. The authors of = draft-ietf-softwire-map-dhcp-05.txt argue that that document is = sufficient to meet the needs of MAP, but it is not a general solution = and leaves the other techniques uncovered.

[Cong] I agree with this conclusion = that DHCPv4 over DHCPv6 shoud be used as the IPv4 provisioning protocol = in IPv6 network.
I think it's clear that DHCPv4 is designed = for IPv4 address provisioning, and DHCPv6 is designed for IPv6 address = provisioning. I don't understand what the benefit is to use DHCPv6 = for IPv4 address = provisioning.

[ian] =46rom discussions in the DHC WG meetings in = Atlanta/Orlando, I understood that there was general agreement that if = ONLY IPv4 address / port set / MAP rules were necessary, for static = reserved addresses, then provisioning this over DHCPv6 was acceptable. = This is from my memory of the discussions, there was no poll taken. =

[Qi] This = should be documented as a statement in the map-dhcp to specify the case = where to use DHCPv6 options for IPv4 allocation or not, if map-dhcp = intends to be a 'Softwire 46 DHCP Options' = document.

However, the MAP-DHCP draft covers = this case. 

But, if dynamic v4 addresses = or any other DHCPv4 options were necessary, then DHCPv4 over DHCPv6 = would be the way of providing this. The v4-configuration document = evaluates approaches against these requirements which is why it reaches = the conclusion that it does.

So, I see that = both can co-exist. They are solutions to meet different requirements and = have their own set of limitations.


 
(4) Summary of Provisioned Information
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Common to multiple methods
--------------------------

Every method requires signalling of the IPv6 tunnel endpoint addresses = at the CPE and the BR. It is assumed that this is done as a preliminary = step, as illustrated in draft-ietf-softwire-public-4over6-10.txt = Figure 2. That document assumes the provisioning of both addresses is = done by DHCPv6, if it is done by DHCP at all.

Note that RFC 6334 provides the AFTR-Name option, which is an = FQDN.

[Cong] map-dhcp-05 defines a = new DHCPv6 option OPTION_S46_BR to = provide BR/lwAFTR address. The draft requires both MAP-E and lw4o6 to = use this = option.

[ian] map-dhcp-05 only describes a DHCPv6 option for = provisioning MAP/lw4o6. It doesn't make any requirements that clients = implement the option. Any provisioning requirements are the other way = round (i.e. the softwire mechanism draft has a normative reference to = the draft that describes provisioning).

If a unified tunnel-end option is = needed, OPTION_AFTR_NAME = in RFC6334 should be used. = If this option is not good enough, we should update it.
If OPTION_S46_BR is not = going to cover DS-Lite, it should not include lw4o6 either. Then we = should define seperate options for each mechanism.
= http://tools.ietf.org/html/draft-sun-softwire-lw4over6-dhcpv6-00 = describes such 


Light-Weight 4over6
-------------------

An object to specify the assigned port set is required. This would be = carried via DHCPv4overDHCPv6.

[Cong] = I agree and think it's a consensus that the recommended = provisioning mechanism for lw4o6 is DHCPv4 over DHCPv6, not = DHCPv6.

Best = Regards, 
Cong
_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.ietf.= org/mailman/listinfo/softwires

_= ______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

= --Apple-Mail-55-422461345-- From otroan@employees.org Tue Oct 22 09:34:58 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B154811E83E8 for ; Tue, 22 Oct 2013 09:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 SHqRZpVstBrE for ; Tue, 22 Oct 2013 09:34:50 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6DA11E82F4 for ; Tue, 22 Oct 2013 09:34:42 -0700 (PDT) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAMuoZlKQ/khN/2dsb2JhbABPCoMHOL8dgSUWdIIlAQEEAXkQC0ZXBi6HZQYNuj2OC4FDB4MfgQoDkC2JC5BYgyY6 X-IronPort-AV: E=Sophos;i="4.93,549,1378857600"; d="asc'?scan'208";a="18456245" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 22 Oct 2013 16:34:42 +0000 Received: from dhcp-10-61-107-167.cisco.com (dhcp-10-61-107-167.cisco.com [10.61.107.167]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9MGYdur032568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Oct 2013 16:34:39 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_96BDFFB5-2C92-47B3-A8DF-00EAEF6D6294"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ole Troan In-Reply-To: Date: Tue, 22 Oct 2013 18:34:38 +0200 Message-Id: References: <5260E78E.90702@gmail.com> <093ADC09-279B-4C10-BD5B-D50DA56828DA@gmx.com> To: Qi Sun X-Mailer: Apple Mail (2.1510) Cc: Softwires Subject: Re: [Softwires] Thoughts on provisioning and universal CPE X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 16:35:03 -0000 --Apple-Mail=_96BDFFB5-2C92-47B3-A8DF-00EAEF6D6294 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Qi, >>> The conclusion out of Berlin is that the best general solution to = provisioning of IPv4 and transition-specific options is to use DHCPv4 = over DHCPv6 as documented in draft-ietf-dhc-dhcpv4-over-dhcpv6-01.txt. = The authors of draft-ietf-softwire-map-dhcp-05.txt argue that that = document is sufficient to meet the needs of MAP, but it is not a general = solution and leaves the other techniques uncovered. >>>=20 >>> [Cong] I agree with this conclusion that DHCPv4 over DHCPv6 shoud be = used as the IPv4 provisioning protocol in IPv6 network. >>> I think it's clear that DHCPv4 is designed for IPv4 address = provisioning, and DHCPv6 is designed for IPv6 address provisioning. I = don't understand what the benefit is to use DHCPv6 for IPv4 address = provisioning. >>=20 >> [ian] =46rom discussions in the DHC WG meetings in Atlanta/Orlando, I = understood that there was general agreement that if ONLY IPv4 address / = port set / MAP rules were necessary, for static reserved addresses, then = provisioning this over DHCPv6 was acceptable. This is from my memory of = the discussions, there was no poll taken. >=20 > [Qi] This should be documented as a statement in the map-dhcp to = specify the case where to use DHCPv6 options for IPv4 allocation or not, = if map-dhcp intends to be a 'Softwire 46 DHCP Options' document. the main concern of MAP-DHCP is to provision the tunnel, i.e. the = link-layer. stateful DHCPv4 is not a possibility with MAP. I do agree that we could have a paragraph on "other configuration = information". >> However, the MAP-DHCP draft covers this case.=20 >>=20 >> But, if dynamic v4 addresses or any other DHCPv4 options were = necessary, then DHCPv4 over DHCPv6 would be the way of providing this. = The v4-configuration document evaluates approaches against these = requirements which is why it reaches the conclusion that it does. >>=20 >> So, I see that both can co-exist. They are solutions to meet = different requirements and have their own set of limitations. >>=20 >>=20 >>> =20 >>> (4) Summary of Provisioned Information >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> Common to multiple methods >>> -------------------------- >>>=20 >>> Every method requires signalling of the IPv6 tunnel endpoint = addresses at the CPE and the BR. It is assumed that this is done as a = preliminary step, as illustrated in = draft-ietf-softwire-public-4over6-10.txt Figure 2. That document assumes = the provisioning of both addresses is done by DHCPv6, if it is done by = DHCP at all. >>>=20 >>> Note that RFC 6334 provides the AFTR-Name option, which is an FQDN. >>>=20 >>> [Cong] map-dhcp-05 defines a new DHCPv6 option OPTION_S46_BR to = provide BR/lwAFTR address. The draft requires both MAP-E and lw4o6 to = use this option. >>=20 >> [ian] map-dhcp-05 only describes a DHCPv6 option for provisioning = MAP/lw4o6. It doesn't make any requirements that clients implement the = option. Any provisioning requirements are the other way round (i.e. the = softwire mechanism draft has a normative reference to the draft that = describes provisioning). >>=20 >>> If a unified tunnel-end option is needed, OPTION_AFTR_NAME in = RFC6334 should be used. If this option is not good enough, we should = update it. >>> If OPTION_S46_BR is not going to cover DS-Lite, it should not = include lw4o6 either. Then we should define seperate options for each = mechanism. >>> http://tools.ietf.org/html/draft-sun-softwire-lw4over6-dhcpv6-00 = describes such scenario.=20 >>>=20 >> [ian] I don't see a requirement for a unified tunnel-endpoint. Quite = the reverse, in fact. If you have several tunnel endpoints for different = tunnelling methods, then you probably need a way of separating them so = that you can direct client traffic to the right tunnel concentrator. >> We tried re-using OPTION_AFTR_NAME, but this gives you the problem of = how to identify RFC6333 tunnel clients from other softwire clients so = that you can route their traffic accordingly. An existing DS-Lite client = does not support OPTION_S46_BR and any practical solution for new = softwire mechanisms must be backwards compatible with existing ds-lite = clients. >=20 > [Qi] IMO, what you said falls into Cong's second 'if': lw4o6, map-e, = ds-lite are different tunnel mechanisms, so that different DHCPv6 = options for signaling of tunnel concentrator's v6 address are necessary. = Or the client would be not able to identify which tunnel concentrator it = should connect to. please read the map-dhcp draft. there are separate container options for the 3 mechanisms that map-dhcp = include. cheers, Ole --Apple-Mail=_96BDFFB5-2C92-47B3-A8DF-00EAEF6D6294 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSZqkfAAoJEFuJXizso86gibYH/3iQoqjxCE0ce+xhGljAVoL9 43Dnf1iVhjCuXgzB/HFFUB4Bxj4C8Ebu4p/SX8mg/kz7S3VpMAbwUD7wnYzr77Ec LdtcBRRNzyHGyRMXf7w1AMmsqxCoq3FgY/P8047ARn2UUaZkVlWwygfz2Fm7BqnN h19PuXeNABiWLoJ55tGwOtFotki4rD+g7AyvoNDT3wE0vGtlXF6h9VHDYJoJsijf +EHHjh5QTBvwuVoUCE99T9IOxS92sn2VQ+UXmlEIFblBGCh2JJqD9JfPE4OtqQit UPHFzOdPBsgY0J0ZTceMQLoT8fEzdp7UllqnkNOx2GdC9ySnOabEe2RTemhSH2w= =cZ16 -----END PGP SIGNATURE----- --Apple-Mail=_96BDFFB5-2C92-47B3-A8DF-00EAEF6D6294-- From gnocuil@gmail.com Tue Oct 29 07:33:02 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC11721E8135 for ; Tue, 29 Oct 2013 07:33:02 -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.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 BFTkwL3rbkDz for ; Tue, 29 Oct 2013 07:33:02 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9B90A21E8134 for ; Tue, 29 Oct 2013 07:33:01 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id j15so64816qaq.13 for ; Tue, 29 Oct 2013 07:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=fISiT1YRqQQnMCZfFZWsGO9aysKnZO1K4IVSu7Zdw34=; b=fyMvk4OEkfhNvXkGhrAfWV5Az8C2pq+/nF4bMN2/WSqCeOU6gisoNHqua5dmwLnC0h okAdNwWySyiNHet5SfUclQW5P0wwJck+9XUuFhq53K+m4M11mkWJulGEhW01bLJUjIGs WJjIFEUzurbfzl2MYuk1ePHEoSJ1S+bPJ4hEjm8nuJGO34jvKqK0qeQz/NgVcar6iv6m V5Gq2rmm/+kSujJ7SUKjwAZ2APcoHmE2IMqTa+cXejtmmkqViB/wuwtzyPWNfsDGqDx+ YhwlaCGa6OboDSmEABpVbR+h0NsRdbBJSTRbq97pTACdSysT05ah8Gpw7oaimC3nqCHO zQ1Q== X-Received: by 10.224.161.13 with SMTP id p13mr1053818qax.23.1383057180790; Tue, 29 Oct 2013 07:33:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.185.33 with HTTP; Tue, 29 Oct 2013 07:32:40 -0700 (PDT) In-Reply-To: <060.6dbd5be52b65a0ac9dd85f78f8b56c74@tools.ietf.org> References: <060.6dbd5be52b65a0ac9dd85f78f8b56c74@tools.ietf.org> From: Cong Liu Date: Tue, 29 Oct 2013 22:32:40 +0800 Message-ID: To: softwires Content-Type: multipart/alternative; boundary=089e0149d166f7167c04e9e217d7 Subject: [Softwires] Fwd: [softwire] #28: Dealing with DHCPv4-over-DHCPv6 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 14:33:03 -0000 --089e0149d166f7167c04e9e217d7 Content-Type: text/plain; charset=ISO-8859-1 Dear all, I have some concerns about current map-dhcp-05 document. From my understanding, this draft has been changed to "softwire-dhcp", to cover all DHCPv6-related provisioning for softwire mechanisms. But I'm confused with the descriptions about lw4o6 and the provisioning. In order to improve the document and push map, lw4o6 and softwire-dhcp further, I think there should be some updates on it. Here are the issues/suggestions: 0) MAP & lw4o6 are parallel solutions, rather than lw4o6 is a subset of MAP. Softwire-dhcp should claim this, and remove "Lightweight 4over6 is a strict subset of MAP-E". 1) MAP uses DHCPv6 as the provisioning mechanism. DHCPv6 is optional for lw4over6, used for stateless provisioning (static mode) 2) Dynamic IPv4 address assignment uses DHCPv4-over-DHCPv6 (IMHO it's the default case of lw4o6). DHCPv4-over-DHCPv6 enable & server address options can be put into containers, to enable the function. 3) use DHCPv4-over-DHCPv6 to provision additional configuration information for both lw4o6 & MAP. 4) Softwire-dhcp should make a normative reference to DHCPv4-over-DHCPv6. I have also submitted two tickets to the tracker : #27 for the "subset" issue, and #28 for DHCPv4-over-DHCPv6 issues. I'd like to ask the WG whether these should be considered. Thanks! Best Regards, Cong Liu ---------- Forwarded message ---------- From: softwire issue tracker Date: 2013/10/29 Subject: [softwire] #28: Dealing with DHCPv4-over-DHCPv6 To: draft-ietf-softwire-map-dhcp@tools.ietf.org, gnocuil@gmail.com Cc: softwires@ietf.org #28: Dealing with DHCPv4-over-DHCPv6 The current map-dhcp-05 draft covers static IPv4 provisioning for lw4o6, but does not cover dynamic IPv4 provisioning. Dynamic IPv4 provisioning is an important part of lw4o6. Current lw4over6-02 document says "An lwB4 MUST support dynamic port-restricted IPv4 address provisioning." According to current specification, dynamic IPv4 provisioning is the default working mode of lw4o6. And there is consensus in dhc wg that DHCPv4-over-DHCPv6 is the best underlying approach for IPv4 provisioning over IPv6 network, especially for dynamic provisioning. Since map-dhcp has been changed into "softwire-dhcp" to cover both MAP and lw4o6, it should cover the dynamic mode of lw4o6 and have a description of using DHCPv4-over-DHCPv6. The document should make a normative reference to DHCPv4-over-DHCPv6. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-softwire-map- gnocuil@gmail.com | dhcp@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: map-dhcp | Version: Severity: Active WG | Keywords: Document | -------------------------+------------------------------------------------- Ticket URL: softwire --089e0149d166f7167c04e9e217d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,

I have some c= oncerns about current map-dhcp-05 document. From my understanding, this dra= ft has been changed to "softwire-dhcp", to cover all DHCPv6-relat= ed provisioning for softwire mechanisms. But I'm confused with the desc= riptions about lw4o6 and the provisioning.

In order to improve the document and push map, lw4o6 an= d softwire-dhcp further, I think there should be some updates on it. Here a= re the issues/suggestions:

0) MAP & lw4o6 are = parallel solutions, rather than lw4o6 is a subset of MAP. Softwire-dhcp sho= uld claim this, and remove "Lightweight 4over6 is a strict subset of M= AP-E".
1) MAP uses DHCPv6 as the provisioning mechanism. DHCPv6 is optional f= or lw4over6, used for stateless provisioning (static mode)
2) Dyn= amic IPv4 address assignment uses DHCPv4-over-DHCPv6 (IMHO it's the def= ault case of lw4o6). DHCPv4-over-DHCPv6 enable & server address options= can be put into containers, to enable the function.
3) use DHCPv4-over-DHCPv6 to provision additional configuration inform= ation for both lw4o6 & MAP.
4) Softwire-dhcp should make a no= rmative reference to DHCPv4-over-DHCPv6.

I have al= so submitted two tickets to the tracker : #27 for the "subset" is= sue, and #28 for DHCPv4-over-DHCPv6 issues.

I'd like to ask the WG whether these should be cons= idered.

Thanks!

Best Rega= rds,
Cong Liu

---------= - Forwarded message ----------
From: softwire issue tracker <trac+softwire@t= ools.ietf.org>
Date: 2013/10/29
Subject: [softwire] #28= : Dealing with DHCPv4-over-DHCPv6
To: draft-ie= tf-softwire-map-dhcp@tools.ietf.org, gnocuil@gmail.com
Cc: softw= ires@ietf.org


#28: Dealing with DHCPv4-over-DHCPv6

=A0The current map-dhcp-05 draft covers static IPv4 provisioning for lw4o6,=
=A0but does not cover dynamic IPv4 provisioning.

=A0Dynamic IPv4 provisioning is an important part of lw4o6. Current
=A0lw4over6-02 document says "An lwB4 MUST support dynamic port-restri= cted
=A0IPv4 address provisioning." According to current specification, dyn= amic
=A0IPv4 provisioning is the default working mode of lw4o6. And there is
=A0consensus in dhc wg that DHCPv4-over-DHCPv6 is the best underlying
=A0approach for IPv4 provisioning over IPv6 network, especially for dynamic=
=A0provisioning.

=A0Since map-dhcp has been changed into "softwire-dhcp" to cover = both MAP and
=A0lw4o6, it should cover the dynamic mode of lw4o6 and have a description = of
=A0using DHCPv4-over-DHCPv6.

=A0The document should make a normative reference to DHCPv4-over-DHCPv6.
--
-------------------------+-------------------------------------------------=
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Owner: =A0draft-ietf-= softwire-map-
=A0 gnocuil@gmail.com =A0 =A0 =A0|= =A0dhcp@tools.ietf.org
=A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 | =A0 =A0 Status: =A0new
=A0Priority: =A0major =A0 =A0 =A0 =A0| =A0Milestone:
Component: =A0map-dhcp =A0 =A0 | =A0 =A0Version:
=A0Severity: =A0Active WG =A0 =A0| =A0 Keywords:
=A0 Document =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
-------------------------+-------------------------------------------------=

Ticket URL: <http://tools.ietf.org/wg/softwire/trac/ticket/28>= ;
softwire <= http://tools.ietf.org/softwire/>


--089e0149d166f7167c04e9e217d7-- From Ted.Lemon@nominum.com Tue Oct 29 12:06:52 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0768711E81B9 for ; Tue, 29 Oct 2013 12:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yQNg1SZZY-0 for ; Tue, 29 Oct 2013 12:06:45 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2D10311E8289 for ; Tue, 29 Oct 2013 12:06:45 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUnAHN/JWVls3ssj2umPic4V9uOZ7gAgt@postini.com; Tue, 29 Oct 2013 12:06:45 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A47811B82E5 for ; Tue, 29 Oct 2013 12:06:31 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7FC6619005D; Tue, 29 Oct 2013 12:06:31 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.03.0158.001; Tue, 29 Oct 2013 12:06:31 -0700 From: Ted Lemon To: Cong Liu Thread-Topic: [Softwires] [softwire] #28: Dealing with DHCPv4-over-DHCPv6 Thread-Index: AQHO1Nn5KbjBSDm9PUmP8k0owmCrZw== Date: Tue, 29 Oct 2013 19:06:30 +0000 Message-ID: <440B58D1-7CA8-4C46-B171-E1E4015FFCD7@nominum.com> References: <060.6dbd5be52b65a0ac9dd85f78f8b56c74@tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7D18CCB35246E446BB16BA86AD0F242F@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: softwires Subject: Re: [Softwires] [softwire] #28: Dealing with DHCPv4-over-DHCPv6 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 19:06:52 -0000 On Oct 29, 2013, at 10:32 AM, Cong Liu wrote: > 0) MAP & lw4o6 are parallel solutions, rather than lw4o6 is a subset of M= AP. Softwire-dhcp should claim this, and remove "Lightweight 4over6 is a st= rict subset of MAP-E". I think the correct thing to say here is that lw4over6 is much simpler than= MAP-E=97the client doesn't need to do any math, and just takes the configu= ration from the server. > 1) MAP uses DHCPv6 as the provisioning mechanism. DHCPv6 is optional for = lw4over6, used for stateless provisioning (static mode) How does the lw4over6 client know it's stateless without a DHCPv6 option th= at tells it? If you mean that the absence of a DHCPv6 option configuring = a static IP address/port set is what does it, then that solution still requ= ires DHCPv6=97it just doesn't require that specific option to be sent. The difference here is not that lw4over6 doesn't require DHCPv6, but that i= t additionally requires DHCPv4 for dynamic allocation, if dynamic allocatio= n is used. I am sure that I am just restating what you already know, but I want to be = sure that we don't start arguing about a point on which we don't actually d= isagree. From gnocuil@gmail.com Wed Oct 30 00:11:20 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8593F21E813A for ; Wed, 30 Oct 2013 00:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 tRAL0mMN+u6N for ; Wed, 30 Oct 2013 00:11:19 -0700 (PDT) Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id CA21521E80D8 for ; Wed, 30 Oct 2013 00:10:18 -0700 (PDT) Received: by mail-qe0-f41.google.com with SMTP id x7so603446qeu.28 for ; Wed, 30 Oct 2013 00:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QDsU5QD6nHFGy9tRlFxa5hn2WJIpz5z7XB/yC0kWvOA=; b=pT+CiEy9eUSkQZGJS1oimETEF1YjF5KjJtdQ60j0H4FP5vnqLHbBJ2aofNbEOXzeMU Y3AE/dmNwJIOhZzzGWsaSX9FUSQh2OPm6R0l2sBhlmHAholzIhKSUBwNMshKqTRABGhb KVZYMBhpWGykKtue2gUwkQl/HHFD9EqV1iD8Wc3akiRaLOsR2qowhPIWXrqbwbXdTEUy UPwHLJFmgyivIHA3+14eJrldPKZLSpwjYac6os/UFVEC57h8UZQk68ZoJIYIx7LIsEgo D/OoE7SZ/wsTx5edu5pW7o9aiC3n+iMjygQqQcsDfcTxm92oM5gjN84ApeQTBS8A9uKs CvzQ== X-Received: by 10.224.167.147 with SMTP id q19mr226801qay.119.1383117018240; Wed, 30 Oct 2013 00:10:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.185.33 with HTTP; Wed, 30 Oct 2013 00:09:58 -0700 (PDT) In-Reply-To: <440B58D1-7CA8-4C46-B171-E1E4015FFCD7@nominum.com> References: <060.6dbd5be52b65a0ac9dd85f78f8b56c74@tools.ietf.org> <440B58D1-7CA8-4C46-B171-E1E4015FFCD7@nominum.com> From: Cong Liu Date: Wed, 30 Oct 2013 15:09:58 +0800 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=089e0149cc888e217804e9f006ec Cc: softwires Subject: Re: [Softwires] [softwire] #28: Dealing with DHCPv4-over-DHCPv6 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 07:11:20 -0000 --089e0149cc888e217804e9f006ec Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ted, Thanks for your comments. 2013/10/30 Ted Lemon > On Oct 29, 2013, at 10:32 AM, Cong Liu wrote: > > 0) MAP & lw4o6 are parallel solutions, rather than lw4o6 is a subset of > MAP. Softwire-dhcp should claim this, and remove "Lightweight 4over6 is a > strict subset of MAP-E". > > I think the correct thing to say here is that lw4over6 is much simpler > than MAP-E=97the client doesn't need to do any math, and just takes the > configuration from the server. > [Cong] I agree. > > 1) MAP uses DHCPv6 as the provisioning mechanism. DHCPv6 is optional fo= r > lw4over6, used for stateless provisioning (static mode) > > How does the lw4over6 client know it's stateless without a DHCPv6 option > that tells it? If you mean that the absence of a DHCPv6 option > configuring a static IP address/port set is what does it, then that > solution still requires DHCPv6=97it just doesn't require that specific op= tion > to be sent. > > The difference here is not that lw4over6 doesn't require DHCPv6, but that > it additionally requires DHCPv4 for dynamic allocation, if dynamic > allocation is used. > [Cong] Yes, that's what I mean. DHCPv6 is required in both cases, and DHCPv4-over-DHCPv6 is also in DHCPv6, so this document should make a discussion on it. > > I am sure that I am just restating what you already know, but I want to b= e > sure that we don't start arguing about a point on which we don't actually > disagree. > [Cong] It seems not have been fully discussed in the mail list, so I just want to make sure whether there's consensus on these points. Thanks! Best Regards, Cong --089e0149cc888e217804e9f006ec Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Ted,

Thanks for your comments.

20= 13/10/30 Ted Lemon <Ted.Lemon@nominum.com>
On Oct 29, 2013, at 10:32 AM, Cong Liu &= lt;gnocuil@gmail.com> wrote: > 0) MAP & lw4o6 are parallel solutions, rather than lw4o6 is a subs= et of MAP. Softwire-dhcp should claim this, and remove "Lightweight 4o= ver6 is a strict subset of MAP-E".

I think the correct thing to say here is that lw4over6 is much simple= r than MAP-E=97the client doesn't need to do any math, and just takes t= he configuration from the server.
[Cong] I agree.=A0


> 1) MAP uses DHCPv6 as the provisioning mechanism. DHCPv6 is optional f= or lw4over6, used for stateless provisioning (static mode)

How does the lw4over6 client know it's stateless without a DHCPv6= option that tells it? =A0 If you mean that the absence of a DHCPv6 option = configuring a static IP address/port set is what does it, then that solutio= n still requires DHCPv6=97it just doesn't require that specific option = to be sent.

The difference here is not that lw4over6 doesn't require DHCPv6, but th= at it additionally requires DHCPv4 for dynamic allocation, if dynamic alloc= ation is used.
[Cong] Yes, that's what I mean. DHC= Pv6 is required in both cases, and DHCPv4-over-DHCPv6 is also in DHCPv6, so= this document should make a discussion on it.
=A0

I am sure that I am just restating what you already know, but I want to be = sure that we don't start arguing about a point on which we don't ac= tually disagree.
[Cong] It seems not have been fully d= iscussed in the mail list, so I just want to make sure whether there's= =A0consensus on these points.

Thanks!

Best Regards,
Cong
--089e0149cc888e217804e9f006ec-- From otroan@employees.org Wed Oct 30 06:50:55 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C3B11E8222 for ; Wed, 30 Oct 2013 06:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.456 X-Spam-Level: X-Spam-Status: No, score=-10.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 VxMAesk+3Zwu for ; Wed, 30 Oct 2013 06:50:49 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6953611E8167 for ; Wed, 30 Oct 2013 06:50:49 -0700 (PDT) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAOANcVKQ/khN/2dsb2JhbABZgwfAWYElFnSCJQEBBAF5BQsLDjhXBi6HZga6d44ggS8Hgx+BDQOQLYN9lWmDJzs X-IronPort-AV: E=Sophos;i="4.93,601,1378857600"; d="asc'?scan'208";a="18651518" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 30 Oct 2013 13:50:48 +0000 Received: from dhcp-lys01-vla250-10-147-113-158.cisco.com (dhcp-lys01-vla250-10-147-113-158.cisco.com [10.147.113.158]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9UDojf4013084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Oct 2013 13:50:46 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_0E86955D-6159-43DF-BD25-4A36F68AE8B1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ole Troan In-Reply-To: Date: Wed, 30 Oct 2013 14:50:45 +0100 Message-Id: <360A36EE-1369-4235-849F-CEA38FAECAE3@employees.org> References: <060.6dbd5be52b65a0ac9dd85f78f8b56c74@tools.ietf.org> To: Cong Liu X-Mailer: Apple Mail (2.1816) Cc: softwires Subject: Re: [Softwires] [softwire] #28: Dealing with DHCPv4-over-DHCPv6 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 13:50:55 -0000 --Apple-Mail=_0E86955D-6159-43DF-BD25-4A36F68AE8B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Cong, > I have some concerns about current map-dhcp-05 document. =46rom my = understanding, this draft has been changed to "softwire-dhcp", to cover = all DHCPv6-related provisioning for softwire mechanisms. But I'm = confused with the descriptions about lw4o6 and the provisioning. >=20 > In order to improve the document and push map, lw4o6 and softwire-dhcp = further, I think there should be some updates on it. Here are the = issues/suggestions: >=20 > 0) MAP & lw4o6 are parallel solutions, rather than lw4o6 is a subset = of MAP. Softwire-dhcp should claim this, and remove "Lightweight 4over6 = is a strict subset of MAP-E". > 1) MAP uses DHCPv6 as the provisioning mechanism. DHCPv6 is optional = for lw4over6, used for stateless provisioning (static mode) > 2) Dynamic IPv4 address assignment uses DHCPv4-over-DHCPv6 (IMHO it's = the default case of lw4o6). DHCPv4-over-DHCPv6 enable & server address = options can be put into containers, to enable the function. > 3) use DHCPv4-over-DHCPv6 to provision additional configuration = information for both lw4o6 & MAP. > 4) Softwire-dhcp should make a normative reference to = DHCPv4-over-DHCPv6. >=20 > I have also submitted two tickets to the tracker : #27 for the = "subset" issue, and #28 for DHCPv4-over-DHCPv6 issues. >=20 > I'd like to ask the WG whether these should be considered. MAP is incompatible with dynamic IPv4 address assignment using DHCPv4. either you can consider MAP DHCP as the building block used by a = separate document describing the DHCPv4 address assignment case. or we can split out LW46 provisioning = from MAP DHCP altogether. cheers, Ole --Apple-Mail=_0E86955D-6159-43DF-BD25-4A36F68AE8B1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJScQ61AAoJEFuJXizso86grpkH/A8bWaysWItn7zfe2XoldL9H tyQ8hmsnT+3Y29H3oRukDkfrH7GENWa/E6WOiCTnCPsP8kAVKRGU1SyHeDsC8WZw MJBzlNyk0b1KD3KPI1fBaZkXuoGcDWIGvQURI9GOC/VU5NVUBtpXvybeXfSqZvIf ZVFsayKKzCswnOBEmya9f7lDREx2JpUCvGWKQj1b5KCQ2nldMxVldslrv+wY0jPC 8C9fOUmMQtX5qKw84k2mgzpx3XDfHPysFZNDEmhiGZbmJwDf1KIpM1rIahs/kzxY 2xdcGsRwAIxmD+MaBmwUTKs/3dHcoN59RTIhRuAnvOpz+F20nff8clF/8iGRWo8= =HMvh -----END PGP SIGNATURE----- --Apple-Mail=_0E86955D-6159-43DF-BD25-4A36F68AE8B1-- From ot@cisco.com Wed Oct 30 06:53:30 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB94011E8222 for ; Wed, 30 Oct 2013 06:53:30 -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 e-QQd1vPW3z0 for ; Wed, 30 Oct 2013 06:53:26 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 3816011E8229 for ; Wed, 30 Oct 2013 06:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1676; q=dns/txt; s=iport; t=1383141190; x=1384350790; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=0UlYGHjfYnQwrG3bJZ20s55Z38bpT7EqKaYPMIkgc+o=; b=dz3Y1CdHPky2vDIxAscgYGRlLMBnW6arZk+7td2Wn7a8rQ365Noy6MCt cKUZFvWF0qPqCmDfXI4bhlq2aJNGIiLGEPpb9INq6fmq4iWiAx7R8grXa V4LrG5xf1haU96vazdhIJER0DtV6oldamtYyqEhBbcto3f/4Melt6QRUm c=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAM0OcVKQ/khN/2dsb2JhbABZgwc4wCGBJRZ0giYBAQR5EAsOOFcGLodsDbppBI9PB4MfgQ0DkC2HXZIJgyc7 X-IronPort-AV: E=Sophos;i="4.93,601,1378857600"; d="asc'?scan'208";a="19127149" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 30 Oct 2013 13:53:09 +0000 Received: from dhcp-lys01-vla250-10-147-113-158.cisco.com (dhcp-lys01-vla250-10-147-113-158.cisco.com [10.147.113.158]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9UDr3UP013572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Oct 2013 13:53:05 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_E0DB0508-1DB9-4421-A165-71F6781CD19F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ole Troan In-Reply-To: <060.522e9001bcb47e4a09fed369a8090c45@tools.ietf.org> Date: Wed, 30 Oct 2013 14:53:02 +0100 Message-Id: References: <060.522e9001bcb47e4a09fed369a8090c45@tools.ietf.org> To: Cong Liu X-Mailer: Apple Mail (2.1816) Cc: softwires , draft-ietf-softwire-map-dhcp@tools.ietf.org Subject: Re: [Softwires] [softwire] #27: lw4o6 is not a subset of map-e X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 13:53:30 -0000 --Apple-Mail=_E0DB0508-1DB9-4421-A165-71F6781CD19F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cong, > #27: lw4o6 is not a subset of map-e >=20 > The current map-dhcp-05 draft says (in section 4) : "Lightweight = 4over6 is > a strict subset of MAP-E in hub and spoke mode with zero embedded = address > bits." >=20 > Lightweight 4over6 is not a subset of MAP-E, they are parallel = solutions. > lw4o6 maintains per-subscriber state in lwAFTR, and supports dynamic = IPv4 > provisioning. MAP-E does not cover these features. which documents describe these features? I've read https://tools.ietf.org/html/draft-ietf-softwire-lw4over6-01 = combined with how LW46 is proposed to be provisioned in MAP DHCP. I'm = clearly missing some text somewhere. cheers, Ole --Apple-Mail=_E0DB0508-1DB9-4421-A165-71F6781CD19F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJScQ8+AAoJEP0up8EdT99JJb8IAMvhel3ORHub0LyPNGAd3tlV sK+gLeTkBzkTpi/mi9u0xL2wWtzKXTYw8ipUyzqbfoVpbMiA+KHwDitzIJJLRCHT uEngJYwrEwlQ1YG3WdgNRfKphSQrXtWXf7dYpuau1cnSYp/t6VPdG3u+iXcFhqS2 aDj5b/xsWqcq26WnGQEP/10Mi/WRXHAYnum1b5jkZfXRQDuQI7voSnJlo2gIH5ir 7h4F6fTxdbONeZSy/Hn4MJlURNUNpm9mMeYpBJT9bkbVK6apbCx0eYOABpEVtl74 uoC/DReRZwJiOBjZpbQOQUuhxyOQwTSSm57PIIBjZTvTJ6pXTLhSegodO7AoTvg= =MqI/ -----END PGP SIGNATURE----- --Apple-Mail=_E0DB0508-1DB9-4421-A165-71F6781CD19F--