Re: [MIB-DOCTORS] Update to draft-ietf-bess-mvpn-mib-06

[Glenn Mansfield Keeni <[e-mail]>]

Hi Tsunoda,
    I have done a review of the MIB. The comments follow.
Glenn

draft: draft-ietf-bess-mvpn-mib-06.txt
        Only the MIB has been reviewed.

COMMENTS:

1. Naming: Please review.
         MO: mvpnBgpGenVrfRouteImport:
               if it is a condition for import name accordingly

2. Usage:  Please make the usages of the following uniform in the document
                       MVPN/mvpn/MVRF
                       tunnel type/Tunnel type
                       Source AS/source-as


3. Units:  The units for the following MOs are unspecified.
         Please check.
         MO: mvpnBgpGenCmcastRouteWithdrawalTimer
         MO: mvpnBgpGenSrcSharedTreeJoinTimer
         MO: mvpnBgpGenMsgRateLimit
         MO: mvpnBgpGenMaxSpmsiAdRoutes
         MO: mvpnBgpGenMaxSpmsiAdRouteFreq
         MO: mvpnBgpGenMaxSrcActiveAdRoutes
         MO: mvpnBgpGenMaxSrcActiveAdRouteFreq
4. Semantics:
         InetAddress and INetAddressType objects
             for several MOs, usage of InetAddressType unknown(0)
             is described. In all such cases the corresponding
             InetAddress MO value MUST be a string of length 0.
             Plese explain that case in the respective DESCRIPTIONs
             E.g. mvpnMrouteUpstreamNeighborAddr
                  mvpnMrouteNextHopSourceAddr
                  mvpnMrouteCmcastSourceAddr
                  mvpnMrouteSourceAddr

5. mvpnSpmsiAdvtCmcastSourceAddr OBJECT-TYPE
      SYNTAX        InetAddress
      ==> corresponding InetAddressType object
          mvpnSpmsiAdvtCmcastSourceAddrType is missing

6. Nits:
         MO:  mvpnMrouteCmcastSourceAddrType OBJECT-TYPE
              DESCRIPTION
                  "A value indicating the address family of the address
                   contained in mvpnMrouteSourceAddr.
              s/mvpnMrouteSourceAddr/mvpnMrouteCmcastSourceAddr/

7. Table descriptions:
      mvpnIpmsiAdvtTable
      mvpnSpmsiAdvtTable
         The DESCRIPTIONs are unclear.
             Do the tables 'contain' all advertisements or,
             Statistics related to the advertisements?


8. Additional suggestions:
    o For INDEX clauses of variable size where the size may potentially
      exceed 128 octets, a statement like the following will be good.
             Implementors need to be aware that if the total number of
             octets in MO1, MO2 and MO3 exceeds NNN, then OIDs of column
             instances in this row will have more than 128 sub-identifiers
             and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3.

    o In REFERENCES be more specific if possible. Eg.
        Current:
            mvpnPmsiTunnelIfIndex OBJECT-TYPE
               REFERENCE
                   "RFC2863
        Suggested:
            mvpnPmsiTunnelIfIndex OBJECT-TYPE
               REFERENCE
                   "RFC2863 Sec. 3.1.5



On 2018/05/02 6:59, Glenn Mansfield Keeni wrote:
> Hi Tsunoda,
>     Thanks for the good work.
> I will start reviewing this right away.
> 
> Glenn
> 
> On 2018/05/01 12:14, Hiroshi Tsunoda wrote:
>> Dear Glenn,
>>
>> Thank you for waiting the update.
>> I have submitted the updated version of
>> draft-ietf-bess-mvpn-mib.
>>
>> Links to the draft and diff are as follows.
>>
>> URL:
>> https://www.ietf.org/internet-drafts/draft-ietf-bess-mvpn-mib-06.txt
>> Htmlized:       https://tools.ietf.org/html/draft-ietf-bess-mvpn-mib-06
>> Htmlized:       
>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-mib
>> Diff:           
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-mib-0
>>
>> This version contains some major changes as follows.
>> I hope this update make the role and usage of the MIB clear for you.
>>
>> +----------------------------------------------------------+
>> Changes:
>>
>> 1. Support for row creation in all tables is removed
>>
>>     Reason: The utility of row creation is dubious.
>>     It increases complexity of the MIB implementation.
>>     Unless an immediate need for row creation, we will go ahead
>>     with the current draft and review the need for row creation
>>     at a later date if and when it arises.
>>
>> 2. Added objects to make the role and usage of this MIB clear.
>>
>>     Reason: This MIB will provide the following management functions.
>>
>>     - Configuration of MVRF related timers
>>
>>     - Generation of Notifications to indicate  creation, deletion,
>>       and/or modification of MVRFs
>>
>>     - Generation of Notification  when a member joins or leaves a
>>       multicast group
>>
>>     - Monitoring of the following
>>       - attributes of MVRFs of MVPNs
>>       - PMSIs
>>       - statistics of advertisements exchanged by a PE
>>       - routing entries in a MVRF
>>       - next-hops for a multicast destination in a MVRF
>> +----------------------------------------------------------+
>>
>> -- tsuno
>>
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mib-doctors