Last Call Review of draft-ietf-avtcore-idms-09
review-ietf-avtcore-idms-09-genart-lc-romascanu-2013-06-06-00

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may
receive.

Document: draft-ietf-avtcore-idms-09
Reviewer: Dan Romascanu
Review Date: 6/6/13
IETF LC End Date: 6/11/13
IESG Telechat date:

Summary:

Not Ready

Major issues:

1. This document is tightly connected with the ETSI specification TS 183 063.
However this relation is mentioned only in a couple of places and does not
describe the complexity of the relation. Moreover, the relation itself seems
problematic.

The I-D uses some of the inter-destination media techniques described by ETSI
TS 183 063. For example Section 7 replicates part of the content of Annex W of
the ETSI document. It does it partially however, and with some modifications,
as only the content definition and behavior of the transmitters and receivers
for SPST=1 were taken from Annex W, while the content and behavior for SPST=2-4
are marked as 'defined by ETSI TISPAN'. The ETSI document details what happens
with the fields when SPST=2-4. This will result in the RTCP XR block for IDMS
to be defined in two places - part in this IETF document (if approved), the
rest in the ETSI document (to be modified accordingly in the future). For some
period of time the same fields will be defined in two places. This seems broken.

2. The note to the RFC Editor in section 14.2 states:

   14.2.  RTCP XR IDMS Report Block

   This document assigns the block type value 12 in the IANA "RTCP XR
   Block Type Registry" to the RTCP XR IDMS Report Block.

   [Note to RFC Editor: this block type value is currently assigned to
   [TS183063].  This document replaces [TS183063] as the normative
   specification of the RTCP XR IDMS Report Block.  Upon publication of
   this document as RFC, [TS183063] will be changed to reflect this.

The first statement is not accurate. Value 12 is not a new assignment, 12 was
already assigned by ETSI, this document asks to change the assignment of value
12 from the RTCP XR Block Type for reporting IDMS information to the IETF
defined RTCP XR IDMS Report Block. This change is however partial as described
previously, as the content of the fields and behavior for SPST = 2-4 remain
under ETSI control. Moreover, it is not clear who has further control for other
new values, as SPST = 5-15 show as 'reserved for future use in both documents'.
The IANA section does not define or refer an IANA registry and the policy for
adding and approving new values for SPST.

This solution is not clean. Only one organization should have control upon the
definition of one single RTCP XR block type. Either the IETF should make the
overleaping parts of the  document Informational and reflect the content of the
ETSI document, or should take control over the whole block.

3. The relation with the ETSI specification TS 183 063 should have been
described clearly from the beginning of the document.

Minor issues:

1. The version of the block definition is set to V=2 which is the same as in
the ETSI specification. Were versions 0 and 1 already used by ETSI? If this is
the case a note should be made.

2. In Section 7:

   Reserved bits (Resrv): 3 bits.  These bits are reserved for future
   definition.  In the absence of such a definition, the bits in this
   field MUST be set to zero and MUST be ignored by the receiver.

s/MUST be set to zero/MUST be set to zero at transmission/

3. In Section 7:

   Reserved bits (Resrv): 25 bits.  These bits are reserved for future
   use and SHALL be set to 0.

s/ SHALL be set to 0/ MUST be set to zero at transmission and MUST be ignored
by the receiver/

4. In Section 7:

   When
   reporting on an RTP packet which is one of several consecutive RTP
   packets having equal timestamps, an SC SHOULD report on the RTP
   packet it received with the lowest sequence number.

Why a SHOULD here and not a MUST? If there are any cases of exception they need
to be detailed.

5. In Section 8:

   Because RTP
   timestamps do wrap around, the sender of this packet SHOULD use
   recent values, i.e. choose NTP timestamps that reflect current time
   and not too far in the future or in the past.

Why a SHOULD here and not a MUST? If there are any cases of exception they need
to be detailed.

6. In Section 8:

   This SHOULD relate to the first
   arriving RTP packet containing this particular RTP timestamp, in case
   multiple RTP packets contain the same RTP timestamp.

Why a SHOULD here and not a MUST? If there are any cases of exception they need
to be detailed.

7. In Section 8:

   The timestamp is formatted based on the NTP
   timestamp format as specified in [RFC5905].  If this field is empty,
   then it SHALL be set to 0.  This field MAY be left empty if none or
   only one of the receivers reported on presentation timestamps.

Why a MAY here? Especially for the case when none of the receivers reported,
what content can be set there but 0 ?

8: The reference:

[TS183063]
              "IMS-based IPTV stage 3 specification, TS 183 063 v3.4.1",
              June 2010.

V3.4.1 is not the latest release. Is this intentional? I found at least one
more recent release dated 2011 and numbered 3.5.2 - I do not know if there is
any diff in the relevant content, but pointing to the most updated review seems
appropriate.

9: Did this document undergo an SDP directorate review? If not I believe that
one would be necessary, as a new SDP Attribute is being defined.

Nits/editorial comments:

1. typo in the last paragraph of section 5 - s/nessecary/necessary/

2. in section 8 expand PT as Packet Type

3. typo in the first paragraph of section 11 - s/mutli/multi/

Regards,

Dan