Subject: RE: [ipcdn] draft-ietf-ipcdn-pktc-mtamib-05 - why 1024?

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 21 Jan 2005 11:24:02 -0700

A question was posed w.r.t. the choice of the max number of errors in the MTA ErrorOID table, currently set as 1024 in the object definition. I just wanted to close the loop on the comment and the suggestions to not limit the error OID table to 1024 but instead, put a max in MODULE-COMPLIANCE.

After talking to some folks here and some vendors, here's a summary of our discussions:
  - we think that a limit of 1024 errors in a config file that is usually 20-100(say even 300) lines or OID assignments is sufficient, even for future extensions,
  - the cable operators do control this config file very strictly and run lab tests before rolling out a new config file and this table is a pre-deployment tool to check config file errors and 1024 is ok.

=> So, the authors are recommending we keep the object as-is. We have had many discussions and valuable refinements to state what happens beyond the 1024th error. 

We will add the following text in the object description clause to explain the rationale:
  "The maximum number of errors or warnings that can be recorded in the pktcMtaDevErrorOidsTable is set to 1024 as a configuration file is usually validated by operators before deployment. Given the possible number of configuration parameter assignments in the MTA configuration file, 1024 is perceived as a sufficient limit even with future extensions."

Feel free to propose better text. 

Let me know if this is ok.
Jean-François
PS: The alternative to get rid of the limit in the object definition, add it to the module compliance, which also provides strong guidance to vendors for their implementations. Let me know if this is a better route, I really think that this is a minor comment given how this table is used. And we're all used to SMICng barking after a certain number of errors when compiling a MIB module and that pretty much means: too many errors, fix those first, then come back and try again...

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