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

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

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





> -----Original Message-----
> From: Brandenburg, R. (Ray) van [mailto:[e-mail]]
> Sent: Monday, June 10, 2013 7:19 PM
> To: Romascanu, Dan (Dan)
> Cc: [e-mail]; General Area Review Team; Roni Even 
> ([e-mail]); [e-mail]
> Subject: Re: Gen-ART review of draft-ietf-avtcore-idms-09
> 
> 
> 
> On 10 jun. 2013, at 17:11, "Romascanu, Dan (Dan)" <[e-mail]>
> wrote:
> 
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Brandenburg, R. (Ray) van [mailto:[e-mail]]
> >> Sent: Monday, June 10, 2013 6:06 PM
> >> To: Romascanu, Dan (Dan)
> >> Cc: [e-mail]; General Area Review Team; Roni Even 
> >> ([e-mail]); 
> >> [e-mail]
> >> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Romascanu, Dan (Dan) [mailto:[e-mail]]
> >> Sent: maandag 10 juni 2013 16:57
> >> To: Brandenburg, R. (Ray) van
> >> Cc: [e-mail]; General Area Review Team; Roni Even 
> >> ([e-mail]); 
> >> [e-mail]
> >> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09
> >>
> >>
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Brandenburg, R. (Ray) van [mailto:[e-mail]]
> >>> Sent: Monday, June 10, 2013 5:52 PM
> >>> To: Romascanu, Dan (Dan)
> >>> Cc: [e-mail]; General Area Review Team; Roni Even 
> >>> ([e-mail]); 
> >>> [e-mail]
> >>> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09
> >>>
> >>> Hi Dan,
> >>>
> >>> See below...
> >>>
> >>> Best regards,
> >>>
> >>> Ray
> >>>
> >>> -----Original Message-----
> >>> From: Romascanu, Dan (Dan) [mailto:[e-mail]]
> >>> Sent: maandag 10 juni 2013 16:35
> >>> To: Brandenburg, R. (Ray) van
> >>> Cc: [e-mail]; General Area Review Team; Roni Even 
> >>> ([e-mail]); 
> >>> [e-mail]
> >>> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09
> >>>
> >>>
> >>> Yes, we seem to get closer and closer, focus on one last issue 
> >>> (and much agreement deleted)
> >>>
> >>> Thanks and Regards,
> >>>
> >>> Dan
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Brandenburg, R. (Ray) van 
> >>>> [mailto:[e-mail]]
> >>>> Sent: Monday, June 10, 2013 5:27 PM
> >>>> To: Romascanu, Dan (Dan)
> >>>> Cc: [e-mail]; General Area Review Team; Roni Even 
> >>>> ([e-mail]); 
> >>>> [e-mail]
> >>>> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09
> >>>>
> >>>> Hi Dan,
> >>>>
> >>>> Please see inline. We seem to be converging:)
> >>>>
> >>>> Ray
> >>>
> >>>>>> 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?
> >>>>
> >>>> [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.
> >>>
> >>> [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?
> >>
> >> [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?
> >
> 
> 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? 

[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

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