Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09

["Brandenburg, R. (Ray) van" <[e-mail]>]

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' ?

> 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?


> 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. 

Best regards,

Ray
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer