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

Sounds good, any diverging opinion?

Thanks
Eduardo


-----Original Message-----
From: Minnie Lu [mailto:[email protected]] 
Sent: Friday, April 16, 2004 12:49 PM
To: Eduardo Cardona
Cc: Randy Presuhn; [email protected]; [email protected]
Subject: RE: [ipcdn] 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