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

From: "Eduardo Cardona" <[email-masked]>
Date: Fri, 16 Apr 2004 12:58:59 -0600

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

     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)'
      
The sentence below is already covered in the Entry Description

   b. for vendors choose to have read-only access for the system 
            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

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Friday, April 16, 2004 12:28 PM
To: Eduardo Cardona; Randy Presuhn
Cc: Donati Andrew-MGIA0477; Minnie Lu; [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,  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

At 10:34 AM 4/16/2004 -0600, Eduardo Cardona wrote:
>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.
>
>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

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 16 Apr 2004 12:56:44 -0700

Hi -

> From: "Eduardo Cardona" <[email-masked]>
> To: "Minnie Lu" <[email-masked]>; "Randy Presuhn" <[email-masked]>
...
> Sent: Friday, April 16, 2004 11:58 AM
> Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification
...
>   "For non-active row, the value is always 'volatile(2)'"

This seems like an unusual constraint.  My understanding is that
the point of having a writable StorageType in a table with RowStatus
is to permit the management application to specify the desired
persistence behaviour of the row.  Regardless of the specified
storage type of a row that is under creation, if it stays in a non-active
state too long, the agent needs to delete it.  (Think of it as preventing
a memory leak in object identifier space.  :-)

> it hurts, will like to hear Randy's and other's opinions
...

The most important active to non-active transition is probably "destroy",
which is necessary for obvious reasons.  Explicitly placing a row
"not in service" is useful if there is a need to modify it, and changes
to the active row would not be permitted for some reason.

The important thing is to be clear on how you want it to work.
I think part of the difficulty here is that it's beginning to sound
like the lifecycle of these rows created for cloning may be quite
different from other rows.  For example, "destroy" doesn't make
sense for "normal" rows here.  Since provisioning isn't supported,
"create-and-go" and "create-and-wait" also don't make sense for
"normal" rows.

As I indicated before, the table is being used for two very
different purposes, and, if it weren't so late in the discussion,
I'd advocate a different approach.

As to Minnie's point, it'd be perfectly reasonable from a MIB design
perspective to not use the StorageType TC, and in the table
description to require active rows to persist.  The question is
whether you actually want it to work that way.  (Forgive me if I've
misunderstood Minnie's concerns.)  What StorageType brings is:
   - a way to control whether entries created by management persist
   - a way to learn whether an entry will persist
   - a distinction between nonVolatile, permanent, and readOnly entries.
If these features aren't needed, then there's a legitimate question
whether it's the right tool for the job.

Randy