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

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