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

Request Review of draft-ietf-avtcore-idms
Requested rev. no specific revision (document currently at 13)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-06-11
Requested 2013-05-30
Draft last updated 2013-06-06
Completed reviews Genart Last Call review of -09 by Dan Romascanu (diff)
Secdir Last Call review of -09 by Vincent Roca (diff)
Assignment Reviewer Dan Romascanu
State Completed
Review review-ietf-avtcore-idms-09-genart-lc-romascanu-2013-06-06
Reviewed rev. 09 (document currently at 13)
Review result Not Ready
Review completed: 2013-06-06

Review
review-ietf-avtcore-idms-09-genart-lc-romascanu-2013-06-06

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