Hi Jeffery,
Some responses inline...
Snipped.
> >
> > 5. mvpnMvrfNumber OBJECT-TYPE
> > SYNTAX Unsigned32
> > MAX-ACCESS read-only
> > STATUS current
> > DESCRIPTION
> > "The total number of MVRFs for IPv4 or IPv6 or mLDP
> > C-Multicast that are present in this device."
> >
> > Should the "or" be changed to "and"?
>
> Zzh> It's for any of those types. Someone said we should use "or". I am open
> to
> suggestions.
If the mvpnMvrfNumber is designed to be the number of each type of the VRFs,
then "or" should be used and it's better to add some clarification text here.
Otherwise, "and" should be used. When I read the mib, it gives my feeling that
mvpnMvrfNumber is the number of all MVRFs.
> > 8.
> > Page 13:
> > mvpnBgpGenVrfRtImport OBJECT-TYPE
> > SYNTAX MplsL3VpnRouteDistinguisher
> > MAX-ACCESS read-write
> > STATUS current
> > DESCRIPTION
> > "The VRF Route Import Extended Community that this device
> > adds to unicast vpn routes that it advertises for this mvpn."
> > ::= { mvpnBgpGeneralEntry 2}
> >
> > mvpnBgpGenSrcAs OBJECT-TYPE
> > SYNTAX Unsigned32
> > MAX-ACCESS read-only
> > STATUS current
> > DESCRIPTION
> > "The Source AS number in Source AS Extended Community that
> this
> > device adds to the unicast vpn routes that it advertises for
> > this mvpn."
> >
> > Why should the "Source", "Extended", and "Community" be upper case? If
> > there is no special intention, suggest to change to lower case. You
> > may need to look through the whole document to do a text clean up.
>
> Zzh> That's per RFC 6513.
If that's the case, I'm fine with it.
>
> >
> > 9.
> > Section 3, Security consideration.
> >
> > Given that the document introduces some read-write objects, I don't
> > think that the current statement of "This document does not introduce
> > new security risks." will pass the IESG review. I'd suggest the
> > authors to enhance the security consideration section. For the mib
> > security consideration, you may refer to some existing mid documents
> > (e.g,
> > https://tools.ietf.org/html/draft-ietf-mpls-tp-oam-id-mib-11) that
> > have already passed the IESG review. Also, you may refer to some
> > history discussions on a mib security consideration (e.g.,
> > https://datatracker.ietf.org/doc/draft-ietf-trill-oam-mib/history/ ).
>
> Zzh> This seems to be no different from CLI configuration/monitoring? But I
> will
> study those past discussions.
Please do so and update the security consideration section.
>
> >
> > 10.Please make sure that the MIB Modules are compiled cleanly.
>
> Zzh> I did use http://www.simpleweb.org/ietf/mibs/validate/. Did you notice
> any problem?
I did not run any validation, if you did, that's great.
Once you update the document, we can start the MIB doctor review.
Best regards,
Mach
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
