RE: docsIfCmtsModulationTable and StorageType TC ?

Jean,

The proposed additional sentence for docsIfCmtsModControl should be more explicit.

Instead of, "In some implementations, rows created at run time may not be deleted", state
"In some implementations, pre-defined rows created at system initialization time may not be deleted"
 

>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."
>
-----> Change to the above sentence:
Instead of, "In some implementations, rows created at run time may not be deleted", state
"In some implementations, pre-defined rows created at system initialization time may not be deleted"

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


We can also add other sentences relating to to the volatility and von-volatility of these rows.

Thanks, 

Andy
Motorola BCS



-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
Sent: Saturday, January 24, 2004 12:00 PM
To: [email protected]
Subject: IPCDN digest, Vol 1 #533 - 1 msg


Send IPCDN mailing list submissions to
	[email protected]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/ipcdn
or, via email, send a message with subject or body 'help' to
	[email protected]

You can reach the person managing the list at
	[email protected]

When replying, please edit your Subject line so it is more specific than "Re: Contents of IPCDN digest..."


Today's Topics:

   1. RE: RE: docsIfCmtsModulationTable and StorageType TC ? (Wijnen, Bert (Bert))

--__--__--

Message: 1
From: "Wijnen, Bert (Bert)" <[email protected]>
To: Murwin William-LWM008 <[email protected]>,
        "'Jean-Francois Mule'"
	 <[email protected]>
Cc: "IPCDN (E-mail) (E-mail)" <[email protected]>
Subject: RE: [ipcdn] RE: docsIfCmtsModulationTable and StorageType TC ?
Date: Sat, 24 Jan 2004 15:32:36 +0100

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



--__--__--

_______________________________________________
IPCDN mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn


End of IPCDN Digest