A Proposed Media Delivery Index (MDI)
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: RFC Editor <email@example.com> Cc: The IESG <firstname.lastname@example.org>, <email@example.com>, firstname.lastname@example.org Subject: Re: Informational RFC to be: draft-welch-mdi-04.txt The IESG has no problem with the publication of 'A Proposed Media Delivery Index' <draft-welch-mdi-04.txt> as an Informational RFC. The IESG would also like the IRSG or RFC-Editor to review the comments in the datatracker (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12192&rfc_flag=0) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. The IESG contact person is Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-welch-mdi-04.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary
Technical Summary This memo defines a Media Delivery Index (MDI) measurement which can be used as a diagnostic tool or a quality indicator for monitoring a network intended to deliver applications such as streaming media MPEG video and Voice over IP or other arrival time and packet loss sensitive information. It provides an indication of traffic jitter, a measure of deviation from nominal flow rates, and a data loss at-a- glance measure for a particular flow. For instance, the MDI may be used as a reference in characterizing and comparing networks carrying UDP streaming media. Included is a set of managed objects for SNMP- based management of IP media streams for which an MDI measurement is obtained. The Media Delivery Index measurement and MIB defined in this memo is intended for Information only. Working Group Summary This document is not the product of a current IETF WG. So the AD review concentrated on checking for conflict/overlap. Allison and I did check with people (Magnus Westerlund and Dan Romascanu) who are active in AVT, RMONMIB and related WGs and technology. In AVT WG this work seem very similar to what has been done in RFC 3611 (RTCP XR). The metrics are slightly different but most of the information could probably be determined using the appropriate RTCP XR reports. There is ongoing work in AVT to define a MIB for these measurements. There are also a proposal to update and possibly extend these RTCP XR measurements to include also Video measurements in addition to the general and VoIP metrics that exist, see draft-ietf-avt-rtcpxr-bis-00.txt which expired this month. In terms of Metrics, the document seems to possibly be underspecifying metrics, and it seems that Metrics definition work might benefit from work that has already been done in IPPM WG. In the MIB module, there is at least one object duplicating information from another standard MIB modules ipMediaStreamBitRate has similar semantics with ifSpeed from RFC 2863. Protocol Quality When reviewing for possible conflict/overlap with current IETF work, it was also noted that there are (serious) MIB issues (a Comment has been recorded by Bert in the I-D tracker, suggesting that the MIB be reviewed against the MIB review guidelines, that it be checked for valid/proper SYNTAX and that it be made complete, all before publication as RFC). There were also concerns if this spec is written well enough. The metrics are under-defined. It seems impossible to implement these metrics as their definitions are to unspecific. Measuring periods are missing, quantization, etc. Note to RFC Editor From RFC 3932 section 3, bullet 2. The IESG thinks that this work is related to IETF work done in the AVT and IPPM WGs, but this does not prevent publishing. Please add the IESG Note (see below) on the front page. Please also look at the COMMENTs recorded in the I-D tracker, because there are serious technical issues that you may want to discuss with the author/submitter and that you probably want to be fixed before publication. IESG Note This RFC is not a candidate for any level of Internet Standard. There are IETF standards which are highly applicable to the space defined by this document as its applicability, in particular, RFCs 3393 and 3611, and there is ongoing IETF work in these areas as well. The IETF also notes that the decision to publish this RFC is not based on IETF review for such things as security, congestion control, MIB fitness, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information. IANA Note IANA probably has to assign a OID to the MIB module (once it is fixed) so that it can be compiled. It should not be an OID under mib-2. Under experimental would be fine, or under the submitters vendor ID would be fine (in which case the submitter should do so, and IANA/RFC-Editor only need to verify the proper vendor ID (i.e. OID under enterprises) is used).