Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-mib-02.txt
Hiroshi Tsunoda <tsuno@m.ieice.org> Tue, 06 June 2017 16:22 UTC
Return-Path: <dr.h.t@ieee.org>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9316712947E for <bess@ietfa.amsl.com>; Tue, 6 Jun 2017 09:22:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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_NONE=-0.0001, SPF_PASS=-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 Dkn9N3w7QDBN for <bess@ietfa.amsl.com>; Tue, 6 Jun 2017 09:22:54 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 DDC8F1292D3 for <bess@ietf.org>; Tue, 6 Jun 2017 09:22:53 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id c10so81195614qtd.1 for <bess@ietf.org>; Tue, 06 Jun 2017 09:22:53 -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=uaeel1zR5RtNwPKnaSW1Kyeljz7gxWSLyQ6fuDNDfxU=; b=CqhuyIl49ZHNpGolOGCamLX99zAfCgA8rBH66G2YFY4XN9NmU+4a4QNoK/Bqp2uJGX 1SDOCVnQ/RGfMHIq/z44bYqHiO3U9BZRGi4009Ni66xKwwtZWyNmwU7wYH8ajgBqV6A3 yKDClroNLDADraed5srR5Q0utxxYnMxagqtxZgLv6H3cEebZg6fnpERPZoMDLRQbc4fD BJAnMpMBBo9hXS6bVGWI2hPTWWef5VRTYdOcI0UXyoHf1MGtY983ZanxCwczoatB6wJX 0AyGB67VRzwFoW1YQHNN0ijO3WKdM1Igr78wlc9mJygwO5z13Nt07pDTxNYvH5zvz3mk Uwag==
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=uaeel1zR5RtNwPKnaSW1Kyeljz7gxWSLyQ6fuDNDfxU=; b=huLp4qLs/PQp3352zTUmoGVJvTx/zoDZpOcQDhrxw5905oLGh9Hr4syfsU6RsZo+R6 alMjRKoPPtzH4X5kmCZxBnTvaC0zJHqcFpquBAieAQp0WeFOQKd+FiSiPoGjQNmwzcDb 1Zs+TcQKq564iPltNv6fbL7B0dmf7Czg3RwOuZZHl5syStUPS1dvjF6MiR7UnuX4XCex ad4FoXSALbh+LmaE3rJobSqa6qVli68YpKP2T7JkEY0aM3JbJBH5FG8yRpfHkyiibuNQ Q8aWJFxJ0kneKnPT1uln2VN3hrUEVElBN6NhENSNJ2oqXmJKow1qfrHGjVX5eX3u9mxx OFfQ==
X-Gm-Message-State: AKS2vOwHt9dIXW/gX/VlQctgXQxVttLWdVMX5lkDjWXSV/HaXucFU7Dj tx0NYDbaklM4M+/xzovh0iqb3HwLwGLq
X-Received: by 10.55.154.142 with SMTP id c136mr16650761qke.123.1496766172777; Tue, 06 Jun 2017 09:22:52 -0700 (PDT)
MIME-Version: 1.0
Sender: dr.h.t@ieee.org
Received: by 10.140.101.229 with HTTP; Tue, 6 Jun 2017 09:22:12 -0700 (PDT)
In-Reply-To: <CAPbjwkyWzJ7AJAFKXcWvhnBvu6C-oY3J+rH8rY4sb1U2tWH35w@mail.gmail.com>
References: <56E7D219.7000902@orange.com> <56FBD402.9040102@cisco.com> <56FBDD81.6080502@cysols.com> <11152_1459347064_56FBDE78_11152_10229_1_56FBDE77.6030605@orange.com> <56FBE17E.5090609@cisco.com> <570C9586.7030905@cysols.com> <570DC523.3040907@cysols.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28CC742F5@SZXEMA510-MBX.china.huawei.com> <BLUPR0501MB1715A41533590C81B9E54601D45C0@BLUPR0501MB1715.namprd05.prod.outlook.com> <CAPbjwkyWzJ7AJAFKXcWvhnBvu6C-oY3J+rH8rY4sb1U2tWH35w@mail.gmail.com>
From: Hiroshi Tsunoda <tsuno@m.ieice.org>
Date: Tue, 06 Jun 2017 18:22:12 +0200
X-Google-Sender-Auth: PfoujpSFLILTzsExeNFScXClXXk
Message-ID: <CAPbjwkycKadkFO5wTdmTAzdstN54P6CpPJ_eNUTWe3wYB7-q6Q@mail.gmail.com>
To: Glenn Mansfield Keeni <glenn@cysols.com>
Cc: Mach Chen <mach.chen@huawei.com>, Benoit Claise <bclaise@cisco.com>, "EXT - thomas.morin@orange.com" <thomas.morin@orange.com>, "ops-ads@ietf.org" <ops-ads@ietf.org>, Martin Vigoureux <martin.vigoureux@nokia.com>, "bess@ietf.org" <bess@ietf.org>, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/YEzgZkggXOl2rCVULIGG_RWFoI8>
Subject: Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-mib-02.txt
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jun 2017 16:22:56 -0000
Hi Glenn, I posted a new revision (-04) of MVPN-MIB document. In this revision, "Summary of MIB Module" has been rewritten. I hope this change improves the readability. URL: https://www.ietf.org/internet-drafts/draft-ietf-bess-mvpn-mib-04.txt Htmlized: https://tools.ietf.org/html/draft-ietf-bess-mvpn-mib-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-mib-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-mib-04 Please see notes below for other changes. 2017-03-01 16:00 GMT+01:00 Hiroshi Tsunoda <tsuno@m.ieice.org>: >> 1. Abstract: >> 1.2 "In particular, it describes managed objects to configure and/or >> monitor Multicast in MPLS/BGP IP VPNs (MVPN) on a router." >> Is this for any router or, a "Provider Edge" router ? >> Please fix accordingly. > > This point will be fixed in the next revision. Fixed. "Provide Edge" router is correct. >> 2. Introduction >> Are the objects "generic" to PIM-MVPN and BGP-MVPN or "common" >> to PIM-MVPN and BGP-MVPN ? Please change accordingly. > > This point will be fixed in the next revision. Fixed. "common" is correct. >> 2.5 The terminology section is a bit terse. Explaining the terms >> that are used, with reference to the protocol documents will >> improve readability. >> e.g. >> - MVPN, PE, PMSI/tunnels, >> - C-multicast routing exchange protocol (PIM or BGP), >> C-multicast states >> - I-PMSI, S-PMSI, provider tunnels > > Partially fixed. I will give more detailed explanation in the next revision. I have added some more explanation in this revision. >> 3. MVPN MIB. >> This gives the overview of the MVPN MIB. >> The MIB module aims to provide "configuring and/or monitoring" >> 3.1 In >> "This MIB enables configuring and/or monitoring of MVPNs on PE >> devices: the whole multicast VPN machinery....." >> "the whole multicast VPN machinery" is very difficult to define. >> Please use precisely defined terms. >> 3.2 In "To represent them,...." >> "them" seems ambiguous, please clarify. >> 3.3 The diagram needs some explanation. >> What do the boxes represent? Tables ? The labels are meant to be >> table names ? The table names do not match the labels. >> What do the arrows signify? Please explain. >> 3.4 The short explanation of the tables could be augmented with some >> information on what they represent and an idea of how they will >> be used. ( RFC 4382 provides a good example). I have rewritten "Sec.3.1 Summary of MIB Module". Eight tables can be categorized into two groups: tables for configuration and tables for monitoring. In this revision, the diagram representing the relationship among tables is divided to two separated diagrams based on the roles of tables. >> MIB definitions: >> 7. Wherever possible, please provide references for objects used in the >> MIB. The references will point to specific sections/sub-sections of >> RFCs defining the protocol for which the MIB is being designed. > > This will be addressed in the next revision. I have added some references but more are required. I will keep working on this. >> 8. MOs. >> 8.2 mvpnMvrfNumber OBJECT-TYPE >> SYNTAX Unsigned32 >> DESCRIPTION >> "The total number of MVRFs that are present on this device, >> whether for IPv4, IPv6, or mLDP C-Multicast." >> o Please make the description precise. E.g. if it is the sum of >> IPv4 MVRFs, IPv6 MVRFs and mLDP C-Multicast MVRFs state it >> explicitly. >> o The expression "present on this device" is used. >> Does "present" imply "configured" MVRFs or "active" MVRFs. >> If it is number of active MVRFs then one would expect that >> the number will vary (increase or decrease). If that is the >> case: >> replace >> SYNTAX Unsigned32 >> by >> SYNTAX Gauge32 I will try to update description in the next revision. >> 8.5 mvpnGenOperStatusChange OBJECT-TYPE >> SYNTAX INTEGER { createdMvrf(1), >> deletedMvrf(2), >> modifiedMvrfIpmsiConfig(3), >> modifiedMvrfSpmsiConfig(4) >> } >> DESCRIPTION >> "This object describes the last operational change that >> o The name does not look right. From the SYNTAX and the DESCRIPTION >> it appears that this is about config or MVRF change rather than >> "OperStatus" change. Please check and fix. >> o Please confirm that the values in the row itself will not be changed >> after creation. ( you do not have a 'modifiedMvrfConfig') The name has been changed into mvpnGenMvrfStatusChange. The name of the related object (mvpnGenOperStatusChangeTime) has also been changed into mvpnGenMvrfStatusChangeTime. >> 8.6 mvpnGenCmcastRouteProtocol OBJECT-TYPE >> MAX-ACCESS read-write >> ::= { mvpnGeneralEntry 4 } >> o You cannot have MAX-ACCESS read-write for a row that may be >> dynamically created. >> Replace >> MAX-ACCESS read-write >> by >> MAX-ACCESS read-create >> if you want to dynamically change that value, otherwise, >> MAX-ACCESS read-only >> will suffice. Fixed. Now, "MAX-ACCESS read-create" is used. >> 8.8 mvpnGenIpmsiConfig OBJECT-TYPE >> DESCRIPTION >> "This points to a row in mvpnPmsiConfigTable, >> for I-PMSI configuration." >> o Please specify the expected behaviour when it is not an I-PMSI >> 8.9 mvpnGenInterAsPmsiConfig >> o same comment as above These will be addressed in the next revision. >> 8.10 mvpnGenRowStatus >> mvpnGenRowStatus OBJECT-TYPE >> SYNTAX RowStatus >> DESCRIPTION >> "This is used to create or delete a row in this table." >> o The description is inadequate for an implementor (and >> others too). >> o You must have a mvpnGenRowStorageType or the DESCRIPTION of >> mvpnGenRowStatus must indicate what will happen to the row >> after an agent restart I will try to address this comment in the next revision. >> 9. Similar comments (8.1 ~ 8.10) for the remaining tables in the MIB >> Particularly 8.10 for the RowStatus type objects >> mvpnGenRowStatus >> mvpnPmsiConfigRowStatus >> mvpnSpmsiConfigRowStatus. >> Please check and fix. I will try to address this comment in the next revision. >> 10. mvpnMvrfChange NOTIFICATION-TYPE >> OBJECTS { >> mvpnGenOperStatusChange >> } >> ::= { mvpnNotifications 2 } >> >> o should be { mvpnNotifications 1 } >> o Include the MOs that the administrator/manager may want to >> see in OBJECTS. The first comment is addressed, the second one is TBD. >> 11. The Security Considerations section does not follow the Security >> Guidelines for IETF MIB Modules >> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. > I rewrite this part according to the guideline described in RFC4181 Sec.3.4. However, there are some TBDs in this part that should be updated according to the update in the main body of MIB module. >> 12. COMPLIANCE. >> 12.1 You seem to mandate MAX-ACCESS read-write/read-create for >> compliance. Is this intended? Configuration capability MUST be >> supported? Please note that sec 2. MVPN MIB says >> "This MIB enables configuring and/or monitoring of MVPNs ..." >> The current compliance requirement contradicts the above claim. >> Please check and fix. >> >> It is general and sound practice to allow for MAX-ACCESS >> read-only compliance. Some implementations may support >> monitoring but not configuration. >> Please check and fix. In this revision, I have added additional ReadOnly compliance Now, there are following two MODULE-COMPLIANCE statements are defined in this module. - mvpnModuleFullCompliance - mvpnModuleReadOnlyCompliance Best regards, -- tsuno
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-… Glenn Mansfield Keeni
- [bess] MIBDoc review of draft-ietf-bess-mvpn-mib-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Mach Chen
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Mach Chen
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Jeffrey (Zhaohui) Zhang
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Mach Chen
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Mach Chen
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Jeffrey (Zhaohui) Zhang
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Mach Chen
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Jeffrey (Zhaohui) Zhang
- [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Benoit Claise
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Jeffrey (Zhaohui) Zhang
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… thomas.morin
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… thomas.morin
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni