Thank you Dan very, very much for your detailed review. And thank you Ray and others for addressing the points noted by Dan - I think the document has improved as a result. Thanks again. I have balloted no-objection for this document in today's IESG telechat.
Jari On Jun 11, 2013, at 1:29 PM, "Brandenburg, R. (Ray) van" <[email protected]> wrote: > > > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:[email protected]] > Sent: maandag 10 juni 2013 19:00 > 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 7:19 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 >> >> >> >> 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 >> > > [[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 > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
