Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt
Glenn Mansfield Keeni <glenn@cysols.com> Sun, 17 July 2016 14:45 UTC
Return-Path: <glenn@cysols.com>
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 ADF0412B01D; Sun, 17 Jul 2016 07:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 JYfES_M1bQ56; Sun, 17 Jul 2016 07:45:16 -0700 (PDT)
Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D7B12B007; Sun, 17 Jul 2016 07:45:15 -0700 (PDT)
Received: from [192.168.0.91] (cysvpn04.priv.cysol.co.jp [192.168.0.91]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.9/8.14.9) with ESMTP id u6HEivBj068793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 17 Jul 2016 23:44:58 +0900 (JST) (envelope-from glenn@cysols.com)
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, Benoit Claise <bclaise@cisco.com>, "EXT - thomas.morin@orange.com" <thomas.morin@orange.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> <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>
From: Glenn Mansfield Keeni <glenn@cysols.com>
Message-ID: <f2d0c86e-5b2a-dbf9-e3a9-2bf66002f263@cysols.com>
Date: Sun, 17 Jul 2016 23:44:52 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <c757a323-24a7-2696-657e-88f8e15e8a36@cysols.com>
Content-Type: text/plain; charset="iso-2022-jp"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/U_xoKVjbLcW2-dcKQ9YCwy75ZQY>
Cc: "mib-doctors@ietf.org" <mib-doctors@ietf.org>, "ops-ads@ietf.org" <ops-ads@ietf.org>, Mach Chen <mach.chen@huawei.com>, Martin Vigoureux <martin.vigoureux@nokia.com>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 17 Jul 2016 14:45:21 -0000
Jeffrey and team, Any progress on the MIB matters (draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt, draft-ietf-bess-mvpn-mib-03.txt )? Glenn On 2016/06/07 18:39, Glenn Mansfield Keeni wrote: > Hi Jeffrey, > Thanks for the good work on draft-ietf-bess-l2l3-vpn-mcast-mib > document. It took me some time to do this review. But now here it > is. A (near complete) review of > draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt is attached. Hope this helps. > I understand that the Security Considerations section is TBD. > > Glenn > > On 2016/05/19 4:48, Jeffrey (Zhaohui) Zhang wrote: >> Hi Glenn, >> >>> -----Original Message----- >>> From: Glenn Mansfield Keeni [mailto:glenn@cysols.com] >>> Sent: Sunday, May 08, 2016 11:02 AM >>> To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Benoit Claise >>> <bclaise@cisco.com>; EXT - thomas.morin@orange.com >>> <thomas.morin@orange.com> >>> Cc: Mach Chen <mach.chen@huawei.com>; ops-ads@ietf.org; Martin Vigoureux >>> <martin.vigoureux@nokia.com>; bess@ietf.org; mib-doctors@ietf.org >>> Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib- >>> 02.txt >>> >>> Jeffrey, >>> > Thanks for your comments. I've addressed most of your comments >>> > in the new revision: >>> Thanks for your cooperation. I will need at least one more revision >>> with the following comments/recommendations addressed before I will >>> be able to complete the detailed review. In the following the numbers >>> refer to the issue numbers in the initial review. The issues that are >>> addressed and closed are not listed. For brevity, the issue >>> descriptions have been trimmed. In case of doubts please look at the >>> response mail appended below. >>> Hope this helps. >> >> Thanks for your detailed comments/suggestions. I posted a new revision >> with the following issues addressed. >> >> URL: >> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt >> >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ >> Htmlized: >> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-04 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-04 >> >> Please see some notes below. >> >>> >>> Glenn >>> >>> ------------------------------------------------------------------- >>> >>> Comments: >>> >>> 1.1 >>> > I had thought this would be standard/obvious for all MIB objects - >>> We will comeback to this time and again, whereever possible make >>> matters explicit and clear. That will help. >>> > Is it enough to say something similar? For example: >>> > In particular, it describes common managed objects used >>> > to configure and/or monitor both L2 and L3 VPN Multicast. >>> That is better. >> >> I take it that this is already closed in -03 revision. >> >>> >>> 2.2 >>> > Having said that, I'll explain PMSI a bit further. >>> PMSI explanation is good. >>> Please use the same style/format for I-PMSI and S-PMSI. >> >> I think -03 revision already use the same style/format for I-PMSI and >> S-PMSI? >> >>> >>> 2.3 >>> > No difference. I was using "Layer 3" or "L3" but it was pointed out >>> > that the layer 3 VPN is often referred to IP VPN in other RFCs and I >>> > was advised to change it accordingly. Looks like I did not change all >>> > the cases. >>> > On the other hand, I noticed that RFC 4382 does use "Layer 3 VPN" so >>> > I'll change it back. >>> No problems. just make sure that the same expression/notation is used >>> uniformly. >> >> I take it that this is also addressed in -03 already. >> >>> 3. >>> > > > 3. Summary of MIB Module. >>> > > > An overview of the L2L3-VPN-MCAST-MIB will be good- the >>> > > > structure of the MIB, short descriptions of the table(s) >>> > > > including usage of the table(s) for management and/or by >>> > > > other MIB(s). >>> > >>> > I had that, but have added one sentence about the only table. >>> A sentence or two about the textual convention will be good. >> >> Added in -04. >> >>> > > > 4. MIB syntax checking: >>> > > > smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB >>> 2>L2L3-VPN-MCAST-MIB.txt >>> > >>> > I used simpleweb's validation tool but looks like I did not use the >>> > strictest level of validation. I've now fixed the following issues >>> and >>> > verified. >>> Good. >>> 5. >>> > > > >>> > > > 5. REFERENCE clauses: Please use REFERENCE clauses liberally. >>> > > > Wherever possible, provide references for objects used in >>> > > > the MIB. The references will point to specific sections/ >>> > > > sub-sections of the RFCs defining the protocol for which the >>> > > > MIB is being designed. It will greatly improve the >>> readability >>> > > > of the document. >>> > >>> > Added. >>> I would recommend using the REFERENCE clause as in rfs4382 and >>> improve on it. >>> Specifically, instead of keeping the reference in the DESCRIPTION >>> clause move it to a separate REFERENCE clause. The addition of the >>> section number is an improvement. It is friendlier to the reader. >>> Note. Same comment for other OBJECTs too. >> >> Oh I missed that. All fixed. >> >>> 7.1 >>> > > > 7.1 CONTACT-INFO >>> > > > Following the conventions (including indentation style) will >>> > > > improve the readability. (e.g. RFC4382, RFC5132). >>> > > > Will be good if it does not overflow into the next page. >>> > >>> > Fixed. >>> The format is OK. The Postal address etc., need not have been >>> deleted. Please put the complete contact information as in the >>> Author's Address. (RFC 2578 section 5.7 gives a usage example). >> >> Fixed. >> >>> 7.3 >>> > I kept "experimental 99" so that I could continue to use mib tools >>> > to validate; but I added notes for the editor to replace them as you >>> > indicated. >>> Use of "experimental 99" is not recommended. >> >> Do you mean 99 is not a good number? What about 9999? As I explained, >> I kept it so that we can use mib tools to validate, and I've added >> detailed notes for the editor. >> >>> 8 >>> > > > 8. Specific MO and TC related comments. >>> > Are spaces allowed? I don't know so I used hyphen. For now I replace >>> > with things like rsvpP2mp. >>> Yes. Camelcase is an allowed practice. SMI does not mind it. >> >> Ok this is closed already then. >> >>> 8.2 >>> > > > 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>> > The intent is to simply return the octet value of the flags >>> > field, w/o listing individual bits like "Leaf Information Required". >>> > More bits could be defined in the future but the MIB would not >>> change. >>> > >>> > Is that OK? >>> As far as possible, the meaning of the objects must be made clear. >>> That will help implementors and operators- users of the MIB. >> >> I added the definition for one existing bit and reference to the IANA >> registry being created for this flag field. >> >>> >>> 8.3 >>> > > > 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>> > Depending on the tunnel type, there could be different sizes. >>> > Future tunnel types could have other sizes that not specified >>> > today. I was thinking to just give a size >>> > tPmsiTunnelAttributeId OBJECT-TYPE range so that it is flexible. >>> > Is that ok? >>> I see that you have changed the size upper limit to 50. >>> If the size varies continuously from 0 to 50 the above description >>> is correct. >>> Please confirm, explain and cite appropriate reference. If the size >>> may change in the future that must be stated too. >> >> I changed to discrete sizes for currently defined tunnel types. >> >>> >>> 8.4 >>> > > > 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>> > > > SYNTAX RowPointer >>> > > > MAX-ACCESS read-only >>> > > > STATUS current >>> > > > DESCRIPTION >>> > > > "If the tunnel has a corresponding interface, >>> > > > this is the row pointer to the ifName table." >>> > > > o DESCRIPTION looks incorrect. Please fix it. Do you >>> > > > want to say this object points to the corresponding >>> > > > row in the ifTable? >>> > >>> > Yes. Fixed. >>> Not quite. >>> What is ifName table ? ifName is a columnar object in the ifXTable. >>> Is l2L3VpnMcastPmsiTunnelIf a pointer to the corresponding row in >>> the >>> ifXTable table ? Please fix accordingly. >> >> You're right. Fixed. >> >>> >>> 9. >>> > > > 9. 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. >>> > > > Please fix. >>> > >>> > I was really hoping that it would not have to be that >>> > tedious. SNMP/MIB secur >>> ity should be no different from the >>> > CLI security - once you secure the infrastructure >>> > then what's more to do? >>> > >>> > I'll need more time to work on this. Let me try to address >>> > the issues in the other mib first and come back to this. >>> >>> Please take your time. Looking at examples will help. And let me >>> know where I can help. >> >> I will need to work on that later. >> >>> >>> 10.1 >>> > > > 10.1 Checking nits according to >>> > > > http://www.ietf.org/id-info/checklist : >>> > Should I break them into different lines or just keep them >>> > as is? Any example of expected indentation if I break the >>> > lines? >>> No problems at all to break lines. >>> l2L3VpnMcastGroups OBJECT IDENTIFIER >>> ::= {l2L3VpnMcastConformance 1} >>> Should do. >> >> Done. >> >>> >>> 10.2 >>> > > > 10.2 Checking references for intended status: Proposed Standard >>> > > > == Missing Reference: 'RFC 7117' is mentioned on line 76, >>> > > > but not defined >>> > > > 'described in [RFC6513, RFC6514, RFC 7117] and other >>> > I hope I understood and fixed it (removing the space in "RFC 7117"). >>> I would recommend that you put it as [RFC6513], [RFC6514], [RFC7117] >>> That is simpler to parse. >> >> I see some other documents do not have comma between multiple >> references so I followed that. >> >>> >>> > > > 11. There is another WIP MVPN-MIB in >>> > > > draft-ietf-bess-mvpn-mib-02.txt >>> > > > MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MIB. >>> > > > Is there a good reason for not merging the 2 documents? >>> > > > I have not seen any discussion or explanation on this. >>> > > > I may have missed it. >>> > > > Please clarify or, give some pointers. >>> > >>> > As mentioned in the introduction: >>> > >>> > this memo describes managed objects common to both VPLS >>> > Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>> > MVPN-MIB is for MVPN. There was another VPLS Multicast MIB >>> > in the work and both would reference common >>> >>> > objects defined in this MIB. >>> >>> OK. So you are saying that this MIB contains core objects that >>> will be used to manage implementations of various multicast VPN >>> protocols e.g. [RFC7117], [RFC6513],[RFC6514] ? It will help if >>> you spell it out at the beginning. >> >> Yes. I thought I did it already: >> >> 1. Introduction >> >> ... and this memo describes managed objects common to both VPLS >> Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >> >> Thanks! >> Jeffrey >> >>> >>> ---------------------------------------------------------------------- >>> On 2016/04/16 21:47, Jeffrey (Zhaohui) Zhang wrote: >>>> Glenn, >>>> >>>> Thanks for your comments. I've addressed most of your comments in the >>> new revision: >>>> >>>> URL: https://www.ietf.org/internet-drafts/draft-ietf-bess- >>> l2l3-vpn-mcast-mib-03.txt >>>> Status: https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3- >>> vpn-mcast-mib/ >>>> Htmlized: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn- >>> mcast-mib-03 >>>> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3- >>> vpn-mcast-mib-03 >>>> >>>> Please see below. >>>> >>>>> 1. Abstract: >>>>> 1.1 A sentence on how the managed objects will be used by >>>>> applications for operations, monitoring and management >>>>> would be good. >>>> >>>> I had thought this would be standard/obvious for all MIB objects - the >>> read-write ones are used to control how a device works, and the >>> read-only >>> ones are used for monitoring. Do I really need to say it explicitly? >>>> >>>> I see RFC 4382 has the following: >>>> >>>> This memo defines a portion of the Management Information Base (MIB) >>>> for use with network management protocols in the Internet community. >>>> In particular, it describes managed objects to configure and/or >>>> monitor Multiprotocol Label Switching Layer-3 Virtual Private >>>> Networks on a Multiprotocol Label Switching (MPLS) Label Switching >>>> Router (LSR) supporting this feature. >>>> >>>> Is it enough to say something similar? For example: >>>> >>>> In particular, it describes common managed objects used to >>> configure >>>> and/or monitor both L2 and L3 VPN Multicast. >>>> >>>>> >>>>> 2. Introduction >>>>> 2.1 Please give the full expansion of the abbreviations >>>>> appearing for the first time. (PE, VPLS,..) >>>> >>>> Fixed. >>>> >>>>> >>>>> 2.2 The terminology section is a bit terse. Explaining the >>>>> terms that are used, nicely with reference to the protocol >>>>> documents will improve readability. >>>>> e.g. >>>>> - PMSI, I-PMSI, S-PMSI, provider tunnels >>>> >>>> As the paragraph alluded to, this MIB needs to be understood in the >>> general context of L2/L3 multicast VPN and providing good explanation of >>> the terms is not attempted. The references for the terms are the the >>> RFCs >>> for the relevant technologies. >>>> >>>> Having said that, I'll explain PMSI a bit further. >>>> >>>>> 2.3 Is there a difference between >>>>> "multicast in Layer 2 and Layer 3 VPNs , defined by >>>>> RFC 7117 and RFC 6513/6514" >>>>> used in the DESCRIPTION in the MODULE-IDENTITY >>>>> and >>>>> "multicast in BGP/MPLS L2 or IP VPN" >>>>> used in the DESCRIPTION of L2L3VpnMcastProviderTunnelType ? >>>>> If these are the same, it will be helpful to stick to the >>>>> same expression. If these are not the same, the dictinction >>>>> should be clarified. >>>> >>>> No difference. I was using "Layer 3" or "L3" but it was pointed out >>>> that >>> the layer 3 VPN is often referred to IP VPN in other RFCs and I was >>> advised to change it accordingly. Looks like I did not change all the >>> cases. >>>> >>>> On the other hand, I noticed that RFC 4382 does use "Layer 3 VPN" so >>> I'll change it back. >>>> >>>>> >>>>> >>>>> 3. Summary of MIB Module. >>>>> An overview of the L2L3-VPN-MCAST-MIB will be good- the >>>>> structure of the MIB, short descriptions of the table(s) >>>>> including usage of the table(s) for management and/or by >>>>> other MIB(s). >>>> >>>> I had that, but have added one sentence about the only table. >>>> >>>>> >>>>> MIB definitions: >>>>> 4. MIB syntax checking: >>>>> smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB 2>L2L3-VPN-MCAST-MIB.txt >>>> >>>> I used simpleweb's validation tool but looks like I did not use the >>> strictest level of validation. I've now fixed the following issues and >>> verified. >>>> >>>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:63: [4] {hyphen-in-label} warning: named >>> number `rsvp-p2mp' must not include a hyphen in SMIv2 >>>>> mibs/L2L3-VPN-MCAST-MIB:64: [4] {hyphen-in-label} warning: named >>> number `ldp-p2mp' must not include a hyphen in SMIv2 >>>>> mibs/L2L3-VPN-MCAST-MIB:65: [4] {hyphen-in-label} warning: named >>> number `pim-asm' must not include a hyphen in SMIv2 >>>>> mibs/L2L3-VPN-MCAST-MIB:66: [4] {hyphen-in-label} warning: named >>> number `pim-ssm' must not include a hyphen in SMIv2 >>>>> mibs/L2L3-VPN-MCAST-MIB:67: [4] {hyphen-in-label} warning: named >>> number `pim-bidir' must not include a hyphen in SMIv2 >>>>> mibs/L2L3-VPN-MCAST-MIB:68: [4] {hyphen-in-label} warning: named >>> number `ingress-replication' must not include a hyphen in SMIv2 >>>>> mibs/L2L3-VPN-MCAST-MIB:69: [4] {hyphen-in-label} warning: named >>> number `ldp-mp2mp' must not include a hyphen in SMIv2 >>>> >>>> See later question/comments below. >>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:215: [5] {group-unref} warning: current >>> group `l2L3VpnMcastOptionalGroup' is not referenced in this module >>>>> mibs/L2L3-VPN-MCAST-MIB:4: [5] {import-unused} warning: identifier >>> `NOTIFICATION-TYPE' imported from module `SNMPv2-SMI' is never used >>>>> mibs/L2L3-VPN-MCAST-MIB:5: [5] {import-unused} warning: identifier >>> `Unsigned32' imported from module `SNMPv2-SMI' is never used >>>>> mibs/L2L3-VPN-MCAST-MIB:8: [5] {import-unused} warning: identifier >>> `NOTIFICATION-GROUP' imported from module `SNMPv2-CONF' is never used >>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: identifier >>> `TruthValue' imported from module `SNMPv2-TC' is never used >>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: identifier >>> `RowStatus' imported from module `SNMPv2-TC' is never used >>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: identifier >>> `TimeStamp' imported from module `SNMPv2-TC' is never used >>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: identifier >>> `TimeInterval' imported from module `SNMPv2-TC' is never used >>>>> mibs/L2L3-VPN-MCAST-MIB:15: [5] {import-unused} warning: identifier >>> `SnmpAdminString' imported from module `SNMP-FRAMEWORK-MIB' is never >>> used >>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: identifier >>> `InetAddress' imported from module `INET-ADDRESS-MIB' is never used >>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: identifier >>> `InetAddressType' imported from module `INET-ADDRESS-MIB' is never used >>>> >>>> Removed the above unused imports. >>>> >>>>> >>>>> 5. REFERENCE clauses: Please use REFERENCE clauses liberally. >>>>> Wherever possible, provide references for objects used in >>>>> the MIB. The references will point to specific sections/ >>>>> sub-sections of the RFCs defining the protocol for which the >>>>> MIB is being designed. It will greatly improve the readability >>>>> of the document. >>>> >>>> Added. >>>> >>>>> >>>>> 6. IMPORTS clause >>>>> MIB modules from which items are imported must be cited and >>>>> included in the normative references. >>>>> The conventional style is >>>>> mplsStdMIB >>>>> FROM MPLS-TC-STD-MIB -- [RFC3811] >>>> >>>> Added. >>>> >>>>> >>>>> 7. Please update the MODULE-IDENTITY. (There are no syntantic errors.) >>>>> 7.1 CONTACT-INFO >>>>> Following the conventions (including indentation style) will >>>>> improve the readability. (e.g. RFC4382, RFC5132). >>>>> Will be good if it does not overflow into the next page. >>>> >>>> Fixed. >>>> >>>>> >>>>> 7.2 REVISION clause: follow the convention recommended in RFC4181 >>>>> sec 4.5 >>>>> REVISION "200212132358Z" -- December 13, 2002 >>>>> DESCRIPTION "Initial version, published as RFC yyyy." >>>>> -- RFC Ed.: replace yyyy with actual RFC number & remove this note: >>>> >>>> Fixed. >>>> >>>>> 7.3 OID assignment: follow the convention recommended in RFC4181 >>>>> sec 4.5 i >>>>> replace >>>>> ::= { experimental 99 } -- number to be assigned >>>>> by >>>>> ::= { <subtree> XXX } >>>>> -- RFC Ed.: replace XXX with IANA-assigned number & remove this >>>>> note >>>>> <subtree> will be the subtree under which the module will be >>>>> registered. >>>>> >>>> >>>> I kept "experimental 99" so that I could continue to use mib tools to >>> validate; but I added notes for the editor to replace them as you >>> indicated. >>>> >>>>> >>>>> 8. Specific MO and TC related comments. >>>>> L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION >>>>> STATUS current >>>>> DESCRIPTION >>>>> "Types of provider tunnels used for multicast in >>>>> BGP/MPLS L2 or IP VPN." >>>>> SYNTAX INTEGER { unconfigured (0), >>>>> rsvp-p2mp (1), >>>>> ldp-p2mp (2), >>>>> pim-asm (3), >>>>> pim-ssm (4), >>>>> pim-bidir (5), >>>>> ingress-replication (6), >>>>> ldp-mp2mp (7) >>>>> >>>>> o Would be nice to align the enumeration labels with the >>>>> labels in the protocol document RFC 6514 unless there is >>>>> a good reason for not doing so. (You will have to take >>>>> care of the smi compilation errors too; '-' is not allowed ). >>>> >>>> Are spaces allowed? I don't know so I used hyphen. For now I replace >>> with things like rsvpP2mp. >>>> Or could/should I just remove the definitions, so that if a new type is >>> defined in the future there is no need to update the MIB? >>>> >>>>> >>>>> 8.1 l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>>>> SYNTAX L2L3VpnMcastPmsiTunnelAttributeEntry >>>>> MAX-ACCESS not-accessible >>>>> STATUS current >>>>> DESCRIPTION >>>>> "An entry in this table corresponds to an PMSI attribute >>>>> that is advertised/received on this router. >>>>> For BGP-based signaling (for I-PMSI via auto-discovery >>>>> procedure, or for S-PMSI via S-PMSI A-D routes), >>>>> they are just as signaled by BGP (RFC 6514 section 5, >>>>> 'PMSI Tunnel attribute'). >>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>> they're derived from S-PMSI Join Message >>>>> (RFC 6513 section 7.4.2, 'UDP-based Protocol').. >>>>> >>>>> Note that BGP-based signaling may be used for >>>>> PIM-MVPN as well." >>>>> o Fix the ".." in "'UDP-based Protocol').." above. >>>>> o Please give the reference for this Table. >>>>> Is it- "PMSI Tunnel attribute" in RFC 6513 Sec.4 ? >>>>> "PMSI Tunnel attribute" in RFC 6514 Sec.5 ? >>>>> both? >>>>> Any other pointers? >>>> >>>> Fixed. >>>> >>>>> >>>>> 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>> SYNTAX OCTET STRING (SIZE (1)) >>>>> MAX-ACCESS not-accessible >>>>> STATUS current >>>>> DESCRIPTION >>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this is 0. >>>>> For BGP-based I/S-PMSI signaling, this is the Flags >>>>> field in PMSI Tunnel Attribute of the corresponding >>>>> I/S-PMSI A-D route." >>>>> ::= { l2L3VpnMcastPmsiTunnelAttributeEntry 1 } >>>>> o Please confirm that the above is a complete enumeration of the >>>>> types of signalling. >>>>> o RFC 6514 Sec.5 says that the Flags field indicates >>>>> "Leaf Information Required". That is useful information. >>>>> Please include in the description. >>>> >>>> The intent is to simply return the octet value of the flags field, w/o >>> listing individual bits like "Leaf Information Required". More bits >>> could >>> be defined in the future but the MIB would not change. >>>> >>>> Is that OK? >>>> >>>>> >>>>> 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>> SYNTAX OCTET STRING ( SIZE (0..37) ) >>>>> MAX-ACCESS not-accessible >>>>> STATUS current >>>>> DESCRIPTION >>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, the first >>>>> four or sixteen octets of this attribute are filled with >>>>> the provider tunnel group address (IPv4 or IPv6).. >>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel >>> Identifier >>>>> Field in PMSI Tunnel Attribute of the corresponding I/S- >>> PMSI >>>>> A-D route." >>>>> o Check the size specifications. The specs above say it can be >>>>> all sizes 0..37. That is not clear from the DESCRIPTION clause. >>>>> o Fix the ".." in "(IPv4 or IPv6).." above. >>>>> o RFC 6514 Sec 5. PMSI Tunnel Attribute gives the Tunnel >>> Identifiers >>>>> for mLDP, PIM-SM, PIM-SSM, BIDIR-PIM,Ingress Replication,MP2MP. >>>>> It appears that the sizes (range) for each case will be >>>>> different. >>>>> Please clarify that, and if there are discrete sizes, specify >>>>> accordingly. >>>> >>>> Depending on the tunnel type, there could be different sizes. Future >>> tunnel types could have other sizes that not specified today. I was >>> thinking to just give a size range so that it is flexible. Is that ok? >>>> >>>>> >>>>> >>>>> 8.3 l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>> SYNTAX RowPointer >>>>> MAX-ACCESS read-only >>>>> STATUS current >>>>> DESCRIPTION >>>>> "If the tunnel exists in some MIB table, this is the >>>>> row pointer to it." >>>>> o "some MIB table" : specify which MIB table. >>>> >>>> I can give an example, like mplsTunnelTable [RFC 3812]. It could be >>> whatever table that a tunnel may be put into. >>>> >>>>> o In what case will the tunnel exist and in what case will it not? >>>> >>>> If a device supports mplsTunnelTable and the tunnel is represented >>>> there, >>> then it exists. >>>> >>>>> o What will be the behaviour if the above condition is not >>> satisfied? >>>> >>>> A null pointer should be given. >>>> >>>>> >>>>> 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>> SYNTAX RowPointer >>>>> MAX-ACCESS read-only >>>>> STATUS current >>>>> DESCRIPTION >>>>> "If the tunnel has a corresponding interface, this is the >>>>> row pointer to the ifName table." >>>>> o DESCRIPTION looks incorrect. Please fix it. Do you want to say >>>>> this object points to the corresponding row in the ifTable? >>>> >>>> Yes. Fixed. >>>> >>>>> o In what case does the TunnelIf exist and in what case will it >>> not? >>>> >>>> Some tunnels may not have a corresponding interface. >>>> >>>>> o What will be expected if the tunnel does not have a >>> corresponding >>>>> interface? >>>> >>>> Null row pointer. >>>> >>>>> >>>>> 9. 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. >>>>> Please fix. >>>> >>>> I was really hoping that it would not have to be that tedious. SNMP/MIB >>> security should be no different from the CLI security - once you secure >>> the infrastructure then what's more to do? >>>> >>>> I'll need more time to work on this. Let me try to address the >>>> issues in >>> the other mib first and come back to this. >>>> >>>>> >>>>> >>>>> 10.ID-nits >>>>> 10.1 Checking nits according to >>>>> http://www.ietf.org/id-info/checklist : >>>>> >>>>> ------------------------------------------------------------------ >>> --------- >>>>> >>>>> ** There are 4 instances of too long lines in the document, the >>> longest one >>>>> being 3 characters in excess of 72. >>>> >>>> I fixed some but there still three too long lines: >>>> >>>> l2L3VpnMcastPmsiTunnelAttributeType >>>> L2L3VpnMcastProviderTunnelType, >>>> >>>> l2L3VpnMcastGroups OBJECT IDENTIFIER ::= >>>> {l2L3VpnMcastConformance >>> 1} >>>> l2L3VpnMcastCompliances OBJECT IDENTIFIER ::= >>>> {l2L3VpnMcastConformance >>> 2} >>>> >>>> Should I break them into different lines or just keep them as is? Any >>> example of expected indentation if I break the lines? >>>> >>>>> >>>>> 10.2 Checking references for intended status: Proposed Standard >>>>> >>>>> ------------------------------------------------------------------ >>> --------- >>>>> >>>>> == Missing Reference: 'RFC 7117' is mentioned on line 76, but not >>>>> defined >>>>> 'described in [RFC6513, RFC6514, RFC 7117] and other documents >>> tha...' >>>> >>>> I hope I understood and fixed it (removing the space in "RFC 7117"). >>>> >>>>> >>>>> 11. There is another WIP MVPN-MIB in draft-ietf-bess-mvpn-mib-02.txt >>>>> MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MIB. >>>>> Is there a good reason for not merging the 2 documents? I have >>>>> not >>> seen >>>>> any discussion or explanation on this. I may have missed it. >>> Please >>>>> clarify or, give some pointers. >>>> >>>> As mentioned in the introduction: >>>> >>>> this memo describes managed objects common to both VPLS >>>> Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>>> >>>> MVPN-MIB is for MVPN. There was another VPLS Multicast MIB in the work >>> and both would reference common objects defined in this MIB. >>>> >>>> Thanks! >>>> Jeffrey >>>> >>>>> -----Original Message----- >>>>> From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Glenn Mansfield >>>>> Keeni >>>>> Sent: Tuesday, April 12, 2016 2:28 AM >>>>> To: Benoit Claise <bclaise@cisco.com>; EXT - thomas.morin@orange.com >>>>> <thomas.morin@orange.com> >>>>> Cc: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; ops-ads@ietf.org; >>> Martin >>>>> Vigoureux <martin.vigoureux@nokia.com>; bess@ietf.org; Mach Chen >>>>> <mach.chen@huawei.com> >>>>> Subject: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib- >>> 02.txt >>>>> >>>>> Hi, >>>>> I have been asked to do a MIB Doctors review of >>>>> draft-ietf-bess-l2l3-vpn-mcast-mib-02.txt. >>>>> My knowledge of L2L3VPN Multicast is limited to the reading >>>>> of this document and browsing through the documents referred >>>>> to in the draft and bess-wg mailing list archives.( read "shallow"). >>>>> So some of the doubts and questions may sound trivial or >>>>> strange. Please bear with me and help me help you make >>>>> this into a better document :-) >>>>> >>>>> The comments are attached. >>>>> >>>>> Glenn >>>>> >>>> >>>> _______________________________________________ >>>> BESS mailing list >>>> BESS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/bess >>>> >> >> > > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors >
- 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