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

Hi, Eduardo,

  Will you agree that the access is read-only for new object StorageType ? 
For this modulation profile table, I see there is a need to "report' but I 
don't see there is a need to let user to 'control' which will create so 
many complicated cases.

   Thanks a lot for your advice !
   Minnie

At 12:58 PM 4/16/2004 -0600, Eduardo Cardona wrote:
>Hi Minnie,
>
>In my side, a two months ago the consensus was to introduce the
>StorageType although other alternatives were suggested, finally all
>arguments always pointed "it is white, heins make them, scrambled eaten"
>so the clearest way was the StorageType
>
>Going to your proposal 2), there is a compliance statement that says
>that only nonVolatile(3) is required wich covers  "For user created
>active row, the value is always 'nonVolatile(3)'
>
>
>Having vendor "writeable"  (instead of read-create) default entries is
>not different that operator created entries, so maybe the text below
>this is not needed
>
>      For system created default rows, the value can be ether
>          a. for vendors choose to have read-create access for the system
>
>              default rows 'volatile(2)' when row is changed to
>notInService or
>             'nonVolatile(3)'
>
>The sentence below is already covered in the Entry Description
>
>    b. for vendors choose to have read-only access for the system
>             default rows 'permanent(4)' or 'readOnly(5)' time, which
>could report a value
>            'permanent' or 'readOnly' for docsIfCmtsModStorageType.
>
>
>The only pending part.
>    "For non-active row, the value is always 'volatile(2)'"
>
>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
>
>Eduardo
>
>
>
>-----Original Message-----
>From: Minnie Lu [mailto:[email protected]]
>Sent: Friday, April 16, 2004 12:28 PM
>To: Eduardo Cardona; Randy Presuhn
>Cc: Donati Andrew-MGIA0477; Minnie Lu; [email protected]; Keske Tom-LTK002;
>Azlina Ahmad; DOCSIS OSS Majordomo List
>Subject: Re: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) -
>Clarification
>
>
>Hi,  Randy and Eduardo,
>
>Thanks a lot for the advice !
>
>I wonder whether it is really needed to add the new object StorageType
>in
>this modulation profiles.  Sorry to go back to the step 1.
>
>1. active row most likely are persistent across reboot already in
>current
>CMTS implementation.  I don't think it will be any extra work for CMTS
>to
>have active MUST be persistent across reboot. Also, it will be clear to
>user that all active rows will be persistent cross reboot.
>2. non-active looks like no use to be persistent across reboot. Also
>non-active rows can be aged out even in the run time.
>
>Since the rule is (please allow me to quoted from Randy's previous
>email)
>"explicit about persistence, either mandating it in DESCRIPTIONs or
>using
>StorageType to report / control it as needed."
>
>Here is my suggestions.
>
>   Suggestion 1:  Explicit about persistence mandating it in DESCRIPTION.
>     "rowStatus is in 'Active' MUST be persistent across managed system
>reload"
>
>      For non-active rows, just follow the RFC, so no need to mention in
>the
>MIB.
>
>   Suggestion 2:  New object StorageType RO  (read-only)
>      For user created active row, the value is always 'nonVolatile(3)'
>      For non-active row, the value is always 'volatile(2)'
>      For system created default rows, the value can be ether
>          a. for vendors choose to have read-create access for the system
>
>default rows
>           'volatile(2)' when row is changed to notInService or
>           'nonVolatile(3)'
>          b. for vendors choose to have read-only access for the system
>default rows
>           'permanent(4)' or 'readOnly(5)'
>
>    Will it work ?
>
>    Thanks a lot for your advice again !
>    Minnie
>
>At 10:34 AM 4/16/2004 -0600, Eduardo Cardona wrote:
> >Hi Andrew,
> >very welcome the clarification, even though, I think It was well
> >understood since docsIfCmtsModControl SYNTAX is RowStatus,
> >
> >Thanks
> >
> >Eduardo
> >
> >-----Original Message-----
> >From: Donati Andrew-MGIA0477 [mailto:[email protected]]
> >Sent: Friday, April 16, 2004 10:24 AM
> >To: Donati Andrew-MGIA0477; 'Minnie Lu'; Eduardo Cardona
> >Cc: Eduardo Cardona; '[email protected]'; 'Randy Presuhn'; Keske
> >Tom-LTK002; 'Azlina Ahmad'; DOCSIS OSS Majordomo List
> >Subject: RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification
> >
> >
> >I would like to correct/clarify the earlier sentence.  The suggestion
> >should have stated to add to the "docsIfCmtsModControl" DESCRIPTION,
> >not to the "Row Status" DESCRIPTION already defined in RFC2579.
> >
> >Instead of:
> >
> >To address the concern raised by Minnie, may I suggest that we add to
> >the DESCRIPTION clause of the row status column to define a time
> >interval that the agent must remove rows that remain in the
> >'notInService' or 'notReady' state.
> >
> >This is what was intended:
> >
> >To address the concern raised by Minnie, may I suggest that we add to
> >the DESCRIPTION clause of  docsIfCmtsModControl to define a time
> >interval that the agent must remove rows that remain in the
> >'notInService' or 'notReady' state.
> >
> >Thanks,
> >Andy
> >
> >-----Original Message-----
> >From: Donati Andrew-MGIA0477
> >Sent: Friday, April 16, 2004 8:01 AM
> >To: 'Minnie Lu'; Eduardo Cardona
> >Cc: Eduardo Cardona; [email protected]; Randy Presuhn; Keske Tom-LTK002;
> >Azlina Ahmad; DOCSIS OSS Majordomo List
> >Subject: RE: V2 Changes for next RFI v2 MIB (draft 10)
> >
> >
> >All,
> >
> >To address the concern raised by Minnie, may I suggest that we add to
> >the DESCRIPTION clause of the row status column to define a time
> >interval that the agent must remove rows that remain in the
> >'notInService' or 'notReady' state.
> >
> >This is defined under "Interaction 4: Making the Conceptual Row
> >Available" in RFC 2579.
> >
> >Taken from RFC2579 Section 2, Row Status, Interaction 4:
> >
> >             "If the management station is prevented from setting the
> >             status column to `active' (e.g., due to management station
> >             or network failure) the conceptual row will be left in the
> >             `notInService' or `notReady' state, consuming resources
> >             indefinitely.  The agent must detect conceptual rows that
> >             have been in either state for an abnormally long period of
> >             time and remove them.  It is the responsibility of the
> >             DESCRIPTION clause of the status column to indicate what
>an
> >             abnormally long period of time would be.  This period of
> >             time should be long enough to allow for human response
>time
> >             (including `think time') between the creation of the
> >             conceptual row and the setting of the status to `active'.
> >             In the absence of such information in the DESCRIPTION
> >             clause, it is suggested that this period be approximately
>5
> >             minutes in length.  This removal action applies not only
>to
> >             newly-created rows, but also to previously active rows
>which
> >             are set to, and left in, the notInService state for a
> >             prolonged period exceeding that which is considered normal
> >             for such a conceptual row."
> >
> >Thanks,
> >Andy
> >
> >-----Original Message-----
> >From: Minnie Lu [mailto:[email protected]]
> >Sent: Thursday, April 15, 2004 3:37 PM
> >To: Eduardo Cardona
> >Cc: Eduardo Cardona; Donati Andrew-MGIA0477; [email protected]; Randy
> >Presuhn; Keske Tom-LTK002; Azlina Ahmad; Minnie Lu; DOCSIS OSS
> >Majordomo List
> >Subject: Re: V2 Changes for next RFI v2 MIB (draft 10)
> >
> >
> >Hi, Eduardo,
> >
> >    Thanks a lot for listening to me. I am happy with the new text.
> >
> >     But I still have concern about saving notInService or notReady
> >rows for modulation profiles into NVRAM and have them persistent across
>
> >CMTS reboot,  especially for the rows with inconsistent attributes
> >which is allowed for rowStatus in 'notInService' and 'notReady'.
> >
> >    Though this is extreme case, but since the MIB or spec does not
> >prevent to do so or does not make it optional, that means CMTS MUST
> >implement such
> >capability to save rows with inconsistent attributes into NVRAM which
>is
> >a
> >waste of CMTS resource and complicated the implementation for no or
> >little
> >gain.
> >
> >    Possible to make it an optional that saving rows with inconsistent
> >attributes into NVRAM and persistent across reboot ?
> >
> >     Thanks a lot for your advice !
> >     Minnie
> >
> >
> >
> >
> >At 10:27 AM 4/15/2004 -0600, Eduardo Cardona wrote:
> >
> > >Hi all,
> > >
> > >Please find attached the summary of changes after all your feedback,
> > >special thanks to Randy Presuhn for all the detailed comments.
> > >
> > >Please note that the storageType objects are being set as CMTS only
> > >requirement docsIfCmtsGroupV2  since the CM compliances are read-only
>
> > >or any other tables do not apply to CMs.
> > >
> > >Change #9 for the docsIfCmRangingTimeout please review the other
> > >question sent to the list and OSSI reflector
> > >
> > >Please see if the coments are being captured properly.
> > >
> > >
> > >PDF has the color change, also attached text file for convenience.
> > >
> > >
> > >Thanks
> > >
> > >Eduardo
> > >
> >
> >
> >_______________________________________________
> >IPCDN mailing list
> >[email protected]
> >https://www1.ietf.org/mailman/listinfo/ipcdn