Virtual Private LAN Service (VPLS) Management Information Base
draft-ietf-l2vpn-vpls-mib-15

I have no objection to the publication of this document, but note a
few things that probably need to be fixed.

===

Section 1 says...

In particular, it defines a MIB module

...but there are three separate MIB modules in this document.

---

Section 4.

It would be helpful if you noted what the arrows in Figure A imply.

---

RFC 3411, RFC 2863, and RFC 3813 are all used as normative references in
Section 6.1, so you should move them to Section 9.1.

---

VPLS-GENERIC-MIB has

   vplsGenericDraft01MIB MODULE-IDENTITY

...which looks like a bit of broken cut and paste

and

several REVISION/DESCRIPTION clauses which I believe are only meant to
reflect revisions of the module published in RFCs. 

This applies to the other modules as well.

---

The REFERENCE clauses don't appear to be formed correctly. For example:

      REFERENCE
          "[RFC4364]"

I think that you are not supposed to use citations in the MIB modules
(because the module may be sucked out of the RFC and so appear without
the references), and I think the approved form for references:
- gives the RFC number
- names the RFC by title
- gives a section number where possible

Similarly, the DESCRIPTION clauses shouldn't use citations, but can 
simply use RFC numbers.

----

Surely VplsBgpRouteDistinguisher and VplsBgpRouteTarget should say how
the protocol things are encoded into the TCs even if only to say that 
the encoding matches what is used in BGP.

---

Probably a pathetic comment, but shouldn't you at least note that
vplsConfigFwdFullLowWatermark must be less than 
vplsConfigFwdFullHighWatermark.

I think that less-than-or-equal-to doesn't work, does it? And given 
that, isn't it the case that vplsConfigFwdFullHighWatermark should have
range 1..100, and vplsConfigFwdFullLowWatermark have range 0..99?

---

At http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security there are
guidelines about what to put in a MIB document's security section. I am
a little surprised that your MIB Doctor let you get away with what you
have here, but I'll leave it to the OPS and SEC ADs to worry about
whether anything needs to be done.

Thanks for addressing my DISCUSS

no objection on the assumption that the two comments present (benoit adrian) will be addressed.

Thanks Benoit for handling the security considerations
boilerplate issue. Feel free to ping me if some help
with getting that sorted is useful.