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