RE: [Isis-wg] Re: TC name issues in draft-ietf-isis-wg-mib-22.txt

Bert -
    Those look like valid points.  I will do some wordsmithing and report back.
    I could address some of the points now, but perhaps it would be better to save my thoughts for an editing session, and see if I can make the text speak for itself
 
- jeff

	-----Original Message----- 
	From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] 
	Sent: Thu 9/1/2005 6:56 PM 
	To: Jeff Parker; C. M. Heard; Parker, Jeff 
	Cc: Christian Hopps; ISIS WG 
	Subject: RE: [Isis-wg] Re: TC name issues in draft-ietf-isis-wg-mib-22.txt
	
	

	Inline
	
	> -----Original Message-----
	> From: Jeff Parker [mailto:jparker@world.std.com]
	> Sent: Thursday, September 01, 2005 19:12
	> To: C. M. Heard; Jeff Parker
	> Cc: Wijnen, Bert (Bert); Christian Hopps; ISIS WG
	> Subject: Re: [Isis-wg] Re: TC name issues in
	> draft-ietf-isis-wg-mib-22.txt
	>
	>
	> Thanks for the comments.
	>
	> >>>>> - Is it wise to define Unsigned8TC and Unsigned16TC
	> >>>>>   with those generic names) in this MIB module?
	> >>>>>   I know there is already an Unsigned16TC in an IPSP PIB.
	>
	> Made these IsisXxx
	>
	Thanks
	
	> >>>>> - Is it wise to have a AdminState TC with that genetic
	> >>>>>   name in this MIB module? Specifically since it says
	> >>>>>   it is for "enabling or disabling a row"
	> 
	> Made this IsisAdminState
	> 
	Thanks
	
	> >>>>> - I see quite some text in comments in the MIB modules and
	> >>>>>   wonder if it would not be better to advise them to move
	> >>>>>   it into DESCRIPTION clauses as appropriate?
	> >>>>> 
	> >>>>> -  various DESCRIPTION clauses are pretty terse.
	> >>>>>
	> >>>>> I do not think any of the above is a showstopper,
	> >>>>> I just wonder if you had discussed that with the author(s)
	> >>>>> and/or WG at all. And I wonder what your opinion is on
	> >>>>> these sort of things.
	>
	> I understand that one man's terse is another man's prolix,
	> but I'm not sure
	> which modules are being discussed.  I skimmed through the
	> whole MIB and
	> didn't find that much relevant in comments outside the
	> DESCRIPTION clauses.
	>
	> I will be happy to move text around or wordsmith if there is
	> an obscure
	> clause, but I think the list already has been pretty frank
	> about objects
	> they found obscure.  I don't see a systemic problem and I
	> didn't spot any
	> problematic object.
	>
	> Bottom line: give me a reference and I will fix it.
	>
	
	OK, as I said in a previous email, the last thing is not anything
	to hold the doc hostage over. But if you want examples, here are a few:
	
	    IsisSystemID ::= TEXTUAL-CONVENTION
	        STATUS current
	        DESCRIPTION
	            "A system ID."
	        SYNTAX OCTET STRING (SIZE(6))
	
	I am sure that IS-IS people know what "A system ID" is.
	But all I can tell is that it is 6 octets. I have no idea
	how it is created/configured, what the format is... etc.
	I see no REFERENCE clause either, which might point me to
	the proper IS-IS document that describes the format and
	semantics of "A system ID".
	
	Now I see that when you use the TC in isisSysID that you
	add a lot of text there. And that is strange. The idea of a
	TC is that the semantics are described in the TC so that you
	do not have to repeat it umty times every time you use
	the same TC. Oh well.
	
	Same story for:
	
	
	    IsisLinkStatePDUID ::= TEXTUAL-CONVENTION
	        STATUS current
	        DESCRIPTION
	            "A Link State PDU Identifier."
	        SYNTAX OCTET STRING (SIZE(8))
	
	In fact I think many of your TCs could use a REFERENCE clause.
	
	Further, On page 12 I see:
	  -- Behavior Definitions
	
	  -- ResettingTimer behavior definition
	  -- "This object specifies the interval between certain events in
	
	So what is "This object" ??
	I see no other occurence of ResettingTimer
	So where does this belong?
	
	  -- the operation of the protocol state machine. If the value of
	  -- this object is set to a new value while the protocol state
	  -- machine is in operation, the implementation shall take the
	  -- necessary steps to ensure that for any time interval which
	  -- was in progress when the value of the corresponding object
	  -- was changed, the next expiration of that interval takes place
	  -- the specified time after the original start of that interval,
	  -- or immediately, whichever is later. The precision with which
	  -- this time shall be implemented shall be the same as that
	  -- associated with the basic operation of the timer object."
	
	  -- ReplaceOnlyWhileDisabled behavior definition
	  -- "This object may not be modified while the corresponding
	  -- table row's variable of type AdminState is in state on."
	
	Same questions
	  -- ManualOrAutomatic behavior definition
	  -- "The access of this object is read-write if the row to which
	  -- it belongs is manual (i.e. is being or was created manually)
	  -- otherwise (i.e. was created automatically) it is read-only."
	
	Same questions
	
	Further I See that for several of your read-write objects,
	you do not define what the persistency behaviour is or should
	be. So what can a management application expect after a
	restart of the agent? Some of the objects I found this for:
	
	  isisSysLevelType
	  isisSysID
	  isisSysMaxPathSplits
	  isisSysMaxLSPGenInt
	
	and probably more objects.
	That is by the way a type of "blocking" issue.
	
	
	On Page 16 I see:
	
	-- The Level 1 Manual Area Address Table
	-- contains the set of area addresses manually configured
	-- for this Intermediate System.
	-- At least one row in which the value of isisManAreaAddrExistState
	-- is active must be present. The maximum number of rows
	-- in this table for for which the object
	-- isisManAreaAddrExistState has the value active is 3.
	--     An attempt to create more 3 rows of isisManAreaAddrEntry
	-- with state 'active' in one instance of the IS-IS protocol
	-- should return inconsistentValue.
	
	    isisManAreaAddrTable OBJECT-TYPE
	        SYNTAX SEQUENCE OF IsisManAreaAddrEntry
	        MAX-ACCESS not-accessible
	        STATUS current
	        DESCRIPTION
	            "The set of manual area addresses configured on this
	             Intermediate System."
	        REFERENCE "{ISIS.aoi manualAreaAddresses (10)}"
	    ::= { isisSystem 2 }
	
	So I wonder why the commented text (all lines starting with --)
	are not just put into the DESCIPTION clause.
	
	That is the sort of things that I wonder about.
	
	Bert