[Isis-wg] Minor comments on draft-ietf-isis-wg-mib-13.txt

Jonathan Harrison <jon.harrison@dataconnection.com> Fri, 02 April 2004 21:48 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03834 for <isis-wg-archive@odin.ietf.org>; Fri, 2 Apr 2004 16:48:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9VKv-0005ze-L1 for isis-wg-archive@odin.ietf.org; Fri, 02 Apr 2004 15:32:21 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32KWLGS023032 for isis-wg-archive@odin.ietf.org; Fri, 2 Apr 2004 15:32:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9S5e-0006SQ-6l for isis-wg-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 12:04:22 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18655 for <isis-wg-web-archive@ietf.org>; Fri, 2 Apr 2004 12:04:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9S5c-0005ju-00 for isis-wg-web-archive@ietf.org; Fri, 02 Apr 2004 12:04:20 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9S4X-0005XF-00 for isis-wg-web-archive@ietf.org; Fri, 02 Apr 2004 12:03:14 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9S3V-0005Jf-00 for isis-wg-web-archive@ietf.org; Fri, 02 Apr 2004 12:02:09 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Q7P-0004mM-OC; Fri, 02 Apr 2004 09:58:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9LQq-0007VW-SL for isis-wg@optimus.ietf.org; Fri, 02 Apr 2004 04:57:48 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02082 for <isis-wg@ietf.org>; Fri, 2 Apr 2004 04:57:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9LQn-0004m2-00 for isis-wg@ietf.org; Fri, 02 Apr 2004 04:57:45 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9LQ1-0004gL-00 for isis-wg@ietf.org; Fri, 02 Apr 2004 04:56:58 -0500
Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1B9LPW-0004XJ-00 for isis-wg@ietf.org; Fri, 02 Apr 2004 04:56:26 -0500
Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2653.19) id <2A747P5G>; Fri, 2 Apr 2004 10:55:52 +0100
Message-ID: <37701240971DD31193970000F6CCB9F7050420AF@duke.datcon.co.uk>
From: Jonathan Harrison <jon.harrison@dataconnection.com>
To: 'Jeff Parker' <jparker@axiowave.com>, isis-wg@ietf.org
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Subject: [Isis-wg] Minor comments on draft-ietf-isis-wg-mib-13.txt
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/isis-wg/>
Date: Fri, 02 Apr 2004 10:55:43 +0100
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

Hi,

We've got a number of minor suggested clarifications and typo fixes to the
MIB, itemized below.  Hopefully, these won't be too controversial!

Please let me know what you think.

Thanks,
Jon
-------------------------------------------
Jon Harrison
Network Protocols Group
Data Connection Ltd
Tel:	+44 20 8366 1177                 
Fax:	+44 20 8363 1468
Email:	jrh@dataconnection.com    
Web:	http://www.dataconnection.com


SUGGESTED FIXES
===============

 - The MIB defines the type WideMetric for 24 bit values and the type
FullMetric for 32 bit values.  The syntax for FullMetric should be "SYNTAX
Unsigned32" rather than "SYNTAX Unsigned32 (0..16777215)".

 - The second sentence of the description of isisSysMaxAge should read "This
should be at least 300 seconds greater than isisSysMaxLSPGenInt."
 
 - isisSysInstance and isisSysLevelIndex are used in notifications, and so
the MIB compiler we use gives warnings because these objects have MAX-ACCESS
not-accessible.  Should these objects have MAX-ACCESS read-only (or
accessible-for-notify) instead?

 - Both isisCircPassiveCircuit and isisCircLevelCSNPInterval have an empty
REFERENCE "{}".  The reference for isisCircPassiveCircuit should be removed.
The reference for isisCircLevelCSNPInterval should be {ISIS.aoi
completeSNPInterval (8)}.

 - isisISAdjIndex - the description should read "This value is automatically
assigned by the system when the adjacency is created."

 - The references sometimes refer to level 1 objects, sometimes level 2
object (for example, l1DefaultMetric and l2DesignatedIntermediateSystem).
It would be more consistent to just refer to L1 objects, if possible.

 - The description for isisISAdjAreaAddrIndex should read "This provides a
simple way to walk the table."

 - The description of isisLSPSummaryEntry description has a typo - should be
"Each entry describes an LSP currently stored in the system."

 - In the LSP table description change "tupples" to "tuples".

 - To make the capitalization consistent, the description of isisLSPTLVType
should read "The type of this TLV".

 - The description of isisCircExtendedCircID could be clarified as follows
"The value to be used as the extended circuit ID in 3Way handshake.  This
value is only used if isisCirc3WayEnabled is true, and must be unique across
all circuits on this IS."

 - The description of the isisNotificationTable should read "Objects seen in
the most recent notification from this instance of the IS-IS protocol."

 - isisPduOriginatingBufferSize - The description should read "Holds the
size of isisSysOrigLSPBuffSize advertised by the peer in the
originatingLSPBufferSize TLV."

 - To make it (even more!) obvious that the minimum LSP generation interval
should be less than the maximum interval, modify the description of
isisSysMaxLSPGenInt as follows "The value must be greater than any value
configured for isisSysLevelMinLSPGenInt, and should be at least 300 seconds
less than isisSysMaxAge."  Similarly, add to the description of
isisSysLevelMinLSPGenInt "The value must be less than isisSysMaxLSPGenInt." 

 - isisSysTable description has a missing 's'.  Should be "The set of
instances of the Integrated IS-IS protocol existing on the system."

 - Add "This object follows the resettingTimer behavior." to the description
of the isisCircLevelCSNPInterval.

 - For consistency, isisISAdjIPAddressType and isisISAdjIPAddress should be
named isisISAdjIPAddrType and isisISAdjIPAddrAddress.

 - isisCircInitFails refers to "ISIS.aoi  initialisationFailures", which
counts specific adjacency initialization failures due to having no version
or area address in common.  The MIB should spell this out.  For example,
"The number of times initialization of an adjacency on this circuit has
failed due to the peer having either no version or no area address in common
with the local system."

 - Finally, isisCircLevelID.  I'd like to clarify whether this object is
only used for point to point circuits (as suggested by the reference to
ptPtCircuitID), or whether this field can be given a sensible value for a
LAN (since the CircuitID syntax doesn't give an option to return a zero
length OCTET STRING).

If the field does take a value on a LAN (with the disadvantage of making the
meaning of the field less clear), then the following text could be used.

"On a point to point circuit with a fully initialized adjacency to a peer
IS, the value of this object is the circuit ID negotiated during adjacency
initialization.  In all other cases, the value is the concatenation of the
local system ID and the one byte isisCircLevelIDOctet for this circuit.
This is the value that would be proposed for the circuit ID on a point to
point circuit, or for the LAN ID should this node be chosen as the LAN
Designated IS."

Or if the field is purely for use as the ptPtCircuitID, I suggest we change
the Circuit ID syntax to "OCTET STRING (SIZE(0|7))", and change the
description as follows:

"On a point to point circuit with a fully initialized adjacency to a peer
IS, the value of this object is the circuit ID negotiated during adjacency
initialization.  On a point to point circuit without such an adjacency, the
value is the concatenation of the local system ID and the one byte
isisCircLevelIDOctet for this circuit i.e. the value that would be proposed
for the circuit ID.

On other circuit types, the value returned is the zero length OCTET STRING."




_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg