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

Randy, 

I guess you confused the docsIfUpChannelTable (the clone) which now says
says temporarly entries (used for clonning) 
Do not persist

The Minnie's situation if for the Modulation table (vendor default
entries) It has has no constrains in modifying objects while active, so
StorageType is just to identify vendor templates (normally readOnly
permanent) of user created entries, ( in your list of ussage of
StorageType) 
Minnie's question if if need to be specify that rowstatus != active,
StorageType = nonVolatile the entry is deleted or if the RowStatus aging
covers that.

Eduardo  


-----Original Message-----
From: Randy Presuhn [mailto:[email protected]] 
Sent: Friday, April 16, 2004 1:57 PM
To: [email protected]
Subject: Re: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) -
Clarification


Hi -

> From: "Eduardo Cardona" <[email protected]>
> To: "Minnie Lu" <[email protected]>; "Randy Presuhn" 
> <[email protected]>
...
> Sent: Friday, April 16, 2004 11:58 AM
> Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - 
> Clarification
...
> The only pending part.
>   "For non-active row, the value is always 'volatile(2)'"

This seems like an unusual constraint.  My understanding is that the
point of having a writable StorageType in a table with RowStatus is to
permit the management application to specify the desired persistence
behaviour of the row.  Regardless of the specified storage type of a row
that is under creation, if it stays in a non-active state too long, the
agent needs to delete it.  (Think of it as preventing a memory leak in
object identifier space.  :-)

> I am not sure if the active to non-active Rowstatus transitions for 
> StorageType are needed or what are the current practices, I won't 
> think it hurts, will like to hear Randy's and other's opinions
...

The most important active to non-active transition is probably
"destroy", which is necessary for obvious reasons.  Explicitly placing a
row "not in service" is useful if there is a need to modify it, and
changes to the active row would not be permitted for some reason.

The important thing is to be clear on how you want it to work. I think
part of the difficulty here is that it's beginning to sound like the
lifecycle of these rows created for cloning may be quite different from
other rows.  For example, "destroy" doesn't make sense for "normal" rows
here.  Since provisioning isn't supported, "create-and-go" and
"create-and-wait" also don't make sense for "normal" rows.

As I indicated before, the table is being used for two very different
purposes, and, if it weren't so late in the discussion, I'd advocate a
different approach.

As to Minnie's point, it'd be perfectly reasonable from a MIB design
perspective to not use the StorageType TC, and in the table description
to require active rows to persist.  The question is whether you actually
want it to work that way.  (Forgive me if I've misunderstood Minnie's
concerns.)  What StorageType brings is:
   - a way to control whether entries created by management persist
   - a way to learn whether an entry will persist
   - a distinction between nonVolatile, permanent, and readOnly entries.
If these features aren't needed, then there's a legitimate question
whether it's the right tool for the job.

Randy



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