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.
> 
What we want is that read-write and/or read-create objects DO explain
what the persistency requirements/expectations are. One way to do that
(most flexible I think) is to use a StorageType object in a table.
Another way to do it, is to include in the Table or Entry DESCRIPTION
clause a statement about the expected behaviour w.r.t. persistency.

So it is not a MUST HAVE storageType object. It is a MUST EXPLAIN the
expected behaviour w.r.t. persistency.

Hope this helps,
Bert
> Thanks,
> Will Murwin