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

Comment inline ... [AZ]

Eduardo Cardona wrote:
> 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'

[AZ] It would be the above.  But after reading some of the comment from
Randy, I think we should be ok for status 'notInService'.

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

[AZ] Thanks!

> </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

[AZ] Since the only requirement to comply is the support for 
'nonVolatile' so I don't see the need to re-state how the 'permanent'
status should behave since its already clearly defined.  This would
also avoid further misinterpretation.

Thanks,
Azlina

> 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
> 
> 
> 
> 
> _______________________________________________
> IPCDN mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipcdn
>