Subject: [VRRP] feedback on the new vrrp MIB document

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 26 Aug 2003 15:14:53 +0200

The doc checked: draft-ietf-vrrp-ipv6-mib-00.txt

- There is a WG chairs web page (accessible from main IETF page)
  at: http://www.ietf.org/IESG/wgchairs.html
  - it has a ptr to ID-NITs (Internet-Draft Requirements)
    that have not been checked on this draft
  - It would be good to add a ptr to mib-review-guidelines
    I will take that as an action point
  - I believe there is a security guidelines too now...

- The ptr to the mib-guidelines has been communicated on the
  wgchairs mailing list (all chairs are on that list) several
  times over the last 6 months. It has also been posted
  to [email-masked] (a generic MIB maling list, I would
  recommend that MIB document editors/authors subscribe to
  it, majordom method). It is also vailable from
  the www.ops.ietf.org web pages, which also has ptrs to
  current MIB boilerplate and MIB security Guidelines.
  The current guidelines are in: 
     draft-ietf-ops-mib-review-guidelines-02.txt

- Anyways.... overall structure of the MIB is probably OK.
  After a quick scan I just wonder why this is IPv6 specific.
  Why not make the MIB such that it can deal with both IPv4 and
  IPv6... should not be too difficult I think, and it could
  obsolete rfc2787. Maybe some objects need to be deprecated and
  new ones added to advance 2787 to support both IP versions.
  I'd need to check in detail if such is feasable or makes sense.
  Maybe people did evaluate that already... if so, they could
  explain it in the new draft/document. Maybe sect2 is trying to 
  say that... I need to check deeper to understand if it can be done
  or not.

- From ID-Nits and MIB review guidelines (examples):

  - they are using old (pre-2003) MIB boilerplate
    cuases references to obsolete RFCs
  - they are using pre-2003 MIB security Considerations section
    Also causes refs to obsolete docs.
  - Counter32 objects MUST state which timer object indicates
    discontinuity
  - Read-create tables MUSt specify what the persistency behaviour
    is (eithr in DESCRIPTION clause or by adding StorageType
    object
  - IPR section is missing
  - Missing REVISION clause in MIB Module
  - A MIB module must compile clean.  Here is what I get with smilint

C:\smi\mibs\ietf>smilint -m -s -l 6 -i namelength-32 ./VRRP-IPv6-MIB
./VRRP-IPv6-MIB:549: [2] {char-illegal-string} illegal character `?' (0xe6) in q
uoted string
./VRRP-IPv6-MIB:549: [2] {char-illegal-string} illegal character `?' (0xc6) in q
uoted string
./VRRP-IPv6-MIB:549: [2] {char-illegal-string} illegal character `?' (0xf6) in q
uoted string
./VRRP-IPv6-MIB:557: [1] {other} parse error, unexpected UPPERCASE_IDENTIFIER, e
xpecting COLON_COLON_EQUAL
./VRRP-IPv6-MIB:655: [1] {lexical} lexically unexpected character, skipping to e
nd of line
./VRRP-IPv6-MIB:656: [5] {} flushing recent incorrect declaration, see previous
error(s)
./VRRP-IPv6-MIB:90: [5] {index-element-accessible} index element `vrrpIpv6OperVr
Id' of row `vrrpIpv6OperEntry' should be not-accessible in SMIv2 MIB
./VRRP-IPv6-MIB:51: [4] {group-membership} node `vrrpIpv6NodeVersion' must be co
ntained in at least one conformance group
./VRRP-IPv6-MIB:61: [4] {group-membership} node `vrrpIpv6NotificationCntl' must
be contained in at least one conformance group
./VRRP-IPv6-MIB:136: [4] {group-membership} node `vrrpIpv6OperVrId' must be cont
ained in at least one conformance group
./VRRP-IPv6-MIB:145: [4] {group-membership} node `vrrpIpv6OperVirtualMacAddr' mu
st be contained in at least one conformance group
./VRRP-IPv6-MIB:156: [4] {group-membership} node `vrrpIpv6OperState' must be con
tained in at least one conformance group
./VRRP-IPv6-MIB:183: [4] {group-membership} node `vrrpIpv6OperAdminState' must b
e contained in at least one conformance group
./VRRP-IPv6-MIB:211: [4] {group-membership} node `vrrpIpv6OperPriority' must be
contained in at least one conformance group
./VRRP-IPv6-MIB:230: [4] {group-membership} node `vrrpIpv6OperIpAddrType' must b
e contained in at least one conformance group
./VRRP-IPv6-MIB:239: [4] {group-membership} node `vrrpIpv6OperMasterIpAddr' must
 be contained in at least one conformance group
./VRRP-IPv6-MIB:250: [4] {group-membership} node `vrrpIpv6OperAdvInterval' must
be contained in at least one conformance group
./VRRP-IPv6-MIB:262: [4] {group-membership} node `vrrpIpv6OperPreemptMode' must
be contained in at least one conformance group
./VRRP-IPv6-MIB:272: [4] {group-membership} node `vrrpIpv6OperVirtualRouterUpTim
e' must be contained in at least one conformance group
./VRRP-IPv6-MIB:283: [4] {group-membership} node `vrrpIpv6OperProtocol' must be
contained in at least one conformance group
./VRRP-IPv6-MIB:302: [4] {group-membership} node `vrrpIpv6OperRowStatus' must be
 contained in at least one conformance group
./VRRP-IPv6-MIB:335: [4] {group-membership} node `vrrpIpv6RouterChecksumErrors'
must be contained in at least one conformance group
./VRRP-IPv6-MIB:345: [4] {group-membership} node `vrrpIpv6RouterVersionErrors' m
ust be contained in at least one conformance group
./VRRP-IPv6-MIB:354: [4] {group-membership} node `vrrpIpv6RouterVrIdErrors' must
 be contained in at least one conformance group
./VRRP-IPv6-MIB:411: [4] {group-membership} node `vrrpIpv6StatsBecomeMaster' mus
t be contained in at least one conformance group
./VRRP-IPv6-MIB:420: [4] {group-membership} node `vrrpIpv6StatsAsMasterUpTime' m
ust be contained in at least one conformance group
./VRRP-IPv6-MIB:429: [4] {group-membership} node `vrrpIpv6StatsAdvRcvd' must be
contained in at least one conformance group
./VRRP-IPv6-MIB:438: [4] {group-membership} node `vrrpIpv6StatsAdvIntervalErrors
' must be contained in at least one conformance group
./VRRP-IPv6-MIB:449: [4] {group-membership} node `vrrpIpv6StatsHopLimitErrors' m
ust be contained in at least one conformance group
./VRRP-IPv6-MIB:459: [4] {group-membership} node `vrrpIpv6StatsPriZeroPktsRcvd'
must be contained in at least one conformance group
./VRRP-IPv6-MIB:468: [4] {group-membership} node `vrrpIpv6StatsPriZeroPktsSent'
must be contained in at least one conformance group
./VRRP-IPv6-MIB:477: [4] {group-membership} node `vrrpIpv6StatsInvalidTypePktsRc
vd' must be contained in at least one conformance group
./VRRP-IPv6-MIB:486: [4] {group-membership} node `vrrpIpv6StatsAddressListErrors
' must be contained in at least one conformance group
./VRRP-IPv6-MIB:497: [4] {group-membership} node `vrrpIpv6StatsPacketLengthError
s' must be contained in at least one conformance group
./VRRP-IPv6-MIB:512: [4] {group-membership} node `vrrpIpv6TrapNewMasterReason' m
ust be contained in at least one conformance group
./VRRP-IPv6-MIB:525: [4] {group-membership} node `vrrpIpv6TrapProtoErrReason' mu
st be contained in at least one conformance group
./VRRP-IPv6-MIB:11: [6] {import-unused} identifier `MODULE-COMPLIANCE' imported
from module `SNMPv2-CONF' is never used
./VRRP-IPv6-MIB:11: [6] {import-unused} identifier `OBJECT-GROUP' imported from
module `SNMPv2-CONF' is never used
./VRRP-IPv6-MIB:12: [6] {import-unused} identifier `NOTIFICATION-GROUP' imported
 from module `SNMPv2-CONF' is never used

  Here is what I get with SMICng

C:\bwijnen\smicng\work>smicmfm vrr6.mi2
E: f(vrr6.mi2), (655,45) EOF inside a string - check for unmatched quotes
E: f(vrr6.mi2), (659,1) Syntax error
** Unsuccessful parsing file "vrr6.mi2"
** 2 errors and 0 warnings in parsing

After I fix that unmatched double quote I get:
W: f(vrrp.mi2), (17,4) MODULE-IDENTITY vrrpIpv6MIB should have at least one REVI
SION clause
W: f(vrrp.mi2), (376,5) Sequence "VrrpRouterStatsEntry" and Row "vrrpIpv6RouterS
tatsEntry" should have related names
W: f(vrrp.mi2), (136,5) Item "vrrpIpv6OperVrId" is not contained in any group de
fined in the current module
W: f(vrrp.mi2), (637,5) OBJECT-GROUP "vrrpIpv6TrapGroup" is not used in a MODULE
-COMPLIANCE in current module
W: f(vrrp.mi2), (649,5) NOTIFICATION-GROUP "vrrpIpv6NotificationGroup" is not us
ed in a MODULE-COMPLIANCE in current module

So now I did spend a quick half an hour... while I think this is the
sort of things that WG members, doc authors/editors, WG chairs are
supposed to do.

Hope this gives you a flavor of things to check first, please

More on the split of IPv4 and IPv6 later
Thanks,
Bert 

_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: [email-masked]
Date: Tue, 26 Aug 2003 21:36:28 -0700

hi Bret,
	Thanks for taking time to review the ID. Glad to see 
	at least one other person reviewing it.

	- We realized the use of old boilerplates. So we
	will be replacing/correcting them in the next revision.
	(I could see a number of format errors too, some due to 
	the use of word and other due to first time editors..)

	- Surprisingly, I did compile the MIB with smilint.
	I will verify how I could have missed this.
	(I used the validator on simpleweb)

	- On the more important question of having a single MIB vs 
	MIB for IPv4 and IPv6, 
	Here are the snippets from my previous mails:

- Two MIB Reasoning:
-VRRP protocol is inherently IP version specific. Though the protocol
seems similar in certain aspects, VRRP for IPv6 is different from VRRP
for IPv4 and hence require two different MIBs.
- We already have a working VRRP IPv4 protocol and a corresponding MIB
definition that is being used by industry.
- It is not necessary to update the VRRP for IPv4 MIB (RFC 2787) 
to make it IPv6 address aware - according to RFC3291:
====
MIB modules which define management information that is 
specific to particular IP version (either IPv4 or IPv6)
and which is very unlikely to ever be applicable to 
another IP version do not need to be redefined.
====

One MIB arguments:
- With the removal of authentication in VRRP for IPv4, both the 
protocols are much closer than before (from configuration/management/statistics point of view)
- Major difference being "associated IP address" in VRRPv2. 
- With the changes specified in "draft-ietf-vrrp-spec-v2-09.txt"
we will require to define a new MIB for VRRPv2 any way.

- The present MIB tables are indexed on "interface Index" and "VRID". I can 
see a way to introduce "Version" into the index to identify if the row 
corresponds to VRRPv2 or VRRPv3 (and hence if it is IPv4 or IPv6). This 
could be messy but we can come up with a way to define one MIB.

- Putting on a network administrator hat, would you expect statistics 
(for example Invalid vrID packets received) in one table for both the protocols? 
Or 
one table with two entries - one for VRRPv2 and the other for VRRPv3? 
Or
Two separate tables each having statistics for one particular protocol version?

Please voice your opinion for and against having two different MIBs and the reason(s)
behind your opinion.

Based on your input, we will proceed with the changes to the existing draft.

-------- from another earlier mail ------
The bottom line question here is:

Do we envision having managed objects that are VRRP-IP version independent?
i.e., at the configuration/monitoring level user/administrator is looking at VRRP and not VRRP-IPv4 and VRRP-IPv6? 

Do we think that one definition of "invalidVRID" (as an example) 
is good enough to specify invalidVRIDs on both VRRP-IPv4 and VRRP-IPv6 
protocols in a mixed environment? If we *do not* need the granularity 
to define per protocol basis, then extending the existing definition 
to include VRRP-IPv6 is the way to go (and hence have one MIB).

I think that we will require the granularity of configuration objects
at protocol level (to debug misconfigurations for example), Which means
that we need to put in protocol version for all the common objects to 
distinguish between two protocols.

From the development point of view, I think VRRP-IPv6 will be implemented 
separate from the VRRP-IPv4 implementation, which means that it is easier to implement a separate new MIB than to change existing MIB implementation 
(well this is debatable - ..)

----

Please let me know your comments. 

Thaks.
-kalyan