Subject: [ipcdn] docsIfCmtsModulationTable and StorageType TC ?

From: Donati Andrew-MGIA0477 <[email-masked]>
Date: Thu, 22 Jan 2004 11:15:07 -0500

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

---

From: "Eduardo Cardona" <[email-masked]>
Date: Thu, 22 Jan 2004 11:21:46 -0700

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-masked]] 
Sent: Thursday, January 22, 2004 9:15 AM
To: [email-masked]'
Cc: Eduardo Cardona; [email-masked]'; [email-masked]'
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

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 23 Jan 2004 10:42:46 -0700

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-masked]; DOCSIS OSS Majordomo List;
Owner DOCSIS OSS Majordomo List; Jean-Francois Mule; Richard Woundy @
Comcast
Cc: [email-masked]; [email-masked]
Subject: [ipcdn] RE: docsIfCmtsModulationTable and StorageType TC ?

Andy, 

Eduardo

-----Original Message-----
From: Donati Andrew-MGIA0477 [mailto:[email-masked]] 
Sent: Thursday, January 22, 2004 9:15 AM
To: [email-masked]'
Cc: Eduardo Cardona; [email-masked]'; [email-masked]'
Subject: docsIfCmtsModulationTable and StorageType TC ?

All,

Regards,
Andy Donati
Motorola BCS

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

---

From: Minnie Lu <[email-masked]>
Date: Fri, 23 Jan 2004 11:25:16 -0800

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

---

From: Donati Andrew-MGIA0477 <[email-masked]>
Date: Fri, 23 Jan 2004 15:32:11 -0500

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-masked]] 
Sent: Friday, January 23, 2004 2:25 PM
To: Donati Andrew-MGIA0477; Jean-Francois Mule
Cc: Eduardo Cardona; [email-masked]; DOCSIS OSS Majordomo List; Owner DOCSIS OSS Majordomo List; Comcast"<[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>"@il06exr06.mot.com
Subject: RE: [ipcdn] RE: docsIfCmtsModulationTable and StorageType TC ?

Hi, Andy, Jean, and all,

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:
>   - Eduardo & the group's email exchanges from October to December 03 
>to close those issues - see many postings on the list archive and the
>and/or docsIfCmtsModControl? Let us know,
>Jean-Francois
>  ipcdn co-chair
>
>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.
>
>
>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.
>
>StorageType objects? There is a case in the docsIfCmtsModulationTable 
>where the presence of this object will be very helpful.

---

From: Murwin William-LWM008 <[email-masked]>
Date: Fri, 23 Jan 2004 18:03:16 -0500

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

Andy,

-----Original Message-----
From: Eduardo Cardona 
Sent: Thursday, January 22, 2004 11:22 AM
To: Donati Andrew-MGIA0477; [email-masked]; DOCSIS OSS Majordomo List;

Andy, 

Eduardo

-----Original Message-----
From: Donati Andrew-MGIA0477 [mailto:[email-masked]] 
Sent: Thursday, January 22, 2004 9:15 AM
To: [email-masked]'
Cc: Eduardo Cardona; [email-masked]'; [email-masked]'
Subject: docsIfCmtsModulationTable and StorageType TC ?

All,

Regards,
Andy Donati
Motorola BCS

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
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
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

---

From: Donati Andrew-MGIA0477 <[email-masked]>
Date: Sun, 25 Jan 2004 22:14:58 -0500

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 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-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Saturday, January 24, 2004 12:00 PM
To: [email-masked]
Subject: IPCDN digest, Vol 1 #533 - 1 msg

Send IPCDN mailing list submissions to
	[email-masked]

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

You can reach the person managing the list at
	[email-masked]

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-masked]>
To: Murwin William-LWM008 <[email-masked]>,
        "'Jean-Francois Mule'"
	 <[email-masked]>
Cc: "IPCDN (E-mail) (E-mail)" <[email-masked]>
Subject: RE: [ipcdn] RE: docsIfCmtsModulationTable and StorageType TC ?
Date: Sat, 24 Jan 2004 15:32:36 +0100

> and also better understand the IESG rules of authoring MIBs 
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
> Will Murwin

--__--__--

End of IPCDN Digest

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 28 Jan 2004 16:07:44 -0700

Given that Bert wrote:
> 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.
and 
> So it is not a MUST HAVE storageType object. It is a MUST 
> EXPLAIN the expected behaviour w.r.t. persistency.

and that both Minnie & Andy have commented that adding some explanatory text is ok, I'd like to close on the direction we select: do we have wg consensus to add text to the relevant & existing table/entry description instead of adding storagetype objects?

If we agree that this is a good compromise at this point, we have to agree on the proposed text. Comments?
Jean-François