RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification

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 protected]] 
Sent: Friday, April 16, 2004 10:24 AM
To: Donati Andrew-MGIA0477; 'Minnie Lu'; Eduardo Cardona
Cc: Eduardo Cardona; '[email protected]'; '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 protected]; 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 protected]] 
Sent: Thursday, April 15, 2004 3:37 PM
To: Eduardo Cardona
Cc: Eduardo Cardona; Donati Andrew-MGIA0477; [email protected]; 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
>