Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt

[Hiroshi Tsunoda <[e-mail]>]

Hi,

I discussed with Jeffrey on the MIB documents during IETF97
and I have volunteered to finalize those.

I will work on draft-ietf-bess-l2l3-vpn-mcast-mib
and prepare updated version (-05) as a response to MIB doctor's
review. This will happen before the end of the month. I will
take some time to get familiar with related documents,

Sincerely yours,

-- 
Hiroshi TSUNODA,
Tohoku Institute of Technology, Sendai, Japan
E-mail: [e-mail]
E-mail: [e-mail]

2016-10-04 3:42 GMT+09:00 Jeffrey (Zhaohui) Zhang <[e-mail]>:
> Gelnn, Benoit,
>
> Sorry for the late action and response after the initial round of review and revision - I have been side tracked by many other things.
>
> I will try to get this done within next two weeks.
>
> Thanks.
> Jeffrey
>
>> -----Original Message-----
>> From: Benoit Claise [mailto:[e-mail]]
>> Sent: Monday, October 03, 2016 12:42 PM
>> To: Glenn Mansfield Keeni; Jeffrey (Zhaohui) Zhang; EXT -
>> [e-mail]
>> Cc: [e-mail]; [e-mail]; Mach Chen; Martin Vigoureux;
>> [e-mail]; [e-mail]
>> Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-
>> 04.txt
>>
>> Authors,
>>
>> Can you please finalize this draft.
>> Glenn provided the first MIB doctor review in April!
>>
>> Regards, Benoit
>> > Hi,
>> >   Any update on the MIB drafts?
>> > Glenn
>> >
>> > On 2016/07/17 23:44, Glenn Mansfield Keeni wrote:
>> >> 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:[e-mail]]
>> >>>>> Sent: Sunday, May 08, 2016 11:02 AM
>> >>>>> To: Jeffrey (Zhaohui) Zhang <[e-mail]>; Benoit Claise
>> >>>>> <[e-mail]>; EXT - [e-mail]
>> >>>>> <[e-mail]>
>> >>>>> Cc: Mach Chen <[e-mail]>; [e-mail]; Martin
>> >>>>> Vigoureux
>> >>>>> <[e-mail]>; [e-mail]; [e-mail]
>> >>>>> 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:[e-mail]] On Behalf Of Glenn
>> >>>>>>> Mansfield
>> >>>>>>> Keeni
>> >>>>>>> Sent: Tuesday, April 12, 2016 2:28 AM
>> >>>>>>> To: Benoit Claise <[e-mail]>; EXT -
>> >>>>>>> [e-mail]
>> >>>>>>> <[e-mail]>
>> >>>>>>> Cc: Jeffrey (Zhaohui) Zhang <[e-mail]>; [e-mail];
>> >>>>> Martin
>> >>>>>>> Vigoureux <[e-mail]>; [e-mail]; Mach Chen
>> >>>>>>> <[e-mail]>
>> >>>>>>> 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
>> >>>>>> [e-mail]
>> >>>>>> https://www.ietf.org/mailman/listinfo/bess
>> >>>>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> MIB-DOCTORS mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/mib-doctors
>> >>>
>> >>
>> >> _______________________________________________
>> >> MIB-DOCTORS mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/mib-doctors
>> >
>> > .
>> >
>
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess