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

Hi Minnie, 

Could be the case that for the same reason you have vendor default
entries, a user may create their own set of entries and turn them
disable to avoid being used to configure interfaces.

Specially I am not comfortable with the case of : active -> notInService
-> reboot -> "where is my old entry"? 


For the case of notReady, I may think that you are trying to align the
CLI approach ( a command does not success if is not well formed then you
execute the write to memory command to save the changes and only correct
table entries are saved, (the bad ones do not exist). I have no strong
opinion against that and I would like to hear from IPCDN participants
about conventional practices or similar situations in other MIB modules.


Will that help? sorry not having a more definitive answer.
It does not preclude to come up with the approapiate wording as a
proposal which may help to discover other type of reactions :)

Eduardo



-----Original Message-----
From: Minnie Lu [mailto:[email protected]] 
Sent: Thursday, April 15, 2004 1: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
>