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

Hi Azlina, see inline,

Eduardo

-----Original Message-----
From: Azlina Ahmad [mailto:[email protected]] 
Sent: Wednesday, April 14, 2004 2:51 PM
To: Eduardo Cardona
Cc: Donati Andrew-MGIA0477; [email protected]
Subject: Re: [ipcdn] 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.

<edo>
Is that a bad configuration or a temporary held offline configuration?
Bad configuration is 'notReady' 
'notInService' could be :
   a createAndWait with complete setup but deferred set 'active'
   an entry previously 'active' set to 'notInService'

I believe the StorageType object carries the RowStatus values before the
reset, leaving to the operator 
The responsibility to have the house clean. :)

</edo>

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).

<edo>
After Randy's comments the definition says: 
 
             Initial default entries MAY be created at system 
             initialization time which could report for a value 
             'permanent' or 'readOnly' for docsIfCmtsModStorageType.
             A CMTS MAY allow the creation of additional Interval
             Usage Codes for a modulation profile being defined at 
             Initialization time.

Will add yours to become:

             Initial default entries MAY be created at system 
             initialization time by defaulting the 
             docsIfCmtsModStorageType value to permanent(4) or 
             readOnly(5).
             A CMTS MAY allow the creation of additional Interval
             Usage Codes for a modulation profile being defined at 
             Initialization time.

</edo>

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.


<edo>
There are two definitions:
Effective read-write columnar values in a row which has a StorageType
'permananent' 
'permanent' Can be written and last value will be back up after reset.

The not writable property in the TC description is for the StorageType 

I guess the only difference within nonVolatile and 'permanent' is that
you may not create 'permanent' entries
via SNMP but could modified existing 'permanent' entries, while
'nonVolatile' entries can be created via SNMP, deleted and even and turn
later to 'volatile'.

What the text is trying to say is that behaves as a 'readOnly' but TC
refers to 
readOnly as a ROM (fully) implementation which is not always the case, 

So  many RFCs uses this phrase to indicate that the storage realization
may be 
Partially ROM (what's that? EEPROM? ) instead of fully ROM but behaves
as readOnly, 
(unchangeable), mainly for the difficult to implement a 'permanent'
entry that is 
persistent and writable. Or a code initialized value ("ROM") but
conditioned to further updates (code with NVRAM hooks i.e.) 

Not that I like to go to all these compliances formalism but probably
necessary.

It leaves also the vendors freedom to handle the 'permanent' cases
read-only or read-write

Being dual read-only or read-write is probably another point for
interoperability problems due the ambiguous definition. I guess is being
accepted as a generalization of permanent -> being likely 'readOnly' 
without state the ROM implications by TC definitions.
Not something I am very concern.
</edo>

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