MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base
RFC 4382

Note: This ballot was opened for revision 07 and is now closed.

(Mark Townsley) Yes

Comment (2005-05-06)
No email
send info
The IANA Considerations section will be updated based on the IANA review as follows:

18.  IANA Considerations

As described in MPLS-TC-STD-MIB [RFC3811], MPLS related standards track MIB modules should be rooted under the mplsStdMIB subtree. There is one MPLS-related MIB module contained in this document. The following "IANA Considerations" subsect requests IANA for a new assignment under the mplsStdMIB subtree.  New assignments can only be made via a Standards Action as specified in [RFC2434].

(Brian Carpenter) No Objection

(Margaret Cullen) (was Discuss, No Objection, Discuss, No Objection, Discuss, No Objection, Discuss, No Objection) No Objection

Comment (2005-05-11)
No email
send info
I never actually had a discuss on this document.  I did have a question, but I figured it out for myself.  I must have pushed the discuss button at some  point, though, and now it wants to say that my discuss was cleared.

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Sam Hartman) No Objection

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

(David Kessens) No Objection

(Allison Mankin) No Objection

(Jon Peterson) No Objection

(Bert Wijnen) No Objection

Comment (2005-05-12)
No email
send info
As i reported during my latest MIB doctor review, the below
should have been considered as IETF Last Call comments, but
they have not been addressed. I think they can be fixed with
RFC-Editor note or during AUTH48.

> In document ... I see:
> 1. MIB OID assignment of:
>    ::= { mplsStdMIB 9999 } -- assigned by IANA, see section 
>                               18.1 for details
>    And Tom knows VERY well that he SHOULD NOT put 9999 in there, but
>    instead use xxxx or nnnn or some such.
> 2. The MODULE is named: MPLS-L3VPN-STD-MIB
>    And then in the one MODULE-COMPLIANCE he speaks of "L3 MPLS VPN MIB"
>    and in the 2nd MODULE-COMPLIANCE he speaks of "L3-MPLS-VPN-STD-MIB"
>    which is inconsistent and confusing.
>    Oh well... I don't have the time to go fishing for more of such.
these "inconsistencies in the text" do not break the MIB module.
but they make it difficult for readers to understand the document.
I have mentioned this many times before and am not planning to continue
to bring this up and instead leave it to WG and authors to do proper
review for such thing either in WG or during AUTH48.

(Alex Zinin) No Objection