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

[Benoit Claise <[e-mail]>]

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