Skip to main content

Application Performance Measurement MIB
draft-ietf-rmonmib-apm-mib-12

Revision differences

Document history

Date Rev. By Action
2015-10-14
12 (System) Notify list changed from  to (None)
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Steven Bellovin
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Ted Hardie
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2004-03-08
12 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2004-03-02
12 (System) RFC published
2003-12-11
12 Amy Vezza IESG state changed to Approved-announcement sent
2003-12-11
12 Amy Vezza IESG has approved the document
2003-12-11
12 Amy Vezza Closed "Approve" ballot
2003-12-11
12 Bert Wijnen State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Bert Wijnen
2003-12-11
12 Bert Wijnen [Note]: 'All issues have been addressed' added by Bert Wijnen
2003-12-11
12 Bert Wijnen Status date has been changed to 2003-12-11 from 2003-11-26
2003-12-08
12 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie
2003-12-01
12 Steven Bellovin [Ballot Position Update] Position for Steve Bellovin has been changed to No Objection from Discuss by Steve Bellovin
2003-11-26
12 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2003-11-26
12 Bert Wijnen [Note]: 'Checking with ADs who raised serious (DISCUSS) issues/concerns.' added by Bert Wijnen
2003-11-26
12 Bert Wijnen
It looks to repsonsible AD (Bert) that issues have been addressed. I am checking with IESG members who
have raised the DISCUSS issues to see …
It looks to repsonsible AD (Bert) that issues have been addressed. I am checking with IESG members who
have raised the DISCUSS issues to see if the new revision does indeed clear those concerns.
2003-11-26
12 Bert Wijnen Status date has been changed to 2003-11-26 from 2003-08-29
2003-10-27
12 (System) New version available: draft-ietf-rmonmib-apm-mib-12.txt
2003-10-02
12 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded by Amy Vezza
2003-10-02
12 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded by Amy Vezza
2003-10-02
12 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded by Amy Vezza
2003-10-02
12 Amy Vezza Removed from agenda for telechat - 2003-10-02 by Amy Vezza
2003-10-02
12 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2003-10-02
12 Ned Freed [Ballot Position Update] New position, No Objection, has been recorded by Ned Freed
2003-10-02
12 Thomas Narten [Ballot Position Update] New position, No Objection, has been recorded by Thomas Narten
2003-10-02
12 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded by Alex Zinin
2003-10-02
12 Jon Peterson
[Ballot comment]
No further objection given Ted's DISCUSS. Considering that the optimal architecture envisioned by the document is one where there is an agent in …
[Ballot comment]
No further objection given Ted's DISCUSS. Considering that the optimal architecture envisioned by the document is one where there is an agent in every enterprise desktop reporting the target and outcome of all network transactions to a centralized server... there do seem to be serious end-user privacy concerns.
2003-10-02
12 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2003-10-02
12 Steven Bellovin
[Ballot discuss]
The Security Considerations should note that too-precise measurements of some cryptographic modules can lead to timing attacks.  See, for example, Boneh and Brumley's …
[Ballot discuss]
The Security Considerations should note that too-precise measurements of some cryptographic modules can lead to timing attacks.  See, for example, Boneh and Brumley's paper "Remote timing attacks are practical" at the 2003 Usenix Security Symposium.

[this can probably be fixed with an RFC Editor's note.]
2003-10-02
12 Steven Bellovin [Ballot Position Update] New position, Discuss, has been recorded by Steve Bellovin
2003-10-01
12 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded by Bill Fenner
2003-10-01
12 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded by Margaret Wasserman
2003-09-30
12 Ted Hardie
[Ballot discuss]
The Security Considerations boilerplate discusses the possibility that the data
may be sensitive in certain network environments, but the implication seems
to be …
[Ballot discuss]
The Security Considerations boilerplate discusses the possibility that the data
may be sensitive in certain network environments, but the implication seems
to be "sensitive to the collector".  TheampNameTable and data associated with
it have *privacy* implications, and these do not seem to be discussed at all.
2003-09-30
12 Ted Hardie
[Ballot comment]
Going through the HTTP example in some detail, I found it hard to understand
how I would use this data in the presence …
[Ballot comment]
Going through the HTTP example in some detail, I found it hard to understand
how I would use this data in the presence of services built on top of HTTP.  The
URL matching algorithm seems designed to allow an administrator to say something
like "maps.cgi?" as a prefix will have a different exception processing than
"zipcode.cgi?".That seems reasonable for exception reporting, for some level
of understanding of the likely inputs.  apmThroughputExceptionMinTime
seems, however, seems likely to obscure more than it reveals, since it makes
a presumption about the "fixed" transaction costs.  The transaction costs
include things like handshake, which are dependent on outside factors and do not
seem to be fixed at all.
2003-09-30
12 Ted Hardie
[Ballot discuss]
The Security Considerations boilerplate discusses the possibility that the data may be sensitive in certain network environments, but the implication seems to be …
[Ballot discuss]
The Security Considerations boilerplate discusses the possibility that the data may be sensitive in certain network environments, but the implication seems to be sensitive to the collector.  The
ampNameTable and data associated with it have *privacy* implications, and these do not seem to be discussed at all.
2003-09-30
12 Ted Hardie [Ballot Position Update] New position, Discuss, has been recorded by Ted Hardie
2003-09-30
12 Russ Housley
[Ballot discuss]
The document includes example server names.  The server names chosen imply something about the kind of service being offered, but then do not …
[Ballot discuss]
The document includes example server names.  The server names chosen imply something about the kind of service being offered, but then do not have the typical "example.com" structure.  I think that company names can be avoided without loosing the message.  For example:

    Amazon  --> www.example.com
    SAP      --> acct.example.com
    HR      --> hr.example.com
    ietf    --> ftp.example.com
    CNN      --> live-action.news.example.com
    Pop3    --> pop3.mail.example.com
    CallCtr  --> call-center.example.com
2003-09-30
12 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2003-09-23
12 Bert Wijnen Add to IESG agenda for October 2nd
2003-09-23
12 Bert Wijnen Placed on agenda for telechat - 2003-10-02 by Bert Wijnen
2003-09-23
12 Bert Wijnen State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Bert Wijnen
2003-09-23
12 Bert Wijnen Ready for IESG Evaluation.
No IETF Last Call comments received.
2003-09-23
12 Bert Wijnen [Ballot Position Update] New position, Yes, has been recorded for Bert Wijnen
2003-09-23
12 Bert Wijnen Ballot has been issued by Bert Wijnen
2003-09-23
12 Bert Wijnen Created "Approve" ballot
2003-09-22
12 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2003-09-02
12 Michael Lee Last call sent
2003-09-02
12 Michael Lee State Changes to In Last Call from Last Call Requested by Michael Lee
2003-08-29
12 Bert Wijnen Last Call was requested by Bert Wijnen
2003-08-29
12 Bert Wijnen State Changes to Last Call Requested from AD Evaluation::Revised ID Needed by Bert Wijnen
2003-08-29
12 (System) Ballot writeup text was added
2003-08-29
12 (System) Last call text was added
2003-08-29
12 (System) Ballot approval text was added
2003-08-29
12 Bert Wijnen Revision 11 addresses all comments and is ready for IETF Last Call.
2003-08-29
12 Bert Wijnen Status date has been changed to 2003-08-29 from 2003-08-28
2003-08-29
11 (System) New version available: draft-ietf-rmonmib-apm-mib-11.txt
2003-08-28
12 Bert Wijnen State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Bert Wijnen
2003-08-28
12 Bert Wijnen WG chair tells me to expect another rev (11).
2003-08-28
12 Bert Wijnen Status date has been changed to 2003-08-28 from 2003-08-20
2003-08-27
12 Bert Wijnen
Several of my AD review questions seemed ignored.
Checking with author and WG chair

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: woensdag 27 augustus 2003 …
Several of my AD review questions seemed ignored.
Checking with author and WG chair

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: woensdag 27 augustus 2003 15:50
To: Steve Waldbusser (E-mail); Andy Bierman (E-mail)
Cc: Wijnen, Bert (Bert)
Subject: RE: [RMONMIB] AD review of: draft-ietf-rmonmib-apm-mib-07.txt


So I won't bring this to the WG list, at least not for now.
I see the questions below (from way back in december last year)
where sort of ignored and/or never answered as to why they
were ignored (at least I cannot find any answer in my mail
archive... so pls resend if there is/was one).

Further, it seems there are still old references from the
old MIB Boilerplate that are not needed (and not cited either)
For example references [5], [6], [7], [8], [9], [10], [11], [12]
Not sure about  [15]
                       
Other uncited references: [18] and [19]

I think that ref [17] should be normative, cause you IMPORT from that
one.

Bert

Thanks,
Bert

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: zondag 29 december 2002 16:32
> To: Steve Waldbusser (E-mail); RMON WG (E-mail)
> Subject: [RMONMIB] AD review of: draft-ietf-rmonmib-apm-mib-07.txt
>
.. snip

> The MIB module itself

.. snip ..

> - Would it not be better to use apmMIB instead of just apm ??
>  I think something like xxxMIB is what we use in most MIB modules
> - I wonder if it would not be better to rname AppLocalIndex to
>  ApmAppLocalIndex. Just to make it easier to not cause name conflicts
>  in the future
> - I ownder if ClientID would be better named ApmClientID, this to make
>  it easier to avoid naming conflicts in the future
> - Same for TransactionAggregationType TC
> - Since the AppLocalIndex TC is meant to stay in sync (that is share
>  the same numbering space, if I understand it correctly), would it
>  then not be better to use the same base datatype, i.e. Integer32 ??
> - Is it wise to have ClientID start at zero?
>  This TC is used for objects that function as index for some tables.
>  So I think I would prefer them to start at 1.
> - Would it not make sense to re-use TruthValue for apmAppDirConfig ??
> - in DESCRIPTION clause of: apmAppDirConfig
> - apmHttp4xxIsFailure OBJECT-TYPE
>    DESCRIPTION
>        "When true, this agent will recognize HTTP errors in the range
>        of 400 through 499 and will treat them as unavailable
>        transactions. When false or when this object isn't supported,
>        they will be treated as successful transactions.
>    Why do we have to cater for "isn't supported" ??
> - apmReportControlAggregationType
>  I see that you use a TC for SYNTAX, and all of the DESCRIPTION clause
>  of the TC itself comes back here. I thought that a TC was to put
>  the DESCRITPION (semantics) in one place and not have to repeat them
>  when the TC is used?
> - apmReportControlStatus OBJECT-TYPE
>    SYNTAX      RowStatus
>    MAX-ACCESS  read-create
>    STATUS      current
>    DESCRIPTION
>        "The status of this apmReportControlEntry.
>
>        An entry may not exist in the active state unless all
>        objects in the entry have an appropriate value.
>
>        If this object is not equal to active(1), all
>        associated entries in the apmReportTable shall be deleted
>        by the agent."
>  That last para seems weird to me. I guess you mean to say that
>  apmReportTable entries ought to be deleted if this row gets
>  deleted (destroyed)? Maybe if this row becomes notInservice,
>  or is notReady, then the apmReportEntries should go in same state?
>  Or is it just me who finds this weird?
> - apmExceptionUnsuccessfulException OBJECT-TYPE
>    SYNTAX      INTEGER {
>                    off(1),
>                    on(2)
>                }
>    MAX-ACCESS  read-create
>    STATUS      current
>    DESCRIPTION
>        "If this value is on(2), an exception will be created if a
>        transaction of the associated type is unsuccessful."
>  Could this not be better using TruthValue TC as SYNTAX?
>
2003-08-21
12 Bert Wijnen
AD did send review and WG came up with two more revisons.
WG chair is now asking to consider revision 10 as the one to …
AD did send review and WG came up with two more revisons.
WG chair is now asking to consider revision 10 as the one to be publised as PS>
2003-08-21
12 Bert Wijnen Status date has been changed to 2003-08-20 from 2003-06-03
2003-08-15
10 (System) New version available: draft-ietf-rmonmib-apm-mib-10.txt
2003-07-02
09 (System) New version available: draft-ietf-rmonmib-apm-mib-09.txt
2003-06-03
12 Bert Wijnen New revision was received on March 6.
Slipped through the cracks. Now in AD re-review.
2003-06-03
12 Bert Wijnen Status date has been changed to 2003-06-03 from 2002-12-29
2003-06-03
12 Bert Wijnen State Changes to AD Evaluation from AD is watching  :: Revised ID Needed by Wijnen, Bert
2003-03-06
08 (System) New version available: draft-ietf-rmonmib-apm-mib-08.txt
2003-02-21
12 Bert Wijnen
-----Original Message-----
From: Andy Bierman [mailto:abierman@cisco.com]
Sent: vrijdag 21 februari 2003 19:59
To: Wijnen, Bert (Bert)
Subject: RE: [RMONMIB] AD review of: draft-ietf-rmonmib-apm-mib-07.txt …
-----Original Message-----
From: Andy Bierman [mailto:abierman@cisco.com]
Sent: vrijdag 21 februari 2003 19:59
To: Wijnen, Bert (Bert)
Subject: RE: [RMONMIB] AD review of: draft-ietf-rmonmib-apm-mib-07.txt


At 07:55 PM 2/21/2003 +0100, Wijnen, Bert (Bert) wrote:
>Have not seen any follow up yet, while my comments were posted
>at the end of december,,,, so close to 2 months ago.
>
>Did I miss anything here?

I've asked Steve about 5 times to get an update done.
He said he would do this before the I-D cutoff.

>Thanks,
>Bert

Andy
2002-12-29
12 Bert Wijnen State Changes to AD is watching  :: Revised ID Needed from AD is watching  :: Point Raised - writeup needed by Wijnen, Bert
2002-12-29
12 Bert Wijnen Today I did send an extensive AD review to the WG mailing list. A new revision is expected.
2002-12-29
12 Bert Wijnen Status date has been changed to 2002-12-29 from 2002-12-28
2002-12-29
12 Bert Wijnen State Changes to AD is watching  :: Point Raised - writeup needed from AD is watching by Wijnen, Bert
2002-12-28
12 Bert Wijnen
Andy (WG chair) asked for AD to consider as PS.
Seems though that the request was never copied to iesg-secretary, and so doc did not …
Andy (WG chair) asked for AD to consider as PS.
Seems though that the request was never copied to iesg-secretary, and so doc did not show up under AD-to-do items.

Document has MIB SYNTAX/compile issues that need to be fixed (as agreed with Andy, WG chair).

AD is reviewing so that review changes can be done at same time.
2002-12-28
12 Bert Wijnen Draft Added by Wijnen, Bert
2002-04-30
07 (System) New version available: draft-ietf-rmonmib-apm-mib-07.txt
2002-03-06
06 (System) New version available: draft-ietf-rmonmib-apm-mib-06.txt
2001-11-06
05 (System) New version available: draft-ietf-rmonmib-apm-mib-05.txt
2001-07-25
04 (System) New version available: draft-ietf-rmonmib-apm-mib-04.txt
2001-03-07
03 (System) New version available: draft-ietf-rmonmib-apm-mib-03.txt
2000-11-30
02 (System) New version available: draft-ietf-rmonmib-apm-mib-02.txt
2000-07-21
01 (System) New version available: draft-ietf-rmonmib-apm-mib-01.txt
2000-05-09
00 (System) New version available: draft-ietf-rmonmib-apm-mib-00.txt