Re: Changes for next RFI v2 MIB (draft 10)

In general, how would we avoid storing a 'bad' configuration?

For example:
      User might create an notInService entry and set the storageType
to nonVolatile (persistent across reload). And while its in Status of 
notInService, the columnar values are not validated.

Change #2:
   :
   "Initial default entries ....., which could report
   for a value 'permanent' or 'readOnly' for docsIfCmtsModStorageType.
   A CMTS may not allow the creation of additional Interval ....."

   [AZ] I found the above to be confusing:
   Can we reword it to:

   "Initial default entries may be created at system intialization
    time by defaulting the docsIfCmtsModStorageType value to
    'permanent(4)' or 'readOnly(5).


Change #3:
   :
   :
   Conceptual rows having the value 'permanent' need
   not allow write-access to any columnar objects ..."

   [AZ] Since the definition of 'permanent(4)' mentioned that
   a row can be changed but not deleted, I don't think we need
   to repeat the statement above.

Thanks,
Azlina


Eduardo Cardona wrote:
> Hi Andrew, all, 
> 
> Please review the attached with the proposed changes for the StorageType
> issues to see of they cover all concerns.
> 
> In summary, there are eight proposed changes
> 
> Changes 1,2,3,4 are related to the issue brough by Andrew Donati by
> adding StorageType object to the Modulation profile table
> 
> Changes 5,6,7,8 are clarifications to accommodate the OPS MIB revision
> guidelines sections 4.6.2 and 4.6.4, quite related to the problem raised
> for the storageType case.
> 
> During the WG Last call for technical issues, there were no other items
> pointing our attention.
> 
> Let the WG know any question or comments by COB Wednesday before
> submiting the draft to IETF.
> 
> 
> Eduardo