Hi, Can you please put the WG in the loop regarding these comments. Ray, can you forward your reply as that contains all the information to the WG. I think it is important we take the discussion of some of the issues, especially regarding change control and the IANA policy in a public forum.
Cheers Magnus On 2013-06-10 10:33, Brandenburg, R. (Ray) van wrote: > 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 > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: [email protected] ---------------------------------------------------------------------- _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
