RE: clarification text for docsIfCmtsModulationTable re: row persistency

Hi, Jean and Andy,

  It seems to me that there are two things we need to address and add the 
text in the description.

1. Pre-defined modulation profiles MAY read-only. Andy's proposal as below 
looks good to me.

"In some implementations, pre-defined rows created at system initialization 
time may
not be deleted".

2. Rows persistence. Jean's proposal as below looks good to me.

"Entries with a status column (docsIfCmtsModControl) of value
  'active' MUST be persist across reboots. Entries with a
  status column (docsIfCmtsModControl) of value 'notReady' and
  'notInService' may not persist after reboots since those
  entries were explicit made not be available for use by the
  managed device ('notInService') or the agent had not
  sufficient info anyway ('notReady')."

Thanks a lot !
Minnie

At 09:14 AM 1/29/2004 -0500, Donati Andrew-MGIA0477 wrote:
>All,
>
>Basically, the initial concern is to cover the cases where the default 
>rows created at system initialization cannot be deleted.  We need to find 
>some way to legally allow vendors to implement these default rows as "read 
>only" (rows cannot be changed or deleted) or "permanent" (rows can be 
>changed but not deleted).
>
>Either one of the following options are possible:
>
>1.  Add the following sentence to the DESCRIPTION clause for 
>docsIfCmtsModControl:
>
>"In some implementations, pre-defined rows created at system 
>initialization time may
>not be deleted"
>
>
>2.  Implement the StorageType object in the table.
>
>
>Thanks,
>Andy
>
>
>
>-----Original Message-----
>From: Wijnen, Bert (Bert) [mailto:[email protected]]
>Sent: Thursday, January 29, 2004 4:50 AM
>To: 'Jean-Francois Mule'; Donati Andrew-MGIA0477; [email protected]
>Cc: [email protected]
>Subject: RE: [ipcdn] clarification text for docsIfCmtsModulationTable re: 
>row persistency
>
>
>Mmmm... when I see this discussion, then it seems to me that using 
>StorageType object is the better choice and makes it possible for vendors 
>to show "may not be deleted" by making them permanent for example.
>
>Also... the issue of when a row gets deleted that is in
>notInService or notReady state, that is described in
>RFC2579 in the RowStatus TC DESCRIPTION clause.
>
>Thanks,
>Bert
>
> > -----Original Message-----
> > From: Jean-Francois Mule [mailto:[email protected]]
> > Sent: donderdag 29 januari 2004 1:52
> > To: Donati Andrew-MGIA0477; [email protected]
> > Cc: [email protected]
> > Subject: [ipcdn] clarification text for docsIfCmtsModulationTable re:
> > row persistency
> >
> >
> > Andy wrote:
> > > The proposed additional sentence for docsIfCmtsModControl
> > > should be more explicit.
> > >
> > > Instead of, "In some implementations, rows created at run
> > > time may not be deleted", state "In some implementations,
> > > pre-defined rows created at system initialization time may
> > > not be deleted"
> > Based on a chat with Eduardo, I do understand a little better
> > that the persistence of those rows may depend on the product
> > implementation. However, I'm curious what this
> > implementation-dependent behavior means to operators & sys admins?
> > I am a bit concerned that adding such vague statements don't
> > help any of us in the end (they don't help sysadmins because
> > one cannot assume much and they don't help new implementors
> > because they don't give much guidance).
> > See below.
> >
> > Minnie wrote:
> > > I would like to propose that only the those entries with
> > > active value in
> > > docsIfCmtsModControl object MUST be saved after the managed
> > > device restarts.
> > I like this proposal better because it states what the
> > behavior should be for *all* implementations on a subset of
> > entries ('active' rows only, right?). Are they any concerns
> > with this approach?
> >
> > Minnie wrote:
> > > For those notInService entries, it is vendor specific
> > > implementation to save them or not.
> > What about 'notReady'? To me 'notReady' and 'notInService'
> > should fall in the same bucket.
> >
> > Minnie wrote:
> > > Those entries which rowStatus is notInService might not have
> > > all consistent
> > > attributes and they are not ready to be used (that is why the
> > > rowstatus is
> > > notInService).  I don't think there is a need to save those
> > > notInService
> > > rows.  But some vendor might want to save them, so I propose
> > > to leave it to
> > > vendor's choice.
> > I personally think it is acceptable to not mandate the
> > persistency of data for 'notReady' and 'notInService' and
> > that we can justify it as you proposed. It may also convey
> > Andy's comment about implementation specific behaviors - but
> > it constraints those to a subset of rows for which nothing
> > was certain from a mgmt station point of view.
> >
> > How about the following text:
> > Entries with a status column (docsIfCmtsModControl) of value
> > 'active' MUST be persist across reboots. Entries with a
> > status column (docsIfCmtsModControl) of value 'notReady' and
> > 'notInService' may not persist after reboots since those
> > entries were explicit made not be available for use by the
> > managed device ('notInService') or the agent had not
> > sufficient info anyway ('notReady').
> >
> > Comments?
> > Jean-François
> >
> > _______________________________________________
> > IPCDN mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/ipcdn
> >
>
>_______________________________________________
>IPCDN mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/ipcdn