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

From: "Eduardo Cardona" <[email-masked]>
Date: Thu, 15 Apr 2004 10:27:41 -0600

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

---

From: Minnie Lu <[email-masked]>
Date: Thu, 15 Apr 2004 12:36:40 -0700

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

>PDF has the color change, also attached text file for convenience.

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

---

From: "Eduardo Cardona" <[email-masked]>
Date: Thu, 15 Apr 2004 16:56:55 -0600

That's a good pointer, 
Thanks Randy
I personally was not aware of this language in the lengthy RowStatus
description, my apologize 

Minnie, Going back to your question, I now think the aging of
'superfluous' entries is the behavior by default for SNMP and I should
put myself in a non-deviating position of that. In the other hand if the
5 minutes by default of RFC 2579 is not convenient, would you have any
text proposal for this matter?

Thanks

Eduardo

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Thursday, April 15, 2004 2:54 PM
To: [email-masked]
Subject: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10)

Hi -

> From: "Eduardo Cardona" <[email-masked]>
> To: "Minnie Lu" <[email-masked]>
...
> Sent: Thursday, April 15, 2004 1:04 PM
> Subject: RE: V2 Changes for next RFI v2 MIB (draft 10)
...
> Specially I am not comfortable with the case of : active -> 
> notInService
> -> reboot -> "where is my old entry"?
...

If you do NOT want it to work this way, then you'll need to put language
to that effect into the DESCRIPTIONs for the RowStatus object. RFC 2579
page 16 makes it clear why:

            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.

Consequently, if the WG wants the peculiar behaviour of having
non-active rows survive re-boots, you'll need to spell it out in the
DESCRIPTIONs.

Randy

---

From: Minnie Lu <[email-masked]>
Date: Thu, 15 Apr 2004 17:55:42 -0700

Hi, Eduardo,

How about adding the following in the description ?
"Non-active row (rowStatus in 'notInService' or 'notReady') MAY be 
destroyed by the agent at reinitialization of the managed system to save 
the resources".

This serves a hint to the user that if they wants to persist any rows 
across CMTS reload, besides setting the StorageType to 
nonVolatile(3),  user also needs to set the rowStatus to active.

As aging non-active rows during the run time, I think it could be vendor 
dependant implementation.

Thanks a lot !
Minnie

---

From: Donati Andrew-MGIA0477 <[email-masked]>
Date: Fri, 16 Apr 2004 08:01:09 -0400

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

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

>requirement docsIfCmtsGroupV2  since the CM compliances are read-only 
>or any other tables do not apply to CMs.
>

---

From: "Eduardo Cardona" <[email-masked]>
Date: Fri, 16 Apr 2004 09:00:24 -0600

Hi Minnie, Andrew, 

In the last few days Randy is being promoting the avoidance of MAY
clauses in specific protocol requirements, and I tend to agree with him
as far as do not create new requirements but indicates how the box
behaves. 

Having timers on a table basis means to me confusion and unnecessary
requirements for both developers and Managers.
I also believe the "thinking time" is a valuable feature but current
SNMP UIs and applications allow users to do the thinking off-line and
set the configuration at once when the management strategy is completed.
( A manager may need to think first time, but if it becomes a very
common and repeated task, the manager better script or introduce the
task in the OSS workflow to save "$thinking" time).

While I think the RowStatus requirements is well intended, I do believe
it would be OK in SNMP only managed devices. The storage architecture of
systems with CLI I believe is very different of an SNMP only system.
Moreover the combinations of both systems makes a cat-catching-its-tail
dilemma between CLI and SNMP modules, which I think should be avoided
with simplistic approaches. Then I do believe that today there is
already a "wide" interoperability issue that is not going to be solved
specializing one SNMP table. 

Therefore, As Randy pointed, the managers should keep the RowStatus in
active as a general policy across all management systems to persist
entries regardless of accurate implemented RowStatus timeouts, or at
reinitialization time deletion. 

I Also believe a manager will be very uncomfortable to rely in the SNMP
agent to age out administratively created entries when it can do them
directly (you always will go back to check to see if that happen just
for reasons beyond the normal operation of the device). 

- Which does not solve a totally out of context problem: auditing the
management data base quality information, and probably make that more
difficult-.

In summary, With the RowStatus requirement (which I do not completely
understand from a perspective of SNMP state-less protocol but RowStatus)
on place I do not see any reasons to deviate from that and I would
prefer just leave by default as is with no extra requirements in the
DESCRIPTION. 

But at the same time not saying that the RowStatus aging timeout is
something will be ever achieved to be fully interoperable as RFC 2579
says, leaving the issue to be mere operator policy for
creation/deletion.

Thanks

Eduardo

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Thursday, April 15, 2004 9:12 PM
To: [email-masked]
Subject: Re: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10)

Hi -

> From: "Minnie Lu" <[email-masked]>
> To: "Eduardo Cardona" <[email-masked]>
...
> Sent: Thursday, April 15, 2004 5:55 PM
> Subject: RE: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10)
...
> How about adding the following in the description ? "Non-active row 
> (rowStatus in 'notInService' or 'notReady') MAY be destroyed by the 
> agent at reinitialization of the managed system to save the 
> resources".

I don't see how this would help interoperability.

RFC 2119 says:
   MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

As a practical matter, the proposed language still means that management
applications MUST be prepared to work with managed devices where the
non-active rows disappear on reboot, as one would expect from the
RowStatus definition. (Neglecting the corner case of reboots completing
in less than five minutes from the creation of the row.)

> across CMTS reload, besides setting the StorageType to nonVolatile(3),

> user also needs to set the rowStatus to active.

They would need to do this anyway, based on the definition of
StorageType and of RowStatus.

> As aging non-active rows during the run time, I think it could be 
> vendor dependant implementation.
...

This doesn't seem consistent with the definition of RowStatus, unless
you add language to the object's description saying that these things
may be retained indefinitely.

Randy

---

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

Hi, Eduardo,

For aging, I would also prefer just leave by default as is with no extra 
requirements in the DESCRIPTION.  We can just focus on the persistence.

Thanks a lot !
Minnie

---

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

Sounds good, any diverging opinion?

Thanks
Eduardo

-----Original Message-----
From: Minnie Lu [mailto:[email-masked]] 
Sent: Friday, April 16, 2004 12:49 PM
To: Eduardo Cardona
Cc: Randy Presuhn; [email-masked]; [email-masked]
Subject: RE: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10)

Hi, Eduardo,

Thanks a lot !
Minnie

>requirements for both developers and Managers. I also believe the 
>"thinking time" is a valuable feature but current SNMP UIs and 
>applications allow users to do the thinking off-line and set the 
>configuration at once when the management strategy is completed. ( A 
>manager may need to think first time, but if it becomes a very common 
>and repeated task, the manager better script or introduce the task in 
>the OSS workflow to save "$thinking" time).
>

>it would be OK in SNMP only managed devices. The storage architecture 
>of systems with CLI I believe is very different of an SNMP only system.

>understand from a perspective of SNMP state-less protocol but 
>RowStatus) on place I do not see any reasons to deviate from that and I

>would prefer just leave by default as is with no extra requirements in 
>the DESCRIPTION.
>
>As a practical matter, the proposed language still means that 
>management applications MUST be prepared to work with managed devices 
>where the non-active rows disappear on reboot, as one would expect from

>the RowStatus definition. (Neglecting the corner case of reboots 
>completing in less than five minutes from the creation of the row.)
>
> > This serves a hint to the user that if they wants to persist any 
> > rows across CMTS reload, besides setting the StorageType to 
> > nonVolatile(3),
>