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 avt at ietf.org https://www1.ietf.org/mailman/listinfo/avt