On 10 jun. 2013, at 17:11, "Romascanu, Dan (Dan)" <[email protected]> wrote:
> > > > >> -----Original Message----- >> From: Brandenburg, R. (Ray) van [mailto:[email protected]] >> Sent: Monday, June 10, 2013 6:06 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 >> >> >> >> -----Original Message----- >> From: Romascanu, Dan (Dan) [mailto:[email protected]] >> Sent: maandag 10 juni 2013 16:57 >> To: Brandenburg, R. (Ray) van >> Cc: [email protected]; General Area Review Team; Roni Even >> ([email protected]); [email protected] >> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 >> >> >> >> >> >>> -----Original Message----- >>> From: Brandenburg, R. (Ray) van [mailto:[email protected]] >>> Sent: Monday, June 10, 2013 5:52 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, >>> >>> See below... >>> >>> Best regards, >>> >>> Ray >>> >>> -----Original Message----- >>> From: Romascanu, Dan (Dan) [mailto:[email protected]] >>> Sent: maandag 10 juni 2013 16:35 >>> To: Brandenburg, R. (Ray) van >>> Cc: [email protected]; General Area Review Team; Roni Even >>> ([email protected]); [email protected] >>> 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:[email protected]] >>>> Sent: Monday, June 10, 2013 5:27 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, >>>> >>>> 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 > Dan > 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
