From nobody Tue May 2 23:31:59 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 D2A7B129C16; Tue, 2 May 2017 23:31:51 -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.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149379311182.21469.11841945219441176957@ietfa.amsl.com> Date: Tue, 02 May 2017 23:31:51 -0700 Archived-At: Subject: [Softwires] I-D Action: draft-ietf-softwire-map-radius-12.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: Wed, 03 May 2017 06:31:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires of the IETF. Title : RADIUS Attribute for Softwire Address plus Port based Mechanisms Authors : Sheng Jiang Yu Fu Bing Liu Peter Deacon Chongfeng Xie Tianxiang Li Filename : draft-ietf-softwire-map-radius-12.txt Pages : 23 Date : 2017-05-02 Abstract: IPv4-over-IPv6 transition mechanisms provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) options have been defined to configure Customer Edge (CE) in MAP-E, MAP-T, and Lightweight 4over6. However, in many networks, the configuration information may be stored in an Authentication Authorization and Accounting (AAA) server, while user configuration information is mainly provided by the Broadband Network Gateway (BNG) through the DHCPv6 protocol. This document defines two new Remote Authentication Dial In User Service (RADIUS) attributes that carry CE configuration information from an AAA server to BNG. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-softwire-map-radius-12 https://datatracker.ietf.org/doc/html/draft-ietf-softwire-map-radius-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-radius-12 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 Wed May 3 19:14: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 2A2CA1294EE for ; Wed, 3 May 2017 19:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 XrlZQSnkJPPR for ; Wed, 3 May 2017 19:14:25 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 59D8F129537 for ; Wed, 3 May 2017 19:14:23 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.49]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0CptOR5jgpZqHarKg--.32870S3; Thu, 04 May 2017 10:14:17 +0800 (CST) From: "Yu Fu" To: Date: Thu, 4 May 2017 10:14:28 +0800 Message-ID: <004c01d2c47c$28bd0230$7a370690$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: zh-cn Thread-Index: AdLD1weYw6W7nQO1R7miHzkf99WnOQAo+N9g X-CM-TRANSID: AQAAf0CptOR5jgpZqHarKg--.32870S3 X-Coremail-Antispam: 1UD129KBjvJXoWxZFWkAF43WryxWFyfGFyUWrg_yoW5GF1kpF WxZa45Gw1xJw18J3ykWr18uwnYv3s5CrWfAFnxGr10vrWUG3Wvyw1S9rWYy39rJrWrGr42 vr4a9w1UWFs5Xr7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkIb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMxkIecxEwVAFwVW8JwCF04k2 0xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI 8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jr0_JrylIxkGc2Ij64vIr41l IxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIx AIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvE x4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU8DKsUUUUUU== X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: [Softwires] FW: I-D Action: draft-ietf-softwire-map-radius-12.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: Thu, 04 May 2017 02:14:27 -0000 Hi all, We have updated the 12 version. It has been added some description in section 4 and 6.1 regarding how the S46 Container Option types and option codes permitted in the Softwire46-Priority Attribute are used and specified. Comments are appreciated. Thanks Yu -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Wednesday, May 03, 2017 2:32 PM To: i-d-announce@ietf.org Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-radius-12.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires of the IETF. Title : RADIUS Attribute for Softwire Address plus Port based Mechanisms Authors : Sheng Jiang Yu Fu Bing Liu Peter Deacon Chongfeng Xie Tianxiang Li Filename : draft-ietf-softwire-map-radius-12.txt Pages : 23 Date : 2017-05-02 Abstract: IPv4-over-IPv6 transition mechanisms provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) options have been defined to configure Customer Edge (CE) in MAP-E, MAP-T, and Lightweight 4over6. However, in many networks, the configuration information may be stored in an Authentication Authorization and Accounting (AAA) server, while user configuration information is mainly provided by the Broadband Network Gateway (BNG) through the DHCPv6 protocol. This document defines two new Remote Authentication Dial In User Service (RADIUS) attributes that carry CE configuration information from an AAA server to BNG. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-softwire-map-radius-12 https://datatracker.ietf.org/doc/html/draft-ietf-softwire-map-radius-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-radius-12 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 From nobody Tue May 16 00:13:04 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 03C63129480; Tue, 16 May 2017 00:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 wrSV73UfQQBB; Tue, 16 May 2017 00:12:59 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 65E4F129C48; Tue, 16 May 2017 00:10:00 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.213]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0B5hubDpRpZQJixKg--.40173S3; Tue, 16 May 2017 15:09:55 +0800 (CST) From: "Yu Fu" To: Cc: Date: Tue, 16 May 2017 15:10:07 +0800 Message-ID: <002101d2ce13$7386f2d0$5a94d870$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdLICzQDa7vUXcvIRTKNfLp9wiksMwGB3CQA Content-Language: zh-cn X-CM-TRANSID: AQAAf0B5hubDpRpZQJixKg--.40173S3 X-Coremail-Antispam: 1UD129KBjvJXoWxKr1DXFWrCFWxCFWruw1DGFg_yoW3XrW8pF Z3Ka1YkrWDJFsrCrZ7Ww4vqasYyFn7GFW7Gr98Xryjkws8JF97tF4Ygas5Xa4DGr40qw4j qrWYvryrGFZ8ZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkFb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8Jw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6r4xMxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07bo-BiUUUUU= X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: [Softwires] FW: early MIB Doctor review for draft-ietf-softwire-map-mib-07 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, 16 May 2017 07:13:02 -0000 I have forgotten to forward the early MIB Doctor review to the WG. = Sorry... -----Original Message----- From: bertietf@bwijnen.net [mailto:bertietf@bwijnen.net]=20 Sent: Monday, May 08, 2017 10:56 PM To: draft-ietf-softwire-map-mib.all@ietf.org; MIB Doctors Subject: early MIB Doctor review for draft-ietf-softwire-map-mib-07 [not sure if draft-ietf-softwire-map-mib.all@ietf.org also includes the = softwire WG mailing list. Anyways, I am not subscribed to that WG list, = so I probably can't post there. Pls WG chairs forward if needed/wanted]. I did an early MIB doctor review for this document. The syntax check with SMICNG is clean. Great. My comments/questions: - section 4 states: The MAP-E MIB provides a way to configure and monitor the MAP = devices in MAP encapsulation mode through SNMP. Yet there are no read-write or read-create objects defined in the MIB module. So I don't think you can "configure" anything on the MAP = devices via SNMP with this MIB module - section 4.1.1 states: The mapRule subtree describes managed objects used for managing the multiple mapping rules in the MAP encapsulation mode. So, since the MIB module is read-only, I think I would change s/managing/monitoring/. But maybe that is just a wording choice. - section 4.1.2 - The BR MUST perform a validation of the consistency of the = source IPv6 address and source port number for the packet using BMR. - The Customer Edge (CE) SHOULD check that MAP received packets' transport-layer destination port number is in the range = configured by MAP for the CE. Mmmm... what is BR ? Please expand the acronym the first time you = use it in your document. Same for BMR. I am not sure that the MIB document is the place to tell = (normatively (MUST/SHOULD) a BR that it MUST perform a certain protocol function. That is (I = assume) specified in the RFC7597 itself, right? Maybe you mean to say that the BR (and CE) MUST and SHOULD report = any invalid packets as found per the rules in RFC7579. They MUST/SHOULD report = them via this MIB module (as per your MODULE Conformance). Oh well, again this may be a wording issue. If my interpretation here is correct, I can live with your wording = although I think it can be clearer and that the proper compliance language is in the = proper document. - section 5. I think I would change: 5. Definitions MAP-E-MIB DEFINITIONS ::=3D BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Integer32, Unsigned32, Counter64 FROM SNMPv2-SMI ifIndex FROM IF-MIB InetAddressType, InetAddress, InetAddressPrefixLength FROM INET-ADDRESS-MIB OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF; Into 5. Definitions The following MIB module imports definitions from [RFC2578], = [RFC2580], [RFC2863], and [RFC4001]. MAP-E-MIB DEFINITIONS ::=3D BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Integer32, Unsigned32, Counter64 FROM SNMPv2-SMI -- RFC2578 ifIndex FROM IF-MIB -- RFC2863 InetAddressType, InetAddress, InetAddressPrefixLength FROM INET-ADDRESS-MIB -- RFC4001 OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF; -- RFC2580 That way, you have a reference to each document (they are all = normative) and in the MIB module itself (where you cannot put = references/citations) you would still have document which RFC the imports are from. Handy = when a MIB module has been extracted from an RFC. In the MIB module itself: mapRuleID OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An identifier used to distinguish the multiple mapping rule which is unique with each CE in the same BR." ::=3D { mapRuleEntry 1 } Since this is an index object, it be better defined as unsigned 32. See RFC4181, section 4.6.1.1. Specifically page 15, which states - Unsigned32 with a range that excludes zero is RECOMMENDED for most index objects. It is acceptable to include zero in the range when it is semantically significant or when it is used as the index value for a unique row with special properties. Such usage SHOULD be clearly documented in the DESCRIPTION clause. mapRuleIPv6PrefixType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "This object MUST be set to the value of ipv6(2) to present the IPv6 address.It describes the address type of the mapRuleIPv6Prefix and mapRuleBRIPv6Address." Such MUST language is not recommended. The way to specify such = mandatory value you best use the MODULE COMPLIANCE statement. Such is = RECOMMENDED as per RFC4181, page 26 mapRuleIPv6Prefix OBJECT-TYPE SYNTAX InetAddress(SIZE (0..16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IPv6 prefix defined in mapping rule which will be assigned to CE. The address type is given by mapRuleIPv6PrefixType." ::=3D { mapRuleEntry 3 } mmmmm, when the InetAddressType is ipv6(2), then my understanding of = RFC4001 is that the SIZE for the InetAddress MUST be 16. Maybe Juergen can = chime in here? And if it is ALWAYS an IPv6 address, then maybe it is even better to = use InetAddressIPv6 as the OBJECT-TYPE. I see the same set of 2 objects for IPv4. In my view, the idea of InetAddressType and InetAddress were/are to = allow yopu to specify one or a single pair that can hold each of the 2 (or even more if = needed) AddressTypes. So why are there separate objects for IPv4 and IPv6 ??? mapRulePSID OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The PSID value algorithmically identifies a set of ports assigned to a CE." REFERENCE "PSID: section 3 of RFC 7597." ::=3D { mapRuleEntry 9 } Mmmm... section 3 of RFC7597 only defines the term. The algorithm = is in section 5.1 Maybe that is a better place to point to. Reading that section 5.1 in RFC7597, I wonder if "Integer32" is the = best representation. In section 5.1, I see a PSID that is 6 bits (figure 2 on page 10). = But there is also text about a PSID of 0x00 and 0xFF, which does not fit in 6 bits. I am not an expert (basically have no knowledge about) on RFC7597. = But sofar I cannot determine what the value range might be and how Integer32 is a good = representation for the PSID. Please explain (not just to me, but adding text to the = internet drafts and the DESCRIPTION clause of this object) mapRulePSIDLen OBJECT-TYPE SYNTAX Integer32 My understanding sofar is that this object can never take a = negative value, so Unsigned32 would be better I think. mapRuleType OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the mapping rule. A value of 0 means it is a BMR; a non-zero value means it is a FMR." REFERENCE "BMR, FMR: section 5 of RFC 7597." ::=3D { mapRuleEntry 13 } That probably works. But it is probably much better to do a = ENUMERATION, Which has a SYNTAX of INTEGER and then lists enumberated values. That = makes it much more extensible in the future (if needed). mapMIBSecurityGroup OBJECT-GROUP OBJECTS { mapSecurityCheckInvalidv4, mapSecurityCheckInvalidv6 } STATUS current DESCRIPTION " The collection of this objects are used to give the information on MAP security checks." ::=3D { mapMIBGroups 2 } These objects are defined with ACCESS accessible-for-notify. I think = that means you have to define this group as a NOTIFICATION-GROUP instead of an = OBJECT-GROUP. - Section 7. Security considerations: These are the objects and their sensitivity/vulnerability: mapRuleIPv6PrefixType mapRuleIPv6Prefix ... etc (quite a list of objects). But nowhere do I see text about "their sensitivity/vulnerability". = ?? Still to be added? Bert From nobody Tue May 16 00:13:15 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 E3E96129B7D; Tue, 16 May 2017 00:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 zjKIES9qEQFK; Tue, 16 May 2017 00:13:11 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id A33EC12E041; Tue, 16 May 2017 00:10:12 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.213]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0B5hubDpRpZQJixKg--.40173S4; Tue, 16 May 2017 15:09:55 +0800 (CST) From: "Yu Fu" To: Cc: , "'MIB Doctors'" , References: <003201d2cad9$c83bec50$58b3c4f0$@cn> <6874911d-0535-8206-d96d-99a956c5bf85@bwijnen.net> In-Reply-To: <6874911d-0535-8206-d96d-99a956c5bf85@bwijnen.net> Date: Tue, 16 May 2017 15:10:08 +0800 Message-ID: <002201d2ce13$73ccd570$5b668050$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdLLMf+kXJXxUjaxQv+CCRcaXI+9NgB8BaKQ Content-Language: zh-cn X-CM-TRANSID: AQAAf0B5hubDpRpZQJixKg--.40173S4 X-Coremail-Antispam: 1UD129KBjvJXoW3XFy7Jw4DGFW8Kw4fAF4UXFb_yoW3Xw1xp3 93ta15trWqqa17CrWv9w1vq34FyFZ3ZFy5Gr98try3C390yr97JF47KF1j9ayDJr10qa1j vrWUX3s8C3s8ZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Cb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28IrcIa0xkI8VA2jI 8067AKxVWUGwA2048vs2IY020Ec7CjxVAFwI0_Jr4l8cAvFVAK0II2c7xJM28CjxkF64kE wVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0cI8IcVCY1x 0267AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7Cj xVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrV C2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE 7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Avz4vE14v_GF4l42xK82IYc2Ij64vIr4 1l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK 67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI 8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAv wI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14 v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07bYD7-UUUUU= X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: Re: [Softwires] early MIB Doctor review for draft-ietf-softwire-map-mib-07 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, 16 May 2017 07:13:13 -0000 Hi Bert, Please see my reply inline.=20 I have cc the email to the softwire WG so that the WG could see the MIB = Doctor's comments. >> In the MIB module itself: >> >> mapRuleID OBJECT-TYPE >> SYNTAX Integer32 (1..2147483647) >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "An identifier used to distinguish the multiple >>mapping >> rule which is unique with each CE in the same BR." >> ::=3D { mapRuleEntry 1 } >> >> Since this is an index object, it be better defined as unsigned 32. >> See RFC4181, section 4.6.1.1. Specifically page 15, which states >> - Unsigned32 with a range that excludes zero is >>RECOMMENDED for >> most index objects. It is acceptable to include zero in the >> range when it is semantically significant or when it is used = as >> the index value for a unique row with special properties. >>Such >> usage SHOULD be clearly documented in the DESCRIPTION >>clause. >> >> [fuyu]: I will change it into unsigned 32. >> >Pls also think about the question if the value can ever be zero for a = good >reason. >Normally INDEX object do not have a value of zero. [fuyu] Yes, since it is an index object and the value range is not = include zero. I think unsigned 32 is better. >> >> >> mapRuleIPv6PrefixType OBJECT-TYPE >> SYNTAX InetAddressType >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "This object MUST be set to the value of ipv6(2) to >> present the IPv6 address.It describes the >> address type of the mapRuleIPv6Prefix and >> mapRuleBRIPv6Address." >> >> Such MUST language is not recommended. The way to specify >>such >> mandatory >> value you best use the MODULE COMPLIANCE statement. Such is >> RECOMMENDED >> as per RFC4181, page 26 >> >> [fuyu]: I will delete the MUST in the updated version. >> >But if you change to InetAddressIPv6 and InetAddressIPv4 (as you state >below), then there is no need for an InetAddressType. [fuyu] :Yes, I will delete the object of mapRuleIPv6PrefixType and = mapRuleIPv4PrefixType too. Thank you for your remind. >> >> >> mapRuleIPv6Prefix OBJECT-TYPE >> SYNTAX InetAddress(SIZE (0..16)) >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The IPv6 prefix defined in mapping rule which will be >> assigned to CE. The address type is given by >> mapRuleIPv6PrefixType." >> ::=3D { mapRuleEntry 3 } >> >> mmmmm, when the InetAddressType is ipv6(2), then my >>understanding >> of RFC4001 >> is that the SIZE for the InetAddress MUST be 16. Maybe Juergen >> can chime in here? >> >> And if it is ALWAYS an IPv6 address, then maybe it is even better >> to use >> InetAddressIPv6 as the OBJECT-TYPE. >> >> I see the same set of 2 objects for IPv4. >> >> In my view, the idea of InetAddressType and InetAddress >>were/are >> to allow yopu to specify >> one or a single pair that can hold each of the 2 (or even more if >> needed) AddressTypes. >> >> So why are there separate objects for IPv4 and IPv6 ??? >> >> [fuyu]:OK, I will change it into >> >> mapRuleIPv6Prefix OBJECT-TYPE >> SYNTAX InetAddressIPv6 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The IPv6 prefix defined in mapping rule which will be >> assigned to CE. The address type is given by >> mapRuleIPv6PrefixType." >> ::=3D { mapRuleEntry 3 } >> >> mapRuleIPv4Prefix OBJECT-TYPE >> SYNTAX InetAddressIPv4 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> " The IPv4 prefix defined in mapping rule which will be >> assigned to CE. The address type is given by >> mapRuleIPv4PrefixType." >> ::=3D { mapRuleEntry 6 } >> >> Do you think it OK? >> >Yes. And you then do not need the InetAddressType object. [fuyu] : Yes, I will delete the objects of mapRuleIPv6PrefixType and = mapRuleIPv4PrefixType too. Thank you for your remind. >> >> >> mapRulePSID OBJECT-TYPE >> SYNTAX Integer32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The PSID value algorithmically identifies a set of >> ports assigned to a CE." >> REFERENCE >> "PSID: section 3 of RFC 7597." >> ::=3D { mapRuleEntry 9 } >> >> Mmmm... section 3 of RFC7597 only defines the term. The >> algorithm is in section 5.1 >> Maybe that is a better place to point to. >> Reading that section 5.1 in RFC7597, I wonder if "Integer32" is >> the best representation. >> In section 5.1, I see a PSID that is 6 bits (figure 2 on page >> 10). But there is also >> text about a PSID of 0x00 and 0xFF, which does not fit in 6 bits. >> I am not an expert (basically have no knowledge about) on >>RFC7597. >> But sofar I cannot >> determine what the value range might be and how Integer32 is a >> good representation for >> the PSID. Please explain (not just to me, but adding text to the >> internet drafts >> and the DESCRIPTION clause of this object) >> >> [fuyu]:Different PSID values guarantee non-overlapping port sets. >> The length of PSID is k bits, and the default value of PSID = offset is 6 >>bits. >> So the bit length of PSID is variable. Thank you for your = question. >> I have reconsidered the SYNTAS of the PSID. It can never be a >>negative value. >> I think Unsigned32 will be better. >> >So do you just map the 4 octets of the PSID into this object? >Is it not better to then use OCTET-STRING with a SIZE(4) ?? >Maybe with a DISPLY-HINT added as well > >Do you normally display the value as an (unsigned) integer? >Or do you normally display it as 0Xxxxxxxxx ?? >Or maybe as bits? [fuyu] We always describe a Basic mapping rule as below: A MAP node (CE or BR) can, via the BMR or equivalent FMR, determine the IPv4 address and port set as shown below: EA bits offset: 40 IPv4 suffix bits (p) Length of IPv4 address (32) - IPv4 prefix length (24) =3D 8 IPv4 address: 192.0.2.18 (0xc0000212) PSID start: 40 + p =3D 40 + 8 =3D 48 PSID length: o - p =3D (56 - 40) - 8 =3D 8 PSID: 0x34 (1232) So I think display the values as (unsigned) integer or display it as = 0Xxxxxxxxx both will be OK. Do you have the surggstions? >> >> >> mapRulePSIDLen OBJECT-TYPE >> SYNTAX Integer32 >> >> My understanding sofar is that this object can never take a >> negative value, >> so Unsigned32 would be better I think. >> >> [fuyu]: I will change it into Unsigned32 in the updated version. >> >Does it also make sense to add a range? (what are the possible values?) = ?? [fuyu] The value range of mapRulePSIDLen is greater than or equal to 0 = and no more than 16, so do you think define as below =20 mapRulePSIDLen OBJECT-TYPE SYNTAX Unsigned32(0..16) =20 Will it make sense? >> - Section 7. Security considerations: >> >> These are the objects and their sensitivity/vulnerability: >> >> mapRuleIPv6PrefixType >> >> mapRuleIPv6Prefix >> >> ... etc (quite a list of objects). >> >> But nowhere do I see text about "their >>sensitivity/vulnerability". ?? >> Still to be added? >> >> [fuyu]: Some of the readable objects in this MIB module may be >>considered sensitive or >> vulnerable in some network environments. These objects are >>readable, >> so maybe they are considered sensitive or vulnerable in some use >>case. >> We have a description why they are sensitive or vulnerable above = the >>list of objects. >> >Mmmm... can you point me to that text? I do not see that you describe = the >vulnerability at any place. You do describe what the objects are for, = but >that does not clearly explain what the security risks are if some >unauthorize person would see them. > >If you describe that at some other place in the document, then at least = I >would suggest to add a pointer to that text in the Security = COnsiderations >Secion. [fuyu]: Sorry. I should point it more clearly. It is in the paragraph 2 = of the section 7. From the first sentence that "Some of the readable objects in this = MIB module may be considered sensitive or vulnerable..." > >Bert Thanks a lot Yu From nobody Tue May 16 00:16:44 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 83EC91294A4 for ; Tue, 16 May 2017 00:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 nnwzFZcnTI6H for ; Tue, 16 May 2017 00:16:40 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 30FF3128D2E for ; Tue, 16 May 2017 00:12:59 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.213]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0A5Rrp6phpZeJixKg--.42591S3; Tue, 16 May 2017 15:12:58 +0800 (CST) From: "Yu Fu" To: Date: Tue, 16 May 2017 15:13:11 +0800 Message-ID: <002301d2ce13$e0ee9bc0$a2cbd340$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdLICzQDa7vUXcvIRTKNfLp9wiksMwAgXU3QAWG3JaA= Content-Language: zh-cn X-CM-TRANSID: AQAAf0A5Rrp6phpZeJixKg--.42591S3 X-Coremail-Antispam: 1UD129KBjvJXoW3Zw4UKrWxZw1DKr1fGrWUtwb_yoWDKr1kpa 9aya1YkrWDXr47CrZ7Xw4vgFyYyrWv9FW7Gr98Xry7C390yr97tF47K3ZY9a4DJr18ta1j v3yjvry5Grs8AaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkFb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMxkIecxEwVAFwVW8CwCF04k2 0xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI 8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jr0_JrylIxkGc2Ij64vIr41l IxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIx AIcVCF04k26cxKx2IYs7xG6Fyj6rWUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07b5iiDUUUUU= X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: [Softwires] FW: early MIB Doctor review for draft-ietf-softwire-map-mib-07 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, 16 May 2017 07:16:42 -0000 It is the background of the discussion of my last email.=20 -----Original Message----- From: fuyu@cnnic.cn [mailto:fuyu@cnnic.cn]=20 Sent: Friday, May 12, 2017 12:40 PM To: bertietf@bwijnen.net Cc: draft-ietf-softwire-map-mib.all@ietf.org; 'MIB Doctors' Subject: RE: early MIB Doctor review for draft-ietf-softwire-map-mib-07 Hi Bert, Thanks a lot for your thorough MIB doctor review.=20 Because I have a fever in the early of this week, sorry to reply you a = little late.=20 Please see my reply inline. >>-----Original Message----- >>From: bertietf@bwijnen.net [mailto:bertietf@bwijnen.net] >>Sent: Monday, May 08, 2017 10:56 PM >>To: draft-ietf-softwire-map-mib.all@ietf.org; MIB Doctors >>Subject: early MIB Doctor review for draft-ietf-softwire-map-mib-07 >> >>[not sure if draft-ietf-softwire-map-mib.all@ietf.org also includes=20 >>the softwire WG mailing list. Anyways, I am not subscribed to that WG=20 >>list, so I probably can't post there. Pls WG chairs forward if = needed/wanted]. >> >>I did an early MIB doctor review for this document. >> >>The syntax check with SMICNG is clean. Great. >> >>My comments/questions: >> >>- section 4 states: >> The MAP-E MIB provides a way to configure and monitor the MAP=20 >>devices >> in MAP encapsulation mode through SNMP. >> Yet there are no read-write or read-create objects defined in the = MIB >> module. So I don't think you can "configure" anything on the MAP=20 >>devices >> via SNMP with this MIB module >> >>- section 4.1.1 states: >> The mapRule subtree describes managed objects used for managing=20 >>the >> multiple mapping rules in the MAP encapsulation mode. >> So, since the MIB module is read-only, I think I would change >> s/managing/monitoring/. But maybe that is just a wording choice. [fuyu] : We will change the "configure and monitor" to "manage and = monitor". Thanks. >>- section 4.1.2 >> - The BR MUST perform a validation of the consistency of the=20 >>source >> IPv6 address and source port number for the packet using BMR. >> >> - The Customer Edge (CE) SHOULD check that MAP received=20 >>packets' >> transport-layer destination port number is in the range=20 >>configured by >> MAP for the CE. >> Mmmm... what is BR ? Please expand the acronym the first time you=20 >>use it in your document. Same for BMR. [fuyu] : I will add the explanation for acronym in the updated version.=20 >> I am not sure that the MIB document is the place to tell=20 >>(normatively >>(MUST/SHOULD) >> a BR that it MUST perform a certain protocol function. That is (I >>assume) specified >> in the RFC7597 itself, right? >> Maybe you mean to say that the BR (and CE) MUST and SHOULD report=20 >>any invalid >> packets as found per the rules in RFC7579. They MUST/SHOULD report = >>them via this >> MIB module (as per your MODULE Conformance). >> Oh well, again this may be a wording issue. >> If my interpretation here is correct, I can live with your wording = >>although I think >> it can be clearer and that the proper compliance language is in=20 >>the proper document. [fuyu] Yes, it is a good suggestion. The protocol function requirement = is specified in RFC7597. So we will change the description and delete MUST/SHOULD language. >> >>- section 5. >> I think I would change: >> >> 5. Definitions >> >> MAP-E-MIB DEFINITIONS ::=3D BEGIN >> >> >> IMPORTS >> MODULE-IDENTITY, OBJECT-TYPE, mib-2, >> Integer32, Unsigned32, Counter64 >> FROM SNMPv2-SMI >> ifIndex >> FROM IF-MIB >> InetAddressType, InetAddress, >> InetAddressPrefixLength >> FROM INET-ADDRESS-MIB >> OBJECT-GROUP, MODULE-COMPLIANCE >> FROM SNMPv2-CONF; >> >> Into >> >> 5. Definitions >> >> The following MIB module imports definitions from [RFC2578],=20 >>[RFC2580], >> [RFC2863], and [RFC4001]. >> >> MAP-E-MIB DEFINITIONS ::=3D BEGIN >> >> >> IMPORTS >> MODULE-IDENTITY, OBJECT-TYPE, mib-2, >> Integer32, Unsigned32, Counter64 >> FROM SNMPv2-SMI -- RFC2578 >> ifIndex >> FROM IF-MIB -- RFC2863 >> InetAddressType, InetAddress, >> InetAddressPrefixLength >> FROM INET-ADDRESS-MIB -- RFC4001 >> OBJECT-GROUP, MODULE-COMPLIANCE >> FROM SNMPv2-CONF; -- RFC2580 >> >> That way, you have a reference to each document (they are all >>normative) >> and in the MIB module itself (where you cannot put >>references/citations) you >> would still have document which RFC the imports are from. Handy=20 >>when a MIB module >> has been extracted from an RFC. [fuyu]: Yes, it is more clear. Thanks, I will change it in the updated = version. >>In the MIB module itself: >> >> mapRuleID OBJECT-TYPE >> SYNTAX Integer32 (1..2147483647) >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "An identifier used to distinguish the multiple mapping >> rule which is unique with each CE in the same BR." >> ::=3D { mapRuleEntry 1 } >> >> Since this is an index object, it be better defined as unsigned 32. >> See RFC4181, section 4.6.1.1. Specifically page 15, which states >> - Unsigned32 with a range that excludes zero is RECOMMENDED for >> most index objects. It is acceptable to include zero in the >> range when it is semantically significant or when it is used = as >> the index value for a unique row with special properties. = Such >> usage SHOULD be clearly documented in the DESCRIPTION clause. [fuyu]: I will change it into unsigned 32. >> >> mapRuleIPv6PrefixType OBJECT-TYPE >> SYNTAX InetAddressType >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "This object MUST be set to the value of ipv6(2) to >> present the IPv6 address.It describes the >> address type of the mapRuleIPv6Prefix and >> mapRuleBRIPv6Address." >> >> Such MUST language is not recommended. The way to specify such=20 >>mandatory >> value you best use the MODULE COMPLIANCE statement. Such is=20 >>RECOMMENDED >> as per RFC4181, page 26 [fuyu]: I will delete the MUST in the updated version. >> >> mapRuleIPv6Prefix OBJECT-TYPE >> SYNTAX InetAddress(SIZE (0..16)) >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The IPv6 prefix defined in mapping rule which will be >> assigned to CE. The address type is given by >> mapRuleIPv6PrefixType." >> ::=3D { mapRuleEntry 3 } >> >> mmmmm, when the InetAddressType is ipv6(2), then my understanding=20 >>of RFC4001 >> is that the SIZE for the InetAddress MUST be 16. Maybe Juergen can = >>chime in here? >> >> And if it is ALWAYS an IPv6 address, then maybe it is even better=20 >>to use >> InetAddressIPv6 as the OBJECT-TYPE. >> >> I see the same set of 2 objects for IPv4. >> >> In my view, the idea of InetAddressType and InetAddress were/are=20 >>to allow yopu to specify >> one or a single pair that can hold each of the 2 (or even more if >>needed) AddressTypes. >> >> So why are there separate objects for IPv4 and IPv6 ??? [fuyu]:OK, I will change it into=20 mapRuleIPv6Prefix OBJECT-TYPE SYNTAX InetAddressIPv6 MAX-ACCESS read-only STATUS current DESCRIPTION "The IPv6 prefix defined in mapping rule which will be assigned to CE. The address type is given by mapRuleIPv6PrefixType." ::=3D { mapRuleEntry 3 } mapRuleIPv4Prefix OBJECT-TYPE SYNTAX InetAddressIPv4 MAX-ACCESS read-only STATUS current DESCRIPTION " The IPv4 prefix defined in mapping rule which will be assigned to CE. The address type is given by mapRuleIPv4PrefixType." ::=3D { mapRuleEntry 6 } Do you think it OK? >> >> mapRulePSID OBJECT-TYPE >> SYNTAX Integer32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The PSID value algorithmically identifies a set of >> ports assigned to a CE." >> REFERENCE >> "PSID: section 3 of RFC 7597." >> ::=3D { mapRuleEntry 9 } >> >> Mmmm... section 3 of RFC7597 only defines the term. The algorithm = >>is in section 5.1 >> Maybe that is a better place to point to. >> Reading that section 5.1 in RFC7597, I wonder if "Integer32" is=20 >>the best representation. >> In section 5.1, I see a PSID that is 6 bits (figure 2 on page=20 >>10). But there is also >> text about a PSID of 0x00 and 0xFF, which does not fit in 6 bits. >> I am not an expert (basically have no knowledge about) on = RFC7597. >>But sofar I cannot >> determine what the value range might be and how Integer32 is a=20 >>good representation for >> the PSID. Please explain (not just to me, but adding text to the=20 >>internet drafts >> and the DESCRIPTION clause of this object) [fuyu]:Different PSID values guarantee non-overlapping port sets. The length of PSID is k bits, and the default value of PSID offset = is 6 bits. So the bit length of PSID is variable. Thank you for your question. I have reconsidered the SYNTAS of the PSID. It can never be a = negative value. I think Unsigned32 will be better. =20 >> >> mapRulePSIDLen OBJECT-TYPE >> SYNTAX Integer32 >> >> My understanding sofar is that this object can never take a=20 >>negative value, >> so Unsigned32 would be better I think. [fuyu]: I will change it into Unsigned32 in the updated version. >> >> mapRuleType OBJECT-TYPE >> SYNTAX Integer32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The type of the mapping rule. A value of 0 means it >> >> is a BMR; a non-zero value means it is a FMR." >> REFERENCE >> "BMR, FMR: section 5 of RFC 7597." >> ::=3D { mapRuleEntry 13 } >> >> That probably works. But it is probably much better to do a=20 >>ENUMERATION, Which >> has a SYNTAX of INTEGER and then lists enumberated values. That=20 >>makes it much >> more extensible in the future (if needed). [fuyu]: Thanks for your suggestion. I will updated it in the next = version. >> mapMIBSecurityGroup OBJECT-GROUP >> OBJECTS { >> mapSecurityCheckInvalidv4, >> mapSecurityCheckInvalidv6 } >> STATUS current >> DESCRIPTION >> " The collection of this objects are used to give the >> information on MAP security checks." >> ::=3D { mapMIBGroups 2 } >> >> These objects are defined with ACCESS accessible-for-notify. I=20 >>think that means >> you have to define this group as a NOTIFICATION-GROUP instead of=20 >>an OBJECT-GROUP. [fuyu]: mapSecurityCheckInvalidv4 and mapSecurityCheckInvalidv6 indicate = the number of the invalid IPv4 or IPv6 packets received by the MAP-E. So I think define this group as OBJECT-GROUP will be = better. I will change the ACCESS of these objects from = accessible-for-notify into read-only. >> - Section 7. Security considerations: >> >> These are the objects and their sensitivity/vulnerability: >> >> mapRuleIPv6PrefixType >> >> mapRuleIPv6Prefix >> >> ... etc (quite a list of objects). >> >> But nowhere do I see text about "their = sensitivity/vulnerability". ?? >> Still to be added? [fuyu]: Some of the readable objects in this MIB module may be = considered sensitive or vulnerable in some network environments. These objects are readable,=20 so maybe they are considered sensitive or vulnerable in some use = case. We have a description why they are sensitive or vulnerable above the = list of objects. >>Bert Thanks again for your MIB doctor review. Cheers Yu From nobody Tue May 16 00:19:33 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 173D21293E8 for ; Tue, 16 May 2017 00:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 n8k3ULkW_giR for ; Tue, 16 May 2017 00:19:28 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id F1EAC129BCF for ; Tue, 16 May 2017 00:15:50 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.213]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0CJkVUlpxpZnZixKg--.40235S3; Tue, 16 May 2017 15:15:49 +0800 (CST) From: "Yu Fu" To: Date: Tue, 16 May 2017 15:16:02 +0800 Message-ID: <002401d2ce14$46a01610$d3e04230$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdLLMSykTIsGdc6vTs2xoyIvKUAXjQC4twFw Content-Language: zh-cn X-CM-TRANSID: AQAAf0CJkVUlpxpZnZixKg--.40235S3 X-Coremail-Antispam: 1UD129KBjvAXoW3CF4DCry7WryUGw15tw43ZFb_yoW8Jr4fWo Za9wn2qa1rtrykZF4rK34kK3y5X3WfKw4fArWYqr15AFsYq3WYkw1xAw4DtFZxKr4UGwn7 Ja4rJa4rZFWYqFn3n29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73VFW2AGmfu7bjvjm3 AaLaJ3UjIYCTnIWjp_UUUYI7k0a2IF6w4kM7kC6x804xWl14x267AKxVWUJVW8JwAFc2x0 x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj4 1l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26F1j6w1UM28EF7xvwVC0 I7IYx2IY6xkF7I0E14v26r4UJVWxJr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xv F2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jrv_JF1lYx0Ex4A2jsIE14v26r1j6r 4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Avz4vE14v_GF4l42xK 82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1l4IxYO2xFxVAFwI0_Jrv_JF1lx2 IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v2 6r1j6r15MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2 IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVW3JVWrJr1lIxAIcVC2z280 aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyT uYvjxUgHanUUUUU X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: [Softwires] FW: early MIB Doctor review for draft-ietf-softwire-map-mib-07 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, 16 May 2017 07:19:31 -0000 Just forward the discussion to the softwire WG. -----Original Message----- From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net]=20 Sent: Friday, May 12, 2017 11:05 PM To: Yu Fu Cc: draft-ietf-softwire-map-mib.all@ietf.org; 'MIB Doctors' Subject: Re: early MIB Doctor review for draft-ietf-softwire-map-mib-07 inline On 12/05/2017 06:39, Yu Fu wrote: > Hi Bert, > > Thanks a lot for your thorough MIB doctor review. > Because I have a fever in the early of this week, sorry to reply you a = little late. > no problem > Please see my reply inline. > >>> -----Original Message----- >>> From: bertietf@bwijnen.net [mailto:bertietf@bwijnen.net] >>> Sent: Monday, May 08, 2017 10:56 PM >>> To: draft-ietf-softwire-map-mib.all@ietf.org; MIB Doctors >>> Subject: early MIB Doctor review for draft-ietf-softwire-map-mib-07 >>> >>> [not sure if draft-ietf-softwire-map-mib.all@ietf.org also includes=20 >>> the softwire WG mailing list. Anyways, I am not subscribed to that=20 >>> WG list, so I probably can't post there. Pls WG chairs forward if = needed/wanted]. >>> >>> I did an early MIB doctor review for this document. >>> >>> The syntax check with SMICNG is clean. Great. >>> >>> My comments/questions: >>> >>> - section 4 states: >>> The MAP-E MIB provides a way to configure and monitor the MAP=20 >>> devices >>> in MAP encapsulation mode through SNMP. >>> Yet there are no read-write or read-create objects defined in the = MIB >>> module. So I don't think you can "configure" anything on the MAP=20 >>> devices >>> via SNMP with this MIB module >>> >>> - section 4.1.1 states: >>> The mapRule subtree describes managed objects used for managing=20 >>> the >>> multiple mapping rules in the MAP encapsulation mode. >>> So, since the MIB module is read-only, I think I would change >>> s/managing/monitoring/. But maybe that is just a wording choice. > > [fuyu] : We will change the "configure and monitor" to "manage and = monitor". Thanks. > ok >>> - section 4.1.2 >>> - The BR MUST perform a validation of the consistency of the=20 >>> source >>> IPv6 address and source port number for the packet using = BMR. >>> >>> - The Customer Edge (CE) SHOULD check that MAP received=20 >>> packets' >>> transport-layer destination port number is in the range=20 >>> configured by >>> MAP for the CE. >>> Mmmm... what is BR ? Please expand the acronym the first time you = >>> use it in your document. Same for BMR. > > [fuyu] : I will add the explanation for acronym in the updated = version. > great >>> I am not sure that the MIB document is the place to tell=20 >>> (normatively >>> (MUST/SHOULD) >>> a BR that it MUST perform a certain protocol function. That is (I >>> assume) specified >>> in the RFC7597 itself, right? >>> Maybe you mean to say that the BR (and CE) MUST and SHOULD report = >>> any invalid >>> packets as found per the rules in RFC7579. They MUST/SHOULD=20 >>> report them via this >>> MIB module (as per your MODULE Conformance). >>> Oh well, again this may be a wording issue. >>> If my interpretation here is correct, I can live with your=20 >>> wording although I think >>> it can be clearer and that the proper compliance language is in=20 >>> the proper document. > > [fuyu] Yes, it is a good suggestion. The protocol function requirement = is specified in RFC7597. > So we will change the description and delete MUST/SHOULD = language. >>> ok >>> - section 5. >>> I think I would change: >>> >>> 5. Definitions >>> >>> MAP-E-MIB DEFINITIONS ::=3D BEGIN >>> >>> >>> IMPORTS >>> MODULE-IDENTITY, OBJECT-TYPE, mib-2, >>> Integer32, Unsigned32, Counter64 >>> FROM SNMPv2-SMI >>> ifIndex >>> FROM IF-MIB >>> InetAddressType, InetAddress, >>> InetAddressPrefixLength >>> FROM INET-ADDRESS-MIB >>> OBJECT-GROUP, MODULE-COMPLIANCE >>> FROM SNMPv2-CONF; >>> >>> Into >>> >>> 5. Definitions >>> >>> The following MIB module imports definitions from [RFC2578],=20 >>> [RFC2580], >>> [RFC2863], and [RFC4001]. >>> >>> MAP-E-MIB DEFINITIONS ::=3D BEGIN >>> >>> >>> IMPORTS >>> MODULE-IDENTITY, OBJECT-TYPE, mib-2, >>> Integer32, Unsigned32, Counter64 >>> FROM SNMPv2-SMI -- RFC2578 >>> ifIndex >>> FROM IF-MIB -- RFC2863 >>> InetAddressType, InetAddress, >>> InetAddressPrefixLength >>> FROM INET-ADDRESS-MIB -- RFC4001 >>> OBJECT-GROUP, MODULE-COMPLIANCE >>> FROM SNMPv2-CONF; -- RFC2580 >>> >>> That way, you have a reference to each document (they are all >>> normative) >>> and in the MIB module itself (where you cannot put >>> references/citations) you >>> would still have document which RFC the imports are from. Handy = >>> when a MIB module >>> has been extracted from an RFC. > > [fuyu]: Yes, it is more clear. Thanks, I will change it in the updated = version. > ok >>> In the MIB module itself: >>> >>> mapRuleID OBJECT-TYPE >>> SYNTAX Integer32 (1..2147483647) >>> MAX-ACCESS not-accessible >>> STATUS current >>> DESCRIPTION >>> "An identifier used to distinguish the multiple mapping >>> rule which is unique with each CE in the same BR." >>> ::=3D { mapRuleEntry 1 } >>> >>> Since this is an index object, it be better defined as unsigned = 32. >>> See RFC4181, section 4.6.1.1. Specifically page 15, which states >>> - Unsigned32 with a range that excludes zero is RECOMMENDED for >>> most index objects. It is acceptable to include zero in the >>> range when it is semantically significant or when it is used = as >>> the index value for a unique row with special properties. = Such >>> usage SHOULD be clearly documented in the DESCRIPTION clause. > > [fuyu]: I will change it into unsigned 32. > Pls also think about the question if the value can ever be zero for a = good reason. Normally INDEX object do not have a value of zero. >>> >>> mapRuleIPv6PrefixType OBJECT-TYPE >>> SYNTAX InetAddressType >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "This object MUST be set to the value of ipv6(2) to >>> present the IPv6 address.It describes the >>> address type of the mapRuleIPv6Prefix and >>> mapRuleBRIPv6Address." >>> >>> Such MUST language is not recommended. The way to specify such=20 >>> mandatory >>> value you best use the MODULE COMPLIANCE statement. Such is=20 >>> RECOMMENDED >>> as per RFC4181, page 26 > > [fuyu]: I will delete the MUST in the updated version. > But if you change to InetAddressIPv6 and InetAddressIPv4 (as you state = below), then there is no need for an InetAddressType. >>> >>> mapRuleIPv6Prefix OBJECT-TYPE >>> SYNTAX InetAddress(SIZE (0..16)) >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "The IPv6 prefix defined in mapping rule which will be >>> assigned to CE. The address type is given by >>> mapRuleIPv6PrefixType." >>> ::=3D { mapRuleEntry 3 } >>> >>> mmmmm, when the InetAddressType is ipv6(2), then my understanding = >>> of RFC4001 >>> is that the SIZE for the InetAddress MUST be 16. Maybe Juergen=20 >>> can chime in here? >>> >>> And if it is ALWAYS an IPv6 address, then maybe it is even better = >>> to use >>> InetAddressIPv6 as the OBJECT-TYPE. >>> >>> I see the same set of 2 objects for IPv4. >>> >>> In my view, the idea of InetAddressType and InetAddress were/are=20 >>> to allow yopu to specify >>> one or a single pair that can hold each of the 2 (or even more if >>> needed) AddressTypes. >>> >>> So why are there separate objects for IPv4 and IPv6 ??? > > [fuyu]:OK, I will change it into > > mapRuleIPv6Prefix OBJECT-TYPE > SYNTAX InetAddressIPv6 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The IPv6 prefix defined in mapping rule which will be > assigned to CE. The address type is given by > mapRuleIPv6PrefixType." > ::=3D { mapRuleEntry 3 } > > mapRuleIPv4Prefix OBJECT-TYPE > SYNTAX InetAddressIPv4 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > " The IPv4 prefix defined in mapping rule which will be > assigned to CE. The address type is given by > mapRuleIPv4PrefixType." > ::=3D { mapRuleEntry 6 } > > Do you think it OK? > Yes. And you then do not need the InetAddressType object. >>> >>> mapRulePSID OBJECT-TYPE >>> SYNTAX Integer32 >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "The PSID value algorithmically identifies a set of >>> ports assigned to a CE." >>> REFERENCE >>> "PSID: section 3 of RFC 7597." >>> ::=3D { mapRuleEntry 9 } >>> >>> Mmmm... section 3 of RFC7597 only defines the term. The=20 >>> algorithm is in section 5.1 >>> Maybe that is a better place to point to. >>> Reading that section 5.1 in RFC7597, I wonder if "Integer32" is=20 >>> the best representation. >>> In section 5.1, I see a PSID that is 6 bits (figure 2 on page=20 >>> 10). But there is also >>> text about a PSID of 0x00 and 0xFF, which does not fit in 6 = bits. >>> I am not an expert (basically have no knowledge about) on = RFC7597. >>> But sofar I cannot >>> determine what the value range might be and how Integer32 is a=20 >>> good representation for >>> the PSID. Please explain (not just to me, but adding text to the = >>> internet drafts >>> and the DESCRIPTION clause of this object) > > [fuyu]:Different PSID values guarantee non-overlapping port sets. > The length of PSID is k bits, and the default value of PSID = offset is 6 bits. > So the bit length of PSID is variable. Thank you for your = question. > I have reconsidered the SYNTAS of the PSID. It can never be a = negative value. > I think Unsigned32 will be better. > So do you just map the 4 octets of the PSID into this object? Is it not better to then use OCTET-STRING with a SIZE(4) ?? Maybe with a DISPLY-HINT added as well Do you normally display the value as an (unsigned) integer? Or do you normally display it as 0Xxxxxxxxx ?? Or maybe as bits? >>> >>> mapRulePSIDLen OBJECT-TYPE >>> SYNTAX Integer32 >>> >>> My understanding sofar is that this object can never take a=20 >>> negative value, >>> so Unsigned32 would be better I think. > > [fuyu]: I will change it into Unsigned32 in the updated version. Does it also make sense to add a range? (what are the possible values?) = ?? >>> >>> mapRuleType OBJECT-TYPE >>> SYNTAX Integer32 >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "The type of the mapping rule. A value of 0 means it >>> >>> is a BMR; a non-zero value means it is a FMR." >>> REFERENCE >>> "BMR, FMR: section 5 of RFC 7597." >>> ::=3D { mapRuleEntry 13 } >>> >>> That probably works. But it is probably much better to do a=20 >>> ENUMERATION, Which >>> has a SYNTAX of INTEGER and then lists enumberated values. That=20 >>> makes it much >>> more extensible in the future (if needed). > > [fuyu]: Thanks for your suggestion. I will updated it in the next = version. > ok > >>> mapMIBSecurityGroup OBJECT-GROUP >>> OBJECTS { >>> mapSecurityCheckInvalidv4, >>> mapSecurityCheckInvalidv6 } >>> STATUS current >>> DESCRIPTION >>> " The collection of this objects are used to give the >>> information on MAP security checks." >>> ::=3D { mapMIBGroups 2 } >>> >>> These objects are defined with ACCESS accessible-for-notify. I=20 >>> think that means >>> you have to define this group as a NOTIFICATION-GROUP instead of=20 >>> an OBJECT-GROUP. > > [fuyu]: mapSecurityCheckInvalidv4 and mapSecurityCheckInvalidv6 = indicate the number of the invalid IPv4 or IPv6 packets received by the > MAP-E. So I think define this group as OBJECT-GROUP will be = better. > I will change the ACCESS of these objects from = accessible-for-notify into read-only. > OK >>> - Section 7. Security considerations: >>> >>> These are the objects and their sensitivity/vulnerability: >>> >>> mapRuleIPv6PrefixType >>> >>> mapRuleIPv6Prefix >>> >>> ... etc (quite a list of objects). >>> >>> But nowhere do I see text about "their = sensitivity/vulnerability". ?? >>> Still to be added? > > [fuyu]: Some of the readable objects in this MIB module may be = considered sensitive or > vulnerable in some network environments. These objects are = readable, > so maybe they are considered sensitive or vulnerable in some use = case. > We have a description why they are sensitive or vulnerable above = the list of objects. > Mmmm... can you point me to that text? I do not see that you describe = the vulnerability at any place. You do describe what the objects are = for, but that does not clearly explain what the security risks are if = some unauthorize person would see them. If you describe that at some other place in the document, then at least = I would suggest to add a pointer to that text in the Security = COnsiderations Secion. Bert >>> Bert > > Thanks again for your MIB doctor review. > > Cheers > Yu > > > From nobody Tue May 16 01:19: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 99E3E12EB1D for ; Tue, 16 May 2017 01:19:19 -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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 tlfgRXo486Pi for ; Tue, 16 May 2017 01:19:15 -0700 (PDT) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C640512943D for ; Tue, 16 May 2017 01:15:37 -0700 (PDT) Received: from Macintosh-4.fritz.box ([IPv6:2001:981:602b:1:a860:6f3c:de7:5417]) by smtp-cloud2.xs4all.net with ESMTP id LwFY1v0020Xfuf201wFZ3d; Tue, 16 May 2017 10:15:35 +0200 To: Yu Fu References: <003201d2cad9$c83bec50$58b3c4f0$@cn> <6874911d-0535-8206-d96d-99a956c5bf85@bwijnen.net> <002201d2ce13$73ccd570$5b668050$@cn> Cc: draft-ietf-softwire-map-mib.all@ietf.org, 'MIB Doctors' , softwires@ietf.org From: "Bert Wijnen (IETF)" Message-ID: <27ba3af4-49b4-17ee-a0f9-cb280a5141cb@bwijnen.net> Date: Tue, 16 May 2017 10:15:33 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <002201d2ce13$73ccd570$5b668050$@cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Softwires] early MIB Doctor review for draft-ietf-softwire-map-mib-07 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, 16 May 2017 08:19:20 -0000 inline On 16/05/2017 09:10, Yu Fu wrote: > Hi Bert, > > Please see my reply inline. > > I have cc the email to the softwire WG so that the WG could see the MIB Doctor's comments. > >>> In the MIB module itself: >>> >>> mapRuleID OBJECT-TYPE >>> SYNTAX Integer32 (1..2147483647) >>> MAX-ACCESS not-accessible >>> STATUS current >>> DESCRIPTION >>> "An identifier used to distinguish the multiple >>> mapping >>> rule which is unique with each CE in the same BR." >>> ::= { mapRuleEntry 1 } >>> >>> Since this is an index object, it be better defined as unsigned 32. >>> See RFC4181, section 4.6.1.1. Specifically page 15, which states >>> - Unsigned32 with a range that excludes zero is >>> RECOMMENDED for >>> most index objects. It is acceptable to include zero in the >>> range when it is semantically significant or when it is used as >>> the index value for a unique row with special properties. >>> Such >>> usage SHOULD be clearly documented in the DESCRIPTION >>> clause. >>> >>> [fuyu]: I will change it into unsigned 32. >>> >> Pls also think about the question if the value can ever be zero for a good >> reason. >> Normally INDEX object do not have a value of zero. > > [fuyu] Yes, since it is an index object and the value range is not include zero. I think unsigned 32 is better. > OK, but then the definition would better be: SYNTAX Unsigned32 (1..4294967295) That wat it is machinereadably clear that valu 0 is not valid. >>> >>> >>> mapRuleIPv6PrefixType OBJECT-TYPE >>> SYNTAX InetAddressType >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "This object MUST be set to the value of ipv6(2) to >>> present the IPv6 address.It describes the >>> address type of the mapRuleIPv6Prefix and >>> mapRuleBRIPv6Address." >>> >>> Such MUST language is not recommended. The way to specify >>> such >>> mandatory >>> value you best use the MODULE COMPLIANCE statement. Such is >>> RECOMMENDED >>> as per RFC4181, page 26 >>> >>> [fuyu]: I will delete the MUST in the updated version. >>> >> But if you change to InetAddressIPv6 and InetAddressIPv4 (as you state >> below), then there is no need for an InetAddressType. > > > [fuyu] :Yes, I will delete the object of mapRuleIPv6PrefixType and mapRuleIPv4PrefixType too. Thank you for your remind. > OK >>> >>> >>> mapRuleIPv6Prefix OBJECT-TYPE >>> SYNTAX InetAddress(SIZE (0..16)) >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "The IPv6 prefix defined in mapping rule which will be >>> assigned to CE. The address type is given by >>> mapRuleIPv6PrefixType." >>> ::= { mapRuleEntry 3 } >>> >>> mmmmm, when the InetAddressType is ipv6(2), then my >>> understanding >>> of RFC4001 >>> is that the SIZE for the InetAddress MUST be 16. Maybe Juergen >>> can chime in here? >>> >>> And if it is ALWAYS an IPv6 address, then maybe it is even better >>> to use >>> InetAddressIPv6 as the OBJECT-TYPE. >>> >>> I see the same set of 2 objects for IPv4. >>> >>> In my view, the idea of InetAddressType and InetAddress >>> were/are >>> to allow yopu to specify >>> one or a single pair that can hold each of the 2 (or even more if >>> needed) AddressTypes. >>> >>> So why are there separate objects for IPv4 and IPv6 ??? >>> >>> [fuyu]:OK, I will change it into >>> >>> mapRuleIPv6Prefix OBJECT-TYPE >>> SYNTAX InetAddressIPv6 >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "The IPv6 prefix defined in mapping rule which will be >>> assigned to CE. The address type is given by >>> mapRuleIPv6PrefixType." >>> ::= { mapRuleEntry 3 } >>> >>> mapRuleIPv4Prefix OBJECT-TYPE >>> SYNTAX InetAddressIPv4 >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> " The IPv4 prefix defined in mapping rule which will be >>> assigned to CE. The address type is given by >>> mapRuleIPv4PrefixType." >>> ::= { mapRuleEntry 6 } >>> >>> Do you think it OK? >>> >> Yes. And you then do not need the InetAddressType object. > > [fuyu] : Yes, I will delete the objects of mapRuleIPv6PrefixType and mapRuleIPv4PrefixType too. Thank you for your remind. > ok >>> >>> >>> mapRulePSID OBJECT-TYPE >>> SYNTAX Integer32 >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "The PSID value algorithmically identifies a set of >>> ports assigned to a CE." >>> REFERENCE >>> "PSID: section 3 of RFC 7597." >>> ::= { mapRuleEntry 9 } >>> >>> Mmmm... section 3 of RFC7597 only defines the term. The >>> algorithm is in section 5.1 >>> Maybe that is a better place to point to. >>> Reading that section 5.1 in RFC7597, I wonder if "Integer32" is >>> the best representation. >>> In section 5.1, I see a PSID that is 6 bits (figure 2 on page >>> 10). But there is also >>> text about a PSID of 0x00 and 0xFF, which does not fit in 6 bits. >>> I am not an expert (basically have no knowledge about) on >>> RFC7597. >>> But sofar I cannot >>> determine what the value range might be and how Integer32 is a >>> good representation for >>> the PSID. Please explain (not just to me, but adding text to the >>> internet drafts >>> and the DESCRIPTION clause of this object) >>> >>> [fuyu]:Different PSID values guarantee non-overlapping port sets. >>> The length of PSID is k bits, and the default value of PSID offset is 6 >>> bits. >>> So the bit length of PSID is variable. Thank you for your question. >>> I have reconsidered the SYNTAS of the PSID. It can never be a >>> negative value. >>> I think Unsigned32 will be better. >>> >> So do you just map the 4 octets of the PSID into this object? >> Is it not better to then use OCTET-STRING with a SIZE(4) ?? >> Maybe with a DISPLY-HINT added as well >> >> Do you normally display the value as an (unsigned) integer? >> Or do you normally display it as 0Xxxxxxxxx ?? >> Or maybe as bits? > > [fuyu] We always describe a Basic mapping rule as below: > > A MAP node (CE or BR) can, via the BMR or equivalent FMR, > determine the IPv4 address and port set as shown below: > > EA bits offset: 40 > IPv4 suffix bits (p) Length of IPv4 address (32) - > IPv4 prefix length (24) = 8 > IPv4 address: 192.0.2.18 (0xc0000212) > PSID start: 40 + p = 40 + 8 = 48 > PSID length: o - p = (56 - 40) - 8 = 8 > PSID: 0x34 (1232) > Not sure I understand: 0x34 (1232) ??? 0x34 in my mind is 52, no? In fact I am not sure I understand much/any of the above. But that is OK, if people who are familiar with (or must use/implement) this and if they understand it then fine. > So I think display the values as (unsigned) integer or display it as 0Xxxxxxxxx both will be OK. > Do you have the surggstions? > My personal feeling/thinking is that it is probably best displayed as 0Xxxxxxxxx. That (I would think) makes it easier to see bit positions as opposed to an (unsigned) integer. But in princople I can live with either. The idea/hope is that if you add a DISPLAY HINT that everyone displays it in the same way. >>> >>> >>> mapRulePSIDLen OBJECT-TYPE >>> SYNTAX Integer32 >>> >>> My understanding sofar is that this object can never take a >>> negative value, >>> so Unsigned32 would be better I think. >>> >>> [fuyu]: I will change it into Unsigned32 in the updated version. >>> >> Does it also make sense to add a range? (what are the possible values?) ?? > > [fuyu] The value range of mapRulePSIDLen is greater than or equal to 0 and no more than 16, so do you think define as below > > mapRulePSIDLen OBJECT-TYPE > SYNTAX Unsigned32(0..16) > > Will it make sense? > > I think that makes sense. Now you can see (machine readable) what the range of valid values is. >>> - Section 7. Security considerations: >>> >>> These are the objects and their sensitivity/vulnerability: >>> >>> mapRuleIPv6PrefixType >>> >>> mapRuleIPv6Prefix >>> >>> ... etc (quite a list of objects). >>> >>> But nowhere do I see text about "their >>> sensitivity/vulnerability". ?? >>> Still to be added? >>> >>> [fuyu]: Some of the readable objects in this MIB module may be >>> considered sensitive or >>> vulnerable in some network environments. These objects are >>> readable, >>> so maybe they are considered sensitive or vulnerable in some use >>> case. >>> We have a description why they are sensitive or vulnerable above the >>> list of objects. >>> >> Mmmm... can you point me to that text? I do not see that you describe the >> vulnerability at any place. You do describe what the objects are for, but >> that does not clearly explain what the security risks are if some >> unauthorize person would see them. >> >> If you describe that at some other place in the document, then at least I >> would suggest to add a pointer to that text in the Security COnsiderations >> Secion. > > [fuyu]: Sorry. I should point it more clearly. It is in the paragraph 2 of the section 7. > From the first sentence that "Some of the readable objects in this MIB module may be > considered sensitive or vulnerable..." >> It states that they " may be considered sensitive of vulnerable". But it does not state WHY or IN WHAT CIRCUMSTANCES they might be vulnerable. What bad things are there that an intruder can do (or find out) when he/she gets read access to these objects? I.e. does he get to see confidential or private information? Does he learn about a competitors internal network structure? Or something else? Bert >> Bert > > Thanks a lot > > Yu > > > From nobody Wed May 17 00:19: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 955021293DA; Wed, 17 May 2017 00:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.797 X-Spam-Level: X-Spam-Status: No, score=0.797 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 F8npT_pZmwc0; Wed, 17 May 2017 00:19:18 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id F0639129BFF; Wed, 17 May 2017 00:15:59 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.89]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0CpsuKi+BtZoOuxKg--.42393S3; Wed, 17 May 2017 15:15:46 +0800 (CST) From: "Yu Fu" To: Cc: , "'MIB Doctors'" , References: <003201d2cad9$c83bec50$58b3c4f0$@cn> <6874911d-0535-8206-d96d-99a956c5bf85@bwijnen.net> <002201d2ce13$73ccd570$5b668050$@cn> <27ba3af4-49b4-17ee-a0f9-cb280a5141cb@bwijnen.net> In-Reply-To: <27ba3af4-49b4-17ee-a0f9-cb280a5141cb@bwijnen.net> Date: Wed, 17 May 2017 15:15:57 +0800 Message-ID: <002401d2cedd$6efb6870$4cf23950$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdLOHSNfBEgrSrxETg2pp8We1O3+SQAlnKBA Content-Language: zh-cn X-CM-TRANSID: AQAAf0CpsuKi+BtZoOuxKg--.42393S3 X-Coremail-Antispam: 1UD129KBjvJXoWxKw4xGF48Cw1UZr1DJF43Wrg_yoWxAw48pF Wftay7KrWDJ34ayrs2qw18try0yrZ2yry3Xr98tryUC390vrn7JF47KrW7ua4DCr18Xa1j v3yUX343ur1UAaUanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkFb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8Jw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6r4xMxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07bo-BiUUUUU= X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: Re: [Softwires] early MIB Doctor review for draft-ietf-softwire-map-mib-07 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, 17 May 2017 07:19:20 -0000 Hi Bert, Please see my reply inline. >> >>>> mapRuleID OBJECT-TYPE >>>> SYNTAX Integer32 (1..2147483647) >>>> MAX-ACCESS not-accessible >>>> STATUS current >>>> DESCRIPTION >>>> "An identifier used to distinguish the multiple >>>>mapping >>>> rule which is unique with each CE in the same BR." >>>> ::=3D { mapRuleEntry 1 } >>>> >>>> Since this is an index object, it be better defined as unsigned = 32. >>>> See RFC4181, section 4.6.1.1. Specifically page 15, which states >>>> - Unsigned32 with a range that excludes zero is >>>>RECOMMENDED for >>>> most index objects. It is acceptable to include zero in the >>>> range when it is semantically significant or when it is used = as >>>> the index value for a unique row with special properties. >>>> Such >>>> usage SHOULD be clearly documented in the DESCRIPTION >>>>clause. >>>>> >>>> [fuyu]: I will change it into unsigned 32. >>>> >>>> Pls also think about the question if the value can ever be zero for = a >>>> good reason. >>>> Normally INDEX object do not have a value of zero. >>>> >> [fuyu] Yes, since it is an index object and the value range is not = include >>zero. I think unsigned 32 is better. >> >OK, but then the definition would better be: > > SYNTAX Unsigned32 (1..4294967295) >That wat it is machinereadably clear that valu 0 is not valid. [fuyu] :OK, I will updated it. Thanks. >>>> >>>> >>>> mapRulePSID OBJECT-TYPE >>>> SYNTAX Integer32 >>>> MAX-ACCESS read-only >>>> STATUS current >>>> DESCRIPTION >>>> "The PSID value algorithmically identifies a set of >>>> ports assigned to a CE." >>>> REFERENCE >>>> "PSID: section 3 of RFC 7597." >>>> ::=3D { mapRuleEntry 9 } >>>> >>>> Mmmm... section 3 of RFC7597 only defines the term. The >>>> algorithm is in section 5.1 >>>> Maybe that is a better place to point to. >>>> Reading that section 5.1 in RFC7597, I wonder if "Integer32" is >>>> the best representation. >>>> In section 5.1, I see a PSID that is 6 bits (figure 2 on page >>>> 10). But there is also >>>> text about a PSID of 0x00 and 0xFF, which does not fit in 6 = bits. >>>> I am not an expert (basically have no knowledge about) on >>>> RFC7597. >>>> But sofar I cannot >>>> determine what the value range might be and how Integer32 is a >>>> good representation for >>>> the PSID. Please explain (not just to me, but adding text to = the >>>> internet drafts >>>> and the DESCRIPTION clause of this object) >>>> >>>> [fuyu]:Different PSID values guarantee non-overlapping port sets. >>>> The length of PSID is k bits, and the default value of PSID >>>> offset is 6 bits. >>>> So the bit length of PSID is variable. Thank you for your >>>>question. >>>> I have reconsidered the SYNTAS of the PSID. It can never be a >>>> negative value. >>>> I think Unsigned32 will be better. >>>> >>>> So do you just map the 4 octets of the PSID into this object? >>>> Is it not better to then use OCTET-STRING with a SIZE(4) ?? >>>> Maybe with a DISPLY-HINT added as well >>>> >>>> Do you normally display the value as an (unsigned) integer? >>>> Or do you normally display it as 0Xxxxxxxxx ?? >>>> Or maybe as bits? >>>> >>>> [fuyu] We always describe a Basic mapping rule as below: >>>> >>>> A MAP node (CE or BR) can, via the BMR or equivalent FMR, >>>> determine the IPv4 address and port set as shown below: >>>> >>>> EA bits offset: 40 >>>> IPv4 suffix bits (p) Length of IPv4 address (32) - >>>> IPv4 prefix length (24) =3D 8 >>>> IPv4 address: 192.0.2.18 (0xc0000212) >>>> PSID start: 40 + p =3D 40 + 8 =3D 48 >>>> PSID length: o - p =3D (56 - 40) - 8 =3D 8 >>>> PSID: 0x34 (1232) >>>> >>>> >Not sure I understand: 0x34 (1232) ??? 0x34 in my mind is 52, no? [fuyu] : Ops, sorry .....it's my fault. 1232 is the port number, not = the integer.=20 > >In fact I am not sure I understand much/any of the above. >But that is OK, if people who are familiar with (or must use/implement) = this >and if they understand it then fine. > >>>> >>>> So I think display the values as (unsigned) integer or display it = as >>>>0Xxxxxxxxx both will be OK. >>>> Do you have the surggstions? >>>> >My personal feeling/thinking is that it is probably best displayed as >0Xxxxxxxxx. >That (I would think) makes it easier to see bit positions as opposed to = an >(unsigned) integer. But in princople I can live with either. The = idea/hope is >that if you add a DISPLAY HINT that everyone displays it in the same = way. [fuyu]:Thank you for your suggestions. I will define it as below: RulePSID ::=3D TEXTUAL-CONVENTION DISPLAY-HINT "0x:" STATUS current DESCRIPTION "Represents ..." SYNTAX OCTET STRING (SIZE (4)) mapRulePSID OBJECT-TYPE SYNTAX RulePSID MAX-ACCESS read-only STATUS current DESCRIPTION "The PSID value algorithmically identifies a set of ports assigned to a CE." REFERENCE "PSID: section 5.1 of RFC 7597." ::=3D { mapRuleEntry 9 } Do you think it will be Ok? >>>> >>>>> - Section 7. Security considerations: >>>>> >>>> These are the objects and their sensitivity/vulnerability: >>>> >>>> mapRuleIPv6PrefixType >>>> >>>> mapRuleIPv6Prefix >>>> >>>> ... etc (quite a list of objects). >>>> >>>> But nowhere do I see text about "their >>>> sensitivity/vulnerability". ?? >>>> Still to be added? >>>> >>>> [fuyu]: Some of the readable objects in this MIB module may be >>>> considered sensitive or >>>> vulnerable in some network environments. These objects are >>>> readable, >>>> so maybe they are considered sensitive or vulnerable in some use >>>> case. >>>> We have a description why they are sensitive or vulnerable above >>>> the list of objects. >>>> >>>> Mmmm... can you point me to that text? I do not see that you = describe >>>> the vulnerability at any place. You do describe what the objects = are >>>> for, but that does not clearly explain what the security risks are = if >>>> some unauthorize person would see them. >>>> >>>> If you describe that at some other place in the document, then at >>>> least I would suggest to add a pointer to that text in the Security >>>> COnsiderations Secion. >>>> >>>> [fuyu]: Sorry. I should point it more clearly. It is in the = paragraph 2 of the >>>>section 7. >>>> From the first sentence that "Some of the readable objects in = this >>>>MIB module may be >>>> considered sensitive or vulnerable..." >>>> >>>> >It states that they " may be considered sensitive of vulnerable". >But it does not state WHY or IN WHAT CIRCUMSTANCES they might be >vulnerable. >What bad things are there that an intruder can do (or find out) when >he/she gets read access to these objects? >I.e. does he get to see confidential or private information? Does he = learn >about a competitors internal network structure? Or something else? [fuyu] : I will update it in more detail in this paragraph.Thanks. > >Bert Thanks again Yu From nobody Wed May 17 00:21: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 69D49129B3C for ; Wed, 17 May 2017 00:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 N6hdbII6QllD for ; Wed, 17 May 2017 00:21:13 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E21F9129B5D for ; Wed, 17 May 2017 00:17:38 -0700 (PDT) Received: from Macintosh-4.fritz.box ([IPv6:2001:981:602b:1:4928:6836:108a:7846]) by smtp-cloud2.xs4all.net with ESMTP id MKHb1v0071etLTN01KHcDv; Wed, 17 May 2017 09:17:36 +0200 To: Yu Fu References: <003201d2cad9$c83bec50$58b3c4f0$@cn> <6874911d-0535-8206-d96d-99a956c5bf85@bwijnen.net> <002201d2ce13$73ccd570$5b668050$@cn> <27ba3af4-49b4-17ee-a0f9-cb280a5141cb@bwijnen.net> <002401d2cedd$6efb6870$4cf23950$@cn> Cc: draft-ietf-softwire-map-mib.all@ietf.org, 'MIB Doctors' , softwires@ietf.org From: "Bert Wijnen (IETF)" Message-ID: Date: Wed, 17 May 2017 09:17:36 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <002401d2cedd$6efb6870$4cf23950$@cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Softwires] early MIB Doctor review for draft-ietf-softwire-map-mib-07 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, 17 May 2017 07:21:16 -0000 thank you. I am happy mow Bert On 17/05/2017 09:15, Yu Fu wrote: > Hi Bert, > > Please see my reply inline. > >>> >>>>> mapRuleID OBJECT-TYPE >>>>> SYNTAX Integer32 (1..2147483647) >>>>> MAX-ACCESS not-accessible >>>>> STATUS current >>>>> DESCRIPTION >>>>> "An identifier used to distinguish the multiple >>>>> mapping >>>>> rule which is unique with each CE in the same BR." >>>>> ::= { mapRuleEntry 1 } >>>>> >>>>> Since this is an index object, it be better defined as unsigned 32. >>>>> See RFC4181, section 4.6.1.1. Specifically page 15, which states >>>>> - Unsigned32 with a range that excludes zero is >>>>> RECOMMENDED for >>>>> most index objects. It is acceptable to include zero in the >>>>> range when it is semantically significant or when it is used as >>>>> the index value for a unique row with special properties. >>>>> Such >>>>> usage SHOULD be clearly documented in the DESCRIPTION >>>>> clause. >>>>>> >>>>> [fuyu]: I will change it into unsigned 32. >>>>> >>>>> Pls also think about the question if the value can ever be zero for a >>>>> good reason. >>>>> Normally INDEX object do not have a value of zero. >>>>> >>> [fuyu] Yes, since it is an index object and the value range is not include >>> zero. I think unsigned 32 is better. >>> >> OK, but then the definition would better be: >> >> SYNTAX Unsigned32 (1..4294967295) >> That wat it is machinereadably clear that valu 0 is not valid. > > > [fuyu] :OK, I will updated it. Thanks. > > >>>>> >>>>> >>>>> mapRulePSID OBJECT-TYPE >>>>> SYNTAX Integer32 >>>>> MAX-ACCESS read-only >>>>> STATUS current >>>>> DESCRIPTION >>>>> "The PSID value algorithmically identifies a set of >>>>> ports assigned to a CE." >>>>> REFERENCE >>>>> "PSID: section 3 of RFC 7597." >>>>> ::= { mapRuleEntry 9 } >>>>> >>>>> Mmmm... section 3 of RFC7597 only defines the term. The >>>>> algorithm is in section 5.1 >>>>> Maybe that is a better place to point to. >>>>> Reading that section 5.1 in RFC7597, I wonder if "Integer32" is >>>>> the best representation. >>>>> In section 5.1, I see a PSID that is 6 bits (figure 2 on page >>>>> 10). But there is also >>>>> text about a PSID of 0x00 and 0xFF, which does not fit in 6 bits. >>>>> I am not an expert (basically have no knowledge about) on >>>>> RFC7597. >>>>> But sofar I cannot >>>>> determine what the value range might be and how Integer32 is a >>>>> good representation for >>>>> the PSID. Please explain (not just to me, but adding text to the >>>>> internet drafts >>>>> and the DESCRIPTION clause of this object) >>>>> >>>>> [fuyu]:Different PSID values guarantee non-overlapping port sets. >>>>> The length of PSID is k bits, and the default value of PSID >>>>> offset is 6 bits. >>>>> So the bit length of PSID is variable. Thank you for your >>>>> question. >>>>> I have reconsidered the SYNTAS of the PSID. It can never be a >>>>> negative value. >>>>> I think Unsigned32 will be better. >>>>> >>>>> So do you just map the 4 octets of the PSID into this object? >>>>> Is it not better to then use OCTET-STRING with a SIZE(4) ?? >>>>> Maybe with a DISPLY-HINT added as well >>>>> >>>>> Do you normally display the value as an (unsigned) integer? >>>>> Or do you normally display it as 0Xxxxxxxxx ?? >>>>> Or maybe as bits? >>>>> >>>>> [fuyu] We always describe a Basic mapping rule as below: >>>>> >>>>> A MAP node (CE or BR) can, via the BMR or equivalent FMR, >>>>> determine the IPv4 address and port set as shown below: >>>>> >>>>> EA bits offset: 40 >>>>> IPv4 suffix bits (p) Length of IPv4 address (32) - >>>>> IPv4 prefix length (24) = 8 >>>>> IPv4 address: 192.0.2.18 (0xc0000212) >>>>> PSID start: 40 + p = 40 + 8 = 48 >>>>> PSID length: o - p = (56 - 40) - 8 = 8 >>>>> PSID: 0x34 (1232) >>>>> >>>>> >> Not sure I understand: 0x34 (1232) ??? 0x34 in my mind is 52, no? > > > [fuyu] : Ops, sorry .....it's my fault. 1232 is the port number, not the integer. > > >> >> In fact I am not sure I understand much/any of the above. >> But that is OK, if people who are familiar with (or must use/implement) this >> and if they understand it then fine. >> >>>>> >>>>> So I think display the values as (unsigned) integer or display it as >>>>> 0Xxxxxxxxx both will be OK. >>>>> Do you have the surggstions? >>>>> >> My personal feeling/thinking is that it is probably best displayed as >> 0Xxxxxxxxx. >> That (I would think) makes it easier to see bit positions as opposed to an >> (unsigned) integer. But in princople I can live with either. The idea/hope is >> that if you add a DISPLAY HINT that everyone displays it in the same way. > > > [fuyu]:Thank you for your suggestions. I will define it as below: > > RulePSID ::= TEXTUAL-CONVENTION > DISPLAY-HINT "0x:" > STATUS current > DESCRIPTION > "Represents ..." > SYNTAX OCTET STRING (SIZE (4)) > > mapRulePSID OBJECT-TYPE > SYNTAX RulePSID > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The PSID value algorithmically identifies a set of > ports assigned to a CE." > REFERENCE > "PSID: section 5.1 of RFC 7597." > ::= { mapRuleEntry 9 } > > Do you think it will be Ok? > >>>>> >>>>>> - Section 7. Security considerations: >>>>>> >>>>> These are the objects and their sensitivity/vulnerability: >>>>> >>>>> mapRuleIPv6PrefixType >>>>> >>>>> mapRuleIPv6Prefix >>>>> >>>>> ... etc (quite a list of objects). >>>>> >>>>> But nowhere do I see text about "their >>>>> sensitivity/vulnerability". ?? >>>>> Still to be added? >>>>> >>>>> [fuyu]: Some of the readable objects in this MIB module may be >>>>> considered sensitive or >>>>> vulnerable in some network environments. These objects are >>>>> readable, >>>>> so maybe they are considered sensitive or vulnerable in some use >>>>> case. >>>>> We have a description why they are sensitive or vulnerable above >>>>> the list of objects. >>>>> >>>>> Mmmm... can you point me to that text? I do not see that you describe >>>>> the vulnerability at any place. You do describe what the objects are >>>>> for, but that does not clearly explain what the security risks are if >>>>> some unauthorize person would see them. >>>>> >>>>> If you describe that at some other place in the document, then at >>>>> least I would suggest to add a pointer to that text in the Security >>>>> COnsiderations Secion. >>>>> >>>>> [fuyu]: Sorry. I should point it more clearly. It is in the paragraph 2 of the >>>>> section 7. >>>>> From the first sentence that "Some of the readable objects in this >>>>> MIB module may be >>>>> considered sensitive or vulnerable..." >>>>> >>>>> >> It states that they " may be considered sensitive of vulnerable". >> But it does not state WHY or IN WHAT CIRCUMSTANCES they might be >> vulnerable. >> What bad things are there that an intruder can do (or find out) when >> he/she gets read access to these objects? >> I.e. does he get to see confidential or private information? Does he learn >> about a competitors internal network structure? Or something else? > > [fuyu] : I will update it in more detail in this paragraph.Thanks. >> >> Bert > > Thanks again > Yu > > > From nobody Wed May 17 08:02:40 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 61F20129C5F; Wed, 17 May 2017 08:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 HE-O3nVop4sD; Wed, 17 May 2017 08:02:37 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73B951293F5; Wed, 17 May 2017 07:56:04 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 17 May 2017 07:56:02 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 17 May 2017 07:56:02 -0700 From: Terry Manderson To: "Bert Wijnen (IETF)" , Yu Fu CC: "draft-ietf-softwire-map-mib.all@ietf.org" , 'MIB Doctors' , "softwires@ietf.org" Thread-Topic: early MIB Doctor review for draft-ietf-softwire-map-mib-07 Thread-Index: AQHSzt4ufXUW3DrbCUefV2/mMb2PhqH5up6A Date: Wed, 17 May 2017 14:56:01 +0000 Message-ID: References: <003201d2cad9$c83bec50$58b3c4f0$@cn> <6874911d-0535-8206-d96d-99a956c5bf85@bwijnen.net> <002201d2ce13$73ccd570$5b668050$@cn> <27ba3af4-49b4-17ee-a0f9-cb280a5141cb@bwijnen.net> <002401d2cedd$6efb6870$4cf23950$@cn> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3577913755_241280046" MIME-Version: 1.0 Archived-At: Subject: Re: [Softwires] early MIB Doctor review for draft-ietf-softwire-map-mib-07 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, 17 May 2017 15:02:39 -0000 --B_3577913755_241280046 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Bert, Yu, Thank you very much for your review and activity on this! Cheers Terry On 17/05/2017, 5:17 PM, "Bert Wijnen (IETF)" wrote: thank you. I am happy mow Bert On 17/05/2017 09:15, Yu Fu wrote: > Hi Bert, > > Please see my reply inline. > >>> >>>>> mapRuleID OBJECT-TYPE >>>>> SYNTAX Integer32 (1..2147483647) >>>>> MAX-ACCESS not-accessible >>>>> STATUS current >>>>> DESCRIPTION >>>>> "An identifier used to distinguish the multiple >>>>> mapping >>>>> rule which is unique with each CE in the same BR." >>>>> ::= { mapRuleEntry 1 } >>>>> >>>>> Since this is an index object, it be better defined as unsigned 32. >>>>> See RFC4181, section 4.6.1.1. Specifically page 15, which states >>>>> - Unsigned32 with a range that excludes zero is >>>>> RECOMMENDED for >>>>> most index objects. It is acceptable to include zero in the >>>>> range when it is semantically significant or when it is used as >>>>> the index value for a unique row with special properties. >>>>> Such >>>>> usage SHOULD be clearly documented in the DESCRIPTION >>>>> clause. >>>>>> >>>>> [fuyu]: I will change it into unsigned 32. >>>>> >>>>> Pls also think about the question if the value can ever be zero for a >>>>> good reason. >>>>> Normally INDEX object do not have a value of zero. >>>>> >>> [fuyu] Yes, since it is an index object and the value range is not include >>> zero. I think unsigned 32 is better. >>> >> OK, but then the definition would better be: >> >> SYNTAX Unsigned32 (1..4294967295) >> That wat it is machinereadably clear that valu 0 is not valid. > > > [fuyu] :OK, I will updated it. Thanks. > > >>>>> >>>>> >>>>> mapRulePSID OBJECT-TYPE >>>>> SYNTAX Integer32 >>>>> MAX-ACCESS read-only >>>>> STATUS current >>>>> DESCRIPTION >>>>> "The PSID value algorithmically identifies a set of >>>>> ports assigned to a CE." >>>>> REFERENCE >>>>> "PSID: section 3 of RFC 7597." >>>>> ::= { mapRuleEntry 9 } >>>>> >>>>> Mmmm... section 3 of RFC7597 only defines the term. The >>>>> algorithm is in section 5.1 >>>>> Maybe that is a better place to point to. >>>>> Reading that section 5.1 in RFC7597, I wonder if "Integer32" is >>>>> the best representation. >>>>> In section 5.1, I see a PSID that is 6 bits (figure 2 on page >>>>> 10). But there is also >>>>> text about a PSID of 0x00 and 0xFF, which does not fit in 6 bits. >>>>> I am not an expert (basically have no knowledge about) on >>>>> RFC7597. >>>>> But sofar I cannot >>>>> determine what the value range might be and how Integer32 is a >>>>> good representation for >>>>> the PSID. Please explain (not just to me, but adding text to the >>>>> internet drafts >>>>> and the DESCRIPTION clause of this object) >>>>> >>>>> [fuyu]:Different PSID values guarantee non-overlapping port sets. >>>>> The length of PSID is k bits, and the default value of PSID >>>>> offset is 6 bits. >>>>> So the bit length of PSID is variable. Thank you for your >>>>> question. >>>>> I have reconsidered the SYNTAS of the PSID. It can never be a >>>>> negative value. >>>>> I think Unsigned32 will be better. >>>>> >>>>> So do you just map the 4 octets of the PSID into this object? >>>>> Is it not better to then use OCTET-STRING with a SIZE(4) ?? >>>>> Maybe with a DISPLY-HINT added as well >>>>> >>>>> Do you normally display the value as an (unsigned) integer? >>>>> Or do you normally display it as 0Xxxxxxxxx ?? >>>>> Or maybe as bits? >>>>> >>>>> [fuyu] We always describe a Basic mapping rule as below: >>>>> >>>>> A MAP node (CE or BR) can, via the BMR or equivalent FMR, >>>>> determine the IPv4 address and port set as shown below: >>>>> >>>>> EA bits offset: 40 >>>>> IPv4 suffix bits (p) Length of IPv4 address (32) - >>>>> IPv4 prefix length (24) = 8 >>>>> IPv4 address: 192.0.2.18 (0xc0000212) >>>>> PSID start: 40 + p = 40 + 8 = 48 >>>>> PSID length: o - p = (56 - 40) - 8 = 8 >>>>> PSID: 0x34 (1232) >>>>> >>>>> >> Not sure I understand: 0x34 (1232) ??? 0x34 in my mind is 52, no? > > > [fuyu] : Ops, sorry .....it's my fault. 1232 is the port number, not the integer. > > >> >> In fact I am not sure I understand much/any of the above. >> But that is OK, if people who are familiar with (or must use/implement) this >> and if they understand it then fine. >> >>>>> >>>>> So I think display the values as (unsigned) integer or display it as >>>>> 0Xxxxxxxxx both will be OK. >>>>> Do you have the surggstions? >>>>> >> My personal feeling/thinking is that it is probably best displayed as >> 0Xxxxxxxxx. >> That (I would think) makes it easier to see bit positions as opposed to an >> (unsigned) integer. But in princople I can live with either. The idea/hope is >> that if you add a DISPLAY HINT that everyone displays it in the same way. > > > [fuyu]:Thank you for your suggestions. I will define it as below: > > RulePSID ::= TEXTUAL-CONVENTION > DISPLAY-HINT "0x:" > STATUS current > DESCRIPTION > "Represents ..." > SYNTAX OCTET STRING (SIZE (4)) > > mapRulePSID OBJECT-TYPE > SYNTAX RulePSID > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The PSID value algorithmically identifies a set of > ports assigned to a CE." > REFERENCE > "PSID: section 5.1 of RFC 7597." > ::= { mapRuleEntry 9 } > > Do you think it will be Ok? > >>>>> >>>>>> - Section 7. Security considerations: >>>>>> >>>>> These are the objects and their sensitivity/vulnerability: >>>>> >>>>> mapRuleIPv6PrefixType >>>>> >>>>> mapRuleIPv6Prefix >>>>> >>>>> ... etc (quite a list of objects). >>>>> >>>>> But nowhere do I see text about "their >>>>> sensitivity/vulnerability". ?? >>>>> Still to be added? >>>>> >>>>> [fuyu]: Some of the readable objects in this MIB module may be >>>>> considered sensitive or >>>>> vulnerable in some network environments. These objects are >>>>> readable, >>>>> so maybe they are considered sensitive or vulnerable in some use >>>>> case. >>>>> We have a description why they are sensitive or vulnerable above >>>>> the list of objects. >>>>> >>>>> Mmmm... can you point me to that text? I do not see that you describe >>>>> the vulnerability at any place. You do describe what the objects are >>>>> for, but that does not clearly explain what the security risks are if >>>>> some unauthorize person would see them. >>>>> >>>>> If you describe that at some other place in the document, then at >>>>> least I would suggest to add a pointer to that text in the Security >>>>> COnsiderations Secion. >>>>> >>>>> [fuyu]: Sorry. I should point it more clearly. It is in the paragraph 2 of the >>>>> section 7. >>>>> From the first sentence that "Some of the readable objects in this >>>>> MIB module may be >>>>> considered sensitive or vulnerable..." >>>>> >>>>> >> It states that they " may be considered sensitive of vulnerable". >> But it does not state WHY or IN WHAT CIRCUMSTANCES they might be >> vulnerable. >> What bad things are there that an intruder can do (or find out) when >> he/she gets read access to these objects? >> I.e. does he get to see confidential or private information? Does he learn >> about a competitors internal network structure? Or something else? > > [fuyu] : I will update it in more detail in this paragraph.Thanks. >> >> Bert > > Thanks again > Yu > > > --B_3577913755_241280046 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFM5O bcWHcOLvP8dYn1pLDZtHbqV5MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE3MDUxNzE0NTU1NVowDQYJKoZIhvcNAQEBBQAEggEAAO417ovKSERuVwkpAJgs mPPCKnikVWdqObcXQp8MSQEg8OU4Jp/HH16WCHEUGVUxRdl0v+dKDjmyNH1YCzjbHHEmO3II 2ce5paTpISUyi4/ywJUQPEzC3yEK76TbwVRzUgjhBrm6HJCGceGKIAa90JN0WaN0KKx7sb3F HO9OcDicptCLyuuPfCApnGJuldtCfJQFx869O1FjOZVa5VPp194AcZP67+F8sPa6V10l0hxk Uj+1R0nzTBl36ZMYDk5cTN+dM2jChqVt+pQTrR6rY2Oqi5WpDO9rj2HDroaQabdQbTflTBBR lVWfvBMymotIU4gi1j4NNFZnNXYOMjiO5g== --B_3577913755_241280046-- From nobody Wed May 17 18:53:57 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 0D0601279E5; Wed, 17 May 2017 18:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 aOSdwtvQC7pO; Wed, 17 May 2017 18:53:48 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1797412947C; Wed, 17 May 2017 18:53:43 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.232]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0BZa+uH_hxZay6yKg--.42202S3; Thu, 18 May 2017 09:53:13 +0800 (CST) From: "Yu Fu" To: , "'Bert Wijnen \(IETF\)'" Cc: , "'MIB Doctors'" , References: <003201d2cad9$c83bec50$58b3c4f0$@cn> <6874911d-0535-8206-d96d-99a956c5bf85@bwijnen.net> <002201d2ce13$73ccd570$5b668050$@cn> <27ba3af4-49b4-17ee-a0f9-cb280a5141cb@bwijnen.net> <002401d2cedd$6efb6870$4cf23950$@cn> In-Reply-To: Date: Thu, 18 May 2017 09:53:23 +0800 Message-ID: <003001d2cf79$8a40a310$9ec1e930$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHSzt4ufXUW3DrbCUefV2/mMb2PhqH5up6A//+YvZA= Content-Language: zh-cn X-CM-TRANSID: AQAAf0BZa+uH_hxZay6yKg--.42202S3 X-Coremail-Antispam: 1UD129KBjvdXoWrJr4xZFWxKr4UCFWkZFWrZrb_yoWxWrcE9F 429rnrKrWDAF48Z3ZFvrsa9anaga97ua4UA345Kr1ft34UA3s2vrnYv395Zw1UJFyjkFnr CF12qF1Yk34FgjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb2xYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW7JVWDJwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwV C2z280aVCY1x0267AKxVWxJr0_GcWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xv F2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r 4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Avz4vE14v_KwCF04k2 0xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI 8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41l IxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIx AIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2 z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUc8nYUUUUU X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: Re: [Softwires] early MIB Doctor review for draft-ietf-softwire-map-mib-07 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, 18 May 2017 01:53:50 -0000 Thanks Terry and Bert, An updated version will be submitted soon. Cheers Yu >-----Original Message----- >From: terry.manderson@icann.org [mailto:terry.manderson@icann.org] >Sent: Wednesday, May 17, 2017 10:56 PM >To: Bert Wijnen (IETF); Yu Fu >Cc: draft-ietf-softwire-map-mib.all@ietf.org; 'MIB Doctors'; >softwires@ietf.org >Subject: Re: early MIB Doctor review for draft-ietf-softwire-map-mib-07 > >Bert, Yu, > >Thank you very much for your review and activity on this! > >Cheers >Terry >> >>On 17/05/2017, 5:17 PM, "Bert Wijnen (IETF)" >>wrote: >> >> thank you. I am happy mow >> >> Bert From jonas.gorski@gmail.com Fri May 19 05:23:53 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 8B0FC12E058; Fri, 19 May 2017 05:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EBleezcatA5r; Fri, 19 May 2017 05:23:51 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 4445F12ECA7; Fri, 19 May 2017 05:18:13 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id b84so234350307wmh.0; Fri, 19 May 2017 05:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=aoTTounu+WP7E4ubj8LjgPr1isFc4teFVUgD+XcOk1M=; b=Ijb3qc0i+mp0iDN6QamFHLfLPwbce/50/0fteCPpsRcIe2k1QK7mdP6FRCsaTtFAz+ EmyB9Q4LoBn/9Z4mbgouNn7urr+ltRAL4ddQltXNxg2NtxbK6rGshvVl2RNHw3AWbxkV zguFQKId6T/VfrgUTlvZNuY4v8TFsyN0E7bqIMnmPfhUvSNpLs/R/b1zaDhfOL5I5OGq 54/wC5oX5dpLiMFEpoYt7YeIHsc37KEBVDmYqzjnQVimd3Va3K5uLkotsmH/QsJEvz6n XldXlRq1ksg3yD0YQIwP1NaTZrajOzBNWaQWuxggyDr1RqfOd5IvXI5GKU5jn0fgDyIl GKiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=aoTTounu+WP7E4ubj8LjgPr1isFc4teFVUgD+XcOk1M=; b=FRMUpguTwLOwzX9S3KAOhp95F/8qkNMs8dqv0Jf0cHIFeObu1iPu4WOZwhlDntLqb1 WY35ziGgFGoSm1a6B43QlzxrHiEOBh3SuYUKSZtctQPZdXGqEoV7pqfVZcux4NwcuI+9 T8U3HS/fLlglSbYGLAGmYzmmUuLEUFgA8/DnNottIG+HgqAvfOw6LfCIY8VJ9pyq/s63 uv9rvG7OReUwd2UH2HAmcqAaOw/lOod498WXmxfnzCmi5l/h7ond6+gxuIvlpGg3z6eX rD8x4tqg+2NvWi0/ZGuNfZG6ubBdU0BDVXbK2TsvvcO8qCmj+lSMzu/QT0t36Os3seGi 7/fg== X-Gm-Message-State: AODbwcDjpjiO0Ea9RBnkjsX3W2NSOL8pYtHtxdHeowX3WhyYeK0AE/Fh z+ZeFt695xn1xA== X-Received: by 10.80.143.5 with SMTP id 5mr6967898edy.68.1495196291725; Fri, 19 May 2017 05:18:11 -0700 (PDT) Received: from ?IPv6:2001:470:9e39:0:65d4:783b:16a2:aed1? ([2001:470:9e39:0:65d4:783b:16a2:aed1]) by smtp.gmail.com with ESMTPSA id h33sm2775818edh.50.2017.05.19.05.18.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 May 2017 05:18:11 -0700 (PDT) From: Jonas Gorski To: tomasz.mrugalski@gmail.com, dhcwg@ietf.org References: Cc: softwires@ietf.org, draft-fsc-softwire-dhcp4o6-saddr-opt@ietf.org Message-ID: <65646669-e32f-958c-684c-a36d4272b046@gmail.com> Date: Fri, 19 May 2017 14:18:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sun, 21 May 2017 08:23:48 -0700 Subject: Re: [Softwires] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 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, 19 May 2017 13:54:45 -0000 Hi, On 22.02.2017 18:37, tomasz.mrugalski@gmail.com wrote: > Hi, > > This message initiates a two weeks long DHC WG adoption call on: > > Title: DHCPv4 over DHCPv6 Source Address Option > Pages: 9 > Date: 2017-02-01 > Document: draft-fsc-softwire-dhcp4o6-saddr-opt-07 > Link: tools.ietf.org/html/draft-fsc-softwire-dhcp4o6-saddr-opt-07 > > This document initially started as work intended to be adopted in > Softwires, but after a discussion with chairs, responsible AD (Suresh) > and presenting this work in DHC, the conclusion is to aim for DHC > adoption, not Softwires. Therefore this is a DHC adoption call. > > This message is cross-posted to Softwires to let Softwire experts weigh > in their opinion. Please be sure to post your comments to DHC list, > though. Comments sent by end of March 8th, 2017 are much appreciated. I am working on implementing this draft (started in version 4), and like to add a few comments. It is based on an existing RFC 7341 client (DHCPv4 over DHCPv6) which wasn't written by me, which was done by modifying an existing DHCPv4 client to transparently wrap all messages in DHCPv6 messages, so the DHCPv4 part doesn't really know about it. My comments are split into three parts, first about the place of the options, then about handling them, and finally some nitpicks. 1. The placement of the new options I'll start with the placement of the (new) options. Pre-draft, the DHCPv6 encapsulation was a strict transport and stateless. This draft now adds both new options to the outer DHCPv6 messages as well the inner DHCPv4 one. This seems quite awkward, as the client now needs to be able to access both the outer envelope as well the inner message at the same time for a full picture. IMHO especially awkward is the change from a DHCPv6 OPTION_DHCP4O6_SADDR_HINT to a DHCPv4 OPTION_DHCP4O6_SADDR. This caused a bit of spaghetti-code when trying to somehow pass information between the (separated) code responsible for the DHCPv6 en-/decapsulation, and the actual DHCPv4 code. The DHCPv4 code needed to get the contents of the DHCPv6 envelope at the appropriate place. Having all three as DHCPv4 options would make it much more consistent, as everything is now kept in one channel. This would also then preserve RFC 7341's statement that "The DHCPv6-relay encapsulation is used solely to deliver DHCPv4 packets to a DHCPv4-capable server, and does not allocate any IPv6 addresses nor does it provide IPv6-configuration information to the client." The alternative that I could think of would be to move the _SADDR_HINT and _BR options to the original DHCPv6 message that contains the OPTION_DHCP4_O_DHCP6_SERVER option. Maybe create an container for them, similar to how RFC 7598 defines containers for software46. The RFC 7341 client would then be able to already send the _SADDR in its discovers. 2. Handling the new options The OPTION_S46_BR poses no large issues. The new OPTION_DHCP4O6_SADDR_HINT caused and still causes a lot of headaches for me. As far as my understanding with modern distributions (be they desktop or embedded) is that the DHCP clients usually do no configuration by their own, and just pass on the Lease's contents to a networking management deamon after they received the ACK. This works fine with DHCPv6, with DHCPv4, and with RFC 7341 DHCPv4overDHCPv6. The new OPTION_DHCP4O6_SADDR_HINT now requires the network management daemon to (potentially) allocate/assign a new IP address during the offer/request phase (including the DAD), which makes the interaction quite a bit more complex, as there are a few new potential error transitions. There is now the awkward state where you might need to revert network configuration after a NACK or error from the server, or a timeout despite never having a valid lease. Of course if one wants to avoid complexity one can just hope that we have a global address on the wan interface already and always return that. This would be alleviated by already having this option in the original DHCPv6 lease, as then the network management daemon could allocate the IP address already during the DHCPv6 lease acquisition handling phase. And finally when adding support for it to a client that does "transparent" DHCPv6 en-/decapsulation this means that the DHCPv6 code now needs access to the DHCPv4 state machine to know when to include the _SADDR option, and when to (not) expect it, as it has no DHCPv6 message types to rely on. 3. Nitpicks The flow diagram in "5. IPv6/IPv4 Binding Message Flow" makes it look like the OPTION_DHCP4O6_SADDR is part of the DHCPv6 message, not part of the embedded DHCPv4 message. The option OPTION_DHCP4O6_SADDR is described in a subsection of "6. DHCPv6 Options", despite it being a DHCPv4 option (and there being only one DHCPv6 option, so the plural doesn't help either). Both make it easy to mistake OPTION_DHCP4O6_SADDR as a DHCPv6 option, and not a DHCPv4 one (as I did until I read the newest draft, and will need to fix). Also it feels a bit like the draft doesn't handle potential error cases enough, although I can't really put my finger on it. One thing I am wondering about is how the client should behave when it doesn't have any assigned prefixes or global addresses? Is sending the link local address fine? Should it abort in that case? How about ULA addresses? In case of using DHCPv6 broadcast address as DHCP4ov6 server this could happen AFAICT. I hope these comments help improving the proposed standard. Regards Jonas Gorski From nobody Wed May 24 22:46: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 D49771205F1; Wed, 24 May 2017 22:46:20 -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.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149569118073.8664.9750883495614643856@ietfa.amsl.com> Date: Wed, 24 May 2017 22:46:20 -0700 Archived-At: Subject: [Softwires] I-D Action: draft-ietf-softwire-map-mib-08.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: Thu, 25 May 2017 05:46:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires 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-08.txt Pages : 15 Date : 2017-05-24 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 encapsulation (MAP-E) mode. 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-softwire-map-mib-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-mib-08 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 Wed May 24 23:15:15 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 0B263129C3D; Wed, 24 May 2017 23:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 9wIwtDbFatLM; Wed, 24 May 2017 23:15:11 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 704BA129C40; Wed, 24 May 2017 23:15:08 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.146]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0B5jOxXdiZZz1e1Kg--.45266S3; Thu, 25 May 2017 14:14:47 +0800 (CST) From: "Yu Fu" To: Cc: , "'MIB Doctors'" , Date: Thu, 25 May 2017 14:14:53 +0800 Message-ID: <003701d2d51e$39503a60$abf0af20$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: zh-cn Thread-Index: AdLVGkWOKVhAssyATxymAkAGncdSbAAAZNzA X-CM-TRANSID: AQAAf0B5jOxXdiZZz1e1Kg--.45266S3 X-Coremail-Antispam: 1UD129KBjvJXoWxAr1UWrW3ZF1fWw15Jr43Jrb_yoW5Jw1UpF Z3t398CrWxta1kK3ykWF1Fv3ZYv3s5trWxuFn8Jr1xZ3yUJ3ZFyF10kryYyr9rJryrKw4x AF48uw15Xan5XrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkIb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMxkIecxEwVAFwVW8AwCF04k2 0xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI 8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41l IxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIx AIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvE x4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU8pyIUUUUUU== X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: [Softwires] FW: I-D Action: draft-ietf-softwire-map-mib-08.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: Thu, 25 May 2017 06:15:13 -0000 Hi Bert, Thanks for your MIB doctor review. I have updated the 08 version based on all your comments. Please see whether it fix all your comments. I have another question when I do the MIB module validation as the Severity level is set to 6(most strict). It has warnings as below. warning: `InetAddress' should be used instead of `InetAddressIPv6' warning: `InetAddress' should be used instead of `InetAddressIPv4' It is because we define the mapRuleIPv6Prefix and mapRuleIPv4Prefix as below: mapRuleIPv6Prefix OBJECT-TYPE SYNTAX InetAddressIPv6 MAX-ACCESS read-only STATUS current DESCRIPTION mapRuleIPv4Prefix OBJECT-TYPE SYNTAX InetAddressIPv4 MAX-ACCESS read-only STATUS current DESCRIPTION Shall we ignore these warnings? Thanks a lot Cheers Yu -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Thursday, May 25, 2017 1:46 PM To: i-d-announce@ietf.org Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-mib-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires 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-08.txt Pages : 15 Date : 2017-05-24 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 encapsulation (MAP-E) mode. 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-softwire-map-mib-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-mib-08 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 From nobody Thu May 25 02:04:42 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 AAAA2129400; Thu, 25 May 2017 02:04:34 -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, RP_MATCHES_RCVD=-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 meElo3rg41zI; Thu, 25 May 2017 02:04:32 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD57B1270A3; Thu, 25 May 2017 02:04:31 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id E94A176; Thu, 25 May 2017 11:04:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Avl1WB3w_HNq; Thu, 25 May 2017 11:04:28 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 25 May 2017 11:04:28 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A131F20063; Thu, 25 May 2017 11:04:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7HVsK-cdb_F1; Thu, 25 May 2017 11:04:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C37C020062; Thu, 25 May 2017 11:04:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9299A3F574C1; Thu, 25 May 2017 11:04:26 +0200 (CEST) Date: Thu, 25 May 2017 11:04:25 +0200 From: Juergen Schoenwaelder To: Yu Fu Cc: bertietf@bwijnen.net, softwires@ietf.org, 'MIB Doctors' , draft-ietf-softwire-map-mib.all@ietf.org Message-ID: <20170525090425.GA41496@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Yu Fu , bertietf@bwijnen.net, softwires@ietf.org, 'MIB Doctors' , draft-ietf-softwire-map-mib.all@ietf.org References: <003701d2d51e$39503a60$abf0af20$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003701d2d51e$39503a60$abf0af20$@cn> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [Softwires] [MIB-DOCTORS] FW: I-D Action: draft-ietf-softwire-map-mib-08.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: Thu, 25 May 2017 09:04:35 -0000 Hi, since these objects seem to be IP version specific, I think it is OK to ignore the warning. Perhaps consider adding comment such as: -- The object mapRuleIPv6Prefix is IPv6 specific and hence it does -- not use the version agnostic InetAddress. This way, it is documented that any warnings related to this can be ignored. (Otherwise, this question may come up again.) /js On Thu, May 25, 2017 at 02:14:53PM +0800, Yu Fu wrote: > Hi Bert, > > Thanks for your MIB doctor review. > > I have updated the 08 version based on all your comments. Please see whether > it fix all your comments. > > I have another question when I do the MIB module validation as the Severity > level is set to 6(most strict). It has warnings as below. > > warning: `InetAddress' should be used instead of `InetAddressIPv6' > warning: `InetAddress' should be used instead of `InetAddressIPv4' > > It is because we define the mapRuleIPv6Prefix and mapRuleIPv4Prefix as > below: > mapRuleIPv6Prefix OBJECT-TYPE > SYNTAX InetAddressIPv6 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > > mapRuleIPv4Prefix OBJECT-TYPE > SYNTAX InetAddressIPv4 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > > Shall we ignore these warnings? > > Thanks a lot > > Cheers > > Yu > > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Thursday, May 25, 2017 1:46 PM > To: i-d-announce@ietf.org > Cc: softwires@ietf.org > Subject: [Softwires] I-D Action: draft-ietf-softwire-map-mib-08.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Softwires 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-08.txt > Pages : 15 > Date : 2017-05-24 > > 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 > encapsulation (MAP-E) mode. > > > 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-08 > https://datatracker.ietf.org/doc/html/draft-ietf-softwire-map-mib-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-mib-08 > > > 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 > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu May 25 19:51:21 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 AA911129B69; Thu, 25 May 2017 19:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 aN1tYO82z4kp; Thu, 25 May 2017 19:51:18 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 253C21279EB; Thu, 25 May 2017 19:51:16 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.16]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0C5wVUOmCdZLaa1Kg--.48213S3; Fri, 26 May 2017 10:50:55 +0800 (CST) From: "Yu Fu" To: "'Juergen Schoenwaelder'" Cc: , , "'MIB Doctors'" , References: <003701d2d51e$39503a60$abf0af20$@cn> <20170525090425.GA41496@elstar.local> In-Reply-To: <20170525090425.GA41496@elstar.local> Date: Fri, 26 May 2017 10:50:59 +0800 Message-ID: <002d01d2d5ca$e88c13d0$b9a43b70$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: zh-cn Thread-Index: AdLVNe/HukKrk9BkQkugf9AG5E/quwAkBwcg X-CM-TRANSID: AQAAf0C5wVUOmCdZLaa1Kg--.48213S3 X-Coremail-Antispam: 1UD129KBjvJXoWxGFW7Aw1xCF4xur1kZF4xJFb_yoWrZF4UpF WxJF4qkr48Jw18Gw4vgF18ZwnYv34fJrWUWrn8Jr17K34Dt3WDtr10kryrCr9rJr1rJr4I yr4UCry3XFs8ZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkFb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8Jw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6r4UMxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07j5wIDUUUUU= X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: Re: [Softwires] [MIB-DOCTORS] FW: I-D Action: draft-ietf-softwire-map-mib-08.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: Fri, 26 May 2017 02:51:21 -0000 Hi Juergen, Thank you for your reply. OK. I will add a note in the MIB. Cheers Yu >-----Original Message----- >From: j.schoenwaelder@jacobs-university.de >[mailto:j.schoenwaelder@jacobs-university.de] >Sent: Thursday, May 25, 2017 5:04 PM >To: Yu Fu >Cc: bertietf@bwijnen.net; softwires@ietf.org; 'MIB Doctors'; >draft-ietf-softwire-map-mib.all@ietf.org >Subject: Re: [MIB-DOCTORS] FW: [Softwires] I-D Action: >draft-ietf-softwire-map-mib-08.txt > >Hi, > >since these objects seem to be IP version specific, I think it is OK to ignore >the warning. Perhaps consider adding comment such as: > > -- The object mapRuleIPv6Prefix is IPv6 specific and hence it does > -- not use the version agnostic InetAddress. > >This way, it is documented that any warnings related to this can be ignored. >(Otherwise, this question may come up again.) > >/js > >>On Thu, May 25, 2017 at 02:14:53PM +0800, Yu Fu wrote: >> Hi Bert, >> >> Thanks for your MIB doctor review. >> >> I have updated the 08 version based on all your comments. Please see >> whether it fix all your comments. >> >> I have another question when I do the MIB module validation as the >> Severity level is set to 6(most strict). It has warnings as below. >> >> warning: `InetAddress' should be used instead of `InetAddressIPv6' >> warning: `InetAddress' should be used instead of `InetAddressIPv4' >> >> It is because we define the mapRuleIPv6Prefix and mapRuleIPv4Prefix as >> below: >> mapRuleIPv6Prefix OBJECT-TYPE >> SYNTAX InetAddressIPv6 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> >> mapRuleIPv4Prefix OBJECT-TYPE >> SYNTAX InetAddressIPv4 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> >> Shall we ignore these warnings? >> >> Thanks a lot >> >> Cheers >> >> Yu >> >> -----Original Message----- >>>>>>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] >>>>>>> On Behalf Of internet-drafts@ietf.org >>>>>>> Sent: Thursday, May 25, 2017 1:46 PM >>>>>>> To: i-d-announce@ietf.org >>>>>>> Cc: softwires@ietf.org >>>>>>> Subject: [Softwires] I-D Action: draft-ietf-softwire-map-mib-08.txt >>>>>>> >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>> directories. >>>>>>> This draft is a work item of the Softwires 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-08.txt >>>>>>> Pages : 15 >>>>>>> Date : 2017-05-24 >>>>>>> >>>>>>> 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 >>>>>>> encapsulation (MAP-E) mode. >>>>>>> >>>>>>> >>>>>>> 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-08 >>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-softwire-map-mib-08 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-mib-08 >>>>>>> >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> MIB-DOCTORS mailing list >>>>>>> MIB-DOCTORS@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>>>> >>>>>>-- >>>>>>Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>>Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >>>>>>Germany >>>>>>Fax: +49 421 200 3103 From nobody Sat May 27 01:36:45 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 2B440126D45; Sat, 27 May 2017 01:36:44 -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.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149587420413.8673.3234969842472483274@ietfa.amsl.com> Date: Sat, 27 May 2017 01:36:44 -0700 Archived-At: Subject: [Softwires] I-D Action: draft-ietf-softwire-map-mib-09.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: Sat, 27 May 2017 08:36:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires 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-09.txt Pages : 15 Date : 2017-05-27 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 encapsulation (MAP-E) mode. 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-softwire-map-mib-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-mib-09 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 Sat May 27 01:44:02 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 196621279E5; Sat, 27 May 2017 01:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 B2iG-IgZqB9c; Sat, 27 May 2017 01:43:58 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id B18E1126D45; Sat, 27 May 2017 01:43:57 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.174]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMuJBPClZRQ+2Kg--.44980S3; Sat, 27 May 2017 16:43:45 +0800 (CST) From: "Yu Fu" To: Cc: "'Juergen Schoenwaelder'" , "'MIB Doctors'" , , Date: Sat, 27 May 2017 16:43:48 +0800 Message-ID: <002101d2d6c5$5c471770$14d54650$@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: AdLWxGOXrFkopQx3RN2BL44RWW6E2QAACCcA Content-Language: zh-cn X-CM-TRANSID: AQAAf0ApMuJBPClZRQ+2Kg--.44980S3 X-Coremail-Antispam: 1UD129KBjvJXoW7trWxJFyxXw4ruF15AFy7Jrb_yoW8CryfpF WxZ398Gw1fJ3W8K397WF1F9w1vv3s5trWfCFn8Jr10vayUJ3WktF10kryrA39rJrWrGr4x AF48uw15Xan5XrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkFb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8Jw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6r43MxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07jwXo7UUUUU= X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: [Softwires] FW: I-D Action: draft-ietf-softwire-map-mib-09.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: Sat, 27 May 2017 08:44:01 -0000 Hi all, I have updated the 09 version based on Juergen's suggestions. Thanks. Comments are appreciated. Yu -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Saturday, May 27, 2017 4:37 PM To: i-d-announce@ietf.org Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-mib-09.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires 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-09.txt Pages : 15 Date : 2017-05-27 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 encapsulation (MAP-E) mode. 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-softwire-map-mib-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-mib-09 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 From nobody Tue May 30 02:37:10 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 7FC6E129423; Tue, 30 May 2017 02:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.9 X-Spam-Level: X-Spam-Status: No, score=-4.9 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, 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 MTiL9JmalLFO; Tue, 30 May 2017 02:37:07 -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 B0037127077; Tue, 30 May 2017 02:37:06 -0700 (PDT) Received: from teraadmins-mbp.lan ([80.159.240.147]) by mail.gmx.com (mrgmx002 [212.227.17.184]) with ESMTPSA (Nemesis) id 0MWSwU-1dRCIs0hNy-00Xe1x; Tue, 30 May 2017 11:37:04 +0200 From: Ian Farrer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Tue, 30 May 2017 11:37:03 +0200 Cc: Softwires-wg To: draft-ietf-softwire-map-mib@ietf.org X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:RTKgIIJM0WBR6jCGm+5COmOd8AUHBnwkHTcAvCsa6Izoew8/85j vo5j9uhKwEn/Nqy+Uu2rdfG7dSrEY2nnfkSI/zJZ/zXBFcBQaD3uiKKMw0EqNKX0In3WwC4 hkPbbbZSbWJpENPZdSaZisr6SJ2eSnuvQxUH2slGxJRWnrYRhohiwTQueblDM29fL+xbIEG W8W19mLYnatqXZyg464oA== X-UI-Out-Filterresults: notjunk:1;V01:K0:2payDYKJe+8=:nMENzEl6A8WwGCnfLDFPjg YAQaDg3ysNPGe08jIfYMW+isxuVo6ZawGa/Fh3amfZwPOFKiDjU30J7qUhNzVRm5vArIwhhW0 EZTiydElgjf7UbL+9Lak2a6zIagCizzK3Wa+TA/AkY5Fnnnv6KWEZQuBjQuCZ5iBzn6ssVNXC 1pYaUrLeXYeHd1b67w+RY4If1N1qEyYC9Izs3mPNRZ2RF45bhX0hOquS4SrCLYDm8P+d+41pA +hkMnuf2P25F/QLgOXOtJnOkqaQARDjWVUsmAHR7JQiv3qVbL+Sll39DOnKXxXATXeq11wXc4 zh8BNB3PCi0mw7g4v882P9pBuUNeXpYS3FK5d4XCm3LzJct0WS82VdR7fqYExmcj/qltHxFgV mLfsam5m/YKuj05m7G7hg1lx3a0u6TOWKN/LgNJqfUivBVoYDzTQINpHMlcu0chLeI9qYrlYQ AI59Lx5wVc+zVh6PMZnGLFP3zIzO0jrcrAlS9Z184Qmz4Y0Tg31LOfvKkVv6rdpArVqrQeGUF WxCbgXPaGTCk6ID2qIhp+8DVKAJXpXgQZQltaAKw9e4IdqbZloRHDtZt1k+vFRpvEAoQx4OKR 2uqdxYKZ8niAUyZZvDWS9/cBv5jpdSHHifCJD7DYh+uzjVuh4z6jNh804h81BL+7KiEslg2X8 eenLX6CkLm2Nh/z4EAAJEVslIk+EYcwSndIgpOVaz/62MchMO+gg0FfSJSwHlUe4aUZcoHO+l gVjJVLsGGGE87oEZUrnyuOCk/4OPvHxRxapfMLzlNRZDOwvZfKPtGXPz6J6Vt/mzCWB/lIcZa ufUvw6B Archived-At: Subject: [Softwires] Review of draft-ietf-softwire-map-mib-09 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, 30 May 2017 09:37:09 -0000 Hi, Here is a review of the current version of the draft. Cheers, Ian Introduction a1) This needs to be updated: RFC7597 is for MAP-E and encapsulation is = the single mode described there. RFC7599 deals with translation and so = probably doesn=E2=80=99t need to be mentioned at all as it=E2=80=99s not = part of the scope. a2) Section 4.1.2 The description of error cases is not correct. The checks that are = performed by both CE and BR validate that the v6, v4 and l4 ports are = consistent, not just the v6 and dest. ports. Please check RFC7597 = section 8.1. MIB Comments: b1) It appears that the intention to provide a single model to be used = by both BR and CE. For =E2=80=98mapRuleBRIpv6Address, the description = only provides information about what the CE does with this value. Is it = valid for a BR? What should the BR do with it? Also, for the =E2=80=98mapRuleType=E2=80=99 field - Is there a case = where a rule provisioned to a BR is not an FMR? (I=E2=80=99m not = familiar enough with MAP BR implementations to know if this is the case) b2) mapRuleID OBJECT-TYPE DESCRIPTION "An identifier used to distinguish the multiple = mapping rule which is unique with each CE in the same BR.=E2=80=9D [if - The description is unclear. If I understand the purpose of this = object, it is to give a unique identifier to each rule. If this is the = case, I would propose: =E2=80=9CA unique identifier used to distinguish = mapping rules.=E2=80=9D b3) The DESCRIPTION fields of mapRulePSIDLen and mapRuleOffset are = identical. The text makes sense for mapRulePSIDLen, but is incorrect for = mapRuleOffset. b4) RulePSID ::=3D TEXTUAL-CONVENTION DISPLAY-HINT "0x:" STATUS current DESCRIPTION "It represents the PSID represented in the hexadecimal version so as to display it more clearly." SYNTAX OCTET STRING (SIZE (4)) [if - Is 4 correct here? The allowable range for the PSID is 0..65535 = which is 2 octets] b5) mapRuleEALen OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The length of the Embedded-Address (EA) defined in mapping rule which will be assigned to CE." REFERENCE "EA: section 3 of RFC 7597." ::=3D { mapRuleEntry 10 } [if - This can also be constrained for allowable values (0..48)] b6) mapRuleType [if - The choice that is being presented here isn=E2=80=99t inline with = the F-Flag field described in sec 4.1 of RFC7598 (and by extension the = FMR description in RFC7597). The F flag defines if a rule can be used = for forwarding (i.e. mesh mode), not if it is a a BMR or an FMR (a BMR = can be used for mesh mode if the F flag is set). Any of the received = rules can be considered as a suitable BMR via the longest prefix match.