Hi Ray, Thanks again for considering my comments.
See in-line. Regards, Dan > -----Original Message----- > From: Brandenburg, R. (Ray) van [mailto:[email protected]] > Sent: Monday, June 10, 2013 3:28 PM > To: Romascanu, Dan (Dan) > Cc: [email protected]; General Area Review Team; Roni Even > ([email protected]); [email protected] > Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > > Hi Dan, > > (I've cc'ed the AVTCORE list on Magnus' request) > > Please see my comments inline (I've shortened the message exchange > somewhat to only include the points of discussion). > > Best regards, > > Ray > > > 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). > > > [[DR]] Thank you for the clarification information. This is very useful. > Can you tell what is the status of the work item in ETSI? > > [Ray] The current status is that the Work Item has been opened and the > contributions have been written and discussed. ETSI has postponed > formally accepting the contributions until the IETF document is given an > RFC number so that they can reference it. > > > 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. > [[DR]] I disagree that there is no need to describe this relationship on > the IETF draft. As control for the XR block was previously in ETSI and > will now be transferred to the IETF we should assume that there are > implementers and deployments who know about the older ETSI > specification. You need a sections that describes the relationship with > the ETSI document, and describes the changes relative to that version - > same as would have been written if there was an RFC that was updated or > made obsolete by this document. > > Moreover, the current document is not consistent, as it still keeps a > normative reference to the older (not even the latest version) ETSI > document. This will be not needed any longer, an informational reference > would be sufficient. > > [Ray] I agree completely. This seems to be a relic and I will update the > reference to make it informational. > > > 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] > > > [[DR]] Eventually it will solve the issue, but the situation is murky in > the interim. I believe that creating a registry would be good, because > it provides a way to describe the interim situation, and also because we > do not know yet for sure who may use the values 5-15 in the future. > > [Ray] As Roni mentioned, it is a chicken-egg problem. If there is > consensus in the WG to create a registry, I am happy to include one in > the draft. > > > 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?] > > > [[DR]] The phrase 'This document assigns ... ' is typically used for new > assignments, and may be misleading, especially in the interim. > Describing explicitly the transfer of control is better IMO. > > [Ray] Fair enough. How about: 'This document asks to update the > assignment of value 12 from the RTCP XR Block Type for reporting IDMS > information to the RTCP XR IDMS Report Block defined in this document' ? > [[DR]] close, with slight edits, I would make it: 'This document updates the assignment of value 12 from the RTCP XR Block Type for reporting IDMS information as per [TS183063] to the RTCP XR IDMS Report Block defined in this document' > > 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.] > > > [[DR]] a registry is better, it also avoids the need to make changes to > this document if new extensions are being defined by ETSI or other > organizations. > > [Ray] See my earlier comment: if the WG consensus is that we need a > registry, I can include one. > > > 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]. > > > [[DR]] This is where we disagree. If there was no history of control, no > previous ETSI specification you would be right, but this is not the > case. > > [Ray] Can we agree to a short informational section that describes the > history of IDMS in ETSI and IETF? > > [[DR]] that's all I am asking > > 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] > > > [[DR]] It would be good to clarify this in the text. > > [Ray] OK > > > > 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]. > > > [[DR]] OK, so the cases when none of the receivers reported and one > receiver only reported should be dealt with differently. This needs to > be clarified. > > [Ray] What exactly is the problem with the MAY here? IMO it doesn't > create any interop issues: whatever is the reason for setting the value > to 0, to the client the end result is the same: ignore it. > [[DR]] In the case when none of the receivers reported we want to avoid leaving some garbage in this field which could be interpreted differently - don't we? > Best regards, > > Ray > 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
