Subject: [Idr] FW: BGP MIB v1 Review

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 18 Mar 2004 10:07:23 -0500

-----Original Message-----
From: Chisholm, Sharon [CAR:0S00:EXCH] 
Sent: Wednesday, March 17, 2004 3:25 PM
To: 'Wijnen, Bert (Bert)'
Cc: 'Susan Hares'; 'Jeffrey Haas'
Subject: BGP MIB v1 Review

hi

I focused more of my energy into reviewing the delta from the previous
version as appose to the older content. I figured we should focus our
efforts on getting version 2 of the MIB correct.

Issues
------

1. Need to update copyright dates to 2004

2. In the description of bgpPeerIdentifier and bgpPeerNegotiatedVersion the
"should" should be "MUST". 

3. The second occurrences of 'should' in bgpPeerNegotiatedVersion is an
interesting case as the value was never restricted in the initial version of
the MIB, yet you are trying to define what a legal value is in the text.
Clarifying where the 'legal' definition is coming from might be helpful.

4. The description for bgp4PathAttrAtomicAggregate is worrisome, but I
suspect we are not actually changing the behaviour as drastically as it
sounds. I am assuming that the NLRI stuff does not have anything to do with
the MIB and this behaviour is described elsewhere. I would suggest rewording
it to say:

                    "This object indicates whether or not a system has 
                     selected a less specific route without
                     selecting a more specific route.

                     If the ATOMIC_AGGREGATE attribute is present
                     in the Path Attributes then this object
                     MUST have a  value of 'lessSpecificRouteNotSelected'.
                     If the ATOMIC_AGGREGATE attribute is missing
                     in the Path Attributes then this object MUST have
                     a value of 'lessSpecificRouteSelected'.

                     Note that ATOMIC_AGGREGATE has been
                     deprecated in the BGP specification."
Note we should also add a REFERENCE clause to the BGP specification.

5. In the definitions of the Notifications, we should replace "This object
deprecates <foo>" with "This Notification replaces the <foo> Notification."
On the other end, replace "This object has been deprecated in favor of
<foo>" with "This Notification has been replaced by the <foo> Notification.

6. There is a line "--- XXX TODO ..." within the reference section that
looks like it should be removed or replaced with an RFC editor instruction.

7. There are no references in the text to RFC1901, RFC2574, RFC2576,
RFC3411, RFC3413, RFC3415, RFC3416 or RFC3417 within the text. These need to
be removed. 

Non-gating Issues
----------

1. I'm assuming the fact that the behaviour of several counters has changed
has been discussed and is considered acceptable. I'm personally not sure it
is the right thing to do.

2. The text describing behaviour of bgpPeerHoldTimer and bgpPeerKeepAlive is
rather passive. This should definitely changed in version 2 or the MIB, but
is probable ok for this version. Example 

                    "If the value is
                     zero (0), the Hold Timer has either not been
                     established with the peer, or, the value of
                     bgpPeerHoldTimeConfigured is zero (0)." versus
			"  If the Hold Timer has not been established with 
                     the peer this object MUST have a value of (0).
                     If the bgpPeerHoldTimeConfigured has a value of
                     (0), then this object MUST have a value of (0)."

Sharon Chisholm
Portfolio Integration
Nortel Networks
Ottawa, Canada

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

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 18 Mar 2004 10:07:23 -0500

-----Original Message-----
From: Chisholm, Sharon [CAR:0S00:EXCH] 
Sent: Wednesday, March 17, 2004 3:25 PM
To: 'Wijnen, Bert (Bert)'
Cc: 'Susan Hares'; 'Jeffrey Haas'
Subject: BGP MIB v1 Review

hi

Issues
------

Non-gating Issues
----------

                    "If the value is

Sharon Chisholm
Portfolio Integration
Nortel Networks
Ottawa, Canada