Subject: I-D ACTION:draft-ietf-idr-bgp4-mib-12.txt

From: [email-masked]
Date: Mon, 08 Sep 2003 06:52:48 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: Definitions of Managed Objects for the Fourth Version 
                          of Border Gateway Protocol (BGP-4)
	Author(s)	: J. Haas, S. Hares
	Filename	: draft-ietf-idr-bgp4-mib-12.txt
	Pages		: 35
	Date		: 2003-9-5
	
This memo is an extension to the SNMP MIB.  The origin of this memo
is from RFC 1269 'Definitions of Managed Objects for the Border
Gateway Protocol (Version 3)', which was updated to support BGP-4 in
RFC 1657.  This memo fixes errors introduced when the MIB was
converted to use the SNMPv2 SMI, as well as updates references to the
current SNMP framework documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-12.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp4-mib-12.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-mib-12.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 8 Sep 2003 12:11:57 -0700 (PDT)

Greetings,

I noticed the I-D announcement and would like to make a few MIB
doctor comments on this draft (but please note that this is the
result of a spot check ... I have NOT done a full MIB doctor review
of this document).

1.) My understanding from reading the draft and from previous e-mail
messages is that this document is supposed to obsolete RFCs 1657 and
1269.  If that understanding is correct, an explicit statement to
that effect, such as

   This memo obsoletes RFC 1657 and RFC 1269.

must be added both to the Abstract and to the Introduction.

2.) I also understand from reading the draft and from previous
e-mail messages that the main purpose of this document is to provide
a clean MIB module that documents the behaviour of deployed
implementations, and that a new MIB module to overcome numerous
shortcomings is under development and will in due course be
submitted for standards-track consideration.  Under the
circumstances it may be appropriate to submit this document as an
Informational RFC rather than for the standards track, as indicated
in the WG last call:  if a replacement is under development, there
is no reason to progress this document along the standards track,
and submitting it for Proposed Standard implies such an intent.

3.) In reviewing the smidiff report between the MIB module in this
draft and the one in RFC 1657 I noticed a couple of questionable
things:

(a) There are no REVISION/DESCRIPTION pairs for the previous
incarnations of the MIB module.  This gives rise to the following
error message:

RFC1657-MIB.my:25 [3] {revision-removed} revision `1994-05-05 00:00'
removed

This can be easily fixed by the following change to the MIB module
at the end of the REVISION/DESCRIPTION pair now present:

OLD:
                          bgpPeerInTotalMessages, bgpPeerOutTotalMessages"

NEW:
                          bgpPeerInTotalMessages, bgpPeerOutTotalMessages.

                      Published as RFC yyyy."
-- RFC Ed.: replace yyyy with actual RFC number & remove this note

            REVISION "199405050000Z"
            DESCRIPTION
                    "Translated to SMIv2 and published as RFC 1657."

            REVISION "199110261839Z"
            DESCRIPTION
                    "Initial version, published as RFC 1269."

Note that "199405050000Z is copied from the LAST-UPDATED clause in
the MIB module in RFC 1657, which is standard practice.  Since that
MIB module did not contain a REVISION/DESCRIPTION pair for the RFC
1269 version, and since RFC 1269 was an SMIv1 module and so has no
LAST-UPDATED or REVISION clause, the date "199110261839Z" is
synthesized from the UTC time stamp Oct 26 18:39:09 1991 on
http://www.rfc-editor.org/rfc/rfc1269.txt

In my opinion, this is a "must-do" change.

(b) The smidiff report indicates that several objects that RFC 1657
declared as 'obsolete' have been promoted to a status of
'deprecated', in violation of SMIv2 revision rules:

BGP4-MIB.my:480 [2] {status-change} status change from `obsolete' to
`deprecated' for `bgpRcvdPathAttrTable'
BGP4-MIB.my:491 [2] {status-change} status change from `obsolete' to
`deprecated' for `bgpPathAttrEntry'
BGP4-MIB.my:516 [2] {status-change} status change from `obsolete' to
`deprecated' for `bgpPathAttrPeer'
BGP4-MIB.my:525 [2] {status-change} status change from `obsolete' to
`deprecated' for `bgpPathAttrDestNetwork'
BGP4-MIB.my:532 [2] {status-change} status change from `obsolete' to
`deprecated' for `bgpPathAttrOrigin'
BGP4-MIB.my:547 [2] {status-change} status change from `obsolete' to
`deprecated' for `bgpPathAttrASPath'
BGP4-MIB.my:563 [2] {status-change} status change from `obsolete' to
`deprecated' for `bgpPathAttrNextHop'
BGP4-MIB.my:572 [2] {status-change} status change from `obsolete' to
`deprecated' for `bgpPathAttrInterASMetric'
BGP4-MIB.my:803 [2] {status-change} status change from `deprecated'
to `current' for `bgpEstablished'
BGP4-MIB.my:812 [2] {status-change} status change from `deprecated'
to `current' for `bgpBackwardTransition'

Unless the WG had a specific reason for making this change, I would
be inclined to recommend that the status of these definitions be
changed back to 'obsolete'.

4.) In the DESCRIPTION clause of bgp4MIBNotificationGroup there is
a typo.  Here is the fix:

OLD:
                 Obsoletes bgp4MIBNotificationGroup."
NEW:
                 Obsoletes bgp4MIBTrapGroup."

In my opinion, this is also another "must-do" change.

Regards,

Mike Heard

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

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 8 Sep 2003 12:11:57 -0700 (PDT)

Greetings,

OLD:

NEW:

                      Published as RFC yyyy."

            REVISION "199405050000Z"
            DESCRIPTION

            REVISION "199110261839Z"
            DESCRIPTION

OLD:

Regards,

Mike Heard

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 10 Sep 2003 09:04:13 -0400

On Wed, Sep 10, 2003 at 09:14:46AM +0200, Wijnen, Bert (Bert) wrote:
> Thanks for the (partial) review Mike.
> I am sure it will be helpfull... I have not read it in detail
> yet... hope to do so later this week.
> 
> I assume author and WG will respond with fixes and or 
> answers.

I accept all of the suggested changes unless there is further feedback
from the WG.  Meanwhile, I'll hold off issuing another version of
the draft pending your review.

-- 
Jeff Haas 
NextHop Technologies

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 10 Sep 2003 08:32:24 -0700 (PDT)

[ list address changed to <[email-masked]>. plz update charter page. ]

> changed back to 'obsolete'.

- First, the status-change messages for bgpEstablished and
bgpBackwardTransition are wrong (the change was from current
to deprecated) and should be ignored.  I will file a bug report
with the smidiff maintainers.

- Second, the group bgp4MIBRcvdPathAttrGroup, which contains all of
the accessible columns in the bgpRcvdPathAttrTable, has a status of
'deprecated'.  That is legal, even though the contained objects
themselves have a status of 'obsolete', but the WG may prefer for
bgp4MIBRcvdPathAttrGroup have a status of 'obsolete'.  If its status
is changed be sure to update the DESCRIPTION clause to match.

Thanks,

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 10 Sep 2003 08:32:24 -0700 (PDT)

Thanks,

Mike Heard