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