RE: [pkt-prov] MTA MIB Error OID table - a number of questions

Hi,
 
I am unaware of any specific reason for the range when it was proposed. (I guess it was assumed that 1024 errors would exceed any errors in a single configuration file!).
 
I would agree on the /dev/null (but indicating in the 1024th entry there were more errors!). 
 
Sumanth
 
.
 

	-----Original Message----- 
	From: [email protected] on behalf of Leandro Rzezak 
	Sent: Thu 8/12/2004 3:00 PM 
	To: 'Jean-Francois Mule'; [email protected]; 'PacketCable Provisioning and OSS Majordomo List' 
	Cc: [email protected]; 'Dave Thaler' 
	Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions
	
	

	About the 2nd issue, perhaps going with the ">/dev/null" mode but
	overwriting the 1024th error with a warning...
	
	Regards,
	
	Leandro Rzezak
	Intraway Corp.
	http://www.intraway.com
	
	-----Original Message-----
	From: [email protected] [mailto:[email protected]] On Behalf Of
	Jean-Francois Mule
	Sent: Thursday, August 12, 2004 5:11 PM
	To: [email protected]; PacketCable Provisioning and OSS Majordomo List
	Cc: [email protected]; Dave Thaler
	Subject: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions
	
	Folks,
	
	   We received one comment from Dave Thaler during the IETF mib doctor
	review on the MTA MIB ErrorOID table for which I would like to request some
	input from the lists (comment #11 from Dave).
	
	1. Max range of the index object:
	   pktcMtaDevErrorOidIndex  OBJECT-TYPE 
	   SYNTAX      Unsigned32 (1..1024)
	                              ^^^^
	Is there any reason why we are limiting the size of this object? From an
	implementation point of view on the snmp mib agent, is this limitation
	buying much?
	
	
	2. What happens if more than 1024 errors are encountered?
	Hopefully this does not happen often since the operators manage the config
	files and it is extremely rare to have config files with over 1024 entries
	or with a smaller number of entries causing 1024 errors.
	That said, if we keep the range as-is, per Dave's recommendation, we should
	define properly what happens after the value 1024 is reached so that all MTA
	vendors do it consistently and so that SNMP mgers can act accordingly in
	those cases.
	
	Assuming we keep the range as is (1..1024), there are a couple of options
	for MTAs to populate the table when a 1025th error is encountered:
	  - ">/dev/null": forget about it, any error after 1024 does not get stored,
	only the first 1024 errors are present in the table,
	  - "wrap": overwrite entries starting with entry 1, so 1025 -> 1, 1026 ->
	2, etc.
	  - "tail": just overwrite the last entry (1..1023 remain stable, 1024 is
	updated with the latest error: 1025 -> 1024, 1026 -> 1024, etc.)
	
	The "wrap" mode is not a good option in my opinion for 2 reasons:
	      - by analogy with compilation errors we sometimes encounter with
	C++/C/SMI, an error early on in the file being parsed can cause numerous
	subsequent errors which are not very relevant;
	      - in this particular case of config files with TLV tuples, if
	something goes wrong on the MTA misinterpreting the length of a TLV for
	e.g., all subsequent TLV parsing will be affected.
	=> "wrap" won't help troubleshoot the primary errors.
	
	My preference would be ">/dev/null". It is simpler for MTAs and if there are
	1024 errors, who cares about the remaining ones (based on the above). The
	"tail" mode is misleading in my opinion and is not very relevant as
	intermediate entries (1025..max_errors-1) will be missed.
	
	Are there any other/better options if we keep the range? Any comments on the
	above?
	
	Jean-François
	
	
	
	_______________________________________________
	IPCDN mailing list
	[email protected]
	https://www1.ietf.org/mailman/listinfo/ipcdn
	
	
	_______________________________________________
	IPCDN mailing list
	[email protected]
	https://www1.ietf.org/mailman/listinfo/ipcdn

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