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

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 10 Jun 2013 11:49:46 +0000

Hi WG, 

Below you will find the Gen-ART review of the IDMS draft, including my response to it.

Since some of the comments in the review have to do with the relationship with the ETSI spec, a topic which we have discussed in the WG earlier, I'm copying the WG here. 

Best regards,

Ray

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: maandag 10 juni 2013 12:22
To: Brandenburg, R. (Ray) van; General Area Review Team
Cc: [email-masked]; Roni Even ([email-masked])
Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09

Hi Ray,

Thank you for the detailed answer. 

See in-line. 

Regards,

Dan

> -----Original Message-----
> From: Brandenburg, R. (Ray) van [mailto:[email-masked]]
> Sent: Monday, June 10, 2013 11:33 AM
> To: Romascanu, Dan (Dan); General Area Review Team
> Cc: [email-masked]; Roni Even
> ([email-masked])
> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09
> 
> 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).
> 
[[DR]] Thank you for the clarification information. This is very useful. Can you tell what is the status of the work item in ETSI? 

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

> 
> 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-masked]]
> Sent: zondag 9 juni 2013 9:53
> To: General Area Review Team
> Cc: [email-masked]
> 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]
> 
[[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. 

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

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

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

> 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]
> 
[[DR]] OK

> 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]
> 
[[DR]] It would be good to clarify this in the text. 

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

> 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

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 10 Jun 2013 12:27:31 +0000

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

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

[Ray] I agree completely. This seems to be a relic and I will update the reference to make it informational. 

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

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

[Ray] See my earlier comment: if the WG consensus is that we need a registry, I can include one. 

[Ray] Can we agree to a short informational section that describes the history of IDMS in ETSI and IETF?

[Ray] OK

[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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 10 Jun 2013 13:10:38 +0000

Hi Ray,

Thanks again for considering my comments. 

See in-line. 

Regards,

Dan

> Sent: Monday, June 10, 2013 3:28 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; General Area Review Team; Roni Even
> ([email-masked]); [email-masked]
> Please see my comments inline (I've shortened the message exchange
> somewhat to only include the points of discussion).
> 
> Best regards,
> 
> Ray
> 
> [[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.
> 
> [[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.
> 
> [[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.
> 
> [[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
[[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' 

> [[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.
> 
> [[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.
> 
[[DR]] that's all I am asking

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

---

From: Kevin Gross <[email-masked]>
Date: Mon, 10 Jun 2013 08:26:04 -0600

Dan, thanks for looking at this.

As a co-author, I'll weigh in on a couple of things that Ray did not
address.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org

On Mon, Jun 10, 2013 at 2:33 AM, Brandenburg, R. (Ray) van <
[email-masked]> wrote:

> Please resolve these comments along with any other Last Call comments you
> may receive.
>
> Why a SHOULD here and not a MUST? If there are any cases of exception they
> need to be detailed.
>

[Kevin] Devices that receive these reports need to deal with rollover
conditions both for the RTP timestamp (which can rollover a couple times a
day) and the NTP timestamp (which will have its first rollover in 2036). I
believe these requirements are already stated in RFC3550 and RFC5905
respectively. The suggestion to use recent timestamps in reporting reduces
statistical chance that a receiving device will need to do extra
computation required to handle an RTP rollover. There's no way to eliminate
this possibility altogether and the requirement is stated in a qualitative
way and so could not be enforced as a MUST.

> Why a SHOULD here and not a MUST? If there are any cases of exception they
> need to be detailed.
>

[Kevin] This is an issue that the authors discussed at length and for which
we do not believe there is an optimal solution and so we were reluctant to
require our recommendation. Ideally we want an NTP timestamp indicating
when all data required to render the specified RTP timestamp has arrived.
For this we'd really like to know when the last packet for an RTP timestamp
arrived. In the presence packet loss and reordering, it is not possible to
reliably record the last packet. It is possible to record the first packet
and so this is our recommendation. The accuracy of arrival times is not so
critical in IDMS as arrival time allows a less precise synchronization than
presentation times.

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 10 Jun 2013 14:27:05 +0000

Hi Dan,

Please see inline. We seem to be converging:)

Ray

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: maandag 10 juni 2013 15:11
To: Brandenburg, R. (Ray) van
Cc: [email-masked]; General Area Review Team; Roni Even ([email-masked]); [email-masked]
Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09

Hi Ray,

See in-line. 

Regards,

Dan

> > 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).
> >
> formally accepting the contributions until the IETF document is given 
> an RFC number so that they can reference it.
> 
> > 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.
> 
> document. This will be not needed any longer, an informational 
> reference would be sufficient.
> 
> > 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.
> >
> [[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.
> 
> > assignment of value 12 from the RTCP XR Block Type for reporting 
> > IDMS information to the IETF defined RTCP XR IDMS Report Block.
> >
> [[DR]] The phrase 'This document assigns ... ' is typically used for 
> new assignments, and may be misleading, especially in the interim.

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

[Ray] Ok.

> > This change is however partial as described previously, as the 
> > content of the fields and behavior for SPST = 2-4 remain under ETSI control.
> > 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.
> 
> [[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] Ok, I think that is acceptable. 

> > Why a SHOULD here and not a MUST? If there are any cases of 
> > exception they need to be detailed.
> >
> > [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].
> >
> 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.
> 

[Ray] I think I see where we disagree. The paragraph says: "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". The way I read this is as: In the case the field is declared empty (= contains NULL information), it SHALL be set to 0. There can be different reasons for declaring the field empty/NULL, one of those reasons is if none or only one receiver reported on presentation timestamps. To me, the paragraph doesn't say that this is the only possible reason, but it does specify very clearly that if you decide the field should be empty, you SHALL set it to zero.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 10 Jun 2013 14:34:31 +0000

Yes, we seem to get closer and closer, focus on one last issue (and much agreement deleted)

Thanks and Regards,

Dan

> Sent: Monday, June 10, 2013 5:27 PM
> To: Romascanu, Dan (Dan)

> [[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?
> 
> [Ray] I think I see where we disagree. The paragraph says: "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". The way I read this is as: In the case the field is
> declared empty (= contains NULL information), it SHALL be set to 0.
> There can be different reasons for declaring the field empty/NULL, one
> of those reasons is if none or only one receiver reported on
> presentation timestamps. To me, the paragraph doesn't say that this is
> the only possible reason, but it does specify very clearly that if you
> decide the field should be empty, you SHALL set it to zero.
> 
> 

[[DR]] But then, why do not you take out 'if none or' - because for the option of 'none' there is no alternative but the 'null' information, and the MAY does not make sense. 

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 10 Jun 2013 14:40:22 +0000

Hi Kevin,

Thank you for looking at my comments and for explaining in detail the editorial decisions that you made. Both explanations make sense, and leaving the current text in place is acceptable.

Regards,

Dan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin Gross
Sent: Monday, June 10, 2013 5:26 PM
To: Brandenburg, R. (Ray) van
Cc: Romascanu, Dan (Dan); General Area Review Team; [email-masked]; [email-masked]
Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09

As a co-author, I'll weigh in on a couple of things that Ray did not address.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com<http://www.avanw.com/>, www.X192.org<http://www.X192.org>

On Mon, Jun 10, 2013 at 2:33 AM, Brandenburg, R. (Ray) van <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: zondag 9 juni 2013 9:53
To: General Area Review Team
Cc: [email-masked]<mailto:[email-masked]>
Subject: Gen-ART review of draft-ietf-avtcore-idms-09

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at

Please resolve these comments along with any other Last Call comments you may receive.

Summary:

Not Ready

Major issues:
5. In Section 8:

   Because RTP

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]

[Kevin] Devices that receive these reports need to deal with rollover conditions both for the RTP timestamp (which can rollover a couple times a day) and the NTP timestamp (which will have its first rollover in 2036). I believe these requirements are already stated in RFC3550 and RFC5905 respectively. The suggestion to use recent timestamps in reporting reduces statistical chance that a receiving device will need to do extra computation required to handle an RTP rollover. There's no way to eliminate this possibility altogether and the requirement is stated in a qualitative way and so could not be enforced as a MUST.

6. In Section 8:

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]

[Kevin] This is an issue that the authors discussed at length and for which we do not believe there is an optimal solution and so we were reluctant to require our recommendation. Ideally we want an NTP timestamp indicating when all data required to render the specified RTP timestamp has arrived. For this we'd really like to know when the last packet for an RTP timestamp arrived. In the presence packet loss and reordering, it is not possible to reliably record the last packet. It is possible to record the first packet and so this is our recommendation. The accuracy of arrival times is not so critical in IDMS as arrival time allows a less precise synchronization than presentation times.

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 10 Jun 2013 14:51:49 +0000

Hi Dan,

See below...

Best regards,

Ray

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: maandag 10 juni 2013 16:35
To: Brandenburg, R. (Ray) van
Cc: [email-masked]; General Area Review Team; Roni Even ([email-masked]); [email-masked]
Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09

Thanks and Regards,

Dan

> > >    then it SHALL be set to 0.  This field MAY be left empty if 
> > > none
> or
> > > [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].
> > >
> > receiver only reported should be dealt with differently. This needs 
> > to be clarified.
> >
> [[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?
> 
> 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 

[Ray] The fact that no receiver reported on the packet presentation timestamp does not necessarily mean that the MSAS does not want to indicate a proposed packet presentation timestamp. The absence of such reports just means that the proposed playout moment might not be realistic, or be supported by any receiver. 

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 10 Jun 2013 14:56:56 +0000

> Sent: Monday, June 10, 2013 5:52 PM
> To: Romascanu, Dan (Dan)
> [[DR]] But then, why do not you take out 'if none or' - because for the
> option of 'none' there is no alternative but the 'null' information, and
> the MAY does not make sense.
> 
> [Ray] The fact that no receiver reported on the packet presentation
> timestamp does not necessarily mean that the MSAS does not want to
> indicate a proposed packet presentation timestamp. The absence of such
> reports just means that the proposed playout moment might not be
> realistic, or be supported by any receiver.
> 

[[DR]] yes, but is the field set to anything but 0 in such cases? 

Dan

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 10 Jun 2013 15:05:58 +0000

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: maandag 10 juni 2013 16:57
To: Brandenburg, R. (Ray) van
Cc: [email-masked]; General Area Review Team; Roni Even ([email-masked]); [email-masked]
Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09

> > > > Why a MAY here? Especially for the case when none of the 
> > > > receivers reported, what content can be set there but 0 ?
> > > >
> > > [[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.
> > >
> >
> > There can be different reasons for declaring the field empty/NULL, 
> > one of those reasons is if none or only one receiver reported on 
> > presentation timestamps. To me, the paragraph doesn't say that this 
> > is the only possible reason, but it does specify very clearly that 
> > if you decide the field should be empty, you SHALL set it to zero.
> >
> >
> 
> [[DR]] But then, why do not you take out 'if none or' - because for 
> the option of 'none' there is no alternative but the 'null' 
> information, and the MAY does not make sense.
> 

[Ray] If the MSAS decides to leave the field empty, it is set to 0 according to the SHALL. If the MSAS decides to include a timestamp anyway, it is set to whatever value the MSAS proposes. 

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 10 Jun 2013 15:11:29 +0000

> Sent: Monday, June 10, 2013 6:06 PM
> To: Romascanu, Dan (Dan)
> [Ray] If the MSAS decides to leave the field empty, it is set to 0
> according to the SHALL. If the MSAS decides to include a timestamp
> anyway, it is set to whatever value the MSAS proposes.
> 

[[DR]] So two different implementations may behave differently in similar situations. Is this a problem? 

Dan

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 10 Jun 2013 16:18:44 +0000

> [[DR]] So two different implementations may behave differently in similar situations. Is this a problem? 

No, I don't think it is a problem if two different MSAS implementations behave differently in this regard. I see it as server-side configuration. Anyway, even if we would replace the MAY with a SHOULD or remove the sentence all together, there would still be different implementations: for example, let's say we have a sync group of 12 devices, with 7 of them reporting presentation timestamps. What should the MSAS do? Set the field in the IDMS Settings Packet to 0 or not? I feel this decision should be up to the implementation as I don't see an advantage to us specifying either one way or the other. 

Ray

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 10 Jun 2013 16:59:59 +0000

> Sent: Monday, June 10, 2013 7:19 PM
> To: Romascanu, Dan (Dan)
> Subject: Re: Gen-ART review of draft-ietf-avtcore-idms-09
> 
> 
> 
> >>>> ([email-masked]);
> >>>> [email-masked]
> >>> indicate a proposed packet presentation timestamp. The absence of
> >>> such reports just means that the proposed playout moment might not
> >>> be realistic, or be supported by any receiver.
> >>>
> >>
> No, I don't think it is a problem if two different MSAS implementations
> behave differently in this regard. I see it as server-side
> configuration. Anyway, even if we would replace the MAY with a SHOULD or
> remove the sentence all together, there would still be different
> implementations: for example, let's say we have a sync group of 12
> devices, with 7 of them reporting presentation timestamps. What should
> the MSAS do? Set the field in the IDMS Settings Packet to 0 or not? I
> feel this decision should be up to the implementation as I don't see an
> advantage to us specifying either one way or the other.
> 
> Ray
> 

[[DR]] The open issue is not about this case but about the case when no receiver reported. You say one MSAS implementation may treat this as null information setting the field to 0 (which would seem to me like the obvious thing to do), but other MSAS implementation may include a timestamp anyway (which one?). My question 'Is this a problem' was about this case? 

Dan

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 11 Jun 2013 10:29:55 +0000

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: maandag 10 juni 2013 19:00
To: Brandenburg, R. (Ray) van
Cc: [email-masked]; General Area Review Team; Roni Even ([email-masked]); [email-masked]
Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09

> >>>>>> how it wants to handle the case of there being only one 
> >>>>>> receiver who reported on presentation timestamps].
> >>>>>>
> >>>>> one receiver only reported should be dealt with differently. 
> >>>>> This needs to be clarified.
> >>>>>
> >>>> avoid leaving some garbage in this field which could be 
> >>>> interpreted differently - don't we?
> >>>>
> >>>> [Ray] I think I see where we disagree. The paragraph says: "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". The way I read this is as: In the case 
> >>>> the field is declared empty (= contains NULL information), it SHALL be set to 0.
> >>>> There can be different reasons for declaring the field 
> >>>> empty/NULL, one of those reasons is if none or only one receiver 
> >>>> reported on presentation timestamps. To me, the paragraph doesn't 
> >>>> say that this is the only possible reason, but it does specify 
> >>>> very clearly that if you decide the field should be empty, you SHALL set it to zero.
> >>>>
> >>>>
> >>>
> >>> [[DR]] But then, why do not you take out 'if none or' - because 
> >>> for the option of 'none' there is no alternative but the 'null'
> >>> [Ray] The fact that no receiver reported on the packet 
> >>> presentation timestamp does not necessarily mean that the MSAS 
> >>> does not want to indicate a proposed packet presentation 
> >>> timestamp. The absence of such reports just means that the 
> >>> proposed playout moment might not be realistic, or be supported by any receiver.
> >>>
> >>
> No, I don't think it is a problem if two different MSAS 
> implementations behave differently in this regard. I see it as 
> server-side configuration. Anyway, even if we would replace the MAY 
> with a SHOULD or remove the sentence all together, there would still 
> be different
> feel this decision should be up to the implementation as I don't see 
> an advantage to us specifying either one way or the other.
> 
> Ray
> 

[Ray] I don't see a difference between the two cases: in both cases the MSAS can decide to send 'some' timestamp.  I'm not saying this is recommended, but I also don't see any interop issues. In any synchronization group there will be a maximum of 1 MSAS, so all receivers will receive the same presentation timestamp. What they do with that timestamp is up to the SCs themselves. 

Ray