Subject: WG LAST CALL draft-ietf-l3vpn-vr-mib-03

From: Ron Bonica <[email-masked]>
Date: Wed, 22 Jun 2005 17:16:58 -0400

Folks,

This message begins a working group last call on 
draft-ietf-l3vpn-vr-mib. The last call will end on
July 8.

                           Ron

-------- Original Message --------
Subject: I-D ACTION:draft-ietf-l3vpn-vr-mib-03.txt
Date: Wed, 22 Jun 2005 15:50:01 -0400
From: [email-masked]
To: [email-masked]
CC: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Layer 3 Virtual Private Networks 
Working Group of the IETF.

	Title		: Virtual Router Management Information Base Using SMIv2
	Author(s)	: E. Stelzer, et al.
	Filename	: draft-ietf-l3vpn-vr-mib-03.txt
	Pages		: 21
	Date		: 2005-6-22
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP based internets.
In particular, it defines objects for managing networks using Virtual
Routers (VR).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-vr-mib-03.txt

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 24 Jun 2005 16:30:49 +0100

Hi,

A few brief comments. Nothing very important.

I-D should indicate intended status.
Since you have suggested that the OID is "experimental" perhaps this I-D
is also Experimental?

Most mentions of "MIB" should read "MIB module"

Nice to indicate (in a comment and not using square brackets) the RFC
number of imports.
(e.g. see draft-ietf-ccamp-gmpls-te-mib-09.txt)

vrName Description clause has spare period and line break.

vrRpTrigger Description appears to repeat itself.

vrRpTrigger
"Bits 4-7 are reserved for future use."
I think the BITS syntax is not constrained to be exactly 8 bits. So you
don't need this sentence.

vrActiveVRs
"vrStatOperationalStatus" should read "vrOperStatus"

vrRpStatus
Shouldn't this have Syntax BITS and a back pointer to vrRpTrigger?
Better still would be to define a Textual Convention for them both to use.

vrRouterAddress
Are you sure that this cannot be configured per VR?

All Notifications return vrRowStatus. I would have expected vrOperStatus.
Seems, however, to be unnecessary as the status can be deduced from the
trap type.

vrUp and vrDown
The Description clauses should refer explicitly to vrOperStatus

vrMaxRoutesExceeded
Isn't there a danger of Notification storms with this Notification?
The definition of vrMaxRoutes is such that vrStatRouteEntries could never
exceed it. So when you reach vrMaxRoutes, each new attempt to add a route
will cause a new Notification.

You should probably reference as normative the RFCs from which you import
things.
That will include the new RFC4001.
Also VPN-TC-STD-MIB in draft-ietf-l3vpn-tc-mib. This is pretty important
as this I-D must not go to RFC before that one does.

Cheers,
Adrian