Hi Glenn, Thanks a lot for your review. I am going to revise the MIB part along with your comments and get back to you hopefully soon.
-- tsuno 2018-05-13 18:56 GMT+09:00 Glenn Mansfield Keeni <[email protected]>: > 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/mib-doctors > > _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
