RE: WGLC for: draft-ietf-hubmib-efm-cu-mib-06.txt

Clay,
 
The reason I changed the syntax of ifCapStackStatus and ifInvCapStackStatus objects from a new enum to the RowStatus was to emphasize the similarity between the ifCapStackTable/ifInvCapStackTable and ifStackTable/ifInvStackTable as well as to try to reuse an existing textual convention instead of inventing yet another enum.
 
I don't think making the ifCapStackStatus/ifInvCapStackStatus to be read-only is illegal or problematic - the ifInvStackStatus object from IF-INV-STACK-MIB with a RowStatus syntax is read-only as well.
 
I would also argue that overloading of NotInService value is ok - this value is defined as:
"- 'NotInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device".
Since these tables are static (read-only) there is no question of resource consumption - these rows are never deleted and thus can stay in NotInService state indefinitely. RFC2579 states that "It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be." I can add a sentence in the DESCRIPTION clause saying that an ifCapStackStatus/ifInvCapStackStatus may be in the NotInService state indefinitely, formally complying with RFC2579.
 
However I'm not bent on staying with RowStatus - I'll move back to the enum if the group feels it is best.
 
Regards,
-E.



  _____  

	From: Clay Sikes [mailto:[email protected]] 
	Sent: Tuesday, October 17, 2006 23:11
	To: [email protected]
	Cc: [email protected]
	Subject: Re: [Hubmib] WGLC for: draft-ietf-hubmib-efm-cu-mib-06.txt
	
	
	Hi,
	
	I have run into an issue with the ifCapStackStatus and ifInvCapStackStatus objects.  Although the ifCapStackMIB passes smilint, I have seen compilation issues with these objects.  It seems that the root cause is the combination RowStatus  syntax and the read-only max-access (A RowStatus that is read-only seems a bit strange to me).  The compiler does not generate all the code that is required.  Although there may or may not be an issue with the compiler, I would beg that the objects be changed from a RowStatus syntax to a enumeration like what was in the -05 version of the ID.  This may resolve Keith's issue as well.
	
	Thoughts?
	
	Thanks,
	Clay
	
	On 10/17/2006 12:09 PM, Keith McCloghrie wrote: 

			This is a formal WG Last Call for 
			  http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-06.txt
			    

		 
		      ifCapStackStatus  OBJECT-TYPE
		        SYNTAX      RowStatus
		        MAX-ACCESS  read-only
		        STATUS      current
		        DESCRIPTION
		          "The status of the 'cross-connect capability' relationship
		          between two sub-layers. The following values can be returned:
		            active(1)       - indicates that the sub-layer interface,
		                              identified by the ifStackLowerLayer MAY
		                              be connected to run 'below' the sub-layer
		                              interface, identified by the
		                              ifStackHigherLayer index.
		            notInService(2) - the sub-layer interfaces cannot be
		                              connected temporarily due to
		                              unavailability of the interface(s), e.g.
		                              one of the interfaces is located on a
		                              pluggable module which is absent.
		
		I suggest this is an ill-advised overloading of 'notInService'.
		RFC 2579 says:
		
		            If the management station is prevented from setting the
		            status column to `active' (e.g., due to management station
		            or network failure) the conceptual row will be left in the
		            `notInService' or `notReady' state, consuming resources
		            indefinitely.  The agent must detect conceptual rows that
		            have been in either state for an abnormally long period of
		            time and remove them.  It is the responsibility of the
		            DESCRIPTION clause of the status column to indicate what an
		            abnormally long period of time would be.  This period of
		            time should be long enough to allow for human response time
		            (including `think time') between the creation of the
		            conceptual row and the setting of the status to `active'.
		            In the absence of such information in the DESCRIPTION
		            clause, it is suggested that this period be approximately 5
		            minutes in length.  This removal action applies not only to
		            newly-created rows, but also to previously active rows which
		            are set to, and left in, the notInService state for a
		            prolonged period exceeding that which is considered normal
		            for such a conceptual row.
		
		In other words, the 'notInService' of RowStatus is for a temporary
		delay in a management station setting it to `active'.  The "temporary"
		situation of a "pluggable module which is absent" is liable to be
		much longer than the 5 minutes before the agent is required to delete
		the row.
		
		Keith.
		
		_______________________________________________
		Hubmib mailing list
		[email protected]
		https://www1.ietf.org/mailman/listinfo/hubmib

_______________________________________________
Hubmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/hubmib