Subject: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification

From: Donati Andrew-MGIA0477 <[email-masked]>
Date: Fri, 16 Apr 2004 12:23:52 -0400

I would like to correct/clarify the earlier sentence.  The suggestion should have stated to add to the "docsIfCmtsModControl" DESCRIPTION,  not to the "Row Status" DESCRIPTION already defined in RFC2579.

Instead of:

To address the concern raised by Minnie, may I suggest that we add to the DESCRIPTION clause of the row status column to define a time interval that the agent must remove rows that remain in the 'notInService' or 'notReady' state.

This is what was intended:

To address the concern raised by Minnie, may I suggest that we add to the DESCRIPTION clause of  docsIfCmtsModControl to define a time interval that the agent must remove rows that remain in the 'notInService' or 'notReady' state.

Thanks,
Andy

-----Original Message-----
From: Donati Andrew-MGIA0477 
Sent: Friday, April 16, 2004 8:01 AM
To: 'Minnie Lu'; Eduardo Cardona
Cc: Eduardo Cardona; [email-masked]; Randy Presuhn; Keske Tom-LTK002; Azlina Ahmad; DOCSIS OSS Majordomo List
Subject: RE: V2 Changes for next RFI v2 MIB (draft 10)

All,

To address the concern raised by Minnie, may I suggest that we add to the DESCRIPTION clause of the row status column to define a time interval that the agent must remove rows that remain in the 'notInService' or 'notReady' state.

This is defined under "Interaction 4: Making the Conceptual Row Available" in RFC 2579. 

Taken from RFC2579 Section 2, Row Status, Interaction 4:  

            "If the management station is prevented from setting the
            status column to `active' (e.g., due to management station
            or network failure) the conceptual row will be left in the
            `notInService' or `notReady' state, consuming resources
            indefinitely.  The agent must detect conceptual rows that
            have been in either state for an abnormally long period of
            time and remove them.  It is the responsibility of the
            DESCRIPTION clause of the status column to indicate what an
            abnormally long period of time would be.  This period of
            time should be long enough to allow for human response time
            (including `think time') between the creation of the
            conceptual row and the setting of the status to `active'.
            In the absence of such information in the DESCRIPTION
            clause, it is suggested that this period be approximately 5
            minutes in length.  This removal action applies not only to
            newly-created rows, but also to previously active rows which
            are set to, and left in, the notInService state for a
            prolonged period exceeding that which is considered normal
            for such a conceptual row."

Thanks,
Andy

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Thursday, April 15, 2004 3:37 PM
To: Eduardo Cardona
Cc: Eduardo Cardona; Donati Andrew-MGIA0477; [email-masked]; Randy Presuhn; Keske Tom-LTK002; Azlina Ahmad; Minnie Lu; DOCSIS OSS Majordomo List
Subject: Re: V2 Changes for next RFI v2 MIB (draft 10)

Hi, Eduardo,

   Thanks a lot for listening to me. I am happy with the new text.

    But I still have concern about saving notInService or notReady rows for 
modulation profiles into NVRAM and have them persistent across CMTS 
reboot,  especially for the rows with inconsistent attributes which is 
allowed for rowStatus in 'notInService' and 'notReady'.

   Though this is extreme case, but since the MIB or spec does not prevent 
to do so or does not make it optional, that means CMTS MUST implement such 
capability to save rows with inconsistent attributes into NVRAM which is a 
waste of CMTS resource and complicated the implementation for no or little 
gain.

   Possible to make it an optional that saving rows with inconsistent 
attributes into NVRAM and persistent across reboot ?

    Thanks a lot for your advice !
    Minnie

At 10:27 AM 4/15/2004 -0600, Eduardo Cardona wrote:

>Hi all,
>
>Please find attached the summary of changes after all your feedback,
>special thanks to Randy Presuhn for all the detailed comments.
>
>Please note that the storageType objects are being set as CMTS only
>requirement docsIfCmtsGroupV2  since the CM compliances are read-only 
>or any other tables do not apply to CMs.
>
>Change #9 for the docsIfCmRangingTimeout please review the other
>question sent to the list and OSSI reflector
>
>Please see if the coments are being captured properly.
>
>
>PDF has the color change, also attached text file for convenience.
>
>
>Thanks
>
>Eduardo
>

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

---

From: "Eduardo Cardona" <[email-masked]>
Date: Fri, 16 Apr 2004 10:34:34 -0600

Hi Andrew, 
very welcome the clarification, even though, I think It was well
understood since docsIfCmtsModControl SYNTAX is RowStatus, 

Thanks

Eduardo

-----Original Message-----
From: Donati Andrew-MGIA0477 [mailto:[email-masked]] 
Sent: Friday, April 16, 2004 10:24 AM
To: Donati Andrew-MGIA0477; 'Minnie Lu'; Eduardo Cardona
Cc: Eduardo Cardona; [email-masked]'; 'Randy Presuhn'; Keske
Tom-LTK002; 'Azlina Ahmad'; DOCSIS OSS Majordomo List
Subject: RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification

I would like to correct/clarify the earlier sentence.  The suggestion
should have stated to add to the "docsIfCmtsModControl" DESCRIPTION,
not to the "Row Status" DESCRIPTION already defined in RFC2579.

Instead of:

To address the concern raised by Minnie, may I suggest that we add to
the DESCRIPTION clause of the row status column to define a time
interval that the agent must remove rows that remain in the
'notInService' or 'notReady' state.

To address the concern raised by Minnie, may I suggest that we add to
the DESCRIPTION clause of  docsIfCmtsModControl to define a time
interval that the agent must remove rows that remain in the
'notInService' or 'notReady' state.

Thanks,
Andy

-----Original Message-----
From: Donati Andrew-MGIA0477 
Sent: Friday, April 16, 2004 8:01 AM
To: 'Minnie Lu'; Eduardo Cardona
Cc: Eduardo Cardona; [email-masked]; Randy Presuhn; Keske Tom-LTK002;
Azlina Ahmad; DOCSIS OSS Majordomo List
Subject: RE: V2 Changes for next RFI v2 MIB (draft 10)

All,

To address the concern raised by Minnie, may I suggest that we add to
the DESCRIPTION clause of the row status column to define a time
interval that the agent must remove rows that remain in the
'notInService' or 'notReady' state.

This is defined under "Interaction 4: Making the Conceptual Row
Available" in RFC 2579. 

Thanks,
Andy

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Thursday, April 15, 2004 3:37 PM
To: Eduardo Cardona
Cc: Eduardo Cardona; Donati Andrew-MGIA0477; [email-masked]; Randy
Presuhn; Keske Tom-LTK002; Azlina Ahmad; Minnie Lu; DOCSIS OSS Majordomo
List
Subject: Re: V2 Changes for next RFI v2 MIB (draft 10)

Hi, Eduardo,

    But I still have concern about saving notInService or notReady rows
for 
modulation profiles into NVRAM and have them persistent across CMTS 
reboot,  especially for the rows with inconsistent attributes which is 
allowed for rowStatus in 'notInService' and 'notReady'.

   Though this is extreme case, but since the MIB or spec does not
prevent 
to do so or does not make it optional, that means CMTS MUST implement
such 
capability to save rows with inconsistent attributes into NVRAM which is
a 
waste of CMTS resource and complicated the implementation for no or
little 
gain.

---

From: Minnie Lu <[email-masked]>
Date: Fri, 16 Apr 2004 11:28:27 -0700

Hi,  Randy and Eduardo,

Thanks a lot for the advice !

I wonder whether it is really needed to add the new object StorageType in 
this modulation profiles.  Sorry to go back to the step 1.

1. active row most likely are persistent across reboot already in current 
CMTS implementation.  I don't think it will be any extra work for CMTS to 
have active MUST be persistent across reboot. Also, it will be clear to 
user that all active rows will be persistent cross reboot.
2. non-active looks like no use to be persistent across reboot. Also 
non-active rows can be aged out even in the run time.

Since the rule is (please allow me to quoted from Randy's previous email) 
"explicit about persistence, either mandating it in DESCRIPTIONs or using 
StorageType to report / control it as needed."

Here is my suggestions.

  Suggestion 1:  Explicit about persistence mandating it in DESCRIPTION.
    "rowStatus is in 'Active' MUST be persistent across managed system reload"

     For non-active rows, just follow the RFC, so no need to mention in the 
MIB.

  Suggestion 2:  New object StorageType RO  (read-only)
     For user created active row, the value is always 'nonVolatile(3)'
     For non-active row, the value is always 'volatile(2)'
     For system created default rows, the value can be ether
         a. for vendors choose to have read-create access for the system 
default rows
          'volatile(2)' when row is changed to notInService or
          'nonVolatile(3)'
         b. for vendors choose to have read-only access for the system 
default rows
          'permanent(4)' or 'readOnly(5)'

   Will it work ?

   Thanks a lot for your advice again !
   Minnie

---

From: Minnie Lu <[email-masked]>
Date: Fri, 16 Apr 2004 12:15:57 -0700

Hi, Eduardo,

  Will you agree that the access is read-only for new object StorageType ? 
For this modulation profile table, I see there is a need to "report' but I 
don't see there is a need to let user to 'control' which will create so 
many complicated cases.

At 12:58 PM 4/16/2004 -0600, Eduardo Cardona wrote:
>Hi Minnie,
>
>In my side, a two months ago the consensus was to introduce the
>StorageType although other alternatives were suggested, finally all
>arguments always pointed "it is white, heins make them, scrambled eaten"
>so the clearest way was the StorageType
>
>Going to your proposal 2), there is a compliance statement that says
>that only nonVolatile(3) is required wich covers  "For user created
>active row, the value is always 'nonVolatile(3)'
>
>
>Having vendor "writeable"  (instead of read-create) default entries is
>not different that operator created entries, so maybe the text below
>this is not needed
>
>              default rows 'volatile(2)' when row is changed to
>notInService or
>             'nonVolatile(3)'
>
>The sentence below is already covered in the Entry Description
>
>             default rows 'permanent(4)' or 'readOnly(5)' time, which
>could report a value
>            'permanent' or 'readOnly' for docsIfCmtsModStorageType.
>
>
>The only pending part.
>    "For non-active row, the value is always 'volatile(2)'"
>
>I am not sure if the active to non-active Rowstatus transitions for
>StorageType are needed or what are the current practices, I won't think
>it hurts, will like to hear Randy's and other's opinions
>
>Eduardo
>
>
>
>Sent: Friday, April 16, 2004 12:28 PM
>To: Eduardo Cardona; Randy Presuhn
>Cc: Donati Andrew-MGIA0477; Minnie Lu; [email-masked]; Keske Tom-LTK002;
>Subject: Re: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) -
>Clarification
>
>
>Hi,  Randy and Eduardo,
>
> >Presuhn; Keske Tom-LTK002; Azlina Ahmad; Minnie Lu; DOCSIS OSS
> >Majordomo List
> >     But I still have concern about saving notInService or notReady
> >rows for modulation profiles into NVRAM and have them persistent across
>
> >CMTS reboot,  especially for the rows with inconsistent attributes
> >which is allowed for rowStatus in 'notInService' and 'notReady'.
> >
> >prevent to do so or does not make it optional, that means CMTS MUST
> >implement such

---

From: "Eduardo Cardona" <[email-masked]>
Date: Fri, 16 Apr 2004 13:52:10 -0600

Hi Minnie, 
I will buy this,
the current compliance statement allow only nonVolatile which makes that
nearly a compliance read-only.
With version 2 of the proposals the other new StorageType objects are
read-only, so for the Modulation Table, even there are some benetifs in
being read-crate a read-only will be ok with me, 

any other opinion?

Thanks

Eduardo

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Friday, April 16, 2004 1:16 PM
To: Eduardo Cardona
Cc: Minnie Lu; Randy Presuhn; Donati Andrew-MGIA0477; [email-masked];
Keske Tom-LTK002; Azlina Ahmad; DOCSIS OSS Majordomo List
Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) -
Clarification

Hi, Eduardo,

  Will you agree that the access is read-only for new object StorageType
? 
For this modulation profile table, I see there is a need to "report' but
I 
don't see there is a need to let user to 'control' which will create so 
many complicated cases.

At 12:58 PM 4/16/2004 -0600, Eduardo Cardona wrote:
>arguments always pointed "it is white, heins make them, scrambled 
>eaten" so the clearest way was the StorageType
>

>Cc: Donati Andrew-MGIA0477; Minnie Lu; [email-masked]; Keske 
>Tom-LTK002; Azlina Ahmad; DOCSIS OSS Majordomo List
>I wonder whether it is really needed to add the new object StorageType 
>in this modulation profiles.  Sorry to go back to the step 1.
>
>1. active row most likely are persistent across reboot already in 
>current CMTS implementation.  I don't think it will be any extra work 
>for CMTS to
>"explicit about persistence, either mandating it in DESCRIPTIONs or 
>using StorageType to report / control it as needed."
>
>Here is my suggestions.
>
>     "rowStatus is in 'Active' MUST be persistent across managed system

>reload"
>
>      For non-active rows, just follow the RFC, so no need to mention 
>in the MIB.
>

> >             clause, it is suggested that this period be 
> > approximately
>5
> >implement such capability to save rows with inconsistent attributes 
> >into NVRAM which
>is
> >a
> >little gain.
> >    Possible to make it an optional that saving rows with 
> >inconsistent attributes into NVRAM and persistent across reboot ?
> >
> > >Please find attached the summary of changes after all your 
> > >feedback, special thanks to Randy Presuhn for all the detailed 
> > >comments.
> > >

---

From: "Eduardo Cardona" <[email-masked]>
Date: Fri, 16 Apr 2004 16:44:21 -0600

Exactly that's the last Minnies, concern, if explicitely or not even
needed.
Thanks
Eduardo

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Friday, April 16, 2004 4:11 PM
To: [email-masked]
Subject: Re: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) -
Clarification

Hi -

> From: "Eduardo Cardona" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Friday, April 16, 2004 2:49 PM
...
> Minnie's question if if need to be specify that rowstatus != active, 
> StorageType = nonVolatile the entry is deleted or if the RowStatus 
> aging covers that.
...

Ah.  Sorry about the confusion.
When an agent ages out a row that hasn't gone active
within the prescribed time, I believe it doesn't matter what the
StorageType was set to.  Of course, it doesn't hurt to be explicit.

Randy

---

From: Minnie Lu <[email-masked]>
Date: Fri, 16 Apr 2004 17:27:13 -0700

Hi, Eduardo and  Randy,

"When an agent ages out a row that hasn't gone active
within the prescribed time, I believe it doesn't matter what the
StorageType was set to."

  Great !  It is very useful info. Thanks a lot !

  So please allow me to summary the requirement as I understand so far.

   For docsIfCmtsModulationTable,
   1. active rows MUST be persistent across CMTS reload.
   2. non-active row will not be persistent (implied by rowStatus and no 
matter what value is in the storageType).
   3. System default rows MAY be read-only by setting the storageType value 
to  permanent(4), or readOnly(5) when system create the default rows.

    I think it is ok to have docsIfCmtsModStorageType as read-only 
object.:-)   In this way, it can be sure that the active row's storageType 
will not be changed to volatile(2) and lost after reboot. This is important 
especially for those in-used rows.

   If I miss anything, please correct me.

   Thanks  a lot !
   Minnie

---

From: "Eduardo Cardona" <[email-masked]>
Date: Sun, 18 Apr 2004 08:18:50 -0600

Hi Minnie, 
 
that's a good summary, 
 
I will make docsIfCmtsModStorageType read-only, based in all your arguments
 
Thanks
 
Eduardo

	-----Original Message----- 
	From: Minnie Lu [mailto:[email-masked]] 
	Sent: Fri 4/16/2004 6:27 PM 
	To: Eduardo Cardona; Randy Presuhn 
	Cc: [email-masked]; [email-masked]; DOCSIS OSS Majordomo List 
	Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification

	Hi, Eduardo and  Randy,

	

	
	
	   Thanks  a lot !
	   Minnie

---

From: Minnie Lu <[email-masked]>
Date: Mon, 19 Apr 2004 10:28:42 -0700

Hi, Eduardo,

Thanks a lot !
Minnie

At 08:18 AM 4/18/2004 -0600, Eduardo Cardona wrote:
> >From: Randy Presuhn 
> [<mailto:[email-masked]>mailto:[email-masked]]
> ><https://www1.ietf.org/mailman/listinfo/ipcdn>https://www1.ietf.org/mailm 
> an/listinfo/ipcdn
> >
> >
> ><https://www1.ietf.org/mailman/listinfo/ipcdn>https://www1.ietf.org/mailm 
> an/listinfo/ipcdn
>

---

From: "Eduardo Cardona" <[email-masked]>
Date: Mon, 19 Apr 2004 17:12:05 -0600

One last comment, as a clarification, 

At least I received one comment from a software vender,  (not a CMTS
vender), being unclear about the reported value of
docsIfCmtsCmStatusUpChannelIfIndex for 2.0 CMTs, ifType 129 or 205 ?
I guess it merits a clarification for non-DOCSIS experts.

Speaking for vendors and Cablelabs perspective is clear that 2.0 CMTS
reports ifIndex with ifType 205 and for DOCSIS 1.x it reports ifIndex
with ifType 129, Something ovbious for a reduced group of the
population. 

See the current text and the clarification below I am including in the
draft 10 

docsIfCmtsCmStatusUpChannelIfIndex OBJECT-TYPE
        SYNTAX      InterfaceIndexOrZero
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "IfIndex of the upstream channel this CM is connected
             to.  If the upstream channel is unknown, this object
             returns a value of zero."
        ::= { docsIfCmtsCmStatusEntry 5 }

docsIfCmtsCmStatusUpChannelIfIndex OBJECT-TYPE
        SYNTAX      InterfaceIndexOrZero
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
             "For DOCSIS 2.0, indicates the ifIndex of the logical 
             upstream channel (ifType 205) this CM is connected to
             For DOCSIS 1.x, indicates the ifIndex of the upstream 
             channel (ifType 129) this CM is connected to.

             If the upstream channel is unknown, this object
             returns a value of zero."
        ::= { docsIfCmtsCmStatusEntry 5 }

Eduardo

-----Original Message-----
From: Eduardo Cardona 
Sent: Sunday, April 18, 2004 8:19 AM
To: Minnie Lu; Randy Presuhn
Cc: [email-masked]; [email-masked]; DOCSIS OSS Majordomo List
Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) -
Clarification

Hi Minnie, 

that's a good summary, 

I will make docsIfCmtsModStorageType read-only, based in all your
arguments

Thanks

Eduardo
-----Original Message----- 
From: Minnie Lu [mailto:[email-masked]] 
Sent: Fri 4/16/2004 6:27 PM 
To: Eduardo Cardona; Randy Presuhn 
Cc: [email-masked]; [email-masked]; DOCSIS OSS Majordomo List 
Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) -
Clarification

Hi, Eduardo and  Randy,

   3. System default rows MAY be read-only by setting the storageType
value

    I think it is ok to have docsIfCmtsModStorageType as read-only
object.:-)   In this way, it can be sure that the active row's
storageType
will not be changed to volatile(2) and lost after reboot. This is
important
especially for those in-used rows.

   Thanks  a lot !
   Minnie