Transport Performance Metrics MIB
draft-ietf-rmonmib-tpm-mib-14

Checking again with Allison.

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Monday, September 06, 2004 17:06
To: 'Allison Mankin (E-mail)'
Cc: 'Andy Bierman (E-mail)'
Subject: RE: TPM-MIB


Another (still friendly :-)) prod/ping.

Thanks, Bert


> -----Original Message-----
> From: Wijnen, Bert (Bert)
> Sent: Thursday, August 26, 2004 21:06
> To: Allison Mankin (E-mail)
> Cc: Andy Bierman (E-mail)
> Subject: RE: TPM-MIB
>
>
> Allison, I hope this did not fall through the cracks!?
>
> Thanks, Bert
>
>
> > -----Original Message-----
> > From: Wijnen, Bert (Bert)
> > Sent: Friday, August 20, 2004 16:52
> > To: Allison Mankin (E-mail)
> > Cc: Andy Bierman (E-mail)
> > Subject: FW: TPM-MIB
> >
> >
> > Allison, some feedback from Andy, wg-chair of the RMONMIB WG
> >
> > What do you say?
> >
> > Thanks, Bert
> >
> >
> > -----Original Message-----
> > From: Andy Bierman [mailto:abierman@cisco.com]
> > Sent: Friday, August 20, 2004 16:40
> > To: Wijnen, Bert (Bert)
> > Cc: Bert Wijnen
> > Subject: RE: TPM-MIB
> >
> >
> > At 03:48 PM 8/19/2004, Wijnen, Bert (Bert) wrote:
> > >I am still discussing this with Allison.
> > >
> > >She wonders how there can be interoperable implementations
> > of this MIB
> > >module if we do not make the IPPM registry a normative
> reference and
> > >explicit text that that registry needs to be used.
> >
> > This is a gray area.
> > The registry holds OIDs which represent a registration
> > from some SDO or vendor.  This includes but is not limited
> > to IPPM metrics. 
> >
> > I suppose there is implicit normative text that an implementation
> > MAY include IPPM metrics.  The issue is whether we should have
> > explicit normative text that says MUST or SHOULD include
> IPPM metrics.
> > If so, then a normative reference is in order.  The WG never
> > really addressed this issue.  We assume that the most useful
> > metrics will get used, and these may change over time.
> >
> > I am nervous about locking into a specific set of metrics,
> > which is a potentially unstable snapshot of the IPPM WG
> > output at some point in time.  We need to think carefully
> > about this normative reference.
> >
> > thanks,
> > Andy
> >
> >
> >
> > >I will have more interactions with her later (hopefully
> > tomorrow Friday).
> > >If you have suggestion on how to resolve, pls let me know.
> > >
> > >Thanks, Bert
> > >
> > >
> > >> -----Original Message-----
> > >> From: Andy Bierman [mailto:abierman@cisco.com]
> > >> Sent: Friday, August 20, 2004 00:17
> > >> To: Bert Wijnen
> > >> Subject: TPM-MIB
> > >>
> > >>
> > >> Hi Bert,
> > >>
> > >> It looks like there is an AD Discuss related to the IPPM Registry.
> > >> Is this just a missing normative reference or something more?
> > >>
> > >> thanks,
> > >> Andy
> > >>
> >
>

New revision was submitted july 2nd, but sofar has not shown up in the I-D repository. Seems that new rev (14) does address all discusses. It compiles clean. Checking with ietf secretariat and author why the submission did not get posted in the repository.

[Ballot comment]
The uses of transport and transaction are not careful.
There's nothing in this MIB that affects its applicability to a
transaction-oriented or a bulk-transport-oriented transport
protocol metric.

I think they inherited verbiage from the APM which did care
about transactions.

[Ballot discuss]
This Discuss is a superset of Russ's - the draft should normatively reference
draft-ietf-ippm-metrics-registry, which is in AD Evaluation, and which registers
the IETF's OIDs for the tmpMetricDefTable. 

        The tpmMetricDefTable describes the metrics
        available to the TPM-MIB.  The tpmMetricDefTable
        defines metrics by referencing existing IETF,
        ITU and other standards organizations' documents
        This table contains one row per metric supported by this
        agent, and should be populated during system
        initialization

In the IPPM draft, we still have some confusion (which Chairs and I have discussed
with Bert) about how other standards bodies register OIDs usefully.  It seems
like there should be an IANA Considerations here and in the IPPM draft that
says a Specification Required, because the OID needs to be imported by the
MIBs using it.  Is that right? 

An IANA Considerations section is needed for p.14, at least.

The IPPM WG should look at this document.  I think it's a candidate for their
reporting MIB milestone, instead of the problem draft they have.  It has interesting
statistics.

[Ballot discuss]
This Discuss is a superset of Russ's:

        The tpmMetricDefTable describes the metrics
        available to the TPM-MIB.  The tpmMetricDefTable
        defines metrics by referencing existing IETF,
        ITU and other standards organizations' documents
        This table contains one row per metric supported by this
        agent, and should be populated during system
        initialization

draft-ietf-ippm-metric-registry registers the OIDs for IETF's metrics, and it is
in AD Evaluation (I'm just sorting out its language about other standards bodies).
What should this draft (and that one) say about  how other standards bodies
register OIDs for metrics?  Specification Required (they write a MIB-formed OID
to be imported?).  Now this document needs to reference the ippm draft
normatively, I think.  Does it also need to import the registry?

An IANA Considerations section is needed for p.14, at least.

The IPPM WG should look at this document.  I think it's a candidate for their
reporting MIB milestone.

[Ballot discuss]
This Discuss is a superset of Russ's (he can probably remove his):

        The tpmMetricDefTable describes the metrics
        available to the TPM-MIB.  The tpmMetricDefTable
        defines metrics by referencing existing IETF,
        ITU and other standards organizations' documents
        This table contains one row per metric supported by this
        agent, and should be populated during system
        initialization

draft-ietf-ippm-metric-registry registers the OIDs for IETF's metrics, and it is
in AD Evaluation (I'm just sorting out its language about other standards bodies).
What should this draft (and that one) say about  how other standards bodies
register OIDs for metrics?  Specification Required (they write a MIB-formed OID
to be imported?).  Now this document needs to reference the ippm draft
normatively, I think.  Does it also need to import the registry?

An IANA Considerations section is needed for p.14, at least.

The IPPM WG should look at this document.  I think it's a candidate for their
reporting MIB milestone.

[Ballot discuss]
In this text:


tpmMetricDefReference OBJECT-TYPE
    SYNTAX      SnmpAdminString
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "This object contains a reference to the document which
        defines this metric. If this document is available online
        via electronic download, then a URL should be specified in
        this object.

        For example, if this tpmMetricDefEntry identified the IPPM
        metric 'Type-P-Round-Trip-Delay', then this object should
        contain the value, e.g.,
        'http://www.ietf.org/rfc/rfc2681.txt'."
    ::= { tpmMetricDefEntry 5 }

the document recommends that a URL should be specified for this
object.  It seems likely that they wanted to specify an HTTP URI,
rather than generically allowing any URI type to be used here
(though they may have intended that HTTP, FTP, and some
additional types be named).  There are some URI types which may
not be appropriate here.  Naming the URI schemes which are allowed
would improve interoperability; if the document does not name the
schemes which are allowed, it should explicitly point out the risks
of including URIs which may not be dereferencable.

[Ballot discuss]
The Abstract says:
  >
  > The metrics are defined through reference to existing IETF, ITU and
  > other standards organizations' documents.
  >
  And then, Section 3 says:
  >
  > The TPM-MIB provides a capability to describe metrics by reference
  > to appropriate IETF, ITU or other standards defining metrics.
  >
  Yet, all of the references are to RFCs.  I would think that informative
  references to any that have already been defined are needed.  Are any
  tpmMetricDefinitionID values mandatory-to-support?

Checking with WG chair and authors about:

I note that Carl has changed email address.

In TPM MIB and SSPM
- I see reference to RFC1903, should be RFC2579
- I see reference to RFC2571, should be RFC3411

In fact 3411 and 2579 are listed in references section, so just
take the otehr two out and make sure that citations in text
are corrected to point to new RFCs.

These are not new guys, RFC2579 and 3411 have been around for a
YEAR or more now!

In SSPM I see reference to RFC2063, which ahs been obsoleted by RFC2722
And a reference to RFC2064, whcih has been obsoleted by RFC2720
And a reference to RFC2592, which ahs been obsoleted by RFC3165

Now.. just before putting it on IESG agenda, I try to do
a last SYNTAX compile check. Results:

  W: f(spm.mi2), (470,20) Item "sspmSourceProfileParameter" should have SIZE specified

Probably best to limit to 64K or less!!

  E: f(tpm.mi2), (24,5) Item "ClientID" not defined in module "APM-MIB"
  E: f(tpm.mi2), (987,17) Item "ClientID" is not known in current module
  E: f(tpm.mi2), (987,17) In defining "tpmAggrReportApmNameClientID", syntax name
    "ClientID" is not known
  E: f(tpm.mi2), (1338,17) Item "ClientID" is not known in current module
  E: f(tpm.mi2), (1338,17) In defining "tpmCurReportApmNameClientID", syntax name
    "ClientID" is not known
  E: f(tpm.mi2), (913,44) Item "ClientID" is not known in current module
  E: f(tpm.mi2), (1295,45) Item "ClientID" is not known in current module

The ClientID was changed in APM-MIB to RmonClientID
This happened back in August in draft-ietf-rmonmib-apm-mib-11.txt
So you should/could have seen/know as members of the rmonmib WG

  W: f(tpm.mi2), (902,13) Row "tpmAggrReportEntry" does not have a consistent
    indexing scheme - index item protocolDirLocalIndex from base row
    protocolDirEntry is not defined as an index item
  W: f(tpm.mi2), (1284,13) Row "tpmCurReportEntry" does not have a consistent
    indexing scheme - index item protocolDirLocalIndex from base row
    protocolDirEntry is not defined as an index item
I may have asked this before. It is probably OK, but I do like
positive acknowledgement that it indeed is OK.
I would go dig in my email archives if this were the only issue,
but since I need other asnwers as well...

  E: f(tpm.mi2), (1776,16) Item "apmReportGroup" should be IMPORTed
  E: f(tpm.mi2), (1777,16) Item "apmExceptionGroup" should be IMPORTed
  E: f(tpm.mi2), (1814,15) Item "apmReportGroup" is not defined in module "TPM-MIB"
  E: f(tpm.mi2), (1815,15) Item "apmExceptionGroup" is not defined in module "TPM-MIB"

I believe that we now agree that we indeed prefer to import.

I also wonder (not sure if I ever listed this before) about:
    tpmApmMIBCompliance MODULE-COMPLIANCE
        STATUS  current
        DESCRIPTION
            "This compliance statement defines the
            following APM-MIB optional groups in order
            for the TPM-MIB to be used in drill-down
            support of the APM-MIB measurements:

            - apmReportGroup (optional)
            - apmExceptionGroup (optional)

            Further, if the tpmCurrentReportsGroup
            and the tpmExcpReportsGroup are to be
            implemented, then these APM-MIB groups
            are necessary."
        MODULE  APM-MIB
        MANDATORY-GROUPS
            { apmReportGroup,
              apmExceptionGroup  }
        ::= { tpmMIBCompliances 2 }

So in the DESCRIPTION clause it claims that these 2 groups are
optional and then it lists them as MANDATORY GROUPS !!??


Thanks,
Bert

AD review comments have been posted to WG mailing list today (far to late of course, appologies). A new revision is expected to address all the comment raised.