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

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.

[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.

[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.]

[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.

[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.

[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.

[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

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

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>

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

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.