Re: Re: V2 Changes for next RFI v2 MIB (draft 10)
"Randy Presuhn" <[email protected]>
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <003201c42360$942805e0$7f1afea9@oemcomputer> |
Hi - > From: "Minnie Lu" <[email protected]> > To: "Eduardo Cardona" <[email protected]> ... > Sent: Thursday, April 15, 2004 5:55 PM > Subject: RE: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) ... > How about adding the following in the description ? > "Non-active row (rowStatus in 'notInService' or 'notReady') MAY be > destroyed by the agent at reinitialization of the managed system to save > the resources". I don't see how this would help interoperability. RFC 2119 says: MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) As a practical matter, the proposed language still means that management applications MUST be prepared to work with managed devices where the non-active rows disappear on reboot, as one would expect from the RowStatus definition. (Neglecting the corner case of reboots completing in less than five minutes from the creation of the row.) > This serves a hint to the user that if they wants to persist any rows > across CMTS reload, besides setting the StorageType to > nonVolatile(3), user also needs to set the rowStatus to active. They would need to do this anyway, based on the definition of StorageType and of RowStatus. > As aging non-active rows during the run time, I think it could be vendor > dependant implementation. ... This doesn't seem consistent with the definition of RowStatus, unless you add language to the object's description saying that these things may be retained indefinitely. Randy