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

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Mon, 10 June 2013 14:57 UTC

Return-Path: <dromasca@avaya.com>
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 D7AEC21F95D7; Mon, 10 Jun 2013 07:57:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.377
X-Spam-Level:
X-Spam-Status: No, score=-103.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 47YXCJLzOHJi; Mon, 10 Jun 2013 07:57:11 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 734D421F938E; Mon, 10 Jun 2013 07:57:01 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AicFAJTotVGHCzI1/2dsb2JhbABagmgheb5CgQQWdIIjAQEBAQMSKD8MBAIBCA0EBAEBCxQJByERFAkIAgQOBQgah1kDDwGdUpMJDYg7F4xbgiwxBwaCeWEDlVgBiCmFXIUkgw+CJw
X-IronPort-AV: E=Sophos;i="4.87,837,1363147200"; d="scan'208";a="12524860"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Jun 2013 10:56:59 -0400
Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 10 Jun 2013 10:52:12 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Mon, 10 Jun 2013 16:56:57 +0200
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>
Thread-Topic: Gen-ART review of draft-ietf-avtcore-idms-09
Thread-Index: Ac5k5mDClosY2XEXSFmBhpnaPpC1lwAw3NGAAAWr/5AAA+nLUAAASPBwAAJBThAAAsYU4AAAcx/AAACXwtAAACxhQA==
Date: Mon, 10 Jun 2013 14:56:56 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA199EBA@AZ-FFEXMB04.global.avaya.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA19894C@AZ-FFEXMB04.global.avaya.com> <FCC100FC8D6B034CB88CD8173B2DA1581F34C609@EXC-MBX03.tsn.tno.nl> <9904FB1B0159DA42B0B887B7FA8119CA199C1B@AZ-FFEXMB04.global.avaya.com> <FCC100FC8D6B034CB88CD8173B2DA1581F34CC74@EXC-MBX03.tsn.tno.nl> <FCC100FC8D6B034CB88CD8173B2DA1581F34CDCD@EXC-MBX03.tsn.tno.nl> <9904FB1B0159DA42B0B887B7FA8119CA199D6F@AZ-FFEXMB04.global.avaya.com> <FCC100FC8D6B034CB88CD8173B2DA1581F34D281@EXC-MBX03.tsn.tno.nl> <9904FB1B0159DA42B0B887B7FA8119CA199E37@AZ-FFEXMB04.global.avaya.com> <FCC100FC8D6B034CB88CD8173B2DA1581F34D3C2@EXC-MBX03.tsn.tno.nl>
In-Reply-To: <FCC100FC8D6B034CB88CD8173B2DA1581F34D3C2@EXC-MBX03.tsn.tno.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.64.58.46]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: General Area Review Team <gen-art@ietf.org>, "avt@ietf.org" <avt@ietf.org>, "draft-ietf-avtcore-idms.all@tools.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 <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jun 2013 14:57:23 -0000
X-List-Received-Date: Mon, 10 Jun 2013 14:57:23 -0000

> -----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 (= 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? 

Dan