RE: RE: docsIfCmtsModulationTable and StorageType TC ?

Jean,

In response to your request for clarification text in the descriptions of docsIfCmtsModulationEntry 
and docsIfCmtsModControl...

---> For docsIfCmtsModulationEntry:
After the sentence, "Initial default entries may be created at system initialization 
Time", add the following sentence:

"In some implementations, these predefined entries may be changed but not deleted or 
may neither be changed nor deleted."  

          
---> For docsIfCmtsModControl: 
After the sentence, "Controls and reflects the status of rows in this table", add the following:

"In some implementations, rows created at run time may not be deleted."

If other ideas come up, I'll let you know.

Thanks,
Andy

 

-----Original Message-----
From: Minnie Lu [mailto:[email protected]] 
Sent: Friday, January 23, 2004 2:25 PM
To: Donati Andrew-MGIA0477; Jean-Francois Mule
Cc: Eduardo Cardona; [email protected]; DOCSIS OSS Majordomo List; Owner DOCSIS OSS Majordomo List; Comcast"<[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>"@il06exr06.mot.com
Subject: RE: [ipcdn] RE: docsIfCmtsModulationTable and StorageType TC ?


Hi, Andy, Jean, and all,

->  else the row object (table entry) DESCRIPTION clause MUST specify
-->  what happens to dynamically-created rows after an agent restart."

I would like to propose that only the those entries with active value in 
docsIfCmtsModControl object MUST be saved after the managed device restarts.

For those notInService entries, it is vendor specific implementation to 
save them or not.

Those entries which rowStatus is notInService might not have all consistent 
attributes and they are not ready to be used (that is why the rowstatus is 
notInService).  I don't think there is a need to save those notInService 
rows.  But some vendor might want to save them, so I propose to leave it to 
vendor's choice.

Thank you !
Minnie


At 10:42 AM 1/23/2004 -0700, Jean-Francois Mule wrote:
>Andy,
>
>I would agree that in some instances, it could have been cleaner to 
>have a storagetype columnar object. As Eduardo pointed out however, we 
>are late in the ID revision cycle:
>   - see David Raftus list of issues from 9/12/03 and draft 07 open 
>issues
>   - my post from 10/1/03 summarizing the remaining open issues for the 
>draft to be completed and asking for comments,
>   - Eduardo & the group's email exchanges from October to December 03 
>to close those issues - see many postings on the list archive and the
>result: draft 09 was published on 12/19/03.
>So unless we have serious issues, my preference would be to *not add 
>new
>objects* at this time.
>
>That said, could we clarify the text in DESCRIPTION clause of some 
>existing objects in order to address your concern? (per section 
>referenced by Eduardo, 4.6.6 of
>draft-ietf-ops-mib-review-guidelines-02.txt:
>   "- There either MUST be one columnar object with a SYNTAX value of
>      StorageType [RFC2579] and a MAX-ACCESS value of read-create, or
>-->  else the row object (table entry) DESCRIPTION clause MUST specify  
>--> what happens to dynamically-created rows after an agent restart."
>
>Can you propose some clarification text for docsIfCmtsModulationEntry 
>and/or docsIfCmtsModControl? Let us know,
>Jean-Francois
>  ipcdn co-chair
>
>-----Original Message-----
>From: Eduardo Cardona
>Sent: Thursday, January 22, 2004 11:22 AM
>To: Donati Andrew-MGIA0477; [email protected]; DOCSIS OSS Majordomo List; 
>Owner DOCSIS OSS Majordomo List; Jean-Francois Mule; Richard Woundy @ 
>Comcast
>Cc: [email protected]; [email protected]
>Subject: [ipcdn] RE: docsIfCmtsModulationTable and StorageType TC ?
>
>
>Andy,
>
>Let me expand the question to the DOCSIS reflectors,
>
>This is a well known issue, that has its roots in RFC 2670 where no 
>read-create entries has a defined StorageType value Also the IPCDN 
>group is aware of the new guidelines for MIB revision (current draft 02 
>)  in section 4.6.4 defines requirements to say what to do at agent 
>initialization for read-create entries and storageType is one of the 
>various options.
>
>
>Predefined entries I believe are well cover by the row object 
>docsIfCmtsModulationEntry which says "Initial default entries may be 
>created at system initialization time." , It leaves them some sort of 
>persistence, weather permanent or read-only are another subject.
>
>A current ECR to OSSI spec  OSSIv2.0-R-04.0121-2 covers the cases where 
>Entries in the modulation profile table may not allow SNMP SETs as a 
>regular read-create entry.
>
>Since this optional template/default topic is a vendor differentiation 
>area we believe that it is OK having in the MIB the minimum 
>requirements, for those vendors not willing to implement default 
>entries, specially due the broad implementation of this MIB as is right 
>now.
>
>
>We are close to request last Call for this MIB and would prefer not to 
>introduce optional features, only broken pieces. Although, we would 
>follow carefully the Bert's and other MIB doctors, advisors and IPCDN 
>members recommendations in this area to get the MIB clear as possible 
>and ready for IESG approval.
>
>Let me know if I cover your concerns
>
>Eduardo
>
>-----Original Message-----
>From: Donati Andrew-MGIA0477 [mailto:[email protected]]
>Sent: Thursday, January 22, 2004 9:15 AM
>To: '[email protected]'
>Cc: Eduardo Cardona; '[email protected]'; '[email protected]'
>Subject: docsIfCmtsModulationTable and StorageType TC ?
>
>
>All,
>
>Do all Read-Create tables within the DOCS-IF-MIB need to have 
>StorageType objects? There is a case in the docsIfCmtsModulationTable 
>where the presence of this object will be very helpful.
>If a vendor chooses to implement several pre-configured default
>modulation profiles that cannot be destroyed,
>these rows can have the status of "permanent" or "readOnly" (depending
>on whether or not values are allowed
>to be changed within these rows).   Currently, if a vendor desires to
>implement one or more pre-defined default
>modulation profiles that are intended to not be deleted, it may be
>difficult to comply with the Row Status
>Textual Convention described in SMIv2- TC.
>
>Regards,
>Andy Donati
>Motorola BCS