Subject: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 17 Mar 2004 10:54:58 -0800

Hi -

I'd welcome discussion of this on the disman mailing list.
I think it's relevant to the question of what to do about the
expression and event MIBs.

Randy

> From: <[email-masked]>
> To: <IETF-Announce:>
> Sent: Wednesday, March 17, 2004 8:10 AM
> Subject: I-D ACTION:draft-yadawad-disman-ahcf-00.txt
>

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> Title : Advanced History Collection Framework
> Author(s) : S. Yadawad, H. Kumar, H. Yamijala, R. Shekar
> Filename : draft-yadawad-disman-ahcf-00.txt
> Pages : 47
> Date : 2004-3-17
>
> This draft defines a portion of the Management Information Base for
>     use with network management protocols in TCP/IP based Internets. In
>     particular, it defines objects for configuring and controlling the
>     history collection of user specified Data, which is an ASN.1
>     INTEGER based object.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt
>
...

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 17 Mar 2004 10:54:58 -0800

Hi -

Randy

...

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 17 Mar 2004 21:18:59 +0200

I will repeat a comment that I made during the meeting in Seoul. I think that all, or almost all that is being defined in this MIB module can already be performed - some features even in multiple ways - by agents that implement existing MIB modules like RMON, Events MIB, and Alarm MIB. I think that it would help the discussion if the authors could shortly describe what is the added value that this MIB module would bring, and what operations/management functions this MIB module provides that are not covered by existing MIB modules.  

Thanks and Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Randy Presuhn
> Sent: 17 March, 2004 8:55 PM
> To: Disman (E-mail)
> Subject: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt
> 
> 
> Hi -
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 17 Mar 2004 22:21:55 +0200

> 
> > operations/management functions this MIB module provides that are
> > not covered by existing MIB modules.
> ...
> 
> To the extent that the script MIB supports languages that are Turing
> complete, one could reasonably argue that all other MIBs are 
> superfluous.
> Of course, a problem with such a line of argument would be the
> amount of pain required to use such a system.  That is why 
> the expression
> MIB and the script MIB were both put out as Proposed Standards.
> 
> The motivation for the expression MIB was that it was supposed to be
> simpler to implement and use.  Whether it adequately met those
> criteria is being questioned.  From my perspective it looks like
> draft-yadawad-disman-ahcf-00.txt presents another factoring of
> the problem.  I am far from convinced that it is *the* solution, but
> (as WG chair) I think it's appropriate to include it in the discussion
> of whether the expression MIB requires some re-thinking.
> 

I was not going that far, and actually I did not have the expression MIB in mind. 

What I am seeing are mechanisms like RMON alarm and usrHistory being reinvented, and objects like ituSeverity from the Alarm MIB being duplicated.

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 17 Mar 2004 22:21:55 +0200

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Mar 2004 00:59:51 +0200

David,

There are a lot of creative ideas indeed. However, I do not understand yet why the design approach that was taken is better than extending the existing RMON usrHistory and Alarm mechanisms with the columns and instance filtering mechanisms. Id I am not mistaken such mechanisms were discussed, and rejected, or delayed by the time RMON2 was developed. 

Let us not forget that RMON agent implementations are widely deployed and understood and some vendors may have implemented such mechanisms already. The argumentation in the I-D is quite extensive, but I am not convinced that this solution is more efficient or saves agent resources.

Regards,

Dan

> Behalf Of David T. Perkins
> Sent: 17 March, 2004 10:43 PM
> To: [email-masked]
> Subject: Re: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt
> 
> 
> HI,
> 
> I just quickly scanned the document. It does provide in creative ways
> features not found in other MIB modules. These include:
>   1) automatic inclusion of values of new instances that come
>      into existence after control entry creation
>   2) filtering based on instance
>   3) identification of instances via "alternative indices" 
> 
> The definitions do have problems, maybe all are fixable. And it
> might be easy to extend it to provide additional benefits at a
> low cost.
> 
> To support it might be pretty expensive in memory and CPU processing,
> and it appears to be best matched for monitoring "hosts" or
> "big routers".
> 
> At 12:14 PM 3/17/2004 -0800, Randy Presuhn wrote:
> >Hi -
> >
> >(as technical contributor)
> >
> >> From: "Romascanu, Dan (Dan)" <[email-masked]>
> >> To: "Randy Presuhn" <[email-masked]>; 
> "Disman (E-mail)" <[email-masked]>
> >> Sent: Wednesday, March 17, 2004 11:18 AM
> >> Subject: RE: [Disman] Fw: I-D 
> ACTION:draft-yadawad-disman-ahcf-00.txt
> >>
> >
> >> I will repeat a comment that I made during the meeting in 
> Seoul. I think that all,
> >> or almost all that is being defined in this MIB module can 
> already be performed
> >> - some features even in multiple ways - by agents that 
> implement existing MIB
> >> modules like RMON, Events MIB, and Alarm MIB.
> >
> >This seems to be the case.  I think the question raised is 
> one of usability,
> >that is, how difficult is it to configure these existing 
> MIBs to these things.
> >This is another facet of the old scripting vs. expression 
> vs. special-purpose
> >MIB debate, but also ties in with the questions Juergen raised in his
> >overview of  
> http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt
> >at the session in Seoul.
> >
> >> I think that it would help the discussion if the authors 
> could shortly describe
> >> what is the added value that this MIB module would bring, and what
> >
> >Agreed.
> >
> Regards,
> /david t. perkins

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Mar 2004 00:59:51 +0200

David,

Regards,

Dan

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 17 Mar 2004 16:06:33 -0800

HI,

On the issue of whether or not to extend existing RMOM definitions
or to create new ones is something that I can see both sides.
It appears to me that the new proposal is something that would
be found in a host or big infrastructure box (such as a big router).
In neither of these is a place one would find RMON, and, thus
to me it boils down to a "packaging" issue.

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 17 Mar 2004 16:06:33 -0800

HI,

---

From: "Shailaja Yadawad" <[email-masked]>
Date: Thu, 18 Mar 2004 03:39:59 -0700

Randy,

>This seems to be the case.  I think the question raised is one of
usability,
>that is, how difficult is it to configure these existing MIBs to these
things.
>This is another facet of the old scripting vs. expression vs.
special-purpose
>at the session in Seoul.

Yes, usability is one of the motivation for our draft.
 
superfluous.
>amount of pain required to use such a system.  That is why the
expression
>MIB and the script MIB were both put out as Proposed Standards.

How true. It is not possible restrict the user to find solution for the
problem with the 
existing MIB definitions.
 
>the problem. 
 
Thanks.
 
Regards,
Shailaja.

---

From: "Shailaja Yadawad" <[email-masked]>
Date: Thu, 18 Mar 2004 03:40:35 -0700

David,
 
You have correctly captured the proposed features in our draft.
 
It will be great to fix all the definitions problems that you foresee.

Regards,
Shailaja.

>>> "David T. Perkins" <[email-masked]> 3/18/2004 2:13:11 AM
>>>

HI,

At 12:14 PM 3/17/2004 -0800, Randy Presuhn wrote:
>> To: "Randy Presuhn" <[email-masked]>; "Disman
(E-mail)" <[email-masked]>
>>
>
>> I will repeat a comment that I made during the meeting in Seoul. I
think that all,
>> or almost all that is being defined in this MIB module can already
be performed
>> - some features even in multiple ways - by agents that implement
existing MIB
usability,
things.
special-purpose
>at the session in Seoul.
>
>> I think that it would help the discussion if the authors could
shortly describe
superfluous.
expression
Regards,
/david t. perkins

---

From: "Shailaja Yadawad" <[email-masked]>
Date: Thu, 18 Mar 2004 03:40:08 -0700

Dan,
 
>I was not going that far, and actually I did not have the expression
MIB in mind. 

Expression MIB can be modified based on some of our features.

>What I am seeing are mechanisms like RMON alarm and usrHistory being
reinvented, and >objects like ituSeverity from the Alarm MIB being
duplicated.

you are correct that our draft contains object definition similar to
that of  RMON alarm and usrHistory but with additional features and
changes.
 
Regards,
Shailaja.

---

From: "Shailaja Yadawad" <[email-masked]>
Date: Thu, 18 Mar 2004 03:41:20 -0700

Dan,
 
Our main objective was easy and automatic configuration. In case of usr
history group, history collection can be configured for any number of
oids of any table for a given control entry, this will break our design
as configuration settings become specific to particular tables. This was
one main reason as why we did not propose extending the usr history
group.
 
Dan, the main thing is easy configuration and also let user configure
only for the desired number of instances which in turn saves the
resource.
 
Regards,
Shailaja.

>>> "Romascanu, Dan (Dan)" <[email-masked]> 3/18/2004 4:29:51 AM
>>>

David,

There are a lot of creative ideas indeed. However, I do not understand
yet why the design approach that was taken is better than extending the
existing RMON usrHistory and Alarm mechanisms with the columns and
instance filtering mechanisms. Id I am not mistaken such mechanisms were
discussed, and rejected, or delayed by the time RMON2 was developed. 

Let us not forget that RMON agent implementations are widely deployed
and understood and some vendors may have implemented such mechanisms
already. The argumentation in the I-D is quite extensive, but I am not
convinced that this solution is more efficient or saves agent
resources.

Regards,

Dan

---

From: "Shailaja Yadawad" <[email-masked]>
Date: Thu, 18 Mar 2004 03:40:35 -0700

David,

Regards,
Shailaja.

HI,

think that all,
be performed
existing MIB
usability,
things.
special-purpose
shortly describe
superfluous.
expression
Regards,
/david t. perkins

---

From: "Shailaja Yadawad" <[email-masked]>
Date: Thu, 18 Mar 2004 03:41:55 -0700

Dan,
 
As mentioned in the draft following are the features 
 
Simple configuration and Instance Management : suppose if the user
wants to configure history collection for all the instances of the
columnar oid, using RMON object definition the  user has to configure
for each instance individually where as using our object definition, it
is just one configuration setting.
 
It has to be noted here that the user has the option of applying same
configuration settings to all the instances or can fine tune the
configuration setting for desired instances.
 
RMON2 user history object definition does not take care of newly added
and deleted instances and hence if the new instances are added the user
has to configure for the new instances manually.
 
Consistent reference to the resource:
History collection activity can be for a long duration and hence it is
important to provide consistent reference of collected history to the
underlying physical media. This kind of feature is seen only interface
group however if user needs this kind of ability for any oid that is
being trended.

Instance Filtering
 
Istance filtering is not available in RMON user history mib.
 
Threshold Monitoring

Yes, threshold monitoring is available in the alarm table but if user
wants a complete solution of history collection and threshold monitoring
in a single object definition, our mib definition provides the
solution.
 
Dan, see it this way, the above mentioned  features are seen in many
mibs but user needs one mib which has all required features as otherwise
it is difficult for the user to implement multiple mibs for one
problem.
 
Regards,
Shailaja.

>>> "Romascanu, Dan (Dan)" <[email-masked]> 3/18/2004 12:48:59 AM
>>>

I will repeat a comment that I made during the meeting in Seoul. I
think that all, or almost all that is being defined in this MIB module
can already be performed - some features even in multiple ways - by
agents that implement existing MIB modules like RMON, Events MIB, and
Alarm MIB. I think that it would help the discussion if the authors
could shortly describe what is the added value that this MIB module
would bring, and what operations/management functions this MIB module
provides that are not covered by existing MIB modules.  

Thanks and Regards,

Dan

---

From: "Shailaja Yadawad" <[email-masked]>
Date: Thu, 18 Mar 2004 03:40:08 -0700

Dan,

 
Regards,
Shailaja.

---

From: "Shailaja Yadawad" <[email-masked]>
Date: Thu, 18 Mar 2004 03:39:59 -0700

Randy,

usability,
things.
special-purpose

superfluous.
expression

 
Thanks.
 
Regards,
Shailaja.

---

From: "Shailaja Yadawad" <[email-masked]>
Date: Thu, 18 Mar 2004 03:41:20 -0700

Dan,

 
Regards,
Shailaja.

David,

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Mar 2004 16:12:02 +0200

(sorry for the cross-posting, but I think that this conversation is relevant for rmonmib)
 
Shailadja,
 
I have read the draft carefully, I think that I understand it better now, and I appreciate what you are trying to achieve. I should point however, that the problems that you are dealing with have solutions in other MIB modules, sometimes even multiple solutions as you are yourself pointing. An optimization may be a good thing for a certain class of applications and devices, but a sound discussion is needed to prove that this is an important enough problem to deserve a new piece of standardization in the IETF.
 
What do you suggest that we do with this? Are you suggesting that we deprecate the relevant MIB groups in RMON and RMON-2 and replace them by new optimized MIB groups on the lines of your proposal? Or should we standardize a new method for user history with instance filtering, and applying alarms to history with lesser MIB objects in addition to existing RMON standards?  
 
Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Shailaja Yadawad
Sent: 18 March, 2004 12:42 PM
To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt

Dan,

Simple configuration and Instance Management : suppose if the user wants to configure history collection for all the instances of the columnar oid, using RMON object definition the  user has to configure for each instance individually where as using our object definition, it is just one configuration setting.
 
It has to be noted here that the user has the option of applying same configuration settings to all the instances or can fine tune the configuration setting for desired instances.
 
RMON2 user history object definition does not take care of newly added and deleted instances and hence if the new instances are added the user has to configure for the new instances manually.
 
Consistent reference to the resource:
History collection activity can be for a long duration and hence it is important to provide consistent reference of collected history to the underlying physical media. This kind of feature is seen only interface group however if user needs this kind of ability for any oid that is being trended.

Instance Filtering

Threshold Monitoring

Yes, threshold monitoring is available in the alarm table but if user wants a complete solution of history collection and threshold monitoring in a single object definition, our mib definition provides the solution.
 
Dan, see it this way, the above mentioned  features are seen in many mibs but user needs one mib which has all required features as otherwise it is difficult for the user to implement multiple mibs for one problem.
 
Regards,
Shailaja.

>>> "Romascanu, Dan (Dan)" <[email-masked]> 3/18/2004 12:48:59 AM >>>

Thanks and Regards,

Dan

> From: [email-masked] [ mailto:[email-masked]]On 
> Behalf Of Randy Presuhn

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Mar 2004 16:12:02 +0200

Shailadja,

 
Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Shailaja Yadawad
Sent: 18 March, 2004 12:42 PM
To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt

Dan,

 

Instance Filtering

Threshold Monitoring

 
Regards,
Shailaja.

Thanks and Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Mar 2004 16:19:00 +0200

... and this brings exactly the two issues that I am trying to point to:

*	as at least a partial solution exists to the problems that your I-D tries to solve, do the additional functionality and optimizations justify new standards work?
*	assuming the answer is yes to the above, should we not consider rather extending the existing RMON design, and try to ensure to the possible extend backwards compatibility to existing RMON MIBs?

Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Shailaja Yadawad
Sent: 18 March, 2004 12:40 PM
To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt

Dan,

>What I am seeing are mechanisms like RMON alarm and usrHistory being reinvented, and >objects like ituSeverity from the Alarm MIB being duplicated.

you are correct that our draft contains object definition similar to that of  RMON alarm and usrHistory but with additional features and changes.
 
Regards,
Shailaja.

---

From: "Shailaja Yadawad" <[email-masked]>
Date: Mon, 22 Mar 2004 05:51:33 -0700

Dan
 
>I have read the draft carefully, I think that I understand it better
now, and I appreciate what >you are trying to achieve. I should point
however, that the problems that you are dealing with >have solutions in
other MIB modules, sometimes even multiple solutions as you are yourself
>pointing. An optimization may be a good thing for a certain class of
applications and devices, >but a sound discussion is needed to prove
that this is an important enough problem to deserve >a new piece of
standardization in the IETF.
 
The draft proposal is  trying to solve a important problems associated
with the history collection. 
The user will in most probability will face these problems like
persistent index ( as Andy mentioned) and need for automatic instance
management and easy configurations during history collection activity.
It is my belief that standardization of such features will help users.

>What do you suggest that we do with this? Are you suggesting that we
deprecate the relevant >MIB groups in RMON and RMON-2 and replace them
by new optimized MIB groups on the lines >of your proposal? Or should we
standardize a new method for user history with instance >filtering, and
applying alarms to history with lesser MIB objects in addition to
existing RMON >standards?  
 
I feel that proposed features needs a standardization. As mentioned in
our draft, deprecating the relevant RMON-2 MIB groups will pose a
backward compatibility issue  of previously collected history data to
the user and so creating a new standard is a good idea. 

Regards,
Shailaja.

---

From: "Shailaja Yadawad" <[email-masked]>
Date: Mon, 22 Mar 2004 05:51:33 -0700

Dan

 

Regards,
Shailaja.

---

From: "Shailaja Yadawad" <[email-masked]>
Date: Mon, 22 Mar 2004 05:58:02 -0700

Dan,
 
For a moment I want to focus on getting the WG to understand the need
for standardization of the proposed features.
 
I want to seek WG help in deciding either for the new standard or
extending the existing standard. 
 
Regards,
Shailaja.  

>>> "Romascanu, Dan (Dan)" <[email-masked]> 3/18/2004 7:49:00 PM
>>>

... and this brings exactly the two issues that I am trying to point
to:
as at least a partial solution exists to the problems that your I-D
tries to solve, do the additional functionality and optimizations
justify new standards work? assuming the answer is yes to the above,
should we not consider rather extending the existing RMON design, and
try to ensure to the possible extend backwards compatibility to existing
RMON MIBs? 
Regards,Dan-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Shailaja Yadawad
Sent: 18 March, 2004 12:40 PM
To: Romascanu, Dan (Dan); [email-masked];
[email-masked]
Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt

Dan,

 
Regards,
Shailaja.

---

From: "Shailaja Yadawad" <[email-masked]>
Date: Mon, 22 Mar 2004 05:58:02 -0700

Dan,

 
Regards,
Shailaja.  

Dan,

 
Regards,
Shailaja.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 22 Mar 2004 15:11:39 +0200

... and that's fine with me. At this point the right questions are - I think - on the table, and Andy's answer helped by clarifying the issue of the relationship with the existing RMON MIB modules from the perspective of the RMON WG.
 
Let us see what other people have to say, if they have an opinion.

Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Shailaja Yadawad
Sent: 22 March, 2004 2:58 PM
To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt

Dan,
 
For a moment I want to focus on getting the WG to understand the need for standardization of the proposed features.
 
I want to seek WG help in deciding either for the new standard or extending the existing standard. 
 
Regards,
Shailaja.  

>>> "Romascanu, Dan (Dan)" <[email-masked]> 3/18/2004 7:49:00 PM >>>

Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Shailaja Yadawad
Sent: 18 March, 2004 12:40 PM
To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt

Dan,

 
Regards,
Shailaja.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 22 Mar 2004 15:11:39 +0200

Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Shailaja Yadawad
Sent: 22 March, 2004 2:58 PM
To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt

Dan,

 
Regards,
Shailaja.  

Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Shailaja Yadawad
Sent: 18 March, 2004 12:40 PM
To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt

Dan,

 
Regards,
Shailaja.

---

From: "Shailaja Yadawad" <[email-masked]>
Date: Mon, 22 Mar 2004 06:24:41 -0700

Hi
 
>Since there is substantial overlap in the membership of the two
>working groups, can we confine this discussion to just one of the
>WG lists?  I suggest that we continue discussion on the disman
>list.  If consensus develops that there is a problem to be solved
>along with a general sense  what technical approach we'd like
>to use, then Andy and I could consult with Bert (our Area Director)
>to figure out whether the work would make sense for either working
>group, a new working group, or whatever.

I am fine with this approach. Sorry, I saw this mail now after I posted
my previous mail. Here onwards will confine my mail discussion to disman
WG.

Regards,
Shailaja.

---

From: "Shailaja Yadawad" <[email-masked]>
Date: Tue, 23 Mar 2004 06:27:33 -0700

Andy,
 
Thanks for your reponse.

>IMO, the problem worth addressing in the IETF is the
>detrimental effect of arbitrary renumbering of object
>instance identifiers after a reboot.  This is a general
>problem, not related to DISMAN or RMONMIB.  Perhaps
>some ideas in this draft could be used to solve the
>general problem.

I totally agree with you in that, the persistent indexing is a
requirement of many application and not just history collection.

>Optimizations to the usrHistory group should be done in
>a new MIB module without impacting the existing RMON-2
>conformance.

I am of the opinion that proposed features of our draft certainly are
required in the history collection framework and hence we(WG) need to
work in optimizing the the usrHistory group.

Regards,
Shailaja.

---

From: "Shailaja Yadawad" <[email-masked]>
Date: Tue, 23 Mar 2004 06:27:33 -0700

Andy,
 
Thanks for your reponse.

Regards,
Shailaja.

---

From: "Shailaja Yadawad" <[email-masked]>
Date: Mon, 22 Mar 2004 06:24:41 -0700

Hi

Regards,
Shailaja.