RE: Re: V2 Changes for next RFI v2 MIB (draft 10)

Hi, Eduardo,

For aging, I would also prefer just leave by default as is with no extra 
requirements in the DESCRIPTION.  We can just focus on the persistence.

Thanks a lot !
Minnie
At 09:00 AM 4/16/2004 -0600, Eduardo Cardona wrote:
>Hi Minnie, Andrew,
>
>In the last few days Randy is being promoting the avoidance of MAY
>clauses in specific protocol requirements, and I tend to agree with him
>as far as do not create new requirements but indicates how the box
>behaves.
>
>Having timers on a table basis means to me confusion and unnecessary
>requirements for both developers and Managers.
>I also believe the "thinking time" is a valuable feature but current
>SNMP UIs and applications allow users to do the thinking off-line and
>set the configuration at once when the management strategy is completed.
>( A manager may need to think first time, but if it becomes a very
>common and repeated task, the manager better script or introduce the
>task in the OSS workflow to save "$thinking" time).
>
>While I think the RowStatus requirements is well intended, I do believe
>it would be OK in SNMP only managed devices. The storage architecture of
>systems with CLI I believe is very different of an SNMP only system.
>Moreover the combinations of both systems makes a cat-catching-its-tail
>dilemma between CLI and SNMP modules, which I think should be avoided
>with simplistic approaches. Then I do believe that today there is
>already a "wide" interoperability issue that is not going to be solved
>specializing one SNMP table.
>
>Therefore, As Randy pointed, the managers should keep the RowStatus in
>active as a general policy across all management systems to persist
>entries regardless of accurate implemented RowStatus timeouts, or at
>reinitialization time deletion.
>
>I Also believe a manager will be very uncomfortable to rely in the SNMP
>agent to age out administratively created entries when it can do them
>directly (you always will go back to check to see if that happen just
>for reasons beyond the normal operation of the device).
>
>- Which does not solve a totally out of context problem: auditing the
>management data base quality information, and probably make that more
>difficult-.
>
>
>In summary, With the RowStatus requirement (which I do not completely
>understand from a perspective of SNMP state-less protocol but RowStatus)
>on place I do not see any reasons to deviate from that and I would
>prefer just leave by default as is with no extra requirements in the
>DESCRIPTION.
>
>But at the same time not saying that the RowStatus aging timeout is
>something will be ever achieved to be fully interoperable as RFC 2579
>says, leaving the issue to be mere operator policy for
>creation/deletion.
>
>Thanks
>
>Eduardo
>
>
>
>
>
>
>-----Original Message-----
>From: Randy Presuhn [mailto:[email protected]]
>Sent: Thursday, April 15, 2004 9:12 PM
>To: [email protected]
>Subject: Re: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10)
>
>
>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
>
>
>
>_______________________________________________
>IPCDN mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/ipcdn
>
>
>_______________________________________________
>IPCDN mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/ipcdn