Re: [MIB-DOCTORS] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-07
Hiroshi Tsunoda <tsuno@m.ieice.org> Mon, 05 June 2017 14:41 UTC
Return-Path: <dr.h.t@ieee.org>
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E98129415 for <mib-doctors@ietfa.amsl.com>; Mon, 5 Jun 2017 07:41:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ieee-org.20150623.gappssmtp.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 mj9XABasbUWR for <mib-doctors@ietfa.amsl.com>; Mon, 5 Jun 2017 07:41:00 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 597961293D9 for <mib-doctors@ietf.org>; Mon, 5 Jun 2017 07:41:00 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id l14so54957413ywk.1 for <mib-doctors@ietf.org>; Mon, 05 Jun 2017 07:41:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jPbVBbfl5yZNvZ+ce8wJ4xztxujWMnKEAHQQCrld17A=; b=KspTbvSlW/5FKsCeUvkn6haDy9FYkFNQwgFNuv80Kh0+eW1nN+9z0DIYoJspA/TaQn LtQY8KysFlUukylfONGNTAnYXY9xWhaYQXRPS/fHpGrxsmH2PElBVRnylaCXX2H/HqCR Cf2uxlDS2JjFKQQLYw+rF6LQKrrWE8m4HRzQp6Yfm//GvjTVyJJ6bWJc3ojo/qq9SCxD Jrq5EsmxA0yJfs2hTDNZaChRqp0RpbQikK6R1xsGXRLWuRzn2Db7/B0S945+NKA/4BqD pwABTSHZTRslJFyQrDAToAgyxwTQNmIjfDtGbtvceCJ1VbVeBq+EIC2S8myXBcU6ojCq 9Org==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jPbVBbfl5yZNvZ+ce8wJ4xztxujWMnKEAHQQCrld17A=; b=hnmM/xu7zcQb6e7UPxfIYkhYzDOUXT56QOutSxWPAsKAwRXYJbvGgs3RH7u5obpvKf 7qq2Xq9f3qLMbPmxuoUCh/xrq+bKIn9CHtxbNFDrjnMFURdkyqAATErNZ9bN5ULqr5/q 5adVzVrwL+dbYVkDh0QDjs/m8R7dMnZecNVJKIEfAn5+CXcQbTM33sg3CmRa906L6SFr KGX4ps/Rci2yMr7N5kur1FibNIhS0/z/QVxhH0eJx7JXGZaXi1Gja7ICpMPfm/fhnCrM x1d0L0WVI62wGlDuKlTlIiCMk1wLwm2/ZvYPUhZdGPviV/D2CX0sd2VDCd1rrjpg+/0w scfA==
X-Gm-Message-State: AKS2vOzDQFnqqY+OUCvUGMPHkoaWnxnixvoJ/njK73yylZYcNp7mQeNO MnjN/ZzS/NBRmWz/Bi9L16mSlY00nJDa
X-Received: by 10.55.154.142 with SMTP id c136mr9204803qke.123.1496673659217; Mon, 05 Jun 2017 07:40:59 -0700 (PDT)
MIME-Version: 1.0
Sender: dr.h.t@ieee.org
Received: by 10.140.101.229 with HTTP; Mon, 5 Jun 2017 07:40:18 -0700 (PDT)
In-Reply-To: <3bb4da95-ce97-385d-ae59-963d8c6f3db0@cysols.com>
References: <56E7D219.7000902@orange.com> <BLUPR0501MB17151A695785D4D8DD485633D4690@BLUPR0501MB1715.namprd05.prod.outlook.com> <b4249e61-0a11-2ce1-c846-67096858fa2c@cysols.com> <BLUPR0501MB1715A3B288A27A39E99203B8D4490@BLUPR0501MB1715.namprd05.prod.outlook.com> <c757a323-24a7-2696-657e-88f8e15e8a36@cysols.com> <CAPbjwkyFeX-S=sJwNMX-fgWThnMMiu_nF8xvcMow_BgJSfwsSQ@mail.gmail.com> <5e663cf0-1418-c410-bcf8-b235ee73fc29@cysols.com> <CAPbjwkyN0yLkpOXWt8D2-Niw7BCoujF+8JLjrPwgWobF03hZ7g@mail.gmail.com> <6f89f1f2-31e9-bf4a-05e9-1bb6e02f339e@cysols.com> <CAPbjwkyEnCGZEsGKjHozWmg-X-P3483=205BBGV9+DxbfJsDmQ@mail.gmail.com> <03f83a27-e397-818d-65e7-27f95cd6e6e0@cysols.com> <CAPbjwkzkKOULh98QBmbArFWXv=o_pyd7J82u7_GvwkWELdY0Pg@mail.gmail.com> <8f9aaac8-f44d-4844-d376-9c37bd7a81e0@cysols.com> <1848f053-9a5e-2f52-09b4-ce0e1688b557@cysols.com> <CAPbjwkzgORotsvYPWF2fqC7icJFXi5z10D1UHDTtYp1wojxw0Q@mail.gmail.com> <CAPbjwkw=zTUB+RL2MN7g2CeW07Xc6o39g6sf6ZpKap1+49ENiw@mail.gmail.com> <3bb4da95-ce97-385d-ae59-963d8c6f3db0@cysols.com>
From: Hiroshi Tsunoda <tsuno@m.ieice.org>
Date: Mon, 05 Jun 2017 16:40:18 +0200
X-Google-Sender-Auth: RKAiA8LlSr_WNGUirZC39j9h2Ao
Message-ID: <CAPbjwkwgCfL9rtHrnTnABjykWAN1n_GUg_s5VZwg3-CWT754jg@mail.gmail.com>
To: Glenn Mansfield Keeni <glenn@cysols.com>
Cc: Mach Chen <mach.chen@huawei.com>, "mib-doctors@ietf.org" <mib-doctors@ietf.org>, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "EXT - thomas.morin@orange.com" <thomas.morin@orange.com>, Martin Vigoureux <martin.vigoureux@nokia.com>, "bess@ietf.org" <bess@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mib-doctors/Kt62Zs1beettR2zrsQ3cNo9muMo>
Subject: Re: [MIB-DOCTORS] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-07
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: MIB Doctors list <mib-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mib-doctors/>
List-Post: <mailto:mib-doctors@ietf.org>
List-Help: <mailto:mib-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jun 2017 14:41:03 -0000
Dear Glenn, Thank you very much for your review. I am going to resubmit a revision as soon as possible. Please wait for a moment regarding MVPN-MIB. -- tsuno 2017-06-05 12:24 GMT+02:00 Glenn Mansfield Keeni <glenn@cysols.com>: > Dear Tsuno/Zhang, > Thanks for the good work. The document readability is > vastly improved. > The following are the comments on > draft-ietf-bess-l2l3-vpn-mcast-mib-08.txt > > Glenn > > 0. The MIBs > L2L3-VPN-MCAST-TC-MIB and > L2L3-VPN-MCAST-MIB > compile OK. There are level-5 warnings > mibs/L2L3-VPN-MCAST-TC-MIB:64: [5] {type-unref} warning: current type > `L2L3VpnMcastProviderTunnelType' is not referenced in this module > mibs/L2L3-VPN-MCAST-TC-MIB:90: [5] {type-unref} warning: current type > `L2L3VpnMcastProviderTunnelId' is not referenced in this module > mibs/L2L3-VPN-MCAST-TC-MIB:90: [5] {type-without-format} warning: type > `L2L3VpnMcastProviderTunnelId' has no format specification > mibs/L2L3-VPN-MCAST-TC-MIB:169: [5] {type-unref} warning: current type > `L2L3VpnMcastProviderTunnelPointer' is not referenced in this module > mibs/L2L3-VPN-MCAST-TC-MIB:198: [5] {type-unref} warning: current type > `L2L3VpnMcastProviderTunnelPointerType' is not referenced in this module > > These may be ignored. > > 1. The explanations for the size of the identifiers for each tunneling > technology in TC L2L3VpnMcastProviderTunnelId > is nicely done. These are aligned with definitions in rfc6514. > In > noTunnelId (0), -- No tunnel information > is there a specific reason to name it 'noTunnelId' instead of > 'noTunnelInfo'. > > 2. The TCs > L2L3VpnMcastProviderTunnelPointerType, and > L2L3VpnMcastProviderTunnelPointer > Are probably not required. The value of the RowPointer [rfc2579] > object is ' the name of the instance of the first > accessible columnar object in the conceptual row' > So the pointer will explicitly contain the name of the table. > An auxilliary type object to indicate the table name is not > necessary. > [This is an oversight on my part. I should have noticed this earlier.] > > > Other Editorials: > P-2. Sec-1. > 1. para-1 makes tedious reading. Could this be improved? > > 2. "Border Gateway Protocol/ MultiProtocol Label Switching (BGP/MPLS)" > The usage of the '/' here is unclear. > > 3. "and L3 VPNs. Therefore, TCs and MOs defined" > The context of the 'Therefore' is not clear. > > 4. "The are two type" > Probably s/The/There/ ? > > > > > > > On 2017/05/26 21:25, Hiroshi Tsunoda wrote: >> >> Dear Glenn, >> >> Thank you for your thorough review and waiting for the updated. >> >> I posted a new revision taking into account your latest comments. >> In the new revision, all of your comments are addressed. >> I also revised the draft to improve the readability. >> >> Please see some notes below. >> >> URL: >> >> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-08.txt >> Htmlized(1): >> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-08 >> Htmlized(2): >> >> https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-08 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-08 >> >> 2017-05-02 14:44 GMT+02:00 Hiroshi Tsunoda <tsuno@m.ieice.org>: >>> >>> 2017-05-01 12:32 GMT+02:00 Glenn Mansfield Keeni <glenn@cysols.com>: >>>> >>>> Dear Tsuno/Zhang >>>> Thanks for waiting. The review of >>>> draft-ietf-bess-l2l3-vpn-mcast-mib-07 follows. >>>> >>>> Glenn >>>> >>>> C1. Abstract: >>>> The draft now defines 2 MIB modules. Please revise the abstract >>>> and probably the title of the document too. >> >> >> Fixed. >> >>>> C2. The MIBs (L2L3-VPN-MCAST-TC-MIB, L2L3-VPN-MCAST-MIB) compile OK. >>>> (Three {type-unref} warnings are there, may be ignored.) >> >> >> I have confirmed that the latest version of MIB modules can also be >> compiled successfully. >> >>>> C3. Page 4: >>>> s/3. Summary of MIB Module/ >>>> 3. Summary of MIB Modules/ >> >> >> Fixed. >> >>>> C4. Page 6: L2L3VpnMcastProviderTunnelPointer DESCRIPTION >>>> s/"Denotes a pointer to the row pertaining to a table entry/ >>>> /"This textual convention represents a pointer to a row in >>>> the table represented by the following object of type >>>> L2L3VpnMcastProviderTunnelPointerType./ >> >> >> Fixed. >> >>>> C5. Page 7: L2L3VpnMcastProviderTunnelPointer DESCRIPTION >>>> The explanation in the last paragraph seems out of place. >>>> It may be removed. >> >> >> Fixed. >> >>>> C6 Page 7: L2L3VpnMcastProviderTunnelPointerType DESCRIPTION >>>> it is unclear when the value 'null(0)' will be used. >>>> Is this allowed only when the corresponding object of type >>>> L2L3VpnMcastProviderTunnelPointer has a value that is a >>>> zero-length string ? If yes, please make that clear. >> >> >> 'null(0)' is the default value and indicates that the corresponding >> L2L3VpnMcastProviderTunnelPointer object is not assigned. >> In the new revision, this point is described clearly. >> >>>> C7. Page 9: l2L3VpnMcastPmsiTunnelAttributeTable DESCRIPTION >>>> s/created by a PE router/maintained by a PE router/ >> >> >> Fixed. >> >>>> C8. Page 12: l2L3VpnMcastPmsiTunnelAttributeId >>>> Do you really want to keep this object in L2L3-VPN-MCAST-MIB. >>>> It will change every time a new "tunnel type" is added to >>>> L2L3VpnMcastProviderTunnelType. That will defeat the purpose >>>> of separating L2L3-VPN-MCAST-TC-MIB from L2L3-VPN-MCAST-MIB >>>> It may be a good idea to define a textual convention like >>>> L2L3VpnMcastPmsiTunnelAttributeId >>>> in the L2L3-VPN-MCAST-TC-MIB and use that textual convention >>>> in the L2L3-VPN-MCAST-MIB >> >> >> Thank you for your suggestion. I revised the definition according to >> your suggestion. >> >>>> C9. Page 13: l2L3VpnMcastPmsiTunnelAttributeId DESCRIPTION >>>> A. s/Thus, the size of this object is 16 octets in IPv4/ >>>> Thus, the size of this object is 8 octets in IPv4/ >> >> >> Fixed. >> >>>> B. The last 2 paragraphs do not tie up well with the previous >>>> paragraphs in the DESCRIPTION. >> >> >> Those 2 paragraphs are removed in the new revision. >> >>>> C. In the last paragraph >>>> "this object is a pair of source and group IP addresses" >>>> is unlcear. Please clarify. >> >> >> Fixed. In the new revision, this point is described as follows. >> >> "the corresponding Tunnel Identifier is composed of >> the source IP address and the group IP address." >> >>>> C10. Page 15: Security Considerations >>>> I would think that any field that reveals information about >>>> a Multicast VPN and/or its members is sensitive. >>>> Does the l2L3VpnMcastPmsiTunnelAttributeId field reveal >>>> information about the participating members? If yes, it must >>>> be marked as sensitive. >> >> >> I revised this point according to your suggestion. >> >>>> C11. Editorial: >>>> >>>> A. This does not pertain to the MIBs as such, >>>> but I am uncomfortable with the several variations >>>> of the phrase >>>> "Layer 2 and Layer 3 Virtual Private Networks (VPN) >>>> that support multicast" >>>> that appears in the text. I do not have a solution >>>> on hand but it would be perhaps be more readable to >>>> define and use a simple name/notation the beast for >>>> which the MIB is being designed (e.g. "L2L3VPNMCast"). >>>> >>>> B. Same with the phrase >>>> "Layer 2 (L2) and Layer 3 (L3) VPN (Virtual Private >>>> Network) >>>> it would be probably be easier on the reader if an >>>> abbreviation like L2L3VPNs was used where ever >>>> applicable. >> >> >> Thank you for your comments. >> In the new reivsion the abbreviation "L2L3VPNMCast" >> is defined and used throughout the draft. >> >>>> C12. P2:Para4: s/within MIB module specifications//; >> >> >> Fixed. >> >>>> C13. General: >>>> A. The DESCRIPTION clauses could do would some more >>>> packing. (Too much space at the end of lines) >>>> B. Please check the articles a/an/the once again. Some >>>> usages do not seem right to me. >> >> >> Fixed. >> >> Sincerely yours, >> >> -- tsuno >> >
- Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-i… Glenn Mansfield Keeni
- Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-i… Hiroshi Tsunoda
- Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-i… Glenn Mansfield Keeni
- Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-i… Glenn Mansfield Keeni
- Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-i… Glenn Mansfield Keeni
- Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-i… Jeffrey (Zhaohui) Zhang
- [MIB-DOCTORS] MIBDoc review of draft-ietf-bess-l2… Glenn Mansfield Keeni
- Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-i… Glenn Mansfield Keeni
- Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-i… Benoit Claise
- Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-i… Jeffrey (Zhaohui) Zhang
- Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-i… Hiroshi Tsunoda
- Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-i… Glenn Mansfield Keeni
- Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-i… Hiroshi Tsunoda
- Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-i… Glenn Mansfield Keeni
- Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-i… Hiroshi Tsunoda
- Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-i… Glenn Mansfield Keeni
- Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-i… Glenn Mansfield Keeni
- Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-i… Hiroshi Tsunoda
- [MIB-DOCTORS] MIBDoc review of draft-ietf-bess-l2… Glenn Mansfield Keeni
- Re: [MIB-DOCTORS] MIBDoc review of draft-ietf-bes… Hiroshi Tsunoda
- Re: [MIB-DOCTORS] MIBDoc review of draft-ietf-bes… Hiroshi Tsunoda
- Re: [MIB-DOCTORS] MIBDoc review of draft-ietf-bes… Glenn Mansfield Keeni
- Re: [MIB-DOCTORS] MIBDoc review of draft-ietf-bes… Glenn Mansfield Keeni
- Re: [MIB-DOCTORS] MIBDoc review of draft-ietf-bes… Hiroshi Tsunoda
- Re: [MIB-DOCTORS] MIBDoc review of draft-ietf-bes… Hiroshi Tsunoda
- Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-i… Glenn Mansfield Keeni