Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9EE21F9425; Tue, 11 Jun 2013 03:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhKpNXonZnqL; Tue, 11 Jun 2013 03:30:08 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id AF07821F9433; Tue, 11 Jun 2013 03:30:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,844,1363129200"; d="scan'208";a="9709115" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 11 Jun 2013 12:29:56 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.85]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.02.0318.004; Tue, 11 Jun 2013 12:29:56 +0200 From: "Brandenburg, R. (Ray) van" To: "Romascanu, Dan (Dan)" Thread-Topic: Gen-ART review of draft-ietf-avtcore-idms-09 Thread-Index: Ac5k5mDClosY2XEXSFmBhpnaPpC1lwAw3NGAAAWr/5AAA+nLUAAASPBwAAJBThAAAsYU4AAAcx/AAACXwtAAACxhQAAAZQ1gAAAuajAAAmW0KAAAUNTwACTzZ6A= Date: Tue, 11 Jun 2013 10:29:55 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA19894C@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199C1B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199D6F@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199E37@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA199EBA@AZ-FFEXMB04.global.avaya.com> , <9904FB1B0159DA42B0B887B7FA8119CA199F21@AZ-FFEXMB04.global.avaya.com> <3DFD3155-BBD9-4BE0-8912-81B92C93D3CB@tno.nl> <9904FB1B0159DA42B0B887B7FA8119CA19A0A6@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA19A0A6@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: General Area Review Team , "avt@ietf.org" , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 10:30:14 -0000 -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] = Sent: maandag 10 juni 2013 19:00 To: Brandenburg, R. (Ray) van Cc: avt@ietf.org; General Area Review Team; Roni Even (ron.even.tlv@gmail.c= om); draft-ietf-avtcore-idms.all@tools.ietf.org Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > -----Original Message----- > From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > Sent: Monday, June 10, 2013 7:19 PM > To: Romascanu, Dan (Dan) > Cc: avt@ietf.org; General Area Review Team; Roni Even = > (ron.even.tlv@gmail.com); draft-ietf-avtcore-idms.all@tools.ietf.org > Subject: Re: Gen-ART review of draft-ietf-avtcore-idms-09 > = > = > = > On 10 jun. 2013, at 17:11, "Romascanu, Dan (Dan)" > wrote: > = > > > > > > > > > >> -----Original Message----- > >> From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > >> Sent: Monday, June 10, 2013 6:06 PM > >> To: Romascanu, Dan (Dan) > >> Cc: avt@ietf.org; General Area Review Team; Roni Even = > >> (ron.even.tlv@gmail.com); = > >> draft-ietf-avtcore-idms.all@tools.ietf.org > >> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > >> > >> > >> > >> -----Original Message----- > >> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > >> Sent: maandag 10 juni 2013 16:57 > >> To: Brandenburg, R. (Ray) van > >> Cc: avt@ietf.org; General Area Review Team; Roni Even = > >> (ron.even.tlv@gmail.com); = > >> draft-ietf-avtcore-idms.all@tools.ietf.org > >> Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 > >> > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] > >>> Sent: Monday, June 10, 2013 5:52 PM > >>> To: Romascanu, Dan (Dan) > >>> Cc: avt@ietf.org; General Area Review Team; Roni Even = > >>> (ron.even.tlv@gmail.com); = > >>> draft-ietf-avtcore-idms.all@tools.ietf.org > >>> 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:dromasca@avaya.com] > >>> Sent: maandag 10 juni 2013 16:35 > >>> To: Brandenburg, R. (Ray) van > >>> Cc: avt@ietf.org; General Area Review Team; Roni Even = > >>> (ron.even.tlv@gmail.com); = > >>> draft-ietf-avtcore-idms.all@tools.ietf.org > >>> 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:ray.vanbrandenburg@tno.nl] > >>>> Sent: Monday, June 10, 2013 5:27 PM > >>>> To: Romascanu, Dan (Dan) > >>>> Cc: avt@ietf.org; General Area Review Team; Roni Even = > >>>> (ron.even.tlv@gmail.com); = > >>>> draft-ietf-avtcore-idms.all@tools.ietf.org > >>>> 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 (=3D contains NULL information), it SHAL= L 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 an= y 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 rec= eiver reported. You say one MSAS implementation may treat this as null info= rmation setting the field to 0 (which would seem to me like the obvious thi= ng to do), but other MSAS implementation may include a timestamp anyway (wh= ich 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 MSA= S 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 ther= e will be a maximum of 1 MSAS, so all receivers will receive the same prese= ntation timestamp. What they do with that timestamp is up to the SCs themse= lves. = Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer