Hi Dan, Many thanks for your very thorough review.
Before responding to your comments in detail, let me give you some background on how we handle the relationship with the ETSI document: Exactly how we should deal with the existing ETSI spec has been discussed at length in AVTCORE, both on- and offlist. As you can see in the earlier versions of the draft, the document used to extend the ETSI document, referencing it where necessary and including sections that describe this relationship. In the end, the WG consensus was that the IETF draft should be the normative spec for the XR block and AVTCORE should have full change control over it. We therefore removed most references to the ETSI spec, and instead started a Work Item in ETSI to change TS 183 063 to point to the IETF draft and remove all normative statements (apart from extending the IETF-defined block with three new SPST values). The current idea is therefore that since the ETSI spec will be referencing the IETF spec, instead of the other way around, that there is no need to describe this relationship in the IETF draft. The IETF spec is the normative 'base' spec, and ETSI is just describing a way to use it within an IPTV system, including three additional SPST values specific to that scenario. Personally, I agree with the WG consensus that this is the 'cleanest' way to handle it, resulting in backwards compatibility with older versions of the ETSI document as well as have full change control in IETF. Please see inline for your comments. Best regards, Ray -----Original Message----- From: Romascanu, Dan (Dan) [mailto:[email protected]] Sent: zondag 9 juni 2013 9:53 To: General Area Review Team Cc: [email protected] Subject: Gen-ART review of draft-ietf-avtcore-idms-09 (resending, I mis-spelled .all address at the first try) 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. [Ray: See my comments above. The ETSI document will be changed to point to the IETF spec. Does this solve your issue? In addition, we could create an IANA registry for SPST values, although I personally believe this to not be necessary] 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. [Ray: Hmm, I'm not sure. I checked with IANA and they don't see a problem in the current wording. I think this is fundamentally a question of describing the 'soll' situation versus describing the process of getting from 'ist' to 'soll'. Once the ETSI doc has been updated, your proposed sentence would no longer be necessary, right?] 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. [Ray: See my earlier comments: IETF will have full control, ETSI will just be extending it.] 3. The relation with the ETSI specification TS 183 063 should have been described clearly from the beginning of the document. [Ray: See my earlier comment. Since the IETF draft will be that normative spec that ETSI will be referencing, I believe this relationship should be described in ETSI, not in IETF]. 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. [Ray: This part of the header is defined by RFC3611, and is specified to be set to 2 to refer to the version of RTP] 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/ [Ray: Thanks, I will update the draft] 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/ [Ray: Thanks, I will update the draft] 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. [Ray: Implementations might be optimized for specific scenarios by reporting on specific packets as indicated by e.g. an out-of-band signal] 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. [Ray: I will check with my co-authors] 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. [Ray: I will check with my co-authors] 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 ? [Ray: I believe it should be up to the implementation to decide how it wants to handle the case of there being only one receiver who reported on presentation timestamps]. 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. [Ray: Thanks for noticing, I will update the reference to the latest ETSI release]. 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. [Ray: Yes, an SDP directorate review has been carried out]. 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/ [Ray: Thanks, I will update the draft] Regards, Dan [Ray: Again, many thanks for the thorough review!] This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
