From nobody Fri Oct 6 17:17:20 2017 Return-Path: X-Original-To: softwires@ietf.org Delivered-To: softwires@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9611321A7; Fri, 6 Oct 2017 17:17:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Mahesh Jethanandani To: Cc: softwires@ietf.org, draft-ietf-softwire-dslite-yang.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150733543329.11064.7489083325636357552@ietfa.amsl.com> Date: Fri, 06 Oct 2017 17:17:13 -0700 Archived-At: Subject: [Softwires] Yangdoctors early review of draft-ietf-softwire-dslite-yang-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.22 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 00:17:13 -0000 Reviewer: Mahesh Jethanandani Review result: On the Right Track Document reviewed: draft-ietf-softwire-dslite-yang-02. Do not know why I was assigned -02 version when I now notice that there are several 03 versions submitted all the way up to -06. Status: On the Right Track. I am not an expert in DS-Lite. This review is looking at the draft from a YANG perspective. With that said, I have marked it as “On the Right Track” because of some of the points discussed below. The authors are encouraged to spend time looking at other models for examples on how to write the model, read RFC6087, Guidelines for YANG documents. Summary: This document defines a YANG data model for the DS-Lite Address Family Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements . Overall Comments: The draft should refer to YANG 1.1 (RFC 7950) instead of RFC6020. The draft is not NMDA compliant. It carries a separate -state container that needs to be collapsed into one single container. For example, it carries containers such as aftr-current-config which seems to be carrying state information for the leafs in dslite-config. Is it given that a server will implement both AFTR and B4? If not, then please define feature statements and use if-feature for each part (AFTR and B4), so implementors can choose what part of the model is implemented. Section 1.1 Terminology What terms are defined in RFC 6333 that are being used in this draft. Please be explicit. Section 1.2 Tree Diagram Please refer to https://tools.ietf.org/html/draft-ietf-netmod-yang-tree-diagrams-01 instead of defining the nomenclature for tree diagram in the document. Section 2. s/can:/can s/provisioned to the AFTR/provisioned on the AFTR/ The document is very light in the architectural description of the YANG model itself. Statements like “model supports enabling one or more instances of the AFTR function on a device” are obvious looking at the model. A more reasonable description would be why multiple instances need to be supported. The same is true for “AFTR instance”. The fact that the instance has been defined as a list assure that each instance can be provisioned with dedicated configuration data, and maintain its own data table. Again why the multiple instances need to be maintained, what purpose do they serve, and the fact that they maintain their own data table is not clear. The document “assumes [RFC4787] [RFC5382][RFC 5508] are enabled”. What particular aspects of those documents is the draft assuming? Note, RFC4787 is NAT Behavioral Requirements for Unicast UDP, and outlines some seven behaviors, all the way from NAT and Port Translation, Filtering, Hairpinning to Fragmentation of Outgoing Packets. Even if all the behaviors are assumed, it would be good to know how they impact this particular model. Section 3 General Comments. Please follow [RFC6087], Guidelines for YANG documents, on how to write a YANG model. For example, the organization in the model should be IETF Softwire WG, not just Softwire WG. The indentation in the model is off in a few places (reference is a keyword that should be at the same indentation as description in all revision statements). Most models follow an indentation of 2 characters for every subsequent depth in the model. I see anywhere between 2 to 10 characters of indentation. As far as naming conventions go, there is little value repeating names in a given hierarchy. For example, if the grouping is aftr-parameters, then it is a given that parameters inside the grouping are aftr parameters. No need to say dslite-aftr-ipv6-address, where both dslite and aftr are redundant. There is little or no use of must statements to qualify the configuration. I am not an expert at DS-Lite, so I cannot suggest where a must statement may be helpful to have. But with all the parameters that are optional, there must be some relationship between the attributes that could be captured with must statements. For example, for the leaf max-softwire-per-subscriber, the leaf is trying to prevent a misbehaving subscriber. Could that behavior be somehow captured with a must statement for the resources it can/cannot consume. Or with port-presevation-enable and port-parity-preservation-enable? Is there a relationship between the two variables that could be captured in the model? All references to RFC should be moved under a reference section. For example: OLD: leaf udp-lifetime { type uint32; units "seconds"; default 120; description "UDP inactivity timeout [RFC4787]."; } NEW: leaf udp-lifetime { type uint32; units "seconds"; default 120; description "UDP inactivity timeout.“; reference “[RFC4787].”; } A note should be prepared for the RFC editor to indicate what revision the model should finally carry, and what the description/reference statement in the model should look like when the document is finally published. See examples in other drafts such as draft-ietf-netconf-zerotouch Editorial Note on what to add. Specific Comments The name of the file in the line with is missing the .yang suffix in the file. When extracted, the extracted file will be missing the suffix. Please add it. This leads to the following error from yanglint. ietf-dslite@2017-01-03" without file extension - unknown format. In grouping port-number, could the port-range be something as simple as container port-number { must “starting-port”; leaf starting-port { type inet:port-number; } leaf ending-port { type inet:port-number; } } where if there is no ending-port it is deemed to be a single port, but if there is a ending-port is considered to be a range? The list transport-protocol has one leaf which is the transport-protocol-id. Why does the single leaf, which is the key, need to be inside a list? Logging-info has a choice statement for protocol. Is it that there can be only one choice for the form of logging? Could it be possible that users might want to enable both syslog and ipfix? A pyang compilation of the model with —ietf and —lint option was clean. A idnits run of the draft reveals some issues with spacing and references. The one related to spacing are parts of the diagram, which confuses idnits. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 162 has weird spacing: '...ocol-id uin...' == Line 207 has weird spacing: '...address ine...' == Line 215 has weird spacing: '...address ine...' == Line 238 has weird spacing: '...rvation boo...' == Line 261 has weird spacing: '...ocol-id uin...' == (5 more instances...) Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC7753' is defined on line 1988, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-boucadair-pcp-yang-03 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). From nobody Mon Oct 9 00:39:28 2017 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 246AC134A63; Mon, 9 Oct 2017 00:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVemQ6ogtWFe; Mon, 9 Oct 2017 00:39:19 -0700 (PDT) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F51B134B26; Mon, 9 Oct 2017 00:39:19 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 6CD19C046E; Mon, 9 Oct 2017 09:34:06 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 4CA7B18006B; Mon, 9 Oct 2017 09:34:06 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0361.001; Mon, 9 Oct 2017 09:34:06 +0200 From: To: Mahesh Jethanandani , "yang-doctors@ietf.org" CC: "softwires@ietf.org" , "draft-ietf-softwire-dslite-yang.all@ietf.org" Thread-Topic: Yangdoctors early review of draft-ietf-softwire-dslite-yang-02 Thread-Index: AQHTPwGhj6PXHsGqNUWyvBEfCKn+raLbHGzw Date: Mon, 9 Oct 2017 07:34:05 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A051070@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <150733543329.11064.7489083325636357552@ietfa.amsl.com> In-Reply-To: <150733543329.11064.7489083325636357552@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Softwires] Yangdoctors early review of draft-ietf-softwire-dslite-yang-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 07:39:22 -0000 RGVhciBNYWhlc2gsIA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGUgZGV0YWlsZWQgcmV2 aWV3LiBNdWNoIGFwcHJlY2lhdGVkLiANCg0KSXQgc2VlbXMgdGhhdCB5b3UgcmV2aWV3ZWQgLTAy IG9mIHRoZSBkcmFmdCwgd2hpbGUgdGhlIGxhdGVzdCB2ZXJzaW9uIGlzIC0wNiAoaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zb2Z0d2lyZS1kc2xpdGUteWFuZy8p Lg0KDQpBcyB5b3UgY2FuIHNlZSBiZWxvdywgYWxtb3N0IGFsbCB0aGUgY29tbWVudHMgZG8gbm90 IGFwcGx5IGZvciAtMDYuDQoNClBsZWFzZSBzZWUgaW5saW5lLiANCg0KQ2hlZXJzLA0KTWVkDQoN Cj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IE1haGVzaCBKZXRoYW5hbmRh bmkgW21haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbV0NCj4gRW52b3nDqcKgOiBzYW1lZGkg NyBvY3RvYnJlIDIwMTcgMDI6MTcNCj4gw4DCoDogeWFuZy1kb2N0b3JzQGlldGYub3JnDQo+IENj wqA6IHNvZnR3aXJlc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1zb2Z0d2lyZS1kc2xpdGUteWFuZy5h bGxAaWV0Zi5vcmc7DQo+IGlldGZAaWV0Zi5vcmcNCj4gT2JqZXTCoDogWWFuZ2RvY3RvcnMgZWFy bHkgcmV2aWV3IG9mIGRyYWZ0LWlldGYtc29mdHdpcmUtZHNsaXRlLXlhbmctMDINCj4gDQo+IFJl dmlld2VyOiBNYWhlc2ggSmV0aGFuYW5kYW5pDQo+IFJldmlldyByZXN1bHQ6IE9uIHRoZSBSaWdo dCBUcmFjaw0KPiANCj4gRG9jdW1lbnQgcmV2aWV3ZWQ6IGRyYWZ0LWlldGYtc29mdHdpcmUtZHNs aXRlLXlhbmctMDIuIERvIG5vdCBrbm93IHdoeSBJDQo+IHdhcw0KPiBhc3NpZ25lZCAtMDIgdmVy c2lvbiB3aGVuIEkgbm93IG5vdGljZSB0aGF0IHRoZXJlIGFyZSBzZXZlcmFsIDAzIHZlcnNpb25z DQo+IHN1Ym1pdHRlZCBhbGwgdGhlIHdheSB1cCB0byAtMDYuDQo+IA0KPiBTdGF0dXM6IE9uIHRo ZSBSaWdodCBUcmFjay4NCj4gDQo+IEkgYW0gbm90IGFuIGV4cGVydCBpbiBEUy1MaXRlLiBUaGlz IHJldmlldyBpcyBsb29raW5nIGF0IHRoZSBkcmFmdCBmcm9tIGENCj4gWUFORw0KPiBwZXJzcGVj dGl2ZS4gV2l0aCB0aGF0IHNhaWQsIEkgaGF2ZSBtYXJrZWQgaXQgYXMg4oCcT24gdGhlIFJpZ2h0 IFRyYWNr4oCdDQo+IGJlY2F1c2UNCj4gb2Ygc29tZSBvZiB0aGUgcG9pbnRzIGRpc2N1c3NlZCBi ZWxvdy4gVGhlIGF1dGhvcnMgYXJlIGVuY291cmFnZWQgdG8gc3BlbmQNCj4gdGltZQ0KPiBsb29r aW5nIGF0IG90aGVyIG1vZGVscyBmb3IgZXhhbXBsZXMgb24gaG93IHRvIHdyaXRlIHRoZSBtb2Rl bCwgcmVhZA0KPiBSRkM2MDg3LA0KPiBHdWlkZWxpbmVzIGZvciBZQU5HIGRvY3VtZW50cy4NCj4g DQo+IFN1bW1hcnk6DQo+IA0KPiBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIGRhdGEgbW9k ZWwgZm9yIHRoZSBEUy1MaXRlIEFkZHJlc3MgRmFtaWx5DQo+IFRyYW5zaXRpb24gUm91dGVyIChB RlRSKSBhbmQgQmFzaWMgQnJpZGdpbmcgQnJvYWRCYW5kIChCNCkgZWxlbWVudHMgLg0KPiANCj4g T3ZlcmFsbCBDb21tZW50czoNCj4gDQo+IFRoZSBkcmFmdCBzaG91bGQgcmVmZXIgdG8gWUFORyAx LjEgKFJGQyA3OTUwKSBpbnN0ZWFkIG9mIFJGQzYwMjAuDQoNCltNZWRdIENhbiBmaXggdGhpcyBv bmUuIA0KDQo+IA0KPiBUaGUgZHJhZnQgaXMgbm90IE5NREEgY29tcGxpYW50LiBJdCBjYXJyaWVz IGEgc2VwYXJhdGUgLXN0YXRlIGNvbnRhaW5lcg0KPiB0aGF0DQo+IG5lZWRzIHRvIGJlIGNvbGxh cHNlZCBpbnRvIG9uZSBzaW5nbGUgY29udGFpbmVyLiBGb3IgZXhhbXBsZSwgaXQgY2Fycmllcw0K PiBjb250YWluZXJzIHN1Y2ggYXMgYWZ0ci1jdXJyZW50LWNvbmZpZyB3aGljaCBzZWVtcyB0byBi ZSBjYXJyeWluZyBzdGF0ZQ0KPiBpbmZvcm1hdGlvbiBmb3IgdGhlIGxlYWZzIGluIGRzbGl0ZS1j b25maWcuDQoNCltNZWRdIFRoZXJlIGFyZSBubyBzdWNoIGNvbnRhaW5lcnMgaW4gLTA2Lg0KDQo+ IA0KPiBJcyBpdCBnaXZlbiB0aGF0IGEgc2VydmVyIHdpbGwgaW1wbGVtZW50IGJvdGggQUZUUiBh bmQgQjQ/DQpbTWVkXSBOby4NCg0KIElmIG5vdCwgdGhlbg0KPiBwbGVhc2UNCj4gZGVmaW5lIGZl YXR1cmUgc3RhdGVtZW50cyBhbmQgdXNlIGlmLWZlYXR1cmUgZm9yIGVhY2ggcGFydCAoQUZUUiBh bmQgQjQpLA0KPiBzbw0KPiBpbXBsZW1lbnRvcnMgY2FuIGNob29zZSB3aGF0IHBhcnQgb2YgdGhl IG1vZGVsIGlzIGltcGxlbWVudGVkLg0KPiANCj4gU2VjdGlvbiAxLjEgVGVybWlub2xvZ3kNCj4g DQo+IFdoYXQgdGVybXMgYXJlIGRlZmluZWQgaW4gUkZDIDYzMzMgdGhhdCBhcmUgYmVpbmcgdXNl ZCBpbiB0aGlzIGRyYWZ0Lg0KPiBQbGVhc2UgYmUNCj4gZXhwbGljaXQuDQoNCltNZWRdIEFjdHVh bGx5LCBhbGwgdGhlIHRlcm1zIGRlZmluZWQgaW4gU2VjdGlvbiAzIG9mIFJGQyA2MzMzIGFyZSB1 c2VkIGluIHRoaXMgZG9jdW1lbnQuIEkgYWRkZWQgYW4gZXhwbGljaXQgcG9pbnRlciB0byBTZWN0 aW9uIDMuDQoNCj4gDQo+IFNlY3Rpb24gMS4yIFRyZWUgRGlhZ3JhbQ0KPiANCj4gUGxlYXNlIHJl ZmVyIHRvDQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC15 YW5nLXRyZWUtZGlhZ3JhbXMtMDENCj4gaW5zdGVhZCBvZg0KPiBkZWZpbmluZyB0aGUgbm9tZW5j bGF0dXJlIGZvciB0cmVlIGRpYWdyYW0gaW4gdGhlIGRvY3VtZW50Lg0KDQpbTWVkXSBEb25lLiBU aGFua3MuDQoNCj4gDQo+IFNlY3Rpb24gMi4NCj4gDQo+IHMvY2FuOi9jYW4NCg0KW01lZF0gVGhl cmUgaXMgbm8gc3VjaCBvY2N1cnJlbmNlIGluIC0wNi4NCg0KPiBzL3Byb3Zpc2lvbmVkIHRvIHRo ZSBBRlRSL3Byb3Zpc2lvbmVkIG9uIHRoZSBBRlRSLw0KDQpbTWVkXSBUaGVyZSBpcyBubyBzdWNo IG9jY3VycmVuY2UgaW4gLTA2Lg0KDQo+IA0KPiBUaGUgZG9jdW1lbnQgaXMgdmVyeSBsaWdodCBp biB0aGUgYXJjaGl0ZWN0dXJhbCBkZXNjcmlwdGlvbiBvZiB0aGUgWUFORw0KPiBtb2RlbA0KPiBp dHNlbGYuIFN0YXRlbWVudHMgbGlrZSDigJxtb2RlbCBzdXBwb3J0cyBlbmFibGluZyBvbmUgb3Ig bW9yZSBpbnN0YW5jZXMgb2YNCj4gdGhlDQo+IEFGVFIgZnVuY3Rpb24gb24gYSBkZXZpY2XigJ0g YXJlIG9idmlvdXMgbG9va2luZyBhdCB0aGUgbW9kZWwuIEEgbW9yZQ0KPiByZWFzb25hYmxlDQo+ IGRlc2NyaXB0aW9uIHdvdWxkIGJlIHdoeSBtdWx0aXBsZSBpbnN0YW5jZXMgbmVlZCB0byBiZSBz dXBwb3J0ZWQuIFRoZSBzYW1lDQo+IGlzDQo+IHRydWUgZm9yIOKAnEFGVFIgaW5zdGFuY2XigJ0u IFRoZSBmYWN0IHRoYXQgdGhlIGluc3RhbmNlIGhhcyBiZWVuIGRlZmluZWQgYXMgYQ0KPiBsaXN0 DQo+IGFzc3VyZSB0aGF0IGVhY2ggaW5zdGFuY2UgY2FuIGJlIHByb3Zpc2lvbmVkIHdpdGggZGVk aWNhdGVkIGNvbmZpZ3VyYXRpb24NCj4gZGF0YSwNCj4gYW5kIG1haW50YWluIGl0cyBvd24gZGF0 YSB0YWJsZS4gQWdhaW4gd2h5IHRoZSBtdWx0aXBsZSBpbnN0YW5jZXMgbmVlZCB0bw0KPiBiZQ0K PiBtYWludGFpbmVkLCB3aGF0IHB1cnBvc2UgZG8gdGhleSBzZXJ2ZSwgYW5kIHRoZSBmYWN0IHRo YXQgdGhleSBtYWludGFpbg0KPiB0aGVpcg0KPiBvd24gZGF0YSB0YWJsZSBpcyBub3QgY2xlYXIu DQo+IA0KPiBUaGUgZG9jdW1lbnQg4oCcYXNzdW1lcyBbUkZDNDc4N10gW1JGQzUzODJdW1JGQyA1 NTA4XSBhcmUgZW5hYmxlZOKAnS4gV2hhdA0KPiBwYXJ0aWN1bGFyIGFzcGVjdHMgb2YgdGhvc2Ug ZG9jdW1lbnRzIGlzIHRoZSBkcmFmdCBhc3N1bWluZz8gTm90ZSwgUkZDNDc4Nw0KPiBpcw0KPiBO QVQgQmVoYXZpb3JhbCBSZXF1aXJlbWVudHMgZm9yIFVuaWNhc3QgVURQLCBhbmQgb3V0bGluZXMg c29tZSBzZXZlbg0KPiBiZWhhdmlvcnMsDQo+IGFsbCB0aGUgd2F5IGZyb20gTkFUIGFuZCBQb3J0 IFRyYW5zbGF0aW9uLCBGaWx0ZXJpbmcsIEhhaXJwaW5uaW5nIHRvDQo+IEZyYWdtZW50YXRpb24g b2YgT3V0Z29pbmcgUGFja2V0cy4gRXZlbiBpZiBhbGwgdGhlIGJlaGF2aW9ycyBhcmUgYXNzdW1l ZCwNCj4gaXQNCj4gd291bGQgYmUgZ29vZCB0byBrbm93IGhvdyB0aGV5IGltcGFjdCB0aGlzIHBh cnRpY3VsYXIgbW9kZWwuDQoNCltNZWRdIFdoYXQgaXQgbWVhbnQgaXMgdGhhdCBhbGwgdGhlIHJl Y29tbWVuZGF0aW9ucyBhcmUgc3VwcG9ydGVkICsgYWxsIHJlY29tbWVuZGVkIHZhbHVlcyBhcmUg dGhlIG9uZXMgZGVmaW5lZCBpbiB0aG9zZSBSRkNzLg0KDQo+IA0KPiBTZWN0aW9uIDMNCj4gDQo+ IEdlbmVyYWwgQ29tbWVudHMuDQo+IA0KPiBQbGVhc2UgZm9sbG93IFtSRkM2MDg3XSwgR3VpZGVs aW5lcyBmb3IgWUFORyBkb2N1bWVudHMsIG9uIGhvdyB0byB3cml0ZSBhDQo+IFlBTkcNCj4gbW9k ZWwuIEZvciBleGFtcGxlLCB0aGUgb3JnYW5pemF0aW9uIGluIHRoZSBtb2RlbCBzaG91bGQgYmUg SUVURiBTb2Z0d2lyZQ0KPiBXRywNCj4gbm90IGp1c3QgU29mdHdpcmUgV0cuDQo+IA0KPiBUaGUg aW5kZW50YXRpb24gaW4gdGhlIG1vZGVsIGlzIG9mZiBpbiBhIGZldyBwbGFjZXMgKHJlZmVyZW5j ZSBpcyBhDQo+IGtleXdvcmQNCj4gdGhhdCBzaG91bGQgYmUgYXQgdGhlIHNhbWUgaW5kZW50YXRp b24gYXMgZGVzY3JpcHRpb24gaW4gYWxsIHJldmlzaW9uDQo+IHN0YXRlbWVudHMpLiBNb3N0IG1v ZGVscyBmb2xsb3cgYW4gaW5kZW50YXRpb24gb2YgMiBjaGFyYWN0ZXJzIGZvciBldmVyeQ0KPiBz dWJzZXF1ZW50IGRlcHRoIGluIHRoZSBtb2RlbC4gSSBzZWUgYW55d2hlcmUgYmV0d2VlbiAyIHRv IDEwIGNoYXJhY3RlcnMNCj4gb2YNCj4gaW5kZW50YXRpb24uDQo+IA0KDQpbTWVkXSBXaWxsIGRv dWJsZSBjaGVjay4gVGhhbmtzLg0KDQoNCj4gQXMgZmFyIGFzIG5hbWluZyBjb252ZW50aW9ucyBn bywgdGhlcmUgaXMgbGl0dGxlIHZhbHVlIHJlcGVhdGluZyBuYW1lcyBpbg0KPiBhDQo+IGdpdmVu IGhpZXJhcmNoeS4gRm9yIGV4YW1wbGUsIGlmIHRoZSBncm91cGluZyBpcyBhZnRyLXBhcmFtZXRl cnMsIHRoZW4gaXQNCj4gaXMgYQ0KPiBnaXZlbiB0aGF0IHBhcmFtZXRlcnMgaW5zaWRlIHRoZSBn cm91cGluZyBhcmUgYWZ0ciBwYXJhbWV0ZXJzLiBObyBuZWVkIHRvDQo+IHNheQ0KPiBkc2xpdGUt YWZ0ci1pcHY2LWFkZHJlc3MsIHdoZXJlIGJvdGggZHNsaXRlIGFuZCBhZnRyIGFyZSByZWR1bmRh bnQuDQo+IA0KDQpbTWVkXSBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgZG9lcyBub3QgYXBwbHkgZm9y IC0wNi4NCg0KDQo+IFRoZXJlIGlzIGxpdHRsZSBvciBubyB1c2Ugb2YgbXVzdCBzdGF0ZW1lbnRz IHRvIHF1YWxpZnkgdGhlIGNvbmZpZ3VyYXRpb24uDQo+IEkgYW0NCj4gbm90IGFuIGV4cGVydCBh dCBEUy1MaXRlLCBzbyBJIGNhbm5vdCBzdWdnZXN0IHdoZXJlIGEgbXVzdCBzdGF0ZW1lbnQgbWF5 DQo+IGJlDQo+IGhlbHBmdWwgdG8gaGF2ZS4gQnV0IHdpdGggYWxsIHRoZSBwYXJhbWV0ZXJzIHRo YXQgYXJlIG9wdGlvbmFsLCB0aGVyZSBtdXN0DQo+IGJlDQo+IHNvbWUgcmVsYXRpb25zaGlwIGJl dHdlZW4gdGhlIGF0dHJpYnV0ZXMgdGhhdCBjb3VsZCBiZSBjYXB0dXJlZCB3aXRoIG11c3QNCj4g c3RhdGVtZW50cy4gRm9yIGV4YW1wbGUsIGZvciB0aGUgbGVhZiBtYXgtc29mdHdpcmUtcGVyLXN1 YnNjcmliZXIsIHRoZQ0KPiBsZWFmIGlzDQo+IHRyeWluZyB0byBwcmV2ZW50IGEgbWlzYmVoYXZp bmcgc3Vic2NyaWJlci4gQ291bGQgdGhhdCBiZWhhdmlvciBiZSBzb21laG93DQo+IGNhcHR1cmVk IHdpdGggYSBtdXN0IHN0YXRlbWVudCBmb3IgdGhlIHJlc291cmNlcyBpdCBjYW4vY2Fubm90IGNv bnN1bWUuIE9yDQo+IHdpdGgNCj4gcG9ydC1wcmVzZXZhdGlvbi1lbmFibGUgYW5kIHBvcnQtcGFy aXR5LXByZXNlcnZhdGlvbi1lbmFibGU/IElzIHRoZXJlIGENCj4gcmVsYXRpb25zaGlwIGJldHdl ZW4gdGhlIHR3byB2YXJpYWJsZXMgdGhhdCBjb3VsZCBiZSBjYXB0dXJlZCBpbiB0aGUNCj4gbW9k ZWw/DQo+IA0KPiBBbGwgcmVmZXJlbmNlcyB0byBSRkMgc2hvdWxkIGJlIG1vdmVkIHVuZGVyIGEg cmVmZXJlbmNlIHNlY3Rpb24uDQoNCltNZWRdIFBsZWFzZSBjaGVjayAtMDYuIEFsbCByZWZlcmVu Y2VzIGFyZSB1bmRlciBhIHJlZmVyZW5jZSBzZWN0aW9uLiANCg0KDQogRm9yDQo+IGV4YW1wbGU6 DQo+IE9MRDoNCj4gICAgICAgbGVhZiB1ZHAtbGlmZXRpbWUgew0KPiAgICAgICAgICAgdHlwZSB1 aW50MzI7DQo+ICAgICAgICAgICB1bml0cyAic2Vjb25kcyI7DQo+ICAgICAgICAgICBkZWZhdWx0 IDEyMDsNCj4gICAgICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICAgICAgIlVEUCBpbmFj dGl2aXR5IHRpbWVvdXQgW1JGQzQ3ODddLiI7DQo+ICAgICAgIH0NCj4gTkVXOg0KPiAgICAgICBs ZWFmIHVkcC1saWZldGltZSB7DQo+ICAgICAgICAgICB0eXBlIHVpbnQzMjsNCj4gICAgICAgICAg IHVuaXRzICJzZWNvbmRzIjsNCj4gICAgICAgICAgIGRlZmF1bHQgMTIwOw0KPiAgICAgICAgICAg ZGVzY3JpcHRpb24NCj4gICAgICAgICAgICAgICAiVURQIGluYWN0aXZpdHkgdGltZW91dC7igJw7 DQo+ICAgICAgICAgICByZWZlcmVuY2UNCj4gICAgICAgICAgICAg4oCcW1JGQzQ3ODddLuKAnTsN Cj4gICAgICAgfQ0KPiANCj4gQSBub3RlIHNob3VsZCBiZSBwcmVwYXJlZCBmb3IgdGhlIFJGQyBl ZGl0b3IgdG8gaW5kaWNhdGUgd2hhdCByZXZpc2lvbiB0aGUNCj4gbW9kZWwgc2hvdWxkIGZpbmFs bHkgY2FycnksIGFuZCB3aGF0IHRoZSBkZXNjcmlwdGlvbi9yZWZlcmVuY2Ugc3RhdGVtZW50DQo+ IGluIHRoZQ0KPiBtb2RlbCBzaG91bGQgbG9vayBsaWtlIHdoZW4gdGhlIGRvY3VtZW50IGlzIGZp bmFsbHkgcHVibGlzaGVkLiBTZWUNCj4gZXhhbXBsZXMgaW4NCj4gb3RoZXIgZHJhZnRzIHN1Y2gg YXMgZHJhZnQtaWV0Zi1uZXRjb25mLXplcm90b3VjaCBFZGl0b3JpYWwgTm90ZSBvbiB3aGF0DQo+ IHRvIGFkZC4NCj4gDQo+IFNwZWNpZmljIENvbW1lbnRzDQo+IA0KPiBUaGUgbmFtZSBvZiB0aGUg ZmlsZSBpbiB0aGUgbGluZSB3aXRoIDxDT0RFIEJFR0lOUz4gaXMgbWlzc2luZyB0aGUgLnlhbmcN Cj4gc3VmZml4DQo+IGluIHRoZSBmaWxlLiBXaGVuIGV4dHJhY3RlZCwgdGhlIGV4dHJhY3RlZCBm aWxlIHdpbGwgYmUgbWlzc2luZyB0aGUNCj4gc3VmZml4Lg0KPiBQbGVhc2UgYWRkIGl0LiBUaGlz IGxlYWRzIHRvIHRoZSBmb2xsb3dpbmcgZXJyb3IgZnJvbSB5YW5nbGludC4NCg0KW01lZF0gVGhp cyB3YXMgZml4ZWQgaW4gcHJldmlvdXMgdmVyc2lvbi4gDQoNCj4gDQo+IGlldGYtZHNsaXRlQDIw MTctMDEtMDMiIHdpdGhvdXQgZmlsZSBleHRlbnNpb24gLSB1bmtub3duIGZvcm1hdC4NCj4gDQo+ IEluIGdyb3VwaW5nIHBvcnQtbnVtYmVyLCBjb3VsZCB0aGUgcG9ydC1yYW5nZSBiZSBzb21ldGhp bmcgYXMgc2ltcGxlIGFzDQo+IA0KPiBjb250YWluZXIgcG9ydC1udW1iZXIgew0KPiAgIG11c3Qg 4oCcc3RhcnRpbmctcG9ydOKAnTsNCj4gICBsZWFmIHN0YXJ0aW5nLXBvcnQgew0KPiAgICAgdHlw ZSBpbmV0OnBvcnQtbnVtYmVyOw0KPiAgIH0NCj4gICBsZWFmIGVuZGluZy1wb3J0IHsNCj4gICAg IHR5cGUgaW5ldDpwb3J0LW51bWJlcjsNCj4gICB9DQo+IH0NCj4gDQo+IHdoZXJlIGlmIHRoZXJl IGlzIG5vIGVuZGluZy1wb3J0IGl0IGlzIGRlZW1lZCB0byBiZSBhIHNpbmdsZSBwb3J0LCBidXQg aWYNCj4gdGhlcmUNCj4gaXMgYSBlbmRpbmctcG9ydCBpcyBjb25zaWRlcmVkIHRvIGJlIGEgcmFu Z2U/DQoNCltNZWRdIFRoaXMgZG9lcyBub3QgYXBwbHkgZm9yIC0wNi4NCg0KPiANCj4gVGhlIGxp c3QgdHJhbnNwb3J0LXByb3RvY29sIGhhcyBvbmUgbGVhZiB3aGljaCBpcyB0aGUgdHJhbnNwb3J0 LXByb3RvY29sLQ0KPiBpZC4NCj4gV2h5IGRvZXMgdGhlIHNpbmdsZSBsZWFmLCB3aGljaCBpcyB0 aGUga2V5LCBuZWVkIHRvIGJlIGluc2lkZSBhIGxpc3Q/DQoNCltNZWRdIElkZW0gYXMgYWJvdmUu DQoNCj4gDQo+IExvZ2dpbmctaW5mbyBoYXMgYSBjaG9pY2Ugc3RhdGVtZW50IGZvciBwcm90b2Nv bC4gSXMgaXQgdGhhdCB0aGVyZSBjYW4gYmUNCj4gb25seQ0KPiBvbmUgY2hvaWNlIGZvciB0aGUg Zm9ybSBvZiBsb2dnaW5nPyBDb3VsZCBpdCBiZSBwb3NzaWJsZSB0aGF0IHVzZXJzIG1pZ2h0DQo+ IHdhbnQNCj4gdG8gZW5hYmxlIGJvdGggc3lzbG9nIGFuZCBpcGZpeD8NCg0KW01lZF0gSWRlbSBh cyBhYm92ZS4NCg0KPiANCj4gQSBweWFuZyBjb21waWxhdGlvbiBvZiB0aGUgbW9kZWwgd2l0aCDi gJRpZXRmIGFuZCDigJRsaW50IG9wdGlvbiB3YXMgY2xlYW4uDQo+IA0KPiBBIGlkbml0cyBydW4g b2YgdGhlIGRyYWZ0IHJldmVhbHMgc29tZSBpc3N1ZXMgd2l0aCBzcGFjaW5nIGFuZCByZWZlcmVu Y2VzLg0KPiBUaGUNCj4gb25lIHJlbGF0ZWQgdG8gc3BhY2luZyBhcmUgcGFydHMgb2YgdGhlIGRp YWdyYW0sIHdoaWNoIGNvbmZ1c2VzIGlkbml0cy4NCg0KW01lZF0gV2lsbCBkb3VibGUgY2hlY2sg dGhvc2UuIFRoYW5rcy4NCg0KPiANCj4gQ2hlY2tpbmcgbml0cyBhY2NvcmRpbmcgdG8gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaWQtaW5mby9jaGVja2xpc3QgOg0KPiAgIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiAtLS0tDQo+IA0KPiAgICoqIFRoZXJlIGFyZSA1IGluc3RhbmNlcyBvZiB0b28gbG9uZyBsaW5l cyBpbiB0aGUgZG9jdW1lbnQsIHRoZSBsb25nZXN0DQo+IG9uZQ0KPiAgICAgIGJlaW5nIDMgY2hh cmFjdGVycyBpbiBleGNlc3Mgb2YgNzIuDQo+IA0KPiAgID09IFRoZXJlIGFyZSAyIGluc3RhbmNl cyBvZiBsaW5lcyB3aXRoIG5vbi1SRkM2ODkwLWNvbXBsaWFudCBJUHY0DQo+IGFkZHJlc3Nlcw0K PiAgICAgIGluIHRoZSBkb2N1bWVudC4gIElmIHRoZXNlIGFyZSBleGFtcGxlIGFkZHJlc3Nlcywg dGhleSBzaG91bGQgYmUNCj4gY2hhbmdlZC4NCj4gDQo+ICAgTWlzY2VsbGFuZW91cyB3YXJuaW5n czoNCj4gICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0tLQ0KPiANCj4gICA9PSBMaW5lIDE2MiBoYXMg d2VpcmQgc3BhY2luZzogJy4uLm9jb2wtaWQgICAgdWluLi4uJw0KPiANCj4gICA9PSBMaW5lIDIw NyBoYXMgd2VpcmQgc3BhY2luZzogJy4uLmFkZHJlc3MgICAgaW5lLi4uJw0KPiANCj4gICA9PSBM aW5lIDIxNSBoYXMgd2VpcmQgc3BhY2luZzogJy4uLmFkZHJlc3MgICAgaW5lLi4uJw0KPiANCj4g ICA9PSBMaW5lIDIzOCBoYXMgd2VpcmQgc3BhY2luZzogJy4uLnJ2YXRpb24gICAgYm9vLi4uJw0K PiANCj4gICA9PSBMaW5lIDI2MSBoYXMgd2VpcmQgc3BhY2luZzogJy4uLm9jb2wtaWQgICAgdWlu Li4uJw0KPiANCj4gICA9PSAoNSBtb3JlIGluc3RhbmNlcy4uLikNCj4gDQo+ICAgQ2hlY2tpbmcg cmVmZXJlbmNlcyBmb3IgaW50ZW5kZWQgc3RhdHVzOiBQcm9wb3NlZCBTdGFuZGFyZA0KPiAgIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiAtLS0tDQo+IA0KPiAgICAgIChTZWUgUkZDcyAzOTY3IGFuZCA0ODk3 IGZvciBpbmZvcm1hdGlvbiBhYm91dCB1c2luZyBub3JtYXRpdmUNCj4gcmVmZXJlbmNlcw0KPiAg ICAgIHRvIGxvd2VyLW1hdHVyaXR5IGRvY3VtZW50cyBpbiBSRkNzKQ0KPiANCj4gICA9PSBVbnVz ZWQgUmVmZXJlbmNlOiAnUkZDNzc1MycgaXMgZGVmaW5lZCBvbiBsaW5lIDE5ODgsIGJ1dCBubyBl eHBsaWNpdA0KPiAgICAgIHJlZmVyZW5jZSB3YXMgZm91bmQgaW4gdGhlIHRleHQNCj4gDQo+ICAg PT0gT3V0ZGF0ZWQgcmVmZXJlbmNlOiBBIGxhdGVyIHZlcnNpb24gKC0wNCkgZXhpc3RzIG9mDQo+ ICAgICAgZHJhZnQtYm91Y2FkYWlyLXBjcC15YW5nLTAzDQo+IA0KPiAgICAgIFN1bW1hcnk6IDEg ZXJyb3IgKCoqKSwgMCBmbGF3cyAofn4pLCA5IHdhcm5pbmdzICg9PSksIDEgY29tbWVudCAoLS0p Lg0KPiANCg0K From nobody Tue Oct 10 05:31:22 2017 Return-Path: X-Original-To: softwires@ietf.org Delivered-To: softwires@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAF01321CB; Tue, 10 Oct 2017 05:31:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: softwires@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150763867526.18348.12833159520045320876@ietfa.amsl.com> Date: Tue, 10 Oct 2017 05:31:15 -0700 Archived-At: Subject: [Softwires] I-D Action: draft-ietf-softwire-dslite-yang-07.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.22 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 12:31:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires WG of the IETF. Title : YANG Data Modules for the DS-Lite Authors : Mohamed Boucadair Christian Jacquenet Senthil Sivakumar Filename : draft-ietf-softwire-dslite-yang-07.txt Pages : 22 Date : 2017-10-10 Abstract: This document defines YANG modules for the DS-Lite Address Family Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-softwire-dslite-yang-07 https://datatracker.ietf.org/doc/html/draft-ietf-softwire-dslite-yang-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-dslite-yang-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 nobody Tue Oct 10 05:36:09 2017 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 5624113450E for ; Tue, 10 Oct 2017 05:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEaBJMJ8Zikk for ; Tue, 10 Oct 2017 05:36:06 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68452134DF6 for ; Tue, 10 Oct 2017 05:35:31 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 41B2B1C0461 for ; Tue, 10 Oct 2017 14:35:30 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 282F7180050 for ; Tue, 10 Oct 2017 14:35:30 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0361.001; Tue, 10 Oct 2017 14:35:29 +0200 From: To: "softwires@ietf.org" Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-dslite-yang-07.txt Thread-Index: AQHTQcOwCNXLjCizc0eT7fBDTRdl0KLdBKwQ Date: Tue, 10 Oct 2017 12:35:29 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A051BE6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <150763867526.18348.12833159520045320876@ietfa.amsl.com> In-Reply-To: <150763867526.18348.12833159520045320876@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-yang-07.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 12:36:07 -0000 Dear all, This version integrates some of the comments received from the yangdoctors.= =20 The document is IMO ready for a WG LC. Cheers, Med > -----Message d'origine----- > De=A0: Softwires [mailto:softwires-bounces@ietf.org] De la part de intern= et- > drafts@ietf.org > Envoy=E9=A0: mardi 10 octobre 2017 14:31 > =C0=A0: i-d-announce@ietf.org > Cc=A0: softwires@ietf.org > Objet=A0: [Softwires] I-D Action: draft-ietf-softwire-dslite-yang-07.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Softwires WG of the IETF. >=20 > Title : YANG Data Modules for the DS-Lite > Authors : Mohamed Boucadair > Christian Jacquenet > Senthil Sivakumar > Filename : draft-ietf-softwire-dslite-yang-07.txt > Pages : 22 > Date : 2017-10-10 >=20 > Abstract: > This document defines YANG modules for the DS-Lite Address Family > Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements . >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-yang/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-softwire-dslite-yang-07 > https://datatracker.ietf.org/doc/html/draft-ietf-softwire-dslite-yang-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-dslite-yang-07 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From nobody Tue Oct 10 08:03:50 2017 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 60F8C134E3A for ; Tue, 10 Oct 2017 08:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62XAEc4fubkq for ; Tue, 10 Oct 2017 08:03:42 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83986134E26 for ; Tue, 10 Oct 2017 08:02:13 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 60F9C206D3 for ; Tue, 10 Oct 2017 17:02:12 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 48F9C1A0063 for ; Tue, 10 Oct 2017 17:02:12 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0361.001; Tue, 10 Oct 2017 17:02:11 +0200 From: To: "softwires@ietf.org" Thread-Topic: I-D Action: draft-ietf-softwire-mesh-multicast-18.txt Thread-Index: AQHTNcWqCHM3khhDj0eVF/SH4OzCdqLdRY/A Date: Tue, 10 Oct 2017 15:02:11 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A051DB7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <150632010531.5045.18248868226186033084@ietfa.amsl.com> In-Reply-To: <150632010531.5045.18248868226186033084@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-mesh-multicast-18.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 15:03:49 -0000 Dear all,=20 FWIW, you may find some comments https://github.com/boucadair/IETF-Drafts-R= eviews/raw/master/draft-ietf-softwire-mesh-multicast-18-rev%20Med.doc=20 I do still think that this document should be positioned as an applicabilit= y statement of RFC8114 for the full mesh scenario. Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: lundi 25 septembre 2017 08:15 > =C0=A0: i-d-announce@ietf.org > Cc=A0: softwires@ietf.org > Objet=A0: I-D Action: draft-ietf-softwire-mesh-multicast-18.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Softwires WG of the IETF. >=20 > Title : Softwire Mesh Multicast > Authors : Mingwei Xu > Yong Cui > Jianping Wu > Shu Yang > Chris Metz > Greg Shepherd > Filename : draft-ietf-softwire-mesh-multicast-18.txt > Pages : 19 > Date : 2017-09-24 >=20 > Abstract: > The Internet needs to support IPv4 and IPv6 packets. Both address > families and their related protocol suites support multicast of the > single-source and any-source varieties. During IPv6 transition, > there will be scenarios where a backbone network running one IP > address family internally (referred to as internal IP or I-IP), while > the attached client networks running another IP address family > (referred to as external IP or E-IP). The I-IP backbone should offer > both unicast and multicast transit services to the client E-IP > networks. >=20 > Softwire Mesh is a solution providing E-IP unicast and multicast > support across an I-IP backbone. This document describes the > mechanism for supporting Internet-style multicast across a set of > E-IP and I-IP networks supporting softwire mesh. We focus on IPv4- > over-IPv6 scenario in this document, due to lack of real-world use > cases for IPv6-over-IPv4 scenario. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-multicast/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-softwire-mesh-multicast-18 > https://datatracker.ietf.org/doc/html/draft-ietf-softwire-mesh-multicast- > 18 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-mesh-multicast-18 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue Oct 10 19:40:24 2017 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 1595A13213D; Tue, 10 Oct 2017 19:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fV8o0FPdnrvj; Tue, 10 Oct 2017 19:40:20 -0700 (PDT) Received: from tsinghua.edu.cn (smtp31.tsinghua.edu.cn [101.6.4.55]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5A7124207; Tue, 10 Oct 2017 19:40:19 -0700 (PDT) Received: from [10.129.163.93] (unknown [58.200.129.136]) by app-2 (Coremail) with SMTP id EAQGZQCHj1eMhN1ZSWyOAA--.1736S4; Wed, 11 Oct 2017 10:40:17 +0800 (CST) From: Yong Cui Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Oct 2017 10:40:16 +0800 Message-Id: Cc: Ian Farrer , draft-ietf-softwire-map-mib@ietf.org, Yong Cui To: softwires@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-CM-TRANSID: EAQGZQCHj1eMhN1ZSWyOAA--.1736S4 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUUYW7AC8VAFwI0_Gr0_Xr1l1xkIjI8I6I8E 6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l82xGYIkIc2x26280x7IE14 v26r18M28IrcIa0xkI8VCY1x0267AKxVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xG Y2AK021l84ACjcxK6xIIjxv20xvE14v26w1j6s0DM28EF7xvwVC0I7IYx2IY6xkF7I0E14 v26r4UJVWxJr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7CjxVAF wI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2 WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkE bVWUJVW8JwACjcxG0xvY0x0EwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1lc2xSY4AK67 AK6r4UMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAF wI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc4 0Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AK xVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr0_Gr 1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjfUOD7aUUUU U X-CM-SenderInfo: 5fxl50tqj632xlqjx3vdohv3gofq/ Archived-At: Subject: [Softwires] WGLC for draft-ietf-softwire-map-mib-10 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2017 02:40:23 -0000 Hi folks, The authors believe the document, Definitions of Managed Objects for = MAP-E (draft-ietf-softwire-map-mib-10), is mature for advancement. We = are now issuing a working group last call for it. Please send your comments, either for or against, to the WG mailing = list. The WGLC will end on Oct. 24, 2017. Thanks, Yong & Ian= From nobody Tue Oct 17 10:55:48 2017 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 65916132D4E for ; Tue, 17 Oct 2017 10:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ruTRF-uavaS for ; Tue, 17 Oct 2017 10:55:40 -0700 (PDT) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9E013217D for ; Tue, 17 Oct 2017 10:55:39 -0700 (PDT) Received: from localhost.localdomain (imgmt2.lax.icann.org [10.32.11.180]) by smtp01.icann.org (Postfix) with ESMTP id 1CEF7E0DF0 for ; Tue, 17 Oct 2017 17:55:39 +0000 (UTC) From: Marilia Hirano To: softwires@ietf.org Message-Id: <20171017175539.DB9E013217D@ietfa.amsl.com> Date: Tue, 17 Oct 2017 10:55:39 -0700 (PDT) Archived-At: Subject: [Softwires] The 2017 IANA annual survey is coming X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 17:55:42 -0000 Dear valued customer, We strive to continuously improve our delivery of the IANA functions. We have engaged Ebiquity, an independent research firm to run our 2017 customer survey and Judy.Bromley@ebiquity.com will send you an invitation to participate early next week. Ebiquity is committed to protecting the confidentiality of all respondents in line with the Code of Conduct of ESOMAR (a membership organization representing the interests of the data, research and insights profession at an international level). We appreciate your time and helping us improve the delivery of the IANA functions. If you have any questions, please contact me at marilia.hirano@iana.org. Yours faithfully, Marilia Hirano Manager, Continuous Improvement ICANN From nobody Tue Oct 24 00:54:46 2017 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 3BE72139680; Tue, 24 Oct 2017 00:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, TRACKER_ID=1.306, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkzQV5CyGwYF; Tue, 24 Oct 2017 00:54:42 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE48E13DCBB; Tue, 24 Oct 2017 00:54:41 -0700 (PDT) Received: from [192.168.1.129] ([80.159.240.8]) by mail.gmx.com (mrgmx002 [212.227.17.184]) with ESMTPSA (Nemesis) id 0LkOaJ-1dV6Nx3OLj-00cOrO; Tue, 24 Oct 2017 09:54:30 +0200 From: Ian Farrer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_388BB74F-7FD4-4D92-9A90-1930AE52ED6C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 24 Oct 2017 09:54:29 +0200 In-Reply-To: Cc: softwires@ietf.org, draft-ietf-softwire-map-mib@ietf.org To: Yong Cui References: X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:Gh/gRRRR84YR/4PcfLZh6azyZgibLXehMXeFYbEY4fmVsevU4gH KBGieSWZ+JZk66IeTmC4xl6cAyX1I3XAitlFEP92tk4UnDgMwJKAbKi+yYh5Yuzitgh6TJX zTamFwD2qWXMwjX8Eh0pjlidCdk8AC9rnKK4NVjje6l18IBSsRZMP9M0zNUgPagR4h5dVgM /r1fVIQhjGfqoKpJozBoA== X-UI-Out-Filterresults: notjunk:1;V01:K0:YuFYFodmAB0=:p72tzt/d00eh7651ekw4dO wXmoVRYjyypJ4bbyNriZEGfXoLZ80EJVDKj7MlETzqqgdNwkKhECR6K5UXceveE/IazlHTeZi Ub5Yzmq0o0BkWYJZs/8HDxAjTyb+4sLry1JB+wceWRyyKjVNa9sCT0LcosEC0syKe868Bhjw3 7EYRI8jX6EUf1yuMqYLvtDtLedjOZKHHuOYEAgJK/YcAoJihuq0JBwSdXEhIrJOKyra2evqn6 gfqgehrSusxHZzgNalIBYNRHkGNMRkqN09AUPDj4sOlknYJ8WP9AWZLO2BfAT5yV4jyQFq5fj xHwPeYwV6sNIOm6JjkQpg8gSANzeHKJbnmppg1LDdrbtClmfap79cJMZh+ziCNYPdmRh1DnUe FuzSVOmE6AWs7LyvfheoUC7lLm89uskm7ly24TTKBK5NO5SqVgZ0heAP/NK/Iep9MBcjpsf/W AtiUG/cd6ktnw2VkT4Ppsx+9uxlPImER4DoSvWiKZHLKGk620IMbQgSEDhXRXuEzyK/bM8w82 MU2qCUGxeqvhv9E30why/dcYqW/Zhl8ynZ4FPVOR4veadbxkEPESJwc4Xje1WdD63H37zFOSo htrxI7jc5KdCn0dVePofAOEJaEb6sBGS9qvnFFWg2bKwvmZ40fH8+wf3JZ9pfYy5xrcXdcJqt /JS5Pimid6VpZqOlcRsi1Bq9CoNOF/QBdN3ZDDA0snEipcqgx/1OLYiSfdHuG0EofdAauMaGG RYuykzdYkSWTxhtGZsAHGGQtKnCm9q927vSfFIQGrPqOL3VV53ruL5uBhwA2RyBlF1c9T+45Q +dhEG+1nNlvC94AORxpslEX0lY+oxKC/7Oph0WtGHkMjKRSnpk= Archived-At: Subject: Re: [Softwires] WGLC for draft-ietf-softwire-map-mib-10 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 07:54:45 -0000 --Apple-Mail=_388BB74F-7FD4-4D92-9A90-1930AE52ED6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I=E2=80=99ve done a fairly extensive review of v10 of the draft. = There=E2=80=99s quite a lot of comments, but nothing major. Thanks, Ian General Comments g1. 1, Introduction [if - RFC7597 only covers MAP-E. Translation is described in RFC7599.=20 I think that this text is carried over from when MAP E and T were both = in the same draft.] Suggested rewording for this section: "Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597] is a stateless, automatic tunnelling mechanism for providing an IPv4 = connectivity service to end-users over a service provider's IPv6 network. This document defines a portion of the Management Information Base (MIB) for use with monitoring MAP-E devices." --- g2. In the description for mapRuleIpv4Prefix, what is the = mapRuleIPv4PrefixType?=20 This is the only mention of this object in the whole document. --- g3. Section 7 - States that there are a list of objects and their = sensitivity / vulnerability, but the list that follows only names the objects. No = vulnerability information is included. =3D=3D=3D=3D=3D=3D=3D=3D Linguistic Comments l1. Abstract "This memo defines a portion of the Management Information Base (MIB) for using with network management protocols in the Internet community. In particular, it defines managed objects for MAP with encapsulation (MAP-E)." This doesn't read very clearly. A suggested rewording: This memo defines a portion of the Management Information Base (MIB) for Mapping Address and Port with encapsulation (MAP-E) for use with network management protocols. --- l2. 4 - Structure of the MIB Module The term 'MAP specification[RFC7597]' is used several times in the = section and it is redundant. Suggest that just [RFC7597] is used.=20 --- l3. The first sentence repeats what has already been said in the abstract and introduction. Suggest it is removed. --- l4. The text states that it relies on 'several parts of the IF-MIB'. Can you = provide more information about which parts and how they are used --- l5. 4.1.1 The mapRule Subtree The mapRule subtree describes managed objects used for managing the multiple mapping rules in the MAP encapsulation mode. s/the MAP encapsulation mode./MAP-E/ --- l6. 4.1.2 The mapSecurityCheck Subtree The mapSecurityCheck subtree is to statistic the number of invalid packets that have been identified. =20 s/is to statistic/provides statistics for/ --- l7. For clarity, I suggest that: - The Border Relay (BR) will perform a validation of the consistency of the source IPv6 address and destination IPv6 address for the packet using Basic Mapping Rule (BMR). is replaced with: The Border Relay (BR) will validates the received packet's source=20 IPv6 address against the configured MAP domain rule and the = destination IPv6 address against the configured BR IPv6 address. --- l8. - The Map node... s/Map/MAP/ --- 5. Definitions l9. DESCRIPTION "The MIB module is defined for management of objects in the MAP-E BRs or CEs." s/in the/for/ --- l10. DESCRIPTION "It represents the PSID represented in the hexadecimal version so as to display it more clearly." "Indicates that the PSID is represented as hexidecimal for clarity" --- l11. DESCRIPTION "This enumeration describes the type of the mapping rule. It defines tree types of mapping rules here: s/This enumeration describes/Enumerates/ --- l12. DESCRIPTION "The (conceptual) table containing rule Information of specific mapping rule. It can also be used for row creation." s/Information of/information for a/ --- l13. DESCRIPTION "The IPv6 prefix defined in mapping rule which will be assigned to CE. The address type is given by mapRuleIPv6PrefixType." s/in mapping rule which will be assigned to CE./in the mapping rule = which will be assigned to the CE./ --- l14. DESCRIPTION "The length of the IPv6 prefix defined in the mapping rule. As a parameter for mapping rule, it will be also assigned to CE." Replace with: "The length of the IPv6 prefix defined in the mapping rule that is = assigned to the CE." --- l15. mapRuleIPv4Prefix DESCRIPTION " The IPv4 prefix defined in mapping rule which will be assigned to CE. The address type is given by mapRuleIPv4PrefixType." s/The IPv4 prefix defined in mapping rule which will be assigned to CE./The IPv4 prefix defined in the mapping rule which will = be assigned to the CE./ --- l15. mapRuleIPv4PrefixLen DESCRIPTION "The length of the IPv4 prefix defined in the mapping rule. As a parameter for mapping rule, it will be also assigned to CE." Replace with: "The length of the IPv4 prefix defined in the mapping rule that is = assigned to the CE." --- l16. mapRuleType DESCRIPTION "It represents the type of the mapping rule. The value of 1 means it is a bmr, the value 2 means it is a fmr, the value 3 means that the bmr is also a fmr for mesh mode." Replace with: "Indicates the type of mapping rule. '1' represents a BMR. '2' = represents an FMR and '3' is for a BMR which is also an FMR for mesh mode." --- l17. mapSecurityCheckTable DESCRIPTION "The (conceptual) table containing information on MAP security checks. This table can be used to statistic the number of invalid packets that been identified." s/to statistic the number of invalid packets that been identified./for statistics on the number of invalid packets that have been identified./ --- l18. mapSecurityCheckEntry DESCRIPTION "Each entry in this table contains the information on a particular MAP SecurityCheck." s/contains the information/contains information/ --- l19. mapSecurityCheckInvalidv4 DESCRIPTION "The Map node (CE and BR) will check that the received packets'source IPv4 address and port is in the range derived from matching MAP Rule.So this object indicate the number of the invalid IPv4 packets received by the MAP domain." Replace with: "Indicates the number of received IPv4 packets which do not have=20 a payload source IPv4 address or port within the range defined in the=20= matching MAP rule." --- l20. mapSecurityCheckInvalidv6 DESCRIPTION "The BR will perform a validation of the consistency of the source IPv6 address and destination IPv6 address for the packet using Basic Mapping Rule (BMR). So this object indicate the number of the invalid IPv6 packets received by the BR." Replace with: "Indicates the number of received IPv6 packets which do not have=20 a source or destination IPv6 address matching a Basic Mapping Rule." --- l21. mapMIBRuleGroup DESCRIPTION " The collection of this objects are used to give the information of mapping rules in MAP-E." Replace with: "The group of objects used to describe the MAP-E mapping rule." --- l22. mapMIBSecurityGroup DESCRIPTION " The collection of this objects are used to give the information on MAP security checks." Replace with: "The group of objects used to provide information on the MAP-E security = checks." --- l23. Section 7 Security Considerations s/(for example by using IPSec), even then, there is no control/ (for example by using IPSec), there is no control/ --- idnits 2.15.00=20 /tmp/draft-ietf-softwire-map-mib-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): = --------------------------------------------------------------------------= -- No issues found here. Checking nits according to = https://www.ietf.org/id-info/1id-guidelines.txt: = --------------------------------------------------------------------------= -- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : = --------------------------------------------------------------------------= -- No issues found here. Miscellaneous warnings: = --------------------------------------------------------------------------= -- -- The document date (September 15, 2017) is 39 days in the past. Is = this intentional? Checking references for intended status: Proposed Standard = --------------------------------------------------------------------------= -- (See RFCs 3967 and 4897 for information about using normative = references to lower-maturity documents in RFCs) =3D=3D Unused Reference: 'RFC7598' is defined on line 636, but no = explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 1 warning (=3D=3D), 2 = comments (--). Run idnits with the --verbose option for more detailed information = about the items above. = --------------------------------------------------------------------------= ------ =20 > On 11. Oct 2017, at 04:40, Yong Cui wrote: >=20 > Hi folks, >=20 > The authors believe the document, Definitions of Managed Objects for = MAP-E (draft-ietf-softwire-map-mib-10), is mature for advancement. We = are now issuing a working group last call for it. >=20 > Please send your comments, either for or against, to the WG mailing = list. The WGLC will end on Oct. 24, 2017. >=20 >=20 > Thanks, >=20 > Yong & Ian --Apple-Mail=_388BB74F-7FD4-4D92-9A90-1930AE52ED6C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,

I=E2=80=99ve done a fairly extensive = review of v10 of the draft. There=E2=80=99s quite a lot of comments, but = nothing major.

Thanks,
Ian


General Comments

g1.
1, = Introduction
[if - RFC7597 only covers MAP-E. = Translation is described in RFC7599. 
I think = that this text is carried over from when MAP E and T were both in = the
same draft.]

Suggested rewording for this = section:

"Mapping of Address and Port with Encapsulation (MAP-E) = [RFC7597] is a
stateless, automatic tunnelling = mechanism for providing an IPv4 connectivity
service = to end-users over a service provider's IPv6 network.

This document defines a = portion of the Management Information Base
(MIB) = for use with monitoring MAP-E devices."
---
g2.
In the description for = mapRuleIpv4Prefix, what is the mapRuleIPv4PrefixType? 
This is the only mention of this object in the whole = document.
---
g3.
Section 7 - States that there are a list of objects and their = sensitivity /
vulnerability, but the list that = follows only names the objects. No vulnerability
information is included.
=3D=3D=3D=3D=3D=3D=3D=3D

Linguistic Comments



l1.
Abstract

"This memo defines a portion of the Management Information = Base (MIB)
for using with network management = protocols in the Internet
community.  In = particular, it defines managed objects for MAP
with = encapsulation (MAP-E)."

This doesn't read very clearly. A suggested = rewording:
This memo defines a portion of the = Management Information Base (MIB)
for Mapping = Address and Port with encapsulation (MAP-E) for use with
network management protocols.
---

l2.
4 - Structure of the MIB = Module

The = term 'MAP specification[RFC7597]' is used several times in the section = and
it is redundant. Suggest that just [RFC7597] is = used. 
---

l3.
The first = sentence repeats what has already been said in the abstract
and introduction. Suggest it is removed.
---

l4.
The text states that it relies on = 'several parts of the IF-MIB'. Can you provide
more = information about which parts and how they are used
---

l5.
4.1.1 The mapRule Subtree

The mapRule subtree = describes managed objects used for managing the
   multiple mapping rules in the MAP encapsulation = mode.

s/the = MAP encapsulation mode./MAP-E/
---

l6.
4.1.2 The mapSecurityCheck Subtree
The = mapSecurityCheck subtree is to statistic the number of invalid
   packets that have been identified. =  

s/is to = statistic/provides statistics for/
---

l7.
For clarity, I suggest that:
- The = Border Relay (BR) will perform a validation of the consistency
  of the source IPv6 address and destination IPv6 = address for the
  packet using Basic Mapping = Rule (BMR).

is = replaced with:
  The Border Relay (BR) will = validates the received packet's source 
  = IPv6 address against the configured MAP domain rule and the = destination
  IPv6 address against the = configured BR IPv6 address.
---

l8.
-= The Map node...
s/Map/MAP/
---

5. Definitions

l9.
DESCRIPTION
      "The MIB module is defined for = management of objects in the
      =  MAP-E BRs or CEs."

s/in the/for/
---
l10.
DESCRIPTION
    "It represents = the PSID represented in the hexadecimal version
     so as to display it more = clearly."

 =   "Indicates that the PSID is represented as hexidecimal for = clarity"
---

l11.
DESCRIPTION
   "This = enumeration describes the type of the mapping rule. It
    defines tree types of mapping rules = here:

s/This = enumeration describes/Enumerates/
---

l12.
DESCRIPTION
   "The = (conceptual) table containing rule Information of
    specific mapping rule. It can also be used for = row
    creation."
s/Information of/information for = a/
---

l13.
DESCRIPTION
   "The IPv6 prefix defined in mapping rule which = will be
    assigned to CE. The address = type is given by
    = mapRuleIPv6PrefixType."

s/in mapping rule which will be assigned to CE./in the = mapping rule which
will be assigned to the = CE./
---

l14.
DESCRIPTION
   "The length of = the IPv6 prefix defined in the mapping rule.
  =   As a parameter for mapping rule, it will be also = assigned
    to CE."

Replace with:
   "The length of the IPv6 prefix defined in the = mapping rule that is assigned
   to the = CE."
---

l15.
mapRuleIPv4Prefix
DESCRIPTION
   " The IPv4 prefix defined in mapping rule which = will be
     assigned to CE. The = address type is given by
    =  mapRuleIPv4PrefixType."

s/The IPv4 prefix defined in mapping = rule which will be
  assigned to CE./The IPv4 = prefix defined in the mapping rule which will be
    assigned to the CE./
---

l15.
mapRuleIPv4PrefixLen
DESCRIPTION
   "The length of = the IPv4 prefix defined in the mapping
  =   rule. As a parameter for mapping rule, it will be also
    assigned to CE."

Replace with:
 =   "The length of the IPv4 prefix defined in the mapping rule that = is assigned
to the CE."
---

l16.
mapRuleType
DESCRIPTION
   "It represents = the type of the mapping rule. The value of
  =   1 means it is a bmr, the value 2 means it is a fmr, the
    value 3 means that the bmr is also a fmr for = mesh mode."

Replace with:
    "Indicates = the type of mapping rule. '1' represents a BMR. '2' represents
    an FMR and '3' is for a BMR which is also an = FMR for mesh mode."
---

l17.
mapSecurityCheckTable
DESCRIPTION
   "The = (conceptual) table containing information on
  =   MAP security checks. This table can be used to = statistic
    the number of invalid = packets that been identified."

s/to statistic the number of invalid = packets that been identified./for
statistics on the = number of invalid packets that have been identified./
---

l18.
mapSecurityCheckEntry
DESCRIPTION
   "Each entry in = this table contains the information on a
  =   particular MAP SecurityCheck."

s/contains the information/contains = information/
---

l19.
mapSecurityCheckInvalidv4
DESCRIPTION
   "The Map node = (CE and BR) will check that the received
  =   packets'source IPv4 address and port is in the range
    derived from matching MAP Rule.So this object = indicate
    the number of the invalid = IPv4 packets received by the
    MAP = domain."

Replace= with:
  "Indicates the number of received = IPv4 packets which do not have 
   a = payload source IPv4 address or port within the range defined in = the 
   matching MAP = rule."
---

l20.
mapSecurityCheckInvalidv6
DESCRIPTION
   "The BR will = perform a validation of the consistency
  =   of the source IPv6 address and destination IPv6 address
    for the packet using Basic Mapping Rule (BMR). = So this
    object indicate the number of = the invalid IPv6 packets
    received by = the BR."

Replace= with:
   "Indicates the number of = received IPv6 packets which do not have 
  =   a source or destination IPv6 address matching a Basic Mapping = Rule."
---

l21.
mapMIBRuleGroup
DESCRIPTION
   " The collection of this objects are used to = give the
    information of mapping rules = in MAP-E."

Replace with:
   "The group of = objects used to describe the MAP-E mapping rule."
---

l22.
mapMIBSecurityGroup
DESCRIPTION
" The collection of this = objects are used to give the
information on MAP = security checks."

Replace with:
"The group of objects used = to provide information on the MAP-E security checks."
---

l23.
Section 7 Security = Considerations

s/(for example by using IPSec), even then, there is no = control/
(for example by using IPSec), there is no = control/
---


idnits= 2.15.00=20 /tmp/draft-ietf-softwire-map-mib-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): = --------------------------------------------------------------------------= -- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: = --------------------------------------------------------------------------= -- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : = --------------------------------------------------------------------------= -- No issues found here. Miscellaneous warnings: = --------------------------------------------------------------------------= -- -- The document date (September 15, 2017) is 39 days in the past. Is = this intentional? Checking references for intended status: Proposed Standard = --------------------------------------------------------------------------= -- (See RFCs 3967 and 4897 for information about using normative = references to lower-maturity documents in RFCs) =3D=3D Unused Reference: 'RFC7598' is defined on line 636, but no = explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 1 warning (=3D=3D), 2 = comments (--). Run idnits with the --verbose option for more detailed information = about the items above. = --------------------------------------------------------------------------= ------

  



On = 11. Oct 2017, at 04:40, Yong Cui <cuiyong@tsinghua.edu.cn> wrote:

Hi = folks,

The authors believe the document, = Definitions of Managed Objects for MAP-E = (draft-ietf-softwire-map-mib-10), is mature for advancement. We are now = issuing a working group last call for it.

Please send your comments, either for or against, to the WG = mailing list. The WGLC will end on Oct. 24, 2017.


Thanks,

Yong = & Ian

= --Apple-Mail=_388BB74F-7FD4-4D92-9A90-1930AE52ED6C-- From nobody Wed Oct 25 08:11:18 2017 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 EB7EA139950; Wed, 25 Oct 2017 02:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.594 X-Spam-Level: X-Spam-Status: No, score=-0.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkSu1UJs2F5K; Wed, 25 Oct 2017 02:29:15 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id E564A139680; Wed, 25 Oct 2017 02:29:13 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.248]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0CZoOheWfBZa8kWAA--.46199S3; Wed, 25 Oct 2017 17:29:02 +0800 (CST) From: "Yu Fu" To: Cc: , , "'Yong Cui'" References: In-Reply-To: Date: Wed, 25 Oct 2017 17:28:59 +0800 Message-ID: <000f01d34d73$b0121830$10364890$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01D34DB6.BE355830" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdNMnW5rGD2PdjJCQAGK/EsTljXuGgAuzRdw Content-Language: zh-cn X-CM-TRANSID: AQAAf0CZoOheWfBZa8kWAA--.46199S3 X-Coremail-Antispam: 1UD129KBjvJXoW3ZFWUXr1UGw48tF4DWF15Arb_yoWkCF13pF Wft3ZxJFyDJr17Gr4kJw48XrySyrs5tr43JrnrKw18Cwn8Cryvyr47Kr1rZFWDGry8Cw1j vrWjvr15WF1DAFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUPvb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAYj202 j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG04xIwI0_Jr0_Gr1l5I8CrV CF0I0E4I0vr24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvj eVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc2 xSY4AK67AK6r4fMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E 5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAV WUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY 1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aV AFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuY vjxUgJ5rDUUUU X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: X-Mailman-Approved-At: Wed, 25 Oct 2017 08:11:17 -0700 Subject: Re: [Softwires] WGLC for draft-ietf-softwire-map-mib-10 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 09:29:19 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0010_01D34DB6.BE355830 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Ian, =20 Thanks for your thorough comments. Please see my reply inline. =20 >g1. >1, Introduction >[if - RFC7597 only covers MAP-E. Translation is described in RFC7599.=20 >I think that this text is carried over from when MAP E and T were both = in the >same draft.] =20 >Suggested rewording for this section: =20 >"Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597] is a >stateless, automatic tunnelling mechanism for providing an IPv4 = connectivity >service to end-users over a service provider's IPv6 network. =20 >This document defines a portion of the Management Information Base >(MIB) for use with monitoring MAP-E devices." =20 [Yu]:Done =20 >g2. >In the description for mapRuleIpv4Prefix, what is the = mapRuleIPv4PrefixType?=20 >This is the only mention of this object in the whole document. =20 [Yu]: Sorry, we had delete the definition of mapRuleIPv4PrefixType since = 08 version. I will delete=20 the description for this. =20 >g3. >Section 7 - States that there are a list of objects and their = sensitivity / >vulnerability, but the list that follows only names the objects. No = vulnerability >information is included. =20 [Yu]: It has a description as followed : =E2=80=9CSome of the readable objects in this MIB module (i.e., objects = with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP=E2=80=9D =E2=80=9CObjects that reveal rule information of the MAP Domain: Various = objects can reveal the rule information of the map domain. A curious outsider could monitor these to assess the number of rules and the IPv6 prefix performed in this domain. Further, an intruder could use the information to guess the address-sharing ratios of the ISPs.=E2=80=9D =20 [Yu]: The objects in the list reveal the rule information and are = readable. So they are vulnerable. =20 >Linguistic Comments >idnits 2.15.00=20 =20 [Yu]: I accept all the comments and an updated version will be submitted = soon. =20 Thanks again =20 Cheers Yu =20 =20 =20 From: ianfarrer@gmx.com [mailto:ianfarrer@gmx.com]=20 Sent: Tuesday, October 24, 2017 3:54 PM To: Yong Cui Cc: softwires@ietf.org; draft-ietf-softwire-map-mib@ietf.org Subject: Re: WGLC for draft-ietf-softwire-map-mib-10 =20 Hi, =20 I=E2=80=99ve done a fairly extensive review of v10 of the draft. = There=E2=80=99s quite a lot of comments, but nothing major. =20 Thanks, Ian =20 =20 General Comments =20 g1. 1, Introduction [if - RFC7597 only covers MAP-E. Translation is described in RFC7599.=20 I think that this text is carried over from when MAP E and T were both = in the same draft.] =20 Suggested rewording for this section: =20 "Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597] is a stateless, automatic tunnelling mechanism for providing an IPv4 = connectivity service to end-users over a service provider's IPv6 network. =20 This document defines a portion of the Management Information Base (MIB) for use with monitoring MAP-E devices." --- g2. In the description for mapRuleIpv4Prefix, what is the = mapRuleIPv4PrefixType?=20 This is the only mention of this object in the whole document. --- g3. Section 7 - States that there are a list of objects and their = sensitivity / vulnerability, but the list that follows only names the objects. No = vulnerability information is included. =3D=3D=3D=3D=3D=3D=3D=3D =20 Linguistic Comments =20 =20 =20 l1. Abstract =20 "This memo defines a portion of the Management Information Base (MIB) for using with network management protocols in the Internet community. In particular, it defines managed objects for MAP with encapsulation (MAP-E)." =20 This doesn't read very clearly. A suggested rewording: This memo defines a portion of the Management Information Base (MIB) for Mapping Address and Port with encapsulation (MAP-E) for use with network management protocols. --- =20 l2. 4 - Structure of the MIB Module =20 The term 'MAP specification[RFC7597]' is used several times in the = section and it is redundant. Suggest that just [RFC7597] is used.=20 --- =20 l3. The first sentence repeats what has already been said in the abstract and introduction. Suggest it is removed. --- =20 l4. The text states that it relies on 'several parts of the IF-MIB'. Can you = provide more information about which parts and how they are used --- =20 l5. 4.1.1 The mapRule Subtree =20 The mapRule subtree describes managed objects used for managing the multiple mapping rules in the MAP encapsulation mode. =20 s/the MAP encapsulation mode./MAP-E/ --- =20 l6. 4.1.2 The mapSecurityCheck Subtree The mapSecurityCheck subtree is to statistic the number of invalid packets that have been identified. =20 =20 s/is to statistic/provides statistics for/ --- =20 l7. For clarity, I suggest that: - The Border Relay (BR) will perform a validation of the consistency of the source IPv6 address and destination IPv6 address for the packet using Basic Mapping Rule (BMR). =20 is replaced with: The Border Relay (BR) will validates the received packet's source=20 IPv6 address against the configured MAP domain rule and the = destination IPv6 address against the configured BR IPv6 address. --- =20 l8. - The Map node... s/Map/MAP/ --- =20 5. Definitions =20 l9. DESCRIPTION "The MIB module is defined for management of objects in the MAP-E BRs or CEs." =20 s/in the/for/ --- =20 l10. DESCRIPTION "It represents the PSID represented in the hexadecimal version so as to display it more clearly." =20 "Indicates that the PSID is represented as hexidecimal for clarity" --- =20 l11. DESCRIPTION "This enumeration describes the type of the mapping rule. It defines tree types of mapping rules here: =20 s/This enumeration describes/Enumerates/ --- =20 l12. DESCRIPTION "The (conceptual) table containing rule Information of specific mapping rule. It can also be used for row creation." =20 s/Information of/information for a/ --- =20 l13. DESCRIPTION "The IPv6 prefix defined in mapping rule which will be assigned to CE. The address type is given by mapRuleIPv6PrefixType." =20 s/in mapping rule which will be assigned to CE./in the mapping rule = which will be assigned to the CE./ --- =20 l14. DESCRIPTION "The length of the IPv6 prefix defined in the mapping rule. As a parameter for mapping rule, it will be also assigned to CE." =20 Replace with: "The length of the IPv6 prefix defined in the mapping rule that is = assigned to the CE." --- =20 l15. mapRuleIPv4Prefix DESCRIPTION " The IPv4 prefix defined in mapping rule which will be assigned to CE. The address type is given by mapRuleIPv4PrefixType." =20 s/The IPv4 prefix defined in mapping rule which will be assigned to CE./The IPv4 prefix defined in the mapping rule which will = be assigned to the CE./ --- =20 l15. mapRuleIPv4PrefixLen DESCRIPTION "The length of the IPv4 prefix defined in the mapping rule. As a parameter for mapping rule, it will be also assigned to CE." =20 Replace with: "The length of the IPv4 prefix defined in the mapping rule that is = assigned to the CE." --- =20 l16. mapRuleType DESCRIPTION "It represents the type of the mapping rule. The value of 1 means it is a bmr, the value 2 means it is a fmr, the value 3 means that the bmr is also a fmr for mesh mode." =20 Replace with: "Indicates the type of mapping rule. '1' represents a BMR. '2' = represents an FMR and '3' is for a BMR which is also an FMR for mesh mode." --- =20 l17. mapSecurityCheckTable DESCRIPTION "The (conceptual) table containing information on MAP security checks. This table can be used to statistic the number of invalid packets that been identified." =20 s/to statistic the number of invalid packets that been identified./for statistics on the number of invalid packets that have been identified./ --- =20 l18. mapSecurityCheckEntry DESCRIPTION "Each entry in this table contains the information on a particular MAP SecurityCheck." =20 s/contains the information/contains information/ --- =20 l19. mapSecurityCheckInvalidv4 DESCRIPTION "The Map node (CE and BR) will check that the received packets'source IPv4 address and port is in the range derived from matching MAP Rule.So this object indicate the number of the invalid IPv4 packets received by the MAP domain." =20 Replace with: "Indicates the number of received IPv4 packets which do not have=20 a payload source IPv4 address or port within the range defined in the = matching MAP rule." --- =20 l20. mapSecurityCheckInvalidv6 DESCRIPTION "The BR will perform a validation of the consistency of the source IPv6 address and destination IPv6 address for the packet using Basic Mapping Rule (BMR). So this object indicate the number of the invalid IPv6 packets received by the BR." =20 Replace with: "Indicates the number of received IPv6 packets which do not have=20 a source or destination IPv6 address matching a Basic Mapping Rule." --- =20 l21. mapMIBRuleGroup DESCRIPTION " The collection of this objects are used to give the information of mapping rules in MAP-E." =20 Replace with: "The group of objects used to describe the MAP-E mapping rule." --- =20 l22. mapMIBSecurityGroup DESCRIPTION " The collection of this objects are used to give the information on MAP security checks." =20 Replace with: "The group of objects used to provide information on the MAP-E security = checks." --- =20 l23. Section 7 Security Considerations =20 s/(for example by using IPSec), even then, there is no control/ (for example by using IPSec), there is no control/ --- =20 =20 idnits 2.15.00=20 =20 /tmp/draft-ietf-softwire-map-mib-10.txt: =20 Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): = -------------------------------------------------------------------------= --- =20 No issues found here. =20 Checking nits according to = https://www.ietf.org/id-info/1id-guidelines.txt: = -------------------------------------------------------------------------= --- =20 No issues found here. =20 Checking nits according to https://www.ietf.org/id-info/checklist : = -------------------------------------------------------------------------= --- =20 No issues found here. =20 Miscellaneous warnings: = -------------------------------------------------------------------------= --- =20 -- The document date (September 15, 2017) is 39 days in the past. Is = this intentional? =20 =20 Checking references for intended status: Proposed Standard = -------------------------------------------------------------------------= --- =20 (See RFCs 3967 and 4897 for information about using normative = references to lower-maturity documents in RFCs) =20 =3D=3D Unused Reference: 'RFC7598' is defined on line 636, but no = explicit reference was found in the text =20 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) =20 =20 Summary: 0 errors (**), 0 flaws (~~), 1 warning (=3D=3D), 2 = comments (--). =20 Run idnits with the --verbose option for more detailed information = about the items above. -------------------------------------------------------------------------= ------- =20 =20 =20 =20 =20 =20 On 11. Oct 2017, at 04:40, Yong Cui wrote: =20 Hi folks, The authors believe the document, Definitions of Managed Objects for = MAP-E (draft-ietf-softwire-map-mib-10), is mature for advancement. We = are now issuing a working group last call for it. Please send your comments, either for or against, to the WG mailing = list. The WGLC will end on Oct. 24, 2017. Thanks, Yong & Ian =20 ------=_NextPart_000_0010_01D34DB6.BE355830 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Ian,

 

Thanks for your thorough comments. Please see my reply = inline.

 

>g1.

>1, Introduction

>[if - RFC7597 only covers MAP-E. Translation is described in = RFC7599. 

>I think that this text is carried over from when MAP E and T were = both in the

>same draft.]

 

>Suggested rewording for this section:

 

>"Mapping of Address and Port with Encapsulation (MAP-E) = [RFC7597] is a

>stateless, automatic tunnelling mechanism for providing an IPv4 = connectivity

>service to end-users over a service provider's IPv6 = network.

 

>This document defines a portion of the Management Information = Base

>(MIB) for use with monitoring MAP-E = devices."

 

[Yu]:Done

 

>g2.

>In the description for mapRuleIpv4Prefix, what is the = mapRuleIPv4PrefixType? 

>This is the only mention of this object in the whole = document.

 

[Yu]: Sorry, we had delete the definition of mapRuleIPv4PrefixType = since 08 version. I will delete

the description for this.

 

>g3.

>Section 7 - States that there are a list of objects and their = sensitivity /

>vulnerability, but the list that follows only names the objects. = No vulnerability

>information is included.

 

[Yu]: It has a description as followed :

=E2=80=9CSome of the readable objects in this MIB module (i.e., = objects with a

=C2=A0=C2=A0 MAX-ACCESS other than not-accessible) may be considered = sensitive or

=C2=A0=C2=A0 vulnerable in some network environments. It is thus = important to

=C2=A0=C2=A0 control even GET and/or NOTIFY access to these objects = and possibly

=C2=A0=C2=A0 to even encrypt the values of these objects when sending = them over

=C2=A0=C2=A0 the network via SNMP=E2=80=9D

=E2=80=9CObjects that reveal rule information of the MAP Domain: = Various objects can reveal the

=C2=A0=C2=A0 rule information of the map domain.=C2=A0 A curious = outsider could monitor

=C2=A0=C2=A0 these to assess the number of rules and the IPv6 prefix = performed in

=C2=A0=C2=A0 this domain.=C2=A0 Further, an intruder could use the = information to guess

=C2=A0=C2=A0 the address-sharing ratios of the = ISPs.=E2=80=9D

 

[Yu]: The objects in the list reveal the rule information and are = readable. So they are vulnerable.

 

>Linguistic Comments

>idnits 2.15.00

 

[Yu]: I accept all the comments and an updated version will be = submitted soon.

 

Thanks again

 

Cheers

Yu

 

 

 

From:= = ianfarrer@gmx.com [mailto:ianfarrer@gmx.com]
Sent: Tuesday, = October 24, 2017 3:54 PM
To: Yong Cui
Cc: = softwires@ietf.org; = draft-ietf-softwire-map-mib@ietf.org
Subject: Re: WGLC for = draft-ietf-softwire-map-mib-10

 

Hi,

 

I=E2=80=99ve done a fairly = extensive review of v10 of the draft. There=E2=80=99s quite a lot of = comments, but nothing major.

 

Thanks,

Ian

 

 

General = Comments

 

g1.

1, = Introduction

[if - RFC7597 only covers MAP-E. Translation is described = in RFC7599. 

I think that this text is carried = over from when MAP E and T were both in = the

same draft.]

 

Suggested rewording for this = section:

 

"Mapping of Address and Port = with Encapsulation (MAP-E) [RFC7597] is = a

stateless, automatic tunnelling mechanism for providing an = IPv4 connectivity

service to end-users over a service = provider's IPv6 network.

 

This document defines a portion of = the Management Information Base

(MIB) for use with monitoring MAP-E = devices."

---

g2.

In the description for = mapRuleIpv4Prefix, what is the = mapRuleIPv4PrefixType? 

This is the only mention of this = object in the whole document.

---

g3.

Section 7 - States that there are a = list of objects and their sensitivity = /

vulnerability, but the list that follows only names the = objects. No vulnerability

information is = included.

=3D=3D=3D=3D=3D=3D=3D=3D

 

Linguistic = Comments

 

 

 

l1.

Abstract

 

"This memo defines a portion = of the Management Information Base = (MIB)

for using with network management protocols in the = Internet

community.  In particular, it defines managed objects = for MAP

with encapsulation = (MAP-E)."

 

This doesn't read very clearly. A = suggested rewording:

This memo defines a portion of the = Management Information Base (MIB)

for Mapping Address and Port with = encapsulation (MAP-E) for use with

network management = protocols.

---

 

l2.

4 - Structure of the MIB = Module

 

The term 'MAP = specification[RFC7597]' is used several times in the section = and

it is redundant. Suggest that just [RFC7597] is = used. 

---

 

l3.

The first sentence repeats what has = already been said in the abstract

and introduction. Suggest it is = removed.

---

 

l4.

The text states that it relies on = 'several parts of the IF-MIB'. Can you = provide

more information about which parts and how they are = used

---

 

l5.

4.1.1 The mapRule = Subtree

 

The mapRule subtree describes = managed objects used for managing the

   multiple mapping rules = in the MAP encapsulation mode.

 

s/the MAP encapsulation = mode./MAP-E/

---

 

l6.

4.1.2 The mapSecurityCheck = Subtree

The mapSecurityCheck subtree is to statistic the number of = invalid

   packets that have been identified. =  

 

s/is to statistic/provides = statistics for/

---

 

l7.

For clarity, I suggest = that:

- The Border Relay (BR) will perform a validation of the = consistency

  of the source IPv6 address and destination IPv6 = address for the

  packet using Basic Mapping = Rule (BMR).

 

is replaced = with:

  The Border Relay (BR) will validates the received = packet's source 

  IPv6 address against the = configured MAP domain rule and the = destination

  IPv6 address against the configured BR IPv6 = address.

---

 

l8.

- The Map = node...

s/Map/MAP/

---

 

5. = Definitions

 

l9.

DESCRIPTION

      "The MIB = module is defined for management of objects in = the

       MAP-E BRs or = CEs."

 

s/in = the/for/

---

 

l10.

DESCRIPTION

    "It represents = the PSID represented in the hexadecimal = version

     so as to display it more = clearly."

 

    "Indicates that = the PSID is represented as hexidecimal for = clarity"

---

 

l11.

DESCRIPTION

   "This enumeration = describes the type of the mapping rule. = It

    defines tree types of mapping rules = here:

 

s/This enumeration = describes/Enumerates/

---

 

l12.

DESCRIPTION

   "The (conceptual) = table containing rule Information of

    specific mapping = rule. It can also be used for row

    = creation."

 

s/Information of/information for = a/

---

 

l13.

DESCRIPTION

   "The IPv6 prefix = defined in mapping rule which will be

    assigned to CE. The = address type is given by

    = mapRuleIPv6PrefixType."

 

s/in mapping rule which will be = assigned to CE./in the mapping rule = which

will be assigned to the = CE./

---

 

l14.

DESCRIPTION

   "The length of = the IPv6 prefix defined in the mapping = rule.

    As a parameter for mapping rule, it will be = also assigned

    to = CE."

 

Replace = with:

   "The length of the IPv6 prefix defined in = the mapping rule that is assigned

   to the = CE."

---

 

l15.

mapRuleIPv4Prefix

DESCRIPTION

   " The IPv4 prefix = defined in mapping rule which will be

     assigned to CE. = The address type is given by

    =  mapRuleIPv4PrefixType."

 

s/The IPv4 prefix defined in = mapping rule which will be

  assigned to CE./The IPv4 = prefix defined in the mapping rule which will = be

    assigned to the = CE./

---

 

l15.

mapRuleIPv4PrefixLen

DESCRIPTION

   "The length of = the IPv4 prefix defined in the = mapping

    rule. As a parameter for mapping rule, it = will be also

    assigned to = CE."

 

Replace = with:

    "The length of the IPv4 prefix defined = in the mapping rule that is assigned

to the = CE."

---

 

l16.

mapRuleType

DESCRIPTION

   "It represents = the type of the mapping rule. The value = of

    1 means it is a bmr, the value 2 means it is = a fmr, the

    value 3 means that the bmr is also a fmr for = mesh mode."

 

Replace = with:

    "Indicates the type of mapping rule. '1' = represents a BMR. '2' represents

    an FMR and '3' is for = a BMR which is also an FMR for mesh = mode."

---

 

l17.

mapSecurityCheckTable

DESCRIPTION

   "The (conceptual) = table containing information on

    MAP security checks. = This table can be used to statistic

    the number of invalid = packets that been identified."

 

s/to statistic the number of = invalid packets that been = identified./for

statistics on the number of invalid = packets that have been identified./

---

 

l18.

mapSecurityCheckEntry

DESCRIPTION

   "Each entry in = this table contains the information on = a

    particular MAP = SecurityCheck."

 

s/contains the information/contains = information/

---

 

l19.

mapSecurityCheckInvalidv4

DESCRIPTION

   "The Map node (CE = and BR) will check that the received

    packets'source IPv4 = address and port is in the range

    derived from matching = MAP Rule.So this object indicate

    the number of the = invalid IPv4 packets received by the

    MAP = domain."

 

Replace = with:

  "Indicates the number of received IPv4 packets = which do not have 

   a payload source IPv4 = address or port within the range defined in = the 

   matching MAP = rule."

---

 

l20.

mapSecurityCheckInvalidv6

DESCRIPTION

   "The BR will = perform a validation of the = consistency

    of the source IPv6 address and destination = IPv6 address

    for the packet using Basic Mapping Rule = (BMR). So this

    object indicate the = number of the invalid IPv6 packets

    received by the = BR."

 

Replace = with:

   "Indicates the number of received IPv6 = packets which do not have 

    a source or = destination IPv6 address matching a Basic Mapping = Rule."

---

 

l21.

mapMIBRuleGroup

DESCRIPTION

   " The collection = of this objects are used to give the

    information of = mapping rules in MAP-E."

 

Replace = with:

   "The group of objects used to describe = the MAP-E mapping rule."

---

 

l22.

mapMIBSecurityGroup

DESCRIPTION

" The collection of this = objects are used to give the

information on MAP security = checks."

 

Replace = with:

"The group of objects used to provide information on = the MAP-E security checks."

---

 

l23.

Section 7 Security = Considerations

 

s/(for example by using IPSec), = even then, there is no control/

(for example by using IPSec), there = is no control/

---

 

 

idnits 2.15.00 
 
/tmp/draft-ietf-softwire-map-mib-10.txt:
 
=C2=A0 Checking boilerplate required by RFC 5378 and the =
IETF Trust (see
=C2=A0 https://trustee.ietf.org/l=
icense-info):
=C2=A0 =
-------------------------------------------------------------------------=
---
 
=C2=A0=C2=A0=C2=A0=C2=A0 No issues found =
here.
 
=C2=A0 Checking nits according to https://www.iet=
f.org/id-info/1id-guidelines.txt:
=C2=A0 =
-------------------------------------------------------------------------=
---
 
=C2=A0=C2=A0=C2=A0=C2=A0 No issues found =
here.
 
=C2=A0 Checking nits according to https://www.ietf.org/id-i=
nfo/checklist :
=C2=A0 =
-------------------------------------------------------------------------=
---
 
=C2=A0=C2=A0=C2=A0=C2=A0 No issues found =
here.
 
=C2=A0 Miscellaneous =
warnings:
=C2=A0 =
-------------------------------------------------------------------------=
---
 
=C2=A0 -- The document date (September 15, 2017) is 39 days =
in the past.=C2=A0 Is this
=C2=A0=C2=A0=C2=A0=C2=A0 =
intentional?
 
 
=C2=A0 Checking references for intended status: Proposed =
Standard
=C2=A0 =
-------------------------------------------------------------------------=
---
 
=C2=A0=C2=A0=C2=A0=C2=A0 (See RFCs 3967 and 4897 for =
information about using normative =
references
=C2=A0=C2=A0=C2=A0=C2=A0 to lower-maturity documents in =
RFCs)
 
=C2=A0 =3D=3D Unused Reference: 'RFC7598' is defined on =
line 636, but no explicit
=C2=A0=C2=A0=C2=A0=C2=A0 reference was found in the =
text
 
=C2=A0 -- Obsolete informational reference (is this =
intentional?): RFC 2629
=C2=A0=C2=A0=C2=A0=C2=A0 (Obsoleted by RFC =
7749)
 
 
=C2=A0=C2=A0=C2=A0=C2=A0 Summary: 0 errors (**), 0 flaws =
(~~), 1 warning (=3D=3D), 2 comments =
(--).
 
=C2=A0=C2=A0=C2=A0=C2=A0 Run idnits with the --verbose =
option for more detailed information =
about
=C2=A0=C2=A0=C2=A0=C2=A0 the items =
above.
------------------------------------------------------------=
--------------------
 

 

  

 

 

 

On 11. Oct 2017, at 04:40, Yong Cui = <cuiyong@tsinghua.edu.cn> = wrote:

 

Hi folks,

The authors = believe the document, Definitions of Managed Objects for MAP-E = (draft-ietf-softwire-map-mib-10), is mature for advancement. We are now = issuing a working group last call for it.

Please send your = comments, either for or against, to the WG mailing list. The WGLC will = end on Oct. 24, 2017.


Thanks,

Yong & = Ian

 

------=_NextPart_000_0010_01D34DB6.BE355830-- From nobody Wed Oct 25 23:57:22 2017 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 9D9B113A2B8; Wed, 25 Oct 2017 23:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YinRW2JxhWu; Wed, 25 Oct 2017 23:57:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7116D1394E4; Wed, 25 Oct 2017 23:57:17 -0700 (PDT) Received: from hargashouseofribs.lan ([80.159.240.8]) by mail.gmx.com (mrgmx001 [212.227.17.184]) with ESMTPSA (Nemesis) id 0MZTw5-1dt6xI27sj-00LDEx; Thu, 26 Oct 2017 08:57:05 +0200 From: Ian Farrer Message-Id: <0A5E6031-5754-4C44-899C-231EC092746F@gmx.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C3DBB44B-BE3E-4970-88F7-BF6764FD5313" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 26 Oct 2017 08:57:06 +0200 In-Reply-To: <000f01d34d73$b0121830$10364890$@cn> Cc: softwires@ietf.org, draft-ietf-softwire-map-mib@ietf.org, Yong Cui To: Yu Fu References: <000f01d34d73$b0121830$10364890$@cn> X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:4yRdRBmWAoL5OnBT49Hup2Sis3fvVxDAjuQxRN3YHEq6z6NTKcO BcRStMkCE1QaP+BLCrOK7doKCOoSF2MNo3NEA5aw3FGcLdzKsRruVBuCQqiP1fhqXotXwS8 wqoM8+AwLm9CwPn1LjnKxOjEDmuEDhVAcuWqE0fkCO2AVVY33I0lU/Io7XyymOPg8DJqsoq 357R9WcoJHwLtjE6xLufA== X-UI-Out-Filterresults: notjunk:1;V01:K0:ovpHc4N1KeQ=:BKOgZOy1jx9xsv87VBCAPZ Hd/4qaVSXtYjBS9rUqDctTWquN8Jaw2mtHnDMcd1iF9lS89qkDyyo/6KkdZjcUrV5hr9YXEt1 KEU3eUnSParuU9PkkXOBNIjiQYlOcucyhfeaLg1ia5E/y6sQZEd9xO15Qf3hdVJxGerUbLVq0 YtSqBiFGjj/pCf1uH95DBn6/v08RRFb36pxgfov11ohKTca+TIXhHm3Xy9eNSpOCddwhS2mVd KyLoZUXje0kir5iJSWax1SfZ3pjexVYzRcTGwdICIvSmSRa+vQ9kPVNCh+e/r5LBO6G0cgXod yZcLAxLK6BBpa1noZtD2GnNb+kJkvFJ/irySwohq01Hfe5BMC+qvI/TWqH5KutNkp2SD2Rg0L eYIM+c3Fq18+zf4NJGptZ1tAjplPQf50WEgSF9YFmUA4BbqStbvR8w3ioCvj1GhpvefAkqrzP 2+imDyxc1U6K0qHoT5X414wN/yDu3iW7CrSGPA7527QUL6B5wdZmcYZOavtsHbki8p+v9NAwf J/b0xinsfFnBZZS/mMOXgQcNd/DZLw+sJkWBbwetR1kHtN+l04nzw6KDi6AMOK8gJd5GAygnN JqAF8Dn3VjlJt+GVlVbUGOJmaPpDI1nGOFtrPub/b2JgjtfZz7LJwTfogQJyN7+ufAV/rmx0l 4+Bi/E2fpHp63SToGMnJklkKvbA/On3MWA4nPlAL2pvNYu6ZHGglfw0lc43KouwqkGXic+kaV wr5Mvd7u3agtRa/qQVEA1atR2BxvjPFns6mBkHO3BqASJi60APUS8BCL2rXtvPO31se3dNZeM WcU/RIUkLtH/vov5fOr366/csWjU02LhmVdK2fXqCYct1sTgyI= Archived-At: Subject: Re: [Softwires] WGLC for draft-ietf-softwire-map-mib-10 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 06:57:21 -0000 --Apple-Mail=_C3DBB44B-BE3E-4970-88F7-BF6764FD5313 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Yu, Please see below.=20 Thanks, Ian > On 25. Oct 2017, at 11:28, Yu Fu wrote: >=20 > >g3. > >Section 7 - States that there are a list of objects and their = sensitivity / > >vulnerability, but the list that follows only names the objects. No = vulnerability > >information is included. > =20 > [Yu]: It has a description as followed : > =E2=80=9CSome of the readable objects in this MIB module (i.e., = objects with a > MAX-ACCESS other than not-accessible) may be considered sensitive = or > vulnerable in some network environments. It is thus important to > control even GET and/or NOTIFY access to these objects and possibly > to even encrypt the values of these objects when sending them over > the network via SNMP=E2=80=9D > =E2=80=9CObjects that reveal rule information of the MAP Domain: = Various objects can reveal the > rule information of the map domain. A curious outsider could = monitor > these to assess the number of rules and the IPv6 prefix performed = in > this domain. Further, an intruder could use the information to = guess > the address-sharing ratios of the ISPs.=E2=80=9D > =20 > [Yu]: The objects in the list reveal the rule information and are = readable. So they are vulnerable. [if - OK. The current text isn=E2=80=99t very clear. Can I propose the = following text as a replacement? Some of the MIB model's objects are vulnerable as the information which they hold may be used for targeting an attack against a MAP node = (CE or BR). E.g., an intruder could use the information to help deduce the customer = IPv4 and IPv6 topologies and address-sharing ratios in use by the ISP. The following is a list of the objects that have this vulnerability: ]= --Apple-Mail=_C3DBB44B-BE3E-4970-88F7-BF6764FD5313 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Yu,

Please see below. 

Thanks,
Ian

On 25. Oct 2017, at 11:28, Yu = Fu <fuyu@cnnic.cn> = wrote:

>g3.
>Section 7 = - States that there are a list of objects and their sensitivity /
>vulnerability, but the list that follows only names the = objects. No vulnerability
>information is included.
 
[Yu]: It has a = description as followed :
=E2=80=9CSome of the readable objects in = this MIB module (i.e., objects with a
   = MAX-ACCESS other than not-accessible) may be considered sensitive or
   = vulnerable in some network environments. It is thus important to
   = control even GET and/or NOTIFY access to these objects and possibly
   = to even encrypt the values of these objects when sending them over
   = the network via SNMP=E2=80=9D
=E2=80=9CObjects that reveal rule = information of the MAP Domain: Various objects can reveal the
   = rule information of the map domain.  A curious outsider could = monitor
   = these to assess the number of rules and the IPv6 prefix performed in
   = this domain.  Further, an intruder could use the information to = guess
   = the address-sharing ratios of the ISPs.=E2=80=9D
 
[Yu]: The = objects in the list reveal the rule information and are readable. So = they are vulnerable.


[if - OK. The current = text isn=E2=80=99t very clear. Can I propose the following text as a = replacement?

Some of = the MIB model's objects are vulnerable as the information
which they hold may be used for targeting an attack against a = MAP node (CE or BR).
E.g., an intruder could use = the information to help deduce the customer IPv4 and IPv6
topologies and address-sharing ratios in use by the = ISP.

The following is a list of the objects that have this = vulnerability:
]
= --Apple-Mail=_C3DBB44B-BE3E-4970-88F7-BF6764FD5313-- From nobody Thu Oct 26 00:09:05 2017 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 69B3F1394E4; Thu, 26 Oct 2017 00:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0siGFHyuNEsK; Thu, 26 Oct 2017 00:09:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5886B13915C; Thu, 26 Oct 2017 00:09:02 -0700 (PDT) Received: from hargashouseofribs.lan ([80.159.240.8]) by mail.gmx.com (mrgmx102 [212.227.17.174]) with ESMTPSA (Nemesis) id 0MUm1o-1dgEcB3Vs4-00Y8lV; Thu, 26 Oct 2017 09:08:59 +0200 From: Ian Farrer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <3B5B03B7-11AB-4AF8-91D4-82107AE482A0@gmx.com> Date: Thu, 26 Oct 2017 09:09:02 +0200 Cc: draft-ietf-softwire-dslite-yang@ietf.org To: Softwires list X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:nTqbOONP4JwMLo7b+XalM3JbviKkZMmg1kIYcQIkJJgGn/Ucyh7 YXSNBtc3heG0enyMSQwFD4Iz+eGCZ70BKArxvrG7I3eNVWcZd0H2DzRFyqaE8m6jedd/Pjg bt1FrGTCtJQgqwAPNxgnY72yqYeMYwMo2zgcZBCbyp5L9oINvNmnjFPrxTle+tcNfQoj4Ya YDU7YsnEFyynsky+EC7wA== X-UI-Out-Filterresults: notjunk:1;V01:K0:FGGA12JYOlw=:yjaErjnSSUlWeDvKGR3AXA RSVPa5GvY+cS3lLP57UZ/StdrHAiGSQ1lFt0kLiv8KxaqP0RWYNgHtZttvebdVTl2tkfE+SQ7 V2sBL1LxfIGtsZ8Fz0H34J5X/yTsEDeqACuEXfCpKWyPm6dCj4QrYdx5D6oXymHN4S7BpqEfa qM0gr3jRNCEBTG4OIhI9i4lWz1WLyt9vx7tvXyx+aJj/4M5dGgwBVtRWJhS31IXbMc1DPtK9U qosNKF8R/ZU5y8g1QbiN94jQeNJ9UHIAvH9MAiJ1+sKesXHxL1qXsdnp884+Lg3z/RxGJJuVk Dz0LwbeijFISIjU5QY2ydCLId2lUIrmSDuaehrmnHrjkugUR1sWg6D2umsO11AQh9T3C5Ii+N J1tQfoLJjxIwZeS9PiB9/1+7wn2VFsd9zeHsBUGWFOKo7zRE78FXFPqw4L8PZj39EjyPsmU33 mn7HAyBdk89oGlIKN/AlizD5mBDi9T/zAeLDywJvg0rnKqLAguAjSq7M1WJV+tkjevBoGWn9R 6UWX/afs7RXxhgNkSbs0ynFeFwWTSQUw5H0QRRYQnqBWKA5QTAITWRO3YXU/i1TZ1ZnoxKr6x e5RL+it9r5lRTJHeMHrLC9aH+ZSiREiUo3M+yNaG825hvpvdhErwqBeiA/QYOwAYGNO49Rddq kz4rlEofRlhP7spTtkkYBgzY78Z4PVFKI9JtXV9Qs2Vl2OT9HWFNYKTPFeYHs89gnlZINcuXw Za5XhXPCSmMNjdVOIMtesekoAWhGwOKjIVzALthn/JJaqDZjl59C8Dj/J2fLeVYUfIkkZEqAg JC6Ey3KLG7ySOn2T7qIhUuf/ZbgCFCeY1eYVvqlKajjBamsNUI= Archived-At: Subject: [Softwires] Work Group Last call for draft-ietf-softwire-dslite-yang-07 - Ends 9th Nov X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 07:09:04 -0000 Hi, The authors believe that draft-ietf-softwire-dslite-yang-07 is now ready = for advancement. This email marks the start of a 2 week work group last = call for the draft. Please send your comments, either for or against, to the softwire WG = mailing list. The WGLC will end on Nov. 9, 2017. Thanks, Yong & Ian= From nobody Thu Oct 26 19:37:47 2017 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 8807013F4FE; Thu, 26 Oct 2017 19:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.49 X-Spam-Level: X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4A7S6GpbJ-SX; Thu, 26 Oct 2017 19:37:44 -0700 (PDT) Received: from tsinghua.edu.cn (smtp28.tsinghua.edu.cn [101.6.4.52]) by ietfa.amsl.com (Postfix) with ESMTP id CC79813A5AF; Thu, 26 Oct 2017 19:37:43 -0700 (PDT) Received: from [192.168.43.117] (unknown [117.136.75.173]) by app-4 (Coremail) with SMTP id EgQGZQAn2cHnm_JZ6d36AA--.36917S3; Fri, 27 Oct 2017 10:37:33 +0800 (CST) Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yong Cui In-Reply-To: <0A5E6031-5754-4C44-899C-231EC092746F@gmx.com> Date: Fri, 27 Oct 2017 10:37:15 +0800 Cc: Yu Fu , softwires@ietf.org, draft-ietf-softwire-map-mib@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <000f01d34d73$b0121830$10364890$@cn> <0A5E6031-5754-4C44-899C-231EC092746F@gmx.com> To: Ian Farrer X-Mailer: Apple Mail (2.3124) X-CM-TRANSID: EgQGZQAn2cHnm_JZ6d36AA--.36917S3 X-Coremail-Antispam: 1UD129KBjvJXoW7Zr47Gr1xKrWDWw4UAr4fKrg_yoW8Zw43pr ZYq3W2krWktrZ3GFs7Jw4vgryrt39YvF43J3ZagryfCwn8Wryvvr17twn0vF9rCryxuF1j vw4YvrZxZr1UZFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUyvb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMxAIw28IcxkI7VAKI48JMxC2 0s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI 0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE 14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20x vaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AK xVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7IU8pnQUUUUUU== X-CM-SenderInfo: 5fxl50tqj632xlqjx3vdohv3gofq/ Archived-At: Subject: Re: [Softwires] WGLC for draft-ietf-softwire-map-mib-10 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 02:37:46 -0000 Hi folk, We don=A1=AFt have major objections to advance the document during the = WGLC. As a result, before we advance the doc, we would encourage the authors = to update a new version to address the minor comments. Thanks so much for the Ian=A1=AFs thorough review and the authors=A1=AF = contribution. Yong > =D4=DA 2017=C4=EA10=D4=C226=C8=D5=A3=AC14:57=A3=ACIan Farrer = =D0=B4=B5=C0=A3=BA >=20 > Hi Yu, >=20 > Please see below.=20 >=20 > Thanks, > Ian >=20 >> On 25. Oct 2017, at 11:28, Yu Fu wrote: >>=20 >> >g3. >> >Section 7 - States that there are a list of objects and their = sensitivity / >> >vulnerability, but the list that follows only names the objects. No = vulnerability >> >information is included. >> =20 >> [Yu]: It has a description as followed : >> =A1=B0Some of the readable objects in this MIB module (i.e., objects = with a >> MAX-ACCESS other than not-accessible) may be considered sensitive = or >> vulnerable in some network environments. It is thus important to >> control even GET and/or NOTIFY access to these objects and = possibly >> to even encrypt the values of these objects when sending them over >> the network via SNMP=A1=B1 >> =A1=B0Objects that reveal rule information of the MAP Domain: Various = objects can reveal the >> rule information of the map domain. A curious outsider could = monitor >> these to assess the number of rules and the IPv6 prefix performed = in >> this domain. Further, an intruder could use the information to = guess >> the address-sharing ratios of the ISPs.=A1=B1 >> =20 >> [Yu]: The objects in the list reveal the rule information and are = readable. So they are vulnerable. >=20 >=20 > [if - OK. The current text isn=A1=AFt very clear. Can I propose the = following text as a replacement? >=20 > Some of the MIB model's objects are vulnerable as the information > which they hold may be used for targeting an attack against a MAP node = (CE or BR). > E.g., an intruder could use the information to help deduce the = customer IPv4 and IPv6 > topologies and address-sharing ratios in use by the ISP. >=20 > The following is a list of the objects that have this vulnerability: > ] From nobody Sun Oct 29 19:57:24 2017 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 3D05813FD60; Sun, 29 Oct 2017 19:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePDVlH6Enr7F; Sun, 29 Oct 2017 19:57:13 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDBF13FD4A; Sun, 29 Oct 2017 19:57:11 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.162]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0A5QOj9lPZZ+nkYAA--.48550S3; Mon, 30 Oct 2017 10:57:02 +0800 (CST) From: "Yu Fu" To: "'Ian Farrer'" Cc: , , "'Yong Cui'" References: <000f01d34d73$b0121830$10364890$@cn> <0A5E6031-5754-4C44-899C-231EC092746F@gmx.com> In-Reply-To: <0A5E6031-5754-4C44-899C-231EC092746F@gmx.com> Date: Mon, 30 Oct 2017 10:57:02 +0800 Message-ID: <01c201d3512a$c38cfeb0$4aa6fc10$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C3_01D3516D.D1B03EB0" X-Mailer: Microsoft Office Outlook 12.0 Content-Language: zh-cn Thread-Index: AdNOKHVykxtkXnF6Rz6PZbv6Nb+QIwDAG8Uw X-CM-TRANSID: AQAAf0A5QOj9lPZZ+nkYAA--.48550S3 X-Coremail-Antispam: 1UD129KBjvJXoW7WF15Wr1rJF45JF17KF1rWFg_yoW8Cw47pF ZIva43ArWkJryxGFs7J3yxWryFy39YvF43JFnaqry7C398Gryvvr15Kwn0vFZ7CryxZFy0 vw4Y9r9xZr1DZFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBqb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAY j202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG04xIwI0_Jr0_Gr1l5I 8CrVCF0I0E4I0vr24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4U McvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Avz4vE14v_Gr1l42xK82 IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC2 0s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMI IF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF 0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4 A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU8oEEUUUUUU== X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: Re: [Softwires] WGLC for draft-ietf-softwire-map-mib-10 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 02:57:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01C3_01D3516D.D1B03EB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Ian, =20 I will do as you suggested. =20 An updated version will be submitted soon.=20 =20 Thanks again =20 Yu =20 From: Ian Farrer [mailto:ianfarrer@gmx.com]=20 Sent: Thursday, October 26, 2017 2:57 PM To: Yu Fu Cc: softwires@ietf.org; draft-ietf-softwire-map-mib@ietf.org; Yong Cui Subject: Re: WGLC for draft-ietf-softwire-map-mib-10 =20 Hi Yu, =20 Please see below.=20 =20 Thanks, Ian =20 On 25. Oct 2017, at 11:28, Yu Fu wrote: =20 >g3. >Section 7 - States that there are a list of objects and their = sensitivity / >vulnerability, but the list that follows only names the objects. No = vulnerability >information is included. =20 [Yu]: It has a description as followed : =E2=80=9CSome of the readable objects in this MIB module (i.e., objects = with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP=E2=80=9D =E2=80=9CObjects that reveal rule information of the MAP Domain: Various = objects can reveal the rule information of the map domain. A curious outsider could monitor these to assess the number of rules and the IPv6 prefix performed in this domain. Further, an intruder could use the information to guess the address-sharing ratios of the ISPs.=E2=80=9D =20 [Yu]: The objects in the list reveal the rule information and are = readable. So they are vulnerable. =20 =20 [if - OK. The current text isn=E2=80=99t very clear. Can I propose the = following text as a replacement? =20 Some of the MIB model's objects are vulnerable as the information which they hold may be used for targeting an attack against a MAP node = (CE or BR). E.g., an intruder could use the information to help deduce the customer = IPv4 and IPv6 topologies and address-sharing ratios in use by the ISP. =20 The following is a list of the objects that have this vulnerability: ] ------=_NextPart_000_01C3_01D3516D.D1B03EB0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Ian,

 

I will do as you suggested.

 

An updated version will be submitted soon.

 

Thanks again

 

Yu

 

From:= Ian Farrer = [mailto:ianfarrer@gmx.com]
Sent: Thursday, October 26, 2017 = 2:57 PM
To: Yu Fu
Cc: softwires@ietf.org; = draft-ietf-softwire-map-mib@ietf.org; Yong Cui
Subject: Re: = WGLC for = draft-ietf-softwire-map-mib-10

 

Hi Yu,

 

Please see = below. 

 

Thanks,

Ian

 

On 25. Oct 2017, at 11:28, Yu Fu = <fuyu@cnnic.cn> = wrote:

 

>g3.

>Section 7 - States that there are a list of objects and their = sensitivity /

>vulnerability, but the list that follows only names the objects. = No vulnerability

>information is included.

 

[Yu]: It has a description as followed :

=E2=80=9CSome of the readable objects in this MIB module (i.e., = objects with a

   MAX-ACCESS other than not-accessible) may be considered = sensitive or

   vulnerable in some network environments. It is thus = important to

   control even GET and/or NOTIFY access to these objects = and possibly

   to even encrypt the values of these objects when sending = them over

   the network via SNMP=E2=80=9D

=E2=80=9CObjects that reveal rule information of the MAP Domain: = Various objects can reveal the

   rule information of the map domain.  A curious = outsider could monitor

   these to assess the number of rules and the IPv6 prefix = performed in

   this domain.  Further, an intruder could use the = information to guess

   the address-sharing ratios of the = ISPs.=E2=80=9D

 

[Yu]: The objects in the list reveal the rule information and are = readable. So they are vulnerable.

 

 

[if - OK. The current text = isn=E2=80=99t very clear. Can I propose the following text as a = replacement?

 

Some of the MIB model's objects are = vulnerable as the information

which they hold may be used for = targeting an attack against a MAP node (CE or = BR).

E.g., an intruder could use the information to help deduce = the customer IPv4 and IPv6

topologies and address-sharing = ratios in use by the ISP.

 

The following is a list of the = objects that have this = vulnerability:

]

= ------=_NextPart_000_01C3_01D3516D.D1B03EB0-- From nobody Mon Oct 30 02:02:03 2017 Return-Path: X-Original-To: softwires@ietf.org Delivered-To: softwires@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE44B13F8CA; Mon, 30 Oct 2017 02:02:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: softwires@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150935412187.3369.1564455292616617857@ietfa.amsl.com> Date: Mon, 30 Oct 2017 02:02:01 -0700 Archived-At: Subject: [Softwires] I-D Action: draft-ietf-softwire-map-mib-11.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.22 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 09:02:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires WG of the IETF. Title : Definitions of Managed Objects for MAP-E Authors : Yu Fu Sheng Jiang Bing Liu Jiang Dong Yuchi Chen Filename : draft-ietf-softwire-map-mib-11.txt Pages : 16 Date : 2017-10-30 Abstract: This memo defines a portion of the Management Information Base (MIB) for Mapping Address and Port with encapsulation (MAP-E) for use with network management protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-mib/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-softwire-map-mib-11 https://datatracker.ietf.org/doc/html/draft-ietf-softwire-map-mib-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-mib-11 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 nobody Mon Oct 30 08:12:23 2017 Return-Path: X-Original-To: softwires@ietf.org Delivered-To: softwires@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86DA013FA54; Mon, 30 Oct 2017 08:12:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: softwires@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150937633651.3401.8976291853315482170@ietfa.amsl.com> Date: Mon, 30 Oct 2017 08:12:16 -0700 Archived-At: Subject: [Softwires] I-D Action: draft-ietf-softwire-yang-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.22 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 15:12:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires WG of the IETF. Title : A YANG Data Model for IPv4-in-IPv6 Address plus Port Softwires Authors : Qi Sun Hao Wang Yong Cui Ian Farrer Sladjana Zechlin Mohamed Boucadair Rajiv Asati Filename : draft-ietf-softwire-yang-02.txt Pages : 41 Date : 2017-10-30 Abstract: This document defines YANG data models for the configuration and operation of IPv4-in-IPv6 softwire Border Relays and Customer Premises Equipment. The model covers the Lightweight 4over6, MAP-E, and MAP-T softwire mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-softwire-yang-02 https://datatracker.ietf.org/doc/html/draft-ietf-softwire-yang-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-yang-02 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 nobody Mon Oct 30 08:13:03 2017 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 1737E13FA3F for ; Mon, 30 Oct 2017 08:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.899 X-Spam-Level: X-Spam-Status: No, score=-4.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytL3jv4jFJ8M for ; Mon, 30 Oct 2017 08:13:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9140913FA5B for ; Mon, 30 Oct 2017 08:12:25 -0700 (PDT) Received: from hargashouseofribs.lan ([80.159.240.8]) by mail.gmx.com (mrgmx002 [212.227.17.184]) with ESMTPSA (Nemesis) id 0LuxG5-1d9Q5G1C77-0105hL for ; Mon, 30 Oct 2017 16:12:23 +0100 From: Ian Farrer Content-Type: multipart/alternative; boundary="Apple-Mail=_E1A4B3BC-4263-4C34-B50A-449F374D651A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Mon, 30 Oct 2017 16:12:22 +0100 To: Softwires list X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:y3asr5bbrQxSaoSQNGYVyRP9RDIjRFbUO8yBQBAnYSksSnFVp9T MQBNQr6ApF6MI68eyt1SPMx4S5P7u2FpSf7tWj0fVpHlRfPaStX9wow1sfxHYKYSytLoA4j 0zwW4ai7Tatky02jvMKMMuv7UFzwY1jUkkuGN/SK9NexKu7w+3kSJJu9/ogz1Pc3DDN4haO IUSQ6HD4Dz4v9F6aNDsDA== X-UI-Out-Filterresults: notjunk:1;V01:K0:3bmOQNb3Yio=:OYmhgSP020dUtmib16inFU aDWrtuhCShlG7XcwmCNq5tJ6sC/SlWbkky7yBTACntBhNOJPfzIRw8cf771O8P1GgzVdo+mlj sLijSdzG/0Y3s+TncZE3FNneD7y1ISImQ+QiFdfu+OqYJzzfwRitl4u5QD+i5ZWLYc/q5iLgY mk4FCSGZ4oAHELTBxv4ENgWb5z2gGnjT2ZM7AbQ99dqGEIhnGnkD1QIpMdxcfSlx5JOzzpo0e bQUVPz7Uea5FcLspkmgtsxlxkvXuDi+PZhm5RUM4teZ/mnfSXO5SNRBue9TohdbIo0XiFAPs1 uDLlq+YVeRCWAt8pP1/Msnuf/CRZ8BiYBU5NCEoxzZbf1Bzyp5LSIdSVYCfBRwphOfX92NdPj 0CR5+hXl5Yc2II79H0oeuCsF+BR/dSEe9ktmzG8rZO3ny4NeFK//xnfzA+Mc1xPwig5htEKUr poL3MQhbnRrn8xZZlXZdhbgGAtDhUkYOPjhY5lfNWxFGlWLJlqKbB9bQdhII3Kb72PEA5inkC WWU3ghpVodGcB6Y92lTTz7ZWEl0J9+fI1mNTT0/Ult3ui04EfQHmRz0QotCuh48LDxas+Xxvs XNRwFhtkhBP/AdKWWm0rDqUHT0ePgJIA/oubJz1UuA/fAADKgoykQ5i8uXSulYbHOdjybutm3 dlecGxTJvk5eMT1x3/q9Yq9tqr4pIWaXWuk4emFjRUw9rRrXNOW6MTCY/5aYdgYI1kasp08qt agJIFc17MWsMY6JytpZeD79JQNmNCE+BcIc5EPkL7OpaU9Z0G1onF3PoO7Wdu+bInUgk0U13H wtmJAFRsPmvZ+lBlRmMEAsFSovcCPYuJzImfFWA7Kf2W7NmkSs= Archived-At: Subject: [Softwires] New version of draft-ietf-softwire-yang posted X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 15:13:02 -0000 --Apple-Mail=_E1A4B3BC-4263-4C34-B50A-449F374D651A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I=E2=80=99ve just posted an updated version of draft-ietf-softwire-yang. = This has taken quite some time to produce and is quite a significant = update from -01. The most notable changes in this version: 1, There are now 3 models as this follows intended function much more = cleanly than the previous approach: * CE Model (MAP-E/T, lw4o6) * BR Model (MAP-E/T, lw4o6) * Common Model (groupings of functions used by CE and BR) 2, The CE model is now structured to work with the ietf-interfaces YANG = model - the softwire is defined as config for building a tunnel = interface. This allows us to use it for getting necessary configuration = described in other models such as ietf-routing. It is also in line with = the way that the tunnel interface is configured in CE devices. 3, Where there is duplication, configuration nodes have been removed in = favour of referencing other YANG models - e.g. referencing ietf-nat for = NAT and PSID configuration in the CE. 4, Better descriptions, improved counters and a lot of other little fix = ups. One question that the authors have been discussing is the approach to = defining =E2=80=98binding=E2=80=99 type softwires (lw4o6, MAP EA=3D0). = This is the current, relevant text in Sec 2: Within the BR and CE modules, the YANG "feature" statement is used to distinguish which of the different softwire mechanism(s) is relevant=09 for a specific element's configuraiton. For each module, a choice statement is included for either 'binding' or 'algorithmic'. Binding is used for configuring Lightweight 4over6, whereas Algorithmic is used for configuring MAP-T or MAP-E. +---------------------+-----------+---------------+ | S46 Mechanism | ce-type? | data-plane? | +---------------------+-----------+---------------+ | Lightweight 4over6 | binding | n/a | | MAP-E | algorithm | encapsulation | | MAP-T | algorithm | translation | +---------------------+-----------+---------------+ A proposed change is to cover the =E2=80=98binding=E2=80=99 cases of MAP = configuration here as well - a suggestion for how this section could = read is: Within the BR and CE modules, the YANG "feature" statement is used to = =20 distinguish which of the different softwire mechanism(s) is relevant = =09 for a specific element's configuraiton. For each module, a choice = =09 statement is included for either 'binding' or 'algorithmic'. Binding = =09 is used for configuring Lightweight 4over6 or MAP with EA=3D0 (with or = =09 without PSID) softwires (described in [RFC7597] Appendix A Examples 4 = =09 and 5). Algorithmic is used for MAP-T or MAP-E 'mesh' (EA>0, no = =09 PSID) configuration. +-------------------------------+-----------+---------------+ = =20 | S46 Mechanism | ce-type? | data-plane? | = =09 +-------------------------------+-----------+---------------+ = =09 | Lightweight 4over6 / MAP EA=3D0 | binding | n/a | = =09 | MAP-E Mesh | algorithm | encapsulation | = =09 | MAP-T Mesh | algorithm | translation | = =09 +-------------------------------+-----------+---------------+ = =20 Obviously, if we were to go this way, then other parts of the draft = would need to be updated in line. As ever, any comments, suggestions etc. appreciated. Thanks, Ian =09= --Apple-Mail=_E1A4B3BC-4263-4C34-B50A-449F374D651A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I=E2=80=99ve just posted an updated version = of draft-ietf-softwire-yang. This has taken quite some time to produce and = is quite a significant update from -01.

The most notable = changes in this version:

1, There are now 3 models as this = follows intended function much more cleanly than the previous = approach:
* CE Model (MAP-E/T, lw4o6)
* BR Model (MAP-E/T, = lw4o6)
*= Common Model (groupings of functions used by CE and = BR)

2, The CE model is now structured to work with the = ietf-interfaces YANG model - the softwire is defined as config for = building a tunnel interface. This allows us to use it for getting = necessary configuration described in other models such as ietf-routing. = It is also in line with the way that the tunnel interface is configured = in CE devices.

3, Where there is duplication, = configuration nodes have been removed in favour of referencing other = YANG models - e.g. referencing ietf-nat for NAT and PSID configuration = in the CE.

4, Better descriptions, improved = counters and a lot of other little fix ups.

One question that the authors have been discussing is the = approach to defining =E2=80=98binding=E2=80=99 type softwires (lw4o6, = MAP EA=3D0). This is the current, relevant text in Sec 2:

Within the BR and CE modules, the YANG "feature" statement is = used to
distinguish which of the different softwire mechanism(s) is = relevant =
for a specific element's configuraiton.  For each = module, a choice
statement is included for either 'binding' or 'algorithmic'. =  Binding
is used for configuring Lightweight 4over6, = whereas Algorithmic is
used for configuring MAP-T = or MAP-E.

+---------------------+-----------+---------------+
|   =  S46 Mechanism    |  ce-type? |  data-plane? =  |
+---------------------+-----------+---------------+
| =  Lightweight 4over6 |  binding  |      n/a =      |
|        MAP-E       =  | algorithm | encapsulation |
|        MAP-T =        | algorithm |  translation =  |
+---------------------+-----------+---------------+

A proposed change is to cover the =E2=80=98binding=E2=80=99= cases of MAP configuration here as well - a suggestion for how this = section could read is:


Within the BR and CE = modules, the YANG "feature" statement is used to =   =    
distinguish which of the different = softwire mechanism(s) is relevant     =   =
for a specific element's configuraiton.  For = each module, a choice     
statement is included for = either 'binding' or 'algorithmic'.  Binding   =   =  
is used for configuring Lightweight 4over6 or MAP with EA=3D0= (with or   =   =  
without PSID) softwires (described in [RFC7597] Appendix A = Examples 4   =   =  
and 5).  Algorithmic is used for MAP-T or MAP-E 'mesh' (EA>0, = no   =
PSID) configuration.

+-------------------------------+-----------+---------------+&n= bsp; =                   =   
|         S46 Mechanism =         |  ce-type? |  data-plane? =  | =   =            
+-------------------------------+-----------+---------------+ =   =            
| Lightweight 4over6 / MAP EA=3D0 |  binding =  |      n/a      | =   =            
|           MAP-E Mesh  =         | algorithm | encapsulation | =   =            
|           MAP-T Mesh  =         | algorithm |  translation  | =   =            
+-------------------------------+-----------+---------------+ =   =             

Obviously, if we were to go this way, then other parts of the = draft would need to be updated in line.

As ever, any comments, = suggestions etc. appreciated.

Thanks,
Ian


=
= --Apple-Mail=_E1A4B3BC-4263-4C34-B50A-449F374D651A-- From nobody Mon Oct 30 19:11:43 2017 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 36B4513FC5E for ; Mon, 30 Oct 2017 19:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cVslSN3i61B for ; Mon, 30 Oct 2017 19:11:39 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 394A1139078 for ; Mon, 30 Oct 2017 19:11:38 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.94]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0D5AN3R2_dZ+9cYAA--.353S3; Tue, 31 Oct 2017 10:11:29 +0800 (CST) From: "Yu Fu" To: "'Softwires list'" Date: Tue, 31 Oct 2017 10:11:29 +0800 Message-ID: <00ff01d351ed$907d5bf0$b17813d0$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdNRXdysp81Dhm3/Sq63ub1j3YTo3AAi9t4g Content-Language: zh-cn X-CM-TRANSID: AQAAf0D5AN3R2_dZ+9cYAA--.353S3 X-Coremail-Antispam: 1UD129KBjvJXoW7Aw45Gw17JF43Wr48uFy8Krg_yoW8Cr17pa yIv3s8Gw4xJ3Wkt397WF109w1vv34rJrWfuFn3Jr10va4UJ3Wvyw10krZ5ArZrJrWrGF4x AF4ruw1UXan5XrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkIb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwV C2z280aVCY1x0267AKxVWxJr0_GcWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xv F2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r 4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Avz4vE14v_Gr1l42xK 82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGw C20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1j6r15MIIYrxkI7VAKI48J MIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMI IF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvE x4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU8DKsUUUUUU== X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: [Softwires] FW: I-D Action: draft-ietf-softwire-map-mib-11.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 02:11:41 -0000 Hi all, We have updated a new version for MAP-E MIB based on Ian's comments. Your comments and review are appreciated. Thanks Yu -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, October 30, 2017 5:02 PM To: i-d-announce@ietf.org Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-mib-11.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires WG of the IETF. Title : Definitions of Managed Objects for MAP-E Authors : Yu Fu Sheng Jiang Bing Liu Jiang Dong Yuchi Chen Filename : draft-ietf-softwire-map-mib-11.txt Pages : 16 Date : 2017-10-30 Abstract: This memo defines a portion of the Management Information Base (MIB) for Mapping Address and Port with encapsulation (MAP-E) for use with network management protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-mib/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-softwire-map-mib-11 https://datatracker.ietf.org/doc/html/draft-ietf-softwire-map-mib-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-mib-11 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/ _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires