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
>>
>