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

Hi Minnie, 
I will buy this,
the current compliance statement allow only nonVolatile which makes that
nearly a compliance read-only.
With version 2 of the proposals the other new StorageType objects are
read-only, so for the Modulation Table, even there are some benetifs in
being read-crate a read-only will be ok with me, 

any other opinion?


Thanks

Eduardo


-----Original Message-----
From: Minnie Lu [mailto:[email protected]] 
Sent: Friday, April 16, 2004 1:16 PM
To: Eduardo Cardona
Cc: Minnie Lu; Randy Presuhn; Donati Andrew-MGIA0477; [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, 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