From magnus.westerlund@ericsson.com Fri Jun 1 07:00:09 2012 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 9855511E8106 for ; Fri, 1 Jun 2012 07:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.219 X-Spam-Level: X-Spam-Status: No, score=-106.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 i2lYDSMDVUCi for ; Fri, 1 Jun 2012 07:00:08 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 071BD11E81C3 for ; Fri, 1 Jun 2012 06:59:59 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-0a-4fc8cade80d8 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 74.11.11869.EDAC8CF4; Fri, 1 Jun 2012 15:59:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.0; Fri, 1 Jun 2012 15:59:58 +0200 Message-ID: <4FC8CADE.90901@ericsson.com> Date: Fri, 1 Jun 2012 15:59:58 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: avt@ietf.org References: <4F980E4D.1040205@ericsson.com> In-Reply-To: <4F980E4D.1040205@ericsson.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjluLIzCtJLcpLzFFi42KZGfG3VvfeqRP+Bof3WFi87FnJ7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOUNm1gLpvFXXOueztLAuJqni5GTQ0LAROLMvA5GCFtM4sK9 9WxdjFwcQgKnGCVWLb3NDuEsY5Q4+e4QSxcjBwevgKbE7B0+IA0sAioSq5peM4PYbAIWEjd/ NLKB2KICwRIv9lxhBbF5BQQlTs58wgJiiwgISKzY/hfMFhZwldh7aQaYLSSgLfH36COwIzgF dCRapkPMkRCQlDj47xo7iM0soCcx5WoLI4QtL9G8dTYzTG9DUwfrBEbBWUjWzULSMgtJywJG 5lWMwrmJmTnp5UZ6qUWZycXF+Xl6xambGIFheXDLb9UdjHfOiRxilOZgURLntd66x19IID2x JDU7NbUgtSi+qDQntfgQIxMHp1QD47IrFyPzFt5p/b6p9l9D0DwnvTuPtqfa8gXX2l56uHuK bYBh91s/Z3cVZ/dTz39NU5v+m/mLTjK/ffNa09cZRcbF8bEa71Rnr3kft0VpoeQMdcne+U+9 rKzeH4yZnlZRVLzmf6HZjMudS04s1Poj5v1Gdc9M3ZszuB0X8R6we3s/5PyW1cbP1JRYijMS DbWYi4oTAflkz9kZAgAA Subject: Re: [AVTCORE] Adopting a WG item for RTP stream duplication? 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: Fri, 01 Jun 2012 14:00:09 -0000 WG, As we have a fair support for creating a WG item I will discuss this with our AD. Cheers Magnus On 2012-04-25 16:46, Magnus Westerlund wrote: > WG, > > In Paris we took a hum on adopting a WG item for RTP Stream Duplication. > The problem this tries to address is described in > https://datatracker.ietf.org/doc/draft-begen-avtcore-rtp-duplication/ > > The result in the meeting room was minuted as: A fair amount of people > supporting a WG item, none against. > > See more about this item (Agenda Item 10) in the minutes > http://www.ietf.org/proceedings/83/minutes/minutes-83-avtcore.htm > > Thus I would like to ask the rest of the WG if they support or oppose > the creation of a WG item for defining how to best perform RTP stream > Duplication. > > Cheers > > Magnus Westerlund > (WG Chair) > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From marshall.eubanks@gmail.com Fri Jun 1 07:06:02 2012 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 7579711E8089 for ; Fri, 1 Jun 2012 07:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.568 X-Spam-Level: X-Spam-Status: No, score=-103.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 zo0oRUJw-IfA for ; Fri, 1 Jun 2012 07:06:01 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7DC11E80B4 for ; Fri, 1 Jun 2012 07:06:00 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1839171lbb.31 for ; Fri, 01 Jun 2012 07:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AUgJ5TyI+nmiWvJBYSu6ZxrqQ5And6pd68LclJlHTI4=; b=xv37C1aGR1sUUUL+JROFnjqmD/KR4C4aFKXcw8B7h6hZXtg2up86UjK8PRYfPBuZky B59WagJQNfIt1G560DURwq9I8JLHpXlJsRKFMwjiFvCQDTJBdLf38S28SoQ+3Sb2+HEG t6pXoS3WHMh8+9dhQix46lUVxiCgqYpWTMLLTgiIPXiQNDfZqnuvi3/we1XUg3+lCq7m iB5Yz6lXAuzR2uGMFGqVjxEeaDsc7PN02ILmVIY6g1sMOtsR/B/aZYXTdVx98zpNcz4v mov2yPHZZc4LDGz2XeKxgd8zVkIJxv+iYsVa4XmWdIqmpyKHymAFBWrDWMqJ6Vfdekaj plCQ== MIME-Version: 1.0 Received: by 10.152.104.171 with SMTP id gf11mr3290253lab.5.1338559560028; Fri, 01 Jun 2012 07:06:00 -0700 (PDT) Received: by 10.112.132.65 with HTTP; Fri, 1 Jun 2012 07:06:00 -0700 (PDT) In-Reply-To: <4F980E4D.1040205@ericsson.com> References: <4F980E4D.1040205@ericsson.com> Date: Fri, 1 Jun 2012 10:06:00 -0400 Message-ID: From: Marshall Eubanks To: Magnus Westerlund Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Adopting a WG item for RTP stream duplication? 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: Fri, 01 Jun 2012 14:06:02 -0000 I support this and, as the I-D seems like a reasonable approach to a solution, I would support its adoption by the WG. Regards On Wed, Apr 25, 2012 at 10:46 AM, Magnus Westerlund wrote: > WG, > > In Paris we took a hum on adopting a WG item for RTP Stream Duplication. > The problem this tries to address is described in > https://datatracker.ietf.org/doc/draft-begen-avtcore-rtp-duplication/ > > The result in the meeting room was minuted as: A fair amount of people > supporting a WG item, none against. > > See more about this item (Agenda Item 10) in the minutes > http://www.ietf.org/proceedings/83/minutes/minutes-83-avtcore.htm > > Thus I would like to ask the rest of the WG if they support or oppose > the creation of a WG item for defining how to best perform RTP stream > Duplication. > > Cheers > > Magnus Westerlund > (WG Chair) > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 > F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From kevin.gross@avanw.com Fri Jun 1 09:49:18 2012 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 CDFC111E80FE for ; Fri, 1 Jun 2012 09:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.335 X-Spam-Level: * X-Spam-Status: No, score=1.335 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 Up+xAFJRQbKq for ; Fri, 1 Jun 2012 09:49:18 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 15C7F11E80E3 for ; Fri, 1 Jun 2012 09:49:17 -0700 (PDT) Received: (qmail 30678 invoked by uid 0); 1 Jun 2012 16:49:17 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy8.bluehost.com with SMTP; 1 Jun 2012 16:49:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:To:From:Subject:Message-ID:Date:MIME-Version; bh=4GN5NKAWUDrWo4Vg3vyHVtGS9sBPfOGhXCyGS+PKDbI=; b=KfRCRw9rTaI90OMH2rZPkKl7vs5A7gC7FPwCpT5HPMlY4QrxhewtnXD5s4wmofPpeZvSgw+njuJnpHCBfRSvz2A3W2FJDJRM8s9FXU51Mapz1b0KLaQo9CkPpvRtPJFk; Received: from mail-we0-f172.google.com ([74.125.82.172]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1SaV2L-0004jp-24 for avt@ietf.org; Fri, 01 Jun 2012 10:49:17 -0600 Received: by werb13 with SMTP id b13so1724182wer.31 for ; Fri, 01 Jun 2012 09:49:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.140.33 with SMTP id d33mr2595475wej.113.1338569355306; Fri, 01 Jun 2012 09:49:15 -0700 (PDT) Received: by 10.223.144.216 with HTTP; Fri, 1 Jun 2012 09:49:15 -0700 (PDT) Date: Fri, 1 Jun 2012 10:49:15 -0600 Message-ID: From: Kevin Gross To: avt@ietf.org Content-Type: multipart/alternative; boundary=0016e6dab08aee286904c16bf647 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.172 authed with kevin.gross@avanw.com} Subject: [AVTCORE] RTCP traffic class 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: Fri, 01 Jun 2012 16:49:18 -0000 --0016e6dab08aee286904c16bf647 Content-Type: text/plain; charset=ISO-8859-1 Is there any guidance available as to how RTCP traffic should be treated by a network? Should it be given the same QoS as associated RTP traffic or is best effort adequate? I have reviewed the RFC 3550, 3551 and draft-ietf-mmusic-traffic-class-for-sdp and I haven't found a recommendation. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org --0016e6dab08aee286904c16bf647 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Is there any guidance available as to how RTCP traffic should be treat= ed by a network? Should it be given the same QoS as associated RTP traffic = or is best effort adequate? I have reviewed the RFC 3550, 3551 and=A0draft-= ietf-mmusic-traffic-class-for-sdp and I haven't found a recommendation.=

Kevin Gross
+1-303-447-0517
Media Netwo= rk Consultant
AVA Networks -=A0www.AVAnw.com,=A0www.X192.org

--0016e6dab08aee286904c16bf647-- From marshall.eubanks@gmail.com Fri Jun 1 12:08:43 2012 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 3BBDF11E8096 for ; Fri, 1 Jun 2012 12:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.569 X-Spam-Level: X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 NwpZmadhupeI for ; Fri, 1 Jun 2012 12:08:42 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB07711E80A4 for ; Fri, 1 Jun 2012 12:08:41 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2062092lbb.31 for ; Fri, 01 Jun 2012 12:08:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=w/CqcMLijP8IOlaGV5/ksUVKq374DXVvKv69SfgoYwE=; b=B2t8MEp6muClihNKFx36bYQyZ2zjgCFMZlXS2spfgK+uNiuXxbKPQ9iobVIEBXAcLM zAY/pwxoBEnvYTAyBxZ9wO5nzYEKB5Z1kD8FWOwfnnd5hUK0y+nDtXYB8Osso+po+7/S EZB9HAvFqTOjzzXFjQLNr9Z9QagQcPCPVQnbSdOFZqdH+STp32Xst2rfy7JXFhfJ/N4b 5H1cgcft1gh2v0/T/HmhQ9j6OB9EoJRr++XGbfp86Y8+pl+ERY12BmxdZywOqn6X5K1u mNl5x7zQ0PjM+96qI/IDs8v17o0R2B8wictH1PC7PQFaC1ubfkmxHQZiUP/zDcUDKmA8 efyA== MIME-Version: 1.0 Received: by 10.152.112.34 with SMTP id in2mr4180652lab.6.1338577720708; Fri, 01 Jun 2012 12:08:40 -0700 (PDT) Received: by 10.112.132.65 with HTTP; Fri, 1 Jun 2012 12:08:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Jun 2012 15:08:40 -0400 Message-ID: From: Marshall Eubanks To: Kevin Gross Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: avt@ietf.org Subject: Re: [AVTCORE] RTCP traffic class 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: Fri, 01 Jun 2012 19:08:43 -0000 On Fri, Jun 1, 2012 at 12:49 PM, Kevin Gross wrote: > Is there any guidance available as to how RTCP traffic should be treated = by > a network? Should it be given the same QoS as associated RTP traffic or i= s > best effort adequate? I have reviewed the RFC 3550, 3551 > and=A0draft-ietf-mmusic-traffic-class-for-sdp and I haven't found a > recommendation. > This is just my opinion, but I have always recommended that RTCP have the same _or better_ QOS than the associated RTP flows : The traffic is small and bounded and (depending on how you are doing your R= TP) RTCP can be crucial to good performance. Regards Marshall > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks -=A0www.AVAnw.com,=A0www.X192.org > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From mzanaty@cisco.com Fri Jun 1 12:40:44 2012 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 28D0211E80E2 for ; Fri, 1 Jun 2012 12:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 vWBZjIDL5+ML for ; Fri, 1 Jun 2012 12:40:43 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2528D11E80CC for ; Fri, 1 Jun 2012 12:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mzanaty@cisco.com; l=1197; q=dns/txt; s=iport; t=1338579643; x=1339789243; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=2HiIhQ3kHST4Rq6sp6DXnEZQl1FLkbirBNo62JCzB1A=; b=GnUBxq7I4Q5B2wmvlrHbTNtJIsJr5VM21M6elt6QpVLC8wCPgMfK3D0g idVmaHD3zAmcn3yDtG+4vyDPEb7eHvSZ5BKB762bv6F7l1OQIe7fR6e9z eS03MQVUuvuuElQjn/jF3qZb1K5dpHZRYp8jgSO+ZzTlsmUCh5qQE9lr7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIgZyU+tJXHA/2dsb2JhbABCA7RAgQeCGAEBAQMBEgEdGTAFBwQCAQgRBAEBAQoGFwEGAUUJCAEBBAESCBqHZAULmCCfXIsPglqCO2ADiA0zjWiNAIFmgn4 X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="88572558" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 01 Jun 2012 19:40:42 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q51Jegu7007592; Fri, 1 Jun 2012 19:40:42 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jun 2012 14:40:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jun 2012 14:40:41 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [AVTCORE] RTCP traffic class thread-index: Ac1AKflQeGqMDCZrQ8aeSz4UqbdRywAA7Cew References: From: "Mo Zanaty (mzanaty)" To: "Marshall Eubanks" , "Kevin Gross" X-OriginalArrivalTime: 01 Jun 2012 19:40:42.0640 (UTC) FILETIME=[6E468100:01CD402E] Cc: "James Polk \(jmpolk\)" , avt@ietf.org Subject: Re: [AVTCORE] RTCP traffic class 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: Fri, 01 Jun 2012 19:40:44 -0000 RFC 4594 recommends that RTCP and RTP have the same QoS/PHB/DSCP. Also see the update in progress: http://tools.ietf.org/html/draft-polk-tsvwg-rfc4594-update-00 Mo -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Marshall Eubanks Sent: Friday, June 01, 2012 3:09 PM To: Kevin Gross Cc: avt@ietf.org Subject: Re: [AVTCORE] RTCP traffic class On Fri, Jun 1, 2012 at 12:49 PM, Kevin Gross = wrote: > Is there any guidance available as to how RTCP traffic should be = treated by > a network? Should it be given the same QoS as associated RTP traffic = or is > best effort adequate? I have reviewed the RFC 3550, 3551 > and=A0draft-ietf-mmusic-traffic-class-for-sdp and I haven't found a > recommendation. > This is just my opinion, but I have always recommended that RTCP have the same _or better_ QOS than the associated RTP flows : The traffic is small and bounded and (depending on how you are doing = your RTP) RTCP can be crucial to good performance. Regards Marshall > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks -=A0www.AVAnw.com,=A0www.X192.org From kevin.gross@avanw.com Fri Jun 1 13:48:15 2012 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 BE00A11E80E0 for ; Fri, 1 Jun 2012 13:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.53 X-Spam-Level: X-Spam-Status: No, score=0.53 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 TSDSj46Mkae7 for ; Fri, 1 Jun 2012 13:48:15 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id C588211E80CE for ; Fri, 1 Jun 2012 13:48:14 -0700 (PDT) Received: (qmail 696 invoked by uid 0); 1 Jun 2012 20:48:14 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy1.bluehost.com with SMTP; 1 Jun 2012 20:48:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=ZEHyTMCONtO59xUuiVM+vMlMmzh1dO4ToCnY0zKNKlU=; b=Isg/eZf+OuYH9dT6sEc+3vyBvlN41LE5oIhxGzMLxt5LDg44SSCFadhisw73fy4KoiVvWkL3p/vJw8lFvcEgRvKpIJgipdaHbvQI8jLlPk6+97x387KA6LqHydV7WtEV; Received: from mail-wg0-f44.google.com ([74.125.82.44]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1SaYlZ-0007Cf-GV for avt@ietf.org; Fri, 01 Jun 2012 14:48:13 -0600 Received: by wgbdr13 with SMTP id dr13so1615680wgb.13 for ; Fri, 01 Jun 2012 13:48:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.226.32 with SMTP id a32mr2916823weq.190.1338583691867; Fri, 01 Jun 2012 13:48:11 -0700 (PDT) Received: by 10.223.144.216 with HTTP; Fri, 1 Jun 2012 13:48:11 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Jun 2012 14:48:11 -0600 Message-ID: From: Kevin Gross To: "Mo Zanaty (mzanaty)" Content-Type: multipart/alternative; boundary=0016e6de17f374b58104c16f4de8 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.44 authed with kevin.gross@avanw.com} Cc: "James Polk \(jmpolk\)" , avt@ietf.org, Marshall Eubanks Subject: Re: [AVTCORE] RTCP traffic class 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: Fri, 01 Jun 2012 20:48:15 -0000 --0016e6de17f374b58104c16f4de8 Content-Type: text/plain; charset=ISO-8859-1 Thanks Mo, Marshall. I forgot to mention that I had checked RFC 4594 and see one mention of RTCP in section 4.3 but that did not look like a clear and general recommendation. Have I missed something? Section 4.1 of draft-polk-tsvwg-rfc4594-update is quite clear about RTCP classification for the "Conversational Service Class Group" but it is not clear that this is a general recommendation for RTCP. The recommendation to use the same class for RTCP can be a bit tricky at the receiver. The receiver certainly can't rely on incoming DSCP on RTP or SR packets to know how to mark outgoing RRs. Maybe draft-ietf-mmusic-traffic-class-for-sdp helps. Maybe there's a simpler solution. Kevin Gross On Fri, Jun 1, 2012 at 1:40 PM, Mo Zanaty (mzanaty) wrote: > RFC 4594 recommends that RTCP and RTP have the same QoS/PHB/DSCP. > Also see the update in progress: > http://tools.ietf.org/html/draft-polk-tsvwg-rfc4594-update-00 > > Mo > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Marshall Eubanks > Sent: Friday, June 01, 2012 3:09 PM > To: Kevin Gross > Cc: avt@ietf.org > Subject: Re: [AVTCORE] RTCP traffic class > > On Fri, Jun 1, 2012 at 12:49 PM, Kevin Gross > wrote: > > Is there any guidance available as to how RTCP traffic should be treated > by > > a network? Should it be given the same QoS as associated RTP traffic or > is > > best effort adequate? I have reviewed the RFC 3550, 3551 > > and draft-ietf-mmusic-traffic-class-for-sdp and I haven't found a > > recommendation. > > > > This is just my opinion, but I have always recommended that RTCP have > the same _or better_ QOS than the associated RTP flows : > > The traffic is small and bounded and (depending on how you are doing your > RTP) > RTCP can be crucial to good performance. > > Regards > Marshall > > > Kevin Gross > > +1-303-447-0517 > > Media Network Consultant > > AVA Networks - www.AVAnw.com, www.X192.org > > --0016e6de17f374b58104c16f4de8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Mo, Marshall.

I forgot to mention that I had chec= ked RFC 4594 and see one mention of RTCP in section 4.3 but that did not lo= ok like a clear and general recommendation. Have I missed something?

Section 4.1 of=A0draft-polk-tsvwg-rfc4594-u= pdate=A0is quite clear about RTCP=A0classification for the "Conversational Service Class Gro= up" but it is not clear that this is a general recommendation for RTCP= .

The recommendation to use the same class for RTCP can b= e a bit tricky at the receiver. The receiver=A0certainly=A0can't rely o= n incoming DSCP on RTP or SR packets to know how to mark outgoing RRs. Mayb= e=A0draft-ietf-mmusic-traffic-class-for-sdp helps. Maybe there's a simp= ler solution.

Kevin Gross

On Fri, Jun 1, 2012 at 1:40 PM, Mo Zanaty (mzanaty) = <mzanaty@cisco.co= m> wrote:
RFC 4594 recommends that RTCP and RTP have t= he same QoS/PHB/DSCP.
Also see the update in progress:
http://tools.ietf.org/html/draft-polk-tsvwg-rfc4594-update= -00

Mo

-----Original Message-----
From: avt-bounces@ietf.org [mai= lto:avt-bounces@ietf.org] On Be= half Of Marshall Eubanks
Sent: Friday, June 01, 2012 3:09 PM
To: Kevin Gross
Cc: avt@ietf.org
Subject: Re: [AVTCORE] RTCP traffic class

On Fri, Jun 1, 2012 at 12:49 PM, Kevin Gross <kevin.gross@avanw.com> wrote:
> Is there any guidance available as to how RTCP traffic should be treat= ed by
> a network? Should it be given the same QoS as associated RTP traffic o= r is
> best effort adequate? I have reviewed the RFC 3550, 3551
> and=A0draft-ietf-mmusic-traffic-class-for-sdp and I haven't found = a
> recommendation.
>

This is just my opinion, but I have always recommended that RTCP have
the same _or better_ QOS than the associated RTP flows :

The traffic is small and bounded and (depending on how you are doing your R= TP)
RTCP can be crucial to good performance.

Regards
Marshall

> Kevin Gross
> +1-303-447-05= 17
> Media Network Consultant
> AVA Networks -=A0ww= w.AVAnw.com,=A0www.X1= 92.org


--0016e6de17f374b58104c16f4de8-- From mzanaty@cisco.com Fri Jun 1 14:39:30 2012 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 4780411E80E2 for ; Fri, 1 Jun 2012 14:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 68s+Z0arZleA for ; Fri, 1 Jun 2012 14:39:28 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E6A4511E8097 for ; Fri, 1 Jun 2012 14:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mzanaty@cisco.com; l=11539; q=dns/txt; s=iport; t=1338586768; x=1339796368; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=DTvW9HmSkl3e0QovqeDOvJwnxMIsfdkDgmjF51ndx18=; b=HUsZp5NSIVO+uk+g4RP/o9WXdde6wNQWzs0Gkck/YcC6qSBvnC00mKJC El0vBGg2gDUbdhODiDd8RVYNse1Tk13hTsFDv5o8e8ABSZvV+bqoltLsH bI4D2WHkPwcFZoo3n6Cr9XMVerP9MapIRyt/EJMxLQl3bAogSECFLuDmT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFADA1yU+tJXHA/2dsb2JhbABCA4JFqQsBiG+BB4IYAQEBAwESAQkRAxkwBQcEAgEIEQQBAQEKBhcBBgFFCQgBAQQTCBMHh2QFC5ggn2CLD4JagjtgA4hAjWiNAIFmgn4 X-IronPort-AV: E=Sophos;i="4.75,700,1330905600"; d="scan'208,217";a="88791385" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 01 Jun 2012 21:39:27 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q51LdRqj025758; Fri, 1 Jun 2012 21:39:27 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jun 2012 16:39:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD403F.04A135DA" Date: Fri, 1 Jun 2012 16:39:25 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [AVTCORE] RTCP traffic class thread-index: Ac1AN930sX4gq/FVRVCt0nwd6yHO8AABLelw References: From: "Mo Zanaty (mzanaty)" To: "Kevin Gross" X-OriginalArrivalTime: 01 Jun 2012 21:39:27.0244 (UTC) FILETIME=[04DECCC0:01CD403F] Cc: "James Polk \(jmpolk\)" , avt@ietf.org, Marshall Eubanks Subject: Re: [AVTCORE] RTCP traffic class 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: Fri, 01 Jun 2012 21:39:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD403F.04A135DA Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable > Maybe there's a simpler solution. =20 For sendrecv and sendonly sessions, send RTCP using the same DSCP as sent RTP. For recvonly sessions (if that's what you mean by "can be a bit tricky at the receiver"), send RTCP using the same DSCP you would have used for sending RTP (despite not actually sending RTP). =20 This becomes almost mandatory when both use the same port (RFC 5761 rtcp-mux), as it is not always easy (or even possible) in some operating systems to change DSCP per packet on the same port. =20 Mo =20 =20 From: Kevin Gross [mailto:kevin.gross@avanw.com]=20 Sent: Friday, June 01, 2012 4:48 PM To: Mo Zanaty (mzanaty) Cc: Marshall Eubanks; avt@ietf.org; James Polk (jmpolk) Subject: Re: [AVTCORE] RTCP traffic class =20 Thanks Mo, Marshall. =20 I forgot to mention that I had checked RFC 4594 and see one mention of RTCP in section 4.3 but that did not look like a clear and general recommendation. Have I missed something? =20 Section 4.1 of draft-polk-tsvwg-rfc4594-update is quite clear about RTCP classification for the "Conversational Service Class Group" but it is not clear that this is a general recommendation for RTCP. =20 The recommendation to use the same class for RTCP can be a bit tricky at the receiver. The receiver certainly can't rely on incoming DSCP on RTP or SR packets to know how to mark outgoing RRs. Maybe draft-ietf-mmusic-traffic-class-for-sdp helps. Maybe there's a simpler solution. Kevin Gross =20 On Fri, Jun 1, 2012 at 1:40 PM, Mo Zanaty (mzanaty) wrote: RFC 4594 recommends that RTCP and RTP have the same QoS/PHB/DSCP. Also see the update in progress: http://tools.ietf.org/html/draft-polk-tsvwg-rfc4594-update-00 Mo -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Marshall Eubanks Sent: Friday, June 01, 2012 3:09 PM To: Kevin Gross Cc: avt@ietf.org Subject: Re: [AVTCORE] RTCP traffic class On Fri, Jun 1, 2012 at 12:49 PM, Kevin Gross wrote: > Is there any guidance available as to how RTCP traffic should be treated by > a network? Should it be given the same QoS as associated RTP traffic or is > best effort adequate? I have reviewed the RFC 3550, 3551 > and draft-ietf-mmusic-traffic-class-for-sdp and I haven't found a > recommendation. > This is just my opinion, but I have always recommended that RTCP have the same _or better_ QOS than the associated RTP flows : The traffic is small and bounded and (depending on how you are doing your RTP) RTCP can be crucial to good performance. Regards Marshall > Kevin Gross > +1-303-447-0517 =20 > Media Network Consultant > AVA Networks - www.AVAnw.com, www.X192.org =20 ------_=_NextPart_001_01CD403F.04A135DA Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

> Maybe = there's a simpler solution.

 =

For = sendrecv and sendonly sessions, send RTCP using the same DSCP as sent = RTP.

For = recvonly sessions (if that’s what you mean by “can be a bit = tricky at the receiver”),

send RTCP = using the same DSCP you would have used for sending RTP (despite not = actually sending RTP).

 =

This = becomes almost mandatory when both use the same port (RFC 5761 = rtcp-mux), as it is not always easy (or even possible) in some operating = systems to change DSCP per packet on the same = port.

 =

Mo

 =

 =

From:= = Kevin Gross [mailto:kevin.gross@avanw.com]
Sent: Friday, June = 01, 2012 4:48 PM
To: Mo Zanaty (mzanaty)
Cc: = Marshall Eubanks; avt@ietf.org; James Polk (jmpolk)
Subject: = Re: [AVTCORE] RTCP traffic class

 

Thanks Mo, = Marshall.

 

I = forgot to mention that I had checked RFC 4594 and see one mention of = RTCP in section 4.3 but that did not look like a clear and general = recommendation. Have I missed something?

 

Section 4.1 of draft-polk-tsvwg-rfc4594-update is quite = clear about RTCP classification for the "Conversational Service Class Group" but = it is not clear that this is a general recommendation for = RTCP.

 

The recommendation to use the same class for RTCP can = be a bit tricky at the receiver. The receiver certainly can't = rely on incoming DSCP on RTP or SR packets to know how to mark outgoing = RRs. Maybe draft-ietf-mmusic-traffic-class-for-sdp helps. Maybe = there's a simpler solution.


Kevin Gross

 

On Fri, Jun 1, 2012 at 1:40 PM, Mo Zanaty (mzanaty) = <mzanaty@cisco.com> wrote:

RFC 4594 recommends that RTCP and RTP have the same = QoS/PHB/DSCP.
Also see the update in progress:
http://tools.ietf.org/html/draft-polk-tsvwg-rfc4594-upd= ate-00

Mo


-----Original = Message-----
From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf = Of Marshall Eubanks
Sent: Friday, June 01, 2012 3:09 PM
To: Kevin = Gross
Cc: avt@ietf.org
Subject: Re: [AVTCORE] = RTCP traffic class

On Fri, Jun 1, 2012 at 12:49 PM, Kevin Gross = <kevin.gross@avanw.com> = wrote:
> Is there any guidance available as to how RTCP traffic = should be treated by
> a network? Should it be given the same QoS = as associated RTP traffic or is
> best effort adequate? I have = reviewed the RFC 3550, 3551
> = and draft-ietf-mmusic-traffic-class-for-sdp and I haven't found = a
> recommendation.
>

This is just my opinion, but I = have always recommended that RTCP have
the same _or better_ QOS than = the associated RTP flows :

The traffic is small and bounded and = (depending on how you are doing your RTP)
RTCP can be crucial to good = performance.

Regards
Marshall

> Kevin Gross
> = +1-303-447-0517
> Media = Network Consultant
> AVA Networks - www.AVAnw.com, www.X192.org

 

------_=_NextPart_001_01CD403F.04A135DA-- From kevin.gross@avanw.com Fri Jun 1 15:22:17 2012 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 F059E11E8104 for ; Fri, 1 Jun 2012 15:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.43 X-Spam-Level: X-Spam-Status: No, score=0.43 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 B22Up9tqdHsR for ; Fri, 1 Jun 2012 15:22:17 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id C115C11E8097 for ; Fri, 1 Jun 2012 15:22:16 -0700 (PDT) Received: (qmail 378 invoked by uid 0); 1 Jun 2012 22:22:15 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy7.bluehost.com with SMTP; 1 Jun 2012 22:22:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=vR8IJsYuX6iPUmFZpIJl5C2/pNEEv9MNNW5t8WlUU6k=; b=C+V0FN6KdnRXWIGeZmKxUwMPqmw8rV62KJDolAAsKR70XqTPI/0NcRTk53RpOp4mLNK9wnvjZqFhqhCfgeis38W2LIJ5uKr3TCDBIlOxsM3YDKAAjLxY5pbCuKtgZSCd; Received: from mail-wg0-f44.google.com ([74.125.82.44]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1SaaEZ-0006mM-Ax for avt@ietf.org; Fri, 01 Jun 2012 16:22:15 -0600 Received: by wgbdr13 with SMTP id dr13so1657458wgb.13 for ; Fri, 01 Jun 2012 15:22:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.228.152 with SMTP id f24mr2951047weq.85.1338589333836; Fri, 01 Jun 2012 15:22:13 -0700 (PDT) Received: by 10.223.144.216 with HTTP; Fri, 1 Jun 2012 15:22:13 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Jun 2012 16:22:13 -0600 Message-ID: From: Kevin Gross To: "Mo Zanaty (mzanaty)" Content-Type: multipart/alternative; boundary=0016e6dd8ecabe556604c1709d31 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.44 authed with kevin.gross@avanw.com} Cc: "James Polk \(jmpolk\)" , avt@ietf.org, Marshall Eubanks Subject: Re: [AVTCORE] RTCP traffic class 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: Fri, 01 Jun 2012 22:22:18 -0000 --0016e6dd8ecabe556604c1709d31 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, exactly, and it would be nice if such a general statement were published in an RFC at some point. This is the language I had proposed to describe the tricky bit. "Senders must mark RTCP packets they send with the same DSCP value as their respective RTP stream packets. Receivers should mark RTCP packets they send with the same DSCP value they would use on RTP packets if transmitting a similar stream." Kevin Gross On Fri, Jun 1, 2012 at 3:39 PM, Mo Zanaty (mzanaty) wrot= e: > > Maybe there's a simpler solution.**** > > ** ** > > For sendrecv and sendonly sessions, send RTCP using the same DSCP as sent > RTP.**** > > For recvonly sessions (if that=92s what you mean by =93can be a bit trick= y at > the receiver=94),**** > > send RTCP using the same DSCP you would have used for sending RTP (despit= e > not actually sending RTP).**** > > ** ** > > This becomes almost mandatory when both use the same port (RFC 5761 > rtcp-mux), as it is not always easy (or even possible) in some operating > systems to change DSCP per packet on the same port.**** > > ** ** > > Mo**** > > ** ** > > ** ** > > *From:* Kevin Gross [mailto:kevin.gross@avanw.com] > *Sent:* Friday, June 01, 2012 4:48 PM > *To:* Mo Zanaty (mzanaty) > *Cc:* Marshall Eubanks; avt@ietf.org; James Polk (jmpolk) > > *Subject:* Re: [AVTCORE] RTCP traffic class**** > > ** ** > > Thanks Mo, Marshall.**** > > ** ** > > I forgot to mention that I had checked RFC 4594 and see one mention of > RTCP in section 4.3 but that did not look like a clear and general > recommendation. Have I missed something?**** > > ** ** > > Section 4.1 of draft-polk-tsvwg-rfc4594-update is > quite clear about RTCP classification for the "Conversational Service > Class Group" but it is not clear that this is a general recommendation fo= r > RTCP.**** > > ** ** > > The recommendation to use the same class for RTCP can be a bit tricky at > the receiver. The receiver certainly can't rely on incoming DSCP on RTP o= r > SR packets to know how to mark outgoing RRs. > Maybe draft-ietf-mmusic-traffic-class-for-sdp helps. Maybe there's a > simpler solution.**** > > > Kevin Gross**** > > ** ** > > On Fri, Jun 1, 2012 at 1:40 PM, Mo Zanaty (mzanaty) > wrote:**** > > RFC 4594 recommends that RTCP and RTP have the same QoS/PHB/DSCP. > Also see the update in progress: > http://tools.ietf.org/html/draft-polk-tsvwg-rfc4594-update-00 > > Mo**** > > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Marshall Eubanks > Sent: Friday, June 01, 2012 3:09 PM > To: Kevin Gross > Cc: avt@ietf.org > Subject: Re: [AVTCORE] RTCP traffic class > > On Fri, Jun 1, 2012 at 12:49 PM, Kevin Gross > wrote: > > Is there any guidance available as to how RTCP traffic should be treate= d > by > > a network? Should it be given the same QoS as associated RTP traffic or > is > > best effort adequate? I have reviewed the RFC 3550, 3551 > > and draft-ietf-mmusic-traffic-class-for-sdp and I haven't found a > > recommendation. > > > > This is just my opinion, but I have always recommended that RTCP have > the same _or better_ QOS than the associated RTP flows : > > The traffic is small and bounded and (depending on how you are doing your > RTP) > RTCP can be crucial to good performance. > > Regards > Marshall > > > Kevin Gross > > +1-303-447-0517 > > Media Network Consultant > > AVA Networks - www.AVAnw.com, www.X192.org**** > > ** ** > --0016e6dd8ecabe556604c1709d31 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, exactly, and it would be nice if such a general statement were publish= ed in an RFC at some point.=A0This is the language I had proposed to descri= be the tricky bit.

"Senders must mark RTCP packets they send with the same DSCP value as their respecti= ve RTP stream packets. Receivers should mark RTCP packets they send with the s= ame DSCP value they would use on RTP packets if transmitting a similar stream.&= quot;

Kevin Gross

On Fri, Jun 1, 20= 12 at 3:39 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote= :

> Mayb= e there's a simpler solution.

=A0

For sendrecv and sendonly sessions, send RTC= P using the same DSCP as sent RTP.

For recvonly sessions (if that=92s what= you mean by =93can be a bit tricky at the receiver=94),

send RTCP using the same DSCP you would= have used for sending RTP (despite not actually sending RTP).

=A0

This becomes almost mandatory when both use the sa= me port (RFC 5761 rtcp-mux), as it is not always easy (or even possible) in= some operating systems to change DSCP per packet on the same port.<= u>

=A0

Mo

=A0

=A0

From: Kevin Gr= oss [mailto:kevi= n.gross@avanw.com]
Sent: Friday, June 01, 2012 4:48 PM
To: Mo Zanaty (mzanaty= )
Cc: Marshall Eubanks; avt@ietf.org; James Polk (jmpolk)


Subject: Re: [AVTCORE] RTCP traffic class

=A0

Thanks Mo, Marshall.

=A0

I forgot to mention = that I had checked RFC 4594 and see one mention of RTCP in section 4.3 but = that did not look like a clear and general recommendation. Have I missed so= mething?

=A0

Section 4.1 of=A0draft-polk-tsvwg-rfc4594-update=A0is quite clear about RTCP=A0classification for the "Conversational Service Class Group" but it is no= t clear that this is a general recommendation for RTCP.

=A0

The recommendation to use the same class for RTCP can be a b= it tricky at the receiver. The receiver=A0certainly=A0can't rely on inc= oming DSCP on RTP or SR packets to know how to mark outgoing RRs. Maybe=A0d= raft-ietf-mmusic-traffic-class-for-sdp helps. Maybe there's a simpler s= olution.


Kevin Gross

=A0

On Fri, Jun 1, 2012 at 1:40 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com>= ; wrote:

RFC 4594 recommends that RTCP and RTP have the same = QoS/PHB/DSCP.
Also see the update in progress:
http:= //tools.ietf.org/html/draft-polk-tsvwg-rfc4594-update-00

Mo

<= div>


-----Ori= ginal Message-----
From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Marshall= Eubanks
Sent: Friday, June 01, 2012 3:09 PM
To: Kevin Gross
Cc: avt@ietf.org
Subject: Re: [AVTC= ORE] RTCP traffic class

On Fri, Jun 1, 2012 at 12:49 PM, Kevin Gross= <kevin.gross= @avanw.com> wrote:
> Is there any guidance available as to how RTCP traffic should be treat= ed by
> a network? Should it be given the same QoS as associated RTP = traffic or is
> best effort adequate? I have reviewed the RFC 3550, 3= 551
> and=A0draft-ietf-mmusic-traffic-class-for-sdp and I haven't found = a
> recommendation.
>

This is just my opinion, but I hav= e always recommended that RTCP have
the same _or better_ QOS than the as= sociated RTP flows :

The traffic is small and bounded and (depending on how you are doing yo= ur RTP)
RTCP can be crucial to good performance.

Regards
Marsh= all

> Kevin Gross
> +1-303-447-0517
> Media Network Consultant
> AVA Networks -=A0www.AVAnw.com,=A0www.X192.org

=A0


--0016e6dd8ecabe556604c1709d31-- From kevin.gross@avanw.com Fri Jun 1 16:13:18 2012 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 2D9CF11E811C for ; Fri, 1 Jun 2012 16:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.369 X-Spam-Level: X-Spam-Status: No, score=0.369 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 bKvp3BlOzSdb for ; Fri, 1 Jun 2012 16:13:17 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 61AD911E808D for ; Fri, 1 Jun 2012 16:13:17 -0700 (PDT) Received: (qmail 22387 invoked by uid 0); 1 Jun 2012 23:13:14 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy7.bluehost.com with SMTP; 1 Jun 2012 23:13:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:To:From:Subject:Message-ID:Date:MIME-Version; bh=iJYtlPhbprl8/mUoGuizZzxSrRiHcCZzlfZSaHpArdw=; b=LCv5UI4gsQEeRlmJ2mCNRaff/eMIHfYFsu7eA0mnktVrgASZlhFdts1SrVMWckFA4CeomFFm+TmA/lgch/6gYZfhpB+i1ZgU1QITrj4g615aV6QIFSR917IuSA6L91Iw; Received: from mail-wg0-f44.google.com ([74.125.82.44]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1Sab1u-0002q2-DV for avt@ietf.org; Fri, 01 Jun 2012 17:13:14 -0600 Received: by wgbdr13 with SMTP id dr13so1673956wgb.13 for ; Fri, 01 Jun 2012 16:13:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.228.152 with SMTP id f24mr3045404weq.85.1338592392660; Fri, 01 Jun 2012 16:13:12 -0700 (PDT) Received: by 10.223.144.216 with HTTP; Fri, 1 Jun 2012 16:13:12 -0700 (PDT) Date: Fri, 1 Jun 2012 17:13:12 -0600 Message-ID: From: Kevin Gross To: avt@ietf.org Content-Type: multipart/alternative; boundary=0016e6dd8eca1045a604c17154f3 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.44 authed with kevin.gross@avanw.com} Subject: [AVTCORE] ASCII representation for RFC 6222 CNAME 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: Fri, 01 Jun 2012 23:13:18 -0000 --0016e6dd8eca1045a604c17154f3 Content-Type: text/plain; charset=ISO-8859-1 I'm working on a revision to draft-williams-avtcore-clksource and it looks like for media clock identification, I need to specify a CNAME in SDP. Although RFC 6222 says it supersedes RFC 3550 section 6.5.1, I assume the ASCII format for the CNAME field described in 6.5.1 is retained. The new CNAME definition in RFC 6222 produces a 256-bit binary value. There is no discussion in RFC 6222 as to how that should be formatted for inclusion in SDES. What is the recommended ASCII representation for the 256 binary CNAME for inclusion in SDES or SDP? Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org --0016e6dd8eca1045a604c17154f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm working on a revision to draft-williams-avtcore-clksource and it lo= oks like for media clock identification, I need to specify a CNAME in SDP.= =A0 Although RFC 6222 says it=A0supersedes=A0RFC 3550 section 6.5.1, I assume t= he ASCII format for the CNAME field described in 6.5.1 is retained.=A0=A0Th= e new CNAME definition in RFC 6222 produces a 256-bit binary value. There i= s no discussion in RFC 6222 as to how that should be formatted for inclusio= n in SDES. What is the recommended ASCII representation for the 256 binary = CNAME for inclusion in SDES or SDP?

Kevin Gross
+1-303-447-0517
Media Netwo= rk Consultant
AVA Networks -=A0www.AVAnw.com,=A0www.X192.org

--0016e6dd8eca1045a604c17154f3-- From jmpolk@cisco.com Fri Jun 1 16:43:17 2012 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 3466911E809A for ; Fri, 1 Jun 2012 16:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 5P+3shRUoNFC for ; Fri, 1 Jun 2012 16:43:16 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAFF11E8081 for ; Fri, 1 Jun 2012 16:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=4055; q=dns/txt; s=iport; t=1338594196; x=1339803796; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=ML0YoeHHxifryJbJ+DZALw+WNG9z+9SUgOOTbCcpfwc=; b=PrjT9wDeyTTvdFJEYh+Fp2Hl8zFOQjBzW5uydjFC9IcxIlrSuXoOLogO TsbR5bdD1fUBf26bRaVyaGn9R9YMhle7MDgU1V7DlWRK142zJYuJBcJ1F TA84dunOeLrMiEHK5c+NpYIdA+6Gyc0w6vZkec63NundJwfKRH5PFMo6J Q=; X-IronPort-AV: E=Sophos;i="4.75,700,1330905600"; d="scan'208";a="47349727" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 01 Jun 2012 23:43:16 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q51NhFAi014384; Fri, 1 Jun 2012 23:43:15 GMT Message-Id: <201206012343.q51NhFAi014384@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 Jun 2012 18:43:12 -0500 To: Kevin Gross From: James Polk In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "James Polk \(jmpolk\)" , avt@ietf.org, Marshall Eubanks Subject: Re: [AVTCORE] RTCP traffic class 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: Fri, 01 Jun 2012 23:43:17 -0000 Kevin Where would you like to see this sort of text (i.e., in which draft)? If in SDP, do you mind making that comment on the MMUSIC list? If as a part of DSCP guidelines, do you mind making that comment on the TSVWG list? James At 05:22 PM 6/1/2012, Kevin Gross wrote: >Yes, exactly, and it would be nice if such a general statement were >published in an RFC at some point. This is the language I had >proposed to describe the tricky bit. > >"Senders must mark RTCP packets they send with the same DSCP value >as their respective RTP stream packets. Receivers should mark RTCP >packets they send with the same DSCP value they would use on RTP >packets if transmitting a similar stream." > >Kevin Gross > >On Fri, Jun 1, 2012 at 3:39 PM, Mo Zanaty (mzanaty) ><mzanaty@cisco.com> wrote: > > > Maybe there's a simpler solution. > > > >For sendrecv and sendonly sessions, send RTCP using the same DSCP as sent RTP. > >For recvonly sessions (if that's what you mean by "can be a bit >tricky at the receiver"), > >send RTCP using the same DSCP you would have used for sending RTP >(despite not actually sending RTP). > > > >This becomes almost mandatory when both use the same port (RFC 5761 >rtcp-mux), as it is not always easy (or even possible) in some >operating systems to change DSCP per packet on the same port. > > > >Mo > > > > > >From: Kevin Gross [mailto:kevin.gross@avanw.com] >Sent: Friday, June 01, 2012 4:48 PM >To: Mo Zanaty (mzanaty) >Cc: Marshall Eubanks; avt@ietf.org; James Polk (jmpolk) > >Subject: Re: [AVTCORE] RTCP traffic class > > > >Thanks Mo, Marshall. > > > >I forgot to mention that I had checked RFC 4594 and see one mention >of RTCP in section 4.3 but that did not look like a clear and >general recommendation. Have I missed something? > > > >Section 4.1 of >draft-polk-tsvwg-rfc4594-update >is quite clear about RTCP classification for the "Conversational >Service Class Group" but it is not clear that this is a general >recommendation for RTCP. > > > >The recommendation to use the same class for RTCP can be a bit >tricky at the receiver. The receiver certainly can't rely on >incoming DSCP on RTP or SR packets to know how to mark outgoing RRs. >Maybe draft-ietf-mmusic-traffic-class-for-sdp helps. Maybe there's a >simpler solution. > > >Kevin Gross > > > >On Fri, Jun 1, 2012 at 1:40 PM, Mo Zanaty (mzanaty) ><mzanaty@cisco.com> wrote: > >RFC 4594 recommends that RTCP and RTP have the same QoS/PHB/DSCP. >Also see the update in progress: >http://tools.ietf.org/html/draft-polk-tsvwg-rfc4594-update-00 > >Mo > > >-----Original Message----- >From: avt-bounces@ietf.org >[mailto:avt-bounces@ietf.org] On Behalf Of Marshall Eubanks >Sent: Friday, June 01, 2012 3:09 PM >To: Kevin Gross >Cc: avt@ietf.org >Subject: Re: [AVTCORE] RTCP traffic class > >On Fri, Jun 1, 2012 at 12:49 PM, Kevin Gross ><kevin.gross@avanw.com> wrote: > > Is there any guidance available as to how RTCP traffic should be treated by > > a network? Should it be given the same QoS as associated RTP traffic or is > > best effort adequate? I have reviewed the RFC 3550, 3551 > > and draft-ietf-mmusic-traffic-class-for-sdp and I haven't found a > > recommendation. > > > >This is just my opinion, but I have always recommended that RTCP have >the same _or better_ QOS than the associated RTP flows : > >The traffic is small and bounded and (depending on how you are doing your RTP) >RTCP can be crucial to good performance. > >Regards >Marshall > > > Kevin Gross > > +1-303-447-0517 > > Media Network Consultant > > AVA Networks - www.AVAnw.com, www.X192.org > > > From kevin.gross@avanw.com Fri Jun 1 17:08:15 2012 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 11A5C11E8091 for ; Fri, 1 Jun 2012 17:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.794 X-Spam-Level: * X-Spam-Status: No, score=1.794 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_HTML_USL_OBFU=1.666] 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 sq9qzQTr3f3c for ; Fri, 1 Jun 2012 17:08:14 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id B2AE011E808F for ; Fri, 1 Jun 2012 17:08:13 -0700 (PDT) Received: (qmail 7168 invoked by uid 0); 2 Jun 2012 00:08:13 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy7.bluehost.com with SMTP; 2 Jun 2012 00:08:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=qLJjBsV69jYyvx+2oDObofmH6a6J3w0Q9B2cbiZh7kM=; b=bTm7v3K/pUcHJpSmEvAQ31h1BxpWzLrPzGSSCqXlHbgs6v2ffhIJA7CATE1M7/IDEv7lXH5MXGkia7S6pB9G9rmKhPBs2NeQapmrF41LDAsaDTVIZP7qtfBKzDRQ4h4F; Received: from mail-wi0-f178.google.com ([209.85.212.178]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1Sabt6-0000Ft-MW for avt@ietf.org; Fri, 01 Jun 2012 18:08:13 -0600 Received: by wibhn6 with SMTP id hn6so919106wib.13 for ; Fri, 01 Jun 2012 17:08:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.54.206 with SMTP id i56mr3284572wec.28.1338595690945; Fri, 01 Jun 2012 17:08:10 -0700 (PDT) Received: by 10.223.144.216 with HTTP; Fri, 1 Jun 2012 17:08:10 -0700 (PDT) In-Reply-To: <201206012343.q51NhFAi014384@mtv-core-2.cisco.com> References: <201206012343.q51NhFAi014384@mtv-core-2.cisco.com> Date: Fri, 1 Jun 2012 18:08:10 -0600 Message-ID: From: Kevin Gross To: James Polk Content-Type: multipart/alternative; boundary=0016e6de000da81ecb04c17218c8 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.212.178 authed with kevin.gross@avanw.com} Cc: avt@ietf.org, Marshall Eubanks Subject: Re: [AVTCORE] RTCP traffic class 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: Sat, 02 Jun 2012 00:08:15 -0000 --0016e6de000da81ecb04c17218c8 Content-Type: text/plain; charset=ISO-8859-1 I would actually expect to find it in RFC 3550. The second place I'd look is a DiffServ RFC (e.g. RFC 4594). It's not really an SDP issue though draft-polk-mmusic-traffic-class-for-sdp might want to include an informative reference. Kevin Gross On Fri, Jun 1, 2012 at 5:43 PM, James Polk wrote: > Kevin > > Where would you like to see this sort of text (i.e., in which draft)? > > If in SDP, do you mind making that comment on the MMUSIC list? > > If as a part of DSCP guidelines, do you mind making that comment on the > TSVWG list? > > James > > > At 05:22 PM 6/1/2012, Kevin Gross wrote: > >> Yes, exactly, and it would be nice if such a general statement were >> published in an RFC at some point. This is the language I had proposed to >> describe the tricky bit. >> >> "Senders must mark RTCP packets they send with the same DSCP value as >> their respective RTP stream packets. Receivers should mark RTCP packets >> they send with the same DSCP value they would use on RTP packets if >> transmitting a similar stream." >> >> Kevin Gross >> >> On Fri, Jun 1, 2012 at 3:39 PM, Mo Zanaty (mzanaty) <> mzanaty@cisco.com>mza**naty@cisco.com > wrote: >> >> > Maybe there's a simpler solution. >> >> >> >> For sendrecv and sendonly sessions, send RTCP using the same DSCP as sent >> RTP. >> >> For recvonly sessions (if that's what you mean by "can be a bit tricky at >> the receiver"), >> >> send RTCP using the same DSCP you would have used for sending RTP >> (despite not actually sending RTP). >> >> >> >> This becomes almost mandatory when both use the same port (RFC 5761 >> rtcp-mux), as it is not always easy (or even possible) in some operating >> systems to change DSCP per packet on the same port. >> >> >> >> Mo >> >> >> >> >> >> From: Kevin Gross [mailto:kevin.gross@avanw.com] >> Sent: Friday, June 01, 2012 4:48 PM >> To: Mo Zanaty (mzanaty) >> Cc: Marshall Eubanks; avt@ietf.**org ; >> James Polk (jmpolk) >> >> >> Subject: Re: [AVTCORE] RTCP traffic class >> >> >> >> Thanks Mo, Marshall. >> >> >> >> I forgot to mention that I had checked RFC 4594 and see one mention of >> RTCP in section 4.3 but that did not look like a clear and general >> recommendation. Have I missed something? >> >> >> >> Section 4.1 of > update-00 >> >draft-polk-tsvwg-**rfc4594-update is quite clear about RTCP >> classification for the "Conversational Service Class Group" but it is not >> clear that this is a general recommendation for RTCP. >> >> >> >> >> The recommendation to use the same class for RTCP can be a bit tricky at >> the receiver. The receiver certainly can't rely on incoming DSCP on RTP or >> SR packets to know how to mark outgoing RRs. Maybe >> draft-ietf-mmusic-traffic-**class-for-sdp helps. Maybe there's a simpler >> solution. >> >> >> Kevin Gross >> >> >> >> On Fri, Jun 1, 2012 at 1:40 PM, Mo Zanaty (mzanaty) <> mzanaty@cisco.com>mza**naty@cisco.com > wrote: >> >> RFC 4594 recommends that RTCP and RTP have the same QoS/PHB/DSCP. >> Also see the update in progress: >> >> >http://tools.ietf.**org/html/draft-polk-tsvwg-**rfc4594-update-00 >> >> Mo >> >> >> >> -----Original Message----- >> From: a**vt-bounces@ietf.org[mailto: >> avt-bounces@ietf.org] On Behalf Of Marshall Eubanks >> Sent: Friday, June 01, 2012 3:09 PM >> To: Kevin Gross >> Cc: avt@ietf.**org >> Subject: Re: [AVTCORE] RTCP traffic class >> >> On Fri, Jun 1, 2012 at 12:49 PM, Kevin Gross <> kevin.gross@avanw.com**>kevin.gross@avanw.com> wrote: >> > Is there any guidance available as to how RTCP traffic should be >> treated by >> > a network? Should it be given the same QoS as associated RTP traffic or >> is >> > best effort adequate? I have reviewed the RFC 3550, 3551 >> > and draft-ietf-mmusic-traffic-**class-for-sdp and I haven't found a >> > recommendation. >> > >> >> This is just my opinion, but I have always recommended that RTCP have >> the same _or better_ QOS than the associated RTP flows : >> >> The traffic is small and bounded and (depending on how you are doing your >> RTP) >> RTCP can be crucial to good performance. >> >> Regards >> Marshall >> >> > Kevin Gross >> > +1-303-447-0517 >> > Media Network Consultant >> > AVA Networks - www.**AVAnw.com, >> www.X192.org >> >> >> >> > --0016e6de000da81ecb04c17218c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would actually expect to find it in RFC 3550. The second place I'd lo= ok is a DiffServ RFC (e.g. RFC 4594). It's not really an SDP issue thou= gh=A0draft-polk-mmusic-traffic-class-for-sdp might want to include an=A0inf= ormative=A0reference.

Kevin Gross

= On Fri, Jun 1, 2012 at 5:43 PM, James Polk <jmpolk@cisco.com>= wrote:
Kevin

Where would you like to see this sort of text (i.e., in which draft)?

If in SDP, do you mind making that comment on the MMUSIC list?

If as a part of DSCP guidelines, do you mind making that comment on the TSV= WG list?

James


At 05:22 PM 6/1/2012, Kevin Gross wrote:
Yes, exactly, and it would be nice if such a general statement were publish= ed in an RFC at some point. This is the language I had proposed to describe= the tricky bit.

"Senders must mark RTCP packets they send with the same DSCP value as = their respective RTP stream packets. Receivers should mark RTCP packets the= y send with the same DSCP value they would use on RTP packets if transmitti= ng a similar stream."

Kevin Gross

On Fri, Jun 1, 2012 at 3:39 PM, Mo Zanaty (mzanaty) <<mailto:mzanaty@cisco.com>mzanaty@cisco.c= om> wrote:

> Maybe there's a simpler solution.



For sendrecv and sendonly sessions, send RTCP using the same DSCP as sent R= TP.

For recvonly sessions (if that's what you mean by "can be a bit tr= icky at the receiver"),

send RTCP using the same DSCP you would have used for sending RTP (despite = not actually sending RTP).



This becomes almost mandatory when both use the same port (RFC 5761 rtcp-mu= x), as it is not always easy (or even possible) in some operating systems t= o change DSCP per packet on the same port.



Mo





From: Kevin Gross [mailto:kevin.gross@avanw.com]
Sent: Friday, June 01, 2012 4:48 PM
To: Mo Zanaty (mzanaty)
Cc: Marshall Eubanks; <mailto:avt@ietf.org>avt@ietf.org; James Polk (jmpolk)


Subject: Re: [AVTCORE] RTCP traffic class



Thanks Mo, Marshall.



I forgot to mention that I had checked RFC 4594 and see one mention of RTCP= in section 4.3 but that did not look like a clear and general recommendati= on. Have I missed something?



Section 4.1 of <http://tools.ietf.org/html/draft= -polk-tsvwg-rfc4594-update-00>draft-polk-tsvwg-rfc4594= -update is quite clear about RTCP classification for the "Conversation= al Service Class Group" but it is not clear that this is a general rec= ommendation for RTCP.




The recommendation to use the same class for RTCP can be a bit tricky at th= e receiver. The receiver certainly can't rely on incoming DSCP on RTP o= r SR packets to know how to mark outgoing RRs. Maybe draft-ietf-mmusic-traf= fic-class-for-sdp helps. Maybe there's a simpler solution.


Kevin Gross



On Fri, Jun 1, 2012 at 1:40 PM, Mo Zanaty (mzanaty) <<mailto:mzanaty@cisco.com>mzanaty@cisco.c= om> wrote:

RFC 4594 recommends that RTCP and RTP have the same QoS/PHB/DSCP.
Also see the update in progress:
<http://tools.ietf.org/html/draft-polk-tsvwg-rfc= 4594-update-00>http://tools.ietf.org/= html/draft-polk-tsvwg-rfc4594-update-00

Mo



-----Original Message-----
From: <mailto:= avt-bounces@ietf.org>avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of M= arshall Eubanks
Sent: Friday, June 01, 2012 3:09 PM
To: Kevin Gross
Cc: <mailto:avt@ietf.o= rg>avt@ietf.org
Subject: Re: [AVTCORE] RTCP traffic class

On Fri, Jun 1, 2012 at 12:49 PM, Kevin Gross <<mailto:kevin.gross@avanw.com>kevin.gross= @avanw.com> wrote:
> Is there any guidance available as to how RTCP traffic should be treat= ed by
> a network? Should it be given the same QoS as associated RTP traffic o= r is
> best effort adequate? I have reviewed the RFC 3550, 3551
> and draft-ietf-mmusic-traffic-class-for-sdp and I haven't f= ound a
> recommendation.
>

This is just my opinion, but I have always recommended that RTCP have
the same _or better_ QOS than the associated RTP flows :

The traffic is small and bounded and (depending on how you are doing your R= TP)
RTCP can be crucial to good performance.

Regards
Marshall

> Kevin Gross
> <tel:%2B1-303-447-0517>+1-303-447-0517
> Media Network Consultant
> AVA Networks - <= http://www.AVAnw.com>www.AVAnw.com, www.X192.org





--0016e6de000da81ecb04c17218c8-- From csp@csperkins.org Sat Jun 2 08:53:02 2012 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 95D4121F8564 for ; Sat, 2 Jun 2012 08:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=0.900, 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 jm1-Al7jzfr3 for ; Sat, 2 Jun 2012 08:53:02 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id E88F621F8565 for ; Sat, 2 Jun 2012 08:53:01 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.11]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SaqdQ-0000xD-ie; Sat, 02 Jun 2012 15:53:00 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: Date: Sat, 2 Jun 2012 16:52:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <55D7C468-DF2E-4AFA-BEBE-74AAAE22C1CE@csperkins.org> References: To: Kevin Gross X-Mailer: Apple Mail (2.1278) Cc: avt@ietf.org Subject: Re: [AVTCORE] ASCII representation for RFC 6222 CNAME 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: Sat, 02 Jun 2012 15:53:02 -0000 On 2 Jun 2012, at 00:13, Kevin Gross wrote: > I'm working on a revision to draft-williams-avtcore-clksource and it = looks like for media clock identification, I need to specify a CNAME in = SDP. Although RFC 6222 says it supersedes RFC 3550 section 6.5.1, I = assume the ASCII format for the CNAME field described in 6.5.1 is = retained. The new CNAME definition in RFC 6222 produces a 256-bit = binary value. There is no discussion in RFC 6222 as to how that should = be formatted for inclusion in SDES. What is the recommended ASCII = representation for the 256 binary CNAME for inclusion in SDES or SDP? Section 4.2 of RFC 6222 describes how these are converted to printable = ASCII values suitable for use in the RTCP CNAME. --=20 Colin Perkins http://csperkins.org/ From richard.ejzak@alcatel-lucent.com Sun Jun 3 16:08:02 2012 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 94D7F21F875E for ; Sun, 3 Jun 2012 16:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.99 X-Spam-Level: X-Spam-Status: No, score=-9.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259] 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 z--7hfw2kSKZ for ; Sun, 3 Jun 2012 16:08:02 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 406B421F875C for ; Sun, 3 Jun 2012 16:07:56 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q53N7sPx030449 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 4 Jun 2012 01:07:54 +0200 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 4 Jun 2012 01:07:54 +0200 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.235]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Sun, 3 Jun 2012 19:07:52 -0400 From: "Ejzak, Richard P (Richard)" To: "avt@ietf.org" Thread-Topic: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt Thread-Index: AQHNQd2z8lXzEWDYjEaIDVDEgAIhBw== Date: Sun, 3 Jun 2012 23:07:51 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92FC2F2@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt 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: Sun, 03 Jun 2012 23:08:02 -0000 http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt In response to the chairs' request for additional input on the multi sessio= n issue, I have submitted this draft for your consideration. There are sup= erficial similarities with an expired draft from last year in http://tools.= ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has a differ= ent take on the use of SSRC as the basis for multi session multiplexing tha= t I think is superior and worthy of consideration as a potential replacemen= t for BUNDLE and/or SHIM. Please comment. Richard -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Sunday, June 03, 2012 5:16 PM To: Ejzak, Richard P (Richard) Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-0= 0.txt A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been s= uccessfully submitted by Richard Ejzak and posted to the IETF repository. Filename: draft-ejzak-avtcore-rtp-subsessions Revision: 00 Title: Media multiplexing with Real-time Transport Protocol (RTP) subsess= ions Creation date: 2012-06-04 WG ID: Individual Submission Number of pages: 9 Abstract: This document describes a means of multiplexing RTP streams having different media types within a single transport connection and how to represent this multiplexing option in SDP. This mechanism is an alternative to the BUNDLE and SHIM proposals currently under active consideration in AVTCORE. Instead of adding an extra multiplexing header as in SHIM to allow multiple RTP sessions within a single transport connection, or using the payload type field to separate different media streams within a single RTP session, this document describes how to partition the existing SSRC space to create RTP subsessions from a single RTP session. A filter can be used to identify each RTP subsession for different QoS handling as necessary. RTP subsessions can be treated like RTP sessions with a few restrictions. In particular, SSRC mapping may be needed when forwarding RTP streams into an RTP subsession to avoid SSRC conflicts, but there are few use cases in which this limitation is a concern and RTP subsessions can be disabled if necessary. = =20 The IETF Secretariat From csp@csperkins.org Mon Jun 4 04:48:37 2012 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 0051221F86F8 for ; Mon, 4 Jun 2012 04:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.149 X-Spam-Level: X-Spam-Status: No, score=-103.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 yoRnc9qDCFEo for ; Mon, 4 Jun 2012 04:48:36 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by ietfa.amsl.com (Postfix) with ESMTP id 18BFA21F878B for ; Mon, 4 Jun 2012 04:48:36 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.11]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SbVly-0004Uj-Z9; Mon, 04 Jun 2012 11:48:35 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <4FC62550.7000707@ericsson.com> Date: Mon, 4 Jun 2012 12:48:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3494BD00-B0E7-4E8A-B9DE-2AAE51898AD7@csperkins.org> References: <20120529022556.7241.72727.idtracker@ietfa.amsl.com> <4FC62550.7000707@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1278) Cc: albrechtschwarz@yahoo.de, IETF AVTCore WG Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-14.txt 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: Mon, 04 Jun 2012 11:48:37 -0000 Magnus, I reviewed the changes between -13 and -14. It is perhaps a shame that = Figure 1 is removed, but the other changes look okay to me. Colin On 30 May 2012, at 14:49, Magnus Westerlund wrote: > WG, Colin and Albrecht, >=20 > Please check if you think the changes in this version are appropriate. >=20 > Cheers >=20 > Magnus >=20 > On 2012-05-29 04:25, internet-drafts@ietf.org wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Audio/Video Transport Core = Maintenance Working Group of the IETF. >>=20 >> Title : Monitoring Architecture for RTP >> Author(s) : Qin Wu >> Geoff Hunt >> Philip Arden >> Filename : draft-ietf-avtcore-monarch-14.txt >> Pages : 27 >> Date : 2012-05-28 >>=20 >> This memo proposes an architecture for extending RTP Control = Protocol >> (RTCP) with a new RTCP Extended Reports (XR) (RFC3611) block type = to >> report new metrics regarding media transmission or reception = quality, >> following RTCP guidelines established in RFC5968. This memo = suggests >> that a new block should contain a single metric or a small number = of >> metrics relevant to a single parameter of interest or concern, = rather >> than containing a number of metrics which attempt to provide full >> coverage of all those parameters of concern to a specific >> application. Applications may then "mix and match" to create a set >> of blocks which covers their set of concerns. Where possible, a >> specific block should be designed to be re-usable across more than >> one application, for example, for all of voice, streaming audio and >> video. >>=20 >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-14.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-14.txt >>=20 >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >>=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon Jun 4 04:52:56 2012 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 9F54321F86BE for ; Mon, 4 Jun 2012 04:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 DgjkVGRsKruU for ; Mon, 4 Jun 2012 04:52:50 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id E6FB221F86B5 for ; Mon, 4 Jun 2012 04:52:49 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.11]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SbVq4-0001eD-cE; Mon, 04 Jun 2012 11:52:48 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Colin Perkins X-Priority: 3 In-Reply-To: Date: Mon, 4 Jun 2012 12:52:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120529022556.7241.72727.idtracker@ietfa.amsl.com><4FC62550.7000707@ericsson.com> <4FC62E7D.30402@ericsson.com><114BEA37E68543458F3F22DFC709324E@china.huawei.com> <4FC71297.6080800@ericsson.com> To: Qin Wu X-Mailer: Apple Mail (2.1278) Cc: Magnus Westerlund , avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-14.txt 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: Mon, 04 Jun 2012 11:52:56 -0000 On 31 May 2012, at 09:35, Qin Wu wrote: > ----- Original Message -----=20 > From: "Magnus Westerlund" > To: "Qin Wu" > Cc: > Sent: Thursday, May 31, 2012 2:41 PM > Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-14.txt >=20 >=20 > On 2012-05-31 04:03, Qin Wu wrote: >=20 >>=20 >> [Qin]: I thought the figure 1 has already been incoporated into = setion 3 and replaced by the description in the section 3. >> Based on your comment, I can propose to have the following figure >>=20 >> +------------| >> ------------------>| |<------------------ >> | | Management | | >> | | System <----- | >> | | | | | >> | +------^-----+ | | >> | | | | >> | | | | >> | +---------------+ | | >> | | | | | >> | | Third Party | | | >> | | RTP Monitor | | | >> | | | | | >> | +---------------+ | | >> | | | >> +-------|-------+ +Intermediate --+ | +--------|------+ >> |RTP Sender | | RTP System | | |RTP Receiver | >> | | | |--- | | >> | +-----------+ | | +-----------+ | | +-----------+ | >> | |RTP Monitor| | RTP | |RTP Monitor| | RTP | |RTP Monitor| | >> | +-----------+ | Stream | +-----------+ |Stream | +-----------+ | >> | |-------->| |------>| | >> | | | | | | >> +---------------+ +---------------+ +---------------+ >> Is this figure what you are looking for? >=20 > Mostly. I don't know if we need to have the Management system in the > picture. What I was looking for was the lower part. The one thing I > think is poorly covered in the above figure is how a third party = monitor > gets to the information it monitors. To my understanding it exists in > two flavors. A passive monitor that sees the RTP/RTCP stream pass it, = or > a system that gets sent RTCP reports but not RTP and uses that to > collect information. >=20 > [Qin]: You are right, actually these two flavors have been described = in the figur 1 of previous version -13. > I can fix the figure I proposed above with the following change: >=20 > +---------------+ > | | > |-->| Third Party | > | | RTP Monitor | > | | | > | +---------|-----+ > |Metric Report| > --------------- > RTP Stream >=20 > Metric > +------- -------+ Metric +Intermediate --+Report +---------------+ > |RTP Sender | Report | RTP System | |RTP Receiver | > | +-----------+ | | +-----------+ | | +-----------+ | > | |RTP Monitor|<------------|RTP Monitor|<----------|RTP Monitor| | > | +-----------+ | | +-----------+ | | +-----------+ | > | | RTP | | RTP | | > | | Stream | |Stream | | > | |-------->| |------>| | > +---------------+ +---------------+ +---------------+ A problem with both versions of the figure is that the Third Party RTP = Monitor appears disconnected from the RTP streams that it's supposed to = be monitoring. --=20 Colin Perkins http://csperkins.org/ From wwwrun@rfc-editor.org Mon Jun 4 21:20:57 2012 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 A12EF21F8672 for ; Mon, 4 Jun 2012 21:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.153 X-Spam-Level: X-Spam-Status: No, score=-102.153 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, NO_RELAYS=-0.001, 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 R+ohX0yQTAq4 for ; Mon, 4 Jun 2012 21:20:57 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E0BC321F8670 for ; Mon, 4 Jun 2012 21:20:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B7C30B1E002; Mon, 4 Jun 2012 21:19:57 -0700 (PDT) To: magnus.westerlund@ericsson.com, ingemar.s.johansson@ericsson.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, keith.drage@alcatel-lucent.com, even.roni@huawei.com From: RFC Errata System Message-Id: <20120605041957.B7C30B1E002@rfc-editor.org> Date: Mon, 4 Jun 2012 21:19:57 -0700 (PDT) Cc: avt@ietf.org, ravikumar@huawei.com, rfc-editor@rfc-editor.org Subject: [AVTCORE] [Technical Errata Reported] RFC5404 (3245) 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, 05 Jun 2012 04:20:58 -0000 The following errata report has been submitted for RFC5404, "RTP Payload Format for G.719". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5404&eid=3245 -------------------------------------- Type: Technical Reported by: int-delay ABNF does not match to example mention in RFC Section: 7.1 Original Text ------------- 7.1. Media Type Definition int-delay: int-delay = "int-delay:" source-delay *("," source-delay) source-delay = SSRC ":" delay-value SSRC = 1*8HEXDIG ; The 32-bit SSRC encoded in hex format delay-value = 1*5DIGIT ; The delay value in milliseconds Example: int-delay=ABCD1234:1000,4321DCB:640 NOTE: No white space allowed in the parameter before the end of all the value pairs Corrected Text -------------- int-delay = "int-delay=" source-delay *("," source-delay) source-delay = SSRC ":" delay-value SSRC = 1*8HEXDIG ; The 32-bit SSRC encoded in hex format delay-value = 1*5DIGIT ; The delay value in milliseconds Example: int-delay=ABCD1234:1000,4321DCB:640 NOTE: No white space allowed in the parameter before the end of all the value pairs Notes ----- "int-delay:" need to change to "int-delay=" 7.2. Mapping to SDP o Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the media type parameter string as a semicolon-separated list of parameter=value pairs. As per section 7.2 int-delay parameter should be part of a=fmtp line and it should have parameter as parameter=value pair. But as per ABNF it should be int-delay: Also example mentions that int-delay= Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5404 (draft-ietf-avt-rtp-g719-04) -------------------------------------- Title : RTP Payload Format for G.719 Publication Date : January 2009 Author(s) : M. Westerlund, I. Johansson Category : PROPOSED STANDARD Source : Audio/Video Transport Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From magnus.westerlund@ericsson.com Mon Jun 4 23:47:08 2012 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 3FCE321F86AB for ; Mon, 4 Jun 2012 23:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.846 X-Spam-Level: X-Spam-Status: No, score=-105.846 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, 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 SgxRmPueYFhM for ; Mon, 4 Jun 2012 23:47:07 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id F235021F869F for ; Mon, 4 Jun 2012 23:47:06 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-b4-4fcdab6626a5 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 2F.B8.00702.66BADCF4; Tue, 5 Jun 2012 08:47:02 +0200 (CEST) To: undisclosed-recipients:; Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.0; Tue, 5 Jun 2012 08:47:02 +0200 Message-ID: <4FCDAB65.9050404@ericsson.com> Date: Tue, 5 Jun 2012 08:47:01 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 References: <20120605041957.B7C30B1E002@rfc-editor.org> In-Reply-To: <20120605041957.B7C30B1E002@rfc-editor.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+JvrW7a6rP+Bs1XtCxe9qxkt3j1+gqr xdPGs4wW1zoPMllcm9PI5sDq0fpsL6tHy5G3rB5Llvxk8pi18wlLAEsUl01Kak5mWWqRvl0C V8bnzZvZC2bJVMz/+Z21gfGZSBcjJ4eEgInEjWs9jBC2mMSFe+vZuhi5OIQETjFKtN3uZQZJ iAjISMyd/ZgVIrGMUaJz1XY2kASvgLbEjlMHwYpYBFQk7r/cDjaJTcBC4uaPRrAaUYFgiRd7 rrBC1AtKnJz5hAVkELPAcyaJfw39YEXCAuYSPya/B7OFgOzj5+cygdicQIPWz3/MBHGepMTB f9fYQWxmAT2JKVdbGCFseYnmrbOZIXq1JRqaOlgnMArNQrJvFpKWWUhaFjAyr2IUzk3MzEkv N9dLLcpMLi7Oz9MrTt3ECAz8g1t+G+xg3HRf7BCjNAeLkjivnup+fyGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2Mof6vHFieql59a/5Bd6K+6+GK7O3dm4NS5vU9czvopfCOO2GC4sWGTz8C 23UkMy9+S2XUk+kNdFzh0MKQdadhzravrU7nrLK7Ft3y+LRv78tvjzfrrI+oyClaq5F3oUf6 vtpN7j3H74qUbbKUe/XxQtVjK9n6m1ISqux88SnrY0puyXx5+XOaEktxRqKhFnNRcSIAZWKY qUoCAAA= Cc: "avt@ietf.org" , Ingemar Johansson S , "ravikumar@huawei.com" Subject: Re: [AVTCORE] [Technical Errata Reported] RFC5404 (3245) 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, 05 Jun 2012 06:47:08 -0000 Hi, This errata appear correct. The MIME RFCs requires parameter-name=value to be separated by "=". Most likely a copy and paste error that wasn't detected. Cheers Magnus On 2012-06-05 06:19, RFC Errata System wrote: > > The following errata report has been submitted for RFC5404, > "RTP Payload Format for G.719". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5404&eid=3245 > > -------------------------------------- > Type: Technical > Reported by: int-delay ABNF does not match to example mention in RFC > > Section: 7.1 > > Original Text > ------------- > 7.1. Media Type Definition > > > > int-delay: > > int-delay = "int-delay:" source-delay *("," source-delay) > > source-delay = SSRC ":" delay-value > > SSRC = 1*8HEXDIG ; The 32-bit SSRC encoded in hex format > > delay-value = 1*5DIGIT ; The delay value in milliseconds > > > > Example: int-delay=ABCD1234:1000,4321DCB:640 > > > > NOTE: No white space allowed in the parameter before the end of > > all the value pairs > > > > Corrected Text > -------------- > int-delay = "int-delay=" source-delay *("," source-delay) > > source-delay = SSRC ":" delay-value > > SSRC = 1*8HEXDIG ; The 32-bit SSRC encoded in hex format > > delay-value = 1*5DIGIT ; The delay value in milliseconds > > > > Example: int-delay=ABCD1234:1000,4321DCB:640 > > > > NOTE: No white space allowed in the parameter before the end of > > all the value pairs > > > > Notes > ----- > "int-delay:" need to change to "int-delay=" > > > > 7.2. Mapping to SDP > > o Any remaining parameters go in the SDP "a=fmtp" attribute by > > copying them directly from the media type parameter string as a > > semicolon-separated list of parameter=value pairs. > > As per section 7.2 int-delay parameter should be part of a=fmtp line and it should have parameter as parameter=value pair. > > > > But as per ABNF it should be int-delay: > > > > Also example mentions that int-delay= > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5404 (draft-ietf-avt-rtp-g719-04) > -------------------------------------- > Title : RTP Payload Format for G.719 > Publication Date : January 2009 > Author(s) : M. Westerlund, I. Johansson > Category : PROPOSED STANDARD > Source : Audio/Video Transport > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From harald@alvestrand.no Mon Jun 4 23:52:19 2012 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 9567321F86FD for ; Mon, 4 Jun 2012 23:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.359 X-Spam-Level: X-Spam-Status: No, score=-110.359 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259, 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 5SwwvZU51Sh8 for ; Mon, 4 Jun 2012 23:52:18 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFB621F86F7 for ; Mon, 4 Jun 2012 23:52:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3DD3339E0A3 for ; Tue, 5 Jun 2012 08:52:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtR9Qh+bTXN9 for ; Tue, 5 Jun 2012 08:52:11 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 764C939E089 for ; Tue, 5 Jun 2012 08:52:11 +0200 (CEST) Message-ID: <4FCDAC9B.1040705@alvestrand.no> Date: Tue, 05 Jun 2012 08:52:11 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: avt@ietf.org References: <03FBA798AC24E3498B74F47FD082A92FC2F2@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92FC2F2@US70UWXCHMBA05.zam.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt 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, 05 Jun 2012 06:52:19 -0000 On 06/04/2012 01:07 AM, Ejzak, Richard P (Richard) wrote: > http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt > > In response to the chairs' request for additional input on the multi session issue, I have submitted this draft for your consideration. There are superficial similarities with an expired draft from last year in http://tools.ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has a different take on the use of SSRC as the basis for multi session multiplexing that I think is superior and worthy of consideration as a potential replacement for BUNDLE and/or SHIM. Please comment. Since this draft is destined for AVTCORE, I'll repeat my comments from the RTCWEB discussion here, and encourage people to keep the discussion on AVTCORE: Richard, having scanned your draft: - I still fundamentally think that the partition of media types into separate RTP sessions was a design mistake that we should seek to rectify, not promulgate, and additional complexity like what you propose for perpetuating the use of "separated" sessions is not helpful. See draft-alvestrand-rtp-sess-neutral for details. - When we have parts of the ecosystem that have code that is written on the assumption that the SSRC space is a 32-bit flat space, I think the partitioning of that space into subspaces as you propose is likely to lead to "interesting" bugs. We should reinforce the randomness and flatness of the SSRC space, not partition it. - You say "The biggest problem with BUNDLE is that it is difficult to partition the RTP streams associated with different media lines since this requires filtering on sets of payload type values. RTP subsessions is superior for this purpose since it is only necessary to screen for a single value in the first 16 bits". This assumes that the partitioning associated with different media lines is a good thing. I claim that it is not. If there are no bigger problems than that with BUNDLE, I would prefer to stick with that approach. > > Richard > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Sunday, June 03, 2012 5:16 PM > To: Ejzak, Richard P (Richard) > Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-00.txt > > A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been successfully submitted by Richard Ejzak and posted to the IETF repository. > > Filename: draft-ejzak-avtcore-rtp-subsessions > Revision: 00 > Title: Media multiplexing with Real-time Transport Protocol (RTP) subsessions > Creation date: 2012-06-04 > WG ID: Individual Submission > Number of pages: 9 > > Abstract: > This document describes a means of multiplexing RTP streams having > different media types within a single transport connection and how to > represent this multiplexing option in SDP. This mechanism is an > alternative to the BUNDLE and SHIM proposals currently under active > consideration in AVTCORE. Instead of adding an extra multiplexing > header as in SHIM to allow multiple RTP sessions within a single > transport connection, or using the payload type field to separate > different media streams within a single RTP session, this document > describes how to partition the existing SSRC space to create RTP > subsessions from a single RTP session. A filter can be used to > identify each RTP subsession for different QoS handling as necessary. > RTP subsessions can be treated like RTP sessions with a few > restrictions. In particular, SSRC mapping may be needed when > forwarding RTP streams into an RTP subsession to avoid SSRC > conflicts, but there are few use cases in which this limitation is a > concern and RTP subsessions can be disabled if necessary. > > > > > The IETF Secretariat > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From christer.holmberg@ericsson.com Tue Jun 5 01:05:19 2012 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 ABC5D21F86A8 for ; Tue, 5 Jun 2012 01:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259] 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 pzo-ODCOay-V for ; Tue, 5 Jun 2012 01:05:18 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB1921F8608 for ; Tue, 5 Jun 2012 01:05:17 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-1e-4fcdbdbcdb14 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EA.E5.00702.CBDBDCF4; Tue, 5 Jun 2012 10:05:16 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Tue, 5 Jun 2012 10:05:16 +0200 From: Christer Holmberg To: Harald Alvestrand , "avt@ietf.org" Date: Tue, 5 Jun 2012 10:05:15 +0200 Thread-Topic: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt Thread-Index: Ac1C58MrAjSy7N00QV6J+yWzyS9UzwACZSKw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C45A1C9A5@ESESSCMS0356.eemea.ericsson.se> References: <03FBA798AC24E3498B74F47FD082A92FC2F2@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCDAC9B.1040705@alvestrand.no> In-Reply-To: <4FCDAC9B.1040705@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvre6evWf9DRY8VLd42bOS3eJYXxeb A5PHlQlXWD2WLPnJFMAUxWWTkpqTWZZapG+XwJVx5str5oIXahWNHzpYGxg3yHcxcnJICJhI 3Og7xwxhi0lcuLeerYuRi0NI4BSjxIJb2xghnDmMElv+zWDpYuTgYBOwkOj+pw3SICLgLdFx 4yUriM0ioCKxZ+EmoEHsHMICgRITa0GKRQSCJGZ3eUMUG0lcmjMXbAavQLjEsUnZIGEhgWqJ nXf2MoHYnAK6EnPfv2MBsRmBjvl+ag1YnFlAXOLWk/lMEEcKSCzZcx7qYFGJl4//sULUi0rc aV/PCFGvJ3Fj6hQ2CFtbYtnC12D1vAKCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG4dzE zJz0cnO91KLM5OLi/Dy94tRNjMDYOLjlt8EOxk33xQ4xSnOwKInz6qnu9xcSSE8sSc1OTS1I LYovKs1JLT7EyMTBKdXA6Pdrr9zSSdPjld+9ZrZgFfP50Klqm9vcncqax9pcI7L8WcA1jdeP fM5r5jn/LbZczXlwgm20wVSukszSrOnru+5NuDz170WDQ7tMfHiFPzVqTHu/O/7Omu4Vx98s tX4ZbHDKbPbS9t+3vf+rCylePB0QcEh+8mKbWwfLZnrynC9okhb4YGzIq8RSnJFoqMVcVJwI AIjUrgVbAgAA Subject: Re: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt 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, 05 Jun 2012 08:05:19 -0000 Hi, Just to clarify also to the AVTCORE community. BUNDLE is not an RTP multiplexing mechanism. BUNDLE is an SDP extension whi= ch allows to signal the re-usage of the same IP address:port for multiple S= DP media descriptions (m- lines). BUNDLE currently does define a "default", which is a single RTP session, bu= t BUNDLE can be extended to also be used with subsessions, SHIM, etc. Regards, Christer -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Haral= d Alvestrand Sent: 5. kes=E4kuuta 2012 9:52 To: avt@ietf.org Subject: Re: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00= .txt On 06/04/2012 01:07 AM, Ejzak, Richard P (Richard) wrote: > http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt > > In response to the chairs' request for additional input on the multi sess= ion issue, I have submitted this draft for your consideration. There are s= uperficial similarities with an expired draft from last year in http://tool= s.ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has a diff= erent take on the use of SSRC as the basis for multi session multiplexing t= hat I think is superior and worthy of consideration as a potential replacem= ent for BUNDLE and/or SHIM. Please comment. Since this draft is destined for AVTCORE, I'll repeat my comments from the = RTCWEB discussion here, and encourage people to keep the discussion on AVTC= ORE: Richard, having scanned your draft: - I still fundamentally think that the partition of media types into separa= te RTP sessions was a design mistake that we should seek to rectify, not pr= omulgate, and additional complexity like what you propose for perpetuating = the use of "separated" sessions is not helpful. See draft-alvestrand-rtp-se= ss-neutral for details. - When we have parts of the ecosystem that have code that is written on the= assumption that the SSRC space is a 32-bit flat space, I think the partiti= oning of that space into subspaces as you propose is likely to lead to "int= eresting" bugs. We should reinforce the randomness and flatness of the SSRC= space, not partition it. - You say "The biggest problem with BUNDLE is that it is difficult to partition the RTP streams associated with different media lines since this requires filtering on sets of payload type values. RTP subsessions is superior for this purpose since it is only necessary to screen for a single value in the first 16 bits". This assumes that the partitioning associated with different media lines is= a good thing. I claim that it is not. If there are no bigger problems than that with BUNDLE, I would prefer to st= ick with that approach. > > Richard > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Sunday, June 03, 2012 5:16 PM > To: Ejzak, Richard P (Richard) > Subject: New Version Notification for=20 > draft-ejzak-avtcore-rtp-subsessions-00.txt > > A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been= successfully submitted by Richard Ejzak and posted to the IETF repository. > > Filename: draft-ejzak-avtcore-rtp-subsessions > Revision: 00 > Title: Media multiplexing with Real-time Transport Protocol (RTP) subse= ssions > Creation date: 2012-06-04 > WG ID: Individual Submission > Number of pages: 9 > > Abstract: > This document describes a means of multiplexing RTP streams having > different media types within a single transport connection and how to > represent this multiplexing option in SDP. This mechanism is an > alternative to the BUNDLE and SHIM proposals currently under active > consideration in AVTCORE. Instead of adding an extra multiplexing > header as in SHIM to allow multiple RTP sessions within a single > transport connection, or using the payload type field to separate > different media streams within a single RTP session, this document > describes how to partition the existing SSRC space to create RTP > subsessions from a single RTP session. A filter can be used to > identify each RTP subsession for different QoS handling as necessary. > RTP subsessions can be treated like RTP sessions with a few > restrictions. In particular, SSRC mapping may be needed when > forwarding RTP streams into an RTP subsession to avoid SSRC > conflicts, but there are few use cases in which this limitation is a > concern and RTP subsessions can be disabled if necessary. > > > > > The IETF Secretariat > _______________________________________________ > Audio/Video Transport Core Maintenance avt@ietf.org=20 > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From richard.ejzak@alcatel-lucent.com Tue Jun 5 16:34:27 2012 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 ACB6D21F85D7 for ; Tue, 5 Jun 2012 16:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.764 X-Spam-Level: X-Spam-Status: No, score=-9.764 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259] 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 hqc5tv7SPngr for ; Tue, 5 Jun 2012 16:34:27 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id D4B2421F85D3 for ; Tue, 5 Jun 2012 16:34:26 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q55NYMFH022136 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Jun 2012 01:34:22 +0200 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 6 Jun 2012 01:34:22 +0200 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.235]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Tue, 5 Jun 2012 19:34:20 -0400 From: "Ejzak, Richard P (Richard)" To: Harald Alvestrand , "avt@ietf.org" Thread-Topic: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt Thread-Index: AQHNQufFoPIG4TttGECDMR5hdlC5jZbsT2GA Date: Tue, 5 Jun 2012 23:34:19 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92FC824@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92FC2F2@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCDAC9B.1040705@alvestrand.no> In-Reply-To: <4FCDAC9B.1040705@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt 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, 05 Jun 2012 23:34:27 -0000 On 06/05/2012 01:52 AM, Harald Alvestrand wrote: > Richard, > having scanned your draft: >=20 > - I still fundamentally think that the partition of media types into > separate RTP sessions was a design mistake that we should seek to > rectify, not promulgate, and additional complexity like what you propose > for perpetuating the use of "separated" sessions is not helpful. See > draft-alvestrand-rtp-sess-neutral for details. There are two reasons why "separating" sessions can be helpful. Firstly, in= more complex RTP session topologies with multiple systems, other systems w= ill already consider each media line to identify a separate RTP session, so= BUNDLE (in its current default mode) essentially merges these sessions tog= ether since they now have a common SSRC space. This has the potential to ca= use additional SSRC conflicts. I am not proposing to separate the sessions = but instead suggesting a way to keep them separate as originally intended. = I agree that there are many use cases in which this merging is not a proble= m. The more important reason for separating sessions is so that it is possible= for the network to easily identify the IP packets associated with differen= t media types for different QoS treatment. Blending of different media type= s into a single RTP session means that the corresponding compound RTCP pack= ets will mix RTCP information for different media types into single IP pack= ets. It is important to assign the same QoS to the RTCP packets as to the c= orresponding RTP streams and this will not be possible with these compound = RTCP packets. You made the following comment on the related rtcweb thread when I mentione= d the need to support QoS: > Yes, some applications need that. > In that case, the simplest way (allowing per-flow prioritization) is to= =20 > use different RTP sessions on different transport addresses. > The next simplest way (using DiffServ) is to apply different DSCP marking= s > on a per-packet basis. Both techniques are well established. If we use different transport connections then we lose the clear advantages= of multiplexing. If we use DiffServ without "separating" the sessions in s= ome way, we still have problems with compound RTCP packets. DSCP has two other problems. There is no current mechanism defined for the = application to direct the browser and/or OS to correctly mark the transmitt= ed packets. (We could fix this.) And since there is no guarantee regarding = the marking of packets from the remote endpoint and through intermediate ne= tworks towards the device, there still needs to be a way to identify each f= low to correctly reassign the markings! That is the purpose of my proposal. So I agree with you that DSCP is required, but it is not sufficient. Richard From kevin.gross@avanw.com Tue Jun 5 18:46:35 2012 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 17C0521F8735 for ; Tue, 5 Jun 2012 18:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.329 X-Spam-Level: X-Spam-Status: No, score=0.329 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 z3Q02QckxtgQ for ; Tue, 5 Jun 2012 18:46:34 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 1070411E80C0 for ; Tue, 5 Jun 2012 18:46:33 -0700 (PDT) Received: (qmail 22577 invoked by uid 0); 6 Jun 2012 01:46:32 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy9.bluehost.com with SMTP; 6 Jun 2012 01:46:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=K58Pl6hgz9GCYBh4cZ6Ws3sUWq5NtZDiGQc6W5j9Y+Q=; b=PuDWAblgUKeb08XqWsv6Jwuc904HZVqomr6tnCdsYYsperPZnM/Ay0vtHn/R1hGD2unnX7BOIlB1IObNELnB3iu3GgBCnYL1sWe42gWdyNNN/kxEEgU157Px6jwiil/0; Received: from [74.125.82.172] (port=56024 helo=mail-we0-f172.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1Sc5KS-0005f9-2G for avt@ietf.org; Tue, 05 Jun 2012 19:46:32 -0600 Received: by werb13 with SMTP id b13so4561869wer.31 for ; Tue, 05 Jun 2012 18:46:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.140.33 with SMTP id d33mr3210443wej.113.1338947190531; Tue, 05 Jun 2012 18:46:30 -0700 (PDT) Received: by 10.223.144.216 with HTTP; Tue, 5 Jun 2012 18:46:30 -0700 (PDT) In-Reply-To: <55D7C468-DF2E-4AFA-BEBE-74AAAE22C1CE@csperkins.org> References: <55D7C468-DF2E-4AFA-BEBE-74AAAE22C1CE@csperkins.org> Date: Tue, 5 Jun 2012 19:46:30 -0600 Message-ID: From: Kevin Gross To: Colin Perkins Content-Type: multipart/alternative; boundary=0016e6dab08aaa27e204c1c3ef29 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.172 authed with kevin.gross@avanw.com} Cc: avt@ietf.org Subject: Re: [AVTCORE] ASCII representation for RFC 6222 CNAME 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: Wed, 06 Jun 2012 01:46:35 -0000 --0016e6dab08aaa27e204c1c3ef29 Content-Type: text/plain; charset=ISO-8859-1 Thanks. Sorry for the trouble. Kevin Gross On Sat, Jun 2, 2012 at 9:52 AM, Colin Perkins wrote: > On 2 Jun 2012, at 00:13, Kevin Gross wrote: > > I'm working on a revision to draft-williams-avtcore-clksource and it > looks like for media clock identification, I need to specify a CNAME in > SDP. Although RFC 6222 says it supersedes RFC 3550 section 6.5.1, I assume > the ASCII format for the CNAME field described in 6.5.1 is retained. The > new CNAME definition in RFC 6222 produces a 256-bit binary value. There is > no discussion in RFC 6222 as to how that should be formatted for inclusion > in SDES. What is the recommended ASCII representation for the 256 binary > CNAME for inclusion in SDES or SDP? > > Section 4.2 of RFC 6222 describes how these are converted to printable > ASCII values suitable for use in the RTCP CNAME. > > -- > Colin Perkins > http://csperkins.org/ > > > > --0016e6dab08aaa27e204c1c3ef29 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks. Sorry for the trouble.

Kevin Gross

On Sat, Jun 2, 2012 at 9:52 AM, Coli= n Perkins <csp@csperkins.org> wrote:
On 2 Jun 2012, at 00:13, K= evin Gross wrote:
> I'm working on a revision to draft-williams-avtcore-clksource and = it looks like for media clock identification, I need to specify a CNAME in = SDP. =A0Although RFC 6222 says it supersedes RFC 3550 section 6.5.1, I assu= me the ASCII format for the CNAME field described in 6.5.1 is retained. =A0= The new CNAME definition in RFC 6222 produces a 256-bit binary value. There= is no discussion in RFC 6222 as to how that should be formatted for inclus= ion in SDES. What is the recommended ASCII representation for the 256 binar= y CNAME for inclusion in SDES or SDP?

Section 4.2 of RFC 6222 describes how these are converted to printabl= e ASCII values suitable for use in the RTCP CNAME.

--
Colin Perkins
http://csperkins.org/




--0016e6dab08aaa27e204c1c3ef29-- From harald@alvestrand.no Wed Jun 6 00:17:08 2012 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 DD45311E80D2 for ; Wed, 6 Jun 2012 00:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.469 X-Spam-Level: X-Spam-Status: No, score=-110.469 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259, 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 GOybHqMx-BEq for ; Wed, 6 Jun 2012 00:17:08 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id DB3FA11E80D6 for ; Wed, 6 Jun 2012 00:17:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4361F39E13F; Wed, 6 Jun 2012 09:17:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijSIO5NOgSaa; Wed, 6 Jun 2012 09:17:06 +0200 (CEST) Received: from [172.28.92.110] (unknown [74.125.122.49]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 82AC439E12F; Wed, 6 Jun 2012 09:17:06 +0200 (CEST) Message-ID: <4FCF03EE.4080400@alvestrand.no> Date: Wed, 06 Jun 2012 09:17:02 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Ejzak, Richard P (Richard)" References: <03FBA798AC24E3498B74F47FD082A92FC2F2@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCDAC9B.1040705@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92FC824@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92FC824@US70UWXCHMBA05.zam.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "avt@ietf.org" Subject: Re: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt 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: Wed, 06 Jun 2012 07:17:09 -0000 On 06/06/2012 01:34 AM, Ejzak, Richard P (Richard) wrote: > On 06/05/2012 01:52 AM, Harald Alvestrand wrote: >> Richard, >> having scanned your draft: >> >> - I still fundamentally think that the partition of media types into >> separate RTP sessions was a design mistake that we should seek to >> rectify, not promulgate, and additional complexity like what you propose >> for perpetuating the use of "separated" sessions is not helpful. See >> draft-alvestrand-rtp-sess-neutral for details. > There are two reasons why "separating" sessions can be helpful. Firstly, in more complex RTP session topologies with multiple systems, other systems will already consider each media line to identify a separate RTP session, so BUNDLE (in its current default mode) essentially merges these sessions together since they now have a common SSRC space. This has the potential to cause additional SSRC conflicts. I am not proposing to separate the sessions but instead suggesting a way to keep them separate as originally intended. I agree that there are many use cases in which this merging is not a problem. > > The more important reason for separating sessions is so that it is possible for the network to easily identify the IP packets associated with different media types for different QoS treatment. Blending of different media types into a single RTP session means that the corresponding compound RTCP packets will mix RTCP information for different media types into single IP packets. It is important to assign the same QoS to the RTCP packets as to the corresponding RTP streams and this will not be possible with these compound RTCP packets. As I stated in draft-alvestrand-rtp-sess-neutral, I heartily agree that RTP session separation is a poweful tool for letting the network give differential treatment to packets. What I don't agree with is the idea that this need for differential treatment aligns with media types. Sometimes we need to treat two different media types the same. Sometimes we need to treat two flows of the same media type differently. Forcing them to be always separated on media type is a bad idea. I don't believe the compound-ness of RTCP packets is relevant to this argument; within a single RTP session (without muxing), all the RTCP packets will be treated the same, which is how it should be if one uses RTP sessions to indicate the need for differential treatment from the network. > > You made the following comment on the related rtcweb thread when I mentioned the need to support QoS: >> Yes, some applications need that. >> In that case, the simplest way (allowing per-flow prioritization) is to >> use different RTP sessions on different transport addresses. >> The next simplest way (using DiffServ) is to apply different DSCP markings >> on a per-packet basis. Both techniques are well established. > If we use different transport connections then we lose the clear advantages of multiplexing. If we use DiffServ without "separating" the sessions in some way, we still have problems with compound RTCP packets. > > DSCP has two other problems. There is no current mechanism defined for the application to direct the browser and/or OS to correctly mark the transmitted packets. (We could fix this.) That's actually a WEBRTC problem, not an AVTCORE problem. > And since there is no guarantee regarding the marking of packets from the remote endpoint and through intermediate networks towards the device, there still needs to be a way to identify each flow to correctly reassign the markings! I believe that's not how diffserv is supposed to work; the diffserv marking from the endpoint is supposed to give enough information for intermediate hops to remark according to policy. I think the most common current practice is that the source host is diffserv-ignorant, and the first router takes on the task of diffserv classification, based on flows - but if we want end-to-end diffserv, that has to change. > That is the purpose of my proposal. > > So I agree with you that DSCP is required, but it is not sufficient. > > Richard > From richard.ejzak@alcatel-lucent.com Wed Jun 6 18:57:53 2012 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 2461111E80C6 for ; Wed, 6 Jun 2012 18:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.797 X-Spam-Level: X-Spam-Status: No, score=-7.797 tagged_above=-999 required=5 tests=[AWL=-1.807, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259] 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 Hwxf+1R2v8FC for ; Wed, 6 Jun 2012 18:57:52 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id 593B611E80BC for ; Wed, 6 Jun 2012 18:57:28 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q571vNjO025148 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Jun 2012 03:57:23 +0200 Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 7 Jun 2012 03:57:23 +0200 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.235]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 6 Jun 2012 21:57:20 -0400 From: "Ejzak, Richard P (Richard)" To: Harald Alvestrand Thread-Topic: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt Thread-Index: AQHNQ7RlSWV+roINM0KqpCYu7kaZG5bt2hmA Date: Thu, 7 Jun 2012 01:57:19 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92FC9FA@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92FC2F2@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCDAC9B.1040705@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92FC824@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCF03EE.4080400@alvestrand.no> In-Reply-To: <4FCF03EE.4080400@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt 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: Thu, 07 Jun 2012 01:57:53 -0000 Harald Alvestrand wrote: > As I stated in draft-alvestrand-rtp-sess-neutral, I heartily agree that > RTP session separation is a poweful tool for letting the network give > differential treatment to packets. What I don't agree with is the idea > that this need for differential treatment aligns with media types. >=20 > Sometimes we need to treat two different media types the same. Sometimes > we need to treat two flows of the same media type differently. Forcing > them to be always separated on media type is a bad idea. My position is that differential treatment aligns with different media line= s rather than different media types. It seems natural to assign the same tr= eatment to the RTP streams associated with a media line based on the negoti= ated payload types. Are you suggesting that different RTP streams associate= d with a media line may be selected for further differentiation? An applica= tion may enable/disable individual streams, but on what basis could the net= work assign different treatment to individual streams associated with a sin= gle media line? Or are you suggesting that multiplexing of media lines on a= single transport connection be disabled when differential treatment is nee= ded? I would prefer to have a solution where we can assign differential tre= atment to flows within a transport connection. >=20 > I don't believe the compound-ness of RTCP packets is relevant to this > argument; within a single RTP session (without muxing), all the RTCP > packets will be treated the same, which is how it should be if one uses > RTP sessions to indicate the need for differential treatment from the > network. I'm afraid I don't follow your argument here. Let me just ask a simple ques= tion. Should RTCP packets get the same QoS treatment in the network as thei= r corresponding RTP streams, or is it ok for them to be treated with some a= rbitrary other QoS? > > And since there is no guarantee regarding the marking of packets from > the remote endpoint and through intermediate networks towards the device, > there still needs to be a way to identify each flow to correctly reassign > the markings! > I believe that's not how diffserv is supposed to work; the diffserv > marking from the endpoint is supposed to give enough information for > intermediate hops to remark according to policy. > I think the most common current practice is that the source host is > diffserv-ignorant, and the first router takes on the task of diffserv > classification, based on flows - but if we want end-to-end diffserv, > that has to change. I did not intend to say anything different; I just said it less precisely t= han you did. For the near future, diffserv markings will not generally surv= ive transport through the internet. Depending on policy they may be remarke= d in a meaningful way or they may simply be remarked for best effort handli= ng. The situation is not as bad as it sounds since differential treatment in th= e access network (be it cable, DSL, or wireless access, but particularly fo= r wireless access), is generally more important than treatment in the backb= one. The access network will need to ensure that packets (flowing in either= direction) are marked correctly to get the right treatment (or the access = network will need to assign the treatment directly based on filtering witho= ut remarking). The only way to intelligently remark packets for correct treatment in the a= ccess network (or to just identify them) is to define a simple filter that = can be used to separate them from other packets sharing the transport conne= ction (and 5-tuple). The filter has to be based on some characteristic of t= he IP packet payload since the TOS can't be trusted to have the right value= . Even if we assume your "common current practice" scenario, where the first = router performs the diffserv classification, and subsequent routers remark = so as to retain the assigned treatment end-to-end, the first router still n= eeds to be told how to identify the packets associated with each assigned t= reatment. Richard From harald@alvestrand.no Wed Jun 6 23:15:53 2012 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 862DB21F86C2 for ; Wed, 6 Jun 2012 23:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.374 X-Spam-Level: X-Spam-Status: No, score=-110.374 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259, 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 TUS4-WMssHvl for ; Wed, 6 Jun 2012 23:15:52 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9773D21F86BD for ; Wed, 6 Jun 2012 23:15:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E4F5A39E115; Thu, 7 Jun 2012 08:15:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dx5GDGUV2dtU; Thu, 7 Jun 2012 08:15:52 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1C06F39E08A; Thu, 7 Jun 2012 08:15:52 +0200 (CEST) Message-ID: <4FD04712.8000106@alvestrand.no> Date: Thu, 07 Jun 2012 08:15:46 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Ejzak, Richard P (Richard)" References: <03FBA798AC24E3498B74F47FD082A92FC2F2@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCDAC9B.1040705@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92FC824@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCF03EE.4080400@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92FC9FA@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92FC9FA@US70UWXCHMBA05.zam.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "avt@ietf.org" Subject: Re: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt 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: Thu, 07 Jun 2012 06:15:53 -0000 On 06/07/2012 03:57 AM, Ejzak, Richard P (Richard) wrote: > Harald Alvestrand wrote: >> As I stated in draft-alvestrand-rtp-sess-neutral, I heartily agree that >> RTP session separation is a poweful tool for letting the network give >> differential treatment to packets. What I don't agree with is the idea >> that this need for differential treatment aligns with media types. >> >> Sometimes we need to treat two different media types the same. Sometimes >> we need to treat two flows of the same media type differently. Forcing >> them to be always separated on media type is a bad idea. > My position is that differential treatment aligns with different media lines rather than different media types. It seems natural to assign the same treatment to the RTP streams associated with a media line based on the negotiated payload types. That ("based on the negotiated payload types") is the part that doesn't seem natural to me. > Are you suggesting that different RTP streams associated with a media line may be selected for further differentiation? An application may enable/disable individual streams, but on what basis could the network assign different treatment to individual streams associated with a single media line? Or are you suggesting that multiplexing of media lines on a single transport connection be disabled when differential treatment is needed? I'm suggesting that media lines should be grouped into RTP sessions, each of which is carried on a single transport connection. That's the reason why the BUNDLE extension is explicit about which sessions are part of the bundle; it's simple to define as many bundles as are needed in order to achieve one's differential-treatment goals. > I would prefer to have a solution where we can assign differential treatment to flows within a transport connection. That's a complexity I don't see the need for. YMMV. > >> I don't believe the compound-ness of RTCP packets is relevant to this >> argument; within a single RTP session (without muxing), all the RTCP >> packets will be treated the same, which is how it should be if one uses >> RTP sessions to indicate the need for differential treatment from the >> network. > I'm afraid I don't follow your argument here. Let me just ask a simple question. Should RTCP packets get the same QoS treatment in the network as their corresponding RTP streams, or is it ok for them to be treated with some arbitrary other QoS? Quibbling somewhat about whether "the same treatment" can be achieved A->B as B->A, but yes; I think that RTCP packets need to get the same treatment as their corresponding RTP streams. This is achieved in BUNDLE by the fact that all RTP and RTCP packets in a bundle are on the same transport flow. > >>> And since there is no guarantee regarding the marking of packets from >> the remote endpoint and through intermediate networks towards the device, >> there still needs to be a way to identify each flow to correctly reassign >> the markings! >> I believe that's not how diffserv is supposed to work; the diffserv >> marking from the endpoint is supposed to give enough information for >> intermediate hops to remark according to policy. >> I think the most common current practice is that the source host is >> diffserv-ignorant, and the first router takes on the task of diffserv >> classification, based on flows - but if we want end-to-end diffserv, >> that has to change. > I did not intend to say anything different; I just said it less precisely than you did. For the near future, diffserv markings will not generally survive transport through the internet. Depending on policy they may be remarked in a meaningful way or they may simply be remarked for best effort handling. > > The situation is not as bad as it sounds since differential treatment in the access network (be it cable, DSL, or wireless access, but particularly for wireless access), is generally more important than treatment in the backbone. The access network will need to ensure that packets (flowing in either direction) are marked correctly to get the right treatment (or the access network will need to assign the treatment directly based on filtering without remarking). > > The only way to intelligently remark packets for correct treatment in the access network (or to just identify them) is to define a simple filter that can be used to separate them from other packets sharing the transport connection (and 5-tuple). The filter has to be based on some characteristic of the IP packet payload since the TOS can't be trusted to have the right value. > > Even if we assume your "common current practice" scenario, where the first router performs the diffserv classification, and subsequent routers remark so as to retain the assigned treatment end-to-end, the first router still needs to be told how to identify the packets associated with each assigned treatment. Good that we're agreeing here! > > Richard > From marshall.eubanks@gmail.com Thu Jun 7 08:19:52 2012 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 D0ED221F861D for ; Thu, 7 Jun 2012 08:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.363 X-Spam-Level: X-Spam-Status: No, score=-103.363 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Z=0.259, 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 Jc3HDJU6t80y for ; Thu, 7 Jun 2012 08:19:52 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8183021F8709 for ; Thu, 7 Jun 2012 08:19:51 -0700 (PDT) Received: by lagv3 with SMTP id v3so657717lag.31 for ; Thu, 07 Jun 2012 08:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zKeA3bYU5ZyeUWkwse8aLdOdZh5QwMEQ4s3I6sT0uFg=; b=qtBd+SAo6t5DYiAso/uj4lHsXV+3k2D5aOex9BMKYQLWo81h9F251mT59j4sXJXT6w LwB+V0C9FEQgeUfetWWYs5WNLdDinivMzDsiwRuoe+RMXUu9f1v9L2NIpjn1mUu3yRlT PW6+3Qrnz/kGK7CYwuGIdmSDtz+DrYd9Vq3hrIzKpCdpQ/syWb8BdVTcTetQckLBuS4u 3wEDCxrXQacbWLhmAcuT0rYxIMcnXz+bsznVcEW+BpxzK1NbILGpTkGfT5R9Q0FhmvLE sPkVazRM9UwOYN9NreHBzL0iLjEoHYD3nyFqssAS4k3SWET9m+ev1sInFqvFs2dtmx6m SPWA== MIME-Version: 1.0 Received: by 10.152.104.171 with SMTP id gf11mr3057912lab.5.1339082390465; Thu, 07 Jun 2012 08:19:50 -0700 (PDT) Received: by 10.112.132.65 with HTTP; Thu, 7 Jun 2012 08:19:50 -0700 (PDT) In-Reply-To: <03FBA798AC24E3498B74F47FD082A92FC9FA@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92FC2F2@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCDAC9B.1040705@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92FC824@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCF03EE.4080400@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92FC9FA@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Thu, 7 Jun 2012 11:19:50 -0400 Message-ID: From: Marshall Eubanks To: "Ejzak, Richard P (Richard)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Harald Alvestrand , "avt@ietf.org" Subject: Re: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt 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: Thu, 07 Jun 2012 15:19:53 -0000 On Wed, Jun 6, 2012 at 9:57 PM, Ejzak, Richard P (Richard) wrote: > Harald Alvestrand wrote: >> As I stated in draft-alvestrand-rtp-sess-neutral, I heartily agree that >> RTP session separation is a poweful tool for letting the network give >> differential treatment to packets. What I don't agree with is the idea >> that this need for differential treatment aligns with media types. >> >> Sometimes we need to treat two different media types the same. Sometimes >> we need to treat two flows of the same media type differently. Forcing >> them to be always separated on media type is a bad idea. > > My position is that differential treatment aligns with different media li= nes rather than different media types. It seems natural to assign the same = treatment to the RTP streams associated with a media line based on the nego= tiated payload types. Are you suggesting that different RTP streams associa= ted with a media line may be selected for further differentiation? An appli= cation may enable/disable individual streams, but on what basis could the n= etwork assign different treatment to individual streams associated with a s= ingle media line? Or are you suggesting that multiplexing of media lines on= a single transport connection be disabled when differential treatment is n= eeded? I would prefer to have a solution where we can assign differential t= reatment to flows within a transport connection. > >> >> I don't believe the compound-ness of RTCP packets is relevant to this >> argument; within a single RTP session (without muxing), all the RTCP >> packets will be treated the same, which is how it should be if one uses >> RTP sessions to indicate the need for differential treatment from the >> network. > > I'm afraid I don't follow your argument here. Let me just ask a simple qu= estion. Should RTCP packets get the same QoS treatment in the network as th= eir corresponding RTP streams, or is it ok for them to be treated with some= arbitrary other QoS? Depends on your need for RTCP. If you don't need it, it doesn't matter. If you do need it, it is dangerous to give it lower priority, as you may not get enough of it to be useable. We just had this discussion on the "RTCP traffic class" thread - see also RFC 4594. So, the answer is no, it is not OK, if by arbitrary you mean possibly a lower service level. (Clearly, there is no problem (at our level) if the RTCP gets put in a higher QOS service level, so that possibility is OK.) Regards Marshall > >> > =A0 And since there is no guarantee regarding the marking of packets f= rom >> the remote endpoint and through intermediate networks towards the device= , >> there still needs to be a way to identify each flow to correctly reassig= n >> the markings! >> I believe that's not how diffserv is supposed to work; the diffserv >> marking from the endpoint is supposed to give enough information for >> intermediate hops to remark according to policy. >> I think the most common current practice is that the source host is >> diffserv-ignorant, and the first router takes on the task of diffserv >> classification, based on flows - but if we want end-to-end diffserv, >> that has to change. > > I did not intend to say anything different; I just said it less precisely= than you did. For the near future, diffserv markings will not generally su= rvive transport through the internet. Depending on policy they may be remar= ked in a meaningful way or they may simply be remarked for best effort hand= ling. > > The situation is not as bad as it sounds since differential treatment in = the access network (be it cable, DSL, or wireless access, but particularly = for wireless access), is generally more important than treatment in the bac= kbone. The access network will need to ensure that packets (flowing in eith= er direction) are marked correctly to get the right treatment (or the acces= s network will need to assign the treatment directly based on filtering wit= hout remarking). > > The only way to intelligently remark packets for correct treatment in the= access network (or to just identify them) is to define a simple filter tha= t can be used to separate them from other packets sharing the transport con= nection (and 5-tuple). The filter has to be based on some characteristic of= the IP packet payload since the TOS can't be trusted to have the right val= ue. > > Even if we assume your "common current practice" scenario, where the firs= t router performs the diffserv classification, and subsequent routers remar= k so as to retain the assigned treatment end-to-end, the first router still= needs to be told how to identify the packets associated with each assigned= treatment. > > Richard > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From richard.ejzak@alcatel-lucent.com Thu Jun 7 12:20:29 2012 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 D76DC21F8594 for ; Thu, 7 Jun 2012 12:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.571 X-Spam-Level: X-Spam-Status: No, score=-9.571 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259] 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 LalEV0xVyN3s for ; Thu, 7 Jun 2012 12:20:29 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id B0ECC21F852C for ; Thu, 7 Jun 2012 12:20:28 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q57JKMQc012795 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Jun 2012 21:20:22 +0200 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 7 Jun 2012 21:20:22 +0200 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.235]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 7 Jun 2012 15:20:20 -0400 From: "Ejzak, Richard P (Richard)" To: Harald Alvestrand Thread-Topic: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt Thread-Index: AQHNQ7RlSWV+roINM0KqpCYu7kaZG5bt2hmAgADLfwCAAIoHEA== Date: Thu, 7 Jun 2012 19:20:17 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92FCC0C@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92FC2F2@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCDAC9B.1040705@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92FC824@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCF03EE.4080400@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92FC9FA@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FD04712.8000106@alvestrand.no> In-Reply-To: <4FD04712.8000106@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt 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: Thu, 07 Jun 2012 19:20:30 -0000 Harald Alvestrand wrote: > That ("based on the negotiated payload types") is the part that doesn't > seem natural to me. I only mean by this that QoS treatment can take into account the characteri= stics of the expected payload. I don't think we differ here. > I'm suggesting that media lines should be grouped into RTP sessions, > each of which is carried on a single transport connection. That's the > reason why the BUNDLE extension is explicit about which sessions are > part of the bundle; it's simple to define as many bundles as are needed > in order to achieve one's differential-treatment goals. > > I would prefer to have a solution where we can assign differential > treatment to flows within a transport connection. > That's a complexity I don't see the need for. YMMV. This seems to be the real issue. We have a difference in understanding of = requirements. I thought that the multi session work was intended to remove= the major limitations of the single session BUNDLE technique. To me, the = most significant limitation of BUNDLE is the inability to assign differenti= al treatment to different media lines within a BUNDLE. If we don't fix thi= s I don't see a need to progress work on multi session within AVTCORE. I a= gree with you that single session BUNDLE is adequate for all reasonable use= cases without this requirement. And differential treatment based on filte= ring on a SHIM header at the end of the IP payload is problematic in some i= mplementations.=20 Richard From dwing@cisco.com Thu Jun 7 13:34:32 2012 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 11FC711E80AA for ; Thu, 7 Jun 2012 13:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 3tHGjW7xXnZh for ; Thu, 7 Jun 2012 13:34:31 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 32CA921F873D for ; Thu, 7 Jun 2012 13:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2497; q=dns/txt; s=iport; t=1339101269; x=1340310869; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=COPgOG89Y4ge3ZFk+lexECKb2mD0gfVAqzpTkdDkrgE=; b=Cna2Jl28AJwP6Sflag5QnA+Pd5MlOjKy4jNG1VxLe67SVSsisccBTGVO Ib3sFM17XDXUR2KkCV2vQi5Fy2dNxkh2KgKVlrFTjpWgdvI+2G2iPvsx5 yZgFu2fDO6pBCOj/oVdvJz5nturHGobDjTiwoNWMXQLs22vVSjQQtW7uA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOwP0U+rRDoH/2dsb2JhbAArGqVUjnmBB4IYAQEBBAEBAQUEBgEXWwEBAgIJDwIEAQEkBAcZAgwVCgkIAQEEARILCQ6HaAwpmQGfcQSLGYYAA4gNM4R9lXSBZoMATw X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="48087545" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 07 Jun 2012 20:34:29 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q57KYSj7017193; Thu, 7 Jun 2012 20:34:28 GMT From: "Dan Wing" To: "'Magnus Westerlund'" , "'IETF AVTCore WG'" References: <4FC34637.1050501@ericsson.com> In-Reply-To: <4FC34637.1050501@ericsson.com> Date: Thu, 7 Jun 2012 13:34:28 -0700 Message-ID: <045301cd44ec$efa793c0$cef6bb40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac08tNptvHxjG+trSnuhkG7pbfadKAIN/beA Content-Language: en-us Subject: Re: [AVTCORE] Errata on RFC 4771 - "Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)" 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: Thu, 07 Jun 2012 20:34:32 -0000 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Magnus Westerlund > Sent: Monday, May 28, 2012 2:33 AM > To: IETF AVTCore WG > Subject: [AVTCORE] Errata on RFC 4771 - "Integrity Transform Carrying > Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)" >=20 > WG, >=20 > Although not produced by this WG, as we are responsible for SRTP it > might be of interest for this community to know that there has been > field an errata on RFC 4771 - "Integrity Transform Carrying Roll-Over > Counter for the Secure Real-time Transport Protocol (SRTP)" >=20 > http://www.rfc-editor.org/errata_search.php?eid=3D3233 >=20 > Errata ID: 3233 >=20 > Status: Reported > Type: Technical >=20 > Reported By: Mats N=E4slund > Date Reported: 2012-05-28 >=20 > Section 2 says: >=20 > When the receiver receives an SRTP packet, it processes the packet > according to RFC 3711 except that during authentication processing > ROC_local is replaced by ROC_sender (retrieved from the packet). >=20 >=20 > It should say: >=20 > When the receiver receives an SRTP packet, it processes the packet > according to RFC 3711 except that during replay check and > authentication > processing > ROC_local is replaced by ROC_sender (retrieved from the packet). >=20 >=20 > Notes: >=20 > While this is typo, it has the unfortunate side effect of creating a > possibility for a replay attack where the attacker injects a previous > message, possibly causing the receiver to loose synch on the ROC = value. > This is prevented if the receiver uses ROC_sender in place of = ROC_local > during both authentication _and_ replay check. >=20 > We thank David McGrew for spotting this error. I would Approve this errata. =20 -d > -- >=20 > Cheers >=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From ray.vanbrandenburg@tno.nl Fri Jun 8 00:44:23 2012 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 535CB21F85F0 for ; Fri, 8 Jun 2012 00:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.16 X-Spam-Level: X-Spam-Status: No, score=0.16 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] 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 CIuK8gVkbz9g for ; Fri, 8 Jun 2012 00:44:21 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 66A6D21F85E7 for ; Fri, 8 Jun 2012 00:44:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,736,1330902000"; d="scan'208,217";a="70315799" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 08 Jun 2012 09:44:19 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.96]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.02.0283.003; Fri, 8 Jun 2012 09:44:18 +0200 From: "Brandenburg, R. (Ray) van" To: Roni Even , "avt@ietf.org" Thread-Topic: [AVTCORE] comments on draft-ietf-avtcore-idms-04 Thread-Index: Ac06AF5PKfMfCU49TDCoStzqXbfshALSOi3g Date: Fri, 8 Jun 2012 07:44:18 +0000 Message-ID: References: <4fbebd05.8854b40a.6284.ffff9d1e@mx.google.com> In-Reply-To: <4fbebd05.8854b40a.6284.ffff9d1e@mx.google.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: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581C5E6775EXCMBX03tsntnon_" MIME-Version: 1.0 Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-idms-04 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: Fri, 08 Jun 2012 07:44:23 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581C5E6775EXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Roni, Thanks for your valuable review. Comments inline. We will upload a new vers= ion somewhere next week. Ray From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni = Even Sent: vrijdag 25 mei 2012 0:56 To: avt@ietf.org Subject: [AVTCORE] comments on draft-ietf-avtcore-idms-04 Hi, I reviewed the draft and have some comments 1. In section 6 you have the sentence "If the RTCP Packet Sender is a= n SC (SPST=3D1) or an MSAS (SPST=3D2)" but above the value 2 is not defined= for this document. Do you expect systems that support this document to als= o support the ETSI XR report from the MSAS? RvB: The idea is that this document defines SPST 1 and 2, while the ETSI do= cument provides some optional extensions (e.g. SPST 3 and 4). 2. In section 6 when defining Packet Presented NTP timestamp it says = "This timestamp reflects the wall clock time at the moment the data contain= ed in the first octet of the associated RTP packet is presented to the use= r " I am not sure how to know this since the displayed information is not t= he RTP information but the decoded information so it is not clear what is t= he first byte. I think that maybe it will good to state in the definition h= ere and in the packet received that it is the first byte of the first packe= t in the frame or the first byte in the rendered frame. I think that in sec= tion 7 you have a better definition. RvB: Your right, I will change the definition to reflect that. 3. About the SDP parameters in section 9 and 10. Are these negotiated= between the MCs and the MSAS or just announced by the MSAS. It will be go= od to clarify the usage RvB: We will add a section to describe how the SDP parameters can be used. = In summary: in most cases the SDP parameters are negotiated. However, in so= me cases (e.g. IPTV Multicast scenarios), they might be announced by the MS= AS. 4. I understand that you list the two SDP parameter but the SC need o= ne of them depending if it supports the ETSI version or this one. Based on = the previous question response it will be good to list the proposed SDP sen= t from the MSAS. RvB: We will add a section with some recommendations on how the MSAS should= deal with the different SDP parameters. 5. I am also not sure how the MSAS will know if to send the RTCP mes= sage or the RTCP-XR message. It is mentioned in section 11 what it should d= o but not how the MSAS know which one to send. RvB: This will be covered by the section proposed under 4) 6. In section 13 it will be good to say that the security considerati= on of RFC 3611 apply here also. RvB: I agree, I will add it. 7. The IANA section is not clear explain one by one what to do with t= he four entities. As for the ETSI ones (the RTCP-XR and SFP) do you want t= o change them or have a reference to this document, if not they are not nee= ded as IANA consideration since there is no IANA action there. RvB: The idea is that we don't change the ETSI ones to maintain compatibili= ty. I will clarify this section to reflect that. 8. You can remove section 16. RvB: Ok. Roni Even as Individual This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1581C5E6775EXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Roni= ,

&n= bsp;

Thanks = for your valuable review. Comments inline. We will upload a new version som= ewhere next week.

&n= bsp;

Ray

&n= bsp;

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: vrijdag 25 mei 2012 0:56
To: avt@ietf.org
Subject: [AVTCORE] comments on draft-ietf-avtcore-idms-04=

 

Hi,

I reviewed the draft and have s= ome comments

 

1. &nbs= p;     In section 6 you have t= he sentence "If the RTCP Packet Sender is an SC (SPST=3D1) or an MSAS = (SPST=3D2)" but above the value 2 is not defined for this document. Do= you expect systems that support this document to also support the ETSI XR report from the MSAS?

RvB: Th= e idea is that this document defines SPST 1 and 2, while the ETSI document = provides some optional extensions (e.g. SPST 3 and 4).

2. &nbs= p;     In section 6 when defin= ing Packet Presented NTP timestamp it says "This timestamp reflects th= e wall clock time at the moment the data contained in the first octet = of the associated RTP packet is presented to the user " I am not sure how to know this since the displayed informa= tion is not the RTP information but the decoded information so it is not cl= ear what is the first byte. I think that maybe it will good to state in the= definition here and in the packet received that it is the first byte of the first packet in the frame or the first by= te in the rendered frame. I think that in section 7 you have a better defin= ition.

RvB: Yo= ur right, I will change the definition to reflect that.

3. &nbs= p;     About the SDP parameter= s in section 9 and 10. Are these negotiated between the MCs and the MSAS or= just announced by the MSAS.  It will be good to clarify the usage

RvB: We= will add a section to describe how the SDP parameters can be used. In summ= ary: in most cases the SDP parameters are negotiated. However, in some case= s (e.g. IPTV Multicast scenarios), they might be announced by the MSAS.

4. &nbs= p;     I understand that you l= ist the two SDP parameter but the SC need one of them depending if it suppo= rts the ETSI version or this one. Based on the previous question response i= t will be good to list the proposed SDP sent from the MSAS.

RvB: We= will add a section with some recommendations on how the MSAS should deal w= ith the different SDP parameters.

5. &nbs= p;      I am also not sur= e how the MSAS will know if to send the RTCP message or the RTCP-XR message= . It is mentioned in section 11 what it should do but not how the MSAS know= which one to send.

RvB: Th= is will be covered by the section proposed under 4)

6. &nbs= p;     In section 13 it will b= e good to say that the security consideration of RFC 3611 apply here also.<= o:p>

RvB: I = agree, I will add it.

7. &nbs= p;     The IANA section is not= clear explain one by one what to do with the four entities. As for the ETS= I  ones (the RTCP-XR and SFP) do you want to change them or have a ref= erence to this document, if not they are not needed as IANA consideration since there is no IANA action there.

RvB: Th= e idea is that we don’t change the ETSI ones to maintain compatibilit= y. I will clarify this section to reflect that.

8. &nbs= p;     You can remove section = 16.

RvB: Ok= .

 

Roni Even as Individual

 

 

 

This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer

--_000_FCC100FC8D6B034CB88CD8173B2DA1581C5E6775EXCMBX03tsntnon_-- From ron.even.tlv@gmail.com Sat Jun 9 23:44:47 2012 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 4875E21F8608 for ; Sat, 9 Jun 2012 23:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.643 X-Spam-Level: X-Spam-Status: No, score=-0.643 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_6CONS_WORD=0.356] 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 5ujUAyofzy-P for ; Sat, 9 Jun 2012 23:44:46 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A406D21F8475 for ; Sat, 9 Jun 2012 23:44:45 -0700 (PDT) Received: by werb13 with SMTP id b13so2139365wer.31 for ; Sat, 09 Jun 2012 23:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=p8Op+cZjaj/yamnBoPCr/yajtrZr6yALpLktbKwCaiE=; b=t56qSMmsLAVScQodq6TjO3qD8LlvRvohKSSjdeENnnx39YzKwkJM+iigedN8IYWQQE qOG6jYVm96WnrsdzyF1ouV4NnbE7PlDC+3KIIHgOW9vBOifcS65/dR8rJJNG0PrrdQgj io/57AZy2HTzTXxRE+xMtlHH2CYfyRl3HvIaYOdxjABQYEVzOFMZCiPxQiZ55WfVft6v F8Xu8w+FvVo7HX1jMO62bDFy3Rdcd8WH1ubPfGYcEwj6EuAXuESbb3kkwsyt901gjGdO mFilWEvRb7re5NOQMAINtX/zSCk0aV+RVzDHhOuK/6Z3CNTTHE3aCrnSkLWVsuseeBUL eFVg== Received: by 10.216.226.136 with SMTP id b8mr4163875weq.152.1339310684722; Sat, 09 Jun 2012 23:44:44 -0700 (PDT) Received: from windows8d787f9 ([77.241.97.116]) by mx.google.com with ESMTPS id ch9sm23460804wib.8.2012.06.09.23.44.42 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Jun 2012 23:44:43 -0700 (PDT) From: "Roni Even" To: , References: In-Reply-To: Date: Sun, 10 Jun 2012 09:41:59 +0300 Message-ID: <4fd4425b.e95bb40a.57b0.fffffbfe@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01CD46ED.4D270A10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac04ty6GngC/btD/SlKdLniA8LS56QOHHZSg Content-Language: en-us Cc: 'Magnus Westerlund' Subject: [AVTCORE] draft-williams-avtcore-clksrc-00 as a WG document 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: Sun, 10 Jun 2012 06:44:47 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01CD46ED.4D270A10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, There was support to adopt this document as a WG document. For the authors: please submit the document as draft-iet-avtcore-clksrc-00 Thanks Roni Even AVTCore co-chair From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Wednesday, May 23, 2012 10:39 AM To: 'avt@ietf.org' Cc: 'Magnus Westerlund' Subject: adopting draft-williams-avtcore-clksrc-00 as a WG document Hi, AVTcore have the following milestone: Nov 2012 - Submit RTP Clock Source Signaling as Proposed Standard The chairs propose to adopt http://tools.ietf.org/html/draft-williams-avtcore-clksrc-00 as the initial document to address this milestone. The document will also be reviewed by the SDP directorate. There are no other documents addressing this milestone so please let the chairs know if you support this action by June 6th Thanks Roni Even ------=_NextPart_000_0004_01CD46ED.4D270A10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

There was support to = adopt this document as a WG document.

 

For the authors: =  please submit the document as = draft-iet-avtcore-clksrc-00

 

Thanks

Roni = Even

AVTCore co-chair

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: Wednesday, = May 23, 2012 10:39 AM
To: 'avt@ietf.org'
Cc: 'Magnus = Westerlund'
Subject: adopting draft-williams-avtcore-clksrc-00 = as a WG document

 

Hi,

AVTcore =
 have the following milestone:
 Nov 2012 =
- Submit RTP Clock Source Signaling as Proposed =
Standard
 =

The chairs =
propose to adopt  http=
://tools.ietf.org/html/draft-williams-avtcore-clksrc-00 as the =
initial document to address this =
milestone.
 =

The =
document will also be reviewed by the SDP =
directorate.
 =

There are =
no other documents addressing this milestone so please let the chairs =
know if you support this action by June =
6th
 =

Thanks=

Roni =
Even

 

------=_NextPart_000_0004_01CD46ED.4D270A10-- From ron.even.tlv@gmail.com Sun Jun 10 00:03:46 2012 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 02DB021F869F for ; Sun, 10 Jun 2012 00:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[AWL=0.089, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 c-aCKHqXxDV2 for ; Sun, 10 Jun 2012 00:03:45 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC7521F869C for ; Sun, 10 Jun 2012 00:03:44 -0700 (PDT) Received: by werb13 with SMTP id b13so2147888wer.31 for ; Sun, 10 Jun 2012 00:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=lpST10nL79sBBjSPMIIapntUPnLBOqBiVZuBRsy/CEk=; b=Gm9IJrPjCb0QDTd6YyDmV55ng5Ii2ikb1tXqAFZY9NH8ZZ84fkga+XGSgz4z2N9qYx znOqNkyknH7lbtd7z0wqTd/mjvfT5A/PRJEgEpKxM+SdTj9GOt1Uor1bSOb2FrFvSIK2 ofa7TQkwyD6LO4Af9DL6tlcJka8Sxlv5ZgIl5ZOdEtE+WSPpkqJl5kSxsmxQj4DPE7Rd Vwg5eS6SVX68vTbvRmxpGKnL853OB7XCu2rHVlirznnYItESTFjbSanmXhAEGmiRQe4n h0XExzPuUzKLQaY+9XRoflCjY1r6NlLcI8w5VFHWf8ZM8WnnZ2FRNhM1jXK3lbiUJak6 IB9Q== Received: by 10.180.83.197 with SMTP id s5mr12095036wiy.9.1339311824140; Sun, 10 Jun 2012 00:03:44 -0700 (PDT) Received: from windows8d787f9 ([77.241.97.116]) by mx.google.com with ESMTPS id f7sm23638989wiv.2.2012.06.10.00.03.41 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Jun 2012 00:03:42 -0700 (PDT) From: "Roni Even" To: , , References: In-Reply-To: Date: Sun, 10 Jun 2012 10:01:05 +0300 Message-ID: <4fd446ce.c748b40a.1566.fffff6f2@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01CD46EF.F42BC650" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac048LoYzASM67h6SCWUcM2QQPDa6QN5Ucqg Content-Language: en-us Subject: [AVTCORE] adopting leap seconds in RTP sessions 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: Sun, 10 Jun 2012 07:03:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000E_01CD46EF.F42BC650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We got support to add a milestone for leap seconds in RTP sessions. There was also support to have http://www.ietf.org/id/draft-gross-avtcore-leap-second-00.txt as the starting point. I have asked for a new milestone to be added for AVTCore. The date for the milestone is synchronized with the cllksrc date so we can finish the IDMS work. For the authors of the document please submit it as draft-ietf-avtcore-leap-second-00. You can also incorporate the change proposed by Marshall and accepted by Kevin. Thanks Roni Even AVTCore co-chair From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Wednesday, May 23, 2012 5:31 PM To: 'avt@ietf.org' Subject: New mile stone on support for leap seconds in RTP sessions Hi, At last IETF meeting as part of the discussion on IDMS is was agreed that support for leap seconds in RTP session is relevant to RFC3550 and not only to IDMS. We would like to take a new milestone for AVTcore Nov 2012 - Submit support for leap seconds for RTP session as Proposed Standard This will be an update to RFC 3550. We would also like to adopt http://www.ietf.org/id/draft-gross-avtcore-leap-second-00.txt as a starting point for this goal. There are two questions to the WGs 1. Do you support the new milestone that will update RFC3550 2. Do you think that we should adopt the above individual draft as an initial document Please respond by June 6th Thanks Roni Even ------=_NextPart_000_000E_01CD46EF.F42BC650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We got support to add a = milestone for leap seconds in RTP sessions. There was also support to = have ht= tp://www.ietf.org/id/draft-gross-avtcore-leap-second-00.txt as the = starting point.

 

I have asked for a new = milestone to be added for AVTCore.  The date for the milestone is = synchronized with the cllksrc date so we can finish the IDMS = work.

 

For the authors of the = document please submit it as = draft-ietf-avtcore-leap-second-00.

You can also incorporate = the change proposed by Marshall and accepted by = Kevin.

 

Thanks

Roni Even =

AVTCore co-chair

 

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: Wednesday, = May 23, 2012 5:31 PM
To: 'avt@ietf.org'
Subject: New = mile stone on support for leap seconds in RTP = sessions

 

Hi,

At last IETF = meeting as part of the discussion on IDMS is was agreed that support for = leap seconds in RTP session is relevant to RFC3550 and not only to = IDMS.

We would like to take a new = milestone for AVTcore

 

Nov 2012 - = Submit support for leap seconds for RTP session  as Proposed = Standard

This will be an update to = RFC 3550.

 

We would also like to adopt ht= tp://www.ietf.org/id/draft-gross-avtcore-leap-second-00.txt as a = starting point for this goal.

 

There are = two questions to the WGs

 

1.       = Do you support the new = milestone that will update RFC3550

2.       = Do you think that we = should adopt the above individual draft as an initial = document

 

 

Please = respond by June 6th

 

Thanks

Roni = Even

 

------=_NextPart_000_000E_01CD46EF.F42BC650-- From ron.even.tlv@gmail.com Sun Jun 10 00:15:23 2012 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 DA2A021F86A5 for ; Sun, 10 Jun 2012 00:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[AWL=0.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 V-BvawDAXI2y for ; Sun, 10 Jun 2012 00:15:20 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3557921F86A6 for ; Sun, 10 Jun 2012 00:15:20 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1408312wgb.13 for ; Sun, 10 Jun 2012 00:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=PGSlZzFHgmokuD54Dab3vMa9dTA+frVjwEfukldLN64=; b=t2+BOWpeGffzIsV7Vu/rpt6fQqQYVkjY07jhEclbIobOax/3yBru1aPjit+/UXeP5e zES/BCkehGBNXSQItQXhGFBgXBfXFd9HVLdcH2lNAJ2PsfTJLIKJHGxDsEq4JlzjUKtE 6zquXqRwf/rjXVlTashEJwVqdHjZu+khlNfvJ5hiOBiUkVKGp0IDAkChQht8x5nsQ87l aa8PdsumcNUIIEW5nTnEdUTIbv6ZJYJ87Y8PDDhcSa8CfoJLFfgrxoNrlvvXQqZMDUek 7Pl3ISpZT0F8dJ77tGlN3K+cmmnTmy/v9Pb/QMtOfQA+1JyYhsai331EQbUoFV4m6fxY bQtQ== Received: by 10.216.198.164 with SMTP id v36mr4443880wen.199.1339312519005; Sun, 10 Jun 2012 00:15:19 -0700 (PDT) Received: from windows8d787f9 ([77.241.97.116]) by mx.google.com with ESMTPS id z8sm23742010wiy.1.2012.06.10.00.15.16 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Jun 2012 00:15:17 -0700 (PDT) From: "Roni Even" To: "'Brandenburg, R. \(Ray\) van'" , References: <4fbebd05.8854b40a.6284.ffff9d1e@mx.google.com> In-Reply-To: Date: Sun, 10 Jun 2012 10:12:39 +0300 Message-ID: <4fd44985.8854b40a.4557.0d03@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01CD46F1.920A8CC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac06AF5PKfMfCU49TDCoStzqXbfshALSOi3gAGOTC8A= Content-Language: en-us Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-idms-04 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: Sun, 10 Jun 2012 07:15:24 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001D_01CD46F1.920A8CC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ray, Thanks for the response. I only have a suggestion on the first comment. 1. In section 6 you have the sentence "If the RTCP Packet Sender is an SC (SPST=1) or an MSAS (SPST=2)" but above the value 2 is not defined for this document. Do you expect systems that support this document to also support the ETSI XR report from the MSAS? RvB: The idea is that this document defines SPST 1 and 2, while the ETSI document provides some optional extensions (e.g. SPST 3 and 4). Roni: I had this comment since I was not sure from this section what is the use for SPST=2. Maybe you can point here to section 11 where you explain it or the new section if it will address this. As a Chair: After you submit an update I can start a WGLC Roni From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] Sent: Friday, June 08, 2012 10:44 AM To: Roni Even; avt@ietf.org Subject: RE: [AVTCORE] comments on draft-ietf-avtcore-idms-04 Hi Roni, Thanks for your valuable review. Comments inline. We will upload a new version somewhere next week. Ray From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even Sent: vrijdag 25 mei 2012 0:56 To: avt@ietf.org Subject: [AVTCORE] comments on draft-ietf-avtcore-idms-04 Hi, I reviewed the draft and have some comments 2. In section 6 you have the sentence "If the RTCP Packet Sender is an SC (SPST=1) or an MSAS (SPST=2)" but above the value 2 is not defined for this document. Do you expect systems that support this document to also support the ETSI XR report from the MSAS? RvB: The idea is that this document defines SPST 1 and 2, while the ETSI document provides some optional extensions (e.g. SPST 3 and 4). 3. In section 6 when defining Packet Presented NTP timestamp it says "This timestamp reflects the wall clock time at the moment the data contained in the first octet of the associated RTP packet is presented to the user " I am not sure how to know this since the displayed information is not the RTP information but the decoded information so it is not clear what is the first byte. I think that maybe it will good to state in the definition here and in the packet received that it is the first byte of the first packet in the frame or the first byte in the rendered frame. I think that in section 7 you have a better definition. RvB: Your right, I will change the definition to reflect that. 4. About the SDP parameters in section 9 and 10. Are these negotiated between the MCs and the MSAS or just announced by the MSAS. It will be good to clarify the usage RvB: We will add a section to describe how the SDP parameters can be used. In summary: in most cases the SDP parameters are negotiated. However, in some cases (e.g. IPTV Multicast scenarios), they might be announced by the MSAS. 5. I understand that you list the two SDP parameter but the SC need one of them depending if it supports the ETSI version or this one. Based on the previous question response it will be good to list the proposed SDP sent from the MSAS. RvB: We will add a section with some recommendations on how the MSAS should deal with the different SDP parameters. 6. I am also not sure how the MSAS will know if to send the RTCP message or the RTCP-XR message. It is mentioned in section 11 what it should do but not how the MSAS know which one to send. RvB: This will be covered by the section proposed under 4) 7. In section 13 it will be good to say that the security consideration of RFC 3611 apply here also. RvB: I agree, I will add it. 8. The IANA section is not clear explain one by one what to do with the four entities. As for the ETSI ones (the RTCP-XR and SFP) do you want to change them or have a reference to this document, if not they are not needed as IANA consideration since there is no IANA action there. RvB: The idea is that we don't change the ETSI ones to maintain compatibility. I will clarify this section to reflect that. 9. You can remove section 16. RvB: Ok. Roni Even as Individual This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer ------=_NextPart_000_001D_01CD46F1.920A8CC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ray,

Thanks for the response. = I only have a suggestion on the first comment.

 

1.       = In section 6 you have the = sentence "If the RTCP Packet Sender is an SC (SPST=3D1) or an MSAS = (SPST=3D2)" but above the value 2 is not defined for this document. = Do you expect systems that support this document to also support the = ETSI XR report from the MSAS?

RvB: The idea is that this document defines SPST = 1 and 2, while the ETSI document provides some optional extensions (e.g. = SPST 3 and 4).  

Roni: I had this comment since I was not sure = from this section what is the use for SPST=3D2. Maybe you can point here = to section 11 where you explain it or the new section if it will address = this.

 

 

As a Chair: After you = submit an update I can start a WGLC

Roni

 

From:= = Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] =
Sent: Friday, June 08, 2012 10:44 AM
To: Roni Even; = avt@ietf.org
Subject: RE: [AVTCORE] comments on = draft-ietf-avtcore-idms-04

 

Hi Roni,

 

Thanks for your valuable = review. Comments inline. We will upload a new version somewhere next = week.

 

Ray

 

From:= = avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] = On Behalf Of Roni Even
Sent: vrijdag 25 mei 2012 = 0:56
To: avt@ietf.org
Subject: = [AVTCORE] comments on = draft-ietf-avtcore-idms-04

 

Hi,

I reviewed the = draft and have some comments

 

2.       = In section 6 you have the = sentence "If the RTCP Packet Sender is an SC (SPST=3D1) or an MSAS = (SPST=3D2)" but above the value 2 is not defined for this document. = Do you expect systems that support this document to also support the = ETSI XR report from the MSAS?

RvB: The idea is that this document defines SPST = 1 and 2, while the ETSI document provides some optional extensions (e.g. = SPST 3 and 4).

3.       = In section 6 when = defining Packet Presented NTP timestamp it says "This timestamp = reflects the wall clock time at the moment the data contained in the = first octet  of the associated RTP packet is presented to the user = " I am not sure how to know this since the displayed information is = not the RTP information but the decoded information so it is not clear = what is the first byte. I think that maybe it will good to state in the = definition here and in the packet received that it is the first byte of = the first packet in the frame or the first byte in the rendered frame. I = think that in section 7 you have a better definition.

RvB: Your right, I will = change the definition to reflect that.

4.       = About the SDP parameters = in section 9 and 10. Are these negotiated between the MCs and the MSAS = or just announced by the MSAS.  It will be good to clarify the = usage

RvB: We will add a section to describe how the = SDP parameters can be used. In summary: in most cases the SDP parameters = are negotiated. However, in some cases (e.g. IPTV Multicast scenarios), = they might be announced by the MSAS.

5.       = I understand that you = list the two SDP parameter but the SC need one of them depending if it = supports the ETSI version or this one. Based on the previous question = response it will be good to list the proposed SDP sent from the = MSAS.

RvB: We will add a section with some = recommendations on how the MSAS should deal with the different SDP = parameters.

6.       =  I am also not sure = how the MSAS will know if to send the RTCP message or the RTCP-XR = message. It is mentioned in section 11 what it should do but not how the = MSAS know which one to send.

RvB: This will be covered by the section = proposed under 4)

7.       = In section 13 it will be = good to say that the security consideration of RFC 3611 apply here = also.

RvB: I agree, I will add = it.

8.       = The IANA section is not = clear explain one by one what to do with the four entities. As for the = ETSI  ones (the RTCP-XR and SFP) do you want to change them or have = a reference to this document, if not they are not needed as IANA = consideration since there is no IANA action there.

RvB: The idea is that we = don’t change the ETSI ones to maintain compatibility. I will = clarify this section to reflect that.

9.       = You can remove section = 16.

RvB: Ok.

 

Roni Even as = Individual

 

 

 

This e-mail = and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclai= mer

------=_NextPart_000_001D_01CD46F1.920A8CC0-- From wwwrun@rfc-editor.org Mon Jun 11 15:49:52 2012 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 BA1F211E80E1; Mon, 11 Jun 2012 15:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, 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 r03CcGtYrcuy; Mon, 11 Jun 2012 15:49:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E40AD11E80DE; Mon, 11 Jun 2012 15:49:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 88CBFB1E022; Mon, 11 Jun 2012 15:49:42 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120611224942.88CBFB1E022@rfc-editor.org> Date: Mon, 11 Jun 2012 15:49:42 -0700 (PDT) Cc: avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVTCORE] RFC 6642 on RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report 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: Mon, 11 Jun 2012 22:49:52 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6642 Title: RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report Author: Q. Wu, Ed., F. Xia, R. Even Status: Standards Track Stream: IETF Date: June 2012 Mailbox: sunseawq@huawei.com, xiayangsong@huawei.com, even.roni@huawei.com Pages: 13 Characters: 29758 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avtcore-feedback-supression-rtp-17.txt URL: http://www.rfc-editor.org/rfc/rfc6642.txt In a large RTP session using the RTP Control Protocol (RTCP) feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion. This memo discusses these cases and defines a new RTCP Third-Party Loss Report that can be used to inform receivers that the feedback target is aware of some loss event, allowing them to suppress feedback. Associated Session Description Protocol (SDP) signaling is also defined. [STANDARDS-TRACK] This document is a product of the Audio/Video Transport Core Maintenance Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From xiayangsong@huawei.com Mon Jun 11 22:38:42 2012 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 CEF6421F858A; Mon, 11 Jun 2012 22:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] 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 KfdXRqp3cuMK; Mon, 11 Jun 2012 22:38:42 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A41F321F857F; Mon, 11 Jun 2012 22:38:36 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGV55739; Tue, 12 Jun 2012 01:38:36 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 11 Jun 2012 22:38:29 -0700 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 11 Jun 2012 22:38:27 -0700 Received: from SZXEML539-MBX.china.huawei.com ([169.254.6.126]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Tue, 12 Jun 2012 13:38:22 +0800 From: Xiayangsong To: "rfc-editor@rfc-editor.org" , "ietf-announce@ietf.org" , "rfc-dist@rfc-editor.org" Thread-Topic: [AVTCORE] RFC 6642 on RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report Thread-Index: AQHNSCVkUZLBJsOwZUui9pwz66Ph5pb2KrXw Date: Tue, 12 Jun 2012 05:38:21 +0000 Message-ID: References: <20120611224942.88CBFB1E022@rfc-editor.org> In-Reply-To: <20120611224942.88CBFB1E022@rfc-editor.org> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.103.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "avt@ietf.org" Subject: Re: [AVTCORE] RFC 6642 on RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report 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, 12 Jun 2012 05:38:43 -0000 Thanks to Qin for his hardworking. -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of rfc-e= ditor@rfc-editor.org Sent: Tuesday, June 12, 2012 6:50 AM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: avt@ietf.org; rfc-editor@rfc-editor.org Subject: [AVTCORE] RFC 6642 on RTP Control Protocol (RTCP) Extension for a = Third-Party Loss Report A new Request for Comments is now available in online RFC libraries. =20 RFC 6642 Title: RTP Control Protocol (RTCP) Extension=20 for a Third-Party Loss Report=20 Author: Q. Wu, Ed., F. Xia, R. Even Status: Standards Track Stream: IETF Date: June 2012 Mailbox: sunseawq@huawei.com,=20 xiayangsong@huawei.com,=20 even.roni@huawei.com Pages: 13 Characters: 29758 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avtcore-feedback-supression-rtp-17.txt URL: http://www.rfc-editor.org/rfc/rfc6642.txt In a large RTP session using the RTP Control Protocol (RTCP) feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion. This memo discusses these cases and defines a new RTCP Third-Party Loss Report that can be used to inform receivers that the feedback target is aware of some loss event, allowing them to suppress feedback. Associated Session Description Protocol (SDP) signaling is also defined. [STANDARDS-TRACK] This document is a product of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From woohwankim@gmail.com Wed Jun 13 00:25:02 2012 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 11EB521F85F6 for ; Wed, 13 Jun 2012 00:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 b4Frfoh03I+3 for ; Wed, 13 Jun 2012 00:24:59 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CE4BB21F85D1 for ; Wed, 13 Jun 2012 00:24:58 -0700 (PDT) Received: by vcqp1 with SMTP id p1so161445vcq.31 for ; Wed, 13 Jun 2012 00:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=QPEb1g0durCZGhLHojLYjTLckhCzAbkjLRsJH/+2UGA=; b=QHCWL2fWAundAr2DDUg8w+wvhCooyTOXvRhzmd/2H1ww7Q8AAdW7dpkxhQc47RsJyR SOStI3LF/a2xKVqfeqVeOlE0d03YMbRdH5u+NDdv3NxlBeZRz0iMrTwu1S5JjZfX8N4g cYuK9VvCN1ITA9jixw6gHJLIfnhImQSUsN2LL8Jh85mJXiGAmPn+2/saINgoQjEFBS7T eE5AJRhTwKX4SiNv0YVMb/Cpiipb8ztsYGFDhHHNxJsbelBgByZTA3uouHCPeZqDSzvB xHfRII+WHmc6SBgj3EaY38UE54OuDFU5Y0WJI3RcgIV77olbXonl1TwSUavYgAepqCbz VytQ== MIME-Version: 1.0 Received: by 10.220.141.15 with SMTP id k15mr832326vcu.30.1339572298074; Wed, 13 Jun 2012 00:24:58 -0700 (PDT) Sender: woohwankim@gmail.com Received: by 10.52.95.12 with HTTP; Wed, 13 Jun 2012 00:24:58 -0700 (PDT) Date: Wed, 13 Jun 2012 16:24:58 +0900 X-Google-Sender-Auth: QxjN2_lYVJpfcNsfpkIkq4I9CXU Message-ID: From: Woo-Hwan Kim To: Magnus Westerlund Content-Type: multipart/alternative; boundary=f46d042f9d3cfa4a3b04c2557ae2 Cc: Daesung Kwon , avt@ietf.org, Je Hong Park Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00 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: Wed, 13 Jun 2012 07:25:02 -0000 --f46d042f9d3cfa4a3b04c2557ae2 Content-Type: text/plain; charset=ISO-8859-1 Further more, It is better to include 'GCM' in the caption of Figure 6 (as in the previous draft) since it does not hold for CCM. In Sec 2.3, there is a typo. - IV abd => IV and Thanks, Woo-Hwan Kim > Date: Tue, 22 May 2012 10:18:27 +0200 > From: Magnus Westerlund > To: draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org > Cc: IETF AVTCore WG > Subject: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00 > Message-ID: <4FBB4BD3.9000909@ericsson.com> > Content-Type: text/plain; charset="ISO-8859-1" > > Hi, > > I got a request to progress this document towards WG last call. So while > we chairs are cleaning up some administrative stuff, like getting a > milestone in place. I thought the authors should get something to do and > thus reviewed the draft. > > 1) Section 1.1 > "Crypto Context For the purposes of this document a crypto context > is the outcome of any process which results in > authentication of each participant in the SRTP > session and possession by each partcipant of a > shared secret master key and a shared master > salt." > > What is the definition of participant here, SSRC, endpoint, user, or > system? Please correct the "partcipant" spelling error also. > > 2) Section 1.1, crypto context: " Ciper Contest" I guess should be > Crypto Context. > > 3) Section 1.1. is the text for crypto context really accurate as the > document does define protection profiles for both DTLS-SRTP and Security > description. > > 4) I am missing protection profiles for MIKEY. I think they should be > defined as MIKEY is the third key-management protocol and are used in a > lot of cases which neither DTLS-SRTP and Security Description are > suitable for. > > 5) Section 1.1 Instantiation: > "each participant in the SRTP/SRTCP > session will need four instantiations of the AEAD > algorithm; one for inbound SRTP traffic, one for > outbound SRTP traffic source, one for inbound > SRTCP traffic, and one for outbound SRTCP traffic > source. " > > Is this really correct. This seems to be limiting the use of AEAD to > point to point scenarios? The other crypto transforms for SRTP are > capable of handling group scenarios. DTLS-SRTP with EKT for example > would allow each end-point to distribute its own master key that it will > use for the SSRCs it sends. There are also scenarios where one use a > common master key for all participants. > > 6) Section 1.2: Associated Data This is data that is to be > authenticated > but not encrypted. In SRTP, the associated > data consists of the entire RTP header, > including the list of CSRC identifiers (if > present) and the RTP header extension (if > present), as shown in Figure 3. > > Shouldn't this point to and discuss the relation to > draft-ietf-avtcore-srtp-encrypted-header-ext-01 > > 7. Section 1.2: > Associated Data This is data that is to be authenticated > but not encrypted. In SRTP, the associated > data consists of the entire RTP header, > including the list of CSRC identifiers (if > present) and the RTP header extension (if > present), as shown in Figure 3. > > Plaintext Data that is to be both encrypted and > authenticated. In SRTP this consists of > the RTP payload, the RTP padding and the > RTP pad count fields (if the latter two > fields are present) as shown in Figure 3. > The padding service provided by RTP is not > needed by the AEAD encryption algorithm, so > the RTP padding and RTP pad count fields > SHOULD be omitted. > > Why are these paragraphs not discussing RTCP? > > 8. Section 1.2.1: > (Note that this means > that the cipher text will be longer than the plain text by precisely > the length of the AEAD authentication tag.) > > This needs more extensive discussion as it needs to be taken into > account in RTP/RTCP when determine packet sizes both for generating > right sized RTP that don't violate MTU and that they are included in the > RTCP avg_rtcp_size parameter part of the scheduling algorithm. > > 9. Section 1.2.2: For confirmation: > > Packet Counter Each AEAD instantiation MUST maintain a 6 octet > zero-based packet counter which is incremented > each time an SRTP packet is sent. As we shall > see below, the packet counter is used to insure > each SRTP packet gets a unique initialization > vector. > > Can this use the "ROC" distribution mechanism (RFC4771) or what the > key-management provide to correctly deduce the field, or will it have > problems with late joiners in a group communication? > > 10. Section 1.2.2 Packet Counter: > > "zero-based packet counter" Does this mean that the 6 octet long field > is initialized to 0 and thus violate the recommendation of RTP sequence > number requirement of random start position. > > 11. Section 1.5: I don't like using the figure to indicate what is of > different types. Two reasons. The first is that it doesn't explicitly > enumerate protocol fields, instead 32-bytes octet with fields. Secondly > because it make it hard for someone that can't see to correctly > interpret this. Think if Sam Hartman would like to read this spec. You > made it much more difficult for him. You had a description earlier that > with a bit more precision would be correct, after having dealt with > comment 6 and what needs to be included due to that. > > 12. Section 1.6. AEAD Processing of SRTCP Packets > > All SRTCP packets MUST be authenticated, but unlike SRTP, SRTCP > packet encryption is optional. A sender can select which packets to > encrypt, and indicates this choice with a 1-bit encryption flag > (located in the leftmost bit of the 32-bit word that contains the > SRTCP index) > > I think it is important to write "SRTCP packet" as SRTCP compount > packet. As each individual RTCP packet can't be individually encrypted > or not in the same compound packet. > > 13. Section 1.6.1 and 1.6.2. Same as comment 11 on this section. Here > you may have to talk about octets as it is defined as the first of > 32-bit words of the first RTCP packet part of the compound that are > unencrypted. > > 14. Section 1.8. Prevention of IV Reuse > > For a given key it is critical that the IV not repeat. This reduces > to the problem of insuring neither the Packet Counter nor the SRTCP > index do not repeat before the AEAD instantiation is rekeyed. > > Processing MUST cease if either the 48-bit Packet Counter or the > 31-bit SRTCP index cycles back to their initial value. Processing > MUST NOT resume until a new SRTP/SRTCP session has been established > using a new shared secret master key and shares master salt. > Ideally, a rekey should be done well before either of these counters > cycle. > > This section fails to discuss another issue where IV reuse could arise. > Namely SSRC collision. If more than a single end-point uses the same > SSRC there can be collision. This either put stringent requirements on > how one key this crypto transform in different topologies or the usage > of SSRC assignment rules. As the later is not really present it might be > worth defining rules and be clear on the impact of an SSRC collision. > > 15. Section 2.1: > C_MAX maximum ciphertext MUST be at most 2^16-40 octets > length per invocation SHOULD be at least 2232 > > I think the lower bound reasonsing is flawed. First of all there is RTCP > that has only IPv4/UDP + 2 32-bits word of none plaintext RTCP headers > thus making it 38 bytes. In addition what about IP Jumbogram (RFC 2675) > which support packet sizes of 2^32 bytes. > > I think the max should be set to what the upper limit where something > breaks. Is 2^32 a working limit from crypto perspective, in that case I > think you should use that. > > 16. Minimal value for C_MAX > Similarly the lower bound on C_MAX is based on the maximum > transmission unit (MTU) of 2272 octets in IEEE 802.11. Because many > RTP applications use very short payloads (for example, the G.729 > codec used in VoIP can be as short as 20 octets), implementations > that only support a maximum ciphertext length smaller than 2232 > octets are permitted under this RFC. However, in the interest of > maximizing interoperability between various AEAD implementations, the > use of C_MAX values less than 2232 is discouraged. > > I actually think the minimum value should be that a C_MAX value of 2234 > MUST be supported. My reasoning is that it must be 2 bytes larger to > support full MTU RTCP. Then it really should be a MUST to ensure that > one knows that a counter part can support that size of plaintext. I > would like to point out that the current key-management systems aren't > the greatest for negotiating a lot of sub-parameters. For example my > understanding is that DTLS-SRTP only support negoptiating whole > profiles, not sub-parameters at all. > > So if you are not specifying a hard limit what packet size a receiver > must support how do you know that you can interoperate? > > At the same time I realize that this is not optimal for a very > constrained device that sends encrypted real-time payloads of some type > that are much smaller and actually don't have the buffering space for so > large packets. > > Maybe the way forward is to separate the C_max value boundary and the > minimal value supported for the defiended profiles and make it clear > that the protection profiles defined in 2.2 and 2.3 actually requires a > C_max that is 2234. > > > 17. Section 2.1: > > For sake of clarity we specify two additional parameters: > > Authentication Tag Length MUST be either 8, 12, or 16 > octets > Maximum number of invocations MUST be at most 2^48 for SRTP > for a given instantiation MUST be at most 2^31 for SRTCP > > As these parameters are for AEAD algorithms in general, how can you be > certain that no one likes an authentication tag length longer than 16 > bytes or for that matter one that is 14 bytes? > > I guess the maximum number of invocations also comes from an assumption > around the IV construction. Which I am not certain holds as you clearly > defined the IV specifically for the algorithms and other AEAD algorithms > can make a different choice for IV including an explicit one, can't > they? Thus does these max values really hold? > > 18. Section 2.2 > In addition to the Packet Counter used in the formation of IVs, each > instantiation of AES-GCM has a block counter which is incremented > each time AES is called to produce a 16-octet output block. > > I would prefer that you where more explicit about the lenght of the > block counters length, i.e ... AES-GCM has a block counter (32-bit) > which ... > > This also applies to the corresponding text in 2.3. > > 19. Section 2.3: > For AES-CCM in SRTP/SRTCP, the > flag octet has the hex value 5A if an 8-octet authentication tag is > used, 6A if a 12-octet authentication tag is used, and 7A if a > 16-octet authentication tag is used. The flag octet is one of the > inputs to AES during the counter mode encryption of the plaintext. > > Considering that the table only defines the modes that has 16-octet auth > tags, whats the point of mentioning the other lengths? > > 20. Section 4: > > RFC 4568 defines SRTP "crypto suites" > > I would prefer that one instead of just using the "RFC 4568" as handle > to the specification instead included the title or an abbreviated one at > least. Like this: > > Security Descriptions [RFC4586] defines SRTP "crypto suites" > > This I think is much more clear as I don't have to go to the reference > section if I don't directly remember what the RFC number is. > > 21. Section 4: > > RFC 4568 defines SRTP "crypto suites"; a crypto suite corresponds to > a particular AEAD algorithm in SRTP. In order to allow SDP to signal > the use of the algorithms defined in this document, IANA will > register the following crypto suites into the subregistry for SRTP > crypto suites under the SRTP transport of the SDP Security > Descriptions: > > srtp-crypto-suite-ext = "AEAD_AES_128_GCM" / > "AEAD_AES_256_GCM" / > "AEAD_AES_128_GCM_8" / > "AEAD_AES_256_GCM_8" / > "AEAD_AES_128_GCM_12" / > "AEAD_AES_256_GCM_12" / > "AEAD_AES_128_CCM" / > "AEAD_AES_256_CCM" / > > Igoe and McGrew Informational [Page 15] > Internet Draft AES-GCM and AES-CCM for SRTP Feb 17, 2012 > > srtp-crypto-suite-ext > > I don't think this fulfills the registration requirement in that it > hasn't made it clear how the key-salt structure for inline method are > constructed. How many bits of keys, and how many bits of salt is to be > included in the structure. > > 22. Section 4: > > When it comes to DTLS-SRTP the protection profiles defined in RFC 5764 > has the following information defined in its section 4.1.2 > SRTP_AES128_CM_HMAC_SHA1_80 > cipher: AES_128_CM > cipher_key_length: 128 > cipher_salt_length: 112 > maximum_lifetime: 2^31 > auth_function: HMAC-SHA1 > auth_key_length: 160 > auth_tag_length: 80 > > I believe this information is present, but maybe it should be collected > together. It also doesn't define how the AEAD parameters defined in this > specification actually are parameterized when needed. > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F?r?gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > > ------------------------------ > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > > End of avt Digest, Vol 97, Issue 11 > *********************************** > --f46d042f9d3cfa4a3b04c2557ae2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Further more,

It i= s better to include 'GCM' in the caption of Figure 6 (as in the pre= vious draft)
since it does not hold for CCM.

In Sec 2.3, there is a typo.
- IV abd =3D> IV and

Thanks,

Woo-Hwan Kim
<= br>
=A0
Date: Tue, 22 May 2012 10:18:27 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: draft= -ietf-avtcore-srtp-aes-gcm@tools.ietf.org
Cc: IETF AVTCore WG <avt@ietf.org>= ;
Subject: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00
Message-ID: <4FBB4BD3.9= 000909@ericsson.com>
Content-Type: text/plain; charset=3D"ISO-8859-1"

Hi,

I got a request to progress this document towards WG last call. So while we chairs are cleaning up some administrative stuff, like getting a
milestone in place. I thought the authors should get something to do and thus reviewed the draft.

1) Section 1.1
"Crypto Context =A0For the purposes of this document a crypto context<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0is the outcome of any process w= hich results in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0authentication of each particip= ant in the SRTP
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0session and possession by each = partcipant of a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0shared secret master key and a = shared master
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0salt."

What is the definition of participant here, SSRC, endpoint, user, or
system? Please correct the "partcipant" spelling error also.

2) Section 1.1, crypto context: " Ciper Contest" I guess should b= e
Crypto Context.

3) Section 1.1. is the text for crypto context really accurate as the
document does define protection profiles for both DTLS-SRTP and Security description.

4) I am missing protection profiles for MIKEY. I think they should be
defined as MIKEY is the third key-management protocol and are used in a
lot of cases which neither DTLS-SRTP and Security Description are
suitable for.

5) Section 1.1 Instantiation:
"each participant in the SRTP/SRTCP
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0session will need four instanti= ations of the AEAD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0algorithm; one for inbound SRTP= traffic, one for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0outbound SRTP traffic source, o= ne for inbound
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0SRTCP traffic, and one for outb= ound SRTCP traffic
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0source. "

Is this really correct. This seems to be limiting the use of AEAD to
point to point scenarios? The other crypto transforms for SRTP are
capable of handling group scenarios. DTLS-SRTP with EKT for example
would allow each end-point to distribute its own master key that it will use for the SSRCs it sends. There are also scenarios where one use a
common master key for all participants.

6) Section 1.2: =A0Associated Data =A0 =A0 =A0 =A0 This is data that is to = be
authenticated
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 but not encrypted.= =A0In SRTP, the associated
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 data consists of t= he entire RTP header,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 including the list= of CSRC identifiers (if
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 present) and the R= TP header extension (if
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 present), as shown= in Figure 3.

Shouldn't this point to and discuss the relation to
draft-ietf-avtcore-srtp-encrypted-header-ext-01

7. Section 1.2:
=A0Associated Data =A0 =A0 =A0 =A0 This is data that is to be authenticated=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 but not encrypted.= =A0In SRTP, the associated
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 data consists of t= he entire RTP header,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 including the list= of CSRC identifiers (if
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 present) and the R= TP header extension (if
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 present), as shown= in Figure 3.

=A0 =A0 Plaintext =A0 =A0 =A0 =A0 =A0 =A0 =A0 Data that is to be both encr= ypted and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 authenticated. =A0= In SRTP this consists of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the RTP payload, t= he RTP padding and the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RTP pad count fiel= ds (if the latter two
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fields are present= ) as shown in Figure 3.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The padding servic= e provided by RTP is not
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 needed by the AEAD= encryption algorithm, so
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the RTP padding an= d RTP pad count fields
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SHOULD be omitted.=

Why are these paragraphs not discussing RTCP?

8. Section 1.2.1:
(Note that this means
=A0 that the cipher text will be longer than the plain text by precisely =A0 the length of the AEAD authentication tag.)

This needs more extensive discussion as it needs to be taken into
account in RTP/RTCP when determine packet sizes both for generating
right sized RTP that don't violate MTU and that they are included in th= e
RTCP avg_rtcp_size parameter part of the scheduling algorithm.

9. Section 1.2.2: For confirmation:

=A0 =A0 Packet Counter =A0 =A0 Each AEAD instantiation MUST maintain a 6 o= ctet
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0zero-based packet counter w= hich is incremented
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0each time an SRTP packet is= sent. =A0As we shall
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0see below, the packet count= er is used to insure
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0each SRTP packet gets a uni= que initialization
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vector.

Can this use the "ROC" distribution mechanism (RFC4771) or what t= he
key-management provide to correctly deduce the field, or will it have
problems with late joiners in a group communication?

10. Section 1.2.2 Packet Counter:

"zero-based packet counter" Does this mean that the 6 octet long = field
is initialized to 0 and thus violate the recommendation of RTP sequence
number requirement of random start position.

11. Section 1.5: I don't like using the figure to indicate what is of different types. Two reasons. The first is that it doesn't explicitly enumerate protocol fields, instead 32-bytes octet with fields. Secondly
because it make it hard for someone that can't see to correctly
interpret this. Think if Sam Hartman would like to read this spec. You
made it much more difficult for him. You had a description earlier that
with a bit more precision would be correct, after having dealt with
comment 6 and what needs to be included due to that.

12. Section 1.6. AEAD Processing of SRTCP Packets

=A0 All SRTCP packets MUST be authenticated, but unlike SRTP, SRTCP
=A0 packet encryption is optional. =A0A sender can select which packets to=
=A0 encrypt, and indicates this choice with a 1-bit encryption flag
=A0 (located in the leftmost bit of the 32-bit word that contains the
=A0 SRTCP index)

I think it is important to write "SRTCP packet" as SRTCP compount=
packet. As each individual RTCP packet can't be individually encrypted<= br> or not in the same compound packet.

13. Section 1.6.1 and 1.6.2. Same as comment 11 on this section. Here
you may have to talk about octets as it is defined as the first of
32-bit words of the first RTCP packet part of the compound that are
unencrypted.

14. Section 1.8. Prevention of IV Reuse

=A0 For a given key it is critical that the IV not repeat. =A0This reduces=
=A0 to the problem of insuring neither the Packet Counter nor the SRTCP =A0 index do not repeat before the AEAD instantiation is rekeyed.

=A0 Processing MUST cease if either the 48-bit Packet Counter or the
=A0 31-bit SRTCP index cycles back to their initial value. =A0Processing =A0 MUST NOT resume until a new SRTP/SRTCP session has been established =A0 using a new shared secret master key and shares master salt.
=A0 Ideally, a rekey should be done well before either of these counters =A0 cycle.

This section fails to discuss another issue where IV reuse could arise.
Namely SSRC collision. If more than a single end-point uses the same
SSRC there can be collision. This either put stringent requirements on
how one key this crypto transform in different topologies or the usage
of SSRC assignment rules. As the later is not really present it might be worth defining rules and be clear on the impact of an SSRC collision.

15. Section 2.1:
C_MAX =A0 =A0 =A0maximum ciphertext =A0 =A0 =A0 MUST be at most 2^16-40 oct= ets
=A0 =A0 =A0 =A0 =A0 length per invocation =A0 =A0SHOULD be at least 2232
I think the lower bound reasonsing is flawed. First of all there is RTCP that has only IPv4/UDP + 2 32-bits word of none plaintext RTCP headers
thus making it 38 bytes. In addition what about IP Jumbogram (RFC 2675)
which support packet sizes of 2^32 bytes.

I think the max should be set to what the upper limit where something
breaks. Is 2^32 a working limit from crypto perspective, in that case I
think you should use that.

16. Minimal value for C_MAX
=A0 Similarly the lower bound on C_MAX is based on the maximum
=A0 transmission unit (MTU) of 2272 octets in IEEE 802.11. =A0Because many=
=A0 RTP applications use very short payloads (for example, the G.729
=A0 codec used in VoIP can be as short as 20 octets), implementations
=A0 that only support a maximum ciphertext length smaller than 2232
=A0 octets are permitted under this RFC. =A0However, in the interest of =A0 maximizing interoperability between various AEAD implementations, the<= br> =A0 use of C_MAX values less than 2232 is discouraged.

I actually think the minimum value should be that a C_MAX value of 2234
MUST be supported. My reasoning is that it must be 2 bytes larger to
support full MTU RTCP. Then it really should be a MUST to ensure that
one knows that a counter part can support that size of plaintext. I
would like to point out that the current key-management systems aren't<= br> the greatest for negotiating a lot of sub-parameters. For example my
understanding is that DTLS-SRTP only support negoptiating whole
profiles, not sub-parameters at all.

So if you are not specifying a hard limit what packet size a receiver
must support how do you know that you can interoperate?

At the same time I realize that this is not optimal for a very
constrained device that sends encrypted real-time payloads of some type
that are much smaller and actually don't have the buffering space for s= o
large packets.

Maybe the way forward is to separate the C_max value boundary and the
minimal value supported for the defiended profiles and make it clear
that the protection profiles defined in 2.2 and 2.3 actually requires a
C_max that is 2234.


17. Section 2.1:

For sake of clarity we specify two additional parameters:

=A0 =A0 =A0Authentication Tag Length =A0 =A0 =A0 =A0 MUST be either 8, 12,= or 16
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 octets
=A0 =A0 =A0Maximum number of invocations =A0 =A0 MUST be at most 2^48 for = SRTP
=A0 =A0 =A0 =A0 for a given instantiation =A0 =A0 =A0MUST be at most 2^31 = for SRTCP

As these parameters are for AEAD algorithms in general, how can you be
certain that no one likes an authentication tag length longer than 16
bytes or for that matter one that is 14 bytes?

I guess the maximum number of invocations also comes from an assumption
around the IV construction. Which I am not certain holds as you clearly
defined the IV specifically for the algorithms and other AEAD algorithms can make a different choice for IV including an explicit one, can't
they? Thus does these max values really hold?

18. Section 2.2
In addition to the Packet Counter used in the formation of IVs, each
=A0 instantiation of AES-GCM has a block counter which is incremented
=A0 each time AES is called to produce a 16-octet output block.

I would prefer that you where more explicit about the lenght of the
block counters length, i.e =A0... AES-GCM has a block counter (32-bit)
which ...

This also applies to the corresponding text in 2.3.

19. Section 2.3:
For AES-CCM in SRTP/SRTCP, the
=A0 flag octet has the hex value 5A if an 8-octet authentication tag is =A0 used, 6A if a 12-octet authentication tag is used, and 7A if a
=A0 16-octet authentication tag is used. =A0The flag octet is one of the =A0 inputs to AES during the counter mode encryption of the plaintext.

Considering that the table only defines the modes that has 16-octet auth tags, whats the point of mentioning the other lengths?

20. Section 4:

RFC 4568 defines SRTP "crypto suites"

I would prefer that one instead of just using the "RFC 4568" as h= andle
to the specification instead included the title or an abbreviated one at least. Like this:

Security Descriptions [RFC4586] defines SRTP "crypto suites"

This I think is much more clear as I don't have to go to the reference<= br> section if I don't directly remember what the RFC number is.

21. Section 4:

RFC 4568 defines SRTP "crypto suites"; a crypto suite corresponds= to
=A0 a particular AEAD algorithm in SRTP. =A0In order to allow SDP to signa= l
=A0 the use of the algorithms defined in this document, IANA will
=A0 register the following crypto suites into the subregistry for SRTP
=A0 crypto suites under the SRTP transport of the SDP Security
=A0 Descriptions:

=A0 =A0 =A0srtp-crypto-suite-ext =3D "AEAD_AES_128_GCM" =A0 =A0/=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"AEAD_AES_= 256_GCM" =A0 =A0/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"AEAD_AES_= 128_GCM_8" =A0/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"AEAD_AES_= 256_GCM_8" =A0/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"AEAD_AES_= 128_GCM_12" /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"AEAD_AES_= 256_GCM_12" /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"AEAD_AES_= 128_CCM" =A0 =A0/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"AEAD_AES_= 256_CCM" =A0 =A0/

Igoe and McGrew =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Informational =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0[Page 15]
Internet Draft =A0 =A0 =A0 =A0 AES-GCM and AES-CCM for SRTP =A0 =A0 =A0 =A0= Feb 17, 2012

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0srtp-crypto-sui= te-ext

I don't think this fulfills the registration requirement in that it
hasn't made it clear how the key-salt structure for inline method are constructed. How many bits of keys, and how many bits of salt is to be
included in the structure.

22. Section 4:

When it comes to DTLS-SRTP the protection profiles defined in RFC 5764
has the following information defined in its section 4.1.2
SRTP_AES128_CM_HMAC_SHA1_80
=A0 =A0 =A0 =A0 cipher: AES_128_CM
=A0 =A0 =A0 =A0 cipher_key_length: 128
=A0 =A0 =A0 =A0 cipher_salt_length: 112
=A0 =A0 =A0 =A0 maximum_lifetime: 2^31
=A0 =A0 =A0 =A0 auth_function: HMAC-SHA1
=A0 =A0 =A0 =A0 auth_key_length: 160
=A0 =A0 =A0 =A0 auth_tag_length: 80

I believe this information is present, but maybe it should be collected
together. It also doesn't define how the AEAD parameters defined in thi= s
specification actually are parameterized when needed.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F?r?gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------



------------------------------

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt


End of avt Digest, Vol 97, Issue 11
***********************************

--f46d042f9d3cfa4a3b04c2557ae2-- From hans.stokking@tno.nl Wed Jun 13 02:07:40 2012 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 73FAF21F857D for ; Wed, 13 Jun 2012 02:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] 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 Hz6BsaR-ZInb for ; Wed, 13 Jun 2012 02:07:35 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4053321F854C for ; Wed, 13 Jun 2012 02:07:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,762,1330902000"; d="scan'208,217";a="15480934" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 13 Jun 2012 11:07:30 +0200 Received: from EXC-MBX01.tsn.tno.nl ([169.254.1.223]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.02.0283.003; Wed, 13 Jun 2012 11:07:30 +0200 From: "Stokking, H.M. (Hans)" To: Roni Even , "avt@ietf.org" Thread-Topic: [AVTCORE] comments on draft-ietf-avtcore-idms-04 Thread-Index: Ac06AF5PKfMfCU49TDCoStzqXbfshALSOi3gAGOTC8AAmvkAcA== Date: Wed, 13 Jun 2012 09:07:29 +0000 Message-ID: <7F110B3ECC623C4EADDEB82154F2693D07669850@EXC-MBX01.tsn.tno.nl> References: <4fbebd05.8854b40a.6284.ffff9d1e@mx.google.com> <4fd44985.8854b40a.4557.0d03@mx.google.com> In-Reply-To: <4fd44985.8854b40a.4557.0d03@mx.google.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: multipart/alternative; boundary="_000_7F110B3ECC623C4EADDEB82154F2693D07669850EXCMBX01tsntnon_" MIME-Version: 1.0 Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-idms-04 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: Wed, 13 Jun 2012 09:07:40 -0000 --_000_7F110B3ECC623C4EADDEB82154F2693D07669850EXCMBX01tsntnon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, I've come up with new text for section 11, including a description on usage= of SDP parameters. This should deal with your original comments 4, 5 and 6= . Basic idea here is: please use the RTCP IDMS report preferably, but pleas= e also be compatible with the TISPAN approach. Please let us know if you agree with the text, we will then upload a new ve= rsion of the draft (including the more minor changes as indicated by Ray ea= rlier in response to your comments). Hans 11 SDP parameters usage and compatibility with TISPAN The SDP usage for IDMS follows the rules defined in RFC3611 in section 5 on= SDP signalling, with the exception of what is stated here. The IDMS usage = of RTCP is a (loosely coupled) collaborative parameter, in the sense that r= eceivers sent their status information and in response (asynchronously) the= MSAS sents synchronization instructions. Both the sync-group parameter (de= fined by ETSI TISPAN) and the rtcp-idms parameter (defined in this document= ) thus indicate the ability to sent and the ability to receive indicated RT= CP messages. This section defines how these SDP parameters should be used, = and thus also explains how compatibility with the TISPAN solution is arrang= ed for. As described in Section 1.4, ETSI TISPAN has described its mechanism for ID= MS in [TS183063]. One of the main differences between the TISPAN document = and this document is the fact that the TISPAN solution uses an RTCP XR bloc= k for both the SC->MSAS message and the MSAS->SC message (by selecting SPST= -type 2), while this document specifies a new RTCP Packet Type for the MSAS= ->SC message. The message from MSAS to SC is not in any way a report on ho= w a receiver sees a session, and therefore a separate RTCP packet type is m= ore appropriate than the XR block solution chosen in ETSI TISPAN. To achiev= e compatibility, MSAS implementations SHOULD implement both the TISPAN RTCP= block and the new RTCP IDMS report for MSAS->SC messages. SCs MAY implemen= t support for both types of messages. For the MSAS->SC signaling, it is rec= ommended to use the RTCP IDMS report defined in this document. The TISPAN = RTCP XR block with SPST=3D2 MAY be used for purposes of compatibility with = the TISPAN solution, but MUST NOT be used if all nodes involved support the= new RTCP IDMS report. Most of the times, the IDMS SDP parameters will be used in the offer/answer= context. Receivers will indicate in their SDP which RTCP messages they sup= port. For a unicast situation, three situations are possible in offer/answer cont= ext: - If a receiver indicates at least the rtcp-idms SDP parameter, the MSAS SH= OULD reply with only the rtcp-idms parameter and use only the RTCP IDMS rep= ort for MSAS->SC communication. - If a receiver indicates only the sync-group SDP parameter, and the MSAS a= lso supports this, it SHOULD reply with only the sync-group parameter and u= se only the RTCP XR block with SPST=3D2 for MSAS->SC communication. - If a receiver indicates only the sync-group SDP parameter, and the MSAS d= oes not support this, the media sender MUST ignore the parameter. This rece= iver will not become part of the synchronization session. Note that it is possible that for a certain synchronization group, that the= MSAS sends RTCP IDMS packets to one receiver and RTCP XR IDMS blocks with = SPST=3D2 to another receiver. In a multicast situation using the offer/answer context, it will work a bit= differently. The negotiation is the same as in the unicast situation. But,= the MSAS will multicast all RTCP messages to all receivers. So: - If all receivers support the RTCP IDMS report, the MSAS SHOULD only sent = the RTCP IDMS report for MSAS->SC messages. - If not all receivers support the RTCP IDMS report, but all receivers supp= ort the TISPAN solution, the MSAS SHOULD only sent the RTCP XR block with S= PST=3D2 for MSAS->SC messages. - If some receivers support only the RTCP IDMS report and other receivers s= upport only the TISPAN solution, the MSAS SHOULD sent both the RTCP IDMS re= port and the RTCP XR block with SPST=3D2 for MSAS->SC messages. This is les= s efficient, since the information sent is duplicated, but this is the only= way to include all receivers in a synchronization session in this scenario= . In certain multicast situations, there is no offer/answer context. In that = case, the MSAS SHOULD use only the RTCP IDMS packet type and thus use only = the SDP parameter rtcp-idms. Receivers that do not support the RTCP IDMS pa= cket will just ignore both the SDP parameter and the RTCP IDMS packets, and= will thus not join the synchronization session. For compatability with the= TISPAN solution, the MSAS MAY choose to use the RTCP XR IDMS block type in= stead, using the SDP parameter sync-group. The media sender SHOULD NOT use = both parameters at the same time in this case of no offer/answer context. From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni = Even Sent: zondag 10 juni 2012 9:13 To: Brandenburg, R. (Ray) van; avt@ietf.org Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-idms-04 Hi Ray, Thanks for the response. I only have a suggestion on the first comment. 1. In section 6 you have the sentence "If the RTCP Packet Sender is an= SC (SPST=3D1) or an MSAS (SPST=3D2)" but above the value 2 is not defined = for this document. Do you expect systems that support this document to also= support the ETSI XR report from the MSAS? RvB: The idea is that this document defines SPST 1 and 2, while the ETSI do= cument provides some optional extensions (e.g. SPST 3 and 4). Roni: I had this comment since I was not sure from this section what is the= use for SPST=3D2. Maybe you can point here to section 11 where you explain= it or the new section if it will address this. As a Chair: After you submit an update I can start a WGLC Roni From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] Sent: Friday, June 08, 2012 10:44 AM To: Roni Even; avt@ietf.org Subject: RE: [AVTCORE] comments on draft-ietf-avtcore-idms-04 Hi Roni, Thanks for your valuable review. Comments inline. We will upload a new vers= ion somewhere next week. Ray From: avt-bounces@ietf.org [mailto:avt-bounces= @ietf.org] On Behalf Of Roni Even Sent: vrijdag 25 mei 2012 0:56 To: avt@ietf.org Subject: [AVTCORE] comments on draft-ietf-avtcore-idms-04 Hi, I reviewed the draft and have some comments 2. In section 6 you have the sentence "If the RTCP Packet Sender is an= SC (SPST=3D1) or an MSAS (SPST=3D2)" but above the value 2 is not defined = for this document. Do you expect systems that support this document to also= support the ETSI XR report from the MSAS? RvB: The idea is that this document defines SPST 1 and 2, while the ETSI do= cument provides some optional extensions (e.g. SPST 3 and 4). 3. In section 6 when defining Packet Presented NTP timestamp it says "= This timestamp reflects the wall clock time at the moment the data containe= d in the first octet of the associated RTP packet is presented to the user= " I am not sure how to know this since the displayed information is not th= e RTP information but the decoded information so it is not clear what is th= e first byte. I think that maybe it will good to state in the definition he= re and in the packet received that it is the first byte of the first packet= in the frame or the first byte in the rendered frame. I think that in sect= ion 7 you have a better definition. RvB: Your right, I will change the definition to reflect that. 4. About the SDP parameters in section 9 and 10. Are these negotiated = between the MCs and the MSAS or just announced by the MSAS. It will be goo= d to clarify the usage RvB: We will add a section to describe how the SDP parameters can be used. = In summary: in most cases the SDP parameters are negotiated. However, in so= me cases (e.g. IPTV Multicast scenarios), they might be announced by the MS= AS. 5. I understand that you list the two SDP parameter but the SC need on= e of them depending if it supports the ETSI version or this one. Based on t= he previous question response it will be good to list the proposed SDP sent= from the MSAS. RvB: We will add a section with some recommendations on how the MSAS should= deal with the different SDP parameters. 6. I am also not sure how the MSAS will know if to send the RTCP mess= age or the RTCP-XR message. It is mentioned in section 11 what it should do= but not how the MSAS know which one to send. RvB: This will be covered by the section proposed under 4) 7. In section 13 it will be good to say that the security consideratio= n of RFC 3611 apply here also. RvB: I agree, I will add it. 8. The IANA section is not clear explain one by one what to do with th= e four entities. As for the ETSI ones (the RTCP-XR and SFP) do you want to= change them or have a reference to this document, if not they are not need= ed as IANA consideration since there is no IANA action there. RvB: The idea is that we don't change the ETSI ones to maintain compatibili= ty. I will clarify this section to reflect that. 9. You can remove section 16. RvB: Ok. Roni Even as Individual This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_7F110B3ECC623C4EADDEB82154F2693D07669850EXCMBX01tsntnon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Roni,
 
I’ve come up with new text for section 1= 1, including a description on usage of SDP parameters. This should deal wit= h your original comments 4, 5 and 6. Basic idea here is: please use the RTC= P IDMS report preferably, but please also be compatible with the TISPAN approach.
 
Please let us know if you agree with the text,= we will then upload a new version of the draft (including the more minor c= hanges as indicated by Ray earlier in response to your comments).
 
Hans
 
1= 1 SDP parameters usage and compatibility with TISPAN
&= nbsp;
T= he SDP usage for IDMS follows the rules defined in RFC3611 in section 5 on = SDP signalling, with the exception of what is stated here. The IDMS usage o= f RTCP is a (loosely coupled) collaborative parameter, in the sense that receivers sent their status information and in= response (asynchronously) the MSAS sents synchronization instructions. Bot= h the sync-group parameter (defined by ETSI TISPAN) and the rtcp-idms param= eter (defined in this document) thus indicate the ability to sent and the ability to receive indicated RTCP= messages. This section defines how these SDP parameters should be used, an= d thus also explains how compatibility with the TISPAN solution is arranged= for.
&= nbsp;
A= s described in Section 1.4, ETSI TISPAN has described its mechanism for IDM= S in [TS183063].  One of the main differences between the TISPAN docum= ent and this document is the fact that the TISPAN solution uses an RTCP XR block for both the SC->MSAS message and = the MSAS->SC message (by selecting SPST-type 2), while this document spe= cifies a new RTCP Packet Type for the MSAS->SC message.  The messag= e from MSAS to SC is not in any way a report on how a receiver sees a session, and therefore a separate RTCP packet type is= more appropriate than the XR block solution chosen in ETSI TISPAN. To achi= eve compatibility, MSAS implementations SHOULD implement both the TISPAN RT= CP block and the new RTCP IDMS report for MSAS->SC messages. SCs MAY implement support for both types of messa= ges. For the MSAS->SC signaling, it is recommended to use the RTCP IDMS = report defined in this document.  The TISPAN RTCP XR block with SPST= =3D2 MAY be used for purposes of compatibility with the TISPAN solution, but MUST NOT be used if all nodes involved suppor= t the new RTCP IDMS report.
&= nbsp;
M= ost of the times, the IDMS SDP parameters will be used in the offer/answer = context. Receivers will indicate in their SDP which RTCP messages they supp= ort.
&= nbsp;
F= or a unicast situation, three situations are possible in offer/answer conte= xt:
-= If a receiver indicates at least the rtcp-idms SDP parameter, the MSAS SHO= ULD reply with only the rtcp-idms parameter and use only the RTCP IDMS repo= rt for MSAS->SC communication.
-= If a receiver indicates only the sync-group SDP parameter, and the MSAS al= so supports this, it SHOULD reply with only the sync-group parameter and us= e only the RTCP XR block with SPST=3D2 for MSAS->SC communication.
-= If a receiver indicates only the sync-group SDP parameter, and the MSAS do= es not support this, the media sender MUST ignore the parameter. This recei= ver will not become part of the synchronization session.
&= nbsp;
N= ote that it is possible that for a certain synchronization group, that the = MSAS sends RTCP IDMS packets to one receiver and RTCP XR IDMS blocks with S= PST=3D2 to another receiver.
&= nbsp;
I= n a multicast situation using the offer/answer context, it will work a bit = differently. The negotiation is the same as in the unicast situation. But, = the MSAS will multicast all RTCP messages to all receivers. So:
-= If all receivers support the RTCP IDMS report, the MSAS SHOULD only sent t= he RTCP IDMS report for MSAS->SC messages.
-= If not all receivers support the RTCP IDMS report, but all receivers suppo= rt the TISPAN solution, the MSAS SHOULD only sent the RTCP XR block with SP= ST=3D2 for MSAS->SC messages.
-= If some receivers support only the RTCP IDMS report and other receivers su= pport only the TISPAN solution, the MSAS SHOULD sent both the RTCP IDMS rep= ort and the RTCP XR block with SPST=3D2 for MSAS->SC messages. This is less efficient, since the information sen= t is duplicated, but this is the only way to include all receivers in a syn= chronization session in this scenario.
&= nbsp;
In certain multicast situations, there is no offer/answer context. In = that case, the MSAS SHOULD use only the RTCP IDMS packet type and thus use = only the SDP parameter rtcp-idms. Receivers that do not support the RTCP ID= MS packet will just ignore both the SDP parameter and the RTCP IDMS packets, and will thus not join the syn= chronization session. For compatability with the TISPAN solution, the MSAS = MAY choose to use the RTCP XR IDMS block type instead, using the SDP parame= ter sync-group. The media sender SHOULD NOT use both parameters at the same time in this case of no offer/an= swer context.
 
Fr= om: avt-bounces@ietf.org [mailt= o:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: zondag 10 juni 2012 9:13
To: Brandenburg, R. (Ray) van; avt@ietf.org
Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-idms-04=
 
Hi Ray,
Thanks for the response. I only have a suggest= ion on the first comment.
 
  1. In section 6 you have the sentence "If the RTCP Packet Sender is a= n SC (SPST=3D1) or an MSAS (SPST=3D2)" but above the value 2 is not de= fined for this document. Do you expect systems that support this document t= o also support the ETSI XR report from the MSAS?
RvB: The idea is that this document defines SP= ST 1 and 2, while the ETSI document provides some optional extensions (e.g.= SPST 3 and 4).  
Roni: I had this comment since I was not sure = from this section what is the use for SPST=3D2. Maybe you can point here to= section 11 where you explain it or the new section if it will address this= .
 
 
As a Chair: After you submit an update I can s= tart a WGLC
Roni
 
Fr= om: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl]=
Sent: Friday, June 08, 2012 10:44 AM
To: Roni Even; = avt@ietf.org
Subject: RE: [AVTCORE] comments on draft-ietf-avtcore-idms-04=
 
Hi Roni,
 
Thanks for your valuable review. Comments inli= ne. We will upload a new version somewhere next week.
 
Ray
 
Fr= om: avt= -bounces@ietf.org [<= font color=3D"blue">mailto:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: vrijdag 25 mei 2012 0:56
To: avt@ietf= .org
Subject: [AVTCORE] comments on draft-ietf-avtcore-idms-04
 
Hi,
I reviewed the draft and have some comments
 
  1. In section 6 you have the sentence "If the RTCP Packet Sender is a= n SC (SPST=3D1) or an MSAS (SPST=3D2)" but above the value 2 is not de= fined for this document. Do you expect systems that support this document t= o also support the ETSI XR report from the MSAS?
RvB: The idea is that this document defines SP= ST 1 and 2, while the ETSI document provides some optional extensions (e.g.= SPST 3 and 4).
  1. In section 6 when defining Packet Presented NTP timestamp it says "= ;This timestamp reflects the wall clock time at the moment the data contain= ed in the first octet  of the associated RTP packet is presented to th= e user " I am not sure how to know this since the displayed information is not the RTP information but the decoded inform= ation so it is not clear what is the first byte. I think that maybe it will= good to state in the definition here and in the packet received that it is= the first byte of the first packet in the frame or the first byte in the rendered frame. I think that in secti= on 7 you have a better definition.
RvB: Your right, I will change the definition = to reflect that.
  1. About the SDP parameters in section 9 and 10. Are these negotiated betw= een the MCs and the MSAS or just announced by the MSAS.  It will be go= od to clarify the usage
RvB: We will add a section to describe how the= SDP parameters can be used. In summary: in most cases the SDP parameters a= re negotiated. However, in some cases (e.g. IPTV Multicast scenarios), they= might be announced by the MSAS.
  1. I understand that you list the two SDP parameter but the SC need one of= them depending if it supports the ETSI version or this one. Based on the p= revious question response it will be good to list the proposed SDP sent fro= m the MSAS.
RvB: We will add a section with some recommend= ations on how the MSAS should deal with the different SDP parameters.
  1.  I am also not sure how the MSAS will know if to send the RTCP mes= sage or the RTCP-XR message. It is mentioned in section 11 what it should d= o but not how the MSAS know which one to send.
RvB: This will be covered by the section propo= sed under 4)
  1. In section 13 it will be good to say that the security consideration of= RFC 3611 apply here also.
RvB: I agree, I will add it.
  1. The IANA section is not clear explain one by one what to do with the fo= ur entities. As for the ETSI  ones (the RTCP-XR and SFP) do you want t= o change them or have a reference to this document, if not they are not nee= ded as IANA consideration since there is no IANA action there.
RvB: The idea is that we don’t change th= e ETSI ones to maintain compatibility. I will clarify this section to refle= ct that.
  1. You can remove section 16.
RvB: Ok.
 
Roni Even as Individual
 
 
 
This e-mail and its content= s are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer<= /a>
 
 --_000_7F110B3ECC623C4EADDEB82154F2693D07669850EXCMBX01tsntnon_-- From ron.even.tlv@gmail.com Wed Jun 13 05:38:13 2012 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 7383D21F8629 for ; Wed, 13 Jun 2012 05:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.389 X-Spam-Level: X-Spam-Status: No, score=0.389 tagged_above=-999 required=5 tests=[AWL=-3.989, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 xZCwbB9QpSBH for ; Wed, 13 Jun 2012 05:38:08 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 457DD21F8628 for ; Wed, 13 Jun 2012 05:38:07 -0700 (PDT) Received: by lagv3 with SMTP id v3so428241lag.31 for ; Wed, 13 Jun 2012 05:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=8zbSPYXutc816AwE60gWvQPz29zZ1iN5D8PS3TEix+A=; b=Kwzkk02r2ZjnuC44JqWG2pxJw+uGQIlpI9NsG3+mjhwqUDuzpd2x3Fo7At/QYH6y/Q tnuEk+GaXjhcmKcjcDo5btx6gCBsbmlVkAKfbq7iKVKa26v+mVmZkRER6K0Re4LvX0zC v/Ubej1wNLHZDrXbyYQ2I4wqk9SH9i0KJqhfY0qeelMewCU5PN9Ljq9valEyY2Jdq/rY 3Ge3LlXJ6uy2x1GjM2v+nju003xjSF3dUa90q+BkufBaGjI/8HD7wi3ph6chuQPbR/Dj SnL5o3j8zsV43rSV7U0PzqxRwbqVTyIUElKNU1rX45J6RpylzwMlRD4812Y7/eDxl5bJ 6Xsg== Received: by 10.152.147.33 with SMTP id th1mr24724213lab.9.1339591085933; Wed, 13 Jun 2012 05:38:05 -0700 (PDT) Received: from windows8d787f9 (18.225.181.62.in-addr.dgcsystems.net. [62.181.225.18]) by mx.google.com with ESMTPS id hz16sm2325165lab.6.2012.06.13.05.38.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jun 2012 05:38:04 -0700 (PDT) From: "Roni Even" To: "'Stokking, H.M. \(Hans\)'" , References: <4fbebd05.8854b40a.6284.ffff9d1e@mx.google.com> <4fd44985.8854b40a.4557.0d03@mx.google.com> <7F110B3ECC623C4EADDEB82154F2693D07669850@EXC-MBX01.tsn.tno.nl> In-Reply-To: <7F110B3ECC623C4EADDEB82154F2693D07669850@EXC-MBX01.tsn.tno.nl> Date: Wed, 13 Jun 2012 15:35:23 +0300 Message-ID: <4fd889ac.706e980a.0841.1768@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01CD497A.26E1C360" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac06AF5PKfMfCU49TDCoStzqXbfshALSOi3gAGOTC8AAmvkAcAAHWlBA Content-Language: en-us Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-idms-04 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: Wed, 13 Jun 2012 12:38:13 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0033_01CD497A.26E1C360 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Hans, Please upload a new version and I will start a last call. Roni From: Stokking, H.M. (Hans) [mailto:hans.stokking@tno.nl] Sent: Wednesday, June 13, 2012 12:07 PM To: Roni Even; avt@ietf.org Subject: RE: [AVTCORE] comments on draft-ietf-avtcore-idms-04 Hi Roni, I've come up with new text for section 11, including a description on usage of SDP parameters. This should deal with your original comments 4, 5 and 6. Basic idea here is: please use the RTCP IDMS report preferably, but please also be compatible with the TISPAN approach. Please let us know if you agree with the text, we will then upload a new version of the draft (including the more minor changes as indicated by Ray earlier in response to your comments). Hans 11 SDP parameters usage and compatibility with TISPAN The SDP usage for IDMS follows the rules defined in RFC3611 in section 5 on SDP signalling, with the exception of what is stated here. The IDMS usage of RTCP is a (loosely coupled) collaborative parameter, in the sense that receivers sent their status information and in response (asynchronously) the MSAS sents synchronization instructions. Both the sync-group parameter (defined by ETSI TISPAN) and the rtcp-idms parameter (defined in this document) thus indicate the ability to sent and the ability to receive indicated RTCP messages. This section defines how these SDP parameters should be used, and thus also explains how compatibility with the TISPAN solution is arranged for. As described in Section 1.4, ETSI TISPAN has described its mechanism for IDMS in [TS183063]. One of the main differences between the TISPAN document and this document is the fact that the TISPAN solution uses an RTCP XR block for both the SC->MSAS message and the MSAS->SC message (by selecting SPST-type 2), while this document specifies a new RTCP Packet Type for the MSAS->SC message. The message from MSAS to SC is not in any way a report on how a receiver sees a session, and therefore a separate RTCP packet type is more appropriate than the XR block solution chosen in ETSI TISPAN. To achieve compatibility, MSAS implementations SHOULD implement both the TISPAN RTCP block and the new RTCP IDMS report for MSAS->SC messages. SCs MAY implement support for both types of messages. For the MSAS->SC signaling, it is recommended to use the RTCP IDMS report defined in this document. The TISPAN RTCP XR block with SPST=2 MAY be used for purposes of compatibility with the TISPAN solution, but MUST NOT be used if all nodes involved support the new RTCP IDMS report. Most of the times, the IDMS SDP parameters will be used in the offer/answer context. Receivers will indicate in their SDP which RTCP messages they support. For a unicast situation, three situations are possible in offer/answer context: - If a receiver indicates at least the rtcp-idms SDP parameter, the MSAS SHOULD reply with only the rtcp-idms parameter and use only the RTCP IDMS report for MSAS->SC communication. - If a receiver indicates only the sync-group SDP parameter, and the MSAS also supports this, it SHOULD reply with only the sync-group parameter and use only the RTCP XR block with SPST=2 for MSAS->SC communication. - If a receiver indicates only the sync-group SDP parameter, and the MSAS does not support this, the media sender MUST ignore the parameter. This receiver will not become part of the synchronization session. Note that it is possible that for a certain synchronization group, that the MSAS sends RTCP IDMS packets to one receiver and RTCP XR IDMS blocks with SPST=2 to another receiver. In a multicast situation using the offer/answer context, it will work a bit differently. The negotiation is the same as in the unicast situation. But, the MSAS will multicast all RTCP messages to all receivers. So: - If all receivers support the RTCP IDMS report, the MSAS SHOULD only sent the RTCP IDMS report for MSAS->SC messages. - If not all receivers support the RTCP IDMS report, but all receivers support the TISPAN solution, the MSAS SHOULD only sent the RTCP XR block with SPST=2 for MSAS->SC messages. - If some receivers support only the RTCP IDMS report and other receivers support only the TISPAN solution, the MSAS SHOULD sent both the RTCP IDMS report and the RTCP XR block with SPST=2 for MSAS->SC messages. This is less efficient, since the information sent is duplicated, but this is the only way to include all receivers in a synchronization session in this scenario. In certain multicast situations, there is no offer/answer context. In that case, the MSAS SHOULD use only the RTCP IDMS packet type and thus use only the SDP parameter rtcp-idms. Receivers that do not support the RTCP IDMS packet will just ignore both the SDP parameter and the RTCP IDMS packets, and will thus not join the synchronization session. For compatability with the TISPAN solution, the MSAS MAY choose to use the RTCP XR IDMS block type instead, using the SDP parameter sync-group. The media sender SHOULD NOT use both parameters at the same time in this case of no offer/answer context. From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even Sent: zondag 10 juni 2012 9:13 To: Brandenburg, R. (Ray) van; avt@ietf.org Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-idms-04 Hi Ray, Thanks for the response. I only have a suggestion on the first comment. 1. In section 6 you have the sentence "If the RTCP Packet Sender is an SC (SPST=1) or an MSAS (SPST=2)" but above the value 2 is not defined for this document. Do you expect systems that support this document to also support the ETSI XR report from the MSAS? RvB: The idea is that this document defines SPST 1 and 2, while the ETSI document provides some optional extensions (e.g. SPST 3 and 4). Roni: I had this comment since I was not sure from this section what is the use for SPST=2. Maybe you can point here to section 11 where you explain it or the new section if it will address this. As a Chair: After you submit an update I can start a WGLC Roni From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] Sent: Friday, June 08, 2012 10:44 AM To: Roni Even; avt@ietf.org Subject: RE: [AVTCORE] comments on draft-ietf-avtcore-idms-04 Hi Roni, Thanks for your valuable review. Comments inline. We will upload a new version somewhere next week. Ray From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even Sent: vrijdag 25 mei 2012 0:56 To: avt@ietf.org Subject: [AVTCORE] comments on draft-ietf-avtcore-idms-04 Hi, I reviewed the draft and have some comments 2. In section 6 you have the sentence "If the RTCP Packet Sender is an SC (SPST=1) or an MSAS (SPST=2)" but above the value 2 is not defined for this document. Do you expect systems that support this document to also support the ETSI XR report from the MSAS? RvB: The idea is that this document defines SPST 1 and 2, while the ETSI document provides some optional extensions (e.g. SPST 3 and 4). 3. In section 6 when defining Packet Presented NTP timestamp it says "This timestamp reflects the wall clock time at the moment the data contained in the first octet of the associated RTP packet is presented to the user " I am not sure how to know this since the displayed information is not the RTP information but the decoded information so it is not clear what is the first byte. I think that maybe it will good to state in the definition here and in the packet received that it is the first byte of the first packet in the frame or the first byte in the rendered frame. I think that in section 7 you have a better definition. RvB: Your right, I will change the definition to reflect that. 4. About the SDP parameters in section 9 and 10. Are these negotiated between the MCs and the MSAS or just announced by the MSAS. It will be good to clarify the usage RvB: We will add a section to describe how the SDP parameters can be used. In summary: in most cases the SDP parameters are negotiated. However, in some cases (e.g. IPTV Multicast scenarios), they might be announced by the MSAS. 5. I understand that you list the two SDP parameter but the SC need one of them depending if it supports the ETSI version or this one. Based on the previous question response it will be good to list the proposed SDP sent from the MSAS. RvB: We will add a section with some recommendations on how the MSAS should deal with the different SDP parameters. 6. I am also not sure how the MSAS will know if to send the RTCP message or the RTCP-XR message. It is mentioned in section 11 what it should do but not how the MSAS know which one to send. RvB: This will be covered by the section proposed under 4) 7. In section 13 it will be good to say that the security consideration of RFC 3611 apply here also. RvB: I agree, I will add it. 8. The IANA section is not clear explain one by one what to do with the four entities. As for the ETSI ones (the RTCP-XR and SFP) do you want to change them or have a reference to this document, if not they are not needed as IANA consideration since there is no IANA action there. RvB: The idea is that we don't change the ETSI ones to maintain compatibility. I will clarify this section to reflect that. 9. You can remove section 16. RvB: Ok. Roni Even as Individual This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer ------=_NextPart_000_0033_01CD497A.26E1C360 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Hans,

Please upload a new version and I will start a last call. =

Roni

 

From:= = Stokking, H.M. (Hans) [mailto:hans.stokking@tno.nl]
Sent: = Wednesday, June 13, 2012 12:07 PM
To: Roni Even; = avt@ietf.org
Subject: RE: [AVTCORE] comments on = draft-ietf-avtcore-idms-04

 

Hi Roni,=

 =

I’ve come up with new text for section 11, including a = description on usage of SDP parameters. This should deal with your = original comments 4, 5 and 6. Basic idea here is: please use the RTCP = IDMS report preferably, but please also be compatible with the TISPAN = approach.=

 =

Please let us know if you agree with the text, we will then upload a = new version of the draft (including the more minor changes as indicated = by Ray earlier in response to your comments).=

 =

Hans=

 =

11 SDP parameters usage = and compatibility with TISPAN=

 =

The SDP usage for IDMS = follows the rules defined in RFC3611 in section 5 on SDP signalling, = with the exception of what is stated here. The IDMS usage of RTCP is a = (loosely coupled) collaborative parameter, in the sense that receivers = sent their status information and in response (asynchronously) the MSAS = sents synchronization instructions. Both the sync-group parameter = (defined by ETSI TISPAN) and the rtcp-idms parameter (defined in this = document) thus indicate the ability to sent and the ability to receive = indicated RTCP messages. This section defines how these SDP parameters = should be used, and thus also explains how compatibility with the TISPAN = solution is arranged for.=

 =

As described in Section = 1.4, ETSI TISPAN has described its mechanism for IDMS in = [TS183063].  One of the main differences between the TISPAN = document and this document is the fact that the TISPAN solution uses an = RTCP XR block for both the SC->MSAS message and the MSAS->SC = message (by selecting SPST-type 2), while this document specifies a new = RTCP Packet Type for the MSAS->SC message.  The message from = MSAS to SC is not in any way a report on how a receiver sees a session, = and therefore a separate RTCP packet type is more appropriate than the = XR block solution chosen in ETSI TISPAN. To achieve compatibility, MSAS = implementations SHOULD implement both the TISPAN RTCP block and the new = RTCP IDMS report for MSAS->SC messages. SCs MAY implement support for = both types of messages. For the MSAS->SC signaling, it is recommended = to use the RTCP IDMS report defined in this document.  The TISPAN = RTCP XR block with SPST=3D2 MAY be used for purposes of compatibility = with the TISPAN solution, but MUST NOT be used if all nodes involved = support the new RTCP IDMS report.=

 =

Most of the times, the = IDMS SDP parameters will be used in the offer/answer context. Receivers = will indicate in their SDP which RTCP messages they support. = =

 =

For a unicast situation, = three situations are possible in offer/answer context:=

- If a receiver = indicates at least the rtcp-idms SDP parameter, the MSAS SHOULD reply = with only the rtcp-idms parameter and use only the RTCP IDMS report for = MSAS->SC communication.=

- If a receiver = indicates only the sync-group SDP parameter, and the MSAS also supports = this, it SHOULD reply with only the sync-group parameter and use only = the RTCP XR block with SPST=3D2 for MSAS->SC = communication.=

- If a receiver = indicates only the sync-group SDP parameter, and the MSAS does not = support this, the media sender MUST ignore the parameter. This receiver = will not become part of the synchronization session.=

 =

Note that it is possible = that for a certain synchronization group, that the MSAS sends RTCP IDMS = packets to one receiver and RTCP XR IDMS blocks with SPST=3D2 to another = receiver.=

 =

In a multicast situation = using the offer/answer context, it will work a bit differently. The = negotiation is the same as in the unicast situation. But, the MSAS will = multicast all RTCP messages to all receivers. So:=

- If all receivers = support the RTCP IDMS report, the MSAS SHOULD only sent the RTCP IDMS = report for MSAS->SC messages.=

- If not all receivers = support the RTCP IDMS report, but all receivers support the TISPAN = solution, the MSAS SHOULD only sent the RTCP XR block with SPST=3D2 for = MSAS->SC messages.=

- If some receivers = support only the RTCP IDMS report and other receivers support only the = TISPAN solution, the MSAS SHOULD sent both the RTCP IDMS report and the = RTCP XR block with SPST=3D2 for MSAS->SC messages. This is less = efficient, since the information sent is duplicated, but this is the = only way to include all receivers in a synchronization session in this = scenario.=

 =

In certain = multicast situations, there is no offer/answer context. In that case, = the MSAS SHOULD use only the RTCP IDMS packet type and thus use only the = SDP parameter rtcp-idms. Receivers that do not support the RTCP IDMS = packet will just ignore both the SDP parameter and the RTCP IDMS = packets, and will thus not join the synchronization session. For = compatability with the TISPAN solution, the MSAS MAY choose to use the = RTCP XR IDMS block type instead, using the SDP parameter sync-group. The = media sender SHOULD NOT use both parameters at the same time in this = case of no offer/answer context.

 =

From:= = avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] = On Behalf Of Roni Even
Sent: zondag 10 juni 2012 = 9:13
To: Brandenburg, R. (Ray) van; avt@ietf.org
Subject: Re: = [AVTCORE] comments on draft-ietf-avtcore-idms-04=

 =

Hi Ray,=

Thanks for the response. I only have a suggestion on the first = comment.=

 =

1.       = In section = 6 you have the sentence "If the RTCP Packet Sender is an SC = (SPST=3D1) or an MSAS (SPST=3D2)" but above the value 2 is not = defined for this document. Do you expect systems that support this = document to also support the ETSI XR report from the = MSAS?

RvB: The idea is that this document defines SPST 1 and 2, while the = ETSI document provides some optional extensions (e.g. SPST 3 and 4). =  =

Roni: I had this comment since I was not sure from this section what = is the use for SPST=3D2. Maybe you can point here to section 11 where = you explain it or the new section if it will address this.=

 =

 =

As a Chair: After you submit an update I can start a WGLC=

Roni=

 =

From:= = Brandenburg, R. (Ray) van [mailto:ray.vanbranden= burg@tno.nl]
Sent: Friday, June 08, 2012 10:44 = AM
To: Roni Even; avt@ietf.org
Subject: RE: = [AVTCORE] comments on draft-ietf-avtcore-idms-04=

 =

Hi Roni,=

 =

Thanks for your valuable review. Comments inline. We will upload a = new version somewhere next week.=

 =

Ray=

 =

From:= = avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] = On Behalf Of Roni Even
Sent: vrijdag 25 mei 2012 = 0:56
To: avt@ietf.org
Subject: = [AVTCORE] comments on draft-ietf-avtcore-idms-04=

 =

Hi, =

I reviewed = the draft and have some comments

 =

2.       = In section = 6 you have the sentence "If the RTCP Packet Sender is an SC = (SPST=3D1) or an MSAS (SPST=3D2)" but above the value 2 is not = defined for this document. Do you expect systems that support this = document to also support the ETSI XR report from the = MSAS?

RvB: The idea is that this document defines SPST 1 and 2, while the = ETSI document provides some optional extensions (e.g. SPST 3 and 4). = =

3.       = In section = 6 when defining Packet Presented NTP timestamp it says "This = timestamp reflects the wall clock time at the moment the data contained = in the first octet  of the associated RTP packet is presented to = the user " I am not sure how to know this since the displayed = information is not the RTP information but the decoded information so it = is not clear what is the first byte. I think that maybe it will good to = state in the definition here and in the packet received that it is the = first byte of the first packet in the frame or the first byte in the = rendered frame. I think that in section 7 you have a better = definition.

RvB: Your right, I will change the definition to reflect that. = =

4.       = About the = SDP parameters in section 9 and 10. Are these negotiated between the MCs = and the MSAS or just announced by the MSAS.  It will be good to = clarify the usage

RvB: We will add a section to describe how the SDP parameters can be = used. In summary: in most cases the SDP parameters are negotiated. = However, in some cases (e.g. IPTV Multicast scenarios), they might be = announced by the MSAS.=

5.       = I = understand that you list the two SDP parameter but the SC need one of = them depending if it supports the ETSI version or this one. Based on the = previous question response it will be good to list the proposed SDP sent = from the MSAS.

RvB: We will add a section with some recommendations on how the MSAS = should deal with the different SDP parameters.=

6.       =  I am = also not sure how the MSAS will know if to send the RTCP message or the = RTCP-XR message. It is mentioned in section 11 what it should do but not = how the MSAS know which one to send.

RvB: This will be covered by the section proposed under = 4)=

7.       = In section = 13 it will be good to say that the security consideration of RFC 3611 = apply here also.

RvB: I agree, I will add it.=

8.       = The IANA = section is not clear explain one by one what to do with the four = entities. As for the ETSI  ones (the RTCP-XR and SFP) do you want = to change them or have a reference to this document, if not they are not = needed as IANA consideration since there is no IANA action there. =

RvB: The idea is that we don’t change the ETSI ones to maintain = compatibility. I will clarify this section to reflect that.=

9.       = You can = remove section 16.

RvB: Ok.=

 =

Roni Even = as Individual

 =

 =

 =

This = e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclai= mer=

 =

------=_NextPart_000_0033_01CD497A.26E1C360-- From internet-drafts@ietf.org Wed Jun 13 06:20:29 2012 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 5A11521F864E; Wed, 13 Jun 2012 06:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.623 X-Spam-Level: X-Spam-Status: No, score=-94.623 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, 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 3TNZ1J-a59ZK; Wed, 13 Jun 2012 06:20:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0C521F85E7; Wed, 13 Jun 2012 06:20:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120613132028.17966.95908.idtracker@ietfa.amsl.com> Date: Wed, 13 Jun 2012 06:20:28 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-05.txt 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: Wed, 13 Jun 2012 13:20:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : RTCP for inter-destination media synchronization Author(s) : Ray van Brandenburg Hans Stokking Fernando Boronat Mario Montagud Kevin Gross Filename : draft-ietf-avtcore-idms-05.txt Pages : 22 Date : 2012-06-13 Abstract: This document gives information on an RTCP Packet Type and RTCP XR Block Type including associated SDP parameters for Inter-Destination Media Synchronization (IDMS). The RTCP XR Block Type, registered with IANA based on an ETSI specification, is used to collect media play-out information from participants in a group playing-out (watching, listening, etc.) a specific RTP media stream. The RTCP packet type specified by this document is used to distribute a common target play-out point to which all the distributed receivers, sharing a media experience, can synchronize. Typical use cases in which IDMS is usefull are social TV, shared service control (i.e. applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-idms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-idms-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-idms-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From woohwankim@gmail.com Wed Jun 13 20:49:40 2012 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 1FB3311E80E9 for ; Wed, 13 Jun 2012 20:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 0untUUNrXuqz for ; Wed, 13 Jun 2012 20:49:37 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 81D5811E80A1 for ; Wed, 13 Jun 2012 20:49:37 -0700 (PDT) Received: by vcqp1 with SMTP id p1so858460vcq.31 for ; Wed, 13 Jun 2012 20:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=kmBHKVn0QqlUf8aS+ynxhFQzk3Z6KGK6LaGlCSu4HXA=; b=SkPgyH3HUhQFZ2Wv6FQUwHPWuRyyWOnu7ryWIBkcuphmwMVtUg80+C+7LYgW2+u77r VRaHYB7gzX8RP5h3ivbU/iFGyLzYGDmGdsZC7195/Y2+pVYtO0BInY3WpdFgRWXbktAc 5nxRQbBrZk6aONl9+zNFaS9+i68Fqwdq/uF6ifexgH4uEaavAyi+ZZOf6UdQFkRqV8xD E71+NFVYIplzHjObmG2MKlCYvc1wqqr1UKgm1Q+DdBEmWDDj74DENSVy7sC7bVpW763D hnD24A/qZf35VZ9Rrcf2H9EPP/vN+cKMIy9Qi8xguA1mJEayOsd/9XZdcoxo4TjLSANa hFfg== MIME-Version: 1.0 Received: by 10.52.33.140 with SMTP id r12mr110971vdi.91.1339645776799; Wed, 13 Jun 2012 20:49:36 -0700 (PDT) Received: by 10.52.95.12 with HTTP; Wed, 13 Jun 2012 20:49:36 -0700 (PDT) Date: Thu, 14 Jun 2012 12:49:36 +0900 Message-ID: From: Woo-Hwan Kim To: draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org, Felix.Wyss@inin.com, Magnus Westerlund Content-Type: multipart/alternative; boundary=20cf3079beb6a6a64e04c26696d1 X-Mailman-Approved-At: Thu, 14 Jun 2012 01:15:47 -0700 Cc: Daesung Kwon , avt@ietf.org, Je Hong Park Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00 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: Thu, 14 Jun 2012 03:49:40 -0000 --20cf3079beb6a6a64e04c26696d1 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have some more comments. For the length of MAC tag of GCM, there is a guidelines in the NIST SP document. http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf In Appendix C, constraints with 64 bit tags are suggested, which is reflecting Ferguson's comment. (It also specifies SRTP as an example which may be appropriate for short tags.) In section 3 of the draft, it is better to address the above rather than Ferguson's document. In the previous posting, I wrote on the caption of Figure 6. I also agree with Westerlund's oipinion because it is necessary to clarify the difference between GCM and CCM. > 18. Section 2.2 > In addition to the Packet Counter used in the formation of IVs, each > instantiation of AES-GCM has a block counter which is incremented > each time AES is called to produce a 16-octet output block. > > I would prefer that you where more explicit about the lenght of the block > counters length, i.e ... AES-GCM has a block counter (32-bit) which ... > > This also applies to the corresponding text in 2.3. Thanks, Woo-Hwan Kim > Date: Tue, 22 May 2012 14:05:30 +0000 > From: "Wyss, Felix" > To: 'Magnus Westerlund' , > "'draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org'" > > Cc: 'IETF AVTCore WG' > Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00 > Message-ID: > > > Content-Type: text/plain; charset="iso-8859-1" > > Furthermore, the issues raised in the following document should be > addressed in section #3: > > http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf > > It basically means the modes with authentication tags smaller than 16 > octets MUST NOT be used with AES-GCM. > In light of that, I question the value of supporting a GCM based mode for > SRTP. > > Thanks, > --Felix > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > > Magnus Westerlund > > Sent: Tuesday, May 22, 2012 04:18 > > To: draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org > > Cc: IETF AVTCore WG > > Subject: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00 > > > > Hi, > > > > I got a request to progress this document towards WG last call. So while > > we chairs are cleaning up some administrative stuff, like getting a > > milestone in place. I thought the authors should get something to do and > > thus reviewed the draft. > > > > 1) Section 1.1 > > "Crypto Context For the purposes of this document a crypto context > > is the outcome of any process which results in > > authentication of each participant in the SRTP > > session and possession by each partcipant of a > > shared secret master key and a shared master > > salt." > > > > What is the definition of participant here, SSRC, endpoint, user, or > > system? Please correct the "partcipant" spelling error also. > > > > 2) Section 1.1, crypto context: " Ciper Contest" I guess should be Crypto > > Context. > > > > 3) Section 1.1. is the text for crypto context really accurate as the > > document does define protection profiles for both DTLS-SRTP and Security > > description. > > > > 4) I am missing protection profiles for MIKEY. I think they should be > > defined as MIKEY is the third key-management protocol and are used in a > > lot of cases which neither DTLS-SRTP and Security Description are > suitable > > for. > > > > 5) Section 1.1 Instantiation: > > "each participant in the SRTP/SRTCP > > session will need four instantiations of the AEAD > > algorithm; one for inbound SRTP traffic, one for > > outbound SRTP traffic source, one for inbound > > SRTCP traffic, and one for outbound SRTCP traffic > > source. " > > > > Is this really correct. This seems to be limiting the use of AEAD to > point > > to point scenarios? The other crypto transforms for SRTP are capable of > > handling group scenarios. DTLS-SRTP with EKT for example would allow each > > end-point to distribute its own master key that it will use for the SSRCs > > it sends. There are also scenarios where one use a common master key for > > all participants. > > > > 6) Section 1.2: Associated Data This is data that is to be > > authenticated > > but not encrypted. In SRTP, the associated > > data consists of the entire RTP header, > > including the list of CSRC identifiers (if > > present) and the RTP header extension (if > > present), as shown in Figure 3. > > > > Shouldn't this point to and discuss the relation to > > draft-ietf-avtcore-srtp-encrypted-header-ext-01 > > > > 7. Section 1.2: > > Associated Data This is data that is to be authenticated > > but not encrypted. In SRTP, the associated > > data consists of the entire RTP header, > > including the list of CSRC identifiers (if > > present) and the RTP header extension (if > > present), as shown in Figure 3. > > > > Plaintext Data that is to be both encrypted and > > authenticated. In SRTP this consists of > > the RTP payload, the RTP padding and the > > RTP pad count fields (if the latter two > > fields are present) as shown in Figure 3. > > The padding service provided by RTP is not > > needed by the AEAD encryption algorithm, so > > the RTP padding and RTP pad count fields > > SHOULD be omitted. > > > > Why are these paragraphs not discussing RTCP? > > > > 8. Section 1.2.1: > > (Note that this means > > that the cipher text will be longer than the plain text by precisely > > the length of the AEAD authentication tag.) > > > > This needs more extensive discussion as it needs to be taken into account > > in RTP/RTCP when determine packet sizes both for generating right sized > > RTP that don't violate MTU and that they are included in the RTCP > > avg_rtcp_size parameter part of the scheduling algorithm. > > > > 9. Section 1.2.2: For confirmation: > > > > Packet Counter Each AEAD instantiation MUST maintain a 6 octet > > zero-based packet counter which is incremented > > each time an SRTP packet is sent. As we shall > > see below, the packet counter is used to insure > > each SRTP packet gets a unique initialization > > vector. > > > > Can this use the "ROC" distribution mechanism (RFC4771) or what the key- > > management provide to correctly deduce the field, or will it have > problems > > with late joiners in a group communication? > > > > 10. Section 1.2.2 Packet Counter: > > > > "zero-based packet counter" Does this mean that the 6 octet long field is > > initialized to 0 and thus violate the recommendation of RTP sequence > > number requirement of random start position. > > > > 11. Section 1.5: I don't like using the figure to indicate what is of > > different types. Two reasons. The first is that it doesn't explicitly > > enumerate protocol fields, instead 32-bytes octet with fields. Secondly > > because it make it hard for someone that can't see to correctly interpret > > this. Think if Sam Hartman would like to read this spec. You made it much > > more difficult for him. You had a description earlier that with a bit > more > > precision would be correct, after having dealt with comment 6 and what > > needs to be included due to that. > > > > 12. Section 1.6. AEAD Processing of SRTCP Packets > > > > All SRTCP packets MUST be authenticated, but unlike SRTP, SRTCP > > packet encryption is optional. A sender can select which packets to > > encrypt, and indicates this choice with a 1-bit encryption flag > > (located in the leftmost bit of the 32-bit word that contains the > > SRTCP index) > > > > I think it is important to write "SRTCP packet" as SRTCP compount packet. > > As each individual RTCP packet can't be individually encrypted or not in > > the same compound packet. > > > > 13. Section 1.6.1 and 1.6.2. Same as comment 11 on this section. Here you > > may have to talk about octets as it is defined as the first of 32-bit > > words of the first RTCP packet part of the compound that are unencrypted. > > > > 14. Section 1.8. Prevention of IV Reuse > > > > For a given key it is critical that the IV not repeat. This reduces > > to the problem of insuring neither the Packet Counter nor the SRTCP > > index do not repeat before the AEAD instantiation is rekeyed. > > > > Processing MUST cease if either the 48-bit Packet Counter or the > > 31-bit SRTCP index cycles back to their initial value. Processing > > MUST NOT resume until a new SRTP/SRTCP session has been established > > using a new shared secret master key and shares master salt. > > Ideally, a rekey should be done well before either of these counters > > cycle. > > > > This section fails to discuss another issue where IV reuse could arise. > > Namely SSRC collision. If more than a single end-point uses the same SSRC > > there can be collision. This either put stringent requirements on how one > > key this crypto transform in different topologies or the usage of SSRC > > assignment rules. As the later is not really present it might be worth > > defining rules and be clear on the impact of an SSRC collision. > > > > 15. Section 2.1: > > C_MAX maximum ciphertext MUST be at most 2^16-40 octets > > length per invocation SHOULD be at least 2232 > > > > I think the lower bound reasonsing is flawed. First of all there is RTCP > > that has only IPv4/UDP + 2 32-bits word of none plaintext RTCP headers > > thus making it 38 bytes. In addition what about IP Jumbogram (RFC 2675) > > which support packet sizes of 2^32 bytes. > > > > I think the max should be set to what the upper limit where something > > breaks. Is 2^32 a working limit from crypto perspective, in that case I > > think you should use that. > > > > 16. Minimal value for C_MAX > > Similarly the lower bound on C_MAX is based on the maximum > > transmission unit (MTU) of 2272 octets in IEEE 802.11. Because many > > RTP applications use very short payloads (for example, the G.729 > > codec used in VoIP can be as short as 20 octets), implementations > > that only support a maximum ciphertext length smaller than 2232 > > octets are permitted under this RFC. However, in the interest of > > maximizing interoperability between various AEAD implementations, the > > use of C_MAX values less than 2232 is discouraged. > > > > I actually think the minimum value should be that a C_MAX value of 2234 > > MUST be supported. My reasoning is that it must be 2 bytes larger to > > support full MTU RTCP. Then it really should be a MUST to ensure that one > > knows that a counter part can support that size of plaintext. I would > like > > to point out that the current key-management systems aren't the greatest > > for negotiating a lot of sub-parameters. For example my understanding is > > that DTLS-SRTP only support negoptiating whole profiles, not sub- > > parameters at all. > > > > So if you are not specifying a hard limit what packet size a receiver > must > > support how do you know that you can interoperate? > > > > At the same time I realize that this is not optimal for a very > constrained > > device that sends encrypted real-time payloads of some type that are much > > smaller and actually don't have the buffering space for so large packets. > > > > Maybe the way forward is to separate the C_max value boundary and the > > minimal value supported for the defiended profiles and make it clear that > > the protection profiles defined in 2.2 and 2.3 actually requires a C_max > > that is 2234. > > > > > > 17. Section 2.1: > > > > For sake of clarity we specify two additional parameters: > > > > Authentication Tag Length MUST be either 8, 12, or 16 > > octets > > Maximum number of invocations MUST be at most 2^48 for SRTP > > for a given instantiation MUST be at most 2^31 for SRTCP > > > > As these parameters are for AEAD algorithms in general, how can you be > > certain that no one likes an authentication tag length longer than 16 > > bytes or for that matter one that is 14 bytes? > > > > I guess the maximum number of invocations also comes from an assumption > > around the IV construction. Which I am not certain holds as you clearly > > defined the IV specifically for the algorithms and other AEAD algorithms > > can make a different choice for IV including an explicit one, can't they? > > Thus does these max values really hold? > > > > 18. Section 2.2 > > In addition to the Packet Counter used in the formation of IVs, each > > instantiation of AES-GCM has a block counter which is incremented > > each time AES is called to produce a 16-octet output block. > > > > I would prefer that you where more explicit about the lenght of the block > > counters length, i.e ... AES-GCM has a block counter (32-bit) which ... > > > > This also applies to the corresponding text in 2.3. > > > > 19. Section 2.3: > > For AES-CCM in SRTP/SRTCP, the > > flag octet has the hex value 5A if an 8-octet authentication tag is > > used, 6A if a 12-octet authentication tag is used, and 7A if a > > 16-octet authentication tag is used. The flag octet is one of the > > inputs to AES during the counter mode encryption of the plaintext. > > > > Considering that the table only defines the modes that has 16-octet auth > > tags, whats the point of mentioning the other lengths? > > > > 20. Section 4: > > > > RFC 4568 defines SRTP "crypto suites" > > > > I would prefer that one instead of just using the "RFC 4568" as handle to > > the specification instead included the title or an abbreviated one at > > least. Like this: > > > > Security Descriptions [RFC4586] defines SRTP "crypto suites" > > > > This I think is much more clear as I don't have to go to the reference > > section if I don't directly remember what the RFC number is. > > > > 21. Section 4: > > > > RFC 4568 defines SRTP "crypto suites"; a crypto suite corresponds to > > a particular AEAD algorithm in SRTP. In order to allow SDP to signal > > the use of the algorithms defined in this document, IANA will > > register the following crypto suites into the subregistry for SRTP > > crypto suites under the SRTP transport of the SDP Security > > Descriptions: > > > > srtp-crypto-suite-ext = "AEAD_AES_128_GCM" / > > "AEAD_AES_256_GCM" / > > "AEAD_AES_128_GCM_8" / > > "AEAD_AES_256_GCM_8" / > > "AEAD_AES_128_GCM_12" / > > "AEAD_AES_256_GCM_12" / > > "AEAD_AES_128_CCM" / > > "AEAD_AES_256_CCM" / > > > > Igoe and McGrew Informational [Page 15] > > Internet Draft AES-GCM and AES-CCM for SRTP Feb 17, 2012 > > > > srtp-crypto-suite-ext > > > > I don't think this fulfills the registration requirement in that it > hasn't > > made it clear how the key-salt structure for inline method are > > constructed. How many bits of keys, and how many bits of salt is to be > > included in the structure. > > > > 22. Section 4: > > > > When it comes to DTLS-SRTP the protection profiles defined in RFC 5764 > has > > the following information defined in its section 4.1.2 > > SRTP_AES128_CM_HMAC_SHA1_80 > > cipher: AES_128_CM > > cipher_key_length: 128 > > cipher_salt_length: 112 > > maximum_lifetime: 2^31 > > auth_function: HMAC-SHA1 > > auth_key_length: 160 > > auth_tag_length: 80 > > > > I believe this information is present, but maybe it should be collected > > together. It also doesn't define how the AEAD parameters defined in this > > specification actually are parameterized when needed. > > > > > > Cheers > > > > Magnus Westerlund > > > --20cf3079beb6a6a64e04c26696d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I have so= me more comments.

For the length of MAC tag of GCM= , there is a guidelines in the NIST SP document.

In Appendix C, constraints with 64 bit tags are suggest= ed, which is reflecting Ferguson's comment.
(It also specifie= s SRTP as an example which may be appropriate for short tags.)

In section 3 of the draft, it is better to address the above= rather than Ferguson's document.

In the previ= ous posting, I wrote on the caption of Figure 6.
I also agree wit= h Westerlund's oipinion because it is necessary to clarify the differen= ce between GCM and CCM.

> 18. Section 2.2
> In addition to the = Packet Counter used in the formation of IVs, each
> =A0 =A0ins= tantiation of AES-GCM has a block counter which is incremented
&g= t; =A0 =A0each time AES is called to produce a 16-octet output block.
>=A0
> I would prefer that you where more explicit abo= ut the lenght of the block
> counters length, i.e =A0... AES-G= CM has a block counter (32-bit) which ...
>=A0
> = This also applies to the corresponding text in 2.3.

Thanks,

Woo-Hwan Kim

=A0
Date: Tue, 22 May 2012 14:05:30 +0000
From: "Wyss, Felix" <Fe= lix.Wyss@inin.com>
To: 'Magnus Westerlund' <magnus.westerlund@ericsson.com>,
=A0 =A0 =A0 =A0"'draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org'&q= uot;
=A0 =A0 =A0 =A0<draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org>
Cc: 'IETF AVTCore WG' <avt@ietf.= org>
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00
Message-ID:
=A0 =A0 =A0 =A0<E314A44C69CF594E89147F3BEFE3ADF943ACB678@MAI= LDB2.i3domain.inin.com>
Content-Type: text/plain; charset=3D"iso-8859-1"

Furthermore, the issues raised in the following document should be addresse= d in section #3:
http://csrc.nist.gov/groups/ST/toolk= it/BCM/documents/comments/CWC-GCM/Ferguson2.pdf

It basically means the modes with authentication tags smaller than 16 octet= s MUST NOT be used with AES-GCM.
In light of that, I question the value of supporting a GCM based mode for S= RTP.

Thanks,
--Felix

> -----Original Message-----
> From: avt-bounces@ietf.org= [mailto:avt-bounces@ietf.org] = On Behalf Of
> Magnus Westerlund
> Sent: Tuesday, May 22, 2012 04:18
> To: = draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org
> Cc: IETF AVTCore WG
> Subject: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00
>
> Hi,
>
> I got a request to progress this document towards WG last call. So whi= le
> we chairs are cleaning up some administrative stuff, like getting a > milestone in place. I thought the authors should get something to do a= nd
> thus reviewed the draft.
>
> 1) Section 1.1
> "Crypto Context =A0For the purposes of this document a crypto con= text
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 is the outcome of any proc= ess which results in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 authentication of each par= ticipant in the SRTP
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 session and possession by = each partcipant of a
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 shared secret master key a= nd a shared master
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 salt."
>
> What is the definition of participant here, SSRC, endpoint, user, or > system? Please correct the "partcipant" spelling error also.=
>
> 2) Section 1.1, crypto context: " Ciper Contest" I guess sho= uld be Crypto
> Context.
>
> 3) Section 1.1. is the text for crypto context really accurate as the<= br> > document does define protection profiles for both DTLS-SRTP and Securi= ty
> description.
>
> 4) I am missing protection profiles for MIKEY. I think they should be<= br> > defined as MIKEY is the third key-management protocol and are used in = a
> lot of cases which neither DTLS-SRTP and Security Description are suit= able
> for.
>
> 5) Section 1.1 Instantiation:
> "each participant in the SRTP/SRTCP
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 session will need four ins= tantiations of the AEAD
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algorithm; one for inbound= SRTP traffic, one for
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 outbound SRTP traffic sour= ce, one for inbound
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SRTCP traffic, and one for= outbound SRTCP traffic
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 source. "
>
> Is this really correct. This seems to be limiting the use of AEAD to p= oint
> to point scenarios? The other crypto transforms for SRTP are capable o= f
> handling group scenarios. DTLS-SRTP with EKT for example would allow e= ach
> end-point to distribute its own master key that it will use for the SS= RCs
> it sends. There are also scenarios where one use a common master key f= or
> all participants.
>
> 6) Section 1.2: =A0Associated Data =A0 =A0 =A0 =A0 This is data that i= s to be
> authenticated
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0but not enc= rypted. =A0In SRTP, the associated
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0data consis= ts of the entire RTP header,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0including t= he list of CSRC identifiers (if
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0present) an= d the RTP header extension (if
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0present), a= s shown in Figure 3.
>
> Shouldn't this point to and discuss the relation to
> draft-ietf-avtcore-srtp-encrypted-header-ext-01
>
> 7. Section 1.2:
> =A0Associated Data =A0 =A0 =A0 =A0 This is data that is to be authenti= cated
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0but not enc= rypted. =A0In SRTP, the associated
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0data consis= ts of the entire RTP header,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0including t= he list of CSRC identifiers (if
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0present) an= d the RTP header extension (if
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0present), a= s shown in Figure 3.
>
> =A0 =A0 =A0Plaintext =A0 =A0 =A0 =A0 =A0 =A0 =A0 Data that is to be bo= th encrypted and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0authenticat= ed. =A0In SRTP this consists of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the RTP pay= load, the RTP padding and the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0RTP pad cou= nt fields (if the latter two
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fields are = present) as shown in Figure 3.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The padding= service provided by RTP is not
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0needed by t= he AEAD encryption algorithm, so
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the RTP pad= ding and RTP pad count fields
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0SHOULD be o= mitted.
>
> Why are these paragraphs not discussing RTCP?
>
> 8. Section 1.2.1:
> (Note that this means
> =A0 =A0that the cipher text will be longer than the plain text by prec= isely
> =A0 =A0the length of the AEAD authentication tag.)
>
> This needs more extensive discussion as it needs to be taken into acco= unt
> in RTP/RTCP when determine packet sizes both for generating right size= d
> RTP that don't violate MTU and that they are included in the RTCP<= br> > avg_rtcp_size parameter part of the scheduling algorithm.
>
> 9. Section 1.2.2: For confirmation:
>
> =A0 =A0 =A0Packet Counter =A0 =A0 Each AEAD instantiation MUST maintai= n a 6 octet
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 zero-based packet coun= ter which is incremented
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 each time an SRTP pack= et is sent. =A0As we shall
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 see below, the packet = counter is used to insure
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 each SRTP packet gets = a unique initialization
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vector.
>
> Can this use the "ROC" distribution mechanism (RFC4771) or w= hat the key-
> management provide to correctly deduce the field, or will it have prob= lems
> with late joiners in a group communication?
>
> 10. Section 1.2.2 Packet Counter:
>
> "zero-based packet counter" Does this mean that the 6 octet = long field is
> initialized to 0 and thus violate the recommendation of RTP sequence > number requirement of random start position.
>
> 11. Section 1.5: I don't like using the figure to indicate what is= of
> different types. Two reasons. The first is that it doesn't explici= tly
> enumerate protocol fields, instead 32-bytes octet with fields. Secondl= y
> because it make it hard for someone that can't see to correctly in= terpret
> this. Think if Sam Hartman would like to read this spec. You made it m= uch
> more difficult for him. You had a description earlier that with a bit = more
> precision would be correct, after having dealt with comment 6 and what=
> needs to be included due to that.
>
> 12. Section 1.6. AEAD Processing of SRTCP Packets
>
> =A0 =A0All SRTCP packets MUST be authenticated, but unlike SRTP, SRTCP=
> =A0 =A0packet encryption is optional. =A0A sender can select which pac= kets to
> =A0 =A0encrypt, and indicates this choice with a 1-bit encryption flag=
> =A0 =A0(located in the leftmost bit of the 32-bit word that contains t= he
> =A0 =A0SRTCP index)
>
> I think it is important to write "SRTCP packet" as SRTCP com= pount packet.
> As each individual RTCP packet can't be individually encrypted or = not in
> the same compound packet.
>
> 13. Section 1.6.1 and 1.6.2. Same as comment 11 on this section. Here = you
> may have to talk about octets as it is defined as the first of 32-bit<= br> > words of the first RTCP packet part of the compound that are unencrypt= ed.
>
> 14. Section 1.8. Prevention of IV Reuse
>
> =A0 =A0For a given key it is critical that the IV not repeat. =A0This = reduces
> =A0 =A0to the problem of insuring neither the Packet Counter nor the S= RTCP
> =A0 =A0index do not repeat before the AEAD instantiation is rekeyed. >
> =A0 =A0Processing MUST cease if either the 48-bit Packet Counter or th= e
> =A0 =A031-bit SRTCP index cycles back to their initial value. =A0Proce= ssing
> =A0 =A0MUST NOT resume until a new SRTP/SRTCP session has been establi= shed
> =A0 =A0using a new shared secret master key and shares master salt. > =A0 =A0Ideally, a rekey should be done well before either of these cou= nters
> =A0 =A0cycle.
>
> This section fails to discuss another issue where IV reuse could arise= .
> Namely SSRC collision. If more than a single end-point uses the same S= SRC
> there can be collision. This either put stringent requirements on how = one
> key this crypto transform in different topologies or the usage of SSRC=
> assignment rules. As the later is not really present it might be worth=
> defining rules and be clear on the impact of an SSRC collision.
>
> 15. Section 2.1:
> C_MAX =A0 =A0 =A0maximum ciphertext =A0 =A0 =A0 MUST be at most 2^16-4= 0 octets
> =A0 =A0 =A0 =A0 =A0 =A0length per invocation =A0 =A0SHOULD be at least= 2232
>
> I think the lower bound reasonsing is flawed. First of all there is RT= CP
> that has only IPv4/UDP + 2 32-bits word of none plaintext RTCP headers=
> thus making it 38 bytes. In addition what about IP Jumbogram (RFC 2675= )
> which support packet sizes of 2^32 bytes.
>
> I think the max should be set to what the upper limit where something<= br> > breaks. Is 2^32 a working limit from crypto perspective, in that case = I
> think you should use that.
>
> 16. Minimal value for C_MAX
> =A0 =A0Similarly the lower bound on C_MAX is based on the maximum
> =A0 =A0transmission unit (MTU) of 2272 octets in IEEE 802.11. =A0Becau= se many
> =A0 =A0RTP applications use very short payloads (for example, the G.72= 9
> =A0 =A0codec used in VoIP can be as short as 20 octets), implementatio= ns
> =A0 =A0that only support a maximum ciphertext length smaller than 2232=
> =A0 =A0octets are permitted under this RFC. =A0However, in the interes= t of
> =A0 =A0maximizing interoperability between various AEAD implementation= s, the
> =A0 =A0use of C_MAX values less than 2232 is discouraged.
>
> I actually think the minimum value should be that a C_MAX value of 223= 4
> MUST be supported. My reasoning is that it must be 2 bytes larger to > support full MTU RTCP. Then it really should be a MUST to ensure that = one
> knows that a counter part can support that size of plaintext. I would = like
> to point out that the current key-management systems aren't the gr= eatest
> for negotiating a lot of sub-parameters. For example my understanding = is
> that DTLS-SRTP only support negoptiating whole profiles, not sub-
> parameters at all.
>
> So if you are not specifying a hard limit what packet size a receiver = must
> support how do you know that you can interoperate?
>
> At the same time I realize that this is not optimal for a very constra= ined
> device that sends encrypted real-time payloads of some type that are m= uch
> smaller and actually don't have the buffering space for so large p= ackets.
>
> Maybe the way forward is to separate the C_max value boundary and the<= br> > minimal value supported for the defiended profiles and make it clear t= hat
> the protection profiles defined in 2.2 and 2.3 actually requires a C_m= ax
> that is 2234.
>
>
> 17. Section 2.1:
>
> For sake of clarity we specify two additional parameters:
>
> =A0 =A0 =A0 Authentication Tag Length =A0 =A0 =A0 =A0 MUST be either 8= , 12, or 16
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0octets
> =A0 =A0 =A0 Maximum number of invocations =A0 =A0 MUST be at most 2^48= for SRTP
> =A0 =A0 =A0 =A0 =A0for a given instantiation =A0 =A0 =A0MUST be at mos= t 2^31 for SRTCP
>
> As these parameters are for AEAD algorithms in general, how can you be=
> certain that no one likes an authentication tag length longer than 16<= br> > bytes or for that matter one that is 14 bytes?
>
> I guess the maximum number of invocations also comes from an assumptio= n
> around the IV construction. Which I am not certain holds as you clearl= y
> defined the IV specifically for the algorithms and other AEAD algorith= ms
> can make a different choice for IV including an explicit one, can'= t they?
> Thus does these max values really hold?
>
> 18. Section 2.2
> In addition to the Packet Counter used in the formation of IVs, each > =A0 =A0instantiation of AES-GCM has a block counter which is increment= ed
> =A0 =A0each time AES is called to produce a 16-octet output block.
>
> I would prefer that you where more explicit about the lenght of the bl= ock
> counters length, i.e =A0... AES-GCM has a block counter (32-bit) which= ...
>
> This also applies to the corresponding text in 2.3.
>
> 19. Section 2.3:
> For AES-CCM in SRTP/SRTCP, the
> =A0 =A0flag octet has the hex value 5A if an 8-octet authentication ta= g is
> =A0 =A0used, 6A if a 12-octet authentication tag is used, and 7A if a<= br> > =A0 =A016-octet authentication tag is used. =A0The flag octet is one o= f the
> =A0 =A0inputs to AES during the counter mode encryption of the plainte= xt.
>
> Considering that the table only defines the modes that has 16-octet au= th
> tags, whats the point of mentioning the other lengths?
>
> 20. Section 4:
>
> RFC 4568 defines SRTP "crypto suites"
>
> I would prefer that one instead of just using the "RFC 4568"= as handle to
> the specification instead included the title or an abbreviated one at<= br> > least. Like this:
>
> Security Descriptions [RFC4586] defines SRTP "crypto suites"=
>
> This I think is much more clear as I don't have to go to the refer= ence
> section if I don't directly remember what the RFC number is.
>
> 21. Section 4:
>
> RFC 4568 defines SRTP "crypto suites"; a crypto suite corres= ponds to
> =A0 =A0a particular AEAD algorithm in SRTP. =A0In order to allow SDP t= o signal
> =A0 =A0the use of the algorithms defined in this document, IANA will > =A0 =A0register the following crypto suites into the subregistry for S= RTP
> =A0 =A0crypto suites under the SRTP transport of the SDP Security
> =A0 =A0Descriptions:
>
> =A0 =A0 =A0 srtp-crypto-suite-ext =3D "AEAD_AES_128_GCM" =A0= =A0/
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "AEAD= _AES_256_GCM" =A0 =A0/
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "AEAD= _AES_128_GCM_8" =A0/
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "AEAD= _AES_256_GCM_8" =A0/
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "AEAD= _AES_128_GCM_12" /
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "AEAD= _AES_256_GCM_12" /
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "AEAD= _AES_128_CCM" =A0 =A0/
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "AEAD= _AES_256_CCM" =A0 =A0/
>
> Igoe and McGrew =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Informational =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page 15]
> Internet Draft =A0 =A0 =A0 =A0 AES-GCM and AES-CCM for SRTP =A0 =A0 = =A0 =A0 Feb 17, 2012
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 srtp-crypt= o-suite-ext
>
> I don't think this fulfills the registration requirement in that i= t hasn't
> made it clear how the key-salt structure for inline method are
> constructed. How many bits of keys, and how many bits of salt is to be=
> included in the structure.
>
> 22. Section 4:
>
> When it comes to DTLS-SRTP the protection profiles defined in RFC 5764= has
> the following information defined in its section 4.1.2
> SRTP_AES128_CM_HMAC_SHA1_80
> =A0 =A0 =A0 =A0 =A0cipher: AES_128_CM
> =A0 =A0 =A0 =A0 =A0cipher_key_length: 128
> =A0 =A0 =A0 =A0 =A0cipher_salt_length: 112
> =A0 =A0 =A0 =A0 =A0maximum_lifetime: 2^31
> =A0 =A0 =A0 =A0 =A0auth_function: HMAC-SHA1
> =A0 =A0 =A0 =A0 =A0auth_key_length: 160
> =A0 =A0 =A0 =A0 =A0auth_tag_length: 80
>
> I believe this information is present, but maybe it should be collecte= d
> together. It also doesn't define how the AEAD parameters defined i= n this
> specification actually are parameterized when needed.
>
>
> Cheers
>
> Magnus Westerlund
>

--20cf3079beb6a6a64e04c26696d1-- From hans.stokking@tno.nl Thu Jun 14 02:55:13 2012 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 EA98221F866A for ; Thu, 14 Jun 2012 02:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.484 X-Spam-Level: *** X-Spam-Status: No, score=3.484 tagged_above=-999 required=5 tests=[AWL=-3.987, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, 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 I9oGjLoQ654l for ; Thu, 14 Jun 2012 02:55:13 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1F46221F865F for ; Thu, 14 Jun 2012 02:55:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,769,1330902000"; d="scan'208";a="70627709" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 14 Jun 2012 11:55:09 +0200 Received: from EXC-MBX01.tsn.tno.nl ([169.254.1.223]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.02.0283.003; Thu, 14 Jun 2012 11:55:09 +0200 From: "Stokking, H.M. (Hans)" To: "avt@ietf.org" Thread-Topic: New version of IDMS draft Thread-Index: Ac1JdmVaGV2tm9tGQ72YihNyf2PxnQAkCAgwAANBs5A= Date: Thu, 14 Jun 2012 09:55:08 +0000 Message-ID: <7F110B3ECC623C4EADDEB82154F2693D0766AE0C@EXC-MBX01.tsn.tno.nl> References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: [AVTCORE] New version of IDMS draft 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: Thu, 14 Jun 2012 09:55:14 -0000 Hi All, Ray has uploaded a new version of the IDMS draft. The most important changes can be found in Section 11, which clarifies the = use of the SDP parameters and gives some recommendations on implementations= supporting both the ETSI and the IETF solution. On behalf of Ray, Hans -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of inter= net-drafts@ietf.org Sent: woensdag 13 juni 2012 15:20 To: i-d-announce@ietf.org Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-05.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : RTCP for inter-destination media synchronization Author(s) : Ray van Brandenburg Hans Stokking Fernando Boronat Mario Montagud Kevin Gross Filename : draft-ietf-avtcore-idms-05.txt Pages : 22 Date : 2012-06-13 Abstract: This document gives information on an RTCP Packet Type and RTCP XR Block Type including associated SDP parameters for Inter-Destination Media Synchronization (IDMS). The RTCP XR Block Type, registered with IANA based on an ETSI specification, is used to collect media play-out information from participants in a group playing-out (watching, listening, etc.) a specific RTP media stream. The RTCP packet type specified by this document is used to distribute a common target play-out point to which all the distributed receivers, sharing a media experience, can synchronize. Typical use cases in which IDMS is usefull are social TV, shared service control (i.e. applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-idms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-idms-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-idms-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From ron.even.tlv@gmail.com Sun Jun 17 09:07:25 2012 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 CD4AD21F85D0 for ; Sun, 17 Jun 2012 09:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 3xtMRITycWZn for ; Sun, 17 Jun 2012 09:07:25 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id D313021F85C9 for ; Sun, 17 Jun 2012 09:07:24 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so852395wib.13 for ; Sun, 17 Jun 2012 09:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=HsCjtgtHOmbQo62vQBY7/zgt6alW1r0BsLNpdqMvxqE=; b=ofkB+2NkYCCTFEE63vAjASx0sc5p3qzRrs9vVSfjlL0XYdbQUQv/JLXD2J32pwnzdC N1fUOQwCdzuZqfS+dJCEvqFUPqwRjsKxHhnEaqAukoP6S6DijfbU2rMZVUC9A2tzbbrh XMArJYbgwnL9CVgc01DfJd4MZqCmcB2KrqhrFSiZ16A2xGXJ4tHzypmOzr5XoK1d3qiB /4V85jQQFja5pP6iW8TAlMbTzhoXoB08vqtEDm1VF1gFOTOTp7Yeu99MKQDbORiRL+0K EIKKlPJhekyEmMQmeGVX2vUyG5SXhQNsqT198Td8r8oZOn/F84tIk4Snx9GUmCFL0cOU M3Ew== Received: by 10.216.144.216 with SMTP id n66mr6532884wej.107.1339949243908; Sun, 17 Jun 2012 09:07:23 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-104-121.red.bezeqint.net. [79.177.104.121]) by mx.google.com with ESMTPS id z8sm33438507wiy.1.2012.06.17.09.07.21 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jun 2012 09:07:22 -0700 (PDT) From: "Roni Even" To: Date: Sun, 17 Jun 2012 19:04:38 +0300 Message-ID: <4fde00ba.8854b40a.5854.12a4@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0159_01CD4CBC.0C5CE6B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1MouWNdp+K0jkOQUKLCbWCw+ddRA== Content-Language: en-us Cc: draft-ietf-avtcore-idms@tools.ietf.org Subject: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 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: Sun, 17 Jun 2012 16:07:26 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0159_01CD4CBC.0C5CE6B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-idms-05 , RTCP for inter-destination media synchronization. The WGLC will end on July 10th, 2012 Please review the draft and send comments to the list. For the draft authors; Are you aware of any IPR that applies to draft-ietf-avtcore-idms-05? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? The above question is needed for the document write-up when sent to publication. Thanks Roni Even AVTcore co-chair ------=_NextPart_000_0159_01CD4CBC.0C5CE6B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I would =
like to start a WGLC on http://too=
ls.ietf.org/html/draft-ietf-avtcore-idms-05 , RTCP for =
inter-destination media synchronization.
 =

The WGLC will = end on July 10th, 2012

 

Please = review the draft and send comments to the list.

 

For the =
draft authors;  Are you aware of any IPR that applies to =
draft-ietf-avtcore-idms-05? If so,
has this =
IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, =
4879, 3669 and 5378 for more details)?
The above =
question is needed for the document write-up when sent to =
publication.
 =

Thanks

 

Roni = Even

AVTcore =  co-chair

 

------=_NextPart_000_0159_01CD4CBC.0C5CE6B0-- From harald@alvestrand.no Sun Jun 17 10:52:13 2012 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 404D421F8621 for ; Sun, 17 Jun 2012 10:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.912 X-Spam-Level: X-Spam-Status: No, score=-109.912 tagged_above=-999 required=5 tests=[AWL=0.686, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 z8Mzs8uaSfjw for ; Sun, 17 Jun 2012 10:52:11 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id BF75021F85C9 for ; Sun, 17 Jun 2012 10:52:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C3F3C39E149 for ; Sun, 17 Jun 2012 19:52:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kh5DBtjDxip for ; Sun, 17 Jun 2012 19:52:08 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2878339E13F for ; Sun, 17 Jun 2012 19:52:08 +0200 (CEST) Message-ID: <4FDE1946.6070808@alvestrand.no> Date: Sun, 17 Jun 2012 19:52:06 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: 'AVT Core WG' References: <20120617175017.29921.35838.idtracker@ietfa.amsl.com> In-Reply-To: <20120617175017.29921.35838.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120617175017.29921.35838.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020500070702040704080308" Subject: [AVTCORE] Fwd: New Version Notification for draft-alvestrand-rtp-sess-neutral-01.txt 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: Sun, 17 Jun 2012 17:52:13 -0000 This is a multi-part message in MIME format. --------------020500070702040704080308 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I realized that this draft had expired. Since the current version of draft-westerlund-rtp-sess-multiplex refers to it, I thought it was best to have it as a stable reference. Apart from incorporating a reply to a comment about mixers, there are no technical changes, and the draft does not reflect the changes in my thinking that have occured in the meantime. Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rtp-sess-neutral-01.txt Date: Sun, 17 Jun 2012 10:50:17 -0700 From: internet-drafts@ietf.org To: harald@alvestrand.no A new version of I-D, draft-alvestrand-rtp-sess-neutral-01.txt has been successfully submitted by Harald T. Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-rtp-sess-neutral Revision: 01 Title: Why RTP Sessions Should Be Content Neutral Creation date: 2012-06-17 WG ID: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-alvestrand-rtp-sess-neutral-01.txt Status: http://datatracker.ietf.org/doc/draft-alvestrand-rtp-sess-neutral Htmlized: http://tools.ietf.org/html/draft-alvestrand-rtp-sess-neutral-01 Diff: http://tools.ietf.org/rfcdiff?url2=draft-alvestrand-rtp-sess-neutral-01 Abstract: This document is not intended for publication as an RFC. It gives the underpinning arguments for why the idea that RTP sessions and MIME top level types are related is a deeply broken paradigm, and that we need to get away from it. These arguments are solely the opinion of the listed author. The IETF Secretariat --------------020500070702040704080308 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I realized that this draft had expired. Since the current version of draft-westerlund-rtp-sess-multiplex refers to it, I thought it was best to have it as a stable reference.

Apart from incorporating a reply to a comment about mixers, there are no technical changes, and the draft does not reflect the changes in my thinking that have occured in the meantime.

                   Harald


-------- Original Message --------
Subject: New Version Notification for draft-alvestrand-rtp-sess-neutral-01.txt
Date: Sun, 17 Jun 2012 10:50:17 -0700
From: internet-drafts@ietf.org
To: harald@alvestrand.no 


A new version of I-D, draft-alvestrand-rtp-sess-neutral-01.txt
has been successfully submitted by Harald T. Alvestrand and posted to the
IETF repository.

Filename:	 draft-alvestrand-rtp-sess-neutral
Revision:	 01
Title:		 Why RTP Sessions Should Be Content Neutral
Creation date:	 2012-06-17
WG ID:		 Individual Submission
Number of pages: 11
URL:             http://www.ietf.org/internet-drafts/draft-alvestrand-rtp-sess-neutral-01.txt
Status:          http://datatracker.ietf.org/doc/draft-alvestrand-rtp-sess-neutral
Htmlized:        http://tools.ietf.org/html/draft-alvestrand-rtp-sess-neutral-01
Diff:            http://tools.ietf.org/rfcdiff?url2=draft-alvestrand-rtp-sess-neutral-01

Abstract:
   This document is not intended for publication as an RFC.

   It gives the underpinning arguments for why the idea that RTP
   sessions and MIME top level types are related is a deeply broken
   paradigm, and that we need to get away from it.

   These arguments are solely the opinion of the listed author.


                                                                                  


The IETF Secretariat
--------------020500070702040704080308-- From hans.stokking@tno.nl Mon Jun 18 00:14:51 2012 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 83CF321F84FB for ; Mon, 18 Jun 2012 00:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.491 X-Spam-Level: * X-Spam-Status: No, score=1.491 tagged_above=-999 required=5 tests=[AWL=1.994, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] 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 yXsiYR0kzoB2 for ; Mon, 18 Jun 2012 00:14:50 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id E98D621F850B for ; Mon, 18 Jun 2012 00:14:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,789,1330902000"; d="scan'208,217";a="15511999" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 18 Jun 2012 09:14:46 +0200 Received: from EXC-MBX01.tsn.tno.nl ([169.254.1.133]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.02.0298.004; Mon, 18 Jun 2012 09:14:46 +0200 From: "Stokking, H.M. (Hans)" To: Roni Even , "avt@ietf.org" Thread-Topic: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 Thread-Index: Ac1MouWNdp+K0jkOQUKLCbWCw+ddRAAfvCtg Date: Mon, 18 Jun 2012 07:14:45 +0000 Message-ID: <7F110B3ECC623C4EADDEB82154F2693D0767681C@EXC-MBX01.tsn.tno.nl> References: <4fde00ba.8854b40a.5854.12a4@mx.google.com> In-Reply-To: <4fde00ba.8854b40a.5854.12a4@mx.google.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: multipart/alternative; boundary="_000_7F110B3ECC623C4EADDEB82154F2693D0767681CEXCMBX01tsntnon_" MIME-Version: 1.0 Cc: "draft-ietf-avtcore-idms@tools.ietf.org" Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 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: Mon, 18 Jun 2012 07:14:51 -0000 --_000_7F110B3ECC623C4EADDEB82154F2693D0767681CEXCMBX01tsntnon_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Roni, To our knowledge, there is no IPR that applies to draft-ietf-avtcore-idms-0= 5. Best, Hans & Ray From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni = Even Sent: zondag 17 juni 2012 18:05 To: avt@ietf.org Cc: draft-ietf-avtcore-idms@tools.ietf.org Subject: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtco= re-idms-05 , RTCP for inter-destination media synchronization. The WGLC will end on July 10th, 2012 Please review the draft and send comments to the list. For the draft authors; Are you aware of any IPR that applies to draft-ietf= -avtcore-idms-05? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 397= 9, 4879, 3669 and 5378 for more details)? The above question is needed for the document write-up when sent to publica= tion. Thanks Roni Even AVTcore co-chair This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_7F110B3ECC623C4EADDEB82154F2693D0767681CEXCMBX01tsntnon_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

= Roni,

=  

= To our knowledge, there is no IPR that applies to draft-ietf-avtcore-idms-05.

=  

= Best, Hans & Ray

=  

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: zondag 17 juni 2012 18= :05
To: avt@ietf.org
Cc: draft-ietf-avtcore-idms@= tools.ietf.org
Subject: [AVTCORE] WGLC on d= raft-ietf-avtcore-idms-05

 

Hi,= 

I would like to start a WGLC on http://tools.ietf.org/html/draft-iet=
f-avtcore-idms-05 , RTCP for inter-destination media=
 synchronization.
 

The WGLC will end on July 1= 0th, 2012

 

Please review the dra= ft and send comments to the list.

 

For the draft authors;  Are you aware of any IPR that =
applies to draft-ietf-avtcore-idms-05? If so,
has this IPR been disclosed in compliance with IETF IPR rul=
es (see RFCs 3979, 4879, 3669 and 5378 for more details)?=

The above question is needed for the document write-up when=
 sent to publication.
 

Thanks

 

Roni Even<= /span>

AVTcore  co-chai= r

 

This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer

--_000_7F110B3ECC623C4EADDEB82154F2693D0767681CEXCMBX01tsntnon_-- From christer.holmberg@ericsson.com Mon Jun 18 07:01:22 2012 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 6BC7921F8656 for ; Mon, 18 Jun 2012 07:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 RMydqQZZ6O3A for ; Mon, 18 Jun 2012 07:01:21 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1318D21F8634 for ; Mon, 18 Jun 2012 07:01:19 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-e7-4fdf34ae0374 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D4.AB.28636.EA43FDF4; Mon, 18 Jun 2012 16:01:18 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.47]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 18 Jun 2012 16:01:18 +0200 From: Christer Holmberg To: Roni Even , "avt@ietf.org" Date: Mon, 18 Jun 2012 16:01:16 +0200 Thread-Topic: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 Thread-Index: Ac1MouWNdp+K0jkOQUKLCbWCw+ddRAAtob1w Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853404689F19@ESESSCMS0356.eemea.ericsson.se> References: <4fde00ba.8854b40a.5854.12a4@mx.google.com> In-Reply-To: <4fde00ba.8854b40a.5854.12a4@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05853404689F19ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvre46k/v+Bp/+Glq87FnJbnFoxxpG i7/tzA7MHjtn3WX3WLLkJ5PHl8uf2QKYo7hsUlJzMstSi/TtErgyulbvYyqYa1txeWZyA+MO sy5GTg4JAROJM2enMUPYYhIX7q1n62Lk4hASOMUosWrPYrCEkMACRom5y5K7GDk42AQsJLr/ aYOYIgKuEvd3+oOYzALhEjdXZoAUswioSsy9sgOsUVjAUuLx3IlMILaIgJXErd6ZzBC2kcT5 bcsYQWxeoNZ1288xQSwyl7jafhnM5gRadO7MUTCbEeiy76fWgNnMAuISt57MZ4K4WEBiyZ7z UNeLSrx8/I8Vol5U4k77ekaI+nyJZ30H2CB2CUqcnPmEZQKj6Cwko2YhKZuFpAwiridxY+oU NghbW2LZwtfMELauxIx/h1iQxRcwsq9iFM5NzMxJLzfUSy3KTC4uzs/TK07dxAiMuoNbfuvu YDx1TuQQozQHi5I4L1fSfn8hgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjPbaWrtuB7uKnO8o 3cTJKsgupXj7R4HAorWdqz6vU34QV3Hz86Yw9wcP9x1wn5S+6KHK6R1eLlbRO7MZtNg9uqt/ HN8iufJ8nlhzwFy52+xfpxRJWU78P+3D/P0l10RFGWc88cusmRRqsHWXUUznil13pv1t0TPf W+OZVbecqVc8W25W6U9JXSWW4oxEQy3mouJEAJ529g2IAgAA Cc: "draft-ietf-avtcore-idms@tools.ietf.org" Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 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: Mon, 18 Jun 2012 14:01:22 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05853404689F19ESESSCMS0356e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As the SDP rtcp-xr attribute is defined RFC 3611, I guess the offer/answer = aspects of that RFC apply also for the extension. If so, it would be good t= o mention that. However, as the SDP rtcp-idms attribute is defined in this document, you al= so need to define the offer/answer aspects. There is some text in section 1= 1, but the section name talks about "TISPAN compatibility". You should have= a section named "Offer/Answer", or something. Regards, Christer From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni = Even Sent: 17. kes=E4kuuta 2012 19:05 To: avt@ietf.org Cc: draft-ietf-avtcore-idms@tools.ietf.org Subject: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtco= re-idms-05 , RTCP for inter-destination media synchronization. The WGLC will end on July 10th, 2012 Please review the draft and send comments to the list. For the draft authors; Are you aware of any IPR that applies to draft-ietf= -avtcore-idms-05? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 397= 9, 4879, 3669 and 5378 for more details)? The above question is needed for the document write-up when sent to publica= tion. Thanks Roni Even AVTcore co-chair --_000_7F2072F1E0DE894DA4B517B93C6A05853404689F19ESESSCMS0356e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

As the SDP rtcp-xr attribute is defined RFC 3611, I gues= s the offer/answer aspects of that RFC apply also for the extension. If so,= it would be good to mention that.

 

However, as the SDP rtcp-idms attribute= is defined in this document, you also need to define the offer/answer aspe= cts. There is some text in section 11, but the section name talks about = 220;TISPAN compatibility”. You should have a section named “Off= er/Answer”, or something.

<= span style=3D'color:#1F497D'> 

Regards,

 

Christer

 

 

 <= /span>

 

From: avt-bounces@ietf.org [= mailto:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: = 17. kes=E4kuuta 2012 19:05
To: avt@ietf.org
Cc: draft-i= etf-avtcore-idms@tools.ietf.org
Subject: [AVTCORE] WGLC on draft-= ietf-avtcore-idms-05

=  

Hi,

I would like to s=
tart a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-idms-05 , RTCP for inter-destination media synchronization.
<= pre> 

T= he WGLC will end on July 10th, 2012

 

Please review the draft and se= nd comments to the list.

 

For the draft authors;  Are you aware of any IPR that applies to d=
raft-ietf-avtcore-idms-05? If so,
has this IPR been =
disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and =
5378 for more details)?
The above question is needed f=
or the document write-up when sent to publication.
<= pre> 

Thanks

 

Roni Even

AVTcore  co-chair

 

= --_000_7F2072F1E0DE894DA4B517B93C6A05853404689F19ESESSCMS0356e_-- From internet-drafts@ietf.org Mon Jun 18 23:41:15 2012 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 B6E1111E80E2; Mon, 18 Jun 2012 23:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 OGA7cAE1bDhN; Mon, 18 Jun 2012 23:41:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2E211E8073; Mon, 18 Jun 2012 23:41:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120619064115.26541.88723.idtracker@ietfa.amsl.com> Date: Mon, 18 Jun 2012 23:41:15 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-15.txt 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, 19 Jun 2012 06:41:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Guidelines for Use of the RTP Monitoring Framework Author(s) : Qin Wu Geoff Hunt Philip Arden Filename : draft-ietf-avtcore-monarch-15.txt Pages : 29 Date : 2012-06-18 Abstract: This memo proposes an extensible RTP monitoring framework for extending RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) (RFC3611) block type to report new metrics regarding media transmission or reception quality, following RTCP guidelines established in RFC5968. This memo suggests that a new block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics which attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks which covers their set of concerns. Where possible, a specific block should be designed to be re-usable across more than one application, for example, for all of voice, streaming audio and video. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-monarch-15 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-monarch-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wwwrun@rfc-editor.org Mon Jun 18 11:39:35 2012 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 DDC4521F86CE for ; Mon, 18 Jun 2012 11:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.179 X-Spam-Level: X-Spam-Status: No, score=-102.179 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 yjZtzir7LEYu for ; Mon, 18 Jun 2012 11:39:35 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7439C21F86C4 for ; Mon, 18 Jun 2012 11:39:35 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 245B272E008; Mon, 18 Jun 2012 11:39:04 -0700 (PDT) To: schulzrinne@cs.columbia.edu, casner@acm.org, ronf@bluecoat.com, van@packetdesign.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, keith.drage@alcatel-lucent.com, even.roni@huawei.com From: RFC Errata System Message-Id: <20120618183905.245B272E008@rfc-editor.org> Date: Mon, 18 Jun 2012 11:39:04 -0700 (PDT) X-Mailman-Approved-At: Tue, 19 Jun 2012 08:04:22 -0700 Cc: pieter.demuytere@gmail.com, avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVTCORE] [Technical Errata Reported] RFC3550 (3263) 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: Mon, 18 Jun 2012 18:39:36 -0000 The following errata report has been submitted for RFC3550, "RTP: A Transport Protocol for Real-Time Applications". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3550&eid=3263 -------------------------------------- Type: Technical Reported by: Pieter Demuytere Section: 6.4.1 Original Text ------------- cumulative number of packets lost: 24 bits The total number of RTP data packets from source SSRC_n that have been lost since the beginning of reception. This number is defined to be the number of packets expected less the number of packets actually received, where the number of packets received includes any which are late or duplicates. Thus, packets that arrive late are not counted as lost, and the loss may be negative if there are duplicates. The number of packets expected is defined to be the extended last sequence number received, as defined next, less the initial sequence number received. This may be calculated as shown in Appendix A.3. Corrected Text -------------- cumulative number of packets lost: 24 bits The total number of RTP data packets from source SSRC_n that have been lost since the beginning of reception. This number is defined to be the number of packets expected less the number of packets actually received, where the number of packets received includes any which are late or duplicates. Thus, packets that arrive late are not counted as lost, and the loss may be negative if there are duplicates. The number of packets expected is defined to be the extended highest sequence number received, as defined next, less the initial sequence number received. This may be calculated as shown in Appendix A.3. Notes ----- Changed The number of packets expected is defined to be the extended last sequence number received... Into The number of packets expected is defined to be the extended highest sequence number received... Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3550 (draft-ietf-avt-rtp-new-12) -------------------------------------- Title : RTP: A Transport Protocol for Real-Time Applications Publication Date : July 2003 Author(s) : H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson Category : DRAFT STANDARD Source : Audio/Video Transport Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From casner@acm.org Mon Jun 18 15:14:10 2012 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 1FF0F11E80FD for ; Mon, 18 Jun 2012 15:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 4+Rq4jxKxudp for ; Mon, 18 Jun 2012 15:14:09 -0700 (PDT) Received: from mailman.packetdesign.com (firewall-gw-dirty-u.packetdesign.com [65.192.41.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF2011E80C1 for ; Mon, 18 Jun 2012 15:14:09 -0700 (PDT) Received: from packetdesign.com (vpn-int.packetdesign.com [192.168.0.180]) by mailman.packetdesign.com (8.13.1/8.13.1) with ESMTP id q5IMDm0L006461; Mon, 18 Jun 2012 15:13:49 -0700 Date: Mon, 18 Jun 2012 15:13:48 -0700 (PDT) From: Stephen Casner To: RFC Errata System In-Reply-To: <20120618183905.245B272E008@rfc-editor.org> Message-ID: References: <20120618183905.245B272E008@rfc-editor.org> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Tue, 19 Jun 2012 08:04:22 -0700 Cc: schulzrinne@cs.columbia.edu, avt@ietf.org, pieter.demuytere@gmail.com, van@packetdesign.com Subject: Re: [AVTCORE] [Technical Errata Reported] RFC3550 (3263) 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: Mon, 18 Jun 2012 22:14:10 -0000 I consider this erratum to be valid. The quoted paragraph says "extended last sequence number received, as defined next", whereas what is defined next is "extended highest sequence number received". I think we made that terminology change but neglected to change the usage in the quoted paragraph. I think this erratum is not too serious, however. I think most readers will figure it out quickly. -- Steve On Mon, 18 Jun 2012, RFC Errata System wrote: > > The following errata report has been submitted for RFC3550, > "RTP: A Transport Protocol for Real-Time Applications". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3550&eid=3263 > > -------------------------------------- > Type: Technical > Reported by: Pieter Demuytere > > Section: 6.4.1 > > Original Text > ------------- > cumulative number of packets lost: 24 bits The total number of RTP data packets from source SSRC_n that have been lost since the beginning of reception. This number is defined to be the number of packets expected less the number of packets actually received, where the number of packets received includes any which are late or duplicates. Thus, packets that arrive late are not counted as lost, and the loss may be negative if there are duplicates. The number of packets expected is defined to be the extended last sequence number received, as defined next, less the initial sequence number received. This may be calculated as shown in Appendix A.3. > > Corrected Text > -------------- > cumulative number of packets lost: 24 bits The total number of RTP data packets from source SSRC_n that have been lost since the beginning of reception. This number is defined to be the number of packets expected less the number of packets actually received, where the number of packets received includes any which are late or duplicates. Thus, packets that arrive late are not counted as lost, and the loss may be negative if there are duplicates. The number of packets expected is defined to be the extended highest sequence number received, as defined next, less the initial sequence number received. This may be calculated as shown in Appendix A.3. > > Notes > ----- > Changed > > The number of packets expected is defined to be the extended last sequence number received... > > Into > > The number of packets expected is defined to be the extended highest sequence number received... > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC3550 (draft-ietf-avt-rtp-new-12) > -------------------------------------- > Title : RTP: A Transport Protocol for Real-Time Applications > Publication Date : July 2003 > Author(s) : H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson > Category : DRAFT STANDARD > Source : Audio/Video Transport > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > From ron.frederick@bluecoat.com Mon Jun 18 16:00:44 2012 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 DC58311E80CF for ; Mon, 18 Jun 2012 16:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 qHOPntuq2QfS for ; Mon, 18 Jun 2012 16:00:44 -0700 (PDT) Received: from plsvl-mailgw-01.bluecoat.com (plsvl-mailgw-01.bluecoat.com [199.91.133.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5576E11E80CB for ; Mon, 18 Jun 2012 16:00:43 -0700 (PDT) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com (unknown [10.2.2.122]) by plsvl-mailgw-01.bluecoat.com (Postfix) with ESMTP id 7129A81A0AA; Mon, 18 Jun 2012 16:00:53 -0800 (AKDT) Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Mon, 18 Jun 2012 16:00:42 -0700 From: "Frederick, Ron" To: Stephen Casner Thread-Topic: [Technical Errata Reported] RFC3550 (3263) Thread-Index: AQHNTYG2DZQGF7agIU2rUGCZmE3vx5cBGZkAgAANGoA= Date: Mon, 18 Jun 2012 23:00:41 +0000 Message-ID: References: <20120618183905.245B272E008@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 19 Jun 2012 08:04:22 -0700 Cc: "" , "" , "" , RFC Errata System , "" Subject: Re: [AVTCORE] [Technical Errata Reported] RFC3550 (3263) 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: Mon, 18 Jun 2012 23:00:45 -0000 I'm good with this change. On Jun 18, 2012, at 3:13 PM, Stephen Casner wrote: I consider this erratum to be valid. The quoted paragraph says "extended last sequence number received, as defined next", whereas what is defined next is "extended highest sequence number received". I think we made that terminology change but neglected to change the usage in the quoted paragraph. I think this erratum is not too serious, however. I think most readers will figure it out quickly. -- Steve On Mon, 18 Jun 2012, RFC Errata System wrote: The following errata report has been submitted for RFC3550, "RTP: A Transport Protocol for Real-Time Applications". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D3550&eid=3D3263 -------------------------------------- Type: Technical Reported by: Pieter Demuytere > Section: 6.4.1 Original Text ------------- cumulative number of packets lost: 24 bits The total number of RTP data pac= kets from source SSRC_n that have been lost since the beginning of receptio= n. This number is defined to be the number of packets expected less the num= ber of packets actually received, where the number of packets received incl= udes any which are late or duplicates. Thus, packets that arrive late are n= ot counted as lost, and the loss may be negative if there are duplicates. T= he number of packets expected is defined to be the extended last sequence n= umber received, as defined next, less the initial sequence number received.= This may be calculated as shown in Appendix A.3. Corrected Text -------------- cumulative number of packets lost: 24 bits The total number of RTP data pac= kets from source SSRC_n that have been lost since the beginning of receptio= n. This number is defined to be the number of packets expected less the num= ber of packets actually received, where the number of packets received incl= udes any which are late or duplicates. Thus, packets that arrive late are n= ot counted as lost, and the loss may be negative if there are duplicates. T= he number of packets expected is defined to be the extended highest sequenc= e number received, as defined next, less the initial sequence number receiv= ed. This may be calculated as shown in Appendix A.3. Notes ----- Changed The number of packets expected is defined to be the extended last sequence = number received... Into The number of packets expected is defined to be the extended highest sequen= ce number received... Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3550 (draft-ietf-avt-rtp-new-12) -------------------------------------- Title : RTP: A Transport Protocol for Real-Time Applications Publication Date : July 2003 Author(s) : H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson Category : DRAFT STANDARD Source : Audio/Video Transport Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG -- Ron Frederick ronf@bluecoat.com From csp@csperkins.org Tue Jun 19 14:46:04 2012 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 9936C11E80EC for ; Tue, 19 Jun 2012 14:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 WCNceW9p4d8j for ; Tue, 19 Jun 2012 14:46:03 -0700 (PDT) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfa.amsl.com (Postfix) with ESMTP id D941421F86C8 for ; Tue, 19 Jun 2012 14:46:00 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.11]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Sh6FL-0001xb-ow for avt@ietf.org; Tue, 19 Jun 2012 21:45:59 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Colin Perkins In-Reply-To: <20120619064115.26541.88723.idtracker@ietfa.amsl.com> Date: Tue, 19 Jun 2012 22:45:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120619064115.26541.88723.idtracker@ietfa.amsl.com> To: IETF AVTCore WG X-Mailer: Apple Mail (2.1278) Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-15.txt 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, 19 Jun 2012 21:46:04 -0000 On 19 Jun 2012, at 07:41, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Audio/Video Transport Core = Maintenance Working Group of the IETF. >=20 > Title : Guidelines for Use of the RTP Monitoring = Framework > Author(s) : Qin Wu > Geoff Hunt > Philip Arden > Filename : draft-ietf-avtcore-monarch-15.txt > Pages : 29 > Date : 2012-06-18 >=20 > Abstract: > This memo proposes an extensible RTP monitoring framework for > extending RTP Control Protocol (RTCP) with a new RTCP Extended > Reports (XR) (RFC3611) block type to report new metrics regarding > media transmission or reception quality, following RTCP guidelines > established in RFC5968. This memo suggests that a new block should > contain a single metric or a small number of metrics relevant to a > single parameter of interest or concern, rather than containing a > number of metrics which attempt to provide full coverage of all = those > parameters of concern to a specific application. Applications may > then "mix and match" to create a set of blocks which covers their = set > of concerns. Where possible, a specific block should be designed to > be re-usable across more than one application, for example, for all > of voice, streaming audio and video. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch I've reviewed this updated draft. In general I think the changes look = reasonable, but I find the new Figure 1 confusing. To me, something more = like the following would convey the ideas better: +-----------+ +----------+ |Third Party| |Management| |RTP Monitor| >>>>>>>>| System |<<<<< +-----------+ ^ +----------+ ^ : ^ ^ ^ : | ^ ^ +---------------+ : | +-------------+ +-------------+ | +-----------+ | : | |+-----------+| |+-----------+| | |RTP Monitor| |..:...|.......||RTP Monitor||........||RTP Monitor|| | +-----------+ | | |+-----------+| |+-----------+| | |------+------>| |------->| | | RTP Sender | |RTP Mixer or | |RTP Receiver | | | |Translator | | | +---------------+ +-------------+ +-------------+ ----> RTP media traffic ..... RTCP control channel >>>>> Non-RTP/RTCP management flows I would also suggest that the figure caption be changed to "Example = showing the components of the RTP monitoring framework", or similar.=20 I also noticed that the last paragraph of Section 3.1 suggests that only = RTCP XR reports are used with multicast groups, but all RTCP packets can = be used, of course. --=20 Colin Perkins http://csperkins.org/ From internet-drafts@ietf.org Tue Jun 19 18:50:54 2012 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 CA9BF11E8125; Tue, 19 Jun 2012 18:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 JaZZGCrfvoAU; Tue, 19 Jun 2012 18:50:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221D011E80EB; Tue, 19 Jun 2012 18:50:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120620015054.704.77202.idtracker@ietfa.amsl.com> Date: Tue, 19 Jun 2012 18:50:54 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-16.txt 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: Wed, 20 Jun 2012 01:50:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Guidelines for Use of the RTP Monitoring Framework Author(s) : Qin Wu Geoff Hunt Philip Arden Filename : draft-ietf-avtcore-monarch-16.txt Pages : 28 Date : 2012-06-19 Abstract: This memo proposes an extensible RTP monitoring framework for extending RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) (RFC3611) block type to report new metrics regarding media transmission or reception quality, following RTCP guidelines established in RFC5968. This memo suggests that a new block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics which attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks which covers their set of concerns. Where possible, a specific block should be designed to be re-usable across more than one application, for example, for all of voice, streaming audio and video. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-monarch-16 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-monarch-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bill.wu@huawei.com Tue Jun 19 18:54:02 2012 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 0955811E8149 for ; Tue, 19 Jun 2012 18:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.813 X-Spam-Level: X-Spam-Status: No, score=-4.813 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] 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 6p8xB8W2Ih+u for ; Tue, 19 Jun 2012 18:54:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEFE11E80BA for ; Tue, 19 Jun 2012 18:54:00 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHI52493; Tue, 19 Jun 2012 21:53:56 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 19 Jun 2012 18:53:24 -0700 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 19 Jun 2012 18:53:27 -0700 Received: from w53375 (10.138.41.149) by szxeml422-hub.china.huawei.com (10.82.67.161) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 20 Jun 2012 09:53:21 +0800 Message-ID: <9E9264F9D2BF437AB56FA00A9AEB05AA@china.huawei.com> From: Qin Wu To: Colin Perkins , IETF AVTCore WG References: <20120619064115.26541.88723.idtracker@ietfa.amsl.com> Date: Wed, 20 Jun 2012 09:53:19 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-15.txt 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: Wed, 20 Jun 2012 01:54:02 -0000 TG9va3MgZ29vZCB0byBtZSwNCkkgaGF2ZSBkb25lIHRoZSB1cGRhdGUgd2l0aCB5b3VyIHN1Z2dl c3RlZCBjaGFuZ2VzLg0KDQpEaWZmIGZyb20gcHJldmlvdXMgdmVyc2lvbiBpczoNCmh0dHA6Ly90 b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTYN Cg0KUmVnYXJkcyENCi1RaW4NCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAi Q29saW4gUGVya2lucyIgPGNzcEBjc3BlcmtpbnMub3JnPg0KVG86ICJJRVRGIEFWVENvcmUgV0ci IDxhdnRAaWV0Zi5vcmc+DQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMjAsIDIwMTIgNTo0NSBBTQ0K U3ViamVjdDogUmU6IFtBVlRDT1JFXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWF2dGNvcmUtbW9u YXJjaC0xNS50eHQNCg0KDQo+IE9uIDE5IEp1biAyMDEyLCBhdCAwNzo0MSwgSW50ZXJuZXQtRHJh ZnRzQGlldGYub3JnIHdyb3RlOg0KPj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxl IGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPj4gVGhpcyBk cmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFp bnRlbmFuY2UgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4+IA0KPj4gVGl0bGUgICAgICAg ICAgIDogR3VpZGVsaW5lcyBmb3IgVXNlIG9mIHRoZSBSVFAgTW9uaXRvcmluZyBGcmFtZXdvcmsN Cj4+IEF1dGhvcihzKSAgICAgICA6IFFpbiBXdQ0KPj4gICAgICAgICAgICAgICAgICAgICAgICAg IEdlb2ZmIEh1bnQNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBQaGlsaXAgQXJkZW4NCj4+ IEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTE1LnR4dA0KPj4g UGFnZXMgICAgICAgICAgIDogMjkNCj4+IERhdGUgICAgICAgICAgICA6IDIwMTItMDYtMTgNCj4+ IA0KPj4gQWJzdHJhY3Q6DQo+PiAgIFRoaXMgbWVtbyBwcm9wb3NlcyBhbiBleHRlbnNpYmxlIFJU UCBtb25pdG9yaW5nIGZyYW1ld29yayBmb3INCj4+ICAgZXh0ZW5kaW5nIFJUUCBDb250cm9sIFBy b3RvY29sIChSVENQKSB3aXRoIGEgbmV3IFJUQ1AgRXh0ZW5kZWQNCj4+ICAgUmVwb3J0cyAoWFIp IChSRkMzNjExKSBibG9jayB0eXBlIHRvIHJlcG9ydCBuZXcgbWV0cmljcyByZWdhcmRpbmcNCj4+ ICAgbWVkaWEgdHJhbnNtaXNzaW9uIG9yIHJlY2VwdGlvbiBxdWFsaXR5LCBmb2xsb3dpbmcgUlRD UCBndWlkZWxpbmVzDQo+PiAgIGVzdGFibGlzaGVkIGluIFJGQzU5NjguICBUaGlzIG1lbW8gc3Vn Z2VzdHMgdGhhdCBhIG5ldyBibG9jayBzaG91bGQNCj4+ICAgY29udGFpbiBhIHNpbmdsZSBtZXRy aWMgb3IgYSBzbWFsbCBudW1iZXIgb2YgbWV0cmljcyByZWxldmFudCB0byBhDQo+PiAgIHNpbmds ZSBwYXJhbWV0ZXIgb2YgaW50ZXJlc3Qgb3IgY29uY2VybiwgcmF0aGVyIHRoYW4gY29udGFpbmlu ZyBhDQo+PiAgIG51bWJlciBvZiBtZXRyaWNzIHdoaWNoIGF0dGVtcHQgdG8gcHJvdmlkZSBmdWxs IGNvdmVyYWdlIG9mIGFsbCB0aG9zZQ0KPj4gICBwYXJhbWV0ZXJzIG9mIGNvbmNlcm4gdG8gYSBz cGVjaWZpYyBhcHBsaWNhdGlvbi4gIEFwcGxpY2F0aW9ucyBtYXkNCj4+ICAgdGhlbiAibWl4IGFu ZCBtYXRjaCIgdG8gY3JlYXRlIGEgc2V0IG9mIGJsb2NrcyB3aGljaCBjb3ZlcnMgdGhlaXIgc2V0 DQo+PiAgIG9mIGNvbmNlcm5zLiAgV2hlcmUgcG9zc2libGUsIGEgc3BlY2lmaWMgYmxvY2sgc2hv dWxkIGJlIGRlc2lnbmVkIHRvDQo+PiAgIGJlIHJlLXVzYWJsZSBhY3Jvc3MgbW9yZSB0aGFuIG9u ZSBhcHBsaWNhdGlvbiwgZm9yIGV4YW1wbGUsIGZvciBhbGwNCj4+ICAgb2Ygdm9pY2UsIHN0cmVh bWluZyBhdWRpbyBhbmQgdmlkZW8uDQo+PiANCj4+IA0KPj4gVGhlIElFVEYgZGF0YXRyYWNrZXIg c3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaA0KPiANCj4gSSd2ZSByZXZpZXdl ZCB0aGlzIHVwZGF0ZWQgZHJhZnQuIEluIGdlbmVyYWwgSSB0aGluayB0aGUgY2hhbmdlcyBsb29r IHJlYXNvbmFibGUsIGJ1dCBJIGZpbmQgdGhlIG5ldyBGaWd1cmUgMSBjb25mdXNpbmcuIFRvIG1l LCBzb21ldGhpbmcgbW9yZSBsaWtlIHRoZSBmb2xsb3dpbmcgd291bGQgY29udmV5IHRoZSBpZGVh cyBiZXR0ZXI6DQo+IA0KPiAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rICAgICAgICAgICAg ICAgICAgKy0tLS0tLS0tLS0rDQo+ICAgICAgICAgICAgICAgIHxUaGlyZCBQYXJ0eXwgICAgICAg ICAgICAgICAgICB8TWFuYWdlbWVudHwNCj4gICAgICAgICAgICAgICAgfFJUUCBNb25pdG9yfCAg ICAgICAgICA+Pj4+Pj4+PnwgIFN5c3RlbSAgfDw8PDw8DQo+ICAgICAgICAgICAgICAgICstLS0t LS0tLS0tLSsgICAgICAgICAgXiAgICAgICArLS0tLS0tLS0tLSsgICAgXg0KPiAgICAgICAgICAg ICAgICAgICAgOiAgIF4gICAgICAgICAgICAgIF4gICAgICAgICAgICAgICAgICAgICAgIF4NCj4g ICAgICAgICAgICAgICAgICAgIDogICB8ICAgICAgICAgICAgICBeICAgICAgICAgICAgICAgICAg ICAgICBeDQo+ICstLS0tLS0tLS0tLS0tLS0rICA6ICAgfCAgICAgICArLS0tLS0tLS0tLS0tLSsg ICAgICAgICstLS0tLS0tLS0tLS0tKw0KPiB8ICstLS0tLS0tLS0tLSsgfCAgOiAgIHwgICAgICAg fCstLS0tLS0tLS0tLSt8ICAgICAgICB8Ky0tLS0tLS0tLS0tK3wNCj4gfCB8UlRQIE1vbml0b3J8 IHwuLjouLi58Li4uLi4uLnx8UlRQIE1vbml0b3J8fC4uLi4uLi4ufHxSVFAgTW9uaXRvcnx8DQo+ IHwgKy0tLS0tLS0tLS0tKyB8ICAgICAgfCAgICAgICB8Ky0tLS0tLS0tLS0tK3wgICAgICAgIHwr LS0tLS0tLS0tLS0rfA0KPiB8ICAgICAgICAgICAgICAgfC0tLS0tLSstLS0tLS0+fCAgICAgICAg ICAgICB8LS0tLS0tLT58ICAgICAgICAgICAgIHwNCj4gfCBSVFAgU2VuZGVyICAgIHwgICAgICAg ICAgICAgIHxSVFAgTWl4ZXIgb3IgfCAgICAgICAgfFJUUCBSZWNlaXZlciB8DQo+IHwgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICB8VHJhbnNsYXRvciAgIHwgICAgICAgIHwgICAgICAgICAg ICAgfA0KPiArLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rICAg ICAgICArLS0tLS0tLS0tLS0tLSsNCj4gDQo+IC0tLS0+IFJUUCBtZWRpYSB0cmFmZmljDQo+IC4u Li4uIFJUQ1AgY29udHJvbCBjaGFubmVsDQo+ID4+Pj4+IE5vbi1SVFAvUlRDUCBtYW5hZ2VtZW50 IGZsb3dzDQo+IA0KPiBJIHdvdWxkIGFsc28gc3VnZ2VzdCB0aGF0IHRoZSBmaWd1cmUgY2FwdGlv biBiZSBjaGFuZ2VkIHRvICJFeGFtcGxlIHNob3dpbmcgdGhlIGNvbXBvbmVudHMgb2YgdGhlIFJU UCBtb25pdG9yaW5nIGZyYW1ld29yayIsIG9yIHNpbWlsYXIuIA0KPiANCj4gSSBhbHNvIG5vdGlj ZWQgdGhhdCB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgU2VjdGlvbiAzLjEgc3VnZ2VzdHMgdGhhdCBv bmx5IFJUQ1AgWFIgcmVwb3J0cyBhcmUgdXNlZCB3aXRoIG11bHRpY2FzdCBncm91cHMsIGJ1dCBh bGwgUlRDUCBwYWNrZXRzIGNhbiBiZSB1c2VkLCBvZiBjb3Vyc2UuDQo+IA0KPiAtLSANCj4gQ29s aW4gUGVya2lucw0KPiBodHRwOi8vY3NwZXJraW5zLm9yZy8NCj4gDQo+IA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQXVkaW8vVmlkZW8g VHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCj4gYXZ0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0 From magnus.westerlund@ericsson.com Wed Jun 20 02:33:56 2012 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 38B9121F86F5 for ; Wed, 20 Jun 2012 02:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, 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 886cuGetD9SE for ; Wed, 20 Jun 2012 02:33:55 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id ABCCA21F86F2 for ; Wed, 20 Jun 2012 02:33:54 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-68-4fe199018dd1 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BA.56.00702.10991EF4; Wed, 20 Jun 2012 11:33:53 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Wed, 20 Jun 2012 11:33:53 +0200 Message-ID: <4FE19900.7000206@ericsson.com> Date: Wed, 20 Jun 2012 11:33:52 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: avt@ietf.org References: <20120620015054.704.77202.idtracker@ietfa.amsl.com> In-Reply-To: <20120620015054.704.77202.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnluLIzCtJLcpLzFFi42KZGfG3Vpdx5kN/g+1HZCxe9qxkd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpRdN1gL2pQqWhfsYm9gvCrVxcjJISFgItH47jQrhC0mceHe erYuRi4OIYFTjBLHnh1hhXCWM0rM/H2ZGaSKV0BbomPCbTCbRUBVYuHXXiYQm03AQuLmj0Y2 EFtUIFhi2vR77BD1ghInZz5hAbFFBAQkVmz/C2YLC7hInDlxHqxXSMBeYsuJT2BxTgEHiXVd HUwQF0lK3GtfDTaTWUBPYsrVFkYIW16ieetsZohebYmGpg7WCYyCs5Csm4WkZRaSlgWMzKsY hXMTM3PSy831Uosyk4uL8/P0ilM3MQID8+CW3wY7GDfdFzvEKM3BoiTOq6e6319IID2xJDU7 NbUgtSi+qDQntfgQIxMHp1QDY6vY5qzfOwtE/BY7/G2dtfD/gjNfL63NnBl7M2m6GMdTToHO NtN5smXHVia6moRu6RE05DLNU1mQJ/Nzfj9fJme3TewVsd7tm1/H1d+VFlVfcYT75Myv7ILK 0y89U1Gz+xQ2dUfQhFl5LQGLG3QFyz4GyN9l6/y4wLTRcP2fWK5l1rUTbJPylViKMxINtZiL ihMBBrMfeRoCAAA= Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-16.txt 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: Wed, 20 Jun 2012 09:33:56 -0000 WG and authors, I hope that anyone that has any additional comments can provide these within a week from now. I will by then tell our AD that the WG believes they have resolved the issues and have consensus on the updates. In regards to the AD review comments I think this document do address them. At least as long as one accept that we have made clear that the documents purpose is more to describe the monitoring framework that has grown into existence rather than defining a monitoring architecture. I have some few comments from my review. All minor editorial ones. 1. Abstract: following RTCP guidelines established in RFC5968. I wonder if this reference should be expanded with the title in the abstract. 2. Section 1: The objective of this document is to define an extensible RTP monitoring framework to provide a small number of re-usable Quality of Service (QoS)/QoE metrics which facilitate reduced implementation costs and help maximize inter-operability. What I reacted to in the above sentence is "define" which i think should be changed to describe, discuss or review. 3. Section 5.4: This memo proposes to define a new XR Block (i.e., the Measurement information block [MEASI]) that will be used to convey the common time period and the number of packets sent during this period. Considering that the reference is in IESG evaluation, shouldn'ta different word than "proposes" to point to this reference. I think you might simply state something like. "Measurement Identity and information Reporting using SDES item and XR Block" [MEASI] enables an RTCP sender to convey the common time period and the number of packets sent during this period. Cheers Magnus On 2012-06-20 03:50, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : Guidelines for Use of the RTP Monitoring Framework > Author(s) : Qin Wu > Geoff Hunt > Philip Arden > Filename : draft-ietf-avtcore-monarch-16.txt > Pages : 28 > Date : 2012-06-19 > > Abstract: > This memo proposes an extensible RTP monitoring framework for > extending RTP Control Protocol (RTCP) with a new RTCP Extended > Reports (XR) (RFC3611) block type to report new metrics regarding > media transmission or reception quality, following RTCP guidelines > established in RFC5968. This memo suggests that a new block should > contain a single metric or a small number of metrics relevant to a > single parameter of interest or concern, rather than containing a > number of metrics which attempt to provide full coverage of all those > parameters of concern to a specific application. Applications may > then "mix and match" to create a set of blocks which covers their set > of concerns. Where possible, a specific block should be designed to > be re-usable across more than one application, for example, for all > of voice, streaming audio and video. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-monarch-16 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-16 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From bill.wu@huawei.com Wed Jun 20 03:07:51 2012 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 9450921F86F2 for ; Wed, 20 Jun 2012 03:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.518 X-Spam-Level: X-Spam-Status: No, score=-4.518 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] 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 YhQ1AeBckh+c for ; Wed, 20 Jun 2012 03:07:50 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id AF5A521F86F1 for ; Wed, 20 Jun 2012 03:07:50 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHB45182; Wed, 20 Jun 2012 06:07:50 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 20 Jun 2012 03:06:44 -0700 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 20 Jun 2012 03:06:48 -0700 Received: from w53375 (10.138.41.149) by szxeml405-hub.china.huawei.com (10.82.67.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 20 Jun 2012 18:06:44 +0800 Message-ID: From: Qin Wu To: Magnus Westerlund , References: <20120620015054.704.77202.idtracker@ietfa.amsl.com> <4FE19900.7000206@ericsson.com> Date: Wed, 20 Jun 2012 18:06:43 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-16.txt 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: Wed, 20 Jun 2012 10:07:52 -0000 MS4gQWJzdHJhY3Q6DQoNCiBmb2xsb3dpbmcgUlRDUCBndWlkZWxpbmVzDQogICBlc3RhYmxpc2hl ZCBpbiBSRkM1OTY4Lg0KDQpJIHdvbmRlciBpZiB0aGlzIHJlZmVyZW5jZSBzaG91bGQgYmUgZXhw YW5kZWQgd2l0aCB0aGUgdGl0bGUgaW4gdGhlDQphYnN0cmFjdC4NCg0KW1Fpbl06IE9rYXksIGJ1 dCB0aGUgd29yZCAiZ3VpZGVsaW5lcyIgbWF5IHJlcGVhdCB0d2ljZSBpbiB0aGlzIHNlbnRlbmNl IGlmIHdlIGp1c3QgZXhwYW5kIHRoZSByZWZlcmVuY2Ugd2l0aCBpdHMgdGl0bGUuDQpIb3cgYWJv dXQgdGhlIGZvbGxvd2luZyBjaGFuZ2U6DQpPTEQgVEVYVDoNCiINCiBmb2xsb3dpbmcgUlRDUCBn dWlkZWxpbmVzDQogICBlc3RhYmxpc2hlZCBpbiBSRkM1OTY4Lg0KIg0KTkVXIFRFWFQ6DQoiDQpm b2xsb3dpbmcgIkd1aWRlbGluZXMgZm9yIEV4dGVuZGluZyB0aGUgUlRQIENvbnRyb2wgUHJvdG9j b2wgKFJUQ1ApIiAoUkZDNTk2OCkuDQoiDQoNCjIuIFNlY3Rpb24gMToNClRoZSBvYmplY3RpdmUg b2YgdGhpcyBkb2N1bWVudCBpcyB0byBkZWZpbmUgYW4gZXh0ZW5zaWJsZSBSVFANCiAgIG1vbml0 b3JpbmcgZnJhbWV3b3JrIHRvIHByb3ZpZGUgYSBzbWFsbCBudW1iZXIgb2YgcmUtdXNhYmxlIFF1 YWxpdHkNCiAgIG9mIFNlcnZpY2UgKFFvUykvUW9FIG1ldHJpY3Mgd2hpY2ggZmFjaWxpdGF0ZSBy ZWR1Y2VkIGltcGxlbWVudGF0aW9uDQogICBjb3N0cyBhbmQgaGVscCBtYXhpbWl6ZSBpbnRlci1v cGVyYWJpbGl0eS4NCg0KV2hhdCBJIHJlYWN0ZWQgdG8gaW4gdGhlIGFib3ZlIHNlbnRlbmNlIGlz ICJkZWZpbmUiIHdoaWNoIGkgdGhpbmsgc2hvdWxkDQpiZSBjaGFuZ2VkIHRvIGRlc2NyaWJlLCBk aXNjdXNzIG9yIHJldmlldy4NCg0KW1Fpbl06IE9rYXksIHdpbGwgdXNlICJkZXNjcmliZSIuDQoN CjMuIFNlY3Rpb24gNS40Og0KICBUaGlzIG1lbW8gcHJvcG9zZXMgdG8NCiAgIGRlZmluZSBhIG5l dyBYUiBCbG9jayAoaS5lLiwgdGhlIE1lYXN1cmVtZW50IGluZm9ybWF0aW9uIGJsb2NrDQogICBb TUVBU0ldKSB0aGF0IHdpbGwgYmUgdXNlZCB0byBjb252ZXkgdGhlIGNvbW1vbiB0aW1lIHBlcmlv ZCBhbmQgdGhlDQogICBudW1iZXIgb2YgcGFja2V0cyBzZW50IGR1cmluZyB0aGlzIHBlcmlvZC4N Cg0KQ29uc2lkZXJpbmcgdGhhdCB0aGUgcmVmZXJlbmNlIGlzIGluIElFU0cgZXZhbHVhdGlvbiwg c2hvdWxkbid0YQ0KZGlmZmVyZW50IHdvcmQgdGhhbiAicHJvcG9zZXMiIHRvIHBvaW50IHRvIHRo aXMgcmVmZXJlbmNlLiBJIHRoaW5rIHlvdQ0KbWlnaHQgc2ltcGx5IHN0YXRlIHNvbWV0aGluZyBs aWtlLg0KDQoNCiJNZWFzdXJlbWVudCBJZGVudGl0eSBhbmQgaW5mb3JtYXRpb24gUmVwb3J0aW5n IHVzaW5nIFNERVMgaXRlbSBhbmQgWFINCkJsb2NrIiBbTUVBU0ldIGVuYWJsZXMgYW4gUlRDUCBz ZW5kZXIgdG8gY29udmV5IHRoZSBjb21tb24gdGltZSBwZXJpb2QNCmFuZCB0aGUgbnVtYmVyIG9m IHBhY2tldHMgc2VudCBkdXJpbmcgdGhpcyBwZXJpb2QuDQoNCltRaW5dOiBSZWFzb25hYmxlLCB0 aGFuayBmb3IgeW91ciBwcm9wb3NlZCBjaGFuZ2UuDQoNCkNoZWVycw0KDQpNYWdudXMNCg0KDQoN Cg0KT24gMjAxMi0wNi0yMCAwMzo1MCwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0K PiANCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUg SW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRl bSBvZiB0aGUgQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UgV29ya2luZyBH cm91cCBvZiB0aGUgSUVURi4NCj4gDQo+IFRpdGxlICAgICAgICAgICA6IEd1aWRlbGluZXMgZm9y IFVzZSBvZiB0aGUgUlRQIE1vbml0b3JpbmcgRnJhbWV3b3JrDQo+IEF1dGhvcihzKSAgICAgICA6 IFFpbiBXdQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEdlb2ZmIEh1bnQNCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICBQaGlsaXAgQXJkZW4NCj4gRmlsZW5hbWUgICAgICAgIDogZHJh ZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTYudHh0DQo+IFBhZ2VzICAgICAgICAgICA6IDI4DQo+ IERhdGUgICAgICAgICAgICA6IDIwMTItMDYtMTkNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlz IG1lbW8gcHJvcG9zZXMgYW4gZXh0ZW5zaWJsZSBSVFAgbW9uaXRvcmluZyBmcmFtZXdvcmsgZm9y DQo+ICAgIGV4dGVuZGluZyBSVFAgQ29udHJvbCBQcm90b2NvbCAoUlRDUCkgd2l0aCBhIG5ldyBS VENQIEV4dGVuZGVkDQo+ICAgIFJlcG9ydHMgKFhSKSAoUkZDMzYxMSkgYmxvY2sgdHlwZSB0byBy ZXBvcnQgbmV3IG1ldHJpY3MgcmVnYXJkaW5nDQo+ICAgIG1lZGlhIHRyYW5zbWlzc2lvbiBvciBy ZWNlcHRpb24gcXVhbGl0eSwgZm9sbG93aW5nIFJUQ1AgZ3VpZGVsaW5lcw0KPiAgICBlc3RhYmxp c2hlZCBpbiBSRkM1OTY4LiAgVGhpcyBtZW1vIHN1Z2dlc3RzIHRoYXQgYSBuZXcgYmxvY2sgc2hv dWxkDQo+ICAgIGNvbnRhaW4gYSBzaW5nbGUgbWV0cmljIG9yIGEgc21hbGwgbnVtYmVyIG9mIG1l dHJpY3MgcmVsZXZhbnQgdG8gYQ0KPiAgICBzaW5nbGUgcGFyYW1ldGVyIG9mIGludGVyZXN0IG9y IGNvbmNlcm4sIHJhdGhlciB0aGFuIGNvbnRhaW5pbmcgYQ0KPiAgICBudW1iZXIgb2YgbWV0cmlj cyB3aGljaCBhdHRlbXB0IHRvIHByb3ZpZGUgZnVsbCBjb3ZlcmFnZSBvZiBhbGwgdGhvc2UNCj4g ICAgcGFyYW1ldGVycyBvZiBjb25jZXJuIHRvIGEgc3BlY2lmaWMgYXBwbGljYXRpb24uICBBcHBs aWNhdGlvbnMgbWF5DQo+ICAgIHRoZW4gIm1peCBhbmQgbWF0Y2giIHRvIGNyZWF0ZSBhIHNldCBv ZiBibG9ja3Mgd2hpY2ggY292ZXJzIHRoZWlyIHNldA0KPiAgICBvZiBjb25jZXJucy4gIFdoZXJl IHBvc3NpYmxlLCBhIHNwZWNpZmljIGJsb2NrIHNob3VsZCBiZSBkZXNpZ25lZCB0bw0KPiAgICBi ZSByZS11c2FibGUgYWNyb3NzIG1vcmUgdGhhbiBvbmUgYXBwbGljYXRpb24sIGZvciBleGFtcGxl LCBmb3IgYWxsDQo+ICAgIG9mIHZvaWNlLCBzdHJlYW1pbmcgYXVkaW8gYW5kIHZpZGVvLg0KPiAN Cj4gDQo+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlz Og0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWF2dGNvcmUt bW9uYXJjaA0KPiANCj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUg YXQ6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXZ0Y29yZS1tb25h cmNoLTE2DQo+IA0KPiBBIGRpZmYgZnJvbSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBh dDoNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWF2dGNv cmUtbW9uYXJjaC0xNg0KPiANCj4gDQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFi bGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy8NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQo+IGF2dEBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0KPiANCg0K DQotLSANCg0KTWFnbnVzIFdlc3Rlcmx1bmQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KTXVsdGltZWRpYSBU ZWNobm9sb2dpZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVBQi9UVk0NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkVy aWNzc29uIEFCICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQpG5HL2Z2F0 YW4gNiAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KU0UtMTY0IDgwIFN0 b2NraG9sbSwgU3dlZGVufCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0 From keith.drage@alcatel-lucent.com Wed Jun 20 03:51:18 2012 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 5175721F872A for ; Wed, 20 Jun 2012 03:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.929 X-Spam-Level: X-Spam-Status: No, score=-109.929 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 McKiuMNIrCzY for ; Wed, 20 Jun 2012 03:51:17 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id D282B21F861C for ; Wed, 20 Jun 2012 03:51:16 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q5KAnjLx022886 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Jun 2012 12:51:07 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 20 Jun 2012 12:50:48 +0200 From: "DRAGE, Keith (Keith)" To: Qin Wu , Magnus Westerlund , "avt@ietf.org" Date: Wed, 20 Jun 2012 12:50:46 +0200 Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-16.txt Thread-Index: Ac1OzJN0wtohA6phQFqHJCY8h5iVHAABP1dw Message-ID: References: <20120620015054.704.77202.idtracker@ietfa.amsl.com> <4FE19900.7000206@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-16.txt 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: Wed, 20 Jun 2012 10:51:18 -0000 > 1. Abstract: > > following RTCP guidelines > established in RFC5968. > > I wonder if this reference should be expanded with the title in the abstr= act. > > [Qin]: Okay, but the word "guidelines" may repeat twice in this=20 > sentence if we just expand the reference with its title. > How about the following change: > OLD TEXT: > " > following RTCP guidelines > established in RFC5968. > " > NEW TEXT: > " > following "Guidelines for Extending the RTP Control Protocol=20 > (RTCP)" (RFC5968). > " In my view we should avoid references in Abstracts completely. The abstract= stands alone, in many documents (e.g. the list of RFCs), without the refer= ence list.=20 In any case, the purpose of the abstract is to identify what the document d= oes, not how it does it, and this reference seems to be doing the latter.=20 Could I also suggest that we delete the word "suggests" from the abstract. = Either the document is instructing XRblock designers to do this or it is no= t. Regards Keith -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin W= u Sent: 20 June 2012 11:07 To: Magnus Westerlund; avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-16.txt From glenzorn@gmail.com Wed Jun 20 05:24:40 2012 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 ACC4A21F8549 for ; Wed, 20 Jun 2012 05:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 gaGIZgALrrQl for ; Wed, 20 Jun 2012 05:24:39 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C485421F86D4 for ; Wed, 20 Jun 2012 05:24:39 -0700 (PDT) Received: by dacx6 with SMTP id x6so9931956dac.31 for ; Wed, 20 Jun 2012 05:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:organization :date:message-id:mime-version:x-mailer; bh=WVHIxVDU64esPn+g1EGqzhamZoDzPVKutY6hlBnA1XI=; b=FMZ28uk6+4Jp73YSZpIwIMFzc8+B3OYNYzTBzm+plOEFx0JlyVtzL295uW8NAL9yAM Wb6QiTWYwaLvlB9M4o4MVQOM2lN2Kt/fgkoRyV+Bz3agd7rC08OOKhG5/RsQlnLBpCBQ p9rA47y3aG5fkg87UbYV8R0B6ZFP/U2AYaImlkSgHCAeEqbdTHsW97QI7cS+o71DaDr9 bzKtZLLaMkMHU6VGHfUOGy9hsPalOgPHJel2ywJ57n8k+XDYkv2ic+19GFF08Zbu6p4v V1kff+mKlKb4cq8+Br6H2hDKvGY8T0AMfTfSBQUKRv7HHV/BPLSYNZT4+fsvZfuWHiEB 05LQ== Received: by 10.68.135.201 with SMTP id pu9mr73462240pbb.146.1340195079390; Wed, 20 Jun 2012 05:24:39 -0700 (PDT) Received: from [192.168.1.99] (ppp-124-121-250-228.revip2.asianet.co.th. [124.121.250.228]) by mx.google.com with ESMTPS id os3sm3298432pbb.41.2012.06.20.05.24.37 (version=SSLv3 cipher=OTHER); Wed, 20 Jun 2012 05:24:38 -0700 (PDT) From: Glen Zorn To: avt@ietf.org In-Reply-To: References: <20120620015054.704.77202.idtracker@ietfa.amsl.com> <4FE19900.7000206@ericsson.com> Content-Type: multipart/alternative; boundary="=-SYMPBH9Wof8kLgkktBE4" Organization: Network Zen Date: Wed, 20 Jun 2012 19:24:35 +0700 Message-ID: <1340195075.24121.27.camel@gwz-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-16.txt 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: Wed, 20 Jun 2012 12:24:40 -0000 --=-SYMPBH9Wof8kLgkktBE4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2012-06-20 at 12:50 +0200, DRAGE, Keith (Keith) wrote: > > 1. Abstract: > > > > following RTCP guidelines > > established in RFC5968. > > > > I wonder if this reference should be expanded with the title in the abstract. It's not actually a reference citation, even though the misspelling makes it look like one; why not just change "RFC5968" to "RFC 5968"? > > > > [Qin]: Okay, but the word "guidelines" may repeat twice in this > > sentence if we just expand the reference with its title. > > How about the following change: > > OLD TEXT: > > " > > following RTCP guidelines > > established in RFC5968. > > " > > NEW TEXT: > > " > > following "Guidelines for Extending the RTP Control Protocol > > (RTCP)" (RFC5968). > > " > > In my view we should avoid references in Abstracts completely. I believe that to be the RFC Editor's view, as well, but again there is no reference involved. > The abstract stands alone, in many documents (e.g. the list of RFCs), without the reference list. > > In any case, the purpose of the abstract is to identify what the document does, not how it does it, and this reference seems to be doing the latter. I do think that the Abstract could use a re-write. > > Could I also suggest that we delete the word "suggests" from the abstract. Either the document is instructing XRblock designers to do this or it is not. Actually, since it's Informational, I'm not sure that it can instruct anybody to do anything. Maybe BCP would be a better intended status? > > Regards > > Keith > > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin Wu > Sent: 20 June 2012 11:07 > To: Magnus Westerlund; avt@ietf.org > Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-16.txt > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=-SYMPBH9Wof8kLgkktBE4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 2012-06-20 at 12:50 +0200, DRAGE, Keith (Keith) wrote: 
> 1. Abstract:
>
>  following RTCP guidelines
>    established in RFC5968.
>
> I wonder if this reference should be expanded with the title in the abstract.

It's not actually a reference citation, even though the misspelling makes it look like one; why not just change "RFC5968" to "RFC 5968"?

>
> [Qin]: Okay, but the word "guidelines" may repeat twice in this 
> sentence if we just expand the reference with its title.
> How about the following change:
> OLD TEXT:
> "
>  following RTCP guidelines
>    established in RFC5968.
> "
> NEW TEXT:
> "
> following "Guidelines for Extending the RTP Control Protocol 
> (RTCP)" (RFC5968).
> "

In my view we should avoid references in Abstracts completely.

I believe that to be the RFC Editor's view, as well, but again there is no reference involved.

The abstract stands alone, in many documents (e.g. the list of RFCs), without the reference list. 

In any case, the purpose of the abstract is to identify what the document does, not how it does it, and this reference seems to be doing the latter.

I do think that the Abstract could use a re-write.


Could I also suggest that we delete the word "suggests" from the abstract. Either the document is instructing XRblock designers to do this or it is not.

Actually, since it's Informational, I'm not sure that it can instruct anybody to do anything.  Maybe BCP would be a better intended status?


Regards

Keith


-----Original Message-----
From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin Wu
Sent: 20 June 2012 11:07
To: Magnus Westerlund; avt@ietf.org
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-16.txt

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

--=-SYMPBH9Wof8kLgkktBE4-- From magnus.westerlund@ericsson.com Wed Jun 20 06:03:07 2012 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 2EF1621F8750 for ; Wed, 20 Jun 2012 06:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.206 X-Spam-Level: X-Spam-Status: No, score=-106.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 GpA5mlSn41rH for ; Wed, 20 Jun 2012 06:03:06 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5F08421F873D for ; Wed, 20 Jun 2012 06:02:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-75-4fe1ca01a470 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D9.4A.28636.10AC1EF4; Wed, 20 Jun 2012 15:02:57 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Wed, 20 Jun 2012 15:02:57 +0200 Message-ID: <4FE1CA00.7070507@ericsson.com> Date: Wed, 20 Jun 2012 15:02:56 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <20120620015054.704.77202.idtracker@ietfa.amsl.com> <4FE19900.7000206@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUyM+JvrS7jqYf+Bh8bFCxe9qxkt3g8dwGr xdPGs4wOzB6tz/ayerQcecvqsWTJT6YA5igum5TUnMyy1CJ9uwSujN8fd7IXzOWv2H50JnsD 42KeLkZODgkBE4kH7R+YIGwxiQv31rN1MXJxCAmcYpTYfnoBC0hCSGA5o8SVVW4gNq+AtsSV x6/AGlgEVCXmz/7MCGKzCVhI3PzRyAZiiwoES0ybfo8dol5Q4uTMJ2BzRASsJV493gJWwyxg J/HuTw8ziC0s4CJx5sR5JojFTxklJs37ADaUUyBO4sOk84wQ10lK3GtfDdWsJzHlagsjhC0v 0bx1NjPEodoSDU0drBMYhWYh2T0LScssJC0LGJlXMQrnJmbmpJcb6qUWZSYXF+fn6RWnbmIE BvbBLb91dzCeOidyiFGag0VJnJcrab+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsZcjtC2 1W6JbVckHya/TV2dfFet5+vipw/Cl2rP7Hxos9varrbPIU4guYthWaJQVKtDosuftSp7Q1fx cDq+uFmurJTvbmBlyKI/2bnPdb559dXCldG74g7/m7qytNprbczlfZlLtLdfOsxsHOChNiXy 9L37s+KkDhYHOukty1ze3Xz44dL7XEosxRmJhlrMRcWJALdu3Wg6AgAA Cc: "avt@ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-16.txt 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: Wed, 20 Jun 2012 13:03:07 -0000 On 2012-06-20 12:50, DRAGE, Keith (Keith) wrote: >> 1. Abstract: >> >> following RTCP guidelines established in RFC5968. >> >> I wonder if this reference should be expanded with the title in the >> abstract. >> >> [Qin]: Okay, but the word "guidelines" may repeat twice in this >> sentence if we just expand the reference with its title. How about >> the following change: OLD TEXT: " following RTCP guidelines >> established in RFC5968. " NEW TEXT: " following "Guidelines for >> Extending the RTP Control Protocol (RTCP)" (RFC5968). " > > In my view we should avoid references in Abstracts completely. The > abstract stands alone, in many documents (e.g. the list of RFCs), > without the reference list. > > In any case, the purpose of the abstract is to identify what the > document does, not how it does it, and this reference seems to be > doing the latter. > > Could I also suggest that we delete the word "suggests" from the > abstract. Either the document is instructing XRblock designers to do > this or it is not. > The ID guidelines (http://www.ietf.org/id-info/guidelines.html) says the following under 6. Formating: An Abstract should be complete in itself, so it should contain no citations unless they are completely defined within the Abstract. It might be equally simple to drop the whole sub-phrase "following RTCP guidelines established in RFC5968." as it isn't the most relevant for an abstract. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From bill.wu@huawei.com Wed Jun 20 06:47:06 2012 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 1A85821F8678 for ; Wed, 20 Jun 2012 06:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[AWL=-3.581, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 McZ0ibjMr2JT for ; Wed, 20 Jun 2012 06:47:05 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1D70421F866D for ; Wed, 20 Jun 2012 06:47:05 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHI87802; Wed, 20 Jun 2012 09:47:04 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 20 Jun 2012 06:45:22 -0700 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 20 Jun 2012 06:45:25 -0700 Received: from SZXEML523-MBS.china.huawei.com ([169.254.6.41]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 20 Jun 2012 21:45:19 +0800 From: Qin Wu To: "DRAGE, Keith (Keith)" , Magnus Westerlund , "avt@ietf.org" Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-16.txt Thread-Index: Ac1OzJN0HPgDEfxhv0uslG+gfPQ4pwABP1dwAAY8Ki0= Date: Wed, 20 Jun 2012 13:45:19 +0000 Message-ID: References: <20120620015054.704.77202.idtracker@ietfa.amsl.com> <4FE19900.7000206@ericsson.com> , In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.46] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [AVTCORE] =?gb2312?b?tPC4tDogIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYXZ0?= =?gb2312?b?Y29yZS1tb25hcmNoLTE2LnR4dA==?= 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: Wed, 20 Jun 2012 13:47:06 -0000 SGksS2VpdGg6DQpUaGFuayBmb3IgeW91ciBjb21tZW50cywgcGxlYXNlIHNlZSBteSByZXBsaWVz IGlubGluZS4NCg0KUmVnYXJkcyENCi1RaW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCreivP7IyzogRFJBR0UsIEtlaXRoIChLZWl0aCkgW2tlaXRoLmRyYWdlQGFs Y2F0ZWwtbHVjZW50LmNvbV0NCreiy83KsbzkOiAyMDEyxOo21MIyMMjVIDE4OjUwDQq1vTogUWlu IFd1OyBNYWdudXMgV2VzdGVybHVuZDsgYXZ0QGlldGYub3JnDQrW98ziOiBSRTogW0FWVENPUkVd IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTE2LnR4dA0KDQo+IDEuIEFi c3RyYWN0Og0KPg0KPiAgZm9sbG93aW5nIFJUQ1AgZ3VpZGVsaW5lcw0KPiAgICBlc3RhYmxpc2hl ZCBpbiBSRkM1OTY4Lg0KPg0KPiBJIHdvbmRlciBpZiB0aGlzIHJlZmVyZW5jZSBzaG91bGQgYmUg ZXhwYW5kZWQgd2l0aCB0aGUgdGl0bGUgaW4gdGhlIGFic3RyYWN0Lg0KPg0KPiBbUWluXTogT2th eSwgYnV0IHRoZSB3b3JkICJndWlkZWxpbmVzIiBtYXkgcmVwZWF0IHR3aWNlIGluIHRoaXMNCj4g c2VudGVuY2UgaWYgd2UganVzdCBleHBhbmQgdGhlIHJlZmVyZW5jZSB3aXRoIGl0cyB0aXRsZS4N Cj4gSG93IGFib3V0IHRoZSBmb2xsb3dpbmcgY2hhbmdlOg0KPiBPTEQgVEVYVDoNCj4gIg0KPiAg Zm9sbG93aW5nIFJUQ1AgZ3VpZGVsaW5lcw0KPiAgICBlc3RhYmxpc2hlZCBpbiBSRkM1OTY4Lg0K PiAiDQo+IE5FVyBURVhUOg0KPiAiDQo+IGZvbGxvd2luZyAiR3VpZGVsaW5lcyBmb3IgRXh0ZW5k aW5nIHRoZSBSVFAgQ29udHJvbCBQcm90b2NvbA0KPiAoUlRDUCkiIChSRkM1OTY4KS4NCj4gIg0K DQpJbiBteSB2aWV3IHdlIHNob3VsZCBhdm9pZCByZWZlcmVuY2VzIGluIEFic3RyYWN0cyBjb21w bGV0ZWx5LiBUaGUgYWJzdHJhY3Qgc3RhbmRzIGFsb25lLCBpbiBtYW55IGRvY3VtZW50cyAoZS5n LiB0aGUgbGlzdCBvZiBSRkNzKSwgd2l0aG91dCB0aGUgcmVmZXJlbmNlIGxpc3QuDQoNCkluIGFu eSBjYXNlLCB0aGUgcHVycG9zZSBvZiB0aGUgYWJzdHJhY3QgaXMgdG8gaWRlbnRpZnkgd2hhdCB0 aGUgZG9jdW1lbnQgZG9lcywgbm90IGhvdyBpdCBkb2VzIGl0LCBhbmQgdGhpcyByZWZlcmVuY2Ug c2VlbXMgdG8gYmUgZG9pbmcgdGhlIGxhdHRlci4NCg0KW1Fpbl06IE9rYXksIEkgbGlrZSB0byBy ZW1vdmUgdGhpcyBzZW50ZW5jZSB0byBtYWtlIGFic3RyYWN0IHN0YW5kYWxvbmUuDQoNCkNvdWxk IEkgYWxzbyBzdWdnZXN0IHRoYXQgd2UgZGVsZXRlIHRoZSB3b3JkICJzdWdnZXN0cyIgZnJvbSB0 aGUgYWJzdHJhY3QuIEVpdGhlciB0aGUgZG9jdW1lbnQgaXMgaW5zdHJ1Y3RpbmcgWFJibG9jayBk ZXNpZ25lcnMgdG8gZG8gdGhpcyBvciBpdCBpcyBub3QuDQoNCltRaW5dOiBPa2F5LCBJIGxpa2Ug dG8gcmVtb3ZlICJUaGlzIG1lbW8gc3VnZ2VzdHMgdGhhdCAiIGZyb20gdGhlIHJlbGF0ZWQgc2Vu dGVuY2UgaW4gdGhlIGFic3RyYWN0Lg0KDQpSZWdhcmRzDQoNCktlaXRoDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGF2dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXZ0 LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBRaW4gV3UNClNlbnQ6IDIwIEp1bmUgMjAx MiAxMTowNw0KVG86IE1hZ251cyBXZXN0ZXJsdW5kOyBhdnRAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbQVZUQ09SRV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTYudHh0 DQoNCg== From bill.wu@huawei.com Wed Jun 20 06:48:26 2012 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 106A521F8633 for ; Wed, 20 Jun 2012 06:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.982 X-Spam-Level: X-Spam-Status: No, score=-4.982 tagged_above=-999 required=5 tests=[AWL=1.165, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] 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 bu-JQCbBphQQ for ; Wed, 20 Jun 2012 06:48:25 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E5B1121F86C2 for ; Wed, 20 Jun 2012 06:48:24 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHI87907; Wed, 20 Jun 2012 09:48:24 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 20 Jun 2012 06:46:08 -0700 Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 20 Jun 2012 06:46:06 -0700 Received: from SZXEML523-MBS.china.huawei.com ([169.254.6.41]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 20 Jun 2012 21:46:03 +0800 From: Qin Wu To: Magnus Westerlund , "DRAGE, Keith (Keith)" Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-16.txt Thread-Index: Ac1OzJN0HPgDEfxhv0uslG+gfPQ4pwABP1dw//+gxwCAAJICoQ== Date: Wed, 20 Jun 2012 13:46:03 +0000 Message-ID: References: <20120620015054.704.77202.idtracker@ietfa.amsl.com> <4FE19900.7000206@ericsson.com> , <4FE1CA00.7070507@ericsson.com> In-Reply-To: <4FE1CA00.7070507@ericsson.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "avt@ietf.org" Subject: [AVTCORE] =?utf-8?b?562U5aSNOiAgSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1h?= =?utf-8?q?vtcore-monarch-16=2Etxt?= 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: Wed, 20 Jun 2012 13:48:26 -0000 SGksDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQrlj5Hku7bkuro6 IE1hZ251cyBXZXN0ZXJsdW5kIFttYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb21dDQrlj5Hp gIHml7bpl7Q6IDIwMTLlubQ25pyIMjDml6UgMjE6MDINCuWIsDogRFJBR0UsIEtlaXRoIChLZWl0 aCkNCkNjOiBRaW4gV3U7IGF2dEBpZXRmLm9yZw0K5Li76aKYOiBSZTogW0FWVENPUkVdIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTE2LnR4dA0KDQpPbiAyMDEyLTA2LTIw IDEyOjUwLCBEUkFHRSwgS2VpdGggKEtlaXRoKSB3cm90ZToNCj4+IDEuIEFic3RyYWN0Og0KPj4N Cj4+IGZvbGxvd2luZyBSVENQIGd1aWRlbGluZXMgZXN0YWJsaXNoZWQgaW4gUkZDNTk2OC4NCj4+ DQo+PiBJIHdvbmRlciBpZiB0aGlzIHJlZmVyZW5jZSBzaG91bGQgYmUgZXhwYW5kZWQgd2l0aCB0 aGUgdGl0bGUgaW4gdGhlDQo+PiBhYnN0cmFjdC4NCj4+DQo+PiBbUWluXTogT2theSwgYnV0IHRo ZSB3b3JkICJndWlkZWxpbmVzIiBtYXkgcmVwZWF0IHR3aWNlIGluIHRoaXMNCj4+IHNlbnRlbmNl IGlmIHdlIGp1c3QgZXhwYW5kIHRoZSByZWZlcmVuY2Ugd2l0aCBpdHMgdGl0bGUuIEhvdyBhYm91 dA0KPj4gdGhlIGZvbGxvd2luZyBjaGFuZ2U6IE9MRCBURVhUOiAiIGZvbGxvd2luZyBSVENQIGd1 aWRlbGluZXMNCj4+IGVzdGFibGlzaGVkIGluIFJGQzU5NjguICIgTkVXIFRFWFQ6ICIgZm9sbG93 aW5nICJHdWlkZWxpbmVzIGZvcg0KPj4gRXh0ZW5kaW5nIHRoZSBSVFAgQ29udHJvbCBQcm90b2Nv bCAoUlRDUCkiIChSRkM1OTY4KS4gIg0KPg0KPiBJbiBteSB2aWV3IHdlIHNob3VsZCBhdm9pZCBy ZWZlcmVuY2VzIGluIEFic3RyYWN0cyBjb21wbGV0ZWx5LiBUaGUNCj4gYWJzdHJhY3Qgc3RhbmRz IGFsb25lLCBpbiBtYW55IGRvY3VtZW50cyAoZS5nLiB0aGUgbGlzdCBvZiBSRkNzKSwNCj4gd2l0 aG91dCB0aGUgcmVmZXJlbmNlIGxpc3QuDQo+DQo+IEluIGFueSBjYXNlLCB0aGUgcHVycG9zZSBv ZiB0aGUgYWJzdHJhY3QgaXMgdG8gaWRlbnRpZnkgd2hhdCB0aGUNCj4gZG9jdW1lbnQgZG9lcywg bm90IGhvdyBpdCBkb2VzIGl0LCBhbmQgdGhpcyByZWZlcmVuY2Ugc2VlbXMgdG8gYmUNCj4gZG9p bmcgdGhlIGxhdHRlci4NCj4NCj4gQ291bGQgSSBhbHNvIHN1Z2dlc3QgdGhhdCB3ZSBkZWxldGUg dGhlIHdvcmQgInN1Z2dlc3RzIiBmcm9tIHRoZQ0KPiBhYnN0cmFjdC4gRWl0aGVyIHRoZSBkb2N1 bWVudCBpcyBpbnN0cnVjdGluZyBYUmJsb2NrIGRlc2lnbmVycyB0byBkbw0KPiB0aGlzIG9yIGl0 IGlzIG5vdC4NCj4NCg0KDQpUaGUgSUQgZ3VpZGVsaW5lcyAoaHR0cDovL3d3dy5pZXRmLm9yZy9p ZC1pbmZvL2d1aWRlbGluZXMuaHRtbCkgc2F5cyB0aGUNCmZvbGxvd2luZyB1bmRlciA2LiBGb3Jt YXRpbmc6DQoNCkFuIEFic3RyYWN0IHNob3VsZCBiZSBjb21wbGV0ZSBpbiBpdHNlbGYsIHNvIGl0 IHNob3VsZCBjb250YWluIG5vDQpjaXRhdGlvbnMgdW5sZXNzIHRoZXkgYXJlIGNvbXBsZXRlbHkg ZGVmaW5lZCB3aXRoaW4gdGhlIEFic3RyYWN0Lg0KDQpJdCBtaWdodCBiZSBlcXVhbGx5IHNpbXBs ZSB0byBkcm9wIHRoZSB3aG9sZSBzdWItcGhyYXNlICJmb2xsb3dpbmcgUlRDUA0KZ3VpZGVsaW5l cyAgICBlc3RhYmxpc2hlZCBpbiBSRkM1OTY4LiIgYXMgaXQgaXNuJ3QgdGhlIG1vc3QgcmVsZXZh bnQgZm9yDQphbiBhYnN0cmFjdC4NCg0KW1Fpbl06IExvb2tzIGdvb2QgdG8gbWUsIHRoYW5rIGZv ciB5b3VyIHN1Z2dlc3Rpb24uDQoNCkNoZWVycw0KDQpNYWdudXMgV2VzdGVybHVuZA0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpNdWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFC L1RWTQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgfCBQaG9uZSAg KzQ2IDEwIDcxNDgyODcNCkbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2 IDczIDA5NDkwNzkNClNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMu d2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCg== From bill.wu@huawei.com Wed Jun 20 07:06:01 2012 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 761A721F863E for ; Wed, 20 Jun 2012 07:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.814 X-Spam-Level: X-Spam-Status: No, score=-0.814 tagged_above=-999 required=5 tests=[AWL=-3.263, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 9B3JYmj5xodW for ; Wed, 20 Jun 2012 07:06:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 221A521F85BB for ; Wed, 20 Jun 2012 07:06:00 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHI89089; Wed, 20 Jun 2012 10:05:50 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 20 Jun 2012 07:04:15 -0700 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 20 Jun 2012 07:04:13 -0700 Received: from SZXEML523-MBS.china.huawei.com ([169.254.6.41]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 20 Jun 2012 22:04:08 +0800 From: Qin Wu To: Glen Zorn , "avt@ietf.org" , "magnus.westerlund@ericsson.com" Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-16.txt Thread-Index: Ac1OzJN0HPgDEfxhv0uslG+gfPQ4pwABP1dw//+WEICAAJ5Ysg== Date: Wed, 20 Jun 2012 14:04:07 +0000 Message-ID: References: <20120620015054.704.77202.idtracker@ietfa.amsl.com> <4FE19900.7000206@ericsson.com> , <1340195075.24121.27.camel@gwz-laptop> In-Reply-To: <1340195075.24121.27.camel@gwz-laptop> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.46] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [AVTCORE] =?gb2312?b?tPC4tDogIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYXZ0?= =?gb2312?b?Y29yZS1tb25hcmNoLTE2LnR4dA==?= 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: Wed, 20 Jun 2012 14:06:01 -0000 SGksR2xlbiBhbmQgYWxsOg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kt6K8/sjLOiBhdnQtYm91bmNlc0BpZXRmLm9yZyBbYXZ0LWJvdW5jZXNAaWV0Zi5vcmddILT6 se0gR2xlbiBab3JuIFtnbGVuem9ybkBnbWFpbC5jb21dDQq3osvNyrG85DogMjAxMsTqNtTCMjDI 1SAyMDoyNA0Ktb06IGF2dEBpZXRmLm9yZw0K1vfM4jogUmU6IFtBVlRDT1JFXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0xNi50eHQNCg0KT24gV2VkLCAyMDEyLTA2LTIw IGF0IDEyOjUwICswMjAwLCBEUkFHRSwgS2VpdGggKEtlaXRoKSB3cm90ZToNCg0KDQo+IDEuIEFi c3RyYWN0Og0KPg0KPiAgZm9sbG93aW5nIFJUQ1AgZ3VpZGVsaW5lcw0KPiAgICBlc3RhYmxpc2hl ZCBpbiBSRkM1OTY4Lg0KPg0KPiBJIHdvbmRlciBpZiB0aGlzIHJlZmVyZW5jZSBzaG91bGQgYmUg ZXhwYW5kZWQgd2l0aCB0aGUgdGl0bGUgaW4gdGhlIGFic3RyYWN0Lg0KDQoNCkl0J3Mgbm90IGFj dHVhbGx5IGEgcmVmZXJlbmNlIGNpdGF0aW9uLCBldmVuIHRob3VnaCB0aGUgbWlzc3BlbGxpbmcg bWFrZXMgaXQgbG9vayBsaWtlIG9uZTsgd2h5IG5vdCBqdXN0IGNoYW5nZSAiUkZDNTk2OCIgdG8g IlJGQyA1OTY4Ij8NCg0KDQpbUWluXTogWW91ciBhcmUgcmlnaHQsIGJ1dCBpdCBsb29rcyB0byBt ZSBkZWxldGluZyB0aGUgc3ViLXNlbnRlbmNlICIgZm9sbG93aW5nIFJUQ1AgZ3VpZGVsaW5lcw0K ZXN0YWJsaXNoZWQgaW4gUkZDNTk2OCIgZnJvbSBhYnN0cmFjdCBpcyBub3QgYSBiaWcgZGVhbCBh bmQgZG9lcyBubyBoYXJtIHRvIHdoYXQgdGhlIGFic3RyYWN0IG1haW5seSB3YW50cyB0byBjb252 ZXkuDQo+DQo+IFtRaW5dOiBPa2F5LCBidXQgdGhlIHdvcmQgImd1aWRlbGluZXMiIG1heSByZXBl YXQgdHdpY2UgaW4gdGhpcw0KPiBzZW50ZW5jZSBpZiB3ZSBqdXN0IGV4cGFuZCB0aGUgcmVmZXJl bmNlIHdpdGggaXRzIHRpdGxlLg0KPiBIb3cgYWJvdXQgdGhlIGZvbGxvd2luZyBjaGFuZ2U6DQo+ IE9MRCBURVhUOg0KPiAiDQo+ICBmb2xsb3dpbmcgUlRDUCBndWlkZWxpbmVzDQo+ICAgIGVzdGFi bGlzaGVkIGluIFJGQzU5NjguDQo+ICINCj4gTkVXIFRFWFQ6DQo+ICINCj4gZm9sbG93aW5nICJH dWlkZWxpbmVzIGZvciBFeHRlbmRpbmcgdGhlIFJUUCBDb250cm9sIFByb3RvY29sDQo+IChSVENQ KSIgKFJGQzU5NjgpLg0KPiAiDQoNCkluIG15IHZpZXcgd2Ugc2hvdWxkIGF2b2lkIHJlZmVyZW5j ZXMgaW4gQWJzdHJhY3RzIGNvbXBsZXRlbHkuDQoNCg0KSSBiZWxpZXZlIHRoYXQgdG8gYmUgdGhl IFJGQyBFZGl0b3IncyB2aWV3LCBhcyB3ZWxsLCBidXQgYWdhaW4gdGhlcmUgaXMgbm8gcmVmZXJl bmNlIGludm9sdmVkLg0KDQpbUWluXTogT2theS4gDQoNClRoZSBhYnN0cmFjdCBzdGFuZHMgYWxv bmUsIGluIG1hbnkgZG9jdW1lbnRzIChlLmcuIHRoZSBsaXN0IG9mIFJGQ3MpLCB3aXRob3V0IHRo ZSByZWZlcmVuY2UgbGlzdC4NCg0KSW4gYW55IGNhc2UsIHRoZSBwdXJwb3NlIG9mIHRoZSBhYnN0 cmFjdCBpcyB0byBpZGVudGlmeSB3aGF0IHRoZSBkb2N1bWVudCBkb2VzLCBub3QgaG93IGl0IGRv ZXMgaXQsIGFuZCB0aGlzIHJlZmVyZW5jZSBzZWVtcyB0byBiZSBkb2luZyB0aGUgbGF0dGVyLg0K DQoNCkkgZG8gdGhpbmsgdGhhdCB0aGUgQWJzdHJhY3QgY291bGQgdXNlIGEgcmUtd3JpdGUuDQoN Cg0KW1Fpbl06T2theSxUaGFuayBmb3IgeW91ciBjbGFyaWZpY2F0aW9uLg0KDQpDb3VsZCBJIGFs c28gc3VnZ2VzdCB0aGF0IHdlIGRlbGV0ZSB0aGUgd29yZCAic3VnZ2VzdHMiIGZyb20gdGhlIGFi c3RyYWN0LiBFaXRoZXIgdGhlIGRvY3VtZW50IGlzIGluc3RydWN0aW5nIFhSYmxvY2sgZGVzaWdu ZXJzIHRvIGRvIHRoaXMgb3IgaXQgaXMgbm90Lg0KDQoNCkFjdHVhbGx5LCBzaW5jZSBpdCdzIElu Zm9ybWF0aW9uYWwsIEknbSBub3Qgc3VyZSB0aGF0IGl0IGNhbiBpbnN0cnVjdCBhbnlib2R5IHRv IGRvIGFueXRoaW5nLiAgTWF5YmUgQkNQIHdvdWxkIGJlIGEgYmV0dGVyIGludGVuZGVkIHN0YXR1 cz8NCg0KDQpbUWluXTpUaGF0J3MgYSBnb29kIHF1ZXN0aW9uLiBJIGRvbid0IGhhdmUgc3Ryb25n IG9waW5pb24gb24gd2hldGhlcnRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIEJDUA0Kb3IgaW5mb3Jt YXRpb25hbC4gU28gSSBsaWtlIHRvIGhlYXIgd2hhdCBvdXIgY2hhaXJzIGFuZCBvdGhlcnMgdGhp bmsgYWJvdXQgdGhpcy4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBh dnQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86YXZ0LWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86 YXZ0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBRaW4gV3UNClNlbnQ6IDIwIEp1bmUg MjAxMiAxMTowNw0KVG86IE1hZ251cyBXZXN0ZXJsdW5kOyBhdnRAaWV0Zi5vcmc8bWFpbHRvOmF2 dEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi1hdnRjb3JlLW1vbmFyY2gtMTYudHh0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5j ZQ0KYXZ0QGlldGYub3JnPG1haWx0bzphdnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0KDQoNCg== From ekr@rtfm.com Wed Jun 20 19:04:59 2012 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 5639911E80BE for ; Wed, 20 Jun 2012 19:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.324 X-Spam-Level: X-Spam-Status: No, score=-102.324 tagged_above=-999 required=5 tests=[AWL=0.653, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 NqHUQaQRplCk for ; Wed, 20 Jun 2012 19:04:58 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF4811E809F for ; Wed, 20 Jun 2012 19:04:58 -0700 (PDT) Received: by vcqp1 with SMTP id p1so67846vcq.31 for ; Wed, 20 Jun 2012 19:04:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=w++hkWRPtzX5a7jKBLG2JCIBGC7ektdolerYWB8lzn8=; b=C7pRvNQd6KiaKw+sYFW0W7/aXDGfuHGWIG9L6NQdvgPFa3qFUdTVBlWnE0iD+jglmO sgaJ5vg0HvRZFvIOT67yrngBkEZipfM1coFx+3D4XD4qf+qEsLSLVRS0UKSE8OVLfmUO /0n+USKyN/Nfxzmr4U81Aj9VwcnJFSz8l6QgNILebgDZ7U0FTt60aOqB3MDArhxVw1Af 4TsTFmWivSG9Ca4cSq7LtiZZ2C2ocorSXOQorwPqeWjgcg2b2nPUF2kEp5pg7KYJKmBx dbuZK3UCEUJmKGviLyrx2ImUH539/llepvzDkTrlckRHCcDxIbW/t/hb2slUOsiyM9Tp iczQ== Received: by 10.52.88.176 with SMTP id bh16mr10235565vdb.132.1340244298140; Wed, 20 Jun 2012 19:04:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Wed, 20 Jun 2012 19:04:17 -0700 (PDT) X-Originating-IP: [74.95.2.169] From: Eric Rescorla Date: Wed, 20 Jun 2012 19:04:17 -0700 Message-ID: To: avt@ietf.org, rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn4ltU2XiIB+TCkYEWLdC7sqGyM9Iof4W7VSvIqxaT6vIPV0vjcJ0S+BAMu2cI/7vtcZtNC Subject: [AVTCORE] Randomly-generated CNAMEs 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: Thu, 21 Jun 2012 02:04:59 -0000 RFC 6222 specifies two CNAME generation algorithms: - Persistent CNAMEs based on UUIDs - Short-term CNAMEs based on a digest of the MAC address and time of day. However, reading this document and the security considerations it seems like both methods produce CNAMEs which aren't unlinkable. Obviously the persistent CNAMEs are linkable, and it doesn't look like short-term CNAMEs have enough entropy to be unlinkable either. Specifically, the inputs are (Section 5): 1. The MAC address (or EUI-64) 2. The time of day (NTP-style) 3. Initial SSRC, and IP/port quartet (3) is known to the other side, (2) is at most 48-bits (and practically much less) and (2) is known to within a fairly narrow margin (and, it appears, communicated in the RTP timestamp). The upshot is that it seems likely that I can link two RTP sessions from the same person. Note that RFC 6222 doesn't say otherwise. Rather, it says: This document uses a hash function to ensure the uniqueness of RTCP CNAMEs. A cryptographic hash function is used because such functions provide the randomness properties that are needed. However, no security assumptions are made on the hash function. The hash function is not assumed to be collision resistant, preimage resistant, or second preimage resistant in an adversarial setting; as described above, an attacker attempting an impersonation attack could merely set the RTCP CNAME directly rather than attacking the hash function. Similarly, the hash function is not assumed to be a one- way function or pseudorandom in a cryptographic sense. For privacy reasons, it would be nice to be able to generate CNAMEs randomly so that they're not linkable. Unfortunately, 6222 seems to require that short-term credentials be generated via the above mechanism. Is there any reason why that shouldn't be allowed? -Ekr From ray.vanbrandenburg@tno.nl Thu Jun 21 02:48:59 2012 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 D60CB21F85C7 for ; Thu, 21 Jun 2012 02:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.155 X-Spam-Level: ** X-Spam-Status: No, score=2.155 tagged_above=-999 required=5 tests=[AWL=2.658, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] 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 BQ9+QaP0lISs for ; Thu, 21 Jun 2012 02:48:58 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9E021F8535 for ; Thu, 21 Jun 2012 02:48:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,450,1336341600"; d="scan'208,217";a="70978212" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 21 Jun 2012 11:48:55 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.199]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0298.004; Thu, 21 Jun 2012 11:48:55 +0200 From: "Brandenburg, R. (Ray) van" To: Christer Holmberg , Roni Even , "avt@ietf.org" Thread-Topic: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 Thread-Index: Ac1MouWNdp+K0jkOQUKLCbWCw+ddRAAtob1wAI5kWEA= Date: Thu, 21 Jun 2012 09:48:54 +0000 Message-ID: References: <4fde00ba.8854b40a.5854.12a4@mx.google.com> <7F2072F1E0DE894DA4B517B93C6A05853404689F19@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853404689F19@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581C607399EXCMBX03tsntnon_" MIME-Version: 1.0 Cc: "draft-ietf-avtcore-idms@tools.ietf.org" Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 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: Thu, 21 Jun 2012 09:49:00 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581C607399EXCMBX03tsntnon_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Christer, Thanks for your comments. We will include your suggestions in the next vers= ion of the draft. Regards, Ray From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: maandag 18 juni 2012 16:01 To: Roni Even; avt@ietf.org Cc: draft-ietf-avtcore-idms@tools.ietf.org Subject: RE: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 Hi, As the SDP rtcp-xr attribute is defined RFC 3611, I guess the offer/answer = aspects of that RFC apply also for the extension. If so, it would be good t= o mention that. However, as the SDP rtcp-idms attribute is defined in this document, you al= so need to define the offer/answer aspects. There is some text in section 1= 1, but the section name talks about "TISPAN compatibility". You should have= a section named "Offer/Answer", or something. Regards, Christer From: avt-bounces@ietf.org [mailto:avt-bounces= @ietf.org] On Behalf Of Roni Even Sent: 17. kes=E4kuuta 2012 19:05 To: avt@ietf.org Cc: draft-ietf-avtcore-idms@tools.ietf.org Subject: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtco= re-idms-05 , RTCP for inter-destination media synchronization. The WGLC will end on July 10th, 2012 Please review the draft and send comments to the list. For the draft authors; Are you aware of any IPR that applies to draft-ietf= -avtcore-idms-05? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 397= 9, 4879, 3669 and 5378 for more details)? The above question is needed for the document write-up when sent to publica= tion. Thanks Roni Even AVTcore co-chair This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1581C607399EXCMBX03tsntnon_ Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Christer,

 

Thanks = for your comments. We will include your suggestions in the next version of = the draft.

&n= bsp;

Regards= ,

&n= bsp;

Ray

&n= bsp;

From: Christer Holmberg [mailto:christer.holmberg@ericsson.= com]
Sent: maandag 18 juni 2012 16:01
To: Roni Even; avt@ietf.org
Cc: draft-ietf-avtcore-idms@tools.ietf.org
Subject: RE: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05=

 

Hi,

&n= bsp;

As the = SDP rtcp-xr attribute is defined RFC 3611, I guess the offer/answer aspects= of that RFC apply also for the extension. If so, it would be good to menti= on that.

&n= bsp;

However= , as the SDP rtcp-idms attribute is defined in this document, you also need= to define the offer/answer aspects. There is some text in section 11, but = the section name talks about “TISPAN compatibility”. You should have a section named “Offer/Answer”, or something.<= o:p>

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: 17. kes=E4kuuta 2012 19:05
To: avt@ietf.org
Cc: draft-= ietf-avtcore-idms@tools.ietf.org
Subject: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

 

Hi,

I would like to start a WGLC on http://tools.ietf.o=
rg/html/draft-ietf-avtcore-idms-05 , RT=
CP for inter-destination media synchronization.
 

The WGLC will end on July 10th, 20= 12

 

Please review the draft and sen= d comments to the list.

 

For the draft authors;  Are you aware=
 of any IPR that applies to draft-ietf-avtcore-idms-05? If so,
has this IPR been disclosed in compliance =
with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?<=
o:p>
The above question is needed for the docum=
ent write-up when sent to publication.
 

Thanks

 

Roni Even

AVTcore  co-chair

 

This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer

--_000_FCC100FC8D6B034CB88CD8173B2DA1581C607399EXCMBX03tsntnon_-- From csp@csperkins.org Thu Jun 21 03:22:07 2012 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 AA36221F84FA; Thu, 21 Jun 2012 03:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 cJDfnMyzNFbC; Thu, 21 Jun 2012 03:22:06 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by ietfa.amsl.com (Postfix) with ESMTP id B8B0021F84F0; Thu, 21 Jun 2012 03:22:06 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SheWb-0002Ch-YT; Thu, 21 Jun 2012 10:22:05 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Thu, 21 Jun 2012 11:22:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <075C431A-A103-4C7E-9D4A-F80CB97DD9FB@csperkins.org> References: To: Eric Rescorla X-Mailer: Apple Mail (2.1278) Cc: rtcweb@ietf.org, avt@ietf.org Subject: Re: [AVTCORE] Randomly-generated CNAMEs 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: Thu, 21 Jun 2012 10:22:07 -0000 Ekr, I'm not sure I understand what problem you're trying to solve: the point = of the CNAME is to allow different RTP sessions to be linked.=20 Colin On 21 Jun 2012, at 03:04, Eric Rescorla wrote: > RFC 6222 specifies two CNAME generation algorithms: >=20 > - Persistent CNAMEs based on UUIDs > - Short-term CNAMEs based on a digest of the MAC address and time of = day. >=20 > However, reading this document and the security considerations it = seems like both methods produce CNAMEs which aren't unlinkable. = Obviously the persistent CNAMEs are linkable, and it doesn't look like = short-term CNAMEs have enough entropy to be unlinkable either. = Specifically, the inputs are (Section 5): >=20 > 1. The MAC address (or EUI-64) > 2. The time of day (NTP-style) > 3. Initial SSRC, and IP/port quartet >=20 > (3) is known to the other side, (2) is at most 48-bits (and = practically much less) and (2) is known to within a fairly narrow margin = (and, it appears, communicated in the RTP timestamp). >=20 > The upshot is that it seems likely that I can link two RTP sessions = from the same person. Note that RFC 6222 doesn't say otherwise. Rather, = it says: >=20 > This document uses a hash function to ensure the uniqueness of RTCP > CNAMEs. A cryptographic hash function is used because such = functions > provide the randomness properties that are needed. However, no > security assumptions are made on the hash function. The hash > function is not assumed to be collision resistant, preimage > resistant, or second preimage resistant in an adversarial setting; = as > described above, an attacker attempting an impersonation attack = could > merely set the RTCP CNAME directly rather than attacking the hash > function. Similarly, the hash function is not assumed to be a one- > way function or pseudorandom in a cryptographic sense. >=20 > For privacy reasons, it would be nice to be able to generate CNAMEs = randomly so that they're not linkable. Unfortunately, 6222 seems to = require that short-term credentials be generated via the above = mechanism. Is there any reason why that shouldn't be allowed? >=20 > -Ekr > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From fluffy@iii.ca Thu Jun 21 05:39:45 2012 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 EDDF521F855E; Thu, 21 Jun 2012 05:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.224 X-Spam-Level: X-Spam-Status: No, score=-1.224 tagged_above=-999 required=5 tests=[AWL=1.375, BAYES_00=-2.599] 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 7FSwUAxJUTaS; Thu, 21 Jun 2012 05:39:44 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 051F221F855F; Thu, 21 Jun 2012 05:39:43 -0700 (PDT) Received: from rtp-vpn5-419.cisco.com (unknown [64.102.254.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6FD1622E1EB; Thu, 21 Jun 2012 08:39:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <075C431A-A103-4C7E-9D4A-F80CB97DD9FB@csperkins.org> Date: Thu, 21 Jun 2012 08:39:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <075C431A-A103-4C7E-9D4A-F80CB97DD9FB@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.1278) Cc: rtcweb@ietf.org, avt@ietf.org Subject: Re: [AVTCORE] Randomly-generated CNAMEs 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: Thu, 21 Jun 2012 12:39:45 -0000 One again, I think we have complete failure on the meaning of the word = session :-)=20 I think what EKR was getting at is that if A call B in one phone call, = then day later A wants to make an anonymous call to B, B should not be = able to tell the second call is coming from same devices. I think that = was part of the goal of 6222 but from EKR's email it looks like it fails = to provide that.=20 On Jun 21, 2012, at 6:22 , Colin Perkins wrote: > Ekr, >=20 > I'm not sure I understand what problem you're trying to solve: the = point of the CNAME is to allow different RTP sessions to be linked.=20 >=20 > Colin >=20 >=20 > On 21 Jun 2012, at 03:04, Eric Rescorla wrote: >> RFC 6222 specifies two CNAME generation algorithms: >>=20 >> - Persistent CNAMEs based on UUIDs >> - Short-term CNAMEs based on a digest of the MAC address and time of = day. >>=20 >> However, reading this document and the security considerations it = seems like both methods produce CNAMEs which aren't unlinkable. = Obviously the persistent CNAMEs are linkable, and it doesn't look like = short-term CNAMEs have enough entropy to be unlinkable either. = Specifically, the inputs are (Section 5): >>=20 >> 1. The MAC address (or EUI-64) >> 2. The time of day (NTP-style) >> 3. Initial SSRC, and IP/port quartet >>=20 >> (3) is known to the other side, (2) is at most 48-bits (and = practically much less) and (2) is known to within a fairly narrow margin = (and, it appears, communicated in the RTP timestamp). >>=20 >> The upshot is that it seems likely that I can link two RTP sessions = from the same person. Note that RFC 6222 doesn't say otherwise. Rather, = it says: >>=20 >> This document uses a hash function to ensure the uniqueness of RTCP >> CNAMEs. A cryptographic hash function is used because such = functions >> provide the randomness properties that are needed. However, no >> security assumptions are made on the hash function. The hash >> function is not assumed to be collision resistant, preimage >> resistant, or second preimage resistant in an adversarial setting; = as >> described above, an attacker attempting an impersonation attack = could >> merely set the RTCP CNAME directly rather than attacking the hash >> function. Similarly, the hash function is not assumed to be a one- >> way function or pseudorandom in a cryptographic sense. >>=20 >> For privacy reasons, it would be nice to be able to generate CNAMEs = randomly so that they're not linkable. Unfortunately, 6222 seems to = require that short-term credentials be generated via the above = mechanism. Is there any reason why that shouldn't be allowed? >>=20 >> -Ekr >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >=20 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From ekr@rtfm.com Thu Jun 21 05:48:54 2012 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 3EB7A21F8615 for ; Thu, 21 Jun 2012 05:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 C+eiaNkFCA3T for ; Thu, 21 Jun 2012 05:48:53 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 91E8621F8610 for ; Thu, 21 Jun 2012 05:48:53 -0700 (PDT) Received: by vcqp1 with SMTP id p1so334385vcq.31 for ; Thu, 21 Jun 2012 05:48:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=8u1gKmtKsDF5/s5R/GRmPakxPndTTkT4jVMfnaEt5To=; b=NJF5p25OrTk1A2QjEbHCYcdtqLVYmrWTaHHkkR2L3sH1Ez80iAcsgSVOM/w4mUUM+8 i8uuEbZX0rQhU3Yh8LWnfFQgmiLxa0P5wisJOB3wD9G+/M1haL7FQPWfsoGf2BUlLMM0 EEk2lhM2Jw7LdIVG77ntte6aDRkYOBU0RErDkUfi5RBq2vEPLevySITmwKRqMlcHTqiZ UmMUt0t9sJE6Q4NVDpnnAzyUqOK9ya8huCYk4QYrMCm9xK6gd4UsqMVmEz7SAatPWRJS Y1L3QeDgfSoR89H6EGzAjcqWiDeOELYKM1QA0//+vfk/mSbED1DoOiDCnku+u3XKgz40 WwAw== Received: by 10.220.141.209 with SMTP id n17mr13566421vcu.65.1340282933029; Thu, 21 Jun 2012 05:48:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Thu, 21 Jun 2012 05:48:12 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <075C431A-A103-4C7E-9D4A-F80CB97DD9FB@csperkins.org> From: Eric Rescorla Date: Thu, 21 Jun 2012 05:48:12 -0700 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkpQp6EvMSCzTnjqYSqwk/d2KpsKsLu9rQaMd3lwVlQt/P3MLAoVzFI+//UkEFWsdyOaKoj Cc: rtcweb@ietf.org, Colin Perkins , avt@ietf.org Subject: Re: [AVTCORE] Randomly-generated CNAMEs 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: Thu, 21 Jun 2012 12:48:54 -0000 On Thu, Jun 21, 2012 at 5:39 AM, Cullen Jennings wrote: > > One again, I think we have complete failure on the meaning of the word se= ssion :-) > > I think what EKR was getting at is that if A call B in one phone call, th= en day later A wants to make an anonymous call to B, B should not be able t= o tell the second call is coming from same devices. I think that was part o= f the goal of 6222 but from EKR's email it looks like it fails to provide t= hat. Exactly. -Ekr From magnus.westerlund@ericsson.com Thu Jun 21 06:52:36 2012 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 58B9721F8669 for ; Thu, 21 Jun 2012 06:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.912 X-Spam-Level: X-Spam-Status: No, score=-105.912 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, 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 jPEMCSLiS0UN for ; Thu, 21 Jun 2012 06:52:35 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5224A21F866B for ; Thu, 21 Jun 2012 06:52:34 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-e0-4fe327203016 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 57.9B.28636.02723EF4; Thu, 21 Jun 2012 15:52:32 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.0; Thu, 21 Jun 2012 15:52:32 +0200 Message-ID: <4FE3271F.7020506@ericsson.com> Date: Thu, 21 Jun 2012 15:52:31 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: avt@ietf.org, "draft-ietf-avtcore-idms@tools.ietf.org" References: <4fde00ba.8854b40a.5854.12a4@mx.google.com> In-Reply-To: <4fde00ba.8854b40a.5854.12a4@mx.google.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3VldB/bG/wdOV1hYve1ayWxzasYbR gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4Mq4f6G4YI5XReeSb4wNjN3WXYycHBICJhJ7 N+5ngbDFJC7cW8/WxcjFISRwilFi672Z7BDOckaJedtmsYJU8QpoS6zb/o8JxGYRUJVYc6qf HcRmE7CQuPmjkQ3EFhUIlpg2/R47RL2gxMmZT4A2cHCICKRJ/L4mBBIWFrCU+Hb2GNhiIQFz iavtl8FGcgKNOXfmKBPEQZIS99pXg41kFtCTmHK1hRHClpdo3jqbGaJXW6KhqYN1AqPgLCTb ZiFpmYWkZQEj8ypG4dzEzJz0ckO91KLM5OLi/Dy94tRNjMBAPbjlt+4OxlPnRA4xSnOwKInz ciXt9xcSSE8sSc1OTS1ILYovKs1JLT7EyMTBKQUMwjtTl8v47HwSZxnS0XBm6ddwzxnq+xeu tX72+XOzYM/mLO3Qn5PK5x6tkngmJDlnAuP6p7tjHP+XLCzZ0PLxx2nt2Fj+k7+PzN4+P+R8 of6mgPcvpnLJhJx/n/i8+JnkqiKuzPgDggFxR3TDs3Tl+mQK5Ox8Co6JuDpHXouKXj8rrEJZ u9tIiaU4I9FQi7moOBEAL5t0SCICAAA= Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 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: Thu, 21 Jun 2012 13:52:36 -0000 Hi, This is my WG last call review as an individual. I think there is quite a lot to address before this document is ready for publication request. 1. This document has 6 authors listed. This is one more than the policy allows: http://www.rfc-editor.org/policy.html#policy.authlist 2. Abstract: "This document gives information on an RTCP Packet Type and RTCP XR Block Type including associated SDP parameters for Inter-Destination Media Synchronization (IDMS)." Doesn't it define these packet/block types? 3. Section 3: The ladder diagrams first line is wrongly indented. 3. Section 3. Ladder diagram, maybe this diagram should have some handle, like figure 1 with a label. 4. Section 3. I am missing discussion on the overview level of clocks. Yes it is present later, but I think the topic should be introduced already here is section 3. 5. Section 6. I think this section should make it clear how an SC can include multiple report blocks for different received sources. In general I think this may be a topic that needs to be lifted into the overview. The issue I see is the following ones. a) Within a multi-party communication session different media senders include different reference clocks. Thus creating multiple synchronization groups within the context of one multi-media communication session. b) even if they can agree on using the same clock reference they still need to enable the fact that an end-point is acting as MSAS for some media sources and SC for others. This should be made more clear. 6. Section 6 appears to be a normative definition of RTCP XR block type 12. That block type is registered by IANA as belonging to ETSI 183 063 specification. Unless we have a formal liasion assigning the change right to IETF I don't see how we can make an updated normative specification of this XR block type. I see two options. a) IETF are given the change right over the block type b) IETF makes a normative reference to the ETSI specification of the block type and then simply makes it clear that they only uses SPST=1. 7. Section 6. Assuming that the normative definition will remain and possibly also as a clarification to the ETSI specification: This section is not making it sufficient clear that what an SC is supposed to do is to pick one RTP packet it recevied, then report the values for this particular packet. I think one should clarify this and also making it clearer what the selection criteria for such a packet is. Should one focus on using maximum delayed packets, media delayed packets or simply random selection? In addition we have the rules about picking packets when multiple RTP sequence numbers have the same TS value. I would recommned that one add some paragraphs before the actual figure definition to discuss this. 8. Section 6, PT field definition. This is not making clear that one shall report the PT of the packet one is reporting on. 9. Section 6. Media Stream Correlation Identifier: 32 bits. This identifier is used to correlate synchronized media streams. The value 0 (all bits are set "0") indicates that this field is empty. The value 2^32-1 (all bits are set "1") is reserved for future use. If the RTCP Packet Sender is an SC (SPST=1) or an MSAS (SPST=2), then the Media Stream Correlation Identifier maps on the Synchronization Group Identifier (SyncGroupId) to which the report applies. It is not clear what "maps" means here. Considering that the field appears to carry the full syncgroupID I think another formulation shall be used. 10. Section 6. "To solve this, an SC SHOULD report on RTP packets in which a certain RTP timestamp shows up for the first time." Does this means with the lowest sequence number or the packet first to arrive with that TS? 11. Section 7 Title "RTCP Packet Type for IDMS (IDMS report)" Why is the packet used to distribute the intended playout timing called a "report". This is very confusing considering that the XR is a report also. 12. Section 7. SSRC: 32 bits. The SSRC of the media source SHALL be set to the value of the SSRC identifier carried in the RTP header [RFC3550] of the RTP packet to which the RTCP IDMS packet relates. First of all I assume this field definition is for "SSRC of media source" field. a. What isn't clear is if it is at all valid that another SSRC "SSRC of packet sender" than the "SSRC of media source" is allowed and shall be considered valid. b. Secondly, when an end-point has multiple sources in the same RTP session to send it appears they need to send multiple RTCP packets. 13. Section 7. It is not clear if there are any restrictions on the values to be included in the RTCP packet. Must the sender of it include information for a already sent packet, a future packet or can it even be a virtual packet that is never sent? I understand that one can scale the figures in this packet to determine what the correct value should be given a received RTP packet and its timestamp. But, are I allowed to calculate a correct time value a year into the future that is then expected to be scaled back. Or is the RTP timestamp value included in the packet in itself an indication for when this information was current? 14. Section 8. [I-D.draft-williams-avtcore-clksrc] defines a set of SDP parameters for signaling the clock synchronization source or sources available to and used by the individual receivers. Using these paramenters, an SC can indicate which synchronization source is being used at the moment, the last time the SC synchronized with this source and the synchronization frequency. An SC can also indicate any other synchronization sources available to it. This allows multiple SCs in an IDMS session to use the same or a similar clock source for their session. So the clksrc draft appear to indended to define the usage of a=ssrc to make it clear which clock source a particular SSRC uses. What isn't clear from this text is that when providing reporting that all nodes sending a report or a configuration must use their view of that particular clock source. I think the implications of having multiple clock sources in an RTP session must be made clearer. As the used clock comes into play both when configuring, reporting and adjusting time scales for playout. 15. Section 9: SyncGroupId = 1*DIGIT ; Numerical value from 0 through 4294967294 As the syncgroupID is limited to 10 digits, why not make that clear in the ABNF also using 1*10DIGIT as the definition. Applies also to Section 10. 16. Section 11. As someone else noted. This section really needs to be split into Offer/Answer rules and one on TISPAN interop. 16. Section 11. Offer/Answer rules It is not clear how one deals with the potential existence of multiple sync groups or how the ID is negotiated. Especially when you in a multi-party negotiate with an application server. I also think it should make clear how it works in declarative cases, like RTSP SDPs. 17. Section 14. This IANA registration is insufficient. It needs to be more precise in which regestries that are to be used. To my understand the following actions are required: register a media level SDP attribute: This is okay considering the template but one could clarify that the registry intended is the one titled "att-field (media level only)" http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml#sdp-parameters-9 One RTCP Control Packet types (PT): http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml#rtp-parameters-3 And if the XR block type is to be normatively defined by this document then two registrations are needed: - New or update of RTCP XR Block Type http://www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr-block-types.xml - Add the XR SDP parameter: http://www.iana.org/assignments/rtcp-xr-sdp-parameters/rtcp-xr-sdp-parameters.xml 18. References. Should [I-D.draft-gross-leap-second] be normative? It is not written in a RFC 2119 style an requirement to take this document into account, so maybe informative is correct. Cheers Magnus On 2012-06-17 18:04, Roni Even wrote: > Hi, > > I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-idms-05 , RTCP for inter-destination media synchronization. > > > > The WGLC will end on July 10th, 2012 > > > > Please review the draft and send comments to the list. > > > > For the draft authors; Are you aware of any IPR that applies to draft-ietf-avtcore-idms-05? If so, > > has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > The above question is needed for the document write-up when sent to publication. > > > > Thanks > > > > Roni Even > > AVTcore co-chair > > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Thu Jun 21 14:12:45 2012 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 0A83221F86B7; Thu, 21 Jun 2012 14:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, 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 GDMugTPgPNRr; Thu, 21 Jun 2012 14:12:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742BE21F855A; Thu, 21 Jun 2012 14:12:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120621211244.19670.19456.idtracker@ietfa.amsl.com> Date: Thu, 21 Jun 2012 14:12:44 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-leap-second-00.txt 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: Thu, 21 Jun 2012 21:12:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : RTP and Leap Seconds Author(s) : Kevin Gross Ray van Brandenburg Filename : draft-ietf-avtcore-leap-second-00.txt Pages : 6 Date : 2012-06-21 Abstract: This document discusses issues that arise when RTP sessions span (UTC) leap seconds. It updates RFC 3550 to describe how RTP senders and receivers should behave in the presence of leap seconds. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-leap-second There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-leap-second-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From glenzorn@gmail.com Thu Jun 21 14:40:18 2012 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 0F69921F8630 for ; Thu, 21 Jun 2012 14:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 EKYRuuvaNgsq for ; Thu, 21 Jun 2012 14:40:17 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1063921F862F for ; Thu, 21 Jun 2012 14:40:17 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2733531pbc.31 for ; Thu, 21 Jun 2012 14:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:organization :date:message-id:mime-version:x-mailer; bh=fX29zjhCB/2/hYJqBq4/yONMxrY36GEN3tEsuxOpTbE=; b=B0WemgbKQWVmKVU7ggODexyvtQNyD3D90rZUZsdPrj1brT/kKalwun+JxEHyzB8lUN mKQlF6z2uwLTG3LFkDqzFAybUx9CcZApCGtcHUa7U0sCAGK+sVHVOlcMxpbFMCDrUk28 y4MMOEYxqWtS8TbfKDvkaP7aHu6+PYAqG2iTB3gKtLBOi8pNs7mrTu0+Faoj2gV0z5XV yJJ5jRRmr+cyxt++dobaGoIkhxg07yW/NFV90/zaBbXUbx8vornPPKqy2i6fqoRnzb+T 9XNOg/sZ1AOYRqW+eVXy/h7yzNYRTNt/ZtbXItBRve8TnMc6NIw7/U0e9UklACB5sbab xB3Q== Received: by 10.68.232.201 with SMTP id tq9mr3096660pbc.70.1340314816789; Thu, 21 Jun 2012 14:40:16 -0700 (PDT) Received: from [192.168.1.99] (ppp-124-120-58-182.revip2.asianet.co.th. [124.120.58.182]) by mx.google.com with ESMTPS id na10sm30352041pbc.23.2012.06.21.14.40.13 (version=SSLv3 cipher=OTHER); Thu, 21 Jun 2012 14:40:15 -0700 (PDT) From: Glen Zorn To: avt@ietf.org In-Reply-To: <4FE3271F.7020506@ericsson.com> References: <4fde00ba.8854b40a.5854.12a4@mx.google.com> <4FE3271F.7020506@ericsson.com> Content-Type: multipart/alternative; boundary="=-VOdAtEQGYfgaNARqrIIA" Organization: Network Zen Date: Fri, 22 Jun 2012 04:40:12 +0700 Message-ID: <1340314812.649.10.camel@gwz-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 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: Thu, 21 Jun 2012 21:40:18 -0000 --=-VOdAtEQGYfgaNARqrIIA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2012-06-21 at 15:52 +0200, Magnus Westerlund wrote: > Hi, > > This is my WG last call review as an individual. I think there is quite > a lot to address before this document is ready for publication request. > > 1. This document has 6 authors listed. This is one more than the policy > allows: > http://www.rfc-editor.org/policy.html#policy.authlist >From that document: "There is no rigid limit on the size of this set, but there is likely to be a discussion if the set exceeds five authors, in which case the right answer is probably to list one editor." It is perfectly reasonable to disagree with the final (arbitrary) statement, however; for example, in the case where a long-lived document has an equally long list of actual authors. Note also that the purpose of the policy is to both manage the size of the front page header and to discourage "corporate name-dropping". In this case, 6 authors is only marginally excessive; whether or not corporate name-dropping is involved is a question that can only be answered by the authors. ... --=-VOdAtEQGYfgaNARqrIIA Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 2012-06-21 at 15:52 +0200, Magnus Westerlund wrote: 
Hi,

This is my WG last call review as an individual. I think there is quite
a lot to address before this document is ready for publication request.

1. This document has 6 authors listed. This is one more than the policy
allows:
http://www.rfc-editor.org/policy.html#policy.authlist

>From that document: "There is no rigid limit on the size of this set, but there is likely to be a discussion if the set exceeds five authors, in which case the right answer is probably to list one editor."  It is perfectly reasonable to disagree with the final (arbitrary) statement, however; for example, in the case where a long-lived document has an equally long list of actual authors.  Note also that the purpose of the policy is to both manage the size of the front page header and to discourage "corporate name-dropping".  In this case, 6 authors is only marginally excessive; whether or not corporate name-dropping is involved is a question that can only be answered by the authors.

... --=-VOdAtEQGYfgaNARqrIIA-- From csp@csperkins.org Thu Jun 21 14:54:41 2012 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 F1EB621F8682; Thu, 21 Jun 2012 14:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 b-WJw2jRaWe0; Thu, 21 Jun 2012 14:54:40 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id E7EE021F8674; Thu, 21 Jun 2012 14:54:39 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.11]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1ShpKo-0004F2-bi; Thu, 21 Jun 2012 21:54:39 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Thu, 21 Jun 2012 22:54:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0114FC22-FAE9-491D-8E5B-97A38F7714E7@csperkins.org> References: <075C431A-A103-4C7E-9D4A-F80CB97DD9FB@csperkins.org> To: Martin Thomson X-Mailer: Apple Mail (2.1278) Cc: rtcweb@ietf.org, avt@ietf.org, Cullen Jennings Subject: Re: [AVTCORE] [rtcweb] Randomly-generated CNAMEs 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: Thu, 21 Jun 2012 21:54:41 -0000 On 21 Jun 2012, at 20:09, Martin Thomson wrote: > On 21 June 2012 05:48, Eric Rescorla wrote: >> On Thu, Jun 21, 2012 at 5:39 AM, Cullen Jennings = wrote: >>> I think what EKR was getting at is that if A call B in one phone = call, then day later A wants to make an anonymous call to B, B should = not be able to tell the second call is coming from same devices. I think = that was part of the goal of 6222 but from EKR's email it looks like it = fails to provide that. >>=20 >> Exactly. >=20 > I agree with the analysis. The idea that the same browser could be > correlated across two independent sessions bothers me. Within the one > "session", fine - on the contrary, mandatory. Outside of that, I'd > like at least an option for anonymity. Using SRTP to encrypt the traffic will stop third-parties correlating = the sessions, and RTCWeb is mandates SRTP and encryption. RFC 6222 does define per-session RTCP CNAME values, if you're concerned = about the called party being able to correlate sessions based on the = RTCP CNAME. We could mandate those instead of short-term persistent RTCP = CNAME values. If that's not sufficient, then someone will need to write = a draft that defines a new RTCP CNAME generation algorithm, which this = draft can refer to.=20 --=20 Colin Perkins http://csperkins.org/ From kevin.gross@avanw.com Thu Jun 21 15:04:01 2012 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 5F8CF11E8072 for ; Thu, 21 Jun 2012 15:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 gtpMr6feLUVm for ; Thu, 21 Jun 2012 15:04:00 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 7514C21F84FA for ; Thu, 21 Jun 2012 15:04:00 -0700 (PDT) Received: (qmail 23787 invoked by uid 0); 21 Jun 2012 22:03:59 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy8.bluehost.com with SMTP; 21 Jun 2012 22:03:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=cq4+KzcxFbjDLSp2wHk0ZsueEnn1hRduTwXWQEcOK34=; b=cOlALcOG76LgPSs29WOyRqcs1hXrdNwaUPFW3+lvdojdCrG5rLsY2k3iK/ihwOew1AceUyVmn/kR+Ermeo3zgpicNKd1RmnJmitwkmgQ7pIvOdrWibhdqECw0Rp+Jk3J; Received: from [74.125.82.44] (port=45939 helo=mail-wg0-f44.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1ShpTr-0003W6-Jt for avt@ietf.org; Thu, 21 Jun 2012 16:03:59 -0600 Received: by wgbdr13 with SMTP id dr13so753691wgb.13 for ; Thu, 21 Jun 2012 15:03:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.216 with SMTP id k66mr14375854wep.191.1340316238282; Thu, 21 Jun 2012 15:03:58 -0700 (PDT) Received: by 10.223.144.216 with HTTP; Thu, 21 Jun 2012 15:03:58 -0700 (PDT) In-Reply-To: <20120621211244.19670.19456.idtracker@ietfa.amsl.com> References: <20120621211244.19670.19456.idtracker@ietfa.amsl.com> Date: Thu, 21 Jun 2012 16:03:58 -0600 Message-ID: From: Kevin Gross To: avt@ietf.org Content-Type: multipart/alternative; boundary=00504502df4145013104c302b12c X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.44 authed with kevin.gross@avanw.com} Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-leap-second-00.txt 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: Thu, 21 Jun 2012 22:04:01 -0000 --00504502df4145013104c302b12c Content-Type: text/plain; charset=ISO-8859-1 Aside from submission as a milestone item, I have incorporated improvements suggested by Marshall Eubanks and Art Allison. I also cleaned up IDNITS. Kevin Gross On Thu, Jun 21, 2012 at 3:12 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Audio/Video Transport Core Maintenance > Working Group of the IETF. > > Title : RTP and Leap Seconds > Author(s) : Kevin Gross > Ray van Brandenburg > Filename : draft-ietf-avtcore-leap-second-00.txt > Pages : 6 > Date : 2012-06-21 > > Abstract: > This document discusses issues that arise when RTP sessions span > (UTC) leap seconds. It updates RFC 3550 to describe how RTP senders > and receivers should behave in the presence of leap seconds. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-leap-second > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-leap-second-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --00504502df4145013104c302b12c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Aside from submission as a milestone item, I have incorporated=A0improvemen= ts=A0suggested by Marshall Eubanks and Art Allison. I also cleaned up IDNIT= S.

Kevin Gross

On Thu,= Jun 21, 2012 at 3:12 PM, <internet-drafts@ietf.org>= wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Audio/Video Transport Core Maintenance = Working Group of the IETF.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : RTP and Leap Seconds
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Kevin Gross
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ray van Brandenburg
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-avtcore-leap-second-00= .txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 6
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-06-21

Abstract:
=A0 This document discusses issues that arise when RTP sessions span
=A0 (UTC) leap seconds. =A0It updates RFC 3550 to describe how RTP senders=
=A0 and receivers should behave in the presence of leap seconds.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-leap= -second

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-avtcore-leap-second-0= 0


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--00504502df4145013104c302b12c-- From ekr@rtfm.com Thu Jun 21 15:11:07 2012 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 8A09621F8649 for ; Thu, 21 Jun 2012 15:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 EIQUCUFda5z2 for ; Thu, 21 Jun 2012 15:11:01 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5696911E8095 for ; Thu, 21 Jun 2012 15:11:01 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so664987vbb.31 for ; Thu, 21 Jun 2012 15:11:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=Zcxid7LLsTAXkINs243c7GKmZyJqsHsdolWVJS5pGTA=; b=bo2oLCIrKBLEzeft/x9cm0Pp7YSczRig1rE/MTOMEuD4OlQ9SRlu577Dq36VEn/Rvh JVTkMUvddPp9h/ScCgru6v7w/t/l6AEwLs48ChLRpW7e0YGZmDj56Nqwqh2OEj0V7hvm N87rXu5GH719JKlulCtwZiABz0xznoiFp4v/SRWlL8DBFExZAF1RbQatnoI99KkFmSt+ zplIeGGQ8Hv0WIfjoyD1J6bAPV8n0TxDUmfdRYQb61kaeiQy9xd6rE06XGY1eVfUx8ZS Mwx39Ftb6V9ovOPopqXmWR0RgwQ2fJ5FT//IV3ZVK7yGG8QIkr36chZjbzAMtIx+GZ8/ 3Fvw== Received: by 10.52.36.33 with SMTP id n1mr9837262vdj.53.1340316660700; Thu, 21 Jun 2012 15:11:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Thu, 21 Jun 2012 15:10:20 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: <0114FC22-FAE9-491D-8E5B-97A38F7714E7@csperkins.org> References: <075C431A-A103-4C7E-9D4A-F80CB97DD9FB@csperkins.org> <0114FC22-FAE9-491D-8E5B-97A38F7714E7@csperkins.org> From: Eric Rescorla Date: Thu, 21 Jun 2012 15:10:20 -0700 Message-ID: To: Colin Perkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn/BCCzwdwyGt13NXVmSeBAD9xUqFIAkohOK9Lfh6ICv4tKXBQFeOnMZTXck4MGIaSg7XU6 Cc: rtcweb@ietf.org, Martin Thomson , avt@ietf.org, Cullen Jennings Subject: Re: [AVTCORE] [rtcweb] Randomly-generated CNAMEs 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: Thu, 21 Jun 2012 22:11:07 -0000 On Thu, Jun 21, 2012 at 2:54 PM, Colin Perkins wrote: > On 21 Jun 2012, at 20:09, Martin Thomson wrote: >> On 21 June 2012 05:48, Eric Rescorla wrote: >>> On Thu, Jun 21, 2012 at 5:39 AM, Cullen Jennings wrote: >>>> I think what EKR was getting at is that if A call B in one phone call,= then day later A wants to make an anonymous call to B, B should not be abl= e to tell the second call is coming from same devices. I think that was par= t of the goal of 6222 but from EKR's email it looks like it fails to provid= e that. >>> >>> Exactly. >> >> I agree with the analysis. =A0The idea that the same browser could be >> correlated across two independent sessions bothers me. =A0Within the one >> "session", fine - on the contrary, mandatory. =A0Outside of that, I'd >> like at least an option for anonymity. > > Using SRTP to encrypt the traffic will stop third-parties correlating the= sessions, and RTCWeb is mandates SRTP and encryption. I'm concerned about tracking by people who are second parties. Consider the case where I call you from an anonymous phone at a domestic violence shelter. I record the CNAME and then call all the DV shelters unti= l I determine which one has a CNAME from the same device. > RFC 6222 does define per-session RTCP CNAME values, if you're concerned a= bout the called party being able to correlate sessions based on the RTCP CN= AME. We could mandate those instead of short-term persistent RTCP CNAME val= ues. If that's not sufficient, then someone will need to write a draft that= defines a new RTCP CNAME generation algorithm, which this draft can refer = to. The problem is that those per-session CNAME values do not appear to be unlinkable. I.e., they are distinct but they are generated from the same underlying data with insufficient entropy to prevent someone who knows two CNAMEs from determini= ng if they are from the same device. As far as new algorithm goes, is there some reason "Random" isn't good enog= uh? -Ekr From csp@csperkins.org Thu Jun 21 15:28:56 2012 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 06DB511E8088; Thu, 21 Jun 2012 15:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 imJjszOGk3fb; Thu, 21 Jun 2012 15:28:55 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by ietfa.amsl.com (Postfix) with ESMTP id 319BE11E8079; Thu, 21 Jun 2012 15:28:55 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.11]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Shpry-0005NP-Xa; Thu, 21 Jun 2012 22:28:54 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: Date: Thu, 21 Jun 2012 23:28:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <075C431A-A103-4C7E-9D4A-F80CB97DD9FB@csperkins.org> <0114FC22-FAE9-491D-8E5B-97A38F7714E7@csperkins.org> To: Eric Rescorla X-Mailer: Apple Mail (2.1278) Cc: rtcweb@ietf.org, Martin Thomson , avt@ietf.org, Cullen Jennings Subject: Re: [AVTCORE] [rtcweb] Randomly-generated CNAMEs 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: Thu, 21 Jun 2012 22:28:56 -0000 On 21 Jun 2012, at 23:10, Eric Rescorla wrote: > On Thu, Jun 21, 2012 at 2:54 PM, Colin Perkins = wrote: >> On 21 Jun 2012, at 20:09, Martin Thomson wrote: >>> On 21 June 2012 05:48, Eric Rescorla wrote: >>>> On Thu, Jun 21, 2012 at 5:39 AM, Cullen Jennings = wrote: >>>>> I think what EKR was getting at is that if A call B in one phone = call, then day later A wants to make an anonymous call to B, B should = not be able to tell the second call is coming from same devices. I think = that was part of the goal of 6222 but from EKR's email it looks like it = fails to provide that. >>>>=20 >>>> Exactly. >>>=20 >>> I agree with the analysis. The idea that the same browser could be >>> correlated across two independent sessions bothers me. Within the = one >>> "session", fine - on the contrary, mandatory. Outside of that, I'd >>> like at least an option for anonymity. >>=20 >> Using SRTP to encrypt the traffic will stop third-parties correlating = the sessions, and RTCWeb is mandates SRTP and encryption. >=20 > I'm concerned about tracking by people who are second parties. >=20 > Consider the case where I call you from an anonymous phone at a = domestic violence shelter. I record the CNAME and then call all the DV = shelters until I determine which one has a CNAME from the same device. >=20 >> RFC 6222 does define per-session RTCP CNAME values, if you're = concerned about the called party being able to correlate sessions based = on the RTCP CNAME. We could mandate those instead of short-term = persistent RTCP CNAME values. If that's not sufficient, then someone = will need to write a draft that defines a new RTCP CNAME generation = algorithm, which this draft can refer to. >=20 > The problem is that those per-session CNAME values do not appear to be > unlinkable. I.e., they are distinct but they are generated from the = same underlying data with insufficient entropy to prevent someone who = knows two CNAMEs from determining if they are from the same device. >=20 > As far as new algorithm goes, is there some reason "Random" isn't good = enoguh? There's some discussion in RFC 3550 Section 6.5.1 and RFC 6222. It might = be possible to use a random choice, provided the same random value is = used across all sessions that need to be correlated, and the value is = chosen to be unique with high probability. I haven't thought about it in = detail. In any case, it's an update to RFC 3550 and RFC 6222, so someone = will have to write up the draft defining this.=20 --=20 Colin Perkins http://csperkins.org/ From kevin.gross@avanw.com Thu Jun 21 16:09:08 2012 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 4BC3921F8589 for ; Thu, 21 Jun 2012 16:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 BL36ol5PwnYa for ; Thu, 21 Jun 2012 16:09:07 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 1491821F85A8 for ; Thu, 21 Jun 2012 16:09:06 -0700 (PDT) Received: (qmail 17514 invoked by uid 0); 21 Jun 2012 23:09:06 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy9.bluehost.com with SMTP; 21 Jun 2012 23:09:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=paJJMO1Bj3r44xeUKnZgS1pQ7qv9N11hMfIjgK1eoeQ=; b=NgKFFY+P4Jvz463hVaUMYQAlKIfGuAwK8M2pjxM7M8tnzYEq267UtcxqViOLRJjU08WzO062rINCNZt4Ax/ZCXOu3FQOrYPX50F++I2Wzy1CQvlU4Q/YHItaFz+P1Elp; Received: from [74.125.82.172] (port=37771 helo=mail-we0-f172.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1ShqUs-00053c-3P; Thu, 21 Jun 2012 17:09:06 -0600 Received: by werb13 with SMTP id b13so912571wer.31 for ; Thu, 21 Jun 2012 16:09:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.226.32 with SMTP id a32mr15190805weq.190.1340320144443; Thu, 21 Jun 2012 16:09:04 -0700 (PDT) Received: by 10.223.144.216 with HTTP; Thu, 21 Jun 2012 16:09:04 -0700 (PDT) In-Reply-To: References: <075C431A-A103-4C7E-9D4A-F80CB97DD9FB@csperkins.org> <0114FC22-FAE9-491D-8E5B-97A38F7714E7@csperkins.org> Date: Thu, 21 Jun 2012 17:09:04 -0600 Message-ID: From: Kevin Gross To: Colin Perkins Content-Type: multipart/alternative; boundary=0016e6de17f3184a0604c3039ad2 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.172 authed with kevin.gross@avanw.com} Cc: Martin Thomson , rtcweb@ietf.org, avt@ietf.org, Cullen Jennings Subject: Re: [AVTCORE] [rtcweb] Randomly-generated CNAMEs 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: Thu, 21 Jun 2012 23:09:08 -0000 --0016e6de17f3184a0604c3039ad2 Content-Type: text/plain; charset=ISO-8859-1 It seems like, pure random CNAMEs would have the same or better probability of uniqueness compared to the hashed values specified in 6222. I don't think it is difficult to prove this if you assume the hash function does what it's designed to and makes data white. 48 is not enough bits to ensure uniqueness of a large population of random numbers. If I remember correctly, 64 bits is where the statistics start to get comfortable. See http://en.wikipedia.org/wiki/Birthday_problem. Potentially there's a bigger problem here than linkability :( Kevin Gross On Thu, Jun 21, 2012 at 4:28 PM, Colin Perkins wrote: > On 21 Jun 2012, at 23:10, Eric Rescorla wrote: > > On Thu, Jun 21, 2012 at 2:54 PM, Colin Perkins > wrote: > >> On 21 Jun 2012, at 20:09, Martin Thomson wrote: > >>> On 21 June 2012 05:48, Eric Rescorla wrote: > >>>> On Thu, Jun 21, 2012 at 5:39 AM, Cullen Jennings > wrote: > >>>>> I think what EKR was getting at is that if A call B in one phone > call, then day later A wants to make an anonymous call to B, B should not > be able to tell the second call is coming from same devices. I think that > was part of the goal of 6222 but from EKR's email it looks like it fails to > provide that. > >>>> > >>>> Exactly. > >>> > >>> I agree with the analysis. The idea that the same browser could be > >>> correlated across two independent sessions bothers me. Within the one > >>> "session", fine - on the contrary, mandatory. Outside of that, I'd > >>> like at least an option for anonymity. > >> > >> Using SRTP to encrypt the traffic will stop third-parties correlating > the sessions, and RTCWeb is mandates SRTP and encryption. > > > > I'm concerned about tracking by people who are second parties. > > > > Consider the case where I call you from an anonymous phone at a domestic > violence shelter. I record the CNAME and then call all the DV shelters > until I determine which one has a CNAME from the same device. > > > >> RFC 6222 does define per-session RTCP CNAME values, if you're concerned > about the called party being able to correlate sessions based on the RTCP > CNAME. We could mandate those instead of short-term persistent RTCP CNAME > values. If that's not sufficient, then someone will need to write a draft > that defines a new RTCP CNAME generation algorithm, which this draft can > refer to. > > > > The problem is that those per-session CNAME values do not appear to be > > unlinkable. I.e., they are distinct but they are generated from the same > underlying data with insufficient entropy to prevent someone who knows two > CNAMEs from determining if they are from the same device. > > > > As far as new algorithm goes, is there some reason "Random" isn't good > enoguh? > > > There's some discussion in RFC 3550 Section 6.5.1 and RFC 6222. It might > be possible to use a random choice, provided the same random value is used > across all sessions that need to be correlated, and the value is chosen to > be unique with high probability. I haven't thought about it in detail. In > any case, it's an update to RFC 3550 and RFC 6222, so someone will have to > write up the draft defining this. > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --0016e6de17f3184a0604c3039ad2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It seems like, pure random CNAMEs would have the same or better probability= of uniqueness compared to the hashed values specified in 6222. I don't= think it is difficult to prove this if you assume the hash function does w= hat it's designed to and makes data white. 48 is not enough bits to ens= ure uniqueness of a large population of random numbers. If I remember corre= ctly, 64 bits is where the statistics start to get comfortable. See=A0 http://en.wikiped= ia.org/wiki/Birthday_problem. Potentially there's a bigger problem = here than linkability :(

Kevin Gross

On Thu, Jun 21, 2012 at 4:28 PM, Colin Perkins <= span dir=3D"ltr"><csp@csperkins.org> wrote:
On 21 Jun 2012, at 23:10, Eric Resc= orla wrote:
> On Thu, Jun 21, 2012 at 2:54 PM, Colin Perkins <csp@csperkins.org> wrote:
>> On 21 Jun 2012, at 20:09, Martin Thomson wrote:
>>> On 21 June 2012 05:48, Eric Rescorla <ekr@rtfm.com> wrote:
>>>> On Thu, Jun 21, 2012 at 5:39 AM, Cullen Jennings <fluffy@iii.ca> wrote:
>>>>> I think what EKR was getting at is that if A call B in= one phone call, then day later A wants to make an anonymous call to B, B s= hould not be able to tell the second call is coming from same devices. I th= ink that was part of the goal of 6222 but from EKR's email it looks lik= e it fails to provide that.
>>>>
>>>> Exactly.
>>>
>>> I agree with the analysis. =A0The idea that the same browser c= ould be
>>> correlated across two independent sessions bothers me. =A0With= in the one
>>> "session", fine - on the contrary, mandatory. =A0Out= side of that, I'd
>>> like at least an option for anonymity.
>>
>> Using SRTP to encrypt the traffic will stop third-parties correlat= ing the sessions, and RTCWeb is mandates SRTP and encryption.
>
> I'm concerned about tracking by people who are second parties.
>
> Consider the case where I call you from an anonymous phone at a domest= ic violence shelter. I record the CNAME and then call all the DV shelters u= ntil I determine which one has a CNAME from the same device.
>
>> RFC 6222 does define per-session RTCP CNAME values, if you're = concerned about the called party being able to correlate sessions based on = the RTCP CNAME. We could mandate those instead of short-term persistent RTC= P CNAME values. If that's not sufficient, then someone will need to wri= te a draft that defines a new RTCP CNAME generation algorithm, which this d= raft can refer to.
>
> The problem is that those per-session CNAME values do not appear to be=
> unlinkable. I.e., they are distinct but they are generated from the sa= me underlying data with insufficient entropy to prevent someone who knows t= wo CNAMEs from determining if they are from the same device.
>
> As far as new algorithm goes, is there some reason "Random" = isn't good enoguh?


There's some discussion in RFC 3550 Section 6.5.1 and RFC 6= 222. It might be possible to use a random choice, provided the same random = value is used across all sessions that need to be correlated, and the value= is chosen to be unique with high probability. I haven't thought about = it in detail. In any case, it's an update to RFC 3550 and RFC 6222, so = someone will have to write up the draft defining this.

--
Colin Perkins
http://csperkins.org/



_____________________________= __________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--0016e6de17f3184a0604c3039ad2-- From ekr@rtfm.com Thu Jun 21 16:13:13 2012 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 5892611E80C5 for ; Thu, 21 Jun 2012 16:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Evs1OjKXfq-F for ; Thu, 21 Jun 2012 16:13:12 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2418711E80C4 for ; Thu, 21 Jun 2012 16:13:12 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so686107vbb.31 for ; Thu, 21 Jun 2012 16:13:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=1Kv+C8keBfs0bEjRvRIU4hvQ63RNIMtql6+zKhaCyhg=; b=i10uVyDSj7Rw1EL3SZCpVDGkF3PecyD0r9MJudFOkLUbFsDjU1/Lji6m8tiCpUZU8Z UJWrD2kpvrsuJjzVai/VZ76HVT+45+JVrBtB1oKMQtVUsRGHq9qw8oYugRXA1g4ROZHs 1xCSE8QxME0epJRRixjXxBJZXiEkxikqu9YleWZxp0eDlGsiLF7CupsPjWerp1QTar+m Rr4uK+rieNOxhAXaJe93QdM6Hz1BIHl/ry24ajVXCsQ8iOywzzgXzE/QfuGoJ6ICkcDm Y/BGoa1Zs0c4T70JDsNRw6QhgFiY3GLHIQ8KZguIFCB+yYGzdH6EoRu9Y7QpwGIDUzdF asdg== Received: by 10.52.100.229 with SMTP id fb5mr11739970vdb.102.1340320388078; Thu, 21 Jun 2012 16:13:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Thu, 21 Jun 2012 16:12:27 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: References: <075C431A-A103-4C7E-9D4A-F80CB97DD9FB@csperkins.org> <0114FC22-FAE9-491D-8E5B-97A38F7714E7@csperkins.org> From: Eric Rescorla Date: Thu, 21 Jun 2012 16:12:27 -0700 Message-ID: To: Kevin Gross Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn2xd2TYcFdRGucB/k4NZJtJazpwswUZNWZb6qIxNp5LmbLkGdbzAk9g+yDZp5xbe4yDGPG Cc: Martin Thomson , rtcweb@ietf.org, Colin Perkins , Cullen Jennings , avt@ietf.org Subject: Re: [AVTCORE] [rtcweb] Randomly-generated CNAMEs 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: Thu, 21 Jun 2012 23:13:13 -0000 This matches my analysis. -Ekr On Thu, Jun 21, 2012 at 4:09 PM, Kevin Gross wrote: > It seems like, pure random CNAMEs would have the same or better probabili= ty > of uniqueness compared to the hashed values specified in 6222. I don't th= ink > it is difficult to prove this if you assume the hash function does what i= t's > designed to and makes data white. 48 is not enough bits to ensure uniquen= ess > of a large population of random numbers. If I remember correctly, 64 bits= is > where the statistics start to get comfortable. See > http://en.wikipedia.org/wiki/Birthday_problem. Potentially there's a bigg= er > problem here than linkability :( > > Kevin Gross > > On Thu, Jun 21, 2012 at 4:28 PM, Colin Perkins wrote: >> >> On 21 Jun 2012, at 23:10, Eric Rescorla wrote: >> > On Thu, Jun 21, 2012 at 2:54 PM, Colin Perkins >> > wrote: >> >> On 21 Jun 2012, at 20:09, Martin Thomson wrote: >> >>> On 21 June 2012 05:48, Eric Rescorla wrote: >> >>>> On Thu, Jun 21, 2012 at 5:39 AM, Cullen Jennings >> >>>> wrote: >> >>>>> I think what EKR was getting at is that if A call B in one phone >> >>>>> call, then day later A wants to make an anonymous call to B, B sho= uld not be >> >>>>> able to tell the second call is coming from same devices. I think = that was >> >>>>> part of the goal of 6222 but from EKR's email it looks like it fai= ls to >> >>>>> provide that. >> >>>> >> >>>> Exactly. >> >>> >> >>> I agree with the analysis. =A0The idea that the same browser could b= e >> >>> correlated across two independent sessions bothers me. =A0Within the= one >> >>> "session", fine - on the contrary, mandatory. =A0Outside of that, I'= d >> >>> like at least an option for anonymity. >> >> >> >> Using SRTP to encrypt the traffic will stop third-parties correlating >> >> the sessions, and RTCWeb is mandates SRTP and encryption. >> > >> > I'm concerned about tracking by people who are second parties. >> > >> > Consider the case where I call you from an anonymous phone at a domest= ic >> > violence shelter. I record the CNAME and then call all the DV shelters= until >> > I determine which one has a CNAME from the same device. >> > >> >> RFC 6222 does define per-session RTCP CNAME values, if you're concern= ed >> >> about the called party being able to correlate sessions based on the = RTCP >> >> CNAME. We could mandate those instead of short-term persistent RTCP C= NAME >> >> values. If that's not sufficient, then someone will need to write a d= raft >> >> that defines a new RTCP CNAME generation algorithm, which this draft = can >> >> refer to. >> > >> > The problem is that those per-session CNAME values do not appear to be >> > unlinkable. I.e., they are distinct but they are generated from the sa= me >> > underlying data with insufficient entropy to prevent someone who knows= two >> > CNAMEs from determining if they are from the same device. >> > >> > As far as new algorithm goes, is there some reason "Random" isn't good >> > enoguh? >> >> >> There's some discussion in RFC 3550 Section 6.5.1 and RFC 6222. It might >> be possible to use a random choice, provided the same random value is us= ed >> across all sessions that need to be correlated, and the value is chosen = to >> be unique with high probability. I haven't thought about it in detail. I= n >> any case, it's an update to RFC 3550 and RFC 6222, so someone will have = to >> write up the draft defining this. >> >> -- >> Colin Perkins >> http://csperkins.org/ >> >> >> >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > > From abegen@cisco.com Thu Jun 21 17:47:53 2012 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 E687311E80BE; Thu, 21 Jun 2012 17:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 dJVZQ2kJSKph; Thu, 21 Jun 2012 17:47:53 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C5B6811E8072; Thu, 21 Jun 2012 17:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=4105; q=dns/txt; s=iport; t=1340326073; x=1341535673; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5vG1J9T2OSEZ2+elvIf8DtIJpFqMkxH+9fi3O1BbDoI=; b=XRrpZyV3xubv/itx1tRks3HSa11bxlFeJkR+k+YRHwUSHxMdQFB2BCV5 nQON52gY98sPxSgptfN8zHS7P6XbyIj7cy1vbBzhb0/wTIuVqfBbAHmlZ QMoY5g6AGNEj8QQJk+YFw86mZidno/WImNYHh2xR8q4eVNgHpxT+W9bDV s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADbA40+tJV2c/2dsb2JhbABFtVyBB4IYAQEBBAEBAQ8BZgwEAgEIEQQBAQEKHQcnCxQJCAIEAQ0FCBqHaQEKmiygEosuhSJgA5Y8jQmBZoJfgV8 X-IronPort-AV: E=Sophos;i="4.77,454,1336348800"; d="scan'208";a="94782737" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 22 Jun 2012 00:47:52 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q5M0lqCb028049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Jun 2012 00:47:52 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0298.004; Thu, 21 Jun 2012 19:47:51 -0500 From: "Ali C. Begen (abegen)" To: Kevin Gross , Colin Perkins Thread-Topic: [AVTCORE] [rtcweb] Randomly-generated CNAMEs Thread-Index: AQHNUALsL5A4WY2ALUqSNGtL0fD+lpcFgQpg Date: Fri, 22 Jun 2012 00:46:14 +0000 Message-ID: References: <075C431A-A103-4C7E-9D4A-F80CB97DD9FB@csperkins.org> <0114FC22-FAE9-491D-8E5B-97A38F7714E7@csperkins.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.29] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18988.001 x-tm-as-result: No--43.431300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , Martin Thomson , "avt@ietf.org" , Cullen Jennings Subject: Re: [AVTCORE] [rtcweb] Randomly-generated CNAMEs 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: Fri, 22 Jun 2012 00:47:54 -0000 Many implementors just assume "0" for any random number they need to come u= p with. So, saying to choose a random number may not cut it. -acbegen > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kev= in Gross > Sent: Thursday, June 21, 2012 7:09 PM > To: Colin Perkins > Cc: Martin Thomson; rtcweb@ietf.org; avt@ietf.org; Cullen Jennings > Subject: Re: [AVTCORE] [rtcweb] Randomly-generated CNAMEs >=20 > It seems like, pure random CNAMEs would have the same or better probabili= ty of uniqueness compared to the hashed values > specified in 6222. I don't think it is difficult to prove this if you ass= ume the hash function does what it's designed to and makes > data white. 48 is not enough bits to ensure uniqueness of a large populat= ion of random numbers. If I remember correctly, 64 > bits is where the statistics start to get comfortable. See http://en.wik= ipedia.org/wiki/Birthday_problem. Potentially there's a > bigger problem here than linkability :( >=20 > Kevin Gross >=20 >=20 > On Thu, Jun 21, 2012 at 4:28 PM, Colin Perkins wrote: >=20 >=20 > On 21 Jun 2012, at 23:10, Eric Rescorla wrote: > > On Thu, Jun 21, 2012 at 2:54 PM, Colin Perkins wro= te: > >> On 21 Jun 2012, at 20:09, Martin Thomson wrote: > >>> On 21 June 2012 05:48, Eric Rescorla wrote: > >>>> On Thu, Jun 21, 2012 at 5:39 AM, Cullen Jennings wr= ote: > >>>>> I think what EKR was getting at is that if A call B in one phone c= all, then day later A wants to make an > anonymous call to B, B should not be able to tell the second call is comi= ng from same devices. I think that was part of the > goal of 6222 but from EKR's email it looks like it fails to provide that. > >>>> > >>>> Exactly. > >>> > >>> I agree with the analysis. The idea that the same browser could be > >>> correlated across two independent sessions bothers me. Within the o= ne > >>> "session", fine - on the contrary, mandatory. Outside of that, I'd > >>> like at least an option for anonymity. > >> > >> Using SRTP to encrypt the traffic will stop third-parties correlating= the sessions, and RTCWeb is mandates SRTP > and encryption. > > > > I'm concerned about tracking by people who are second parties. > > > > Consider the case where I call you from an anonymous phone at a domest= ic violence shelter. I record the CNAME > and then call all the DV shelters until I determine which one has a CNAME= from the same device. > > > >> RFC 6222 does define per-session RTCP CNAME values, if you're concern= ed about the called party being able to > correlate sessions based on the RTCP CNAME. We could mandate those instea= d of short-term persistent RTCP CNAME values. > If that's not sufficient, then someone will need to write a draft that de= fines a new RTCP CNAME generation algorithm, which > this draft can refer to. > > > > The problem is that those per-session CNAME values do not appear to be > > unlinkable. I.e., they are distinct but they are generated from the sa= me underlying data with insufficient entropy to > prevent someone who knows two CNAMEs from determining if they are from th= e same device. > > > > As far as new algorithm goes, is there some reason "Random" isn't good= enoguh? >=20 >=20 >=20 > There's some discussion in RFC 3550 Section 6.5.1 and RFC 6222. It might= be possible to use a random choice, > provided the same random value is used across all sessions that need to b= e correlated, and the value is chosen to be unique > with high probability. I haven't thought about it in detail. In any case,= it's an update to RFC 3550 and RFC 6222, so someone > will have to write up the draft defining this. >=20 >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 >=20 From ekr@rtfm.com Thu Jun 21 18:03:08 2012 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 50A6611E80C6 for ; Thu, 21 Jun 2012 18:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 S984ICCfLTv2 for ; Thu, 21 Jun 2012 18:03:07 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C05D911E8072 for ; Thu, 21 Jun 2012 18:03:07 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so718343vbb.31 for ; Thu, 21 Jun 2012 18:03:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=bhJBd76ybP2jZJFNdJfIRAagsQ0EO5+NxQyurHya87Q=; b=ZA5quwKsSmoauhQ99kgQTXOkAuc36QY+Kk8rdgYha7uFs79aR6wwSnzPKvvEkJO0oH 2NL0WifKpJHVdSjXvZhDTDNXDkLQ7GBjNirY5KXKRuouaen2ANhPSmTUysnD8dFbLdBP 9df3yiyaJTX0JwcOlafYHyMM6ZfvXt9Fq/M1tvkKXHXD8Es8qHFDyljYtUNQWlKgdNQ+ W8bBzuzIkl4tuvMMgvX0uFgdEUgESsTYp6rDyBC2Y0rHoDlmIZWGTySNMr7fJbxrjPws 5CX46KlLE2ki/dSK4hGLZn16GRxHAr3+URJ6dSDZAPdCiaqE7K9OrQSiCKOuBRyzcPL2 hMAQ== Received: by 10.52.36.33 with SMTP id n1mr79997vdj.53.1340326987284; Thu, 21 Jun 2012 18:03:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Thu, 21 Jun 2012 18:02:27 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: References: <075C431A-A103-4C7E-9D4A-F80CB97DD9FB@csperkins.org> <0114FC22-FAE9-491D-8E5B-97A38F7714E7@csperkins.org> From: Eric Rescorla Date: Thu, 21 Jun 2012 18:02:27 -0700 Message-ID: To: "Ali C. Begen (abegen)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlzpU4+p1c8Z/HqinbEkNfqXf4S4znxb3uWBEvrvci70mjrIpZBTstmF9v12Y3jifK6mraP Cc: "avt@ietf.org" , "rtcweb@ietf.org" , Cullen Jennings , Martin Thomson , Colin Perkins Subject: Re: [AVTCORE] [rtcweb] Randomly-generated CNAMEs 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: Fri, 22 Jun 2012 01:03:08 -0000 On Thu, Jun 21, 2012 at 5:46 PM, Ali C. Begen (abegen) wrote: > Many implementors just assume "0" for any random number they need to come up with. So, saying to choose a random number may not cut it. I would require it to be cryptographically random. That's not an issue since this system needs such numbers all over the place. From kevin.gross@avanw.com Thu Jun 21 20:07:47 2012 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 775FD11E8091 for ; Thu, 21 Jun 2012 20:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 htoB-wAAgKfS for ; Thu, 21 Jun 2012 20:07:46 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 9642E11E80C6 for ; Thu, 21 Jun 2012 20:07:46 -0700 (PDT) Received: (qmail 20682 invoked by uid 0); 22 Jun 2012 03:07:44 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy8.bluehost.com with SMTP; 22 Jun 2012 03:07:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=hKf/KJmuMyYi/xl39HZlBrawaQRm4caKwWF1x8S8emI=; b=M5OLbFzZD6u7DNflr1+xYnMnqc1/qTiJbyup9TYJwF9RG/pBlIGE0BbXR0iXRj9nAh2XCinHCcG0GLT/21CEMH1km0be+U6quBnFp4CBRr4Y2Qc5xw2D5E1Jewa1WZeJ; Received: from [209.85.212.172] (port=36091 helo=mail-wi0-f172.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1ShuDn-00066n-Tp; Thu, 21 Jun 2012 21:07:44 -0600 Received: by wibhm11 with SMTP id hm11so137862wib.13 for ; Thu, 21 Jun 2012 20:07:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.78.228 with SMTP id e4mr1178059wix.4.1340334462431; Thu, 21 Jun 2012 20:07:42 -0700 (PDT) Received: by 10.223.144.216 with HTTP; Thu, 21 Jun 2012 20:07:42 -0700 (PDT) In-Reply-To: References: <075C431A-A103-4C7E-9D4A-F80CB97DD9FB@csperkins.org> <0114FC22-FAE9-491D-8E5B-97A38F7714E7@csperkins.org> Date: Thu, 21 Jun 2012 21:07:42 -0600 Message-ID: From: Kevin Gross To: Justin Uberti Content-Type: multipart/alternative; boundary=f46d04388e638372a004c306eff3 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.212.172 authed with kevin.gross@avanw.com} Cc: "rtcweb@ietf.org" , "avt@ietf.org" , Colin Perkins Subject: Re: [AVTCORE] [rtcweb] Randomly-generated CNAMEs 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: Fri, 22 Jun 2012 03:07:47 -0000 --f46d04388e638372a004c306eff3 Content-Type: text/plain; charset=ISO-8859-1 RFC 4086 - Randomness Requirements for Security On Thu, Jun 21, 2012 at 7:48 PM, Justin Uberti wrote: > > > On Thu, Jun 21, 2012 at 9:02 PM, Eric Rescorla wrote: > >> On Thu, Jun 21, 2012 at 5:46 PM, Ali C. Begen (abegen) >> wrote: >> > Many implementors just assume "0" for any random number they need to >> come up with. So, saying to choose a random number may not cut it. >> >> I would require it to be cryptographically random. That's not an issue >> since this system needs such numbers all over the place. >> >> > Right. In our implementation, we use random data for CNAMEs; it's simpler > than performing the RFC 6222 steps and indistinguishable on the wire. > --f46d04388e638372a004c306eff3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RFC 4086 -=A0Randomness Requirements f= or Security

On Thu, Jun 21, 2= 012 at 7:48 PM, Justin Uberti <juberti@google.com> wrote:


O= n Thu, Jun 21, 2012 at 9:02 PM, Eric Rescorla <ekr@rtfm.com> wrot= e:
On Thu, Jun 21, 2012 at 5:46 PM, Ali C. Bege= n (abegen) <abegen= @cisco.com> wrote:
> Many implementors just assume "0" for any random number they= need to come up with. So, saying to choose a random number may not cut it.=

I would require it to be cryptographically random. That's not an issue<= br> since this system needs such numbers all over the place.


Righ= t. In our implementation, we use random data for CNAMEs; it's simpler t= han performing the RFC 6222 steps and indistinguishable on the wire.

--f46d04388e638372a004c306eff3-- From martin.thomson@gmail.com Thu Jun 21 12:09:12 2012 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 3932D21F86D9; Thu, 21 Jun 2012 12:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.793 X-Spam-Level: X-Spam-Status: No, score=-3.793 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 iyeRsifriEik; Thu, 21 Jun 2012 12:09:11 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B7CB021F86D5; Thu, 21 Jun 2012 12:09:10 -0700 (PDT) Received: by bkty8 with SMTP id y8so1008894bkt.31 for ; Thu, 21 Jun 2012 12:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8RQB9JExY1J5O1pCbplT5qn0AFaTTLw4xswD2lI64/U=; b=j6hD1wuXxgRc/wa8YaF59jwbPsUquckVyRP4C/jPIeakJBJmkGLfXKHOXTvL6nH0R8 7Y8/aCoBgz9Mmx7TtKZ1tJsxYZMY3STeksSbRfzkV1CBiPLBrY41I6cL9L4GZpvs4ocQ QLMAFCoXLVCHVutNZ7wq2jFL7ph0Gmw2pHoAEszkK6Una0A9hCbLxSher/IE5QL8iQTa wzE/LVwUg1ucfMPFScEGCYxjwq5pxyn88YS1edVhnIhwNWYWPxRyKg06hr+SbZAjKtdh i+tmmkqhi8XM/buDHT7PUEt0eVXSbJsnknFgKrA81eG4P9skUHJLV4R9cPcMF1eebVJu vFtg== MIME-Version: 1.0 Received: by 10.204.128.149 with SMTP id k21mr12200675bks.42.1340305749770; Thu, 21 Jun 2012 12:09:09 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Thu, 21 Jun 2012 12:09:09 -0700 (PDT) In-Reply-To: References: <075C431A-A103-4C7E-9D4A-F80CB97DD9FB@csperkins.org> Date: Thu, 21 Jun 2012 12:09:09 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 22 Jun 2012 09:33:18 -0700 Cc: rtcweb@ietf.org, Colin Perkins , Cullen Jennings , avt@ietf.org Subject: Re: [AVTCORE] [rtcweb] Randomly-generated CNAMEs 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: Thu, 21 Jun 2012 19:09:12 -0000 On 21 June 2012 05:48, Eric Rescorla wrote: > On Thu, Jun 21, 2012 at 5:39 AM, Cullen Jennings wrote: >> I think what EKR was getting at is that if A call B in one phone call, t= hen day later A wants to make an anonymous call to B, B should not be able = to tell the second call is coming from same devices. I think that was part = of the goal of 6222 but from EKR's email it looks like it fails to provide = that. > > > Exactly. I agree with the analysis. The idea that the same browser could be correlated across two independent sessions bothers me. Within the one "session", fine - on the contrary, mandatory. Outside of that, I'd like at least an option for anonymity. From juberti@google.com Thu Jun 21 18:49:20 2012 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 A2B7721F8601 for ; Thu, 21 Jun 2012 18:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.693 X-Spam-Level: X-Spam-Status: No, score=-102.693 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 MuGNy0La9pbR for ; Thu, 21 Jun 2012 18:49:20 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 063EA21F855B for ; Thu, 21 Jun 2012 18:49:19 -0700 (PDT) Received: by qcsq13 with SMTP id q13so822014qcs.31 for ; Thu, 21 Jun 2012 18:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=PSKHI3FRfHrBmsCpKTUTlLOVOg3MgforDneHcLuZwuU=; b=YA4tKD37fXpwhYE6HjkSXDvJNjloS8WKGeLbxgYbqSLBPi1fIPvMYO1FzE8m2hiGTM Q0h8/4+eHd5HIYAcvDW5NPDCGe5bmJbytwCKjir31sDXJxo+7ZExCzuO7k/J95mTSzIe lrMSI016jX1HzQmVcwPob2U3QznCd/vjsybhweGZ0UPXOE0WQo4P7bDb2rhrRJLpaAtq e0RuajU+XBr5EZQoK4Z28FUYqY4iK/YUhb1TfHewgvpFK5P9c9xKHffyu2gmT2gu68F/ uAH2VbV/HwmLkSv8JOm7pSUixSa05QKxBzsZ/pqFu96SrKrucy7GjY9B6Fh82bLHqP4j ugxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=PSKHI3FRfHrBmsCpKTUTlLOVOg3MgforDneHcLuZwuU=; b=HMSanRQB1an7RkMkcvN3ZIYqO7xW6Vpj9CA4+DuXQws0hLltKCsJ45PYVMpNKD53sh VGeBj+vMms0W2iQoj4z8oRk3YNRcND36/6q26Cm3maObUH36SklFBGKX3sr6Qa1gBNTM m7rUocQp3EP1Eg7p9qTTCpxbZiOAMoDRS2ZGwCIMJqC1JwSxicb1h0t+Q8PRjsyNZjmg DN5OEukQn8mpbPHcUi6U2ldMDLeFTEpydm2Cz2b2Q/jwprIPhWCEvTkpohJcPWDD8M22 SQxi6S69RVnS/uA/sUPhkFdctVFYU9rJdZcQbSynXOWHpjfH87O9vFdYOqqEGgVBnZPG elWQ== Received: by 10.224.181.83 with SMTP id bx19mr3150676qab.79.1340329759280; Thu, 21 Jun 2012 18:49:19 -0700 (PDT) Received: by 10.224.181.83 with SMTP id bx19mr3150658qab.79.1340329759175; Thu, 21 Jun 2012 18:49:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.65.211 with HTTP; Thu, 21 Jun 2012 18:48:58 -0700 (PDT) In-Reply-To: References: <075C431A-A103-4C7E-9D4A-F80CB97DD9FB@csperkins.org> <0114FC22-FAE9-491D-8E5B-97A38F7714E7@csperkins.org> From: Justin Uberti Date: Thu, 21 Jun 2012 21:48:58 -0400 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=485b397dcd392d72b004c305d73d X-System-Of-Record: true X-Gm-Message-State: ALoCoQlLZs7PBoeiHOqh4rdiVP5+Z9SIxv02Dwouw+jHJiFRfd6JMb84Xqv+PkFwqqCIh4N5RIhw9jMaaFYknaAxRpEzXzf/0SpAVHm4NKbeayeSFAtkOcL3jUWcINn4v5MOAnkdHomOHLKdnMXIPx4MIjPMlKFt3UUufBOtagE0orxRIVuZEv8= X-Mailman-Approved-At: Fri, 22 Jun 2012 09:33:20 -0700 Cc: "rtcweb@ietf.org" , "avt@ietf.org" , Colin Perkins Subject: Re: [AVTCORE] [rtcweb] Randomly-generated CNAMEs 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: Fri, 22 Jun 2012 01:49:20 -0000 --485b397dcd392d72b004c305d73d Content-Type: text/plain; charset=UTF-8 On Thu, Jun 21, 2012 at 9:02 PM, Eric Rescorla wrote: > On Thu, Jun 21, 2012 at 5:46 PM, Ali C. Begen (abegen) > wrote: > > Many implementors just assume "0" for any random number they need to > come up with. So, saying to choose a random number may not cut it. > > I would require it to be cryptographically random. That's not an issue > since this system needs such numbers all over the place. > > Right. In our implementation, we use random data for CNAMEs; it's simpler than performing the RFC 6222 steps and indistinguishable on the wire. --485b397dcd392d72b004c305d73d Content-Type: text/html; charset=UTF-8


On Thu, Jun 21, 2012 at 9:02 PM, Eric Rescorla <ekr@rtfm.com> wrote:
On Thu, Jun 21, 2012 at 5:46 PM, Ali C. Begen (abegen) <abegen@cisco.com> wrote:
> Many implementors just assume "0" for any random number they need to come up with. So, saying to choose a random number may not cut it.

I would require it to be cryptographically random. That's not an issue
since this system needs such numbers all over the place.


Right. In our implementation, we use random data for CNAMEs; it's simpler than performing the RFC 6222 steps and indistinguishable on the wire.
--485b397dcd392d72b004c305d73d-- From mary.ietf.barnes@gmail.com Fri Jun 22 12:44:53 2012 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 60B0D21F8533 for ; Fri, 22 Jun 2012 12:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.718 X-Spam-Level: X-Spam-Status: No, score=-103.718 tagged_above=-999 required=5 tests=[AWL=-0.119, 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 WLV7Jyy9TtyM for ; Fri, 22 Jun 2012 12:44:52 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D015E21F8525 for ; Fri, 22 Jun 2012 12:44:52 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2765025obb.31 for ; Fri, 22 Jun 2012 12:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=VIFxNAgmWSbh8uin5Lwzgpiru840lK8zsuyHEa2VXsc=; b=ym0jaGY0Kp91ej55byvlzPcO1uuQIVJJg2c99T4svvExWM3AX2EnA02TKpoJCi2A1R BN/E0tJPI+0HCYRfYvJhZmHPPl5l+wEqEvj9qAKXMz7upnlw0rMu0QYG2xz1lpS1ZZY+ Ro3OEHHqjQWYK2+rG+YxQmDC/b2fU+O1Lnf8Gfc4DA2OtazbLaN2nvxqDAAJ5i6SVQKe /bucaI2F2PXjUDz9/+b93+NpxaJwuSxfHJ4jOcBGbX78wpQRm89Hcct+egSzlD9zXgLl Ji9VExtciCgVFMMIIhpuCIgJa0935Kocitbodfq63NT4uQQnU51OOOw6oEEpIYv+iMy7 MLYQ== MIME-Version: 1.0 Received: by 10.182.40.71 with SMTP id v7mr3291854obk.5.1340394292284; Fri, 22 Jun 2012 12:44:52 -0700 (PDT) Received: by 10.182.38.67 with HTTP; Fri, 22 Jun 2012 12:44:52 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Jun 2012 14:44:52 -0500 Message-ID: From: Mary Barnes To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [AVTCORE] Fwd: "Telepresence Tutorial" @ IETF-84 (Please RSVP) 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: Fri, 22 Jun 2012 19:44:53 -0000 ---------- Forwarded message ---------- From: Mary Barnes Date: Fri, Jun 22, 2012 at 2:44 PM Subject: Fwd: "Telepresence Tutorial" @ IETF-84 (Please RSVP) To: rai@ietf.org Cc: mmusic@ietf.org, avtcore@ietf.org, DISPATCH Hi all, Apologies to the many of you that are receiving this multiple times. Unfortunately, the RAI list is not a superset of participants in WGs that might be interested in this. =A0Folks that aren't on the RAI list might want to subscribe here: https://www.ietf.org/mailman/listinfo/rai We are planning a lunchtime tutorial on Monday, July 30th. =A0The primary objective is to provide more background on telepresence as well as an update of the work in CLUE to the broader RAI and IETF community. =A0This will hopefully facilitate the process of completing the CLUE protocol work as it gets broader community review. Here's the proposed outline: 1) Introduction to telepresence 2) Example telepresence scenarios 3) Introduction to the CLUE work 4) High level introduction of framework 5) One or two use cases as examples of how the CLUE framework is realized - showing how existing protocols (e.g., SDP, RTP) are integral to the solution along with additional signaling for CLUE. We have reserved a room for around 50 and attendance will be FCFS, so please RSVP ASAP: http://www.doodle.com/mzu3nmdeehkxkiy The deadline to reply is Friday, July 13th, 2012 (5pm Pacific), as we are trying to find a sponsor for lunch (i.e., box lunches). Note, if anyone is willing to sponsor all or even part of the lunch, please let me know ASAP. =A0Also, if you have any dietary restrictions (e.g., vegetarian, etc.), please let me know offline or include a comment in the doodle. http://www.doodle.com/mzu3nmdeehkxkiys Please send any questions/comments to me (or to the CLUE WG mailing list) =A0rather than reply all. Regards, Mary CLUE WG co-chair From magnus.westerlund@ericsson.com Mon Jun 25 01:32:37 2012 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 91E9D21F8475 for ; Mon, 25 Jun 2012 01:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.182 X-Spam-Level: X-Spam-Status: No, score=-106.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 Wb82tEfh3XJ1 for ; Mon, 25 Jun 2012 01:32:33 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2926021F8470 for ; Mon, 25 Jun 2012 01:32:32 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-ec-4fe8221feca3 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 57.39.00702.F1228EF4; Mon, 25 Jun 2012 10:32:31 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.0; Mon, 25 Jun 2012 10:32:30 +0200 Message-ID: <4FE8221E.4040104@ericsson.com> Date: Mon, 25 Jun 2012 10:32:30 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Glen Zorn References: <4fde00ba.8854b40a.5854.12a4@mx.google.com> <4FE3271F.7020506@ericsson.com> <1340314812.649.10.camel@gwz-laptop> In-Reply-To: <1340314812.649.10.camel@gwz-laptop> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvra680gt/gxcfBCxe9qxkt1g/+RKL A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJVx+s9xloKPAhUvf15hbmA8xNvFyMkhIWAi 0fVyMguELSZx4d56ti5GLg4hgVOMEtsbTrBAOMsZJRYdn8YIUsUroC3Rv2gaUIKDg0VAVeLq WVmQMJuAhcTNH41sILaoQLDEtOn32CHKBSVOznwCtkBEQEli4yWQOAcHs4CixKR2SZCwsICl xLezx8BKhARqJI7dnQq2iVPAUOLisdusELdJStxrXw02nllAU6J1+292CFteonnrbGaIXm2J hqYO1gmMQrOQbJ6FpGUWkpYFjMyrGIVzEzNz0svN9VKLMpOLi/Pz9IpTNzECA/jglt8GOxg3 3Rc7xCjNwaIkzqunut9fSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6MR5xExxhTOXoVbl22b vVwuumS+vnfsbdDKCAlBvmXPTC5WbV6j67iv5cCSqrWbz+y75eOdE+v/MODLXbkDJg8OhH6s r9mtWfQ52ff+Pf3ZgbUffr0/kdhVPedo7p20fk6WLbXdznPP//n61FMy69DH5cHfbq57czGH 9Wfw2yNvjcP/X5vz5/UhJZbijERDLeai4kQAQghHZS4CAAA= Cc: "avt@ietf.org" Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 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: Mon, 25 Jun 2012 08:32:37 -0000 Glen, Yes, I know it is a recommendation. The WG chair still need to motivate the exception. But, yes I should have been clearer that it is possible to have 6 authors. But from my perspective as a WG chair, although not shepherd of this doc, I do like the authors to consider if they really should be all six, or if some are more suitable on a contributors list inside the document. Especially if not all authors are going to be responsive in dealing with the comments and especially AUTH48. Cheers Magnus On 2012-06-21 23:40, Glen Zorn wrote: > On Thu, 2012-06-21 at 15:52 +0200, Magnus Westerlund wrote: >> Hi, >> >> This is my WG last call review as an individual. I think there is quite >> a lot to address before this document is ready for publication request. >> >> 1. This document has 6 authors listed. This is one more than the policy >> allows: >> http://www.rfc-editor.org/policy.html#policy.authlist > > From that document: "There is no rigid limit on the size of this set, > but there is likely to be a discussion if the set exceeds five authors, > in which case the right answer is probably to list one editor." It is > perfectly reasonable to disagree with the final (arbitrary) statement, > however; for example, in the case where a long-lived document has an > equally long list of actual authors. Note also that the purpose of the > policy is to both manage the size of the front page header and to > discourage "corporate name-dropping". In this case, 6 authors is only > marginally excessive; whether or not corporate name-dropping is involved > is a question that can only be answered by the authors. > > ... -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ray.vanbrandenburg@tno.nl Mon Jun 25 05:15:50 2012 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 9846C21F8512 for ; Mon, 25 Jun 2012 05:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.79 X-Spam-Level: * X-Spam-Status: No, score=1.79 tagged_above=-999 required=5 tests=[AWL=1.694, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_14=0.6] 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 yAzfY0+-Q4mz for ; Mon, 25 Jun 2012 05:15:46 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0B91E21F8458 for ; Mon, 25 Jun 2012 05:15:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,471,1336341600"; d="scan'208";a="15572623" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1b.tno.nl with ESMTP; 25 Jun 2012 14:15:43 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.152]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0298.004; Mon, 25 Jun 2012 14:15:43 +0200 From: "Brandenburg, R. (Ray) van" To: Magnus Westerlund , "avt@ietf.org" , "draft-ietf-avtcore-idms@tools.ietf.org" Thread-Topic: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 Thread-Index: Ac1MouWNdp+K0jkOQUKLCbWCw+ddRADAXESAAMj08/A= Date: Mon, 25 Jun 2012 12:15:42 +0000 Message-ID: References: <4fde00ba.8854b40a.5854.12a4@mx.google.com> <4FE3271F.7020506@ericsson.com> In-Reply-To: <4FE3271F.7020506@ericsson.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="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 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: Mon, 25 Jun 2012 12:15:50 -0000 Hi Magnus, Many thanks for the very thorough review. You will find my comments inline. Ray -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] = Sent: donderdag 21 juni 2012 15:53 To: avt@ietf.org; draft-ietf-avtcore-idms@tools.ietf.org Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 Hi, This is my WG last call review as an individual. I think there is quite a l= ot to address before this document is ready for publication request. 1. This document has 6 authors listed. This is one more than the policy allows: http://www.rfc-editor.org/policy.html#policy.authlist RvB: See my other mail. 2. Abstract: "This document gives information on an RTCP Packet Type and RTCP XR Block Type including associated SDP parameters for Inter-Destination Media Synchronization (IDMS)." Doesn't it define these packet/block types? RvB: We will change the abstract to reflect the contents more accurately. T= he draft defines the RTCP Packet Type and mandates the use of the ETSI-defi= ned XR Block Type, which is included in the draft for sake of completeness. 3. Section 3: The ladder diagrams first line is wrongly indented. RvB: OK. 3. Section 3. Ladder diagram, maybe this diagram should have some handle, l= ike figure 1 with a label. RvB: OK. 4. Section 3. I am missing discussion on the overview level of clocks. Yes it is present = later, but I think the topic should be introduced already here is section 3. RvB: Good idea. We will include a short section to discuss this. 5. Section 6. I think this section should make it clear how an SC can inclu= de multiple report blocks for different received sources. In general I thin= k this may be a topic that needs to be lifted into the overview. The issue = I see is the following ones. a) Within a multi-party communication session different media senders inclu= de different reference clocks. Thus creating multiple synchronization group= s within the context of one multi-media communication session. b) even if they can agree on using the same clock reference they still need= to enable the fact that an end-point is acting as MSAS for some media sour= ces and SC for others. This should be made more clear. RvB: I agree that these are both valid scenarios. However, I'm not sure whe= ther they pose a problem. In the case where an SC has to report on multiple= groups, it will just send multiple report blocks (possibly concatenated us= ing RTCP rules). Do I miss something here? 6. Section 6 appears to be a normative definition of RTCP XR block type 12.= That block type is registered by IANA as belonging to ETSI 183 063 specifi= cation. Unless we have a formal liasion assigning the change right to IETF = I don't see how we can make an updated normative specification of this XR b= lock type. I see two options. a) IETF are given the change right over the block type b) IETF makes a normative reference to the ETSI specification of the block = type and then simply makes it clear that they only uses SPST=3D1. RvB: I fully agree with the problems of trying to change the specification.= When starting this work, we have therefore decided to go for your route B). 7. Section 6. Assuming that the normative definition will remain and possib= ly also as a clarification to the ETSI specification: This section is not m= aking it sufficient clear that what an SC is supposed to do is to pick one = RTP packet it recevied, then report the values for this particular packet. = I think one should clarify this and also making it clearer what the selecti= on criteria for such a packet is. Should one focus on using maximum delayed= packets, media delayed packets or simply random selection? In addition we = have the rules about picking packets when multiple RTP sequence numbers hav= e the same TS value. I would recommned that one add some paragraphs before = the actual figure definition to discuss this. RvB: Good point. In theory it shouldn't really matter. Up to now, we have b= een assuming random selection, just picking a packet when the RTCP rules al= low you to send a report. I will check with my co-authors to see whether th= ey still think this is good enough. I will come back to you on this one. 8. Section 6, PT field definition. This is not making clear that one shall = report the PT of the packet one is reporting on. RvB: Ok. 9. Section 6. Media Stream Correlation Identifier: 32 bits. This identifier is used to correlate synchronized media streams. The value 0 (all bits are set "0") indicates that this field is empty. The value 2^32-1 (all bits are set "1") is reserved for future use. If the RTCP Packet Sender is an SC (SPST=3D1) or an MSAS (SPST=3D2), then the Media Stream Correlation Identifier maps on the Synchronization Group Identifier (SyncGroupId) to which the report applies. It is not clear what "maps" means here. Considering that the field appears = to carry the full syncgroupID I think another formulation shall be used. RvB: We will rephrase this paragraph to make it more clear. 10. Section 6. "To solve this, an SC SHOULD report on RTP packets in which a certain RTP timestamp shows up for the first time." Does this means with the lowest sequence number or the packet first to arri= ve with that TS? RvB: The lowest sequence. We will clarify this sentence. 11. Section 7 Title "RTCP Packet Type for IDMS (IDMS report)" Why is the packet used to distribute the intended playout timing called a "= report". This is very confusing considering that the XR is a report also. RvB: Sorry, you're right. We'll come up with a better name. 12. Section 7. SSRC: 32 bits. The SSRC of the media source SHALL be set to the value of the SSRC identifier carried in the RTP header [RFC3550] of the RTP packet to which the RTCP IDMS packet relates. First of all I assume this field definition is for "SSRC of media source" f= ield. RvB: Correct a. What isn't clear is if it is at all valid that another SSRC "SSRC of pac= ket sender" than the "SSRC of media source" is allowed and shall be conside= red valid. RvB: We have always assumed the SSRC of Media Source scenario. Do you think= there is a good reason to support 'SSRC of packet sender' as well? b. Secondly, when an end-point has multiple sources in the same RTP session= to send it appears they need to send multiple RTCP packets. RvB: Do you mean a scenario where one source sends multiple RTP streams (e.= g. audio and video). In that case, it is only necessary to do IDMS for one = stream. The rest is lip-sync. The Media-level SDP part describes which stre= am to perform IDMS for. I will check with my co-authors whether they think = it is useful to recommend either audio or video streams here for this purpo= se. = 13. Section 7. It is not clear if there are any restrictions on the values to be included = in the RTCP packet. Must the sender of it include information for a already= sent packet, a future packet or can it even be a virtual packet that is ne= ver sent? I understand that one can scale the figures in this packet to determine wha= t the correct value should be given a received RTP packet and its timestamp= . But, are I allowed to calculate a correct time value a year into the futu= re that is then expected to be scaled back. Or is the RTP timestamp value i= ncluded in the packet in itself an indication for when this information was= current? RvB: Good point. Because RTP timestamps wrap around, choosing a time far in= to future may cause problems. So indeed, the timestamp chosen needs to be a= (relatively) current one. We will change the section to reflect this. = 14. Section 8. [I-D.draft-williams-avtcore-clksrc] defines a set of SDP parameters for signaling the clock synchronization source or sources available to and used by the individual receivers. Using these paramenters, an SC can indicate which synchronization source is being used at the moment, the last time the SC synchronized with this source and the synchronization frequency. An SC can also indicate any other synchronization sources available to it. This allows multiple SCs in an IDMS session to use the same or a similar clock source for their session. So the clksrc draft appear to indended to define the usage of a=3Dssrc to m= ake it clear which clock source a particular SSRC uses. What isn't clear fr= om this text is that when providing reporting that all nodes sending a repo= rt or a configuration must use their view of that particular clock source. = I think the implications of having multiple clock sources in an RTP session= must be made clearer. As the used clock comes into play both when configur= ing, reporting and adjusting time scales for playout. RvB: I'm not completely following you here. The synchronization source ment= ioned here is a wall clock source (e.g. NTP), and not a media clock source.= The reference to the clcksrc document is just to provide the reader with t= he means to perform clock synchronization (and thus improve the accuracy of= IDMS). Does this help? = 15. Section 9: SyncGroupId =3D 1*DIGIT ; Numerical value from 0 through 4294967294 As the syncgroupID is limited to 10 digits, why not make that clear in the = ABNF also using 1*10DIGIT as the definition. Applies also to Section 10. RvB: Ok. 16. Section 11. As someone else noted. This section really needs to be split into Offer/Ans= wer rules and one on TISPAN interop. RvB: Agree. We will change this in the next iteration. 16. Section 11. Offer/Answer rules It is not clear how one deals with the potential existence of multiple sync= groups or how the ID is negotiated. Especially when you in a multi-party n= egotiate with an application server. I also think it should make clear how it works in declarative cases, like R= TSP SDPs. RvB: We will take up this point in the new version (see previous comment). = 17. Section 14. This IANA registration is insufficient. It needs to be more precise in whic= h regestries that are to be used. RvB: Ok. Thanks for you examples. = To my understand the following actions are required: register a media level SDP attribute: This is okay considering the template= but one could clarify that the registry intended is the one titled "att-fi= eld (media level only)" http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml#sdp-param= eters-9 One RTCP Control Packet types (PT): http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml#rtp-param= eters-3 And if the XR block type is to be normatively defined by this document then= two registrations are needed: - New or update of RTCP XR Block Type http://www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr-block-types.xml - Add the XR SDP parameter: http://www.iana.org/assignments/rtcp-xr-sdp-parameters/rtcp-xr-sdp-paramete= rs.xml 18. References. Should [I-D.draft-gross-leap-second] be normative? It is not written in a RFC 2119 style an requirement to take this document = into account, so maybe informative is correct. RvB: I propose going for informative. The leap-second draft is just a way o= f increasing the accuracy of IDMS. And since it is meant as an update to RF= C3550, can be considered part of RTCP and not specifically targeted at IDMS. Cheers Magnus On 2012-06-17 18:04, Roni Even wrote: > Hi, > = > I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avt= core-idms-05 , RTCP for inter-destination media synchronization. > = > = > = > The WGLC will end on July 10th, 2012 > = > = > = > Please review the draft and send comments to the list. > = > = > = > For the draft authors; Are you aware of any IPR that applies to = > draft-ietf-avtcore-idms-05? If so, > = > has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3= 979, 4879, 3669 and 5378 for more details)? > = > The above question is needed for the document write-up when sent to publi= cation. > = > = > = > Thanks > = > = > = > Roni Even > = > AVTcore co-chair > = > = > = -- = Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From Internet-Drafts@ietf.org Tue Jun 26 13:21:17 2012 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 E58B911E80D5; Tue, 26 Jun 2012 13:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Bk-QEsCQN+4m; Tue, 26 Jun 2012 13:21:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6E611E809C; Tue, 26 Jun 2012 13:21:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120626202117.809.18295.idtracker@ietfa.amsl.com> Date: Tue, 26 Jun 2012 13:21:17 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D ACTION:draft-ietf-avtcore-srtp-aes-gcm-01.txt 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, 26 Jun 2012 20:21:18 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. Title : AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) Author(s) : D. McGrew, et al Filename : draft-ietf-avtcore-srtp-aes-gcm Pages : 24 Date : June 26, 2012 This document defines how AES-GCM, AES-CCM, and other Authenticated Encryption with Associated Data (AEAD) algorithms can be used to provide confidentiality and data authentication mechanisms in the SRTP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-srtp-aes-gcm-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avtcore-srtp-aes-gcm"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-06-26132117.I-D@ietf.org> --NextPart-- From ray.vanbrandenburg@tno.nl Wed Jun 27 02:04:32 2012 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 2386621F8668 for ; Wed, 27 Jun 2012 02:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.302 X-Spam-Level: * X-Spam-Status: No, score=1.302 tagged_above=-999 required=5 tests=[AWL=1.806, 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 UUarLm7U8tqu for ; Wed, 27 Jun 2012 02:04:31 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1D94E21F865C for ; Wed, 27 Jun 2012 02:04:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,483,1336341600"; d="scan'208";a="71304535" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 27 Jun 2012 11:04:29 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.152]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0298.004; Wed, 27 Jun 2012 11:04:29 +0200 From: "Brandenburg, R. (Ray) van" To: Magnus Westerlund , Glen Zorn Thread-Topic: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 Thread-Index: Ac1MouWNdp+K0jkOQUKLCbWCw+ddRADAXESAABBVagAArafTAABpsX1w Date: Wed, 27 Jun 2012 09:04:29 +0000 Message-ID: References: <4fde00ba.8854b40a.5854.12a4@mx.google.com> <4FE3271F.7020506@ericsson.com> <1340314812.649.10.camel@gwz-laptop> <4FE8221E.4040104@ericsson.com> In-Reply-To: <4FE8221E.4040104@ericsson.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.153] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 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: Wed, 27 Jun 2012 09:04:32 -0000 SGkgR2xlbi9NYWdudXMsDQoNCkFzIGF1dGhvciBvZiB0aGUgZHJhZnQsIGFsbCBJIGNhbiBzYXkg aXMgdGhhdCBhbGwgdGhlIGF1dGhvcnMgd2hvIGFyZSBvbiB0aGUgZHJhZnQgcmlnaHQgbm93ICh3 ZSd2ZSByZW1vdmVkIHNvbWUgcGVvcGxlIGJldHdlZW4gdGhlIC0wMSBhbmQgLTAyIHZlcnNpb24g Zm9yIGV4YWN0bHkgdGhpcyByZWFzb24pIGhhdmUgbWFkZSBzaWduaWZpY2FudCBjb250cmlidXRp b25zIGFuZCBhcmUgYWN0aXZlbHkgaW52b2x2ZWQsIHdoZXRoZXIgdGhhdCBhbGxvd3MgdXMgdG8g ZXhwYW5kIHRoZSBudW1iZXIgb2YgYXV0aG9ycyBiZXlvbmQgdGhlIGxpbWl0IG9mIDUsIEkgY2Fu J3Qgc2F5LiBJIHdpbGwgbGVhdmUgdGhhdCBkZWNpc2lvbiB1cCB0byB0aGUgZG9jdW1lbnQgc2hl cGhlcmQgYW5kIHRoZSBXRyBjaGFpcnMuDQoNClRoYW5rcywNCg0KUmF5DQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGF2dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXZ0 LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYWdudXMgV2VzdGVybHVuZA0KU2VudDog bWFhbmRhZyAyNSBqdW5pIDIwMTIgMTA6MzMNClRvOiBHbGVuIFpvcm4NCkNjOiBhdnRAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gV0dMQyBvbiBkcmFmdC1pZXRmLWF2dGNvcmUtaWRt cy0wNQ0KDQpHbGVuLA0KDQpZZXMsIEkga25vdyBpdCBpcyBhIHJlY29tbWVuZGF0aW9uLiBUaGUg V0cgY2hhaXIgc3RpbGwgbmVlZCB0byBtb3RpdmF0ZSB0aGUgZXhjZXB0aW9uLiBCdXQsIHllcyBJ IHNob3VsZCBoYXZlIGJlZW4gY2xlYXJlciB0aGF0IGl0IGlzIHBvc3NpYmxlIHRvIGhhdmUgNiBh dXRob3JzLiBCdXQgZnJvbSBteSBwZXJzcGVjdGl2ZSBhcyBhIFdHIGNoYWlyLCBhbHRob3VnaCBu b3Qgc2hlcGhlcmQgb2YgdGhpcyBkb2MsIEkgZG8gbGlrZSB0aGUgYXV0aG9ycyB0byBjb25zaWRl ciBpZiB0aGV5IHJlYWxseSBzaG91bGQgYmUgYWxsIHNpeCwgb3IgaWYgc29tZSBhcmUgbW9yZSBz dWl0YWJsZSBvbiBhIGNvbnRyaWJ1dG9ycyBsaXN0IGluc2lkZSB0aGUgZG9jdW1lbnQuIEVzcGVj aWFsbHkgaWYgbm90IGFsbCBhdXRob3JzIGFyZSBnb2luZyB0byBiZSByZXNwb25zaXZlIGluIGRl YWxpbmcgd2l0aCB0aGUgY29tbWVudHMgYW5kIGVzcGVjaWFsbHkgQVVUSDQ4Lg0KDQpDaGVlcnMN Cg0KTWFnbnVzDQoNCk9uIDIwMTItMDYtMjEgMjM6NDAsIEdsZW4gWm9ybiB3cm90ZToNCj4gT24g VGh1LCAyMDEyLTA2LTIxIGF0IDE1OjUyICswMjAwLCBNYWdudXMgV2VzdGVybHVuZCB3cm90ZToN Cj4+IEhpLA0KPj4NCj4+IFRoaXMgaXMgbXkgV0cgbGFzdCBjYWxsIHJldmlldyBhcyBhbiBpbmRp dmlkdWFsLiBJIHRoaW5rIHRoZXJlIGlzIA0KPj4gcXVpdGUgYSBsb3QgdG8gYWRkcmVzcyBiZWZv cmUgdGhpcyBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24gcmVxdWVzdC4NCj4+DQo+ PiAxLiBUaGlzIGRvY3VtZW50IGhhcyA2IGF1dGhvcnMgbGlzdGVkLiBUaGlzIGlzIG9uZSBtb3Jl IHRoYW4gdGhlIA0KPj4gcG9saWN5DQo+PiBhbGxvd3M6DQo+PiBodHRwOi8vd3d3LnJmYy1lZGl0 b3Iub3JnL3BvbGljeS5odG1sI3BvbGljeS5hdXRobGlzdA0KPiANCj4gRnJvbSB0aGF0IGRvY3Vt ZW50OiAiVGhlcmUgaXMgbm8gcmlnaWQgbGltaXQgb24gdGhlIHNpemUgb2YgdGhpcyBzZXQsIA0K PiBidXQgdGhlcmUgaXMgbGlrZWx5IHRvIGJlIGEgZGlzY3Vzc2lvbiBpZiB0aGUgc2V0IGV4Y2Vl ZHMgZml2ZSANCj4gYXV0aG9ycywgaW4gd2hpY2ggY2FzZSB0aGUgcmlnaHQgYW5zd2VyIGlzIHBy b2JhYmx5IHRvIGxpc3Qgb25lIA0KPiBlZGl0b3IuIiAgSXQgaXMgcGVyZmVjdGx5IHJlYXNvbmFi bGUgdG8gZGlzYWdyZWUgd2l0aCB0aGUgZmluYWwgDQo+IChhcmJpdHJhcnkpIHN0YXRlbWVudCwg aG93ZXZlcjsgZm9yIGV4YW1wbGUsIGluIHRoZSBjYXNlIHdoZXJlIGEgDQo+IGxvbmctbGl2ZWQg ZG9jdW1lbnQgaGFzIGFuIGVxdWFsbHkgbG9uZyBsaXN0IG9mIGFjdHVhbCBhdXRob3JzLiAgTm90 ZSANCj4gYWxzbyB0aGF0IHRoZSBwdXJwb3NlIG9mIHRoZSBwb2xpY3kgaXMgdG8gYm90aCBtYW5h Z2UgdGhlIHNpemUgb2YgdGhlIA0KPiBmcm9udCBwYWdlIGhlYWRlciBhbmQgdG8gZGlzY291cmFn ZSAiY29ycG9yYXRlIG5hbWUtZHJvcHBpbmciLiAgSW4gDQo+IHRoaXMgY2FzZSwgNiBhdXRob3Jz IGlzIG9ubHkgbWFyZ2luYWxseSBleGNlc3NpdmU7IHdoZXRoZXIgb3Igbm90IA0KPiBjb3Jwb3Jh dGUgbmFtZS1kcm9wcGluZyBpcyBpbnZvbHZlZCBpcyBhIHF1ZXN0aW9uIHRoYXQgY2FuIG9ubHkg YmUgYW5zd2VyZWQgYnkgdGhlIGF1dGhvcnMuDQo+IA0KPiAuLi4NCg0KDQoNCg0KLS0gDQoNCk1h Z251cyBXZXN0ZXJsdW5kDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk11bHRpbWVkaWEgVGVjaG5vbG9naWVz LCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFZNDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpFcmljc3NvbiBBQiAg ICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KRsOkcsO2Z2F0YW4gNiAgICAg ICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KU0UtMTY0IDgwIFN0b2NraG9sbSwg U3dlZGVufCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQpUaGlzIGUtbWFpbCBh bmQgaXRzIGNvbnRlbnRzIGFyZSBzdWJqZWN0IHRvIHRoZSBESVNDTEFJTUVSIGF0IGh0dHA6Ly93 d3cudG5vLm5sL2VtYWlsZGlzY2xhaW1lcgo= From magnus.westerlund@ericsson.com Wed Jun 27 02:36:55 2012 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 9418A21F867C for ; Wed, 27 Jun 2012 02:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.212 X-Spam-Level: X-Spam-Status: No, score=-106.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 3twDWFqRTlby for ; Wed, 27 Jun 2012 02:36:55 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4F021F8678 for ; Wed, 27 Jun 2012 02:36:54 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-a7-4fead4351bf3 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 29.1C.00702.534DAEF4; Wed, 27 Jun 2012 11:36:53 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.0; Wed, 27 Jun 2012 11:36:53 +0200 Message-ID: <4FEAD434.4060906@ericsson.com> Date: Wed, 27 Jun 2012 11:36:52 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Brandenburg, R. (Ray) van" References: <4fde00ba.8854b40a.5854.12a4@mx.google.com> <4FE3271F.7020506@ericsson.com> <1340314812.649.10.camel@gwz-laptop> <4FE8221E.4040104@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+Jvra7plVf+Bu8O6lq87FnJbrF+8iUW i2+brzM6MHvsnHWX3WPJkp9MHgfXXWAOYI7isklJzcksSy3St0vgytg45xR7QZNkxa+jf9kb GJ8KdzFyckgImEhs2TyXGcIWk7hwbz1bFyMXh5DAKUaJi0/PQTnLGSUuPJrMDlLFK6At0X62 gxHEZhFQlWg+8IcVxGYTsJC4+aORDcQWFQiWmDb9HlS9oMTJmU9YQGwRAWuJK5e7wLYxCzhK XLxyDiwuLGAp8e3sMRaIZXcYJf7/P8kEkuAU8JG4eKSfEeI8SYl77avZIJo1JVq3/2aHsOUl mrfOBhsqBHRcQ1MH6wRGoVlIds9C0jILScsCRuZVjMK5iZk56eXmeqlFmcnFxfl5esWpmxiB oX1wy2+DHYyb7osdYpTmYFES59VT3e8vJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXGt5aVf NeuPH576ataVb7N28skf9JNptDw7ZQPrvz8trXd7+68IrJjrcHpZqQ5vAav1Kb+bwb/mqmU1 3dy8oT2r0j91Q7cmW8w3l3C7Er5nb+rs3/7hkDW+uSvFdzfPvBrLj9O2S29etIl5V0ecS7ZO Cs//W/V/FJgc1x7kYQhU/51ntCju1zElluKMREMt5qLiRAADFWFXOwIAAA== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 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: Wed, 27 Jun 2012 09:36:55 -0000 On 2012-06-27 11:04, Brandenburg, R. (Ray) van wrote: > Hi Glen/Magnus, > > As author of the draft, all I can say is that all the authors who are > on the draft right now (we've removed some people between the -01 and > -02 version for exactly this reason) have made significant > contributions and are actively involved, whether that allows us to > expand the number of authors beyond the limit of 5, I can't say. I > will leave that decision up to the document shepherd and the WG > chairs. > If that is the case, I don't see any significant problem with continuing with 6 authors on the list. But it is Roni's decision as Shepherd. Cheers Magnus > Thanks, > > Ray > > > -----Original Message----- From: avt-bounces@ietf.org > [mailto:avt-bounces@ietf.org] On Behalf Of Magnus Westerlund Sent: > maandag 25 juni 2012 10:33 To: Glen Zorn Cc: avt@ietf.org Subject: > Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 > > Glen, > > Yes, I know it is a recommendation. The WG chair still need to > motivate the exception. But, yes I should have been clearer that it > is possible to have 6 authors. But from my perspective as a WG chair, > although not shepherd of this doc, I do like the authors to consider > if they really should be all six, or if some are more suitable on a > contributors list inside the document. Especially if not all authors > are going to be responsive in dealing with the comments and > especially AUTH48. > > Cheers > > Magnus > > On 2012-06-21 23:40, Glen Zorn wrote: >> On Thu, 2012-06-21 at 15:52 +0200, Magnus Westerlund wrote: >>> Hi, >>> >>> This is my WG last call review as an individual. I think there is >>> quite a lot to address before this document is ready for >>> publication request. >>> >>> 1. This document has 6 authors listed. This is one more than the >>> policy allows: >>> http://www.rfc-editor.org/policy.html#policy.authlist >> >> From that document: "There is no rigid limit on the size of this >> set, but there is likely to be a discussion if the set exceeds five >> authors, in which case the right answer is probably to list one >> editor." It is perfectly reasonable to disagree with the final >> (arbitrary) statement, however; for example, in the case where a >> long-lived document has an equally long list of actual authors. >> Note also that the purpose of the policy is to both manage the size >> of the front page header and to discourage "corporate >> name-dropping". In this case, 6 authors is only marginally >> excessive; whether or not corporate name-dropping is involved is a >> question that can only be answered by the authors. >> >> ... > > > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From bill.wu@huawei.com Wed Jun 27 20:08:50 2012 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 7705411E81AF for ; Wed, 27 Jun 2012 20:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.835 X-Spam-Level: X-Spam-Status: No, score=-3.835 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] 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 63523UaFNGig for ; Wed, 27 Jun 2012 20:08:49 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id EDEA711E81AE for ; Wed, 27 Jun 2012 20:08:48 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHN90771; Wed, 27 Jun 2012 23:08:48 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 27 Jun 2012 20:03:46 -0700 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 27 Jun 2012 20:03:43 -0700 Received: from w53375 (10.138.41.149) by szxeml410-hub.china.huawei.com (10.82.67.137) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 28 Jun 2012 11:03:31 +0800 Message-ID: <111C724E6D4143EA8F5D87DAD4BD6918@china.huawei.com> From: Qin Wu To: Magnus Westerlund , , References: <4fde00ba.8854b40a.5854.12a4@mx.google.com> <4FE3271F.7020506@ericsson.com> Date: Thu, 28 Jun 2012 11:03:30 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 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: Thu, 28 Jun 2012 03:08:50 -0000 SGksDQpJIGhhdmUgcmV2aWV3ZWQgWFIgQmxvY2sgYXNwZWN0IGFuZCBpdCBzZWVtcyBJQU5BIGhh cyBhbHJlYWR5IGFsbG9jYXRlZCBCbG9jayBUeXBlIDEyIHRvIHRoaXMgSURNUyBYUiBCbG9jay4g DQpodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3J0Y3AteHItYmxvY2stdHlwZXMvcnRj cC14ci1ibG9jay10eXBlcy54bWwNCkkgaGF2ZSBub3QgYmVlbiBhd2FyZSBvZiB0aGlzIGJlZm9y ZS4gSSBhbSB3b25kZXJpbmcgd2hhdCdzIHRoZSBwcm9jZWR1cmUgZm9yIG90aGVyIFNET3MgdG8g YXNrIElFVEYgZm9yIElBTkEgcmVnaXN0cnk/DQpTZW5kIExpYWlzb24gc3RhdGVtZW50IG9yIHNv bWV0aGluZyBlbHNlPw0KDQpCZXNpZGVzIHRoaXMsIGJlbG93IGFyZSBhIGZldyBjb21tZW50cyBy ZWxhdGVkIHRvIFhSIEJsb2NrOg0KMS4gU2VjdGlvbiA2LCANCkl0IGlzIGJldHRlciB0byBudW1i ZXIgdGhlIGZpZ3VyZSBpbiB0aGUgc2VjdGlvbiA2IHdpdGggYSB0aXRsZS4NCjIuIFNlY3Rpb24g NiwgZmlndXJlDQpJdCBpcyB1bnVzdWFsIHRvIHJlc2V2ZSBzb21lIGJpdHMgaW4gdGhlIG1pZGRs ZSBvZiAidHlwZSBzcGVjaWZpYyBmaWVsZCIgYWZ0ZXIgQmxvY2sgVHlwZSAoQlQpIGZpZWxkLg0K V2h5IG5vdCBtb3ZlIFAgYml0IGJlZm9yZSByZXNldmVkIGJpdHMgaW4gdGhpcyBmaWVsZC4NCjMu IFNlY3Rpb24gNiwgU1BTVCBmaWVsZA0KRm9yIFNQU1QgPTIsIGl0IGlzIGJldHRlciB0byBwb2lu dCBvdXQgdGhlIHBhY2tldCBzZW5kZXIgaXMgTWVkaWEgU3luY2hyb25pemF0aW9uIEFwcGxpY2F0 aW9uIFNlcnZlciAoTVNBUykNCnRvIGdldCBpbiBsaW5lIHdpdGggU1BTVCA9MTsNCjQuIFNlY3Rp b24gNiwgUGF5bG9hZCBUeXBlIChQVCkNClBheWxvYWQgVHlwZSAoUFQpIGFuZCBQYWNrZXQgVHlw ZSAoUFQpIGFyZSBkZWZpbmVkIGluIHRoZSBzYW1lIFhSIEJsb2NrIGFuZCBoYXMgdGhlIHNhbWUg c2hvcnQgbmFtZSwNCml0IGlzIHF1aXRlIGNvbmZ1c2luZy4gU3VnZ2VzdCB0byBkaXN0aW5jdCB0 aGVtIGluIHRoZSBYUiBCTG9jayBmb3JtYXQuDQoNCjUuIFNlY3Rpb24gNiwgUGF5bG9hZCBUeXBl IChQVCkNCldoeSBTeW5jaHJvbml6YXRpb24gQ2xpZW50IChTQykgc2hvdWxkIHNlbmQgUGF5bG9h ZCBUeXBlIGluIHRoZSBYUiBCbG9jayBtZXNzYWdlIHRvIE1lZGlhIFN5bmNocm9uaXphdGlvbiBB cHBsaWNhdGlvbiBTZXJ2ZXIgKE1TQVMpDQp3aGlsZSBNU0FTIGRvZXMgbm90IG5lZWQgdG8gc2Vu ZCBQYXlsb2FkIFR5cGUgaW4gdGhlIElETVMgUlRDUCBtZXNzYWdlIHRvICBTQz8NCkl0IHNlZW1z IHlvdSBpbmRpY2F0ZSBNU0FTIHNob3VsZCBoYW5kbGUgdmFyaW91cyBwYXlsb2FkIFR5cGUgc2Vu dCBmcm9tIGRpZmZlcmVudCBTQ3M/IEhvdyBNU0FTIHByb2NzcyBQYXlsb2FkIFR5cGU/IFRoZSBQ YXlsb2FkIFR5cGUgZGlmZmVyZW5jZSANCmVhY2ggU0MgaXMgdXNpbmcgYWZmZWN0IHRoZSB0aW1l c3RhbXBzIGNhcnJpZWQgaW4gdGhlIElETVMgUlRDUCBwYWNrZXQ/DQoNCkkgYW0gd29uZGVyaW5n IGlmIGl0IGlzIHJlYWxseSBuZWNlc3NhcnkgdG8gYWxsb3cgWFIgQmxvY2sgY2FycnkgUGF5bG9h ZCBUeXBlPw0KDQo2LiBTZWN0aW9uIDYsIFNTUkMgb2YgbWVkaWEgc291cmNlIGZpZWxkDQpUbyBn ZXQgaW4gbGluZSB3aXRoIHRoZSBleGlzdGluZyBSVENQIFhSIEJsb2NrLCBpdCBpcyBiZXR0ZXIg cHV0IFNTUkMgb2YgbWVkaWEgc291cmNlIGZpZWxkIHJpZ2h0IGFmdGVyIHJlcG9ydCBCbG9jayBo ZWFkZXIgYmVmb3JlIFBheWxvYWQgVHlwZSBmaWxlZC4gDQoNCjcuIFNlY3Rpb24gNiwgUGFja2V0 IFByZXNlbnRlZCBOVFAgdGltZXN0YW1wIGZpZWxkOg0KV2h5IHRoZSBzaXplIG9mIFBhY2tldCBQ cmVzZW50ZWQgTlRQIHRpbWVzdGFtcCBmaWVsZCBpbiB0aGUgSURNUyBYUiBibG9jayBpcyAzMiBi aXQgd2hpbGUgdGhlIHNpemUgb2YgUGFja2V0IFByZXNlbnRlZCBOVFAgdGltZXN0YW1wIGZpZWxk IGluIHRoZSBJRE1TIFJUQ1AgcGFja2V0DQogaXMgNjQgYml0PyBJdCBpcyBiZXR0ZXIgdG8gY2xh cmlmeSB0aGlzIGluIHRoZSBkb2N1bWVudD8NCg0KOCBTZWN0aW9uIDYsIE1lZGlhIFN0cmVhbSBD b3JyZWxhdGlvbiBJZGVudGlmaWVyIGZpZWxkOg0KSXQgbG9va3MgdGhlIHZhbHVlIG9mIE1lZGlh IFN0cmVhbSBDb3JyZWxhdGlvbiBJZGVudGlmaWVyICBpcyBzYW1lIGFzIFN5bmNHcm91cElkLA0K U3luR3JvdXBJRCBpcyBzaWduYWxlZCB1c2luZyBTRFAgYW5kIFNDIG9yIE1TQVMganVzdCB1c2Ug cHV0IFN5bmNHcm91cElEIA0KaW50byBNZWRpYSBTdHJlYW0gQ29ycmVsYXRpb24gSWRlbnRpZmll ciBmaWVsZA0KSSBhbSB3b25kZXJpbmcgd2h5IG5vdCB1c2UgdGhlIHNhbWUgbmFtZSBmb3IgdGhl bT8gVGhhdCBpcyB0byBzYXksIGNoYW5nZSBNZWRpYSBTdHJlYW0gQ29ycmVsYXRpb24gZmllbGQg dG8gU3luY0dyb3VwSWQuDQoNClJlZ2FyZHMhDQotUWluDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tIA0KRnJvbTogIk1hZ251cyBXZXN0ZXJsdW5kIiA8bWFnbnVzLndlc3Rlcmx1bmRAZXJp Y3Nzb24uY29tPg0KVG86IDxhdnRAaWV0Zi5vcmc+OyA8ZHJhZnQtaWV0Zi1hdnRjb3JlLWlkbXNA dG9vbHMuaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgSnVuZSAyMSwgMjAxMiA5OjUyIFBNDQpT dWJqZWN0OiBSZTogW0FWVENPUkVdIFdHTEMgb24gZHJhZnQtaWV0Zi1hdnRjb3JlLWlkbXMtMDUN Cg0KDQpIaSwNCg0KVGhpcyBpcyBteSBXRyBsYXN0IGNhbGwgcmV2aWV3IGFzIGFuIGluZGl2aWR1 YWwuIEkgdGhpbmsgdGhlcmUgaXMgcXVpdGUNCmEgbG90IHRvIGFkZHJlc3MgYmVmb3JlIHRoaXMg ZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIHJlcXVlc3QuDQoNCjEuIFRoaXMgZG9j dW1lbnQgaGFzIDYgYXV0aG9ycyBsaXN0ZWQuIFRoaXMgaXMgb25lIG1vcmUgdGhhbiB0aGUgcG9s aWN5DQphbGxvd3M6DQpodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3BvbGljeS5odG1sI3BvbGlj eS5hdXRobGlzdA0KDQoyLiBBYnN0cmFjdDoNCiJUaGlzIGRvY3VtZW50IGdpdmVzIGluZm9ybWF0 aW9uIG9uIGFuIFJUQ1AgUGFja2V0IFR5cGUgYW5kIFJUQ1AgWFINCiAgIEJsb2NrIFR5cGUgaW5j bHVkaW5nIGFzc29jaWF0ZWQgU0RQIHBhcmFtZXRlcnMgZm9yIEludGVyLURlc3RpbmF0aW9uDQog ICBNZWRpYSBTeW5jaHJvbml6YXRpb24gKElETVMpLiINCg0KRG9lc24ndCBpdCBkZWZpbmUgdGhl c2UgcGFja2V0L2Jsb2NrIHR5cGVzPw0KDQozLiBTZWN0aW9uIDM6DQoNClRoZSBsYWRkZXIgZGlh Z3JhbXMgZmlyc3QgbGluZSBpcyB3cm9uZ2x5IGluZGVudGVkLg0KDQozLiBTZWN0aW9uIDMuIExh ZGRlciBkaWFncmFtLCBtYXliZSB0aGlzIGRpYWdyYW0gc2hvdWxkIGhhdmUgc29tZQ0KaGFuZGxl LCBsaWtlIGZpZ3VyZSAxIHdpdGggYSBsYWJlbC4NCg0KNC4gU2VjdGlvbiAzLg0KSSBhbSBtaXNz aW5nIGRpc2N1c3Npb24gb24gdGhlIG92ZXJ2aWV3IGxldmVsIG9mIGNsb2Nrcy4gWWVzIGl0IGlz DQpwcmVzZW50IGxhdGVyLCBidXQgSSB0aGluayB0aGUgdG9waWMgc2hvdWxkIGJlIGludHJvZHVj ZWQgYWxyZWFkeSBoZXJlDQppcyBzZWN0aW9uIDMuDQoNCjUuIFNlY3Rpb24gNi4gSSB0aGluayB0 aGlzIHNlY3Rpb24gc2hvdWxkIG1ha2UgaXQgY2xlYXIgaG93IGFuIFNDIGNhbg0KaW5jbHVkZSBt dWx0aXBsZSByZXBvcnQgYmxvY2tzIGZvciBkaWZmZXJlbnQgcmVjZWl2ZWQgc291cmNlcy4gSW4N CmdlbmVyYWwgSSB0aGluayB0aGlzIG1heSBiZSBhIHRvcGljIHRoYXQgbmVlZHMgdG8gYmUgbGlm dGVkIGludG8gdGhlDQpvdmVydmlldy4gVGhlIGlzc3VlIEkgc2VlIGlzIHRoZSBmb2xsb3dpbmcg b25lcy4NCg0KYSkgV2l0aGluIGEgbXVsdGktcGFydHkgY29tbXVuaWNhdGlvbiBzZXNzaW9uIGRp ZmZlcmVudCBtZWRpYSBzZW5kZXJzDQppbmNsdWRlIGRpZmZlcmVudCByZWZlcmVuY2UgY2xvY2tz LiBUaHVzIGNyZWF0aW5nIG11bHRpcGxlDQpzeW5jaHJvbml6YXRpb24gZ3JvdXBzIHdpdGhpbiB0 aGUgY29udGV4dCBvZiBvbmUgbXVsdGktbWVkaWENCmNvbW11bmljYXRpb24gc2Vzc2lvbi4NCg0K YikgZXZlbiBpZiB0aGV5IGNhbiBhZ3JlZSBvbiB1c2luZyB0aGUgc2FtZSBjbG9jayByZWZlcmVu Y2UgdGhleSBzdGlsbA0KbmVlZCB0byBlbmFibGUgdGhlIGZhY3QgdGhhdCBhbiBlbmQtcG9pbnQg aXMgYWN0aW5nIGFzIE1TQVMgZm9yIHNvbWUNCm1lZGlhIHNvdXJjZXMgYW5kIFNDIGZvciBvdGhl cnMuIFRoaXMgc2hvdWxkIGJlIG1hZGUgbW9yZSBjbGVhci4NCg0KNi4gU2VjdGlvbiA2IGFwcGVh cnMgdG8gYmUgYSBub3JtYXRpdmUgZGVmaW5pdGlvbiBvZiBSVENQIFhSIGJsb2NrIHR5cGUNCjEy LiBUaGF0IGJsb2NrIHR5cGUgaXMgcmVnaXN0ZXJlZCBieSBJQU5BIGFzIGJlbG9uZ2luZyB0byBF VFNJIDE4MyAwNjMNCnNwZWNpZmljYXRpb24uIFVubGVzcyB3ZSBoYXZlIGEgZm9ybWFsIGxpYXNp b24gYXNzaWduaW5nIHRoZSBjaGFuZ2UNCnJpZ2h0IHRvIElFVEYgSSBkb24ndCBzZWUgaG93IHdl IGNhbiBtYWtlIGFuIHVwZGF0ZWQgbm9ybWF0aXZlDQpzcGVjaWZpY2F0aW9uIG9mIHRoaXMgWFIg YmxvY2sgdHlwZS4gSSBzZWUgdHdvIG9wdGlvbnMuDQoNCmEpIElFVEYgYXJlIGdpdmVuIHRoZSBj aGFuZ2UgcmlnaHQgb3ZlciB0aGUgYmxvY2sgdHlwZQ0KDQpiKSBJRVRGIG1ha2VzIGEgbm9ybWF0 aXZlIHJlZmVyZW5jZSB0byB0aGUgRVRTSSBzcGVjaWZpY2F0aW9uIG9mIHRoZQ0KYmxvY2sgdHlw ZSBhbmQgdGhlbiBzaW1wbHkgbWFrZXMgaXQgY2xlYXIgdGhhdCB0aGV5IG9ubHkgdXNlcyBTUFNU PTEuDQoNCjcuIFNlY3Rpb24gNi4gQXNzdW1pbmcgdGhhdCB0aGUgbm9ybWF0aXZlIGRlZmluaXRp b24gd2lsbCByZW1haW4gYW5kDQpwb3NzaWJseSBhbHNvIGFzIGEgY2xhcmlmaWNhdGlvbiB0byB0 aGUgRVRTSSBzcGVjaWZpY2F0aW9uOiBUaGlzIHNlY3Rpb24NCmlzIG5vdCBtYWtpbmcgaXQgc3Vm ZmljaWVudCBjbGVhciB0aGF0IHdoYXQgYW4gU0MgaXMgc3VwcG9zZWQgdG8gZG8gaXMNCnRvIHBp Y2sgb25lIFJUUCBwYWNrZXQgaXQgcmVjZXZpZWQsIHRoZW4gcmVwb3J0IHRoZSB2YWx1ZXMgZm9y IHRoaXMNCnBhcnRpY3VsYXIgcGFja2V0LiBJIHRoaW5rIG9uZSBzaG91bGQgY2xhcmlmeSB0aGlz IGFuZCBhbHNvIG1ha2luZyBpdA0KY2xlYXJlciB3aGF0IHRoZSBzZWxlY3Rpb24gY3JpdGVyaWEg Zm9yIHN1Y2ggYSBwYWNrZXQgaXMuIFNob3VsZCBvbmUNCmZvY3VzIG9uIHVzaW5nIG1heGltdW0g ZGVsYXllZCBwYWNrZXRzLCBtZWRpYSBkZWxheWVkIHBhY2tldHMgb3Igc2ltcGx5DQpyYW5kb20g c2VsZWN0aW9uPyBJbiBhZGRpdGlvbiB3ZSBoYXZlIHRoZSBydWxlcyBhYm91dCBwaWNraW5nIHBh Y2tldHMNCndoZW4gbXVsdGlwbGUgUlRQIHNlcXVlbmNlIG51bWJlcnMgaGF2ZSB0aGUgc2FtZSBU UyB2YWx1ZS4gSSB3b3VsZA0KcmVjb21tbmVkIHRoYXQgb25lIGFkZCBzb21lIHBhcmFncmFwaHMg YmVmb3JlIHRoZSBhY3R1YWwgZmlndXJlDQpkZWZpbml0aW9uIHRvIGRpc2N1c3MgdGhpcy4NCg0K OC4gU2VjdGlvbiA2LCBQVCBmaWVsZCBkZWZpbml0aW9uLiBUaGlzIGlzIG5vdCBtYWtpbmcgY2xl YXIgdGhhdCBvbmUNCnNoYWxsIHJlcG9ydCB0aGUgUFQgb2YgdGhlIHBhY2tldCBvbmUgaXMgcmVw b3J0aW5nIG9uLg0KDQo5LiBTZWN0aW9uIDYuDQogICBNZWRpYSBTdHJlYW0gQ29ycmVsYXRpb24g SWRlbnRpZmllcjogMzIgYml0cy4gIFRoaXMgaWRlbnRpZmllciBpcw0KICAgdXNlZCB0byBjb3Jy ZWxhdGUgc3luY2hyb25pemVkIG1lZGlhIHN0cmVhbXMuICBUaGUgdmFsdWUgMCAoYWxsIGJpdHMN CiAgIGFyZSBzZXQgIjAiKSBpbmRpY2F0ZXMgdGhhdCB0aGlzIGZpZWxkIGlzIGVtcHR5LiAgVGhl IHZhbHVlIDJeMzItMQ0KICAgKGFsbCBiaXRzIGFyZSBzZXQgIjEiKSBpcyByZXNlcnZlZCBmb3Ig ZnV0dXJlIHVzZS4gIElmIHRoZSBSVENQDQogICBQYWNrZXQgU2VuZGVyIGlzIGFuIFNDIChTUFNU PTEpIG9yIGFuIE1TQVMgKFNQU1Q9MiksIHRoZW4gdGhlIE1lZGlhDQogICBTdHJlYW0gQ29ycmVs YXRpb24gSWRlbnRpZmllciBtYXBzIG9uIHRoZSBTeW5jaHJvbml6YXRpb24gR3JvdXANCiAgIElk ZW50aWZpZXIgKFN5bmNHcm91cElkKSB0byB3aGljaCB0aGUgcmVwb3J0IGFwcGxpZXMuDQoNCkl0 IGlzIG5vdCBjbGVhciB3aGF0ICJtYXBzIiBtZWFucyBoZXJlLiBDb25zaWRlcmluZyB0aGF0IHRo ZSBmaWVsZA0KYXBwZWFycyB0byBjYXJyeSB0aGUgZnVsbCBzeW5jZ3JvdXBJRCBJIHRoaW5rIGFu b3RoZXIgZm9ybXVsYXRpb24gc2hhbGwNCmJlIHVzZWQuDQoNCjEwLiBTZWN0aW9uIDYuDQoiVG8g c29sdmUNCiAgIHRoaXMsIGFuIFNDIFNIT1VMRCByZXBvcnQgb24gUlRQIHBhY2tldHMgaW4gd2hp Y2ggYSBjZXJ0YWluIFJUUA0KICAgdGltZXN0YW1wIHNob3dzIHVwIGZvciB0aGUgZmlyc3QgdGlt ZS4iDQoNCkRvZXMgdGhpcyBtZWFucyB3aXRoIHRoZSBsb3dlc3Qgc2VxdWVuY2UgbnVtYmVyIG9y IHRoZSBwYWNrZXQgZmlyc3QgdG8NCmFycml2ZSB3aXRoIHRoYXQgVFM/DQoNCjExLiBTZWN0aW9u IDcgVGl0bGUNCiJSVENQIFBhY2tldCBUeXBlIGZvciBJRE1TIChJRE1TIHJlcG9ydCkiDQoNCldo eSBpcyB0aGUgcGFja2V0IHVzZWQgdG8gZGlzdHJpYnV0ZSB0aGUgaW50ZW5kZWQgcGxheW91dCB0 aW1pbmcgY2FsbGVkDQphICJyZXBvcnQiLiBUaGlzIGlzIHZlcnkgY29uZnVzaW5nIGNvbnNpZGVy aW5nIHRoYXQgdGhlIFhSIGlzIGEgcmVwb3J0IGFsc28uDQoNCg0KMTIuIFNlY3Rpb24gNy4NCg0K ICAgU1NSQzogMzIgYml0cy4gIFRoZSBTU1JDIG9mIHRoZSBtZWRpYSBzb3VyY2UgU0hBTEwgYmUg c2V0IHRvIHRoZQ0KICAgdmFsdWUgb2YgdGhlIFNTUkMgaWRlbnRpZmllciBjYXJyaWVkIGluIHRo ZSBSVFAgaGVhZGVyIFtSRkMzNTUwXSBvZg0KICAgdGhlIFJUUCBwYWNrZXQgdG8gd2hpY2ggdGhl IFJUQ1AgSURNUyBwYWNrZXQgcmVsYXRlcy4NCg0KRmlyc3Qgb2YgYWxsIEkgYXNzdW1lIHRoaXMg ZmllbGQgZGVmaW5pdGlvbiBpcyBmb3IgIlNTUkMgb2YgbWVkaWENCnNvdXJjZSIgZmllbGQuDQoN CmEuIFdoYXQgaXNuJ3QgY2xlYXIgaXMgaWYgaXQgaXMgYXQgYWxsIHZhbGlkIHRoYXQgYW5vdGhl ciBTU1JDICJTU1JDIG9mDQpwYWNrZXQgc2VuZGVyIiB0aGFuIHRoZSAiU1NSQyBvZiBtZWRpYSBz b3VyY2UiIGlzIGFsbG93ZWQgYW5kIHNoYWxsIGJlDQpjb25zaWRlcmVkIHZhbGlkLg0KDQpiLiBT ZWNvbmRseSwgd2hlbiBhbiBlbmQtcG9pbnQgaGFzIG11bHRpcGxlIHNvdXJjZXMgaW4gdGhlIHNh bWUgUlRQDQpzZXNzaW9uIHRvIHNlbmQgaXQgYXBwZWFycyB0aGV5IG5lZWQgdG8gc2VuZCBtdWx0 aXBsZSBSVENQIHBhY2tldHMuDQoNCjEzLiBTZWN0aW9uIDcuDQoNCkl0IGlzIG5vdCBjbGVhciBp ZiB0aGVyZSBhcmUgYW55IHJlc3RyaWN0aW9ucyBvbiB0aGUgdmFsdWVzIHRvIGJlDQppbmNsdWRl ZCBpbiB0aGUgUlRDUCBwYWNrZXQuIE11c3QgdGhlIHNlbmRlciBvZiBpdCBpbmNsdWRlIGluZm9y bWF0aW9uDQpmb3IgYSBhbHJlYWR5IHNlbnQgcGFja2V0LCBhIGZ1dHVyZSBwYWNrZXQgb3IgY2Fu IGl0IGV2ZW4gYmUgYSB2aXJ0dWFsDQpwYWNrZXQgdGhhdCBpcyBuZXZlciBzZW50Pw0KDQpJIHVu ZGVyc3RhbmQgdGhhdCBvbmUgY2FuIHNjYWxlIHRoZSBmaWd1cmVzIGluIHRoaXMgcGFja2V0IHRv IGRldGVybWluZQ0Kd2hhdCB0aGUgY29ycmVjdCB2YWx1ZSBzaG91bGQgYmUgZ2l2ZW4gYSByZWNl aXZlZCBSVFAgcGFja2V0IGFuZCBpdHMNCnRpbWVzdGFtcC4gQnV0LCBhcmUgSSBhbGxvd2VkIHRv IGNhbGN1bGF0ZSBhIGNvcnJlY3QgdGltZSB2YWx1ZSBhIHllYXINCmludG8gdGhlIGZ1dHVyZSB0 aGF0IGlzIHRoZW4gZXhwZWN0ZWQgdG8gYmUgc2NhbGVkIGJhY2suIE9yIGlzIHRoZSBSVFANCnRp bWVzdGFtcCB2YWx1ZSBpbmNsdWRlZCBpbiB0aGUgcGFja2V0IGluIGl0c2VsZiBhbiBpbmRpY2F0 aW9uIGZvciB3aGVuDQp0aGlzIGluZm9ybWF0aW9uIHdhcyBjdXJyZW50Pw0KDQoxNC4gU2VjdGlv biA4Lg0KICAgW0ktRC5kcmFmdC13aWxsaWFtcy1hdnRjb3JlLWNsa3NyY10gZGVmaW5lcyBhIHNl dCBvZiBTRFAgcGFyYW1ldGVycw0KICAgZm9yIHNpZ25hbGluZyB0aGUgY2xvY2sgc3luY2hyb25p emF0aW9uIHNvdXJjZSBvciBzb3VyY2VzIGF2YWlsYWJsZQ0KICAgdG8gYW5kIHVzZWQgYnkgdGhl IGluZGl2aWR1YWwgcmVjZWl2ZXJzLiAgVXNpbmcgdGhlc2UgcGFyYW1lbnRlcnMsIGFuDQogICBT QyBjYW4gaW5kaWNhdGUgd2hpY2ggc3luY2hyb25pemF0aW9uIHNvdXJjZSBpcyBiZWluZyB1c2Vk IGF0IHRoZQ0KICAgbW9tZW50LCB0aGUgbGFzdCB0aW1lIHRoZSBTQyBzeW5jaHJvbml6ZWQgd2l0 aCB0aGlzIHNvdXJjZSBhbmQgdGhlDQogICBzeW5jaHJvbml6YXRpb24gZnJlcXVlbmN5LiAgQW4g U0MgY2FuIGFsc28gaW5kaWNhdGUgYW55IG90aGVyDQogICBzeW5jaHJvbml6YXRpb24gc291cmNl cyBhdmFpbGFibGUgdG8gaXQuICBUaGlzIGFsbG93cyBtdWx0aXBsZSBTQ3MgaW4NCiAgIGFuIElE TVMgc2Vzc2lvbiB0byB1c2UgdGhlIHNhbWUgb3IgYSBzaW1pbGFyIGNsb2NrIHNvdXJjZSBmb3Ig dGhlaXINCiAgIHNlc3Npb24uDQoNClNvIHRoZSBjbGtzcmMgZHJhZnQgYXBwZWFyIHRvIGluZGVu ZGVkIHRvIGRlZmluZSB0aGUgdXNhZ2Ugb2YgYT1zc3JjIHRvDQptYWtlIGl0IGNsZWFyIHdoaWNo IGNsb2NrIHNvdXJjZSBhIHBhcnRpY3VsYXIgU1NSQyB1c2VzLiBXaGF0IGlzbid0DQpjbGVhciBm cm9tIHRoaXMgdGV4dCBpcyB0aGF0IHdoZW4gcHJvdmlkaW5nIHJlcG9ydGluZyB0aGF0IGFsbCBu b2Rlcw0Kc2VuZGluZyBhIHJlcG9ydCBvciBhIGNvbmZpZ3VyYXRpb24gbXVzdCB1c2UgdGhlaXIg dmlldyBvZiB0aGF0DQpwYXJ0aWN1bGFyIGNsb2NrIHNvdXJjZS4gSSB0aGluayB0aGUgaW1wbGlj YXRpb25zIG9mIGhhdmluZyBtdWx0aXBsZQ0KY2xvY2sgc291cmNlcyBpbiBhbiBSVFAgc2Vzc2lv biBtdXN0IGJlIG1hZGUgY2xlYXJlci4gQXMgdGhlIHVzZWQgY2xvY2sNCmNvbWVzIGludG8gcGxh eSBib3RoIHdoZW4gY29uZmlndXJpbmcsIHJlcG9ydGluZyBhbmQgYWRqdXN0aW5nIHRpbWUNCnNj YWxlcyBmb3IgcGxheW91dC4NCg0KMTUuIFNlY3Rpb24gOToNCg0KICAgU3luY0dyb3VwSWQgPSAx KkRJR0lUIDsgTnVtZXJpY2FsIHZhbHVlIGZyb20gMCB0aHJvdWdoIDQyOTQ5NjcyOTQNCg0KQXMg dGhlIHN5bmNncm91cElEIGlzIGxpbWl0ZWQgdG8gMTAgZGlnaXRzLCB3aHkgbm90IG1ha2UgdGhh dCBjbGVhciBpbg0KdGhlIEFCTkYgYWxzbyB1c2luZyAxKjEwRElHSVQgYXMgdGhlIGRlZmluaXRp b24uDQoNCkFwcGxpZXMgYWxzbyB0byBTZWN0aW9uIDEwLg0KDQoxNi4gU2VjdGlvbiAxMS4NCg0K QXMgc29tZW9uZSBlbHNlIG5vdGVkLiBUaGlzIHNlY3Rpb24gcmVhbGx5IG5lZWRzIHRvIGJlIHNw bGl0IGludG8NCk9mZmVyL0Fuc3dlciBydWxlcyBhbmQgb25lIG9uIFRJU1BBTiBpbnRlcm9wLg0K DQoxNi4gU2VjdGlvbiAxMS4gT2ZmZXIvQW5zd2VyIHJ1bGVzDQpJdCBpcyBub3QgY2xlYXIgaG93 IG9uZSBkZWFscyB3aXRoIHRoZSBwb3RlbnRpYWwgZXhpc3RlbmNlIG9mIG11bHRpcGxlDQpzeW5j IGdyb3VwcyBvciBob3cgdGhlIElEIGlzIG5lZ290aWF0ZWQuIEVzcGVjaWFsbHkgd2hlbiB5b3Ug aW4gYQ0KbXVsdGktcGFydHkgbmVnb3RpYXRlIHdpdGggYW4gYXBwbGljYXRpb24gc2VydmVyLg0K DQpJIGFsc28gdGhpbmsgaXQgc2hvdWxkIG1ha2UgY2xlYXIgaG93IGl0IHdvcmtzIGluIGRlY2xh cmF0aXZlIGNhc2VzLA0KbGlrZSBSVFNQIFNEUHMuDQoNCjE3LiBTZWN0aW9uIDE0Lg0KDQpUaGlz IElBTkEgcmVnaXN0cmF0aW9uIGlzIGluc3VmZmljaWVudC4gSXQgbmVlZHMgdG8gYmUgbW9yZSBw cmVjaXNlIGluDQp3aGljaCByZWdlc3RyaWVzIHRoYXQgYXJlIHRvIGJlIHVzZWQuDQoNClRvIG15 IHVuZGVyc3RhbmQgdGhlIGZvbGxvd2luZyBhY3Rpb25zIGFyZSByZXF1aXJlZDoNCg0KcmVnaXN0 ZXIgYSBtZWRpYSBsZXZlbCBTRFAgYXR0cmlidXRlOiBUaGlzIGlzIG9rYXkgY29uc2lkZXJpbmcg dGhlDQp0ZW1wbGF0ZSBidXQgb25lIGNvdWxkIGNsYXJpZnkgdGhhdCB0aGUgcmVnaXN0cnkgaW50 ZW5kZWQgaXMgdGhlIG9uZQ0KdGl0bGVkICJhdHQtZmllbGQgIChtZWRpYSBsZXZlbCBvbmx5KSIN Cmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvc2RwLXBhcmFtZXRlcnMvc2RwLXBhcmFt ZXRlcnMueG1sI3NkcC1wYXJhbWV0ZXJzLTkNCg0KDQpPbmUgUlRDUCBDb250cm9sIFBhY2tldCB0 eXBlcyAoUFQpOg0KaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9ydHAtcGFyYW1ldGVy cy9ydHAtcGFyYW1ldGVycy54bWwjcnRwLXBhcmFtZXRlcnMtMw0KDQpBbmQgaWYgdGhlIFhSIGJs b2NrIHR5cGUgaXMgdG8gYmUgbm9ybWF0aXZlbHkgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50DQp0 aGVuIHR3byByZWdpc3RyYXRpb25zIGFyZSBuZWVkZWQ6DQoNCi0gTmV3IG9yIHVwZGF0ZSBvZiBS VENQIFhSIEJsb2NrIFR5cGUNCmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvcnRjcC14 ci1ibG9jay10eXBlcy9ydGNwLXhyLWJsb2NrLXR5cGVzLnhtbA0KLSBBZGQgdGhlIFhSIFNEUCBw YXJhbWV0ZXI6DQpodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3J0Y3AteHItc2RwLXBh cmFtZXRlcnMvcnRjcC14ci1zZHAtcGFyYW1ldGVycy54bWwNCg0KMTguIFJlZmVyZW5jZXMuIFNo b3VsZCBbSS1ELmRyYWZ0LWdyb3NzLWxlYXAtc2Vjb25kXSBiZSBub3JtYXRpdmU/DQpJdCBpcyBu b3Qgd3JpdHRlbiBpbiBhIFJGQyAyMTE5IHN0eWxlIGFuIHJlcXVpcmVtZW50IHRvIHRha2UgdGhp cw0KZG9jdW1lbnQgaW50byBhY2NvdW50LCBzbyBtYXliZSBpbmZvcm1hdGl2ZSBpcyBjb3JyZWN0 Lg0KDQoNCkNoZWVycw0KDQpNYWdudXMNCg0KDQoNCk9uIDIwMTItMDYtMTcgMTg6MDQsIFJvbmkg RXZlbiB3cm90ZToNCj4gSGksDQo+IA0KPiBJIHdvdWxkIGxpa2UgdG8gc3RhcnQgYSBXR0xDIG9u IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXZ0Y29yZS1pZG1zLTA1ICwg UlRDUCBmb3IgaW50ZXItZGVzdGluYXRpb24gbWVkaWEgc3luY2hyb25pemF0aW9uLg0KPiANCj4g IA0KPiANCj4gVGhlIFdHTEMgd2lsbCBlbmQgb24gSnVseSAxMHRoLCAyMDEyDQo+IA0KPiAgDQo+ IA0KPiBQbGVhc2UgcmV2aWV3IHRoZSBkcmFmdCBhbmQgc2VuZCBjb21tZW50cyB0byB0aGUgbGlz dC4NCj4gDQo+ICANCj4gDQo+IEZvciB0aGUgZHJhZnQgYXV0aG9yczsgIEFyZSB5b3UgYXdhcmUg b2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtaWV0Zi1hdnRjb3JlLWlkbXMtMDU/IElm IHNvLA0KPiANCj4gaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0 aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3Ig bW9yZSBkZXRhaWxzKT8NCj4gDQo+IFRoZSBhYm92ZSBxdWVzdGlvbiBpcyBuZWVkZWQgZm9yIHRo ZSBkb2N1bWVudCB3cml0ZS11cCB3aGVuIHNlbnQgdG8gcHVibGljYXRpb24uDQo+IA0KPiAgDQo+ IA0KPiBUaGFua3MNCj4gDQo+ICANCj4gDQo+IFJvbmkgRXZlbg0KPiANCj4gQVZUY29yZSAgY28t Y2hhaXINCj4gDQo+ICANCj4gDQoNCg0KLS0gDQoNCk1hZ251cyBXZXN0ZXJsdW5kDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCk11bHRpbWVkaWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIv VFZNDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpFcmljc3NvbiBBQiAgICAgICAgICAgICAgICB8IFBob25lICAr NDYgMTAgNzE0ODI4Nw0KRuRy9mdhdGFuIDYgICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDcz IDA5NDkwNzkNClNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2Vz dGVybHVuZEBlcmljc3Nvbi5jb20NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBdWRpby9WaWRlbyBUcmFuc3BvcnQg Q29yZSBNYWludGVuYW5jZQ0KYXZ0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2F2dA0K From glenzorn@gmail.com Wed Jun 27 20:24:22 2012 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 1CAE021F8766 for ; Wed, 27 Jun 2012 20:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 vu4mLA3h5Hbs for ; Wed, 27 Jun 2012 20:24:21 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B53CA11E81AE for ; Wed, 27 Jun 2012 20:12:05 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2675617obb.31 for ; Wed, 27 Jun 2012 20:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:organization :date:message-id:mime-version:x-mailer; bh=S2drSvOzT1oW8yqtZYy3CoAdZU45d2reDL6QKYEH0CE=; b=ILLSQbBnJnCAdcN6glONO5d9HyLj+mEF9lhfi4AY6CBhls9BbYqV4s8KAGZwB9wRmZ Nd6+aerxcU2eFIyt53xKs/XELfI/dZwTSEelti0v2O17zR2NWb4mFB+mP3jVakyV1lMA ZtaYakEkbTq4dT29wRMw3D/ANSRhuFw0dddUVmpSgYmizATBASKd4P9d7wkQN/bl4gOH BLIUeRZwLTzVZTOSRBve0sI7ZeAAPpXu7MSsU9mxT440nFRTRf66nJCla4XYaOL5197F 5SgjwwIWx/Gzih/qZ1FEiSbmrT1kBJplb7WYaF8rSr0txc5ht+QlecpyN1e29MP0ug/8 0SuA== Received: by 10.182.139.2 with SMTP id qu2mr228145obb.34.1340853125153; Wed, 27 Jun 2012 20:12:05 -0700 (PDT) Received: from [192.168.1.99] (ppp-110-169-216-206.revip5.asianet.co.th. [110.169.216.206]) by mx.google.com with ESMTPS id u9sm52150314obl.20.2012.06.27.20.12.02 (version=SSLv3 cipher=OTHER); Wed, 27 Jun 2012 20:12:03 -0700 (PDT) From: Glen Zorn To: avt@ietf.org In-Reply-To: <111C724E6D4143EA8F5D87DAD4BD6918@china.huawei.com> References: <4fde00ba.8854b40a.5854.12a4@mx.google.com> <4FE3271F.7020506@ericsson.com> <111C724E6D4143EA8F5D87DAD4BD6918@china.huawei.com> Content-Type: multipart/alternative; boundary="=-SS/CCoVG658yxAQJWhuz" Organization: Network Zen Date: Thu, 28 Jun 2012 10:11:59 +0700 Message-ID: <1340853119.5506.53.camel@gwz-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 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: Thu, 28 Jun 2012 03:24:22 -0000 --=-SS/CCoVG658yxAQJWhuz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2012-06-28 at 11:03 +0800, Qin Wu wrote: > Hi, > I have reviewed XR Block aspect and it seems IANA has already allocated Block Type 12 to this IDMS XR Block. > http://www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr-block-types.xml > I have not been aware of this before. I am wondering what's the procedure for other SDOs to ask IETF for IANA registry? > Send Liaison statement or something else? AFAIK, there is no special procedure; just follow the allocation policy. ... --=-SS/CCoVG658yxAQJWhuz Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 2012-06-28 at 11:03 +0800, Qin Wu wrote: 
Hi,
I have reviewed XR Block aspect and it seems IANA has already allocated Block Type 12 to this IDMS XR Block. 
http://www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr-block-types.xml
I have not been aware of this before. I am wondering what's the procedure for other SDOs to ask IETF for IANA registry?
Send Liaison statement or something else?

AFAIK, there is no special procedure; just follow the allocation policy.

... --=-SS/CCoVG658yxAQJWhuz-- From magnus.westerlund@ericsson.com Wed Jun 27 23:50:30 2012 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 DEB1A11E8196 for ; Wed, 27 Jun 2012 23:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.914 X-Spam-Level: X-Spam-Status: No, score=-105.914 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, 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 M+nVJWMjKbf1 for ; Wed, 27 Jun 2012 23:50:28 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B9DCF11E80E9 for ; Wed, 27 Jun 2012 23:50:27 -0700 (PDT) X-AuditID: c1b4fb25-b7fc16d000005db2-9e-4febfeb1bacb Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E6.BF.23986.1BEFBEF4; Thu, 28 Jun 2012 08:50:26 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Thu, 28 Jun 2012 08:50:25 +0200 Message-ID: <4FEBFEAD.2040908@ericsson.com> Date: Thu, 28 Jun 2012 08:50:21 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Brandenburg, R. (Ray) van" References: <4fde00ba.8854b40a.5854.12a4@mx.google.com> <4FE3271F.7020506@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+Jvre6mf6/9DV4fYbN42bOS3eLQjjWM Ft82X2d0YPZYsuQnk8fBdReYPb5c/swWwBzFZZOSmpNZllqkb5fAlTHh+n72giNlFfOn/mBp YPwV28XIySEhYCJxZ99OZghbTOLCvfVsXYxcHEICpxgl/s//yQLhLGeUONbQxtjFyMHBK6At sfufBojJIqAq0TVDGqSXTcBC4uaPRjYQW1QgWGLa9HvsIDavgKDEyZlPWEBsEQFriSuXu8B2 MQuUS2y8twDMFhawlPh29hjUqumMEsu394AlOAV8JC72r2WDOE5S4l77ajaIZj2JKVdbGCFs eYnmrbPB6oWATmto6mCdwCg0C8nuWUhaZiFpWcDIvIpRODcxMye93EgvtSgzubg4P0+vOHUT IzCsD275rbqD8c45kUOM0hwsSuK81lv3+AsJpCeWpGanphakFsUXleakFh9iZOLglGpgVJ66 +Hn7toYfxXIJS2/tUg/YfnXj32suRsXVa3gMfcSjHqysSROPvWN89MMFBvarUYvybATl/e2E 7e9dZu//PnH95mPfPug27XGKVFgXH3vkePqRzQJHOrcW5+o+mX8ydn/YxCqvzKP/H1/ikPM6 E8GdV2DwqrcmIdngwO4Lt9xTIpV/L2RzVmIpzkg01GIuKk4EAB92Z3c5AgAA Cc: "draft-ietf-avtcore-idms@tools.ietf.org" , "avt@ietf.org" Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 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: Thu, 28 Jun 2012 06:50:30 -0000 On 2012-06-25 14:15, Brandenburg, R. (Ray) van wrote: > Hi Magnus, > > Many thanks for the very thorough review. You will find my comments > inline. > > Ray > > -----Original Message----- From: Magnus Westerlund > [mailto:magnus.westerlund@ericsson.com] Sent: donderdag 21 juni 2012 > 15:53 To: avt@ietf.org; draft-ietf-avtcore-idms@tools.ietf.org > Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 > > Hi, > > This is my WG last call review as an individual. I think there is > quite a lot to address before this document is ready for publication > request. > > 1. This document has 6 authors listed. This is one more than the > policy allows: http://www.rfc-editor.org/policy.html#policy.authlist > > RvB: See my other mail. > > 2. Abstract: "This document gives information on an RTCP Packet Type > and RTCP XR Block Type including associated SDP parameters for > Inter-Destination Media Synchronization (IDMS)." > > Doesn't it define these packet/block types? > > RvB: We will change the abstract to reflect the contents more > accurately. The draft defines the RTCP Packet Type and mandates the > use of the ETSI-defined XR Block Type, which is included in the draft > for sake of completeness. > > 3. Section 3: > > The ladder diagrams first line is wrongly indented. > > RvB: OK. > > 3. Section 3. Ladder diagram, maybe this diagram should have some > handle, like figure 1 with a label. > > RvB: OK. > > 4. Section 3. I am missing discussion on the overview level of > clocks. Yes it is present later, but I think the topic should be > introduced already here is section 3. > > RvB: Good idea. We will include a short section to discuss this. > > 5. Section 6. I think this section should make it clear how an SC can > include multiple report blocks for different received sources. In > general I think this may be a topic that needs to be lifted into the > overview. The issue I see is the following ones. > > a) Within a multi-party communication session different media senders > include different reference clocks. Thus creating multiple > synchronization groups within the context of one multi-media > communication session. > > b) even if they can agree on using the same clock reference they > still need to enable the fact that an end-point is acting as MSAS for > some media sources and SC for others. This should be made more > clear. > > RvB: I agree that these are both valid scenarios. However, I'm not > sure whether they pose a problem. In the case where an SC has to > report on multiple groups, it will just send multiple report blocks > (possibly concatenated using RTCP rules). Do I miss something here? No, I don't think they represent any significant issues. It just that I think it is worth pointing out that this is expected and that implementations needs to handle such situations. Many implementors reads the spec and looks at the examples and if it is not spelled out that these are valid cases they might not implement to support them. > > 6. Section 6 appears to be a normative definition of RTCP XR block > type 12. That block type is registered by IANA as belonging to ETSI > 183 063 specification. Unless we have a formal liasion assigning the > change right to IETF I don't see how we can make an updated normative > specification of this XR block type. I see two options. > > a) IETF are given the change right over the block type > > b) IETF makes a normative reference to the ETSI specification of the > block type and then simply makes it clear that they only uses > SPST=1. > > RvB: I fully agree with the problems of trying to change the > specification. When starting this work, we have therefore decided to > go for your route B). Ok, I have no issues with that, however it must be much more clear and explicit that the ETSI spec is the normative one. > > 7. Section 6. Assuming that the normative definition will remain and > possibly also as a clarification to the ETSI specification: This > section is not making it sufficient clear that what an SC is supposed > to do is to pick one RTP packet it recevied, then report the values > for this particular packet. I think one should clarify this and also > making it clearer what the selection criteria for such a packet is. > Should one focus on using maximum delayed packets, media delayed > packets or simply random selection? In addition we have the rules > about picking packets when multiple RTP sequence numbers have the > same TS value. I would recommned that one add some paragraphs before > the actual figure definition to discuss this. > > RvB: Good point. In theory it shouldn't really matter. Up to now, we > have been assuming random selection, just picking a packet when the > RTCP rules allow you to send a report. I will check with my > co-authors to see whether they still think this is good enough. I > will come back to you on this one. Good > > 8. Section 6, PT field definition. This is not making clear that one > shall report the PT of the packet one is reporting on. > > RvB: Ok. > > 9. Section 6. Media Stream Correlation Identifier: 32 bits. This > identifier is used to correlate synchronized media streams. The > value 0 (all bits are set "0") indicates that this field is empty. > The value 2^32-1 (all bits are set "1") is reserved for future use. > If the RTCP Packet Sender is an SC (SPST=1) or an MSAS (SPST=2), then > the Media Stream Correlation Identifier maps on the Synchronization > Group Identifier (SyncGroupId) to which the report applies. > > It is not clear what "maps" means here. Considering that the field > appears to carry the full syncgroupID I think another formulation > shall be used. > > RvB: We will rephrase this paragraph to make it more clear. > > 10. Section 6. "To solve this, an SC SHOULD report on RTP packets in > which a certain RTP timestamp shows up for the first time." > > Does this means with the lowest sequence number or the packet first > to arrive with that TS? > > RvB: The lowest sequence. We will clarify this sentence. > > 11. Section 7 Title "RTCP Packet Type for IDMS (IDMS report)" > > Why is the packet used to distribute the intended playout timing > called a "report". This is very confusing considering that the XR is > a report also. > > RvB: Sorry, you're right. We'll come up with a better name. > > 12. Section 7. > > SSRC: 32 bits. The SSRC of the media source SHALL be set to the > value of the SSRC identifier carried in the RTP header [RFC3550] of > the RTP packet to which the RTCP IDMS packet relates. > > First of all I assume this field definition is for "SSRC of media > source" field. > > RvB: Correct > > a. What isn't clear is if it is at all valid that another SSRC "SSRC > of packet sender" than the "SSRC of media source" is allowed and > shall be considered valid. > > RvB: We have always assumed the SSRC of Media Source scenario. Do you > think there is a good reason to support 'SSRC of packet sender' as > well? No, I don't have a use case in mind. This could be useful if one has a separate node taking care of determining a number of source should be played out. At the same time I think it creates thorny security question etc. Today, you can build the authorization to set the playout time on the media source. With this you get in addition to authenticating source you also need to know that the third party setting the playout is authorized to do it on behalf of the media source. I would suggest to skip third party functionality at this point. > > b. Secondly, when an end-point has multiple sources in the same RTP > session to send it appears they need to send multiple RTCP packets. > > RvB: Do you mean a scenario where one source sends multiple RTP > streams (e.g. audio and video). In that case, it is only necessary to > do IDMS for one stream. The rest is lip-sync. The Media-level SDP > part describes which stream to perform IDMS for. I will check with my > co-authors whether they think it is useful to recommend either audio > or video streams here for this purpose. Lets assume audio only RTP session. I can have two audio source. This means that the end-point needs to set playout for both its sources or rely on lip sync assuming they are using the same CNAME. I think this opens up to several aspects: a) The need to describe that you only need to actually provide playout time for one SSRC within a synchronization context, i.e. the SSRC having the same CNAME. I think this needs to be explicit that this can be done in this way. I think you also needs to say what to do if I get playout times for two SSRCs with the same CNAME and they don't match. This spans over both multiple RTP session and multiple SSRCs within a session. b) The next is that you will receive playout reports from all SSRCs an end-point have in the session. Also here consistency is an important aspect, but I would expect that especially the receive time report will jitter at the same order of the transport jitter. > > 13. Section 7. > > It is not clear if there are any restrictions on the values to be > included in the RTCP packet. Must the sender of it include > information for a already sent packet, a future packet or can it even > be a virtual packet that is never sent? > > I understand that one can scale the figures in this packet to > determine what the correct value should be given a received RTP > packet and its timestamp. But, are I allowed to calculate a correct > time value a year into the future that is then expected to be scaled > back. Or is the RTP timestamp value included in the packet in itself > an indication for when this information was current? > > RvB: Good point. Because RTP timestamps wrap around, choosing a time > far into future may cause problems. So indeed, the timestamp chosen > needs to be a (relatively) current one. We will change the section to > reflect this. > > 14. Section 8. [I-D.draft-williams-avtcore-clksrc] defines a set of > SDP parameters for signaling the clock synchronization source or > sources available to and used by the individual receivers. Using > these paramenters, an SC can indicate which synchronization source is > being used at the moment, the last time the SC synchronized with this > source and the synchronization frequency. An SC can also indicate > any other synchronization sources available to it. This allows > multiple SCs in an IDMS session to use the same or a similar clock > source for their session. > > So the clksrc draft appear to indended to define the usage of a=ssrc > to make it clear which clock source a particular SSRC uses. What > isn't clear from this text is that when providing reporting that all > nodes sending a report or a configuration must use their view of that > particular clock source. I think the implications of having multiple > clock sources in an RTP session must be made clearer. As the used > clock comes into play both when configuring, reporting and adjusting > time scales for playout. > > RvB: I'm not completely following you here. The synchronization > source mentioned here is a wall clock source (e.g. NTP), and not a > media clock source. The reference to the clcksrc document is just to > provide the reader with the means to perform clock synchronization > (and thus improve the accuracy of IDMS). Does this help? Correct, I hadn't thought through this sufficiently. All SSRCs in one or more RTP session using the same CNAME MUST use the same wall clock, i.e. same clksrc. If you have different ones you need to use different CNAMES. So it is actually CNAMES and clock sources that should be bound in the signalling. >From that perspective an end-point could use multiple CNAMES and thus have different clock sources present in the same session. A prime example would be a central node that forwards streams, but do not resynchronize them into a single CNAME. Such an end-point would in an O/A SDP signalling have need to express the different clock source for the other participants in the session. > > 15. Section 9: > > SyncGroupId = 1*DIGIT ; Numerical value from 0 through 4294967294 > > As the syncgroupID is limited to 10 digits, why not make that clear > in the ABNF also using 1*10DIGIT as the definition. > > Applies also to Section 10. > > RvB: Ok. > > 16. Section 11. > > As someone else noted. This section really needs to be split into > Offer/Answer rules and one on TISPAN interop. > > RvB: Agree. We will change this in the next iteration. > > 16. Section 11. Offer/Answer rules It is not clear how one deals with > the potential existence of multiple sync groups or how the ID is > negotiated. Especially when you in a multi-party negotiate with an > application server. > > I also think it should make clear how it works in declarative cases, > like RTSP SDPs. > > RvB: We will take up this point in the new version (see previous > comment). > > 17. Section 14. > > This IANA registration is insufficient. It needs to be more precise > in which regestries that are to be used. > > RvB: Ok. Thanks for you examples. > > To my understand the following actions are required: > > register a media level SDP attribute: This is okay considering the > template but one could clarify that the registry intended is the one > titled "att-field (media level only)" > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml#sdp-parameters-9 > > > > One RTCP Control Packet types (PT): > http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml#rtp-parameters-3 > > And if the XR block type is to be normatively defined by this > document then two registrations are needed: > > - New or update of RTCP XR Block Type > http://www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr-block-types.xml > > - Add the XR SDP parameter: > http://www.iana.org/assignments/rtcp-xr-sdp-parameters/rtcp-xr-sdp-parameters.xml > > 18. References. Should [I-D.draft-gross-leap-second] be normative? > It is not written in a RFC 2119 style an requirement to take this > document into account, so maybe informative is correct. > > RvB: I propose going for informative. The leap-second draft is just a > way of increasing the accuracy of IDMS. And since it is meant as an > update to RFC3550, can be considered part of RTCP and not > specifically targeted at IDMS. I think that is fine. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From keith.drage@alcatel-lucent.com Thu Jun 28 02:10:55 2012 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 B353521F8997 for ; Thu, 28 Jun 2012 02:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.594 X-Spam-Level: X-Spam-Status: No, score=-109.594 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, 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 xIVFtt3vqjcm for ; Thu, 28 Jun 2012 02:10:54 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id C53C521F8992 for ; Thu, 28 Jun 2012 02:10:52 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q5S999mj006160 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Jun 2012 11:10:43 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 28 Jun 2012 11:10:20 +0200 From: "DRAGE, Keith (Keith)" To: Qin Wu , Magnus Westerlund , "avt@ietf.org" , "draft-ietf-avtcore-idms@tools.ietf.org" Date: Thu, 28 Jun 2012 11:10:18 +0200 Thread-Topic: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 Thread-Index: Ac1U218N063ktbLRQvGDM/t3PqgyzgALx/LA Message-ID: References: <4fde00ba.8854b40a.5854.12a4@mx.google.com> <4FE3271F.7020506@ericsson.com> <111C724E6D4143EA8F5D87DAD4BD6918@china.huawei.com> In-Reply-To: <111C724E6D4143EA8F5D87DAD4BD6918@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 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: Thu, 28 Jun 2012 09:10:55 -0000 Regarding IANA registration. The requirement is specification required, which can obviously be a specifi= cation from some other body than IETF. If you go to the IANA page you will find a set of pages relating to request= ing an assignment. Generally I would expect the secretariat of a standards = body to complete the request, although again I don't think that is mandator= y. You will see the registration in this case came from a member of the ETS= I secretariat and the referenced specification is an ETSI specification. This is all entirely in accordance with the registry requirements. I do notice that the IETF document and the ETSI document define one and the= same XR block. Is there an intention that the ETSI document gets modified = to reference the IETF document when finally approved and published (i.e. th= at the IETF document takes ownership and updates the existing registration?= Or is there some other strategy for this block type? Whatever occurs, this strategy will probably need some explanation in the I= ANA considerations. Keith -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin W= u Sent: 28 June 2012 04:04 To: Magnus Westerlund; avt@ietf.org; draft-ietf-avtcore-idms@tools.ietf.org Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 Hi, I have reviewed XR Block aspect and it seems IANA has already allocated Blo= ck Type 12 to this IDMS XR Block.=20 http://www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr-block-types.xml I have not been aware of this before. I am wondering what's the procedure f= or other SDOs to ask IETF for IANA registry? Send Liaison statement or something else? Besides this, below are a few comments related to XR Block: 1. Section 6,=20 It is better to number the figure in the section 6 with a title. 2. Section 6, figure It is unusual to reseve some bits in the middle of "type specific field" af= ter Block Type (BT) field. Why not move P bit before reseved bits in this field. 3. Section 6, SPST field For SPST =3D2, it is better to point out the packet sender is Media Synchro= nization Application Server (MSAS) to get in line with SPST =3D1; 4. Section 6, Payload Type (PT) Payload Type (PT) and Packet Type (PT) are defined in the same XR Block and= has the same short name, it is quite confusing. Suggest to distinct them in the XR BLock format. 5. Section 6, Payload Type (PT) Why Synchronization Client (SC) should send Payload Type in the XR Block me= ssage to Media Synchronization Application Server (MSAS) while MSAS does not need to send Payload Type in the IDMS RTCP message to = SC? It seems you indicate MSAS should handle various payload Type sent from dif= ferent SCs? How MSAS procss Payload Type? The Payload Type difference=20 each SC is using affect the timestamps carried in the IDMS RTCP packet? I am wondering if it is really necessary to allow XR Block carry Payload Ty= pe? 6. Section 6, SSRC of media source field To get in line with the existing RTCP XR Block, it is better put SSRC of me= dia source field right after report Block header before Payload Type filed.= =20 7. Section 6, Packet Presented NTP timestamp field: Why the size of Packet Presented NTP timestamp field in the IDMS XR block i= s 32 bit while the size of Packet Presented NTP timestamp field in the IDMS= RTCP packet is 64 bit? It is better to clarify this in the document? 8 Section 6, Media Stream Correlation Identifier field: It looks the value of Media Stream Correlation Identifier is same as SyncG= roupId, SynGroupID is signaled using SDP and SC or MSAS just use put SyncGroupID=20 into Media Stream Correlation Identifier field I am wondering why not use the same name for them? That is to say, change M= edia Stream Correlation field to SyncGroupId. Regards! -Qin ----- Original Message -----=20 From: "Magnus Westerlund" To: ; Sent: Thursday, June 21, 2012 9:52 PM Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 Hi, This is my WG last call review as an individual. I think there is quite a lot to address before this document is ready for publication request. 1. This document has 6 authors listed. This is one more than the policy allows: http://www.rfc-editor.org/policy.html#policy.authlist 2. Abstract: "This document gives information on an RTCP Packet Type and RTCP XR Block Type including associated SDP parameters for Inter-Destination Media Synchronization (IDMS)." Doesn't it define these packet/block types? 3. Section 3: The ladder diagrams first line is wrongly indented. 3. Section 3. Ladder diagram, maybe this diagram should have some handle, like figure 1 with a label. 4. Section 3. I am missing discussion on the overview level of clocks. Yes it is present later, but I think the topic should be introduced already here is section 3. 5. Section 6. I think this section should make it clear how an SC can include multiple report blocks for different received sources. In general I think this may be a topic that needs to be lifted into the overview. The issue I see is the following ones. a) Within a multi-party communication session different media senders include different reference clocks. Thus creating multiple synchronization groups within the context of one multi-media communication session. b) even if they can agree on using the same clock reference they still need to enable the fact that an end-point is acting as MSAS for some media sources and SC for others. This should be made more clear. 6. Section 6 appears to be a normative definition of RTCP XR block type 12. That block type is registered by IANA as belonging to ETSI 183 063 specification. Unless we have a formal liasion assigning the change right to IETF I don't see how we can make an updated normative specification of this XR block type. I see two options. a) IETF are given the change right over the block type b) IETF makes a normative reference to the ETSI specification of the block type and then simply makes it clear that they only uses SPST=3D1. 7. Section 6. Assuming that the normative definition will remain and possibly also as a clarification to the ETSI specification: This section is not making it sufficient clear that what an SC is supposed to do is to pick one RTP packet it recevied, then report the values for this particular packet. I think one should clarify this and also making it clearer what the selection criteria for such a packet is. Should one focus on using maximum delayed packets, media delayed packets or simply random selection? In addition we have the rules about picking packets when multiple RTP sequence numbers have the same TS value. I would recommned that one add some paragraphs before the actual figure definition to discuss this. 8. Section 6, PT field definition. This is not making clear that one shall report the PT of the packet one is reporting on. 9. Section 6. Media Stream Correlation Identifier: 32 bits. This identifier is used to correlate synchronized media streams. The value 0 (all bits are set "0") indicates that this field is empty. The value 2^32-1 (all bits are set "1") is reserved for future use. If the RTCP Packet Sender is an SC (SPST=3D1) or an MSAS (SPST=3D2), then the Media Stream Correlation Identifier maps on the Synchronization Group Identifier (SyncGroupId) to which the report applies. It is not clear what "maps" means here. Considering that the field appears to carry the full syncgroupID I think another formulation shall be used. 10. Section 6. "To solve this, an SC SHOULD report on RTP packets in which a certain RTP timestamp shows up for the first time." Does this means with the lowest sequence number or the packet first to arrive with that TS? 11. Section 7 Title "RTCP Packet Type for IDMS (IDMS report)" Why is the packet used to distribute the intended playout timing called a "report". This is very confusing considering that the XR is a report also= . 12. Section 7. SSRC: 32 bits. The SSRC of the media source SHALL be set to the value of the SSRC identifier carried in the RTP header [RFC3550] of the RTP packet to which the RTCP IDMS packet relates. First of all I assume this field definition is for "SSRC of media source" field. a. What isn't clear is if it is at all valid that another SSRC "SSRC of packet sender" than the "SSRC of media source" is allowed and shall be considered valid. b. Secondly, when an end-point has multiple sources in the same RTP session to send it appears they need to send multiple RTCP packets. 13. Section 7. It is not clear if there are any restrictions on the values to be included in the RTCP packet. Must the sender of it include information for a already sent packet, a future packet or can it even be a virtual packet that is never sent? I understand that one can scale the figures in this packet to determine what the correct value should be given a received RTP packet and its timestamp. But, are I allowed to calculate a correct time value a year into the future that is then expected to be scaled back. Or is the RTP timestamp value included in the packet in itself an indication for when this information was current? 14. Section 8. [I-D.draft-williams-avtcore-clksrc] defines a set of SDP parameters for signaling the clock synchronization source or sources available to and used by the individual receivers. Using these paramenters, an SC can indicate which synchronization source is being used at the moment, the last time the SC synchronized with this source and the synchronization frequency. An SC can also indicate any other synchronization sources available to it. This allows multiple SCs in an IDMS session to use the same or a similar clock source for their session. So the clksrc draft appear to indended to define the usage of a=3Dssrc to make it clear which clock source a particular SSRC uses. What isn't clear from this text is that when providing reporting that all nodes sending a report or a configuration must use their view of that particular clock source. I think the implications of having multiple clock sources in an RTP session must be made clearer. As the used clock comes into play both when configuring, reporting and adjusting time scales for playout. 15. Section 9: SyncGroupId =3D 1*DIGIT ; Numerical value from 0 through 4294967294 As the syncgroupID is limited to 10 digits, why not make that clear in the ABNF also using 1*10DIGIT as the definition. Applies also to Section 10. 16. Section 11. As someone else noted. This section really needs to be split into Offer/Answer rules and one on TISPAN interop. 16. Section 11. Offer/Answer rules It is not clear how one deals with the potential existence of multiple sync groups or how the ID is negotiated. Especially when you in a multi-party negotiate with an application server. I also think it should make clear how it works in declarative cases, like RTSP SDPs. 17. Section 14. This IANA registration is insufficient. It needs to be more precise in which regestries that are to be used. To my understand the following actions are required: register a media level SDP attribute: This is okay considering the template but one could clarify that the registry intended is the one titled "att-field (media level only)" http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml#sdp-param= eters-9 One RTCP Control Packet types (PT): http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml#rtp-param= eters-3 And if the XR block type is to be normatively defined by this document then two registrations are needed: - New or update of RTCP XR Block Type http://www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr-block-types.xml - Add the XR SDP parameter: http://www.iana.org/assignments/rtcp-xr-sdp-parameters/rtcp-xr-sdp-paramete= rs.xml 18. References. Should [I-D.draft-gross-leap-second] be normative? It is not written in a RFC 2119 style an requirement to take this document into account, so maybe informative is correct. Cheers Magnus On 2012-06-17 18:04, Roni Even wrote: > Hi, >=20 > I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avt= core-idms-05 , RTCP for inter-destination media synchronization. >=20 > =20 >=20 > The WGLC will end on July 10th, 2012 >=20 > =20 >=20 > Please review the draft and send comments to the list. >=20 > =20 >=20 > For the draft authors; Are you aware of any IPR that applies to draft-ie= tf-avtcore-idms-05? If so, >=20 > has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3= 979, 4879, 3669 and 5378 for more details)? >=20 > The above question is needed for the document write-up when sent to publi= cation. >=20 > =20 >=20 > Thanks >=20 > =20 >=20 > Roni Even >=20 > AVTcore co-chair >=20 > =20 >=20 --=20 Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From hans.stokking@tno.nl Thu Jun 28 02:34:14 2012 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 3EB3A21F84DF for ; Thu, 28 Jun 2012 02:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.104 X-Spam-Level: X-Spam-Status: No, score=-0.104 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] 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 s6RtG1DMMHgN for ; Thu, 28 Jun 2012 02:34:13 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id E190811E8097 for ; Wed, 27 Jun 2012 23:29:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,489,1336341600"; d="scan'208,217";a="15615067" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1b.tno.nl with ESMTP; 28 Jun 2012 08:29:26 +0200 Received: from EXC-MBX01.tsn.tno.nl ([169.254.1.128]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0298.004; Thu, 28 Jun 2012 08:29:25 +0200 From: "Stokking, H.M. (Hans)" To: "avt@ietf.org" Thread-Topic: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 Thread-Index: AQHNVNvHdp+K0jkOQUKLCbWCw+ddRJcPQ9mg Date: Thu, 28 Jun 2012 06:29:25 +0000 Message-ID: <7F110B3ECC623C4EADDEB82154F2693D07685B14@EXC-MBX01.tsn.tno.nl> References: <4fde00ba.8854b40a.5854.12a4@mx.google.com> <4FE3271F.7020506@ericsson.com> <111C724E6D4143EA8F5D87DAD4BD6918@china.huawei.com> <1340853119.5506.53.camel@gwz-laptop> In-Reply-To: <1340853119.5506.53.camel@gwz-laptop> 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: multipart/alternative; boundary="_000_7F110B3ECC623C4EADDEB82154F2693D07685B14EXCMBX01tsntnon_" MIME-Version: 1.0 Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 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: Thu, 28 Jun 2012 09:34:14 -0000 --_000_7F110B3ECC623C4EADDEB82154F2693D07685B14EXCMBX01tsntnon_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpUaGUgcmVnaXN0cmF0aW9uIGRlcGVuZHMgb24gdGhlIHJlcXVpcmVtZW50cyBw b3NlZCBieSB0aGUgcmVnaXN0cnkuIEZvciBSVENQIFhSIGJsb2NrcywgdGhpcyBzYXlzIHNvbWV0 aGluZyBsaWtlIOKAmHNwZWNpZmljYXRpb24gcmVxdWlyZWTigJkuIFRoaXMgbWVhbnMgdGhhdCBh bnkgYm9keSBjYW4gc3BlY2lmeSBzb21ldGhpbmcsIG5vcm1hbGx5IHN0YW5kYXJkaXNhdGlvbiBi b2RpZXMgKGxpa2UgRVRTSSwgSVRVLCBldGMpIGJ1dCB0aGlzIGNvdWxkIGV2ZW4gYmUgYW4gb3Bl biBzdGFuZGFyZCBieSBhIGNvbXBhbnkgSSBzdXBwb3NlLiBGdXJ0aGVybW9yZSwgSUFOQSB3b3Vs ZCBhc2sgc29tZW9uZSBmb3IgYSByZXZpZXcgb2YgdGhlIGRvY3VtZW50LiBJbiB0aGlzIGNhc2Ug dGhlIG1lbnRpb25lZCBleHBlcnQgb24gdGhlIElBTkEgc2l0ZSBpcyBKb2VyZyBPdHQsIHNlZSBo dHRwOi8vd3d3LmlhbmEub3JnL3Byb3RvY29scyAuDQoNClRoaXMgd2hvbGUgdGhpbmcgc3RhcnRl ZCB3aXRoIEVUU0ksIGFsdGhvdWdoIGl0IGlzIGNsZWFybHkgc29tZXRoaW5nIGZvciB0aGUgQVZU L0FWVENPUkUgZ3JvdXAuIFRoYXTigJlzIHRoZSB3aG9sZSByZWFzb24gd2Ugc3RhcnRlZCB0aGUg d29yayBoZXJlLg0KDQpCZXN0LCBIYW5zDQoNCkZyb206IGF2dC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86YXZ0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHbGVuIFpvcm4NClNlbnQ6 IGRvbmRlcmRhZyAyOCBqdW5pIDIwMTIgNToxMg0KVG86IGF2dEBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtBVlRDT1JFXSBXR0xDIG9uIGRyYWZ0LWlldGYtYXZ0Y29yZS1pZG1zLTA1DQoNCk9uIFRo dSwgMjAxMi0wNi0yOCBhdCAxMTowMyArMDgwMCwgUWluIFd1IHdyb3RlOg0KDQoNCg0KSGksDQoN CkkgaGF2ZSByZXZpZXdlZCBYUiBCbG9jayBhc3BlY3QgYW5kIGl0IHNlZW1zIElBTkEgaGFzIGFs cmVhZHkgYWxsb2NhdGVkIEJsb2NrIFR5cGUgMTIgdG8gdGhpcyBJRE1TIFhSIEJsb2NrLg0KDQpo dHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3J0Y3AteHItYmxvY2stdHlwZXMvcnRjcC14 ci1ibG9jay10eXBlcy54bWwNCg0KSSBoYXZlIG5vdCBiZWVuIGF3YXJlIG9mIHRoaXMgYmVmb3Jl LiBJIGFtIHdvbmRlcmluZyB3aGF0J3MgdGhlIHByb2NlZHVyZSBmb3Igb3RoZXIgU0RPcyB0byBh c2sgSUVURiBmb3IgSUFOQSByZWdpc3RyeT8NCg0KU2VuZCBMaWFpc29uIHN0YXRlbWVudCBvciBz b21ldGhpbmcgZWxzZT8NCg0KQUZBSUssIHRoZXJlIGlzIG5vIHNwZWNpYWwgcHJvY2VkdXJlOyBq dXN0IGZvbGxvdyB0aGUgYWxsb2NhdGlvbiBwb2xpY3kuDQoNCi4uLg0KVGhpcyBlLW1haWwgYW5k IGl0cyBjb250ZW50cyBhcmUgc3ViamVjdCB0byB0aGUgRElTQ0xBSU1FUiBhdCBodHRwOi8vd3d3 LnRuby5ubC9lbWFpbGRpc2NsYWltZXIK --_000_7F110B3ECC623C4EADDEB82154F2693D07685B14EXCMBX01tsntnon_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE0Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE0Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxQ0Q1NTA4LjFGRkM3MzMwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8bzpEb05vdFJlbHlPbkNTUy8+ DQo8L286T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPHc6V29yZERvY3VtZW50Pg0KPHc6VHJhY2tNb3Zlcy8+DQo8dzpU cmFja0Zvcm1hdHRpbmcvPg0KPHc6SHlwaGVuYXRpb25ab25lPjIxPC93Okh5cGhlbmF0aW9uWm9u ZT4NCjx3OkVudmVsb3BlVmlzLz4NCjx3OlZhbGlkYXRlQWdhaW5zdFNjaGVtYXMvPg0KPHc6U2F2 ZUlmWE1MSW52YWxpZD5mYWxzZTwvdzpTYXZlSWZYTUxJbnZhbGlkPg0KPHc6SWdub3JlTWl4ZWRD b250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCjx3OkFsd2F5c1Nob3dQbGFjZWhv bGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD4NCjx3OkRvTm90UHJv bW90ZVFGLz4NCjx3OkxpZFRoZW1lT3RoZXI+Tkw8L3c6TGlkVGhlbWVPdGhlcj4NCjx3OkxpZFRo ZW1lQXNpYW4+WC1OT05FPC93OkxpZFRoZW1lQXNpYW4+DQo8dzpMaWRUaGVtZUNvbXBsZXhTY3Jp cHQ+WC1OT05FPC93OkxpZFRoZW1lQ29tcGxleFNjcmlwdD4NCjx3OkNvbXBhdGliaWxpdHk+DQo8 dzpEb05vdEV4cGFuZFNoaWZ0UmV0dXJuLz4NCjx3OkJyZWFrV3JhcHBlZFRhYmxlcy8+DQo8dzpT cGxpdFBnQnJlYWtBbmRQYXJhTWFyay8+DQo8dzpFbmFibGVPcGVuVHlwZUtlcm5pbmcvPg0KPC93 OkNvbXBhdGliaWxpdHk+DQo8bTptYXRoUHI+DQo8bTptYXRoRm9udCBtOnZhbD0iQ2FtYnJpYSBN YXRoIi8+DQo8bTpicmtCaW4gbTp2YWw9ImJlZm9yZSIvPg0KPG06YnJrQmluU3ViIG06dmFsPSIm IzQ1Oy0iLz4NCjxtOnNtYWxsRnJhYyBtOnZhbD0ib2ZmIi8+DQo8bTpkaXNwRGVmLz4NCjxtOmxN YXJnaW4gbTp2YWw9IjAiLz4NCjxtOnJNYXJnaW4gbTp2YWw9IjAiLz4NCjxtOmRlZkpjIG06dmFs PSJjZW50ZXJHcm91cCIvPg0KPG06d3JhcEluZGVudCBtOnZhbD0iMTQ0MCIvPg0KPG06aW50TGlt IG06dmFsPSJzdWJTdXAiLz4NCjxtOm5hcnlMaW0gbTp2YWw9InVuZE92ciIvPg0KPC9tOm1hdGhQ cj48L3c6V29yZERvY3VtZW50Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8dzpMYXRlbnRTdHlsZXMgRGVmTG9ja2VkU3RhdGU9ImZhbHNlIiBEZWZVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgRGVmU2VtaUhpZGRlbj0idHJ1ZSIgRGVmUUZvcm1hdD0iZmFsc2UiIERl ZlByaW9yaXR5PSI5OSIgTGF0ZW50U3R5bGVDb3VudD0iMjY3Ij4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm9ybWFsIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1l PSJoZWFkaW5nIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i OSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0 cnVlIiBOYW1lPSJoZWFkaW5nIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA2Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9Imhl YWRpbmcgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA5Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9j IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9 InRvYyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBO YW1lPSJ0b2MgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIz OSIgTmFtZT0idG9jIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iMzkiIE5hbWU9InRvYyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjM5IiBOYW1lPSJ0b2MgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjM1IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJjYXB0aW9uIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEwIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUaXRsZSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBOYW1lPSJEZWZh dWx0IFBhcmFncmFwaCBGb250Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjExIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJTdWJ0aXRsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIyMiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3Ryb25nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjIwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iVGFibGUgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iUGxhY2Vob2xkZXIgVGV4dCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJObyBT cGFjaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFk aW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkNvbG9yZnVsIExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkNvbG9yZnVsIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDEi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IlJldmlzaW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJMaXN0IFBhcmFncmFwaCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSIyOSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iUXVvdGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUXVvdGUiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDEi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNj ZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlk IDMgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsg TGlzdCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29s b3JmdWwgU2hhZGluZyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBB Y2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExp c3QgMSBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIExpc3QgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2Vu dCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5n IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYx IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBM aXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdo dCBHcmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gU2hhZGluZyAxIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFj Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3Qg QWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVs IFNoYWRpbmcgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkNvbG9yZnVsIExpc3QgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50 IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEg QWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBM aXN0IDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBHcmlkIDEgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2Nl bnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBB Y2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3Jp ZCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IFNoYWRpbmcgMSBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2Vu dCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFk aW5nIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xv cmZ1bCBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA2Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2Vu dCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAy IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3 IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g R3JpZCAxIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gR3JpZCAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDYiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDYiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTkiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBF bXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMSIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIg TmFtZT0iSW50ZW5zZSBFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSIzMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg UUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIFJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBSZWZlcmVuY2UiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzMiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkJvb2sg VGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzciIE5h bWU9IkJpYmxpb2dyYXBoeSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIzOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVE9DIEhlYWRpbmciLz4NCjwvdzpMYXRlbnRT dHlsZXM+DQo8L3htbD48IVtlbmRpZl0tLT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9u cyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0Ow0KCW1zby1mb250LWFsdDpDYWxpYnJpOw0KCW1zby1mb250LWNoYXJz ZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpzd2lzczsNCgltc28tZm9udC1waXRjaDp2 YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUyMDA5MjkyOSAxMDczNzg2MTExIDkgMCA0 MTUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDsNCgltc28tZm9udC1hbHQ6Ij9sP3IgPz8/Pz8/Pz8/Pz8/Pz8/Pz8/ Pz8/Pz8/Pz8iOw0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWls eTpzd2lzczsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6 LTUyMDA4MTY2NSAtMTA3MzcxNzE1NyA0MSAwIDY2MDQ3IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDsNCgltc28t Zm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6bW9kZXJuOw0KCW1zby1m b250LXBpdGNoOmZpeGVkOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTIwMDkyOTI5IDEwNzM4MDY1 OTEgOSAwIDQxNSAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLXN0 eWxlLXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsN Cgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KcHJlDQoJe21zby1zdHlsZS1ub3Nob3c6 eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ bXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1sb2NrZWQ6eWVzOw0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OkNhbGlicmk7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS11 bmhpZGU6bm87DQoJbXNvLWFuc2ktZm9udC1zaXplOjExLjBwdDsNCgltc28tYmlkaS1mb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWFz Y2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJy aTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1kZWZhdWx0LXByb3BzOnllczsNCglm b250LXNpemU6MTAuMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJbXNvLWJpZGkt Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDsNCgltc28taGVhZGVy LW1hcmdpbjozNS40cHQ7DQoJbXNvLWZvb3Rlci1tYXJnaW46MzUuNHB0Ow0KCW1zby1wYXBlci1z b3VyY2U6MDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDEwXT48c3R5bGU+LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnRhYmxlLk1zb05vcm1hbFRhYmxlDQoJe21zby1zdHlsZS1uYW1lOiJUYWJsZSBOb3JtYWwiOw0K CW1zby10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsN Cgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLXBhcmVudDoiIjsNCgltc28tcGFkZGluZy1hbHQ6MGNtIDUuNHB0IDBjbSA1LjRwdDsNCglt c28tcGFyYS1tYXJnaW46MGNtOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglt c28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9Ik5MIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0idGFiLWludGVy dmFsOjM1LjRwdCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgQWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1iaWRp LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4t VVMiPlRoZSByZWdpc3RyYXRpb24gZGVwZW5kcyBvbiB0aGUgcmVxdWlyZW1lbnRzDQogcG9zZWQg YnkgdGhlIHJlZ2lzdHJ5LiBGb3IgUlRDUCBYUiBibG9ja3MsIHRoaXMgc2F5cyBzb21ldGhpbmcg bGlrZSDigJhzcGVjaWZpY2F0aW9uIHJlcXVpcmVk4oCZLiBUaGlzIG1lYW5zIHRoYXQgYW55IGJv ZHkgY2FuIHNwZWNpZnkgc29tZXRoaW5nLCBub3JtYWxseSBzdGFuZGFyZGlzYXRpb24gYm9kaWVz IChsaWtlIEVUU0ksIElUVSwgZXRjKSBidXQgdGhpcyBjb3VsZCBldmVuIGJlIGFuIG9wZW4gc3Rh bmRhcmQgYnkgYSBjb21wYW55IEkgc3VwcG9zZS4NCiBGdXJ0aGVybW9yZSwgSUFOQSB3b3VsZCBh c2sgc29tZW9uZSBmb3IgYSByZXZpZXcgb2YgdGhlIGRvY3VtZW50LiBJbiB0aGlzIGNhc2UgdGhl IG1lbnRpb25lZCBleHBlcnQgb24gdGhlIElBTkEgc2l0ZSBpcyBKb2VyZyBPdHQsIHNlZQ0KPGEg aHJlZj0iaHR0cDovL3d3dy5pYW5hLm9yZy9wcm90b2NvbHMiPmh0dHA6Ly93d3cuaWFuYS5vcmcv cHJvdG9jb2xzPC9hPiAuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1iaWRpLWZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1hbnNpLWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGli cmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGktZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWFu c2ktbGFuZ3VhZ2U6RU4tVVMiPlRoaXMgd2hvbGUgdGhpbmcgc3RhcnRlZCB3aXRoIEVUU0ksDQog YWx0aG91Z2ggaXQgaXMgY2xlYXJseSBzb21ldGhpbmcgZm9yIHRoZSBBVlQvQVZUQ09SRSBncm91 cC4gVGhhdOKAmXMgdGhlIHdob2xlIHJlYXNvbiB3ZSBzdGFydGVkIHRoZSB3b3JrIGhlcmUuPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1hbnNpLWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMi PkJlc3QsIEhhbnM8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWFuc2ktbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGZvbnQgc2l6 ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O21z by1hbnNpLWxhbmd1YWdlOkVOLVVTO2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwvZm9u dD48L2I+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTIj4NCiBhdnQtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmF2dC1ib3VuY2VzQGlldGYub3JnXSA8Yj48c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+T24gQmVoYWxmIE9mDQo8L3NwYW4+PC9iPkdsZW4gWm9ybjxicj4NCjxiPjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TZW50Ojwvc3Bhbj48L2I+IGRvbmRlcmRhZyAy OCBqdW5pIDIwMTIgNToxMjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5U bzo8L3NwYW4+PC9iPiBhdnRAaWV0Zi5vcmc8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogW0FWVENPUkVdIFdHTEMgb24gZHJhZnQt aWV0Zi1hdnRjb3JlLWlkbXMtMDU8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIz IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21z by1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+T24gVGh1 LCAyMDEyLTA2LTI4IGF0IDExOjAzICYjNDM7MDgwMCwgUWluIFd1IHdyb3RlOg0KPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SGksPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkkgaGF2ZSByZXZpZXdlZCBYUiBCbG9jayBhc3BlY3QgYW5k IGl0IHNlZW1zIElBTkEgaGFzIGFscmVhZHkgYWxsb2NhdGVkIEJsb2NrIFR5cGUgMTIgdG8gdGhp cyBJRE1TIFhSIEJsb2NrLiA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxm b250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9ydGNwLXhyLWJs b2NrLXR5cGVzL3J0Y3AteHItYmxvY2stdHlwZXMueG1sIj5odHRwOi8vd3d3LmlhbmEub3JnL2Fz c2lnbm1lbnRzL3J0Y3AteHItYmxvY2stdHlwZXMvcnRjcC14ci1ibG9jay10eXBlcy54bWw8L2E+ PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkkgaGF2ZSBub3Qg YmVlbiBhd2FyZSBvZiB0aGlzIGJlZm9yZS4gSSBhbSB3b25kZXJpbmcgd2hhdCdzIHRoZSBwcm9j ZWR1cmUgZm9yIG90aGVyIFNET3MgdG8gYXNrIElFVEYgZm9yIElBTkEgcmVnaXN0cnk/PG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3Vy aWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlNlbmQgTGlhaXNvbiBzdGF0 ZW1lbnQgb3Igc29tZXRoaW5nIGVsc2U/PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1mb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxicj4NCkFGQUlLLCB0aGVyZSBpcyBubyBzcGVj aWFsIHByb2NlZHVyZTsganVzdCBmb2xsb3cgdGhlIGFsbG9jYXRpb24gcG9saWN5Ljxicj4NCjxi cj4NCi4uLiA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cD5UaGlzIGUt bWFpbCBhbmQgaXRzIGNvbnRlbnRzIGFyZSBzdWJqZWN0IHRvIHRoZSBESVNDTEFJTUVSIGF0IGh0 dHA6Ly93d3cudG5vLm5sL2VtYWlsZGlzY2xhaW1lcjwvcD48L2JvZHk+DQo8L2h0bWw+DQo= --_000_7F110B3ECC623C4EADDEB82154F2693D07685B14EXCMBX01tsntnon_-- From bill.wu@huawei.com Thu Jun 28 03:08:38 2012 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 C727D21F85C3 for ; Thu, 28 Jun 2012 03:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[AWL=1.550, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 vFV7WsBYHSLe for ; Thu, 28 Jun 2012 03:08:38 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9040921F8996 for ; Thu, 28 Jun 2012 02:59:40 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHO10415; Thu, 28 Jun 2012 05:59:40 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 28 Jun 2012 02:58:10 -0700 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 28 Jun 2012 02:58:06 -0700 Received: from w53375 (10.138.41.149) by szxeml405-hub.china.huawei.com (10.82.67.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 28 Jun 2012 17:58:00 +0800 Message-ID: From: Qin Wu To: Glen Zorn , References: <4fde00ba.8854b40a.5854.12a4@mx.google.com><4FE3271F.7020506@ericsson.com><111C724E6D4143EA8F5D87DAD4BD6918@china.huawei.com> <1340853119.5506.53.camel@gwz-laptop> Date: Thu, 28 Jun 2012 17:57:59 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B9_01CD5557.8DD562A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 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: Thu, 28 Jun 2012 10:08:39 -0000 ------=_NextPart_000_02B9_01CD5557.8DD562A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSBzZWUuDQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IEdsZW4gWm9y biANCiAgVG86IGF2dEBpZXRmLm9yZyANCiAgU2VudDogVGh1cnNkYXksIEp1bmUgMjgsIDIwMTIg MTE6MTEgQU0NCiAgU3ViamVjdDogUmU6IFtBVlRDT1JFXSBXR0xDIG9uIGRyYWZ0LWlldGYtYXZ0 Y29yZS1pZG1zLTA1DQoNCg0KICBPbiBUaHUsIDIwMTItMDYtMjggYXQgMTE6MDMgKzA4MDAsIFFp biBXdSB3cm90ZTogDQpIaSwNCkkgaGF2ZSByZXZpZXdlZCBYUiBCbG9jayBhc3BlY3QgYW5kIGl0 IHNlZW1zIElBTkEgaGFzIGFscmVhZHkgYWxsb2NhdGVkIEJsb2NrIFR5cGUgMTIgdG8gdGhpcyBJ RE1TIFhSIEJsb2NrLiANCmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvcnRjcC14ci1i bG9jay10eXBlcy9ydGNwLXhyLWJsb2NrLXR5cGVzLnhtbA0KSSBoYXZlIG5vdCBiZWVuIGF3YXJl IG9mIHRoaXMgYmVmb3JlLiBJIGFtIHdvbmRlcmluZyB3aGF0J3MgdGhlIHByb2NlZHVyZSBmb3Ig b3RoZXIgU0RPcyB0byBhc2sgSUVURiBmb3IgSUFOQSByZWdpc3RyeT8NClNlbmQgTGlhaXNvbiBz dGF0ZW1lbnQgb3Igc29tZXRoaW5nIGVsc2U/DQoNCiAgQUZBSUssIHRoZXJlIGlzIG5vIHNwZWNp YWwgcHJvY2VkdXJlOyBqdXN0IGZvbGxvdyB0aGUgYWxsb2NhdGlvbiBwb2xpY3kuDQoNCiAgLi4u IA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCiAgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUg TWFpbnRlbmFuY2UNCiAgYXZ0QGlldGYub3JnDQogIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYXZ0DQo= ------=_NextPart_000_02B9_01CD5557.8DD562A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNv bnRlbnQ9Ik1TSFRNTCA4LjAwLjYwMDEuMTkyNTgiPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+ DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPkkgc2VlLjwvRElWPg0KPEJMT0NLUVVPVEUg DQpzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVw eDsgUEFERElORy1SSUdIVDogMHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBw eCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPi0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZM7IEJBQ0tHUk9V TkQ6ICNlNGU0ZTQ7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxl PWdsZW56b3JuQGdtYWlsLmNvbSBocmVmPSJtYWlsdG86Z2xlbnpvcm5AZ21haWwuY29tIj5HbGVu IFpvcm48L0E+IA0KICA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0IOWui+S9kyI+PEI+ VG86PC9CPiA8QSB0aXRsZT1hdnRAaWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzphdnRAaWV0Zi5v cmciPmF2dEBpZXRmLm9yZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovk vZMiPjxCPlNlbnQ6PC9CPiBUaHVyc2RheSwgSnVuZSAyOCwgMjAxMiAxMToxMSBBTTwvRElWPg0K ICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5TdWJqZWN0OjwvQj4gUmU6IFtBVlRD T1JFXSBXR0xDIG9uIA0KICBkcmFmdC1pZXRmLWF2dGNvcmUtaWRtcy0wNTwvRElWPg0KICA8RElW PjxCUj48L0RJVj5PbiBUaHUsIDIwMTItMDYtMjggYXQgMTE6MDMgKzA4MDAsIFFpbiBXdSB3cm90 ZTogDQogIDxCTE9DS1FVT1RFIHR5cGU9IkNJVEUiPjxQUkU+SGksDQpJIGhhdmUgcmV2aWV3ZWQg WFIgQmxvY2sgYXNwZWN0IGFuZCBpdCBzZWVtcyBJQU5BIGhhcyBhbHJlYWR5IGFsbG9jYXRlZCBC bG9jayBUeXBlIDEyIHRvIHRoaXMgSURNUyBYUiBCbG9jay4gDQo8QSBocmVmPSJodHRwOi8vd3d3 LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3J0Y3AteHItYmxvY2stdHlwZXMvcnRjcC14ci1ibG9jay10 eXBlcy54bWwiPmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvcnRjcC14ci1ibG9jay10 eXBlcy9ydGNwLXhyLWJsb2NrLXR5cGVzLnhtbDwvQT4NCkkgaGF2ZSBub3QgYmVlbiBhd2FyZSBv ZiB0aGlzIGJlZm9yZS4gSSBhbSB3b25kZXJpbmcgd2hhdCdzIHRoZSBwcm9jZWR1cmUgZm9yIG90 aGVyIFNET3MgdG8gYXNrIElFVEYgZm9yIElBTkEgcmVnaXN0cnk/DQpTZW5kIExpYWlzb24gc3Rh dGVtZW50IG9yIHNvbWV0aGluZyBlbHNlPw0KPC9QUkU+PC9CTE9DS1FVT1RFPjxCUj5BRkFJSywg dGhlcmUgaXMgbm8gc3BlY2lhbCBwcm9jZWR1cmU7IGp1c3QgZm9sbG93IHRoZSANCiAgYWxsb2Nh dGlvbiBwb2xpY3kuPEJSPjxCUj4uLi4gDQogIDxQPg0KICA8SFI+DQoNCiAgPFA+PC9QPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPkF1ZGlvL1ZpZGVv IA0KICBUcmFuc3BvcnQgQ29yZSANCiAgTWFpbnRlbmFuY2U8QlI+YXZ0QGlldGYub3JnPEJSPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0PEJSPjwvQkxPQ0tRVU9URT48 L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_02B9_01CD5557.8DD562A0-- From bill.wu@huawei.com Thu Jun 28 03:10:48 2012 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 B5A4E21F8849 for ; Thu, 28 Jun 2012 03:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.001 X-Spam-Level: X-Spam-Status: No, score=-4.001 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] 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 b4rCrZaf-3Y6 for ; Thu, 28 Jun 2012 03:10:48 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 29C3E21F8A16 for ; Thu, 28 Jun 2012 03:02:23 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHG87292; Thu, 28 Jun 2012 06:02:22 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 28 Jun 2012 03:01:22 -0700 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 28 Jun 2012 03:01:18 -0700 Received: from w53375 (10.138.41.149) by szxeml423-hub.china.huawei.com (10.82.67.162) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 28 Jun 2012 18:01:10 +0800 Message-ID: <935282B8B2504427BDAC2FABCC39850A@china.huawei.com> From: Qin Wu To: "DRAGE, Keith (Keith)" , Magnus Westerlund , , References: <4fde00ba.8854b40a.5854.12a4@mx.google.com><4FE3271F.7020506@ericsson.com> <111C724E6D4143EA8F5D87DAD4BD6918@china.huawei.com> Date: Thu, 28 Jun 2012 18:01:10 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 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: Thu, 28 Jun 2012 10:10:49 -0000 SGksIA0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJEUkFHRSwgS2VpdGgg KEtlaXRoKSIgPGtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbT4NClRvOiAiUWluIFd1IiA8 YmlsbC53dUBodWF3ZWkuY29tPjsgIk1hZ251cyBXZXN0ZXJsdW5kIiA8bWFnbnVzLndlc3Rlcmx1 bmRAZXJpY3Nzb24uY29tPjsgPGF2dEBpZXRmLm9yZz47IDxkcmFmdC1pZXRmLWF2dGNvcmUtaWRt c0B0b29scy5pZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBKdW5lIDI4LCAyMDEyIDU6MTAgUE0N ClN1YmplY3Q6IFJFOiBbQVZUQ09SRV0gV0dMQyBvbiBkcmFmdC1pZXRmLWF2dGNvcmUtaWRtcy0w NQ0KDQoNClJlZ2FyZGluZyBJQU5BIHJlZ2lzdHJhdGlvbi4NCg0KVGhlIHJlcXVpcmVtZW50IGlz IHNwZWNpZmljYXRpb24gcmVxdWlyZWQsIHdoaWNoIGNhbiBvYnZpb3VzbHkgYmUgYSBzcGVjaWZp Y2F0aW9uIGZyb20gc29tZSBvdGhlciBib2R5IHRoYW4gSUVURi4NCg0KSWYgeW91IGdvIHRvIHRo ZSBJQU5BIHBhZ2UgeW91IHdpbGwgZmluZCBhIHNldCBvZiBwYWdlcyByZWxhdGluZyB0byByZXF1 ZXN0aW5nIGFuIGFzc2lnbm1lbnQuIEdlbmVyYWxseSBJIHdvdWxkIGV4cGVjdCB0aGUgc2VjcmV0 YXJpYXQgb2YgYSBzdGFuZGFyZHMgYm9keSB0byBjb21wbGV0ZSB0aGUgcmVxdWVzdCwgYWx0aG91 Z2ggYWdhaW4gSSBkb24ndCB0aGluayB0aGF0IGlzIG1hbmRhdG9yeS4gWW91IHdpbGwgc2VlIHRo ZSByZWdpc3RyYXRpb24gaW4gdGhpcyBjYXNlIGNhbWUgZnJvbSBhIG1lbWJlciBvZiB0aGUgRVRT SSBzZWNyZXRhcmlhdCBhbmQgdGhlIHJlZmVyZW5jZWQgc3BlY2lmaWNhdGlvbiBpcyBhbiBFVFNJ IHNwZWNpZmljYXRpb24uDQoNClRoaXMgaXMgYWxsIGVudGlyZWx5IGluIGFjY29yZGFuY2Ugd2l0 aCB0aGUgcmVnaXN0cnkgcmVxdWlyZW1lbnRzLg0KDQpbUWluXTogSSBhbSBjbGVhci4gVGhhbmsg Zm9yIHlvdXIgY2xhcmlmaWNhdGlvbi4NCg0KSSBkbyBub3RpY2UgdGhhdCB0aGUgSUVURiBkb2N1 bWVudCBhbmQgdGhlIEVUU0kgZG9jdW1lbnQgZGVmaW5lIG9uZSBhbmQgdGhlIHNhbWUgWFIgYmxv Y2suIElzIHRoZXJlIGFuIGludGVudGlvbiB0aGF0IHRoZSBFVFNJIGRvY3VtZW50IGdldHMgbW9k aWZpZWQgdG8gcmVmZXJlbmNlIHRoZSBJRVRGIGRvY3VtZW50IHdoZW4gZmluYWxseSBhcHByb3Zl ZCBhbmQgcHVibGlzaGVkIChpLmUuIHRoYXQgdGhlIElFVEYgZG9jdW1lbnQgdGFrZXMgb3duZXJz aGlwIGFuZCB1cGRhdGVzIHRoZSBleGlzdGluZyByZWdpc3RyYXRpb24/IE9yIGlzIHRoZXJlIHNv bWUgb3RoZXIgc3RyYXRlZ3kgZm9yIHRoaXMgYmxvY2sgdHlwZT8NCg0KW1Fpbl06IFRoYXQncyBt eSBjb25jZXJuIGFzIHdlbGwgYW5kIHdoeSByYWlzZSB0aGlzIGlzc3VlLg0KDQpXaGF0ZXZlciBv Y2N1cnMsIHRoaXMgc3RyYXRlZ3kgd2lsbCBwcm9iYWJseSBuZWVkIHNvbWUgZXhwbGFuYXRpb24g aW4gdGhlIElBTkEgY29uc2lkZXJhdGlvbnMuDQoNCltRaW5dOiBBZ3JlZS4NCg0KS2VpdGgNCg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBhdnQtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmF2dC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUWluIFd1DQpTZW50 OiAyOCBKdW5lIDIwMTIgMDQ6MDQNClRvOiBNYWdudXMgV2VzdGVybHVuZDsgYXZ0QGlldGYub3Jn OyBkcmFmdC1pZXRmLWF2dGNvcmUtaWRtc0B0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFtB VlRDT1JFXSBXR0xDIG9uIGRyYWZ0LWlldGYtYXZ0Y29yZS1pZG1zLTA1DQoNCkhpLA0KSSBoYXZl IHJldmlld2VkIFhSIEJsb2NrIGFzcGVjdCBhbmQgaXQgc2VlbXMgSUFOQSBoYXMgYWxyZWFkeSBh bGxvY2F0ZWQgQmxvY2sgVHlwZSAxMiB0byB0aGlzIElETVMgWFIgQmxvY2suIA0KaHR0cDovL3d3 dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9ydGNwLXhyLWJsb2NrLXR5cGVzL3J0Y3AteHItYmxvY2st dHlwZXMueG1sDQpJIGhhdmUgbm90IGJlZW4gYXdhcmUgb2YgdGhpcyBiZWZvcmUuIEkgYW0gd29u ZGVyaW5nIHdoYXQncyB0aGUgcHJvY2VkdXJlIGZvciBvdGhlciBTRE9zIHRvIGFzayBJRVRGIGZv ciBJQU5BIHJlZ2lzdHJ5Pw0KU2VuZCBMaWFpc29uIHN0YXRlbWVudCBvciBzb21ldGhpbmcgZWxz ZT8NCg0KQmVzaWRlcyB0aGlzLCBiZWxvdyBhcmUgYSBmZXcgY29tbWVudHMgcmVsYXRlZCB0byBY UiBCbG9jazoNCjEuIFNlY3Rpb24gNiwgDQpJdCBpcyBiZXR0ZXIgdG8gbnVtYmVyIHRoZSBmaWd1 cmUgaW4gdGhlIHNlY3Rpb24gNiB3aXRoIGEgdGl0bGUuDQoyLiBTZWN0aW9uIDYsIGZpZ3VyZQ0K SXQgaXMgdW51c3VhbCB0byByZXNldmUgc29tZSBiaXRzIGluIHRoZSBtaWRkbGUgb2YgInR5cGUg c3BlY2lmaWMgZmllbGQiIGFmdGVyIEJsb2NrIFR5cGUgKEJUKSBmaWVsZC4NCldoeSBub3QgbW92 ZSBQIGJpdCBiZWZvcmUgcmVzZXZlZCBiaXRzIGluIHRoaXMgZmllbGQuDQozLiBTZWN0aW9uIDYs IFNQU1QgZmllbGQNCkZvciBTUFNUID0yLCBpdCBpcyBiZXR0ZXIgdG8gcG9pbnQgb3V0IHRoZSBw YWNrZXQgc2VuZGVyIGlzIE1lZGlhIFN5bmNocm9uaXphdGlvbiBBcHBsaWNhdGlvbiBTZXJ2ZXIg KE1TQVMpDQp0byBnZXQgaW4gbGluZSB3aXRoIFNQU1QgPTE7DQo0LiBTZWN0aW9uIDYsIFBheWxv YWQgVHlwZSAoUFQpDQpQYXlsb2FkIFR5cGUgKFBUKSBhbmQgUGFja2V0IFR5cGUgKFBUKSBhcmUg ZGVmaW5lZCBpbiB0aGUgc2FtZSBYUiBCbG9jayBhbmQgaGFzIHRoZSBzYW1lIHNob3J0IG5hbWUs DQppdCBpcyBxdWl0ZSBjb25mdXNpbmcuIFN1Z2dlc3QgdG8gZGlzdGluY3QgdGhlbSBpbiB0aGUg WFIgQkxvY2sgZm9ybWF0Lg0KDQo1LiBTZWN0aW9uIDYsIFBheWxvYWQgVHlwZSAoUFQpDQpXaHkg U3luY2hyb25pemF0aW9uIENsaWVudCAoU0MpIHNob3VsZCBzZW5kIFBheWxvYWQgVHlwZSBpbiB0 aGUgWFIgQmxvY2sgbWVzc2FnZSB0byBNZWRpYSBTeW5jaHJvbml6YXRpb24gQXBwbGljYXRpb24g U2VydmVyIChNU0FTKQ0Kd2hpbGUgTVNBUyBkb2VzIG5vdCBuZWVkIHRvIHNlbmQgUGF5bG9hZCBU eXBlIGluIHRoZSBJRE1TIFJUQ1AgbWVzc2FnZSB0byAgU0M/DQpJdCBzZWVtcyB5b3UgaW5kaWNh dGUgTVNBUyBzaG91bGQgaGFuZGxlIHZhcmlvdXMgcGF5bG9hZCBUeXBlIHNlbnQgZnJvbSBkaWZm ZXJlbnQgU0NzPyBIb3cgTVNBUyBwcm9jc3MgUGF5bG9hZCBUeXBlPyBUaGUgUGF5bG9hZCBUeXBl IGRpZmZlcmVuY2UgDQplYWNoIFNDIGlzIHVzaW5nIGFmZmVjdCB0aGUgdGltZXN0YW1wcyBjYXJy aWVkIGluIHRoZSBJRE1TIFJUQ1AgcGFja2V0Pw0KDQpJIGFtIHdvbmRlcmluZyBpZiBpdCBpcyBy ZWFsbHkgbmVjZXNzYXJ5IHRvIGFsbG93IFhSIEJsb2NrIGNhcnJ5IFBheWxvYWQgVHlwZT8NCg0K Ni4gU2VjdGlvbiA2LCBTU1JDIG9mIG1lZGlhIHNvdXJjZSBmaWVsZA0KVG8gZ2V0IGluIGxpbmUg d2l0aCB0aGUgZXhpc3RpbmcgUlRDUCBYUiBCbG9jaywgaXQgaXMgYmV0dGVyIHB1dCBTU1JDIG9m IG1lZGlhIHNvdXJjZSBmaWVsZCByaWdodCBhZnRlciByZXBvcnQgQmxvY2sgaGVhZGVyIGJlZm9y ZSBQYXlsb2FkIFR5cGUgZmlsZWQuIA0KDQo3LiBTZWN0aW9uIDYsIFBhY2tldCBQcmVzZW50ZWQg TlRQIHRpbWVzdGFtcCBmaWVsZDoNCldoeSB0aGUgc2l6ZSBvZiBQYWNrZXQgUHJlc2VudGVkIE5U UCB0aW1lc3RhbXAgZmllbGQgaW4gdGhlIElETVMgWFIgYmxvY2sgaXMgMzIgYml0IHdoaWxlIHRo ZSBzaXplIG9mIFBhY2tldCBQcmVzZW50ZWQgTlRQIHRpbWVzdGFtcCBmaWVsZCBpbiB0aGUgSURN UyBSVENQIHBhY2tldA0KIGlzIDY0IGJpdD8gSXQgaXMgYmV0dGVyIHRvIGNsYXJpZnkgdGhpcyBp biB0aGUgZG9jdW1lbnQ/DQoNCjggU2VjdGlvbiA2LCBNZWRpYSBTdHJlYW0gQ29ycmVsYXRpb24g SWRlbnRpZmllciBmaWVsZDoNCkl0IGxvb2tzIHRoZSB2YWx1ZSBvZiBNZWRpYSBTdHJlYW0gQ29y cmVsYXRpb24gSWRlbnRpZmllciAgaXMgc2FtZSBhcyBTeW5jR3JvdXBJZCwNClN5bkdyb3VwSUQg aXMgc2lnbmFsZWQgdXNpbmcgU0RQIGFuZCBTQyBvciBNU0FTIGp1c3QgdXNlIHB1dCBTeW5jR3Jv dXBJRCANCmludG8gTWVkaWEgU3RyZWFtIENvcnJlbGF0aW9uIElkZW50aWZpZXIgZmllbGQNCkkg YW0gd29uZGVyaW5nIHdoeSBub3QgdXNlIHRoZSBzYW1lIG5hbWUgZm9yIHRoZW0/IFRoYXQgaXMg dG8gc2F5LCBjaGFuZ2UgTWVkaWEgU3RyZWFtIENvcnJlbGF0aW9uIGZpZWxkIHRvIFN5bmNHcm91 cElkLg0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZy b206ICJNYWdudXMgV2VzdGVybHVuZCIgPG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4N ClRvOiA8YXZ0QGlldGYub3JnPjsgPGRyYWZ0LWlldGYtYXZ0Y29yZS1pZG1zQHRvb2xzLmlldGYu b3JnPg0KU2VudDogVGh1cnNkYXksIEp1bmUgMjEsIDIwMTIgOTo1MiBQTQ0KU3ViamVjdDogUmU6 IFtBVlRDT1JFXSBXR0xDIG9uIGRyYWZ0LWlldGYtYXZ0Y29yZS1pZG1zLTA1DQoNCg0KSGksDQoN ClRoaXMgaXMgbXkgV0cgbGFzdCBjYWxsIHJldmlldyBhcyBhbiBpbmRpdmlkdWFsLiBJIHRoaW5r IHRoZXJlIGlzIHF1aXRlDQphIGxvdCB0byBhZGRyZXNzIGJlZm9yZSB0aGlzIGRvY3VtZW50IGlz IHJlYWR5IGZvciBwdWJsaWNhdGlvbiByZXF1ZXN0Lg0KDQoxLiBUaGlzIGRvY3VtZW50IGhhcyA2 IGF1dGhvcnMgbGlzdGVkLiBUaGlzIGlzIG9uZSBtb3JlIHRoYW4gdGhlIHBvbGljeQ0KYWxsb3dz Og0KaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9wb2xpY3kuaHRtbCNwb2xpY3kuYXV0aGxpc3QN Cg0KMi4gQWJzdHJhY3Q6DQoiVGhpcyBkb2N1bWVudCBnaXZlcyBpbmZvcm1hdGlvbiBvbiBhbiBS VENQIFBhY2tldCBUeXBlIGFuZCBSVENQIFhSDQogICBCbG9jayBUeXBlIGluY2x1ZGluZyBhc3Nv Y2lhdGVkIFNEUCBwYXJhbWV0ZXJzIGZvciBJbnRlci1EZXN0aW5hdGlvbg0KICAgTWVkaWEgU3lu Y2hyb25pemF0aW9uIChJRE1TKS4iDQoNCkRvZXNuJ3QgaXQgZGVmaW5lIHRoZXNlIHBhY2tldC9i bG9jayB0eXBlcz8NCg0KMy4gU2VjdGlvbiAzOg0KDQpUaGUgbGFkZGVyIGRpYWdyYW1zIGZpcnN0 IGxpbmUgaXMgd3JvbmdseSBpbmRlbnRlZC4NCg0KMy4gU2VjdGlvbiAzLiBMYWRkZXIgZGlhZ3Jh bSwgbWF5YmUgdGhpcyBkaWFncmFtIHNob3VsZCBoYXZlIHNvbWUNCmhhbmRsZSwgbGlrZSBmaWd1 cmUgMSB3aXRoIGEgbGFiZWwuDQoNCjQuIFNlY3Rpb24gMy4NCkkgYW0gbWlzc2luZyBkaXNjdXNz aW9uIG9uIHRoZSBvdmVydmlldyBsZXZlbCBvZiBjbG9ja3MuIFllcyBpdCBpcw0KcHJlc2VudCBs YXRlciwgYnV0IEkgdGhpbmsgdGhlIHRvcGljIHNob3VsZCBiZSBpbnRyb2R1Y2VkIGFscmVhZHkg aGVyZQ0KaXMgc2VjdGlvbiAzLg0KDQo1LiBTZWN0aW9uIDYuIEkgdGhpbmsgdGhpcyBzZWN0aW9u IHNob3VsZCBtYWtlIGl0IGNsZWFyIGhvdyBhbiBTQyBjYW4NCmluY2x1ZGUgbXVsdGlwbGUgcmVw b3J0IGJsb2NrcyBmb3IgZGlmZmVyZW50IHJlY2VpdmVkIHNvdXJjZXMuIEluDQpnZW5lcmFsIEkg dGhpbmsgdGhpcyBtYXkgYmUgYSB0b3BpYyB0aGF0IG5lZWRzIHRvIGJlIGxpZnRlZCBpbnRvIHRo ZQ0Kb3ZlcnZpZXcuIFRoZSBpc3N1ZSBJIHNlZSBpcyB0aGUgZm9sbG93aW5nIG9uZXMuDQoNCmEp IFdpdGhpbiBhIG11bHRpLXBhcnR5IGNvbW11bmljYXRpb24gc2Vzc2lvbiBkaWZmZXJlbnQgbWVk aWEgc2VuZGVycw0KaW5jbHVkZSBkaWZmZXJlbnQgcmVmZXJlbmNlIGNsb2Nrcy4gVGh1cyBjcmVh dGluZyBtdWx0aXBsZQ0Kc3luY2hyb25pemF0aW9uIGdyb3VwcyB3aXRoaW4gdGhlIGNvbnRleHQg b2Ygb25lIG11bHRpLW1lZGlhDQpjb21tdW5pY2F0aW9uIHNlc3Npb24uDQoNCmIpIGV2ZW4gaWYg dGhleSBjYW4gYWdyZWUgb24gdXNpbmcgdGhlIHNhbWUgY2xvY2sgcmVmZXJlbmNlIHRoZXkgc3Rp bGwNCm5lZWQgdG8gZW5hYmxlIHRoZSBmYWN0IHRoYXQgYW4gZW5kLXBvaW50IGlzIGFjdGluZyBh cyBNU0FTIGZvciBzb21lDQptZWRpYSBzb3VyY2VzIGFuZCBTQyBmb3Igb3RoZXJzLiBUaGlzIHNo b3VsZCBiZSBtYWRlIG1vcmUgY2xlYXIuDQoNCjYuIFNlY3Rpb24gNiBhcHBlYXJzIHRvIGJlIGEg bm9ybWF0aXZlIGRlZmluaXRpb24gb2YgUlRDUCBYUiBibG9jayB0eXBlDQoxMi4gVGhhdCBibG9j ayB0eXBlIGlzIHJlZ2lzdGVyZWQgYnkgSUFOQSBhcyBiZWxvbmdpbmcgdG8gRVRTSSAxODMgMDYz DQpzcGVjaWZpY2F0aW9uLiBVbmxlc3Mgd2UgaGF2ZSBhIGZvcm1hbCBsaWFzaW9uIGFzc2lnbmlu ZyB0aGUgY2hhbmdlDQpyaWdodCB0byBJRVRGIEkgZG9uJ3Qgc2VlIGhvdyB3ZSBjYW4gbWFrZSBh biB1cGRhdGVkIG5vcm1hdGl2ZQ0Kc3BlY2lmaWNhdGlvbiBvZiB0aGlzIFhSIGJsb2NrIHR5cGUu IEkgc2VlIHR3byBvcHRpb25zLg0KDQphKSBJRVRGIGFyZSBnaXZlbiB0aGUgY2hhbmdlIHJpZ2h0 IG92ZXIgdGhlIGJsb2NrIHR5cGUNCg0KYikgSUVURiBtYWtlcyBhIG5vcm1hdGl2ZSByZWZlcmVu Y2UgdG8gdGhlIEVUU0kgc3BlY2lmaWNhdGlvbiBvZiB0aGUNCmJsb2NrIHR5cGUgYW5kIHRoZW4g c2ltcGx5IG1ha2VzIGl0IGNsZWFyIHRoYXQgdGhleSBvbmx5IHVzZXMgU1BTVD0xLg0KDQo3LiBT ZWN0aW9uIDYuIEFzc3VtaW5nIHRoYXQgdGhlIG5vcm1hdGl2ZSBkZWZpbml0aW9uIHdpbGwgcmVt YWluIGFuZA0KcG9zc2libHkgYWxzbyBhcyBhIGNsYXJpZmljYXRpb24gdG8gdGhlIEVUU0kgc3Bl Y2lmaWNhdGlvbjogVGhpcyBzZWN0aW9uDQppcyBub3QgbWFraW5nIGl0IHN1ZmZpY2llbnQgY2xl YXIgdGhhdCB3aGF0IGFuIFNDIGlzIHN1cHBvc2VkIHRvIGRvIGlzDQp0byBwaWNrIG9uZSBSVFAg cGFja2V0IGl0IHJlY2V2aWVkLCB0aGVuIHJlcG9ydCB0aGUgdmFsdWVzIGZvciB0aGlzDQpwYXJ0 aWN1bGFyIHBhY2tldC4gSSB0aGluayBvbmUgc2hvdWxkIGNsYXJpZnkgdGhpcyBhbmQgYWxzbyBt YWtpbmcgaXQNCmNsZWFyZXIgd2hhdCB0aGUgc2VsZWN0aW9uIGNyaXRlcmlhIGZvciBzdWNoIGEg cGFja2V0IGlzLiBTaG91bGQgb25lDQpmb2N1cyBvbiB1c2luZyBtYXhpbXVtIGRlbGF5ZWQgcGFj a2V0cywgbWVkaWEgZGVsYXllZCBwYWNrZXRzIG9yIHNpbXBseQ0KcmFuZG9tIHNlbGVjdGlvbj8g SW4gYWRkaXRpb24gd2UgaGF2ZSB0aGUgcnVsZXMgYWJvdXQgcGlja2luZyBwYWNrZXRzDQp3aGVu IG11bHRpcGxlIFJUUCBzZXF1ZW5jZSBudW1iZXJzIGhhdmUgdGhlIHNhbWUgVFMgdmFsdWUuIEkg d291bGQNCnJlY29tbW5lZCB0aGF0IG9uZSBhZGQgc29tZSBwYXJhZ3JhcGhzIGJlZm9yZSB0aGUg YWN0dWFsIGZpZ3VyZQ0KZGVmaW5pdGlvbiB0byBkaXNjdXNzIHRoaXMuDQoNCjguIFNlY3Rpb24g NiwgUFQgZmllbGQgZGVmaW5pdGlvbi4gVGhpcyBpcyBub3QgbWFraW5nIGNsZWFyIHRoYXQgb25l DQpzaGFsbCByZXBvcnQgdGhlIFBUIG9mIHRoZSBwYWNrZXQgb25lIGlzIHJlcG9ydGluZyBvbi4N Cg0KOS4gU2VjdGlvbiA2Lg0KICAgTWVkaWEgU3RyZWFtIENvcnJlbGF0aW9uIElkZW50aWZpZXI6 IDMyIGJpdHMuICBUaGlzIGlkZW50aWZpZXIgaXMNCiAgIHVzZWQgdG8gY29ycmVsYXRlIHN5bmNo cm9uaXplZCBtZWRpYSBzdHJlYW1zLiAgVGhlIHZhbHVlIDAgKGFsbCBiaXRzDQogICBhcmUgc2V0 ICIwIikgaW5kaWNhdGVzIHRoYXQgdGhpcyBmaWVsZCBpcyBlbXB0eS4gIFRoZSB2YWx1ZSAyXjMy LTENCiAgIChhbGwgYml0cyBhcmUgc2V0ICIxIikgaXMgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2Uu ICBJZiB0aGUgUlRDUA0KICAgUGFja2V0IFNlbmRlciBpcyBhbiBTQyAoU1BTVD0xKSBvciBhbiBN U0FTIChTUFNUPTIpLCB0aGVuIHRoZSBNZWRpYQ0KICAgU3RyZWFtIENvcnJlbGF0aW9uIElkZW50 aWZpZXIgbWFwcyBvbiB0aGUgU3luY2hyb25pemF0aW9uIEdyb3VwDQogICBJZGVudGlmaWVyIChT eW5jR3JvdXBJZCkgdG8gd2hpY2ggdGhlIHJlcG9ydCBhcHBsaWVzLg0KDQpJdCBpcyBub3QgY2xl YXIgd2hhdCAibWFwcyIgbWVhbnMgaGVyZS4gQ29uc2lkZXJpbmcgdGhhdCB0aGUgZmllbGQNCmFw cGVhcnMgdG8gY2FycnkgdGhlIGZ1bGwgc3luY2dyb3VwSUQgSSB0aGluayBhbm90aGVyIGZvcm11 bGF0aW9uIHNoYWxsDQpiZSB1c2VkLg0KDQoxMC4gU2VjdGlvbiA2Lg0KIlRvIHNvbHZlDQogICB0 aGlzLCBhbiBTQyBTSE9VTEQgcmVwb3J0IG9uIFJUUCBwYWNrZXRzIGluIHdoaWNoIGEgY2VydGFp biBSVFANCiAgIHRpbWVzdGFtcCBzaG93cyB1cCBmb3IgdGhlIGZpcnN0IHRpbWUuIg0KDQpEb2Vz IHRoaXMgbWVhbnMgd2l0aCB0aGUgbG93ZXN0IHNlcXVlbmNlIG51bWJlciBvciB0aGUgcGFja2V0 IGZpcnN0IHRvDQphcnJpdmUgd2l0aCB0aGF0IFRTPw0KDQoxMS4gU2VjdGlvbiA3IFRpdGxlDQoi UlRDUCBQYWNrZXQgVHlwZSBmb3IgSURNUyAoSURNUyByZXBvcnQpIg0KDQpXaHkgaXMgdGhlIHBh Y2tldCB1c2VkIHRvIGRpc3RyaWJ1dGUgdGhlIGludGVuZGVkIHBsYXlvdXQgdGltaW5nIGNhbGxl ZA0KYSAicmVwb3J0Ii4gVGhpcyBpcyB2ZXJ5IGNvbmZ1c2luZyBjb25zaWRlcmluZyB0aGF0IHRo ZSBYUiBpcyBhIHJlcG9ydCBhbHNvLg0KDQoNCjEyLiBTZWN0aW9uIDcuDQoNCiAgIFNTUkM6IDMy IGJpdHMuICBUaGUgU1NSQyBvZiB0aGUgbWVkaWEgc291cmNlIFNIQUxMIGJlIHNldCB0byB0aGUN CiAgIHZhbHVlIG9mIHRoZSBTU1JDIGlkZW50aWZpZXIgY2FycmllZCBpbiB0aGUgUlRQIGhlYWRl ciBbUkZDMzU1MF0gb2YNCiAgIHRoZSBSVFAgcGFja2V0IHRvIHdoaWNoIHRoZSBSVENQIElETVMg cGFja2V0IHJlbGF0ZXMuDQoNCkZpcnN0IG9mIGFsbCBJIGFzc3VtZSB0aGlzIGZpZWxkIGRlZmlu aXRpb24gaXMgZm9yICJTU1JDIG9mIG1lZGlhDQpzb3VyY2UiIGZpZWxkLg0KDQphLiBXaGF0IGlz bid0IGNsZWFyIGlzIGlmIGl0IGlzIGF0IGFsbCB2YWxpZCB0aGF0IGFub3RoZXIgU1NSQyAiU1NS QyBvZg0KcGFja2V0IHNlbmRlciIgdGhhbiB0aGUgIlNTUkMgb2YgbWVkaWEgc291cmNlIiBpcyBh bGxvd2VkIGFuZCBzaGFsbCBiZQ0KY29uc2lkZXJlZCB2YWxpZC4NCg0KYi4gU2Vjb25kbHksIHdo ZW4gYW4gZW5kLXBvaW50IGhhcyBtdWx0aXBsZSBzb3VyY2VzIGluIHRoZSBzYW1lIFJUUA0Kc2Vz c2lvbiB0byBzZW5kIGl0IGFwcGVhcnMgdGhleSBuZWVkIHRvIHNlbmQgbXVsdGlwbGUgUlRDUCBw YWNrZXRzLg0KDQoxMy4gU2VjdGlvbiA3Lg0KDQpJdCBpcyBub3QgY2xlYXIgaWYgdGhlcmUgYXJl IGFueSByZXN0cmljdGlvbnMgb24gdGhlIHZhbHVlcyB0byBiZQ0KaW5jbHVkZWQgaW4gdGhlIFJU Q1AgcGFja2V0LiBNdXN0IHRoZSBzZW5kZXIgb2YgaXQgaW5jbHVkZSBpbmZvcm1hdGlvbg0KZm9y IGEgYWxyZWFkeSBzZW50IHBhY2tldCwgYSBmdXR1cmUgcGFja2V0IG9yIGNhbiBpdCBldmVuIGJl IGEgdmlydHVhbA0KcGFja2V0IHRoYXQgaXMgbmV2ZXIgc2VudD8NCg0KSSB1bmRlcnN0YW5kIHRo YXQgb25lIGNhbiBzY2FsZSB0aGUgZmlndXJlcyBpbiB0aGlzIHBhY2tldCB0byBkZXRlcm1pbmUN CndoYXQgdGhlIGNvcnJlY3QgdmFsdWUgc2hvdWxkIGJlIGdpdmVuIGEgcmVjZWl2ZWQgUlRQIHBh Y2tldCBhbmQgaXRzDQp0aW1lc3RhbXAuIEJ1dCwgYXJlIEkgYWxsb3dlZCB0byBjYWxjdWxhdGUg YSBjb3JyZWN0IHRpbWUgdmFsdWUgYSB5ZWFyDQppbnRvIHRoZSBmdXR1cmUgdGhhdCBpcyB0aGVu IGV4cGVjdGVkIHRvIGJlIHNjYWxlZCBiYWNrLiBPciBpcyB0aGUgUlRQDQp0aW1lc3RhbXAgdmFs dWUgaW5jbHVkZWQgaW4gdGhlIHBhY2tldCBpbiBpdHNlbGYgYW4gaW5kaWNhdGlvbiBmb3Igd2hl bg0KdGhpcyBpbmZvcm1hdGlvbiB3YXMgY3VycmVudD8NCg0KMTQuIFNlY3Rpb24gOC4NCiAgIFtJ LUQuZHJhZnQtd2lsbGlhbXMtYXZ0Y29yZS1jbGtzcmNdIGRlZmluZXMgYSBzZXQgb2YgU0RQIHBh cmFtZXRlcnMNCiAgIGZvciBzaWduYWxpbmcgdGhlIGNsb2NrIHN5bmNocm9uaXphdGlvbiBzb3Vy Y2Ugb3Igc291cmNlcyBhdmFpbGFibGUNCiAgIHRvIGFuZCB1c2VkIGJ5IHRoZSBpbmRpdmlkdWFs IHJlY2VpdmVycy4gIFVzaW5nIHRoZXNlIHBhcmFtZW50ZXJzLCBhbg0KICAgU0MgY2FuIGluZGlj YXRlIHdoaWNoIHN5bmNocm9uaXphdGlvbiBzb3VyY2UgaXMgYmVpbmcgdXNlZCBhdCB0aGUNCiAg IG1vbWVudCwgdGhlIGxhc3QgdGltZSB0aGUgU0Mgc3luY2hyb25pemVkIHdpdGggdGhpcyBzb3Vy Y2UgYW5kIHRoZQ0KICAgc3luY2hyb25pemF0aW9uIGZyZXF1ZW5jeS4gIEFuIFNDIGNhbiBhbHNv IGluZGljYXRlIGFueSBvdGhlcg0KICAgc3luY2hyb25pemF0aW9uIHNvdXJjZXMgYXZhaWxhYmxl IHRvIGl0LiAgVGhpcyBhbGxvd3MgbXVsdGlwbGUgU0NzIGluDQogICBhbiBJRE1TIHNlc3Npb24g dG8gdXNlIHRoZSBzYW1lIG9yIGEgc2ltaWxhciBjbG9jayBzb3VyY2UgZm9yIHRoZWlyDQogICBz ZXNzaW9uLg0KDQpTbyB0aGUgY2xrc3JjIGRyYWZ0IGFwcGVhciB0byBpbmRlbmRlZCB0byBkZWZp bmUgdGhlIHVzYWdlIG9mIGE9c3NyYyB0bw0KbWFrZSBpdCBjbGVhciB3aGljaCBjbG9jayBzb3Vy Y2UgYSBwYXJ0aWN1bGFyIFNTUkMgdXNlcy4gV2hhdCBpc24ndA0KY2xlYXIgZnJvbSB0aGlzIHRl eHQgaXMgdGhhdCB3aGVuIHByb3ZpZGluZyByZXBvcnRpbmcgdGhhdCBhbGwgbm9kZXMNCnNlbmRp bmcgYSByZXBvcnQgb3IgYSBjb25maWd1cmF0aW9uIG11c3QgdXNlIHRoZWlyIHZpZXcgb2YgdGhh dA0KcGFydGljdWxhciBjbG9jayBzb3VyY2UuIEkgdGhpbmsgdGhlIGltcGxpY2F0aW9ucyBvZiBo YXZpbmcgbXVsdGlwbGUNCmNsb2NrIHNvdXJjZXMgaW4gYW4gUlRQIHNlc3Npb24gbXVzdCBiZSBt YWRlIGNsZWFyZXIuIEFzIHRoZSB1c2VkIGNsb2NrDQpjb21lcyBpbnRvIHBsYXkgYm90aCB3aGVu IGNvbmZpZ3VyaW5nLCByZXBvcnRpbmcgYW5kIGFkanVzdGluZyB0aW1lDQpzY2FsZXMgZm9yIHBs YXlvdXQuDQoNCjE1LiBTZWN0aW9uIDk6DQoNCiAgIFN5bmNHcm91cElkID0gMSpESUdJVCA7IE51 bWVyaWNhbCB2YWx1ZSBmcm9tIDAgdGhyb3VnaCA0Mjk0OTY3Mjk0DQoNCkFzIHRoZSBzeW5jZ3Jv dXBJRCBpcyBsaW1pdGVkIHRvIDEwIGRpZ2l0cywgd2h5IG5vdCBtYWtlIHRoYXQgY2xlYXIgaW4N CnRoZSBBQk5GIGFsc28gdXNpbmcgMSoxMERJR0lUIGFzIHRoZSBkZWZpbml0aW9uLg0KDQpBcHBs aWVzIGFsc28gdG8gU2VjdGlvbiAxMC4NCg0KMTYuIFNlY3Rpb24gMTEuDQoNCkFzIHNvbWVvbmUg ZWxzZSBub3RlZC4gVGhpcyBzZWN0aW9uIHJlYWxseSBuZWVkcyB0byBiZSBzcGxpdCBpbnRvDQpP ZmZlci9BbnN3ZXIgcnVsZXMgYW5kIG9uZSBvbiBUSVNQQU4gaW50ZXJvcC4NCg0KMTYuIFNlY3Rp b24gMTEuIE9mZmVyL0Fuc3dlciBydWxlcw0KSXQgaXMgbm90IGNsZWFyIGhvdyBvbmUgZGVhbHMg d2l0aCB0aGUgcG90ZW50aWFsIGV4aXN0ZW5jZSBvZiBtdWx0aXBsZQ0Kc3luYyBncm91cHMgb3Ig aG93IHRoZSBJRCBpcyBuZWdvdGlhdGVkLiBFc3BlY2lhbGx5IHdoZW4geW91IGluIGENCm11bHRp LXBhcnR5IG5lZ290aWF0ZSB3aXRoIGFuIGFwcGxpY2F0aW9uIHNlcnZlci4NCg0KSSBhbHNvIHRo aW5rIGl0IHNob3VsZCBtYWtlIGNsZWFyIGhvdyBpdCB3b3JrcyBpbiBkZWNsYXJhdGl2ZSBjYXNl cywNCmxpa2UgUlRTUCBTRFBzLg0KDQoxNy4gU2VjdGlvbiAxNC4NCg0KVGhpcyBJQU5BIHJlZ2lz dHJhdGlvbiBpcyBpbnN1ZmZpY2llbnQuIEl0IG5lZWRzIHRvIGJlIG1vcmUgcHJlY2lzZSBpbg0K d2hpY2ggcmVnZXN0cmllcyB0aGF0IGFyZSB0byBiZSB1c2VkLg0KDQpUbyBteSB1bmRlcnN0YW5k IHRoZSBmb2xsb3dpbmcgYWN0aW9ucyBhcmUgcmVxdWlyZWQ6DQoNCnJlZ2lzdGVyIGEgbWVkaWEg bGV2ZWwgU0RQIGF0dHJpYnV0ZTogVGhpcyBpcyBva2F5IGNvbnNpZGVyaW5nIHRoZQ0KdGVtcGxh dGUgYnV0IG9uZSBjb3VsZCBjbGFyaWZ5IHRoYXQgdGhlIHJlZ2lzdHJ5IGludGVuZGVkIGlzIHRo ZSBvbmUNCnRpdGxlZCAiYXR0LWZpZWxkICAobWVkaWEgbGV2ZWwgb25seSkiDQpodHRwOi8vd3d3 LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3NkcC1wYXJhbWV0ZXJzL3NkcC1wYXJhbWV0ZXJzLnhtbCNz ZHAtcGFyYW1ldGVycy05DQoNCg0KT25lIFJUQ1AgQ29udHJvbCBQYWNrZXQgdHlwZXMgKFBUKToN Cmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvcnRwLXBhcmFtZXRlcnMvcnRwLXBhcmFt ZXRlcnMueG1sI3J0cC1wYXJhbWV0ZXJzLTMNCg0KQW5kIGlmIHRoZSBYUiBibG9jayB0eXBlIGlz IHRvIGJlIG5vcm1hdGl2ZWx5IGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudA0KdGhlbiB0d28gcmVn aXN0cmF0aW9ucyBhcmUgbmVlZGVkOg0KDQotIE5ldyBvciB1cGRhdGUgb2YgUlRDUCBYUiBCbG9j ayBUeXBlDQpodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3J0Y3AteHItYmxvY2stdHlw ZXMvcnRjcC14ci1ibG9jay10eXBlcy54bWwNCi0gQWRkIHRoZSBYUiBTRFAgcGFyYW1ldGVyOg0K aHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9ydGNwLXhyLXNkcC1wYXJhbWV0ZXJzL3J0 Y3AteHItc2RwLXBhcmFtZXRlcnMueG1sDQoNCjE4LiBSZWZlcmVuY2VzLiBTaG91bGQgW0ktRC5k cmFmdC1ncm9zcy1sZWFwLXNlY29uZF0gYmUgbm9ybWF0aXZlPw0KSXQgaXMgbm90IHdyaXR0ZW4g aW4gYSBSRkMgMjExOSBzdHlsZSBhbiByZXF1aXJlbWVudCB0byB0YWtlIHRoaXMNCmRvY3VtZW50 IGludG8gYWNjb3VudCwgc28gbWF5YmUgaW5mb3JtYXRpdmUgaXMgY29ycmVjdC4NCg0KDQpDaGVl cnMNCg0KTWFnbnVzDQoNCg0KDQpPbiAyMDEyLTA2LTE3IDE4OjA0LCBSb25pIEV2ZW4gd3JvdGU6 DQo+IEhpLA0KPiANCj4gSSB3b3VsZCBsaWtlIHRvIHN0YXJ0IGEgV0dMQyBvbiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWF2dGNvcmUtaWRtcy0wNSAsIFJUQ1AgZm9yIGlu dGVyLWRlc3RpbmF0aW9uIG1lZGlhIHN5bmNocm9uaXphdGlvbi4NCj4gDQo+ICANCj4gDQo+IFRo ZSBXR0xDIHdpbGwgZW5kIG9uIEp1bHkgMTB0aCwgMjAxMg0KPiANCj4gIA0KPiANCj4gUGxlYXNl IHJldmlldyB0aGUgZHJhZnQgYW5kIHNlbmQgY29tbWVudHMgdG8gdGhlIGxpc3QuDQo+IA0KPiAg DQo+IA0KPiBGb3IgdGhlIGRyYWZ0IGF1dGhvcnM7ICBBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIg dGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWlldGYtYXZ0Y29yZS1pZG1zLTA1PyBJZiBzbywNCj4gDQo+ IGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIg cnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWls cyk/DQo+IA0KPiBUaGUgYWJvdmUgcXVlc3Rpb24gaXMgbmVlZGVkIGZvciB0aGUgZG9jdW1lbnQg d3JpdGUtdXAgd2hlbiBzZW50IHRvIHB1YmxpY2F0aW9uLg0KPiANCj4gIA0KPiANCj4gVGhhbmtz DQo+IA0KPiAgDQo+IA0KPiBSb25pIEV2ZW4NCj4gDQo+IEFWVGNvcmUgIGNvLWNoYWlyDQo+IA0K PiAgDQo+IA0KDQoNCi0tIA0KDQpNYWdudXMgV2VzdGVybHVuZA0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpN dWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RWTQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgy ODcNCkbkcvZnYXRhbiA2ICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQpT RS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW58IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJp Y3Nzb24uY29tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRl bmFuY2UNCmF2dEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9hdnQNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpB dWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KYXZ0QGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dA== From ron.even.tlv@gmail.com Thu Jun 28 14:54:34 2012 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 6C31811E80C7 for ; Thu, 28 Jun 2012 14:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 0pKXGB3U44Ef for ; Thu, 28 Jun 2012 14:54:29 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C6A5011E80C6 for ; Thu, 28 Jun 2012 14:54:28 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1811679wgb.13 for ; Thu, 28 Jun 2012 14:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=m53LBXaIqupwXGy5r8vcIUpEtfsd65LYNPktBjm/IMk=; b=YF3Rc632NIq+870+pv89scBR4tbPNyO1rkM3W15r4UaRmRcXRdh/F87aOBYjeH8BaG pWFJ1WJRSiHpM2f+foalXBbs7oqKvC8DPD8dnMK0b6Qvk6VJ6bA4gFIdQ7Bn1/jWUF+G BprTZG5QZTs/t2LHmgtn1nNn9IVXZADo+I6gJ8reGqcDek24P9H7KLqOzRbV2IcbTCRc Ex0GkJFCT99irZJGYxI8ORPeqzr22du1LGRexCi25Pp/++UvmBozjEHtX9p2mfWbXX7N BBRBZ/2PXTcgf/zFp2HSb8ArSlMzsBK1s8Cpbc8xbZePhF+yoL45mzqp0k6cvQJIR5pE 93DQ== Received: by 10.216.207.151 with SMTP id n23mr2109711weo.100.1340920467982; Thu, 28 Jun 2012 14:54:27 -0700 (PDT) Received: from RoniE ([109.64.198.75]) by mx.google.com with ESMTPS id eu4sm2595721wib.2.2012.06.28.14.54.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jun 2012 14:54:27 -0700 (PDT) From: "Roni Even" To: Date: Fri, 29 Jun 2012 00:54:07 +0200 Message-ID: <00f301cd5580$edee88a0$c9cb99e0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F4_01CD5591.B177F4E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1VgOwcGk4KskvfTk6BtIizTtNPBw== Content-Language: en-us Cc: Magnus Westerlund Subject: [AVTCORE] AVTCore sessions in Vancouver - request for agenda time 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: Thu, 28 Jun 2012 21:54:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F4_01CD5591.B177F4E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The prelimanry agenda was published. AvtCore will have two timeslots. Note that this is not the final agenda and may change. Please let the WG chairs know if you would like to present avtcore Session 1 (2:00:00) Thursday, Afternoon Session II 1510-1710 Room Name: Regency E --------------------------------------------- avtcore Session 2 (1:00:00) Friday, Afternoon Session I 1120-1220 Room Name: Regency E --------------------------------------------- If you wish to have agenda time at the upcoming meeting regarding AVTcore work, please send an agenda request to the AVTcore chairs. We are trying to prepare the agenda early and not wait for the last minute. Thanks Roni Even AVTCore co-chair ------=_NextPart_000_00F4_01CD5591.B177F4E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

The prelimanry = agenda was published. AvtCore will have two timeslots. Note that this is = not the final agenda and may change.

 

 

Please let = the WG chairs know if you would like to present

 

    avtcore Session 1 = (2:00:00)

    = Thursday, Afternoon Session II 1510-1710

    Room Name: Regency = E

   =  ---------------------------------------------

    avtcore Session 2 = (1:00:00)

    = Friday, Afternoon Session I 1120-1220

    Room Name: Regency = E

    = ---------------------------------------------

 

 

If you = wish to have agenda time at the upcoming meeting regarding AVTcore work, = please send an agenda request to the AVTcore chairs. We are trying to = prepare the agenda early and not wait for the last = minute.

Thanks

Roni Even

AVTCore co-chair

 

 

------=_NextPart_000_00F4_01CD5591.B177F4E0-- From csp@csperkins.org Fri Jun 29 05:18:21 2012 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 8D92C21F869C for ; Fri, 29 Jun 2012 05:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 o108V75ryepK for ; Fri, 29 Jun 2012 05:18:20 -0700 (PDT) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfa.amsl.com (Postfix) with ESMTP id 93B4E21F86FD for ; Fri, 29 Jun 2012 05:18:20 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Ska9T-0003RO-p8; Fri, 29 Jun 2012 12:18:19 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4fde00ba.8854b40a.5854.12a4@mx.google.com> Date: Fri, 29 Jun 2012 13:18:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <192F77F8-66E2-46B0-BE3C-F7B22CB72794@csperkins.org> References: <4fde00ba.8854b40a.5854.12a4@mx.google.com> To: Roni Even X-Mailer: Apple Mail (2.1278) Cc: draft-ietf-avtcore-idms@tools.ietf.org, avt@ietf.org Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 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: Fri, 29 Jun 2012 12:18:21 -0000 Roni, I have some comments on this draft: - I don't believe RTCP is on the RFC Editor's list of approved acronyms = for document titles, but RTP is, so I suggest changing the title of the = draft to "Inter-destination Media Synchronisation Using the RTP Control = Protocol (RTCP)". - Acronyms also need expanding on first use in the abstract. - Editorial: the draft might read better if the Section 1.1 heading were = removed, and if sub-sections 1.2, 1.3, and 1.4 were made part of a new = Section 2 "Rationale". - Editorial: in Section 1.2, "scalable to large multicast networks" may = be better phrased "scalable to large groups" since the functionality is = not multicast specific. - Section 3, near the end of page 6, the draft says "...when both Alice = and Bob received (or played out) a particular RTP packet". This might be = clearer written "when both Alice and Bob received (and, optionally, when = they played out) a particular RTP packet".=20 - Section 3 doesn't seem to mention that Alice and Bob need synchronised = clocks for this to work. It probably should. - I find the justification for using a 32 bit NTP presentation timestamp = in Section 6, but a 64 bit NTP presentation timestamp in Section 7 to be = unconvincing. Could you either strengthen the justification, or move to = a common size? - Section 6: is the PT field needed? The combination of RTP timestamp = and SSRC should identify a packet, even with changes in PT and clock = rate. - Section 6, penultimate paragraph: "...in which a certain RTP timestamp = shows up for the first time" is problematic, since the RTP timestamp can = wrap.=20 - Section 8: "receiver involved need synchronised clocks" - yes, but be = clear what clock needs to be synchronised. The RTP-format media clocks = don't need to be synchronised, for example, while the NTP-format clock = does. - Section 8, 3rd paragraph: is the use of the mechanism in = draft-williams-avtcore-clksrc mandatory? It would be useful to make an = RFC 2119 style recommendation here. - Section 8, last paragraph: should "...is therefore recommended to take = the guidelines..." be "...RECOMMENDED..."? Colin On 17 Jun 2012, at 17:04, Roni Even wrote: > Hi, > I would like to start a WGLC on = http://tools.ietf.org/html/draft-ietf-avtcore-idms-05 , RTCP for = inter-destination media synchronization. > =20 > The WGLC will end on July 10th, 2012 > =20 > Please review the draft and send comments to the list. > =20 > For the draft authors; Are you aware of any IPR that applies to = draft-ietf-avtcore-idms-05? If so, > has this IPR been disclosed in compliance with IETF IPR rules (see = RFCs 3979, 4879, 3669 and 5378 for more details)? > The above question is needed for the document write-up when sent to = publication. > =20 > Thanks > =20 > Roni Even > AVTcore co-chair > =20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From pabuhler@cisco.com Fri Jun 29 00:45:28 2012 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 07C2521F86B7 for ; Fri, 29 Jun 2012 00:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 S8UMR8ISXL4u for ; Fri, 29 Jun 2012 00:45:27 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2610E21F86B4 for ; Fri, 29 Jun 2012 00:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pabuhler@cisco.com; l=1398; q=dns/txt; s=iport; t=1340955927; x=1342165527; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=CNaVx/JPRN1le6hOGmCyWBUmQLNFrlrWunGFrlTsQCg=; b=f5TgC2CCK+9Ahs7kR0YfNnFUAYrSEGjLdf0nptlsjHt99VLGhMxsfRfe M1wv810OsxTrfAZmMWisrzZZPjZRadb7sjlEaePd1gab5Jb2cuMQZ6VVr 9fI5lKmAW6KlyQtZj1VhlP8dKW9HSi5DDM7HKQQOXhvwgUR9PqZqYG9M+ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANNc7U+tJV2b/2dsb2JhbABFtkmBB4IaAQQSASc/EgEqFEImAQQODRqHaQuYUaBikGFgA5FThHGNC4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="97208008" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 29 Jun 2012 07:45:11 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5T7jBLa013652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Jun 2012 07:45:11 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.25]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0298.004; Fri, 29 Jun 2012 02:45:10 -0500 From: "Pascal Buhler (pabuhler)" To: Magnus Westerlund Thread-Topic: comment on draft-westerlund-avtext-rtcp-sdes-srcname Thread-Index: Ac1VyxsKVUarKPrxSCOaeJCjD+Dlyw== Date: Fri, 29 Jun 2012 07:43:26 +0000 Message-ID: <7EC1BF197B21C747868126E92F8A7D62D8BE@xmb-aln-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.82.227] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19004.004 x-tm-as-result: No--33.142000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 29 Jun 2012 10:01:57 -0700 Cc: "Pascal Buhler \(pabuhler\)" , "avt@ietf.org" Subject: [AVTCORE] comment on draft-westerlund-avtext-rtcp-sdes-srcname 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: Fri, 29 Jun 2012 07:45:28 -0000 One of the problems mentioned in the draft, that is the case when receiving= the RTP streams before the SEDS has arrived is something that needs to be = addressed. The option of including the mapping in the SDP is not always app= ropriate due to devices like an RTP Translator in the middle. Therefore I w= as wondering if you have considered including a definition of a RTP header = extension (http://tools.ietf.org/html/rfc5285) to include the SRCNAME in th= e RTP stream. Yes it is potentially a lot of bits wasted but it is up to th= e sender to decide the size of the SRCNAME so that can mitigate it somewhat= . Also it may not be required in every packet just packets that make sense = for example only in the beginning of a stream, at key points in the stream = or else periodically. When using the SRCNAME to correlate two or more separ= ate encodings of the same source it is important as a receiver that when fi= rst receiving one encoding and then switching to receive a second encoding = to make this correlation as soon as possible. There is also mention of using this as a way correlating FEC with media. Ho= w would this work in the simulcast case where there are multiple encodings = of the same source. How to use only SRCNAME to map the FEC stream to the in= dividual media streams when all media streams have the same SRCNAME. Thanks Pascal Buhler