Subject: I-D ACTION:draft-ietf-isis-wg-mib-00.txt

From: [email-masked]
Date: Thu, 04 Mar 1999 20:40:49 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IS-IS for IP Internets Working Group of the IETF.

	Title		: Management Information Base for IS-IS
	Author(s)	: J. Parker
	Filename	: draft-ietf-isis-wg-mib-00.txt
	Pages		: 71
	Date		: 03-Mar-99
	
     This document describes a management information base for the
     IS-IS Routing protocol,  as described in RFC 1142 [2], when it
     is used to construct routing tables for IP networks, as
     described in RFC 1195 [3].
 
     This memo defines an experimental portion of the Management
     Information Base (MIB) for use with network management
     protocols in the Internet community.
 
     This memo is based on a    draft revision of an IETF MIB dated
     March of 1994 and titled 'Integrated IS-IS Management
     Information Base'.  This version has been modified to include
     MIB-II syntax, to exclude portions of the protocol that    are
     not relevant to    IP, such as the ES-IS protocol, and to add
     management support for current practice.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-00.txt

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-isis-wg-mib-00.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-isis-wg-mib-00.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: Jeff Parker <[email-masked]>
Date: Thu, 18 Mar 1999 15:55:35 -0500

Rajesh -
	Thanks for the careful review.
	You raise a good point: it would be best not
to administer things that we don't specify.  However,
we are in an unusual situation: we don't control the
specification, and yet we want to interact with existing 
practice.  
	I'd like to try to flesh out the text on these an
similiar additions, and move them to an optional section.
It would be best to get the text from the implementors.  
If there is consensus that, even with text, an item is out
of scope, then we should remove the field.
	I think the idea of a document describing 
current practice that differs from the spec would be
useful.  I'll send you some items that caught my eye.

- jparker
- nexabit.com

> -----Original Message-----
> From:	Rajesh Balay [SMTP:[email-masked]]
> Sent:	Monday, March 15, 1999 1:14 PM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	Re: I-D ACTION:draft-ietf-isis-wg-mib-00.txt
> 
> I am touching a topic which we had discussed before...
> 
> There are references in the draft to objects which are not part of the
> spec.;
> the issue is: should the MIB be the place where folks are going to
> discover
> these items, or should the scope of the MIB be limited to what is
> described
> in the spec.,  wg drafts, etc.
> 
> I have come across the following:
> 
> 1. isisSysLSPIgnoreErrors
> 
> Isn't this a proposed fix .... or is there any reason to operate
> routers which
> do not ignore lsp checksum errors i.e., given the choice.
> 
> 2. isisCircLspInterval, isisCircLSPTrottle
> 
> If they refer parameters specified in the spec, it would be better
> to use the parameter name instead. If these are something new,
> shouldn't
> we have a document explaining these.
> 
> 3. isisCircMeshGroupEnabled, isisCircMeshGroup
> 
> Again, a draft explaining this would help before we add this in to the
> MIB.
> 
> Leaving items as these in the MIB without having an agreed upon
> interpretation
> may lead to compatibility problems. From the discussion in december
> (notes from
> Tony P., Mike Shand, Jeff Parker), there seems to be a consensus on
> having
> more words of wisdom on such parameters which are outside of the
> spec.; 
> drafts on each of these or a "current practices" document detailing
> these items
> is someting which is required.....looks like nobody has stepped-up
> yet.
> 
> I could "compile/edit" such a document assuming the
> authors/vendors/users 
> of these features, etc., are willing to contribute.
> 
> regards,
> -rajesh