A Proposed Media Delivery Index (MDI)
RFC 4445

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: RFC Editor <rfc-editor@rfc-editor.org>
Cc: The IESG <iesg@ietf.org>, <iana@iana.org>, ietf-announce@ietf.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).