Re: [Softwires] Opsdir last call review of draft-ietf-softwire-map-mib-12
"Yu Fu" <fuyu@cnnic.cn> Sun, 08 April 2018 08:44 UTC
Return-Path: <fuyu@cnnic.cn>
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 BD55D124207; Sun, 8 Apr 2018 01:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 94ytVgIpDOoE; Sun, 8 Apr 2018 01:44:53 -0700 (PDT)
Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 66BB8126CB6; Sun, 8 Apr 2018 01:44:51 -0700 (PDT)
Received: from LIUXD (unknown [218.241.103.63]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0C5wNx_1slapN7nAA--.9600S3; Sun, 08 Apr 2018 16:44:47 +0800 (CST)
From: Yu Fu <fuyu@cnnic.cn>
To: 'Qin Wu' <bill.wu@huawei.com>
Cc: softwires@ietf.org, ietf@ietf.org, draft-ietf-softwire-map-mib.all@ietf.org, ops-dir@ietf.org
References: <152301400592.3723.16935065114036251800@ietfa.amsl.com>
In-Reply-To: <152301400592.3723.16935065114036251800@ietfa.amsl.com>
Date: Sun, 08 Apr 2018 16:44:51 +0800
Message-ID: <010601d3cf15$dc4d4270$94e7c750$@cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: zh-cn
Thread-Index: AdPNm1L/Bv7FUXHtSdeT/BudtwPqJABQeLqg
X-CM-TRANSID: AQAAf0C5wNx_1slapN7nAA--.9600S3
X-Coremail-Antispam: 1UD129KBjvJXoWxAr15Aw47Zry3CF43ZF1DKFg_yoW5Zw48pa y8ta17KrWxXry7J3Z7Za18uryIvrs3Wa15Jry5K342y390g3WvvF4rKayY9F1UCrW8Aayj vrWava98WFyqyaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkYb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IE w4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMc vjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Avz4vE14v_GFyl42xK82IY c2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU0o89tUUUUU==
X-CM-SenderInfo: pix13q5fqqxugofq/
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/5LCE4w-6z5PKp6Zi2GCdV2ttKU8>
Subject: Re: [Softwires] Opsdir last call review of draft-ietf-softwire-map-mib-12
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Apr 2018 08:44:56 -0000
Hi, Qin Wu Thank you for your kind comments and suggestions. Please see my reply inline >I have reviewed this document as part of the Operational directorate's >ongoing effort to review all IETF documents being processed by the IESG. >These comments were written with the intent of improving the operational >aspects of the IETF drafts. Comments that are not addressed in last call >may be included in AD reviews during the IESG review. Document editors >and WG chairs should treat these comments just like any other last call >comments. This draft defines MIB for MAP-E for use with SNMP. It is well >written and I have no concern on operational aspects. Here are a few >editorial comments as follows: 1. Please remove unused reference >RFC7598. [fuyu] The RFC7598 is referenced by the definition of RuleType >2. Section 4.1, the 1st paragraph, last sentence Can you list >which parts of the IF-MIB in more details here the MAP-E depends on? [fuyu] Yes, I will update it in more detail as : "MAP-E MIB is configurable on a per-interface basis, so it depends on several parts of the IF-MIB by ifEntry [RFC2863]". >3.Section 4.1.1 two categories on mapping rules In MIB module definition, it >looks the mapping rule is divided into three categories, i.e., BMR, FMR and >BMRandFMR,which is not consistent with two categories classification >defined in section 4.1.1, I am wondering whether we also have fmrandbmr, >i.e., Forwarding Mapping Rule can also be basic Mapping Rule, in other >words, is fmrandbmr same as bmrandfmr? Is fmrandbmr a set that belong >to both fmr and bmr? Try to understand this, would it be great to clarify >this in section 4.1.1. [fuyu] In the section 5 of RFC7597, it defines two types of mapping rules: Basic Mapping Rule (BMR) and Forwarding Mapping Rule (FMR). So we should accord with this definition in RFC7597. And in the section 4.1 of RFC7598, it defines F-flag to specify whether the rule is to be used for forwarding (FMR). If set, this rule is used as an FMR; if not set, this rule is a BMR only and MUST NOT be used for forwarding. And a BMR can also be used as an FMR for forwarding if the F-flag is set. So in the RuleType definition, it defines bmrAndfmr to specify this scenario. I will update a description as above in section 4.1.1. >4.Section 4.1.2 two kind of invalid packets In MIB >module definition, two MapSecurityCheckEntries are defined, one is >mapSecurityCheckInvalidv4, the other is mapSecurityCheckInvalidv4. I am >wondering whether these two entries are corresponding to two kind >of invalid >packets described in section 4.1.2. also I am not sure I understand payload >source IPv4 address and port, are these payload source and port are >referred to received packets’ source IPv4 address port mentioned in >section 4.1.2. [fuyu] Yes, two kind of invalid packets In MIB module definition is mapSecurityCheckInvalidv4 and mapSecurityCheckInvalidv6, which are corresponding to two kind of invalid packets described in section 4.1.2. I will update a clarify in the MIB definition. >5.Section 6 does this document request IANA to assign new OID under >mib-2 or just use existing OID under mib-2? [fuyu] It request IANA to assign a new OID. Thanks again for your review Cheers Yu