Subject: [AVT] Comments on draft-ietf-avt-rtcp-xr-mib-00.txt

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 4 Nov 2004 11:44:35 +0200

I apologize if you get this twice, but my first message did not seem to make it to the list. 

Please find below a set of comments to the latest RTCP XR MIB. It's a progress relative to the previous version, but there also is a way to go until the document can be proposed for WGLC. One basic issue is that the MIB does not yet compile. I did not comment on all syntax problems, but I hope I caught many of the obvious ones. I suggest to the authors to bring the MIB to a correctly compiled state prior to the submission of the next version. 

Regards,

Dan

1. There are a lot of useless references in the document, including some relating to historical versions of the SNMP protocol. See http://www.ops.ietf.org/mib-boilerplate.html for the minimal and sufficient list of SNMP related references
2. The Overview section speaks about an "RTP System", but RTP is not expanded or explained prior to this occurrence.
3. At the last IETF meeting we discussed about the relationship between RTCP XR MIB and RAQMON, and decided to include a 'Relationship to RAQMON' section, which is now only a place-holder. I suggested to the editors the following text:
'The Real-time Application QoS monitoring (RAQMON) Framework [RAQMON-FRAMEWORK - provide reference here to <http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-framework-07.txt>] defines an architecture that extends the Remote Monitoring (RMON) family of applications for monitoring of application QoS in real-time, and an extensible data model with objects carried between RAQMON data sources and RAQMON collectors. The RAQMON work is more generic, and complementary in concept to RTCP-XR, covering a wider range of applications running concurrently, while RTCP-XR focuses on QoS monitoring of media traffic in VoIP. 
The Real-time Application QoS Monitoring (RAQMON) MIB is defined by [RAQMON-MIB - provide reference here to <http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-mib-05.txt>] and runs on RAQMON collectors. A more comprehensive performance monitoring application may query both RAQMON collectors for RAQMON MIB information about the QoS parameters of multiple concurrent applications and end-points and gateways for RTCP-XR information about the media QoS of VoIP.'
4. paragraph 2.2.3 - it is not clear what case is being presented here. How in the RTCP XR architecture does a host system acquire information about streams beyond what they are sending and receiving? 
5. Gathering all monitoring objects in one single table may not be a good idea. A table imposes grouping all objects in the same compliance group. I believe some low-cost implementation may chose to implement only part of the objects, and still claim compliance. I suggest that you consider splitting into two or more tables. 
6. While a MIB module is under development, the RFC number in which it will eventually be published is usually unknown and must be filled in by the RFC Editor prior to publication. An appropriate form for the REVISION clause applying to a version under development would be something along the following lines:
 REVISION "200212132358Z" -- December 13, 2002 
DESCRIPTION "Initial version, published as RFC yyyy." 
-- RFC Ed.: replace yyyy with actual RFC number & remove this note 
7. The comment in 2.3 about row creation seems to be out of context. There is no row creation in this MIB, as far as I understand
8. The DESCRIPTION clause of rtcpXrVoipEntry includes the following: 'A row in this table  is created for each RTP session endpoint participating.'. This is both broken syntax, as well as it seems to be in conflict with the passive monitoring concept. 
9. STATUS 'optional' is not valid in SMIv2. This needs to be fixed by using compliance clauses
10. MAX-ACCESS clauses are missing
11. Need to use REFERENCE clauses rather than referring to references in the DESCRIPTION clauses
12. Need to define Notifications rather than traps
13. CONTACT_INFO is missing in the MIB
14. Need to define compliance clauses
15. rtcpXrVoipEntry in the TABLE definition needs to be capitalized
16. There are many instances where INTEGER is used instead of Integer32 (SMIv1 left-overs)
17. rtcpXrVoipCallIdentifier - why is this an OCTET STRING? what is the size?
18. rtcpXrVoipCallIdentifier - how is this object defined? Is there a RFC 3611 reference? why an OBJECT STRING? what is the size? 
19. rtcpXrVoipSourceIPaddress and rtcpXrVoipDestinationIPaddress - using an OCTET STRING for IP addresses is NOT RECOMMENDED. InetAddressType and InetAddress TCs should be used
20. rtcpXrVoipSourceIdentifier - seems to be a SnmpAdminString syntax
21. Missing IANA Considerations section

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Alan Clark" <[email-masked]>
Date: Thu, 4 Nov 2004 06:32:44 -0500

Comments on draft-ietf-avt-rtcp-xr-mib-00.txtDan

Thanks for your comments - we are hoping to get a small group together next
week to edit the document and have been saving comments - I hope than you
can join us?

Regards

Alan
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
Romascanu, Dan (Dan)
  Sent: Thursday, November 04, 2004 4:45 AM
  To: [email-masked]
  Subject: [AVT] Comments on draft-ietf-avt-rtcp-xr-mib-00.txt

  I apologize if you get this twice, but my first message did not seem to
make it to the list.

  Please find below a set of comments to the latest RTCP XR MIB. It's a
progress relative to the previous version, but there also is a way to go
until the document can be proposed for WGLC. One basic issue is that the MIB
does not yet compile. I did not comment on all syntax problems, but I hope I
caught many of the obvious ones. I suggest to the authors to bring the MIB
to a correctly compiled state prior to the submission of the next version.

  Regards,

  Dan

  1. There are a lot of useless references in the document, including some
relating to historical versions of the SNMP protocol. See
http://www.ops.ietf.org/mib-boilerplate.html for the minimal and sufficient
list of SNMP related references

  2. The Overview section speaks about an "RTP System", but RTP is not
expanded or explained prior to this occurrence.

  3. At the last IETF meeting we discussed about the relationship between
RTCP XR MIB and RAQMON, and decided to include a 'Relationship to RAQMON'
section, which is now only a place-holder. I suggested to the editors the
following text:

  'The Real-time Application QoS monitoring (RAQMON) Framework
[RAQMON-FRAMEWORK - provide reference here to
<http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-framework-07.
txt>] defines an architecture that extends the Remote Monitoring (RMON)
family of applications for monitoring of application QoS in real-time, and
an extensible data model with objects carried between RAQMON data sources
and RAQMON collectors. The RAQMON work is more generic, and complementary in
concept to RTCP-XR, covering a wider range of applications running
concurrently, while RTCP-XR focuses on QoS monitoring of media traffic in
VoIP.

  The Real-time Application QoS Monitoring (RAQMON) MIB is defined by
[RAQMON-MIB - provide reference here to
<http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-mib-05.txt>]
and runs on RAQMON collectors. A more comprehensive performance monitoring
application may query both RAQMON collectors for RAQMON MIB information
about the QoS parameters of multiple concurrent applications and end-points
and gateways for RTCP-XR information about the media QoS of VoIP.'

  4. paragraph 2.2.3 - it is not clear what case is being presented here.
How in the RTCP XR architecture does a host system acquire information about
streams beyond what they are sending and receiving?

  5. Gathering all monitoring objects in one single table may not be a good
idea. A table imposes grouping all objects in the same compliance group. I
believe some low-cost implementation may chose to implement only part of the
objects, and still claim compliance. I suggest that you consider splitting
into two or more tables.

  6. While a MIB module is under development, the RFC number in which it
will eventually be published is usually unknown and must be filled in by the
RFC Editor prior to publication. An appropriate form for the REVISION clause
applying to a version under development would be something along the
following lines:

  7. The comment in 2.3 about row creation seems to be out of context. There
is no row creation in this MIB, as far as I understand

  8. The DESCRIPTION clause of rtcpXrVoipEntry includes the following: 'A
row in this table  is created for each RTP session endpoint participating.'.
This is both broken syntax, as well as it seems to be in conflict with the
passive monitoring concept.

  9. STATUS 'optional' is not valid in SMIv2. This needs to be fixed by
using compliance clauses

  11. Need to use REFERENCE clauses rather than referring to references in
the DESCRIPTION clauses

  16. There are many instances where INTEGER is used instead of Integer32
(SMIv1 left-overs)

  17. rtcpXrVoipCallIdentifier - why is this an OCTET STRING? what is the
size?

  18. rtcpXrVoipCallIdentifier - how is this object defined? Is there a RFC
3611 reference? why an OBJECT STRING? what is the size?

  19. rtcpXrVoipSourceIPaddress and rtcpXrVoipDestinationIPaddress - using
an OCTET STRING for IP addresses is NOT RECOMMENDED. InetAddressType and
InetAddress TCs should be used

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 05 Nov 2004 13:56:30 +0100

Hi Dan,

I have a comment on the below.

Romascanu, Dan (Dan) wrote:
> RTCP XR MIB and RAQMON, and decided to include a 'Relationship to 
> RAQMON' section, which is now only a place-holder. I suggested to the 
> editors the following text:
> 
> */'The Real-time Application QoS monitoring (RAQMON) Framework 
> [RAQMON-FRAMEWORK - provide reference here to_ 
> <http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-framework-07.txt>_] 
> defines an architecture that extends the Remote Monitoring (RMON) family 
> of applications for monitoring of application QoS in real-time, and an 
> extensible data model with objects carried between RAQMON data sources 
> and RAQMON collectors. The RAQMON work is more generic, and 
> complementary in concept to RTCP-XR, covering a wider range of 
> applications running concurrently, while RTCP-XR focuses on QoS 
> monitoring of media traffic in VoIP./*//

Although one of the RTCP XR types has received substantially more 
interest, the RTCP XR is not limited to VoIP. It is a general framework 
which is currently populated with the following different reporting blocks:
        4.1.  Loss RLE Report Block. . . . . . . . . . . . . . . . . .  9
        4.2.  Duplicate RLE Report Block . . . . . . . . . . . . . . . 16
        4.3.  Packet Receipt Times Report Block. . . . . . . . . . . . 18
        4.4.  Receiver Reference Time Report Block . . . . . . . . . . 20
        4.5.  DLRR Report Block. . . . . . . . . . . . . . . . . . . . 21
        4.6.  Statistics Summary Report Block. . . . . . . . . . . . . 22
        4.7.  VoIP Metrics Report Block. . . . . . . . . . . . . . . . 25

Thus, I can also provide some more comments of the document:

MW1: The XR MIB needs to be defined in such a way that it can easily be 
extended if more report types are created.

MW2: THE XR MIB should define structures for all the currently defined 
XR report blocks.

MW3: The security consideration section also seems to be a bit strange, 
is it mostly copy and pasted from the RTP MIB?

MW4: rtcpXrVoipSessionIdentifier OBJECT-TYPE
     SYNTAX OCTET STRING
     STATUS optional
     DESCRIPTION
         "Unique identifier for this session.  Where a billing record
          correlation identifer is not available for a particular call,
          another identifier such as SSRC can be used."
     ::= { rtcpXrVoipEntry 3 }

How can the SSRC be a session identifier?

MW5: How is sessions with more than a single destination handled?

MW6: rtcpXrVoipVocoderType OBJECT-TYPE
     SYNTAX OCTET STRING
     STATUS current
     DESCRIPTION
         "Vocoder type used on this call."
     ::= { rtcpXrVoipEntry 10 }

rtcpXrVoipFrameSize OBJECT-TYPE
     SYNTAX INTEGER
     STATUS current
     DESCRIPTION
         "Companion information to vocoder type.  This represents the
          size of the frames within the RTP packets at the time the
          information is capture."
     ::= { rtcpXrVoipEntry 11 }

First, is multiple instances allowed? A session may consist of multiple 
media codecs and/or configurations of a codec. Also how is the vocoder 
type expressed. What is the string? The RTP payload MIME type with its 
parameters? Maybe one should consider to make this definition a bit more 
generic to fit any media encoding format? Thus it can potentially be 
re-used?

MW7: rtcpXrVoipSampleRate OBJECT-TYPE
     SYNTAX OCTET STRING
     STATUS current
     DESCRIPTION
         "Companion information to vocoder type.  This represents the
          rate at which the frames where sampled.
     ::= { rtcpXrVoipEntry 12 }

Which rate are you talking about here? The audio sample rate, or the 
rate with which frames are produced?

MW8: All references can not be normative, a lot of these must be 
informative ones.

MW9: Run a spellchecker over the description texts.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]