RE: RE: docsIfCmtsModulationTable and StorageType TC ?

Jean,

What is the IESG position on a table that is read-create, that contains row-status control, and in past drafts/RFCs had descriptions which led implementators/operators to question the which entries where persistence, read-only, and volatile. 

I thought that was the reason why all the DOCSIS MIB, i.e. BPI+, DOCSIS QOS, and subcriber management all had to add StorageType objects to Read-Create Tables even though all entries in these MIB are persistence through reboot. Bert had given this as a general comment to all DOCSIS MIBs at the IPCDN Interim Meeting (March 2003).
Was this comment from Bert to improve the quality of the Mibs or is it required by IESG for approval? Is this comment only apply to new drafts rather rework of RFCs ?

I am not trying to offer an opinion if this change is need or not. I am just trying to have the author avoid futher work if IESG requires this as improvement
and also better understand the IESG rules of authoring MIBs with RowStatus control.

Thanks,
Will Murwin


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


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