From nobody Tue Sep 1 05:49:50 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616751B530B; Tue, 1 Sep 2015 05:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEW-6v2npqBw; Tue, 1 Sep 2015 05:49:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB27C1B2F19; Tue, 1 Sep 2015 05:49:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150901124947.6862.19178.idtracker@ietfa.amsl.com> Date: Tue, 01 Sep 2015 05:49:47 -0700 Archived-At: Cc: payload-chairs@ietf.org, payload@ietf.org, draft-ietf-payload-rtp-h265@ietf.org Subject: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 12:49:49 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-payload-rtp-h265-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) For a 99 page detailed specification, the security considerations are tremendously brief. There are two non-boilerplate paragraphs - one says developers "MUST exercise caution" (meaning what precisely?) and the other extolls the virtues of not encrypting. For a 99 page specification of a highly non-trivial encoding scheme, I would have expected to see the results of a better analysis. Was that analysis done? That should at least include consideration of the CVEs already published relating to H.264 [1] which include 34 CVEs relating to various kinds of remote-code-execution and DoS. If the authors here are asserting that this presumably more complex codec will have few vulnerabilities, then I would welcome seeing the justification for that statement. (Note: In some cases with payload drafts, authors can fairly claim that the I-D does not describe the payload in detail and hence that the security considerations text need not be comprehensive as implementers are expected to find that elsewhere. In this case, the 99 pages strongly argues otherwise IMO - there are plenty of ways to go badly wrong implementing what is stated in this draft.) To summarise: "MUST exercise caution" is not useful, can't you translate that into actionable advice to an implementer based on experience with security issues found with this and similar codecs? [1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=h.264 (2) This is just a process nit probably. The shepherd write-up doesn't mention the Nokia IPR declaration. Were the WG also ok with that one? The write-up seems to pre-date that latest IPR declaration, which is from a company that seems to employ one of the authors. That is odd timing really so can someone explain the sequence of events and why all is well? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - General: I was puzzled as to why there is so much text that is presumably non-normative explanatory text covering what is elsewehere in (I guess) ITU documents. It seems like there is a lot, but not enough, here for an implementer. - 4.1: " The assignment of an RTP payload type for this new packet format is outside the scope of this document and will not be specified here. " Huh? That's confusing. For me at least. - p75 - why would md5 ever be most-preferred these days? Better to not say that, even in an example. Even better would be to deprecate md5 even for this non-security purpose to simplify code-audit. Or, if there is some reason why e.g. sha256 isn't suited then explaining that would also help for code-audits. From nobody Tue Sep 1 22:09:52 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D39E1B43EE; Tue, 1 Sep 2015 22:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVe3QoJmccsz; Tue, 1 Sep 2015 22:09:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1D51B43F9; Tue, 1 Sep 2015 22:09:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150902050950.30223.95513.idtracker@ietfa.amsl.com> Date: Tue, 01 Sep 2015 22:09:50 -0700 Archived-At: Cc: payload-chairs@ietf.org, payload@ietf.org, draft-ietf-payload-rtp-h265@ietf.org Subject: [payload] Barry Leiba's No Objection on draft-ietf-payload-rtp-h265-14: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 05:09:51 -0000 Barry Leiba has entered the following ballot position for draft-ietf-payload-rtp-h265-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. Section 1.1 is hugely long, and I wonder why it's necessary. Can someone really skip the HEVC reference because you've included all this? Is it really worth including all this, when people who need to know it should be getting it from the proper HEVC documents? 2. In Section 7.1, the media-type registration template has a tremendously long "optional parameters" section. I strongly suggest that you move all that text into another subsection, and refer to it in the template, like this: NEW OPTIONAL parameters: profile-space, tier-flag, profile-id, profile-compatibility- indicator, interop-constraints, and level-id. See Section of RFC XXXX for details. END IANA will keep the template and make it available, and it's not intended to have such an extended technical exposition in it. That belongs in the reference document only. From nobody Wed Sep 2 13:13:19 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0033B1B356B; Wed, 2 Sep 2015 13:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuXc5v7LafyF; Wed, 2 Sep 2015 13:13:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98CAD1A6FEF; Wed, 2 Sep 2015 13:13:16 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t82KCvDO032599 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 2 Sep 2015 15:13:08 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: payload-chairs@ietf.org, payload@ietf.org, draft-ietf-payload-rtp-h265@ietf.org Date: Wed, 02 Sep 2015 15:12:57 -0500 Message-ID: <3145A183-A9DA-47FD-A8F3-2708365D7FFD@nostrum.com> In-Reply-To: <20150901124947.6862.19178.idtracker@ietfa.amsl.com> References: <20150901124947.6862.19178.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: art-ads@ietf.org, Stephen Farrell Subject: Re: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 20:13:18 -0000 Hi, Stephen's discuss item 2 pointed out that we had a late IPR disclosure on this draft after the publication request. I am in discussions with the chairs on how to handle this. I have removed it from the agenda for the September 3 telechat. I hope to put it on a future telechat once we agree on a way forward. Thanks! Ben. On 1 Sep 2015, at 7:49, Stephen Farrell wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- [...] > > > (2) This is just a process nit probably. The shepherd > write-up doesn't mention the Nokia IPR declaration. Were > the WG also ok with that one? The write-up seems to > pre-date that latest IPR declaration, which is from a > company that seems to employ one of the authors. That is > odd timing really so can someone explain the sequence of > events and why all is well? [...] From nobody Wed Sep 2 15:52:10 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA6B1B3959; Wed, 2 Sep 2015 15:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzVY2H_Tv87B; Wed, 2 Sep 2015 15:51:58 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29871B5858; Wed, 2 Sep 2015 15:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1441234254; x=1472770254; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vNM3zfttx/+DH/YKRy5aEXBKvCxA6IJ0ONVz0c+BFBY=; b=fu41/vVoOhk3Ob0af3f/+v+BwmuYDCjEsV2Y2iuXG85lLa8UJvfh57Hf 0cSayUezaXAXBNKPUn+W9Odjk+aWBy0psJ0L4D4QufNX+/F8koFcLpuYT zHGABHSmeFYNGYaAC8UsayJ2HRjXLetXJYjuEM+jhPglPCAabuBybva36 4=; X-IronPort-AV: E=McAfee;i="5700,7163,7912"; a="136467715" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine01.qualcomm.com with ESMTP; 02 Sep 2015 15:50:54 -0700 X-IronPort-AV: E=Sophos;i="5.17,457,1437462000"; d="scan'208";a="33568326" Received: from nalasexr01d.na.qualcomm.com ([10.49.56.24]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 Sep 2015 15:50:52 -0700 Received: from NALASEXR01H.na.qualcomm.com (10.49.56.54) by NALASEXR01D.na.qualcomm.com (10.49.56.24) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 2 Sep 2015 15:50:52 -0700 Received: from NALASEXR01H.na.qualcomm.com ([10.49.56.54]) by NALASEXR01H.na.qualcomm.com ([10.49.56.54]) with mapi id 15.00.1076.010; Wed, 2 Sep 2015 15:50:52 -0700 From: "Wang, Ye-Kui" To: Ben Campbell , "payload-chairs@ietf.org" , "payload@ietf.org" , "draft-ietf-payload-rtp-h265@ietf.org" Thread-Topic: Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) Thread-Index: AQHQ5bvQ644RVKsMa0q9W3NeNKDIGZ4p1tQQ Date: Wed, 2 Sep 2015 22:50:51 +0000 Message-ID: <7716c02481654eed90dc8ff754efb7b3@NALASEXR01H.na.qualcomm.com> References: <20150901124947.6862.19178.idtracker@ietfa.amsl.com> <3145A183-A9DA-47FD-A8F3-2708365D7FFD@nostrum.com> In-Reply-To: <3145A183-A9DA-47FD-A8F3-2708365D7FFD@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.47.70.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "art-ads@ietf.org" , Stephen Farrell Subject: Re: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 22:52:04 -0000 Hi Ben, All, The authors are discussing on how to address Stephen Farrell's DISCUSS and = Barry Leiba's comments. We will send our collectively responses once they a= re ready.=20 However, for the one related to the Nokia IPR statement, per Miska Hannukse= la, the co-author who works for Nokia, the (so-called late) Nokia IPR state= ment (http://datatracker.ietf.org/ipr/2508/) re-iterates the IPR statement = that was submitted against draft-schierl-payload-rtp-h265 (https://datatrac= ker.ietf.org/ipr/1753/). Hence, the WG should have been aware of the situat= ion since 00 version of the Schierl draft. I therefore request to check whether it is possible not to delay the progre= ss of this document because of this. Thanks! BR, YK -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Wednesday, September 02, 2015 1:13 PM To: payload-chairs@ietf.org; payload@ietf.org; draft-ietf-payload-rtp-h265@= ietf.org Cc: art-ads@ietf.org; Stephen Farrell Subject: Re: Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (= with DISCUSS and COMMENT) Hi, Stephen's discuss item 2 pointed out that we had a late IPR disclosure on t= his draft after the publication request. I am in discussions with the chair= s on how to handle this. I have removed it from the agenda for the Septemb= er 3 telechat. I hope to put it on a future telechat once we agree on a way= forward. Thanks! Ben. On 1 Sep 2015, at 7:49, Stephen Farrell wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- [...] > > > (2) This is just a process nit probably. The shepherd write-up doesn't=20 > mention the Nokia IPR declaration. Were the WG also ok with that one?=20 > The write-up seems to pre-date that latest IPR declaration, which is=20 > from a company that seems to employ one of the authors. That is odd=20 > timing really so can someone explain the sequence of events and why=20 > all is well? [...] From nobody Wed Sep 2 16:36:25 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DFF1B38C9; Wed, 2 Sep 2015 16:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KXl0yQm2nzL; Wed, 2 Sep 2015 16:36:21 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A1631ACE8C; Wed, 2 Sep 2015 16:36:21 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t82Na5AS050877 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 2 Sep 2015 18:36:15 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Wang, Ye-Kui" Date: Wed, 02 Sep 2015 18:36:05 -0500 Message-ID: <605D88DA-3C79-49B2-A01C-51BAEA68AA9B@nostrum.com> In-Reply-To: <7716c02481654eed90dc8ff754efb7b3@NALASEXR01H.na.qualcomm.com> References: <20150901124947.6862.19178.idtracker@ietfa.amsl.com> <3145A183-A9DA-47FD-A8F3-2708365D7FFD@nostrum.com> <7716c02481654eed90dc8ff754efb7b3@NALASEXR01H.na.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: art-ads@ietf.org, payload-chairs@ietf.org, draft-ietf-payload-rtp-h265@ietf.org, payload@ietf.org, Stephen Farrell Subject: Re: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 23:36:23 -0000 On 2 Sep 2015, at 17:50, Wang, Ye-Kui wrote: > Hi Ben, All, > > The authors are discussing on how to address Stephen Farrell's DISCUSS > and Barry Leiba's comments. We will send our collectively responses > once they are ready. > Thanks for doing that. > However, for the one related to the Nokia IPR statement, per Miska > Hannuksela, the co-author who works for Nokia, the (so-called late) > Nokia IPR statement (http://datatracker.ietf.org/ipr/2508/) > re-iterates the IPR statement that was submitted against > draft-schierl-payload-rtp-h265 > (https://datatracker.ietf.org/ipr/1753/). Hence, the WG should have > been aware of the situation since 00 version of the Schierl draft. > > I therefore request to check whether it is possible not to delay the > progress of this document because of this. Thanks! Thanks for that information. I think that clears the authors from any blame for not making a timely disclosure. But I don't think that's sufficient to avoid a delay, for a couple of reasons. First, saying the work group "should have been aware" is not sufficient. The work group needs to agree that it is willing to progress a document with an IPR disclosure. A "should have been aware" standard makes it to easy for people to simply not notice. The second is, there's no evidence in the tracker that draft-ietf-payload-rtp-h265 was a replacement to draft-schierl-payload-rtp-h265. I don't mean to say that it's not, just that the datatracker "replaces" field does not show it. Without the replaces information, an IPR search on draft-ietf-payload-rtp-h265 does not show the disclosure for the older draft. Now, I recognize this is a silly clerical issue--but the effect is that working group participants were highly likely to miss the existence of the older disclosure when considering draft-ietf-payload-rtp-h265. It's too late to put the draft back on tomorrow's telechat in any case. But if the chairs make a working group consensus call concerning the Nokia disclosure in the next few days, and the results are to proceed, I will put it back on the earliest possible telechat agenda. Thanks! Ben. > > BR, YK > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, September 02, 2015 1:13 PM > To: payload-chairs@ietf.org; payload@ietf.org; > draft-ietf-payload-rtp-h265@ietf.org > Cc: art-ads@ietf.org; Stephen Farrell > Subject: Re: Stephen Farrell's Discuss on > draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) > > Hi, > > Stephen's discuss item 2 pointed out that we had a late IPR disclosure > on this draft after the publication request. I am in discussions with > the chairs on how to handle this. I have removed it from the agenda > for the September 3 telechat. I hope to put it on a future telechat > once we agree on a way forward. > > Thanks! > > Ben. > > On 1 Sep 2015, at 7:49, Stephen Farrell wrote: > >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- > > [...] > >> >> >> (2) This is just a process nit probably. The shepherd write-up >> doesn't >> mention the Nokia IPR declaration. Were the WG also ok with that >> one? >> The write-up seems to pre-date that latest IPR declaration, which is >> from a company that seems to employ one of the authors. That is odd >> timing really so can someone explain the sequence of events and why >> all is well? > > [...] From nobody Wed Sep 2 16:40:20 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6791B2DDF; Wed, 2 Sep 2015 16:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVdckTcZbZzV; Wed, 2 Sep 2015 16:40:17 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DA2B1ACD5A; Wed, 2 Sep 2015 16:40:17 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t82Ne3aH051172 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 2 Sep 2015 18:40:14 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Wang, Ye-Kui" Date: Wed, 02 Sep 2015 18:40:03 -0500 Message-ID: <336AA599-9E3D-450B-9F86-583836F89488@nostrum.com> In-Reply-To: <605D88DA-3C79-49B2-A01C-51BAEA68AA9B@nostrum.com> References: <20150901124947.6862.19178.idtracker@ietfa.amsl.com> <3145A183-A9DA-47FD-A8F3-2708365D7FFD@nostrum.com> <7716c02481654eed90dc8ff754efb7b3@NALASEXR01H.na.qualcomm.com> <605D88DA-3C79-49B2-A01C-51BAEA68AA9B@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: art-ads@ietf.org, payload-chairs@ietf.org, draft-ietf-payload-rtp-h265@ietf.org, payload@ietf.org, Stephen Farrell Subject: Re: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 23:40:19 -0000 On 2 Sep 2015, at 18:36, Ben Campbell wrote: > On 2 Sep 2015, at 17:50, Wang, Ye-Kui wrote: > >> Hi Ben, All, >> >> The authors are discussing on how to address Stephen Farrell's >> DISCUSS and Barry Leiba's comments. We will send our collectively >> responses once they are ready. >> > > Thanks for doing that. > >> However, for the one related to the Nokia IPR statement, per Miska >> Hannuksela, the co-author who works for Nokia, the (so-called late) >> Nokia IPR statement (http://datatracker.ietf.org/ipr/2508/) >> re-iterates the IPR statement that was submitted against >> draft-schierl-payload-rtp-h265 >> (https://datatracker.ietf.org/ipr/1753/). Hence, the WG should have >> been aware of the situation since 00 version of the Schierl draft. >> >> I therefore request to check whether it is possible not to delay the >> progress of this document because of this. Thanks! > > Thanks for that information. I think that clears the authors from any > blame for not making a timely disclosure. > > But I don't think that's sufficient to avoid a delay, for a couple of > reasons. First, saying the work group "should have been aware" is not > sufficient. The work group needs to agree that it is willing to > progress a document with an IPR disclosure. A "should have been aware" > standard makes it to easy for people to simply not notice. > > The second is, there's no evidence in the tracker that > draft-ietf-payload-rtp-h265 was a replacement to > draft-schierl-payload-rtp-h265. I don't mean to say that it's not, > just that the datatracker "replaces" field does not show it. Without > the replaces information, an IPR search on draft-ietf-payload-rtp-h265 > does not show the disclosure for the older draft. Now, I recognize > this is a silly clerical issue--but the effect is that working group > participants were highly likely to miss the existence of the older > disclosure when considering draft-ietf-payload-rtp-h265. > > It's too late to put the draft back on tomorrow's telechat in any > case. But if the chairs make a working group consensus call concerning > the Nokia disclosure in the next few days, and the results are to > proceed, I will put it back on the earliest possible telechat agenda. Oops, I meant to add "or point me to where the working group explicitly discussed the disclosure with respect to draft-ietf-payload-rtp-h265". Ben. > > Thanks! > > Ben. > > >> >> BR, YK >> >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Wednesday, September 02, 2015 1:13 PM >> To: payload-chairs@ietf.org; payload@ietf.org; >> draft-ietf-payload-rtp-h265@ietf.org >> Cc: art-ads@ietf.org; Stephen Farrell >> Subject: Re: Stephen Farrell's Discuss on >> draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) >> >> Hi, >> >> Stephen's discuss item 2 pointed out that we had a late IPR >> disclosure on this draft after the publication request. I am in >> discussions with the chairs on how to handle this. I have removed it >> from the agenda for the September 3 telechat. I hope to put it on a >> future telechat once we agree on a way forward. >> >> Thanks! >> >> Ben. >> >> On 1 Sep 2015, at 7:49, Stephen Farrell wrote: >> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >> >> [...] >> >>> >>> >>> (2) This is just a process nit probably. The shepherd write-up >>> doesn't >>> mention the Nokia IPR declaration. Were the WG also ok with that >>> one? >>> The write-up seems to pre-date that latest IPR declaration, which is >>> from a company that seems to employ one of the authors. That is odd >>> timing really so can someone explain the sequence of events and why >>> all is well? >> >> [...] From nobody Wed Sep 2 18:06:18 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0979B1AD059; Wed, 2 Sep 2015 18:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jqa9pHvKBtOx; Wed, 2 Sep 2015 18:06:15 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E47F11ACEF1; Wed, 2 Sep 2015 18:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1441242374; x=1472778374; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AgIzzHaAP8W3JbJunFPvpMZQAeKbnj4rCEBpvo7AWUs=; b=SFzDEFMIxNT5UsorvaSD8JTFnvLzyjrceGNend4oNu4S9CfIVqyztqb5 W16TIf7mbT8KA4JxFFcTvsn/ya+oOr3CJuDR3ZKujm3U+oj2HmwTLBaIe n4ZKD6TfhjiTC/PZmdxiFufoQQeRGHmqmdUqlDwBdWdbw37YVG2nnNiQt M=; X-IronPort-AV: E=McAfee;i="5700,7163,7912"; a="97120098" Received: from ironmsg04-lv.qualcomm.com ([10.47.202.184]) by sabertooth02.qualcomm.com with ESMTP; 02 Sep 2015 18:06:14 -0700 X-IronPort-AV: E=Sophos;i="5.17,458,1437462000"; d="scan'208";a="27532934" Received: from nalasexr01g.na.qualcomm.com ([10.49.56.53]) by ironmsg04-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 Sep 2015 18:06:13 -0700 Received: from NALASEXR01H.na.qualcomm.com (10.49.56.54) by NALASEXR01G.na.qualcomm.com (10.49.56.53) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 2 Sep 2015 18:06:13 -0700 Received: from NALASEXR01H.na.qualcomm.com ([10.49.56.54]) by NALASEXR01H.na.qualcomm.com ([10.49.56.54]) with mapi id 15.00.1076.010; Wed, 2 Sep 2015 18:06:13 -0700 From: "Wang, Ye-Kui" To: Ben Campbell Thread-Topic: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) Thread-Index: AQHQ5bvQ644RVKsMa0q9W3NeNKDIGZ4p1tQQgACDUoCAAAEcgP//oQaA Date: Thu, 3 Sep 2015 01:06:13 +0000 Message-ID: <1d19d4f1d918410eb0335997999a7e13@NALASEXR01H.na.qualcomm.com> References: <20150901124947.6862.19178.idtracker@ietfa.amsl.com> <3145A183-A9DA-47FD-A8F3-2708365D7FFD@nostrum.com> <7716c02481654eed90dc8ff754efb7b3@NALASEXR01H.na.qualcomm.com> <605D88DA-3C79-49B2-A01C-51BAEA68AA9B@nostrum.com> <336AA599-9E3D-450B-9F86-583836F89488@nostrum.com> In-Reply-To: <336AA599-9E3D-450B-9F86-583836F89488@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.47.70.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "art-ads@ietf.org" , "payload-chairs@ietf.org" , "payload@ietf.org" , "draft-ietf-payload-rtp-h265@ietf.org" , Stephen Farrell Subject: Re: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 01:06:17 -0000 Thanks for the clarifications! Reminded by your comments below, I further checked and noticed that the Qua= lcomm IPR declaration (https://datatracker.ietf.org/ipr/2118/) that was mad= e on the individual draft was not included in the list of IPR declarations = during the last calls too. My search did not indicate other IPR declaration= s possibly not (fully) mentioned during last calls. WG chairs, please take this into account too when addressing Ben's request = below. BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Ben Campbell Sent: Wednesday, September 02, 2015 4:40 PM To: Wang, Ye-Kui Cc: art-ads@ietf.org; payload-chairs@ietf.org; draft-ietf-payload-rtp-h265@= ietf.org; payload@ietf.org; Stephen Farrell Subject: Re: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-= h265-14: (with DISCUSS and COMMENT) On 2 Sep 2015, at 18:36, Ben Campbell wrote: > On 2 Sep 2015, at 17:50, Wang, Ye-Kui wrote: > >> Hi Ben, All, >> >> The authors are discussing on how to address Stephen Farrell's=20 >> DISCUSS and Barry Leiba's comments. We will send our collectively=20 >> responses once they are ready. >> > > Thanks for doing that. > >> However, for the one related to the Nokia IPR statement, per Miska=20 >> Hannuksela, the co-author who works for Nokia, the (so-called late)=20 >> Nokia IPR statement (http://datatracker.ietf.org/ipr/2508/) >> re-iterates the IPR statement that was submitted against >> draft-schierl-payload-rtp-h265 >> (https://datatracker.ietf.org/ipr/1753/). Hence, the WG should have=20 >> been aware of the situation since 00 version of the Schierl draft. >> >> I therefore request to check whether it is possible not to delay the=20 >> progress of this document because of this. Thanks! > > Thanks for that information. I think that clears the authors from any=20 > blame for not making a timely disclosure. > > But I don't think that's sufficient to avoid a delay, for a couple of=20 > reasons. First, saying the work group "should have been aware" is not=20 > sufficient. The work group needs to agree that it is willing to=20 > progress a document with an IPR disclosure. A "should have been aware" > standard makes it to easy for people to simply not notice. > > The second is, there's no evidence in the tracker that > draft-ietf-payload-rtp-h265 was a replacement to=20 > draft-schierl-payload-rtp-h265. I don't mean to say that it's not,=20 > just that the datatracker "replaces" field does not show it. Without=20 > the replaces information, an IPR search on draft-ietf-payload-rtp-h265=20 > does not show the disclosure for the older draft. Now, I recognize=20 > this is a silly clerical issue--but the effect is that working group=20 > participants were highly likely to miss the existence of the older=20 > disclosure when considering draft-ietf-payload-rtp-h265. > > It's too late to put the draft back on tomorrow's telechat in any=20 > case. But if the chairs make a working group consensus call concerning=20 > the Nokia disclosure in the next few days, and the results are to=20 > proceed, I will put it back on the earliest possible telechat agenda. Oops, I meant to add "or point me to where the working group explicitly dis= cussed the disclosure with respect to draft-ietf-payload-rtp-h265". Ben. > > Thanks! > > Ben. > > >> >> BR, YK >> >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Wednesday, September 02, 2015 1:13 PM >> To: payload-chairs@ietf.org; payload@ietf.org;=20 >> draft-ietf-payload-rtp-h265@ietf.org >> Cc: art-ads@ietf.org; Stephen Farrell >> Subject: Re: Stephen Farrell's Discuss on >> draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) >> >> Hi, >> >> Stephen's discuss item 2 pointed out that we had a late IPR=20 >> disclosure on this draft after the publication request. I am in=20 >> discussions with the chairs on how to handle this. I have removed it=20 >> from the agenda for the September 3 telechat. I hope to put it on a=20 >> future telechat once we agree on a way forward. >> >> Thanks! >> >> Ben. >> >> On 1 Sep 2015, at 7:49, Stephen Farrell wrote: >> >>> -------------------------------------------------------------------- >>> -- >>> DISCUSS: >>> -------------------------------------------------------------------- >>> -- >> >> [...] >> >>> >>> >>> (2) This is just a process nit probably. The shepherd write-up=20 >>> doesn't mention the Nokia IPR declaration. Were the WG also ok with=20 >>> that one? >>> The write-up seems to pre-date that latest IPR declaration, which is=20 >>> from a company that seems to employ one of the authors. That is odd=20 >>> timing really so can someone explain the sequence of events and why=20 >>> all is well? >> >> [...] _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Wed Sep 2 18:09:06 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE6E1ACEAF; Wed, 2 Sep 2015 18:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TD_oJT4bSUOP; Wed, 2 Sep 2015 18:09:04 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759771AD06B; Wed, 2 Sep 2015 18:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1441242544; x=1472778544; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=mPLDxSYd/NKhUCtUOoWQzJXGWgFhNDyM8aAJJ6uQGCc=; b=VuzLCaJogPI2xGx8x0vm0XvkHnhXGoRPOaANWzhiGocVKGKeO0VbamBC 3qgRJHGRalMR31Yr3IhS/G+fwTWppIFkrAYGL/djEqsdodQY+g/U9uZem HqVyZIXxT7ofpAibCEP0sxjt/NzW7Q65sNcaSD29t+ppJD+m+EtH9OVL9 U=; X-IronPort-AV: E=McAfee;i="5700,7163,7912"; a="97120325" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 02 Sep 2015 18:09:04 -0700 X-IronPort-AV: E=Sophos;i="5.17,457,1437462000"; d="scan'208";a="34065900" Received: from nalasexr01c.na.qualcomm.com ([10.49.56.23]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 Sep 2015 18:09:03 -0700 Received: from NALASEXR01H.na.qualcomm.com (10.49.56.54) by NALASEXR01C.na.qualcomm.com (10.49.56.23) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 2 Sep 2015 18:09:02 -0700 Received: from NALASEXR01H.na.qualcomm.com ([10.49.56.54]) by NALASEXR01H.na.qualcomm.com ([10.49.56.54]) with mapi id 15.00.1076.010; Wed, 2 Sep 2015 18:09:02 -0700 From: "Wang, Ye-Kui" To: request.allow.spoof , Ben Campbell , "art-ads@ietf.org" , "payload-chairs@ietf.org" , "draft-ietf-payload-rtp-h265@ietf.org" , "payload@ietf.org" , Stephen Farrell Thread-Topic: QUALCOMM spoof attempt detected: RE: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) Thread-Index: AQHQ5eTFXc3DKZTIjEOXdGUXJxfI4J4p/mWg Date: Thu, 3 Sep 2015 01:09:02 +0000 Message-ID: <66981664ff4d4634a6d6c8b59b28e74f@NALASEXR01H.na.qualcomm.com> References: <690491$tn0pc5@gatewaypony01.qualcomm.com> In-Reply-To: <690491$tn0pc5@gatewaypony01.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.47.70.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [payload] QUALCOMM spoof attempt detected: RE: Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 01:09:06 -0000 UGxlYXNlIHBhc3MgdGhpcyBlbWFpbCBBU0FQLCB3aGljaCBpcyBmb3IgSUVURiBzdGFuZGFyZGl6 YXRpb24uDQoNCkJSLCBZSw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcmVx dWVzdC5hbGxvdy5zcG9vZkBxdWFsY29tbS5jb20gW21haWx0bzpyZXF1ZXN0LmFsbG93LnNwb29m QHF1YWxjb21tLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwMiwgMjAxNSA2OjA3 IFBNDQpUbzogQmVuIENhbXBiZWxsOyBhcnQtYWRzQGlldGYub3JnOyBwYXlsb2FkLWNoYWlyc0Bp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1oMjY1QGlldGYub3JnOyBwYXlsb2FkQGll dGYub3JnOyBTdGVwaGVuIEZhcnJlbGwNClN1YmplY3Q6IFFVQUxDT01NIHNwb29mIGF0dGVtcHQg ZGV0ZWN0ZWQ6IFJFOiBbcGF5bG9hZF0gU3RlcGhlbiBGYXJyZWxsJ3MgRGlzY3VzcyBvbiBkcmFm dC1pZXRmLXBheWxvYWQtcnRwLWgyNjUtMTQ6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQoN ClBMRUFTRSBSRVNFTkQgVEhFIElORk9STUFUSU9OIFVTSU5HIEEgUEVSU09OQUwgRU1BSUwgQURE UkVTUy4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkFuIGVtYWlsIGhhcyBiZWVu IHNlbnQgdG8geW91IGZyb20gb3V0c2lkZSBvZiBRdWFsY29tbSwgYnV0IHRoZSDigJxGcm9t4oCd IGFkZHJlc3MgaGFzIGJlZW4gY2hhbmdlZCAoaS5lLiwgc3Bvb2ZlZCkgdG8gbWFrZSBpdCBsb29r IGxpa2UgaXQgb3JpZ2luYXRlZCBmcm9tIGluc2lkZSBRdWFsY29tbS4gU2luY2UgdGhpcyBjYW4g aW5kaWNhdGUgYSBwaGlzaGluZyBhdHRhY2sgdGhlIGVtYWlsIGhhcyBiZWVuIHF1YXJhbnRpbmVk IHRvIHByb3RlY3QgeW91Lg0KDQrigJxTcG9vZmluZ+KAnSBjYW4gYWxzbyBvY2N1ciB3aGVuIHlv dSB1c2UgeW91ciBRdWFsY29tbSBlbWFpbCBhZGRyZXNzIG9uIGV4dGVybmFsIHdlYnNpdGVzIHRv IHNlbmQgeW91cnNlbGYsIGZyaWVuZHMsIGFuZCBjb2xsZWFndWVzIGFydGljbGVzLCBkaXJlY3Rp b25zLCByZXNlcnZhdGlvbnMsIGV0Yy4gDQoNCklmIHlvdSBkbyBub3QgcmVjb2duaXplIHRoZSBl bWFpbCBvciB0aGUgZW1haWwgc2VuZGVyLCB0aGVyZSBpcyBubyBhY3Rpb24gcmVxdWlyZWQgYnkg eW91LiBUaGUgcXVhcmFudGluZWQgZW1haWwgd2lsbCBiZSBkZWxldGVkLg0KDQpJZiB0aGUgcXVh cmFudGluZWQgZW1haWwgaXMgYnVzaW5lc3MgcmVsYXRlZCwgc2ltcGx5IHJlcGx5IHRvIHRoaXMg ZW1haWwgd2l0aCBhIGp1c3RpZmljYXRpb24gZm9yIGl0cyByZWxlYXNlLg0KDQpUbyBsZWFybiBt b3JlIGFib3V0IHNwb29maW5nIGFuZCB3aHkgdGhpcyBlbWFpbCBtYXkgaGF2ZSBiZWVuIGxhYmVs ZWQgYSBzcG9vZmVkIGVtYWlsLCBwbGVhc2UgdmlzaXQgaHR0cDovL3F3aWtpLnF1YWxjb21tLmNv bS9pdC9RQ1Nwb29mLg0KDQoNClF1YXJhbnRpbmU6IGh0dHBzOi8vcXVhcmFudGluZS5xdWFsY29t bS5jb20gUmVtb3RlIEhvc3Q6IG1haWwuaWV0Zi5vcmcgU2VydmVyIElQOiA0LjMxLjE5OC40NCBF bnZlbG9wZSBTZW5kZXI6IHlla3Vpd0BxdGkucXVhbGNvbW0uY29tDQpGcm9tOiAiV2FuZywgWWUt S3VpIiA8eWVrdWl3QHF0aS5xdWFsY29tbS5jb20+DQpUbzogQmVuIENhbXBiZWxsIDxiZW5Abm9z dHJ1bS5jb20+DQpTdWJqZWN0OiBSRTogW3BheWxvYWRdIFN0ZXBoZW4gRmFycmVsbCdzIERpc2N1 c3Mgb24gZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1oMjY1LTE0OiAod2l0aCBESVNDVVNTIGFuZCBD T01NRU5UKQ0KDQoNCg== From nobody Fri Sep 4 14:08:30 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FABC1B2C71; Fri, 4 Sep 2015 14:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XD8tj0PER2kv; Fri, 4 Sep 2015 14:08:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0114.outbound.protection.outlook.com [65.55.169.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3E31B2C66; Fri, 4 Sep 2015 14:07:48 -0700 (PDT) Received: from BN3PR0701MB1265.namprd07.prod.outlook.com (10.160.118.14) by BN3PR0701MB1268.namprd07.prod.outlook.com (10.160.118.142) with Microsoft SMTP Server (TLS) id 15.1.256.15; Fri, 4 Sep 2015 21:07:45 +0000 Received: from BN3PR0701MB1265.namprd07.prod.outlook.com ([10.160.118.14]) by BN3PR0701MB1265.namprd07.prod.outlook.com ([10.160.118.14]) with mapi id 15.01.0256.013; Fri, 4 Sep 2015 21:07:45 +0000 From: Stephan Wenger To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) Thread-Index: AQHQ5LSzVyEERmgMHkCq5MbBLEfk054sbLcA Date: Fri, 4 Sep 2015 21:07:44 +0000 Message-ID: <1E1BD4D7-093D-4F44-81DE-8F9CF0F40572@stewe.org> References: <20150901124947.6862.19178.idtracker@ietfa.amsl.com> In-Reply-To: <20150901124947.6862.19178.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [24.5.177.48] x-microsoft-exchange-diagnostics: 1; BN3PR0701MB1268; 5:akhh0wp3cnCJ93slbSdXScKAAYqRGmdWLoZQMQr2A3PUmHY/EzRMR5JpucFJK/W3YuieeISWExZ5rrlxo+RugsKMXMaCVrG0baYnnmgnDguvpi5d/KdjARtsYxS/m2Q7IsSrCshpIkiYzBVzWlCkjw==; 24:+2se3YG63fDRT4IatXa1ZyBJR2nR248xJkzKM4HLz85IzabmrsKRWxx7fUgIHvZ28/h1zAJnNlVtH8uy47p3vATJXJJCGOEH4oQNozPKtAk=; 20:CaCmxeeYqc0EwkFRHSYoCLINqgFVHyJjV1S8YGmRrlKVbYxnWNZn50vuXf/3VQIjB3GPDd/A5xrFQ27jn99VjQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0701MB1268; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:BN3PR0701MB1268; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0701MB1268; x-forefront-prvs: 06891E23FB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(52604005)(199003)(24454002)(189002)(479174004)(230783001)(5004730100002)(76176999)(81156007)(5001860100001)(105586002)(122556002)(36756003)(5001770100001)(99286002)(102836002)(83716003)(46102003)(77156002)(101416001)(77096005)(50986999)(106356001)(10400500002)(4001540100001)(54356999)(33656002)(87936001)(68736005)(82746002)(5007970100001)(97736004)(5001960100002)(106116001)(86362001)(5001830100001)(19580395003)(62966003)(19580405001)(5002640100001)(92566002)(40100003)(189998001)(2900100001)(66066001)(5001920100001)(64706001)(2950100001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0701MB1268; H:BN3PR0701MB1265.namprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9F34F378952B994B8CD8F531C694707E@namprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2015 21:07:44.7143 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0701MB1268 Archived-At: Cc: "payload-chairs@ietf.org" , "payload@ietf.org" , "draft-ietf-payload-rtp-h265@ietf.org" Subject: Re: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 21:08:26 -0000 SGkgU3RlcGhlbiwgYWxsLA0KV2l0aCBhbGwgcmVzcGVjdCBkdWUsIHRoaXMgYXBwZWFycyB0byB1 cyBhdXRob3JzIGFzIG9uZSBvciB0aGUgbW9yZSBzbG9wcHkgcmV2aWV3cyBvZiB0aGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uIGFuZCBzZWN1cml0eSBmZWF0dXJlcyBvZiB0aGUgZG9j dW1lbnQuICBQbGVhc2Ugc2VlIG91ciBjb21tZW50cyBpbmxpbmUuDQpSZWdhcmRzLA0KU3RlcGhh bg0KDQoNCg0KDQoNCk9uIDkvMS8xNSwgMDU6NDksICJTdGVwaGVuIEZhcnJlbGwiIDxzdGVwaGVu LmZhcnJlbGxAY3MudGNkLmllPiB3cm90ZToNCg0KPlN0ZXBoZW4gRmFycmVsbCBoYXMgZW50ZXJl ZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj5kcmFmdC1pZXRmLXBheWxvYWQt cnRwLWgyNjUtMTQ6IERpc2N1c3MNCj4NCj5bLi4uXQ0KPg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5ESVND VVNTOg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4NCj4oMSkgRm9yIGEgOTkgcGFnZSBkZXRhaWxlZCBz cGVjaWZpY2F0aW9uLCB0aGUgc2VjdXJpdHkNCj5jb25zaWRlcmF0aW9ucyBhcmUgdHJlbWVuZG91 c2x5IGJyaWVmLiAgVGhlcmUgYXJlIHR3bw0KPm5vbi1ib2lsZXJwbGF0ZSBwYXJhZ3JhcGhzIC0g b25lIHNheXMgZGV2ZWxvcGVycyAiTVVTVA0KPmV4ZXJjaXNlIGNhdXRpb24iIChtZWFuaW5nIHdo YXQgcHJlY2lzZWx5PykgDQoNClRoZSB0aGlyZCBwYXJhZ3JhcGggc2F5cyBkZXZlbG9wZXJzIE1V U1QgdXNlIGNhdXRpb24gd2l0aCByZXNwZWN0IHRvIGEgdmVyeSBzcGVjaWZpYyBjb2RlcG9pbnQg aW4gdGhlIGNvZGVjIHNwZWMsIG5hbWVseSB0aGUgdXNlciBkYXRhIFNFSSBtZXNzYWdlcy4gIEJ1 dCBhbHNvIHBsZWFzZSBzZWUgYmVsb3cuDQoNCg0KPmFuZCB0aGUgb3RoZXINCj5leHRvbGxzIHRo ZSB2aXJ0dWVzIG9mIG5vdCBlbmNyeXB0aW5nLiANCg0KVGhlIGZvdXJ0aCBwYXJhZ3JhcGggc2lt cGx5IHN0YXRlcyB0aGF0IHRoZSBtaWRkbGVib3ggY2FsbGVkIE1BTkUgYXMgdXNlZCBpbiB0aGlz IGRvYyAoYW5kIGFzIHVzZWQgaW4gbWFueSBjdXJyZW50IHZpZGVvIGNvbmZlcmVuY2luZyBzeXN0 ZW1zKSBpcyBpbmNvbXBhdGlibGUgd2l0aCBlbmQtdG8tZW5kIGVuY3J5cHRpb24uICBUaGUgSUVU RiB0cmllcyB0byBzb2x2ZSB0aGF0IHZ1bG5lcmFiaWxpdHkgaW4gdGhlIHBlcmMgV0cuICBVbnRp bCBzdWNoIHNvbHV0aW9ucyBhcmUgd2lkZWx5IGRlcGxveWVkLCBpdOKAmXMgcHJvYmFibHkgYXBw cm9wcmlhdGUgdG8gd2FybiBwZW9wbGUgb2YgY2VydGFpbiBmZWF0dXJlcyBvZiBNQU5Fcy4NCg0K DQoNCj5Gb3IgYSA5OSBwYWdlDQo+c3BlY2lmaWNhdGlvbiBvZiBhIGhpZ2hseSBub24tdHJpdmlh bCBlbmNvZGluZyBzY2hlbWUsIEkNCj53b3VsZCBoYXZlIGV4cGVjdGVkIHRvIHNlZSB0aGUgcmVz dWx0cyBvZiBhIGJldHRlcg0KPmFuYWx5c2lzLiBXYXMgdGhhdCBhbmFseXNpcyBkb25lPyANCg0K VG8gdGhlIGV4dGVudCBhbiBhbmFseXNpcyBpcyByZXF1aXJlZCBmb3IgdGhlIFJUUCBwYXlsb2Fk IHNwZWNpZmljYXRpb24sIHRoZSBhbnN3ZXIgaXMgeWVzLCBpdCB3YXMgZG9uZTsgYW5kIG5vLCBu byB2dWxuZXJhYmlsaXRpZXMgYmV5b25kIHRob3NlIG1lbnRpb25lZCB3ZXJlIGZvdW5kLiAgV2Ug bmVpdGhlciBhbmFseXplZCB0aGUgc2VjdXJpdHkgYXNwZWN0cyBvZiBSVFAgaXRzZWxmLCBub3Ig aW4gbXVjaCBkZXRhaWwgdGhlIHNlY3VyaXR5IGFzcGVjdHMgb2YgSC4yNjUsIGFsdGhvdWdoIHdl IHBvaW50IG91dCB0aGUgb25lIHZ1bG5lcmFiaWxpdHkgdGhhdCBpcyBwZXJoYXBzIG5vdCBjb21t b25seSBrbm93biBhbmQgd2VsbCB1bmRlcnN0b29kIGluIHRoZSB0aGlyZCBwYXJhZ3JhcGggKHRo ZSBvbmUgd2l0aCB0aGUg4oCcTVVTVCBleGVyY2lzZSBjYXV0aW9u4oCdKS4NCg0KDQo+VGhhdCBz aG91bGQgYXQgbGVhc3QNCj5pbmNsdWRlIGNvbnNpZGVyYXRpb24gb2YgdGhlIENWRXMgYWxyZWFk eSBwdWJsaXNoZWQNCj5yZWxhdGluZyB0byBILjI2NCBbMV0gd2hpY2ggaW5jbHVkZSAzNCBDVkVz IHJlbGF0aW5nIHRvDQo+dmFyaW91cyBraW5kcyBvZiByZW1vdGUtY29kZS1leGVjdXRpb24gYW5k IERvUy4gDQoNCldlIHdlcmUgbm90IGF3YXJlIG9mIHRoZSBleGlzdGVuY2Ugb2YgQ1ZFcyBhbGxl Z2VkbHkgcmVsYXRlZCB0byBILjI2NCBhbmQgaXRzIHRyYW5zcG9ydCBzcGVjcy4gIFRoYW5rcyBm b3IgcG9pbnRpbmcgaXQgb3V0Lg0KDQpVcG9uIGJyaWVmIHJldmlldywgbm9uZSBvZiB0aGUgMzQg Q1ZFcyByZWxhdGUgdG8gSC4yNjQgb3ZlciBSVFAgaW4gYW55IHdheSwgc2hhcGUsIG9yIGZvcm0u DQoNCkV2ZXJ5IG9uZSByZWxhdGVzIHRvIGFuIGltcGxlbWVudGF0aW9uIHByb2JsZW0sIGFuZCBO T1QgdG8gYSBzcGVjaWZpY2F0aW9uIHByb2JsZW0uICBTb21lIG9mIHRoZW0gY2xlYXJseSBhcmUg bWlzY2hhcmFjdGVyaXplZCBieSB0aGUgc2VhcmNoIGVuZ2luZSBvciB0aGUgZmlsZXJzOyBjZXJ0 YWlubHksIHByb2JsZW1zIHdpdGggU01UUCwgUlRTUCwgZmlsZSBuYW1lIHBhcnNpbmcgZXRjLiBo YXZlIG5vdGhpbmcgdG8gZG8gd2l0aCB2aWRlbyBjb2RlY3Mgb3IgUlRQLiAgVGhleSBhcmUgaXJy ZWxldmFudCBoZXJlLiAgTWFueSBhcHBlYXIgdG8gYmUgZHVwbGljYXRlcywgb3IgYXQgbGVhc3Qg cmVwb3J0aW5nIHRoZSBzYW1lIHNvdXJjZSBvZiBhIHByb2JsZW0gbGVhZGluZyB0byBkaWZmZXJl bnQgdnVsbmVyYWJpbGl0aWVzLiAgT2YgdGhvc2UgZGlyZWN0bHkgcmVsYXRlZCB0byBjb2RlYyBp bXBsZW1lbnRhdGlvbnMsIHRoZXkgcHJldHR5IG11Y2ggYWxsIHJlZmVyIHRvIHZ1bG5lcmFiaWxp dGllcyB0aGF0IG9wZW4gd2hlbiBmZWVkaW5nIGVpdGhlciBub24tY29tcGxpYW50LCBvciBjb21w bGlhbnQgYnV0IOKAnGV2aWzigJ0gYml0c3RyZWFtcyB0byBkZWNvZGVycy4gIFRob3NlIGFyZSB0 aGUgb25seSBvbmVzIHdlIHBvc3NpYmx5IGNvdWxkIGRvIHNvbWV0aGluZyBhYm91dC4NCg0KVGhl IHNlY29uZCBwYXJhZ3JhcGggKG9uZSBvZiB0aG9zZSB5b3UgbGFiZWxsZWQgYXMg4oCcYm9pbGVy cGxhdGXigJ0pIGRlYWxzIHdpdGggZXhhY3RseSB0aG9zZSB2dWxuZXJhYmlsaXRpZXMgYW5kIHJl Y29tbWVuZHMgYSBzb2x1dGlvbi4NCg0KVGhlcmUgaXMgdmVyeSBsaXR0bGUgd2UgY2FuIHJlY29t bWVuZCBiZXlvbmQgd2hhdCBpcyBpbiB0aGUgc2Vjb25kIHBhcmFncmFwaCB0byBhIGNvZGVjIGlt cGxlbWVudGVyIHJlZ2FyZGluZyB0aGUgZGVjb2RlcuKAmXMgcmVhY3Rpb24gdG8gbm9uLWNvbXBs aWFudCBiaXRzdHJlYW1zLiAgVGhlIG9ubHkgdGhpbmcgdGhhdCBjb21lcyB0byBtaW5kIGlzIHRv IHNheSB0aGF0IGV2ZW4gaW4gY2FzZSBvZiBhcHBsaWVkIGVuZC10by1lbmQgc2VjdXJpdHkgYXR0 YWNrZXJzIG1heSBmZWVkIG5vbi1jb21wbGlhbnQgYml0c3RyZWFtcyB0byBhbiB1bmF3YXJlIHN5 c3RlbSwgYW5kIHRoYXQgc3lzdGVtIGJldHRlciBkb2VzIG5vdCBjcmFzaCBhbmQgYnVybiBvdmVy IHRob3NlIGJpdHN0cmVhbXMgYnV0IGdyYWNlZnVsbHkgZGlzY2FyZCB0aGVtIG9yIHNvbWV0aGlu Zy4gIFdpdGggcmVzcGVjdCB0byDigJxldmls4oCdIGJpdHN0cmVhbXMsIHdlIGNvdWxkIHBvaW50 IG91dCB0aGF0IHRoZSB2aWRlbyBjb2RlYyBzdGFuZGFyZGl6YXRpb24gY29tbXVuaXR5IGhhcyBs b25nIHJlY29nbml6ZWQgdGhlaXIgZXhpc3RlbmNlIChmb3IgcmVhc29ucyBjb21wbGV0ZWx5IHVu cmVsYXRlZCB0byBzZWN1cml0eSksIGFuZCBwdWJsaXNoZXMgYSBzZXQgb2YgdGVzdCDigJxldmls 4oCdIGJpdHN0cmVhbXMgZGVzaWduZWQgdG8gY2hlY2sgbWFueSBvZiB0aGUgc3RyZXNzIHBvaW50 cyBvZiBhIGRlY29kZXIgaW1wbGVtZW50YXRpb24uICBJdOKAmXMgcXVpdGUgb2J2aW91cyB0aGF0 IG1hbnkgb2YgdGhlIG9wZW4gc291cmNlIGZvbGtzIGJ1aWxkaW5nIGRlY29kZXJzLCBhcyB3ZWxs IGFzIHNvbWUgZWFybHkgY29tbWVyY2lhbCBILjI2NCBkZWNvZGVyIGltcGxlbWVudGF0aW9ucywg ZGlkIG5vdCBydW4gdGVzdHMgYWdhaW5zdCB0aG9zZSBiaXRzdHJlYW1zLS1vciByYW4gdGhlIHRl c3RzLCBrbmV3IGFib3V0IHRoZSB2dWxuZXJhYmlsaXR5LCBidXQgZGVjaWRlZCB0aGF0IHBlcmZv cm1hbmNlIGlzIG1vcmUgaW1wb3J0YW50IHRoYW4gc3RhYmlsaXR5IGFuZCBzZWN1cml0eSBhZ2Fp bnN0IHRoZW9yZXRpY2FsIHRocmVhdCBzY2VuYXJpb3MuICBXZSBjb3VsZCBwb2ludCBvdXQgdGhh dCBpdCBpcyBwcnVkZW50IGZvciBhIGRlY29kZXIgaW1wbGVtZW50ZXIgdG8gcnVuIGl0cyBpbXBs ZW1lbnRhdGlvbiBhdCBsZWFzdCBhZ2FpbnN0IHB1Ymxpc2hlZCBrbm93biDigJxldmls4oCdIGJp dHN0cmVhbXMuICBCdXQgdGhhdOKAmXMgYWxsIHdlIGNhbiBwb3NzaWJseSBkbyB3aXRoIHJlc3Bl Y3QgdG8gY29kZWMgaW1wbGVtZW50YXRpb25zLiAgDQoNCkFsbCB0aGUgc2htdWggYWJvdmUgaXMg cHJvYmFibHkgdXNlZnVsIGlucHV0IGZvciB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2Vj dGlvbiBvZiBJRVRGIHZpZGVvIGNvZGVjcyBhcyBkZXNpZ25lZCBieSBuZXR2Yy4gIFRoZXkgZG8g bm90IG5lY2Vzc2FyaWx5IGJlbG9uZyB0byBhbiBSVFAgcGF5bG9hZCBzcGVjLCBidXQgaWYgeW91 IHByZWZlciB3ZSB3aWxsIGFkZCB0aGVtIG5ldmVydGhlbGVzcy4NCg0KDQoNCj5JZiB0aGUNCj5h dXRob3JzIGhlcmUgYXJlIGFzc2VydGluZyB0aGF0IHRoaXMgcHJlc3VtYWJseSBtb3JlDQo+Y29t cGxleCBjb2RlYyB3aWxsIGhhdmUgZmV3IHZ1bG5lcmFiaWxpdGllcywgdGhlbiBJIHdvdWxkDQo+ d2VsY29tZSBzZWVpbmcgdGhlIGp1c3RpZmljYXRpb24gZm9yIHRoYXQgc3RhdGVtZW50Lg0KDQpO byBvbmUgYnV0IHVzIChpbiB0aGUgdGhpcmQgcGFyYWdyYXBoKSBoYXMgcG9pbnRlZCBvdXQgYSBz ZWN1cml0eSB2dWxuZXJhYmlsaXR5IGluIHNwZWMgc3BhY2UuICBXZSBjYW7igJl0IHJlYWxseSBj b21iYXQgc2hvZGR5IGltcGxlbWVudGF0aW9uIHByYWN0aWNlcy4NCg0KDQo+KE5vdGU6IEluIHNv bWUgY2FzZXMgd2l0aCBwYXlsb2FkIGRyYWZ0cywgYXV0aG9ycyBjYW4NCj5mYWlybHkgY2xhaW0g dGhhdCB0aGUgSS1EIGRvZXMgbm90IGRlc2NyaWJlIHRoZSBwYXlsb2FkDQo+aW4gZGV0YWlsIGFu ZCBoZW5jZSB0aGF0IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0ZXh0DQo+bmVlZCBub3Qg YmUgY29tcHJlaGVuc2l2ZSBhcyBpbXBsZW1lbnRlcnMgYXJlIGV4cGVjdGVkIHRvDQo+ZmluZCB0 aGF0IGVsc2V3aGVyZS4gSW4gdGhpcyBjYXNlLCB0aGUgOTkgcGFnZXMgc3Ryb25nbHkNCj5hcmd1 ZXMgb3RoZXJ3aXNlIElNTyAtIHRoZXJlIGFyZSBwbGVudHkgb2Ygd2F5cyB0byBnbw0KPmJhZGx5 IHdyb25nIGltcGxlbWVudGluZyB3aGF0IGlzIHN0YXRlZCBpbiB0aGlzIGRyYWZ0LikNCg0KQWdy ZWVkIGluIHByaW5jaXBsZS4gIEJ1dCB3ZSBhcmUgbm90IGF3YXJlIG9mIGFueXRoaW5nIHRoYXQg Y2FuIGdvIHdyb25nIHdpdGhpbiB0aGUgcHJvdG9jb2wgZGVzaWduZWQgaW4gdGhlIDk5IHBhZ2Vz IGJleW9uZCB3aGF0IHdlIHBvaW50ZWQgb3V0IGluIHRoZSBmb3VydGggcGFyYWdyYXBoLS1hbmQg eWVzLCB3ZSBsb29rZWQuDQoNCg0KDQo+VG8gc3VtbWFyaXNlOiAiTVVTVCBleGVyY2lzZSBjYXV0 aW9uIiBpcyBub3QgdXNlZnVsLA0KPmNhbid0IHlvdSB0cmFuc2xhdGUgdGhhdCBpbnRvIGFjdGlv bmFibGUgYWR2aWNlIHRvIGFuDQo+aW1wbGVtZW50ZXIgYmFzZWQgb24gZXhwZXJpZW5jZSB3aXRo IHNlY3VyaXR5IGlzc3Vlcw0KPmZvdW5kIHdpdGggdGhpcyBhbmQgc2ltaWxhciBjb2RlY3M/DQoN ClNvIGxldOKAmXMgbG9vayBpbiBtb3JlIGRldGFpbCBhdCB0aGUg4oCcTVVTVCBleGVyY2lzZSBj YXV0aW9u4oCdLiAgVGhlIG9mZmVuZGluZyBwYXJhZ3JhcGggcmVhZHM6DQrigJxEZWNvZGVycyBN VVNUIGV4ZXJjaXNlIGNhdXRpb24gd2l0aCByZXNwZWN0IHRvIHRoZSBoYW5kbGluZyBvZiB1c2Vy IGRhdGEgU0VJIG1lc3NhZ2VzLCBwYXJ0aWN1bGFybHkgaWYgdGhleSBjb250YWluIGFjdGl2ZSBl bGVtZW50cywgYW5kIE1VU1QgcmVzdHJpY3QgdGhlaXIgZG9tYWluIG9mIGFwcGxpY2FiaWxpdHkg dG8gdGhlIHByZXNlbnRhdGlvbiBvZiB0aGUgYml0c3RyZWFtLuKAnSANCldlIHBvaW50IG91dCBv bmUgSC4yNjQvSC4yNjUgY29kZWMgc3BlY2lmaWMgcG90ZW50aWFsIHZ1bG5lcmFiaWxpdHkgcGVy aGFwcyBub3Qgd2VsbCB1bmRlcnN0b29kIGJ5IHNvbWUgcGVvcGxlIChhcyBpdCBpcyBwcmV0dHkg ZXhvdGljKS0tdGhlIOKAnHVzZXIgZGF0YSBTdXBwbGVtZW50YXJ5IEVuaGFuY2VtZW50IEluZm9y bWF0aW9uIChTRUkpIG1lc3NhZ2XigJ0uICBWaWRlbyBjb2RlYyBpbXBsZW1lbnRlcnMtLXRoZSBt YWluIGF1ZGllbmNlIGZvciB0aGlzIHNwZWMtLWtub3cgd2hhdCBTRUkgbWVzc2FnZXMgYXJlLCBi dXQgbm90IG5lY2Vzc2FyaWx5IHRoaXMgb25lLiAgVGhlIHVzZXIgZGF0YSBTRUkgYWxsb3dzIGFu IGVuY29kZXIgdG8gZW1iZWQgaW50byB0aGUgdmlkZW8gYml0c3RyZWFtIHByZXR0eSBtdWNoIGFu eSBiaXRzdHJpbmcgdXAgdG8gYSBjZXJ0YWluIChpbiBtYW55IGNhc2VzIHF1aXRlIGxhcmdlKSBs ZW5ndGguICBNYWNoaW5lIGNvZGUsIEphdmFzY3JpcHQsIC4uLiwgYW55dGhpbmcuICBPYnZpb3Vz bHksIHRoaXMgY2FuIGJlIGRhbmdlcm91cy4gIEhvd2V2ZXIsIGl0IGlzIGFsc28gdXNlZnVsIGFu ZCB1c2VkIGluIHByYWN0aWNlIGluIHNvbWUgb2YgdG9kYXnigJlzIHN5c3RlbXMgKHRob3VnaCBu b3QgbmVjZXNzYXJpbHkgd2l0aCBhY3RpdmUgY29udGVudCkuICBJbnNvZmFyLCB3ZSBkbyBub3Qg cmVxdWlyZSBhIHJlY2VpdmVyIHRvIGRpc2NhcmQgdGhpcyBwb3RlbnRpYWxseSBkYW5nZXJvdXMg KGJ1dCBvZnRlbiBxdWl0ZSB1c2VmdWwpIGRhdGEuICBJbnN0ZWFkLCB3ZSBzYXkgdGhhdCBhIGRl Y29kZXIgbXVzdCBiZSBjYXJlZnVsIGFyb3VuZCB0aGVzZSBiaXRzLCBhbmQgcmVzdHJpY3QgdGhl aXIgdXNlIHRvIHRoZSByZW5kZXJpbmcgc3Vic3lzdGVtLiAgSWYgaW1wbGVtZW50ZWQgY29ycmVj dGx5LCB0aGUgd29yc2UgdGhhdCB3b3VsZCBoYXBwZW4gaXMgYSBtZXNzZWQgdXAgdmlkZW8gcGlj dHVyZS4NCllvdSBzdWdnZXN0IHRoYXQg4oCcTVVTVCBleGVyY2lzZSBjYXV0aW9u4oCdIGlzIG5v dCBhY3Rpb25hYmxlLCBhbmQgdXBvbiByZWZsZWN0aW9uIHdlIGFncmVlLiAgSW5mb3JtYXRpdmUg bGFuZ3VhZ2UgYXBwZWFycyB0byBiZSBtb3JlIGFwcHJvcHJpYXRlLiAgV2UgY291bGQgcmVtb3Zl IHRoZSDigJxjYXV0aW9u4oCdIGxhbmd1YWdlIGFuZCBqdXN0IHN0YXkgd2l0aCB0aGUgY2xlYXJs eSBhY3Rpb25hYmxlIG90aGVyIHJlbWVkeSwgb3Igd2UgY291bGQgc29mdGVuIHRoZSDigJxjYXV0 aW9u4oCdIGxhbmd1YWdlIHRvIHNvbWV0aGluZyBsaWtlIOKAnGRlY29kZXIgaW1wbGVtZW50ZXJz IGhhdmUgdG8gd2VpZ2h0IHRoZSBwb3RlbnRpYWwgYmVuZWZpdHMgb2YgdXNpbmcgYWN0aXZlIGNv bnRlbnQgYWdhaW5zdCB0aGVpciBkYW5nZXJzLiAgT25lIHdheSB0byBkbyBzbyBpcyB0byByZXN0 cmljdCB0aGUgZG9tYWluIG9mIGFwcGxpY2FiaWxpdHkgdG8gdGhlIHByZXNlbnRhdGlvbiBvZiB0 aGUgYml0c3RyZWFtLuKAnS4gIERvZXMgdGhpcyBhZGRyZXNzIHlvdXIgY29uY2Vybj8NCg0KDQo+ DQo+KDIpIFRoaXMgaXMganVzdCBhIHByb2Nlc3Mgbml0IHByb2JhYmx5LiBUaGUgc2hlcGhlcmQN Cj53cml0ZS11cCBkb2Vzbid0IG1lbnRpb24gdGhlIE5va2lhIElQUiBkZWNsYXJhdGlvbi4gIFdl cmUNCj50aGUgV0cgYWxzbyBvayB3aXRoIHRoYXQgb25lPyBUaGUgd3JpdGUtdXAgc2VlbXMgdG8N Cj5wcmUtZGF0ZSB0aGF0IGxhdGVzdCBJUFIgZGVjbGFyYXRpb24sIHdoaWNoIGlzIGZyb20gYQ0K PmNvbXBhbnkgdGhhdCBzZWVtcyB0byBlbXBsb3kgb25lIG9mIHRoZSBhdXRob3JzLiBUaGF0IGlz DQo+b2RkIHRpbWluZyByZWFsbHkgc28gY2FuIHNvbWVvbmUgZXhwbGFpbiB0aGUgc2VxdWVuY2Ug b2YNCj5ldmVudHMgYW5kIHdoeSBhbGwgaXMgd2VsbD8NCg0KSSB3aWxsIGxlYXZlIHRoZSBjaGFp cnMgYW5kIEJlbiB0byBzb3J0IHRoaXMgb3V0LiAgSG93ZXZlciwgSSByZW1lbWJlciBxdWl0ZSBj bGVhcmx5IHRoYXQgSSBteXNlbGYgcG9pbnRlZCBvdXQgZHVyaW5nIElFVEYgcGF5bG9hZCBzZXNz aW9ucyB0aGUgTm9raWEgSVBSIGF0IGxlYXN0IG9uY2UsIGluY2x1ZGluZyBteSB1bmRlcnN0YW5k aW5nIG9mIHRoZSBzY29wZSBvZiBwcm90ZWN0aW9uIGFuZCBpdHMgbGltaXRhdGlvbiB0byBjZXJ0 YWluIG9wdGlvbmFsIG1vZGVzIG9mIG9wZXJhdGlvbi4gIEkgZG9u4oCZdCBiZWxpZXZlIHRoYXQg dGhlc2UgZGlzY3Vzc2lvbnMgd2VyZSBtaW51dGVkLCBidXQgdGhleSBwcm9iYWJseSBjYW4gYmUg Zm91bmQgaW4gYXVkaW8gcmVjb3Jkcy4gIEluIG90aGVyIHdvcmRzLCB5ZXMsIHRoZSBOb2tpYSBJ UFIgd2FzIHJhaXNlZCBpbiB0aGUgV0csIGFuZCBpbiBhIGxldmVsIG9mIGRldGFpbCByYXRoZXIg dW5jb21tb24gZm9yIHN1Y2ggZGlzY3Vzc2lvbnMuICBSZWFsbHksIG5vIHJlZ3VsYXIgZm9sbG93 ZXIgb2YgdGhlIHBheWxvYWQgV0cgc2hvdWxkIGJlIHN1cnByaXNlZCBvZiB0aGlzLg0KDQo+DQo+ DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPkNPTU1FTlQ6DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPg0KPg0KPi0g R2VuZXJhbDogSSB3YXMgcHV6emxlZCBhcyB0byB3aHkgdGhlcmUgaXMgc28gbXVjaCB0ZXh0DQo+ dGhhdCBpcyBwcmVzdW1hYmx5IG5vbi1ub3JtYXRpdmUgZXhwbGFuYXRvcnkgdGV4dA0KPmNvdmVy aW5nIHdoYXQgaXMgZWxzZXdlaGVyZSBpbiAoSSBndWVzcykgSVRVIGRvY3VtZW50cy4NCj5JdCBz ZWVtcyBsaWtlIHRoZXJlIGlzIGEgbG90LCBidXQgbm90IGVub3VnaCwgaGVyZSBmb3IgYW4NCj5p bXBsZW1lbnRlci4NCg0KVGhlIFdHIGhlYXJkIHRoaXMgY29tbWVudCBiZWZvcmUgYW5kIGRpc2N1 c3NlZCBpdC4gIEl0IGlzIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIFdHIGNvbnNlbnN1cyB0aGF0 IHRoZSBsZXZlbCBvZiBkZXRhaWwgaXMgYWJvdXQgcmlnaHQuICBGb3IgeW91ciBpbmZvcm1hdGlv biwgdGhlIEguMjY1IHZlcnNpb24gMSBzcGVjIGlzIGFuIGV4dHJlbWVseSBkZW5zZSBkb2N1bWVu dCAobXVjaCBkZW5zZXIgdGhhbiB0aGUgcGF5bG9hZCBmb3JtYXQpIGFuZCwgc2V0IG91dCBpbiAx MCBwdC4gVGltZXMgUm9tYW4sIHNwYW5zIDMwMCBwYWdlcy4gIFdlIGNvdmVyIHRoZSBjb3JlIGNv ZGVjIG9ubHkgc3VwZXJmaWNpYWxseSwgYnV0IGRpZyBpbiBhIGJpdCBkZWVwZXIgaW4gdGhvc2Ug YXNwZWN0cyB3aGVyZSB3ZSBhZGRlZCBzaWduYWxpbmcgc3VwcG9ydCBmb3IgY2FwYWJpbGl0eSBl eGNoYW5nZSAoZm9yIGV4YW1wbGUsIHBhcmFsbGVsaXphdGlvbiB0b29scykuIA0KDQo+DQo+LSA0 LjE6ICIgVGhlIGFzc2lnbm1lbnQgb2YgYW4gUlRQIHBheWxvYWQgdHlwZSBmb3IgdGhpcw0KPm5l dyBwYWNrZXQgZm9ybWF0IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQNCj5h bmQgd2lsbCBub3QgYmUgc3BlY2lmaWVkIGhlcmUuICIgSHVoPyBUaGF0J3MgY29uZnVzaW5nLg0K PkZvciBtZSBhdCBsZWFzdC4NCg0KVGhpcyBpcyBjb21tb24gdGV4dCBhbW9uZyBtYW55IG90aGVy IFJUUCBwYXlsb2FkIGZvcm1hdHMuICBIaXN0b3JpY2FsbHksIFJUUCBwYXlsb2FkIGZvcm1hdHMg KG9yIFJUUCBwcm9maWxlcykgaGFyZC1jb2RlZCB0aGUgUlRQIHBheWxvYWQgdHlwZSBmb3IgYSBt ZWRpYSBmb3JtYXQuICBUb2RheSwgdGhlIGFzc2lnbm1lbnQgb2YgdGhlIFJUUCBwYXlsb2FkIHR5 cGUgaXMgaGFuZGxlZCBkeW5hbWljYWxseSBieSB0aGUgY2FsbCBjb250cm9sIHByb3RvY29sLCBm b3IgZXhhbXBsZSBieSBTSVAuICBJIGRvbuKAmXQgdGhpbmsgdGhhdCB0aGlzIHBhcmFncmFwaCBp cyBjb25mdXNpbmcgdG8gYW55b25lIGZhbWlsaWFyIHdpdGggUlRQLg0KDQo+DQo+LSBwNzUgLSB3 aHkgd291bGQgbWQ1IGV2ZXIgYmUgbW9zdC1wcmVmZXJyZWQgdGhlc2UgZGF5cz8NCj5CZXR0ZXIg dG8gbm90IHNheSB0aGF0LCBldmVuIGluIGFuIGV4YW1wbGUuIEV2ZW4gYmV0dGVyDQo+d291bGQg YmUgdG8gZGVwcmVjYXRlIG1kNSBldmVuIGZvciB0aGlzIG5vbi1zZWN1cml0eQ0KPnB1cnBvc2Ug dG8gc2ltcGxpZnkgY29kZS1hdWRpdC4gT3IsIGlmIHRoZXJlIGlzIHNvbWUNCj5yZWFzb24gd2h5 IGUuZy4gc2hhMjU2IGlzbid0IHN1aXRlZCB0aGVuIGV4cGxhaW5pbmcgdGhhdA0KPndvdWxkIGFs c28gaGVscCBmb3IgY29kZS1hdWRpdHMuDQoNClRoZSBjb2RlIHBvaW50IHlvdXIgY29tbWVudCBy ZWxhdGVzIHRvIGlzIGF2YWlsYWJsZSB0byBuZWdvdGlhdGUgdGhlIGNhcGFiaWxpdHkgdG8gaW5j bHVkZSBhIGNlcnRhaW4gU0VJIG1lc3NhZ2UgKG5hbWVseSB0aGUgZGVjb2RlZCBwaWN0dXJlIGhh c2ggKERQSCkgU0VJIG1lc3NhZ2UpIGludG8gdGhlIEguMjY1IGJpdHN0cmVhbS4gIFdlIGFyZSB0 aGVyZWZvcmUgcmVzdHJpY3RlZCB0byB0aGUgc3ludGF4IG9mIHRoYXQgU0VJIG1lc3NhZ2UuICBU aGUgRFBIIG9mZmVycyB0aGUgY2hvaWNlIG9mIGFuIE1ENSBjaGVja3N1bSwgYSAxNiBiaXQgQ1JD IG9yIGEgMzIgYml0IGFkZC11bnRpbCB3cmFwYXJvdW5kIGNoZWNrc3VtLiAgUGxlYXNlIHJlZmVy IHRvIHRoZSBjaXRlZCBwYXJhZ3JhcGhzIGluIEguMjY1IHRvIHRoZSBhdmFpbGFibGUgb3B0aW9u cy4gIE9mIHRoZXNlLCB3ZSByZWNvbW1lbmQgdGhlIG1vc3Qgc29waGlzdGljYXRlZCBvbmUgKGFu ZCB0aGlzIGlzIGlubGluZSB3aXRoIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gcHJhY3RpY2U7IGZv ciBleGFtcGxlLCB0aGUgSC4yNjUgcmVmZXJlbmNlIGNvZGUgaW5jbHVkZXMgRFBIcyB1c2luZyB0 aGUgTUQ1IGNoZWNrc3VtKS4NClNwZWN1bGF0aW5nIGEgYml0IHdoeSBJVFUgYW5kIElTTy9JRUMg dXNlcyB0aGVzZSAoYW5kIG5vdCBvdGhlciwgbW9yZSBzb3BoaXN0aWNhdGVkKSBjaGVja3N1bXMs IEkgZ3Vlc3MgTUQ1IHdhcyBjaG9zZW4gYXMgaXQgaXMgc3VmZmljaWVudCBmb3IgdGhlIHB1cnBv c2UuICBJbmNsdWRpbmcgdGhlIERQSCBpcyBtb3N0bHkgYSBjcnVkZSBlcnJvciBkZXRlY3Rpb24g dG9vbC4gIEl04oCZcyB1bnJlbGF0ZWQgdG8gc2VjdXJpdHkuICBJbiBhbnkgY2FzZSwgaXTigJlz IG5vdCB1cCB0byBhIFJUUCBwYXlsb2FkIGZvcm1hdCBkb2N1bWVudCB0byBxdWVzdGlvbiB0aGUg ZGVzaWduIGNob2ljZXMgbWFkZSBieSB0aGUgcGF5bG9hZCBzdGFuZGFyZGl6ZXJzLg0KDQo= From nobody Fri Sep 4 14:30:08 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C2B1B2BB9; Fri, 4 Sep 2015 14:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pollXVe6UupH; Fri, 4 Sep 2015 14:29:59 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD661B2CC1; Fri, 4 Sep 2015 14:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1441402199; x=1472938199; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LdaY1thp6PGBmGNzcOIAa3gvlOR7i/Up9jAyq7xHvn4=; b=ItKiFMWRkUY+lpwOSzhnPb2aeVvw7xfoee30kDu7/mUWJOWp9kcRhZVQ VvUeQyfJFyzsr/ItczsKxx/tspKun7AanR9gscNHpUiHTdF0h4gjxXylN MZSq9mFqy6ASIf/o3fAwRClWYlOAUnMN0wi5rR9CheZTwl1nUnNtA/2iK w=; X-IronPort-AV: E=McAfee;i="5700,7163,7914"; a="136847271" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine01.qualcomm.com with ESMTP; 04 Sep 2015 14:29:59 -0700 X-IronPort-AV: E=Sophos;i="5.17,470,1437462000"; d="scan'208";a="33587440" Received: from nalasexr01f.na.qualcomm.com ([10.49.56.52]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Sep 2015 14:29:58 -0700 Received: from NALASEXR01H.na.qualcomm.com (10.49.56.54) by NALASEXR01F.na.qualcomm.com (10.49.56.52) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 4 Sep 2015 14:29:57 -0700 Received: from NALASEXR01H.na.qualcomm.com ([10.49.56.54]) by NALASEXR01H.na.qualcomm.com ([10.49.56.54]) with mapi id 15.00.1076.010; Fri, 4 Sep 2015 14:29:57 -0700 From: "Wang, Ye-Kui" To: Barry Leiba , The IESG Thread-Topic: Barry Leiba's No Objection on draft-ietf-payload-rtp-h265-14: (with COMMENT) Thread-Index: AQHQ5T2buki+5o8CCEGPI1RAlUkXKp4s47DA Date: Fri, 4 Sep 2015 21:29:56 +0000 Message-ID: <4816a58da40947eaa58167a46c08d591@NALASEXR01H.na.qualcomm.com> References: <20150902050950.30223.95513.idtracker@ietfa.amsl.com> In-Reply-To: <20150902050950.30223.95513.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.47.70.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "payload-chairs@ietf.org" , "payload@ietf.org" , "draft-ietf-payload-rtp-h265@ietf.org" Subject: Re: [payload] Barry Leiba's No Objection on draft-ietf-payload-rtp-h265-14: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 21:30:04 -0000 SGkgQmFycnksDQoNClRoYW5rcyBhIGxvdCBmb3IgeW91ciByZXZpZXcuDQoNCk9uIHRoZSBmaXJz dCBwb2ludCAob24gdGhlIEhFVkMgb3ZlcnZpZXcpOiBXZSB0cmllZCB0byBwcm92aWRlIHNvbWUg ZWFzeS10by11bmRlcnN0YW5kIGRlc2NyaXB0aW9ucyBvZiB0aGUgSEVWQyBmZWF0dXJlcyB0aGF0 IGltcGxlbWVudGVycyBvZiB0aGlzIGRvY3VtZW50IG1heSBiZSBpbnRlcmVzdGVkLiBUaGlzIGZv bGxvd2VkIHRoZSBkb2N1bWVudCBzdHJ1Y3R1cmUgb2YgZWFybGllciB2aWRlbyBjb2RlYyBSVFAg cGF5bG9hZCBmb3JtYXQgc3VjaCBhcyBSRkMgMzk4NC82MTg0IGFuZCBSRkMgNjE5MC4gDQoNCkFz IFN0ZXBoYW4gY2xhcmlmaWVkIGluIHRoZSByZXBseSB0byBTdGVwaGVuIEZhcnJlbGwsIHdoaWNo IEkgY29weSBoZXJlOiBUaGUgV0cgaGVhcmQgdGhpcyBjb21tZW50IGJlZm9yZSBhbmQgZGlzY3Vz c2VkIGl0LiAgSXQgaXMgbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgV0cgY29uc2Vuc3VzIHRoYXQg dGhlIGxldmVsIG9mIGRldGFpbCBpcyBhYm91dCByaWdodC4gIEZvciB5b3VyIGluZm9ybWF0aW9u LCB0aGUgSC4yNjUgdmVyc2lvbiAxIHNwZWMgaXMgYW4gZXh0cmVtZWx5IGRlbnNlIGRvY3VtZW50 IChtdWNoIGRlbnNlciB0aGFuIHRoZSBwYXlsb2FkIGZvcm1hdCkgYW5kLCBzZXQgb3V0IGluIDEw IHB0LiBUaW1lcyBSb21hbiwgc3BhbnMgMzAwIHBhZ2VzLiAgV2UgY292ZXIgdGhlIGNvcmUgY29k ZWMgb25seSBzdXBlcmZpY2lhbGx5LCBidXQgZGlnIGluIGEgYml0IGRlZXBlciBpbiB0aG9zZSBh c3BlY3RzIHdoZXJlIHdlIGFkZGVkIHNpZ25hbGluZyBzdXBwb3J0IGZvciBjYXBhYmlsaXR5IGV4 Y2hhbmdlIChmb3IgZXhhbXBsZSwgcGFyYWxsZWxpemF0aW9uIHRvb2xzKS4NCg0KT24gdGhlIHNl Y29uZCBwb2ludCAob24gdGhlIG1lZGlhIHR5cGUgcGFyYW1ldGVycyBhbmQgSUFOQSByZWdpc3Ry YXRpb24pOiBUaGlzIHBvaW50IGhhcyBhbHNvIGJlZW4gZGlzY3Vzc2VkIGJ5IHRoZSBXRywgYW5k IGV4cGxpY2l0bHkgZGlzY3Vzc2VkIGF0IGEgcmVjZW50IGZhY2UtdG8tZmFjZSBJRVRGIG1lZXRp bmcsIHdpdGggdGhlIGRlY2lzaW9uIGJlaW5nIHRvIGtlZXAgaXQgYXMgaXMuDQoNCkJSLCBZSw0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQmFycnkgTGVpYmEgW21haWx0bzpi YXJyeWxlaWJhQGNvbXB1dGVyLm9yZ10gDQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDEsIDIw MTUgMTA6MTAgUE0NClRvOiBUaGUgSUVTRw0KQ2M6IHBheWxvYWQtY2hhaXJzQGlldGYub3JnOyBk cmFmdC1pZXRmLXBheWxvYWQtcnRwLWgyNjVAaWV0Zi5vcmc7IHBheWxvYWRAaWV0Zi5vcmcNClN1 YmplY3Q6IEJhcnJ5IExlaWJhJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtcGF5bG9hZC1y dHAtaDI2NS0xNDogKHdpdGggQ09NTUVOVCkNCg0KQmFycnkgTGVpYmEgaGFzIGVudGVyZWQgdGhl IGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWgy NjUtMTQ6IE5vIE9iamVjdGlvbg0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBz dWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1 ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9k dWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8v d3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KZm9yIG1v cmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4N Cg0KDQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2Fu IGJlIGZvdW5kIGhlcmU6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLXBheWxvYWQtcnRwLWgyNjUvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01NRU5UOg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQoxLiBTZWN0aW9uIDEuMSBpcyBodWdlbHkgbG9uZywgYW5kIEkgd29uZGVy IHdoeSBpdCdzIG5lY2Vzc2FyeS4gIENhbiBzb21lb25lIHJlYWxseSBza2lwIHRoZSBIRVZDIHJl ZmVyZW5jZSBiZWNhdXNlIHlvdSd2ZSBpbmNsdWRlZCBhbGwgdGhpcz8gDQpJcyBpdCByZWFsbHkg d29ydGggaW5jbHVkaW5nIGFsbCB0aGlzLCB3aGVuIHBlb3BsZSB3aG8gbmVlZCB0byBrbm93IGl0 IHNob3VsZCBiZSBnZXR0aW5nIGl0IGZyb20gdGhlIHByb3BlciBIRVZDIGRvY3VtZW50cz8NCg0K Mi4gSW4gU2VjdGlvbiA3LjEsIHRoZSBtZWRpYS10eXBlIHJlZ2lzdHJhdGlvbiB0ZW1wbGF0ZSBo YXMgYSB0cmVtZW5kb3VzbHkgbG9uZyAib3B0aW9uYWwgcGFyYW1ldGVycyIgc2VjdGlvbi4gIEkg c3Ryb25nbHkgc3VnZ2VzdCB0aGF0IHlvdSBtb3ZlIGFsbCB0aGF0IHRleHQgaW50byBhbm90aGVy IHN1YnNlY3Rpb24sIGFuZCByZWZlciB0byBpdCBpbiB0aGUgdGVtcGxhdGUsIGxpa2UgdGhpczoN Cg0KTkVXDQogICBPUFRJT05BTCBwYXJhbWV0ZXJzOg0KICAgICAgcHJvZmlsZS1zcGFjZSwgdGll ci1mbGFnLCBwcm9maWxlLWlkLCBwcm9maWxlLWNvbXBhdGliaWxpdHktDQogICAgICBpbmRpY2F0 b3IsIGludGVyb3AtY29uc3RyYWludHMsIGFuZCBsZXZlbC1pZC4gIFNlZQ0KICAgICAgU2VjdGlv biA8d2hhdGV2ZXI+IG9mIFJGQyBYWFhYIGZvciBkZXRhaWxzLg0KRU5EDQoNCklBTkEgd2lsbCBr ZWVwIHRoZSB0ZW1wbGF0ZSBhbmQgbWFrZSBpdCBhdmFpbGFibGUsIGFuZCBpdCdzIG5vdCBpbnRl bmRlZCB0byBoYXZlIHN1Y2ggYW4gZXh0ZW5kZWQgdGVjaG5pY2FsIGV4cG9zaXRpb24gaW4gaXQu ICBUaGF0IGJlbG9uZ3MgaW4gdGhlIHJlZmVyZW5jZSBkb2N1bWVudCBvbmx5Lg0KDQoNCg== From nobody Fri Sep 4 15:05:24 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FB61B31D4; Fri, 4 Sep 2015 15:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDJZW-7R-YAI; Fri, 4 Sep 2015 15:05:18 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147481B31C2; Fri, 4 Sep 2015 15:05:18 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t84M51QE052955 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 4 Sep 2015 17:05:12 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Stephan Wenger" Date: Fri, 04 Sep 2015 17:05:01 -0500 Message-ID: <9ED14454-CCCC-4132-BC8A-47F3A1C2718A@nostrum.com> In-Reply-To: <1E1BD4D7-093D-4F44-81DE-8F9CF0F40572@stewe.org> References: <20150901124947.6862.19178.idtracker@ietfa.amsl.com> <1E1BD4D7-093D-4F44-81DE-8F9CF0F40572@stewe.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-payload-rtp-h265@ietf.org, payload-chairs@ietf.org, The IESG , payload@ietf.org, Stephen Farrell Subject: Re: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 22:05:19 -0000 On 4 Sep 2015, at 16:07, Stephan Wenger wrote: >> (2) This is just a process nit probably. The shepherd >> write-up doesn't mention the Nokia IPR declaration. Were >> the WG also ok with that one? The write-up seems to >> pre-date that latest IPR declaration, which is from a >> company that seems to employ one of the authors. That is >> odd timing really so can someone explain the sequence of >> events and why all is well? > > > I will leave the chairs and Ben to sort this out. However, I remember > quite clearly that I myself pointed out during IETF payload sessions > the Nokia IPR at least once, including my understanding of the scope > of protection and its limitation to certain optional modes of > operation. I don’t believe that these discussions were minuted, but > they probably can be found in audio records. In other words, yes, the > Nokia IPR was raised in the WG, and in a level of detail rather > uncommon for such discussions. Really, no regular follower of the > payload WG should be surprised of this. There's a separate discussion of the IPR issue (and that has turned up a QualComm disclosure that was showing in the tracker for the same reason the Nokia one did not.) My personal opinion is that we need to follow a higher standard than "people should be aware/not surprised"; we really explicit WG discussion about whether it wants to progress the draft in the face of a disclosure. That being said, do you know (or can you guess) which meeting might have an audio record of the discussion? Thanks! Ben. From nobody Fri Sep 4 20:26:11 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791561AD373; Fri, 4 Sep 2015 20:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id looYg0JrY5ku; Fri, 4 Sep 2015 20:26:06 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38FC1B3B71; Fri, 4 Sep 2015 20:26:05 -0700 (PDT) Received: by vkbf67 with SMTP id f67so21019820vkb.0; Fri, 04 Sep 2015 20:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=B+PP0RRgsoRjfl/G8ZRkSugwy/2YISsNRlgXuoQmHVA=; b=TBJuVcuIiZQ3xGMiAiPBSPDlb0uIYkEmK7Fy9lYN9xXxJsPr5Ujxd2S17pMqgNaomP RnrZNcNBI4PGJMqOSyiSNl+QFPOQuAsWu0ciGkCSZuNowtdgM1GitN/RjZjjlZl9xCdi JYSpjnBetR2Ztc/bD2co4cusFmTk0WEdwcbRk7X/sXtEjXeIccslOyMMYMoLszFYjZLX h7SvvyYNOueZj4UIAtH8XZa3mvM2PhseLKHK0sVlwgd3ievBJ+s6o+G/BJbXePmbPY7J FRyorxVQtP7gWkFWYbyYU13Udk0VSnpD0rd9kuuvvmocz+7Mc/+zHc2KAkJw2l+A9Ydz MvfQ== MIME-Version: 1.0 X-Received: by 10.52.184.163 with SMTP id ev3mr9336642vdc.63.1441423564846; Fri, 04 Sep 2015 20:26:04 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Fri, 4 Sep 2015 20:26:04 -0700 (PDT) In-Reply-To: <4816a58da40947eaa58167a46c08d591@NALASEXR01H.na.qualcomm.com> References: <20150902050950.30223.95513.idtracker@ietfa.amsl.com> <4816a58da40947eaa58167a46c08d591@NALASEXR01H.na.qualcomm.com> Date: Fri, 4 Sep 2015 23:26:04 -0400 X-Google-Sender-Auth: S4QPtnY3vGc9bS_LzWSiEKRs3zg Message-ID: From: Barry Leiba To: "Wang, Ye-Kui" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "draft-ietf-payload-rtp-h265@ietf.org" , "payload-chairs@ietf.org" , The IESG , "payload@ietf.org" Subject: Re: [payload] Barry Leiba's No Objection on draft-ietf-payload-rtp-h265-14: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 03:26:07 -0000 YK, thanks for the response. I'm happy with the part about the HEVC overview -- if the working group thinks it's useful to have it, I have no further concern. On not reorganizing the registration template, I'll also step aside. I think it's the wrong decision, but if it's the working group's decision it's not for me to say otherwise. Again, thanks for considering my comments. Barry On Fri, Sep 4, 2015 at 5:29 PM, Wang, Ye-Kui wrot= e: > Hi Barry, > > Thanks a lot for your review. > > On the first point (on the HEVC overview): We tried to provide some easy-= to-understand descriptions of the HEVC features that implementers of this d= ocument may be interested. This followed the document structure of earlier = video codec RTP payload format such as RFC 3984/6184 and RFC 6190. > > As Stephan clarified in the reply to Stephen Farrell, which I copy here: = The WG heard this comment before and discussed it. It is my understanding = of the WG consensus that the level of detail is about right. For your info= rmation, the H.265 version 1 spec is an extremely dense document (much dens= er than the payload format) and, set out in 10 pt. Times Roman, spans 300 p= ages. We cover the core codec only superficially, but dig in a bit deeper = in those aspects where we added signaling support for capability exchange (= for example, parallelization tools). > > On the second point (on the media type parameters and IANA registration):= This point has also been discussed by the WG, and explicitly discussed at = a recent face-to-face IETF meeting, with the decision being to keep it as i= s. > > BR, YK > > -----Original Message----- > From: Barry Leiba [mailto:barryleiba@computer.org] > Sent: Tuesday, September 01, 2015 10:10 PM > To: The IESG > Cc: payload-chairs@ietf.org; draft-ietf-payload-rtp-h265@ietf.org; payloa= d@ietf.org > Subject: Barry Leiba's No Objection on draft-ietf-payload-rtp-h265-14: (w= ith COMMENT) > > Barry Leiba has entered the following ballot position for > draft-ietf-payload-rtp-h265-14: No Objection > > When responding, please keep the subject line intact and reply to all ema= il addresses included in the To and CC lines. (Feel free to cut this introd= uctory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1. Section 1.1 is hugely long, and I wonder why it's necessary. Can some= one really skip the HEVC reference because you've included all this? > Is it really worth including all this, when people who need to know it sh= ould be getting it from the proper HEVC documents? > > 2. In Section 7.1, the media-type registration template has a tremendousl= y long "optional parameters" section. I strongly suggest that you move all= that text into another subsection, and refer to it in the template, like t= his: > > NEW > OPTIONAL parameters: > profile-space, tier-flag, profile-id, profile-compatibility- > indicator, interop-constraints, and level-id. See > Section of RFC XXXX for details. > END > > IANA will keep the template and make it available, and it's not intended = to have such an extended technical exposition in it. That belongs in the r= eference document only. > > From nobody Sat Sep 5 14:18:06 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86AA11B4113; Sat, 5 Sep 2015 14:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1XHMYgoHiuQ; Sat, 5 Sep 2015 14:18:03 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD4F1B3D5B; Sat, 5 Sep 2015 14:18:03 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so48246731wic.1; Sat, 05 Sep 2015 14:18:02 -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:content-transfer-encoding:thread-index :content-language; bh=6dV2PUusLu6UJclmxcbABkgOrpsUsEd1yjakjxPWtws=; b=bXdpDyC2vSq/j6F9vpMxMSTdlL5rGaCIoqva+MNM80ksdkY3MkYrhcOED1JL5m1pgL SZ8hF1e68CHt7bStfOJMImQg93pRmUjSB1CNi7N29qgbAXlBtAA22IoUfOJb0NAgqYDn ufQCvSXBA9SyhXKnji7kM/4dkLRjNOfQeCBQigmTPbrjTvDXPrmsCgrcGWo/pNkTwVvC OVrslWvACUop5DV5b7IRiYZrP7wiha1arkfzSJ9jSXcN9yWfZyXf5o7V9jPgg3Fz9ZHO KSgLHKUxCL4Xhqh1FUacnyKqEsE6PdzoPr7g/IeiHShxcd7TOMnKXdj1Tytubh4qie44 pFZQ== X-Received: by 10.194.121.232 with SMTP id ln8mr22204384wjb.76.1441487881883; Sat, 05 Sep 2015 14:18:01 -0700 (PDT) Received: from RoniPC (bzq-79-180-110-132.red.bezeqint.net. [79.180.110.132]) by smtp.gmail.com with ESMTPSA id jy2sm11971198wid.8.2015.09.05.14.17.59 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 05 Sep 2015 14:18:00 -0700 (PDT) From: "Roni Even" To: "'Ben Campbell'" , "'Stephan Wenger'" References: <20150901124947.6862.19178.idtracker@ietfa.amsl.com> <1E1BD4D7-093D-4F44-81DE-8F9CF0F40572@stewe.org> <9ED14454-CCCC-4132-BC8A-47F3A1C2718A@nostrum.com> In-Reply-To: <9ED14454-CCCC-4132-BC8A-47F3A1C2718A@nostrum.com> Date: Sun, 6 Sep 2015 00:17:55 +0300 Message-ID: <01cc01d0e820$560c5270$0224f750$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIgtR7ivCdockvcLA6j1+jQ8ZKWZwH2uDJOAevUkU+db8FsUA== Content-Language: he Archived-At: Cc: payload@ietf.org, payload-chairs@ietf.org, 'The IESG' , draft-ietf-payload-rtp-h265@ietf.org, 'Stephen Farrell' Subject: Re: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 21:18:05 -0000 Hi Stephan, I am trying to remember but this Nokia IPR was submitted December 2014 = after we sent the document to publication and we had two meetings since = (Dallas and Prague). Was it discussed before on earlier version of the = document? Roni -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Ben = Campbell Sent: Saturday, September 05, 2015 1:05 AM To: Stephan Wenger Cc: draft-ietf-payload-rtp-h265@ietf.org; payload-chairs@ietf.org; The = IESG; payload@ietf.org; Stephen Farrell Subject: Re: [payload] Stephen Farrell's Discuss on = draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) On 4 Sep 2015, at 16:07, Stephan Wenger wrote: >> (2) This is just a process nit probably. The shepherd write-up=20 >> doesn't mention the Nokia IPR declaration. Were the WG also ok with=20 >> that one? The write-up seems to pre-date that latest IPR declaration, = >> which is from a company that seems to employ one of the authors. That = >> is odd timing really so can someone explain the sequence of events=20 >> and why all is well? > > > I will leave the chairs and Ben to sort this out. However, I remember = > quite clearly that I myself pointed out during IETF payload sessions=20 > the Nokia IPR at least once, including my understanding of the scope=20 > of protection and its limitation to certain optional modes of=20 > operation. I don=E2=80=99t believe that these discussions were = minuted, but=20 > they probably can be found in audio records. In other words, yes, the = > Nokia IPR was raised in the WG, and in a level of detail rather=20 > uncommon for such discussions. Really, no regular follower of the=20 > payload WG should be surprised of this. There's a separate discussion of the IPR issue (and that has turned up a = QualComm disclosure that was showing in the tracker for the same reason = the Nokia one did not.) My personal opinion is that we need to follow a = higher standard than "people should be aware/not surprised"; we really = explicit WG discussion about whether it wants to progress the draft in = the face of a disclosure. That being said, do you know (or can you guess) which meeting might have = an audio record of the discussion? Thanks! Ben. _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Sat Sep 5 20:31:17 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47D21B48AF; Sat, 5 Sep 2015 20:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDAVx100uLg4; Sat, 5 Sep 2015 20:31:13 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0772.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:772]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8B01B39B7; Sat, 5 Sep 2015 20:31:12 -0700 (PDT) Received: from BN3PR0701MB1265.namprd07.prod.outlook.com (10.160.118.14) by BN3PR0701MB1268.namprd07.prod.outlook.com (10.160.118.142) with Microsoft SMTP Server (TLS) id 15.1.256.15; Sun, 6 Sep 2015 03:31:08 +0000 Received: from BN3PR0701MB1265.namprd07.prod.outlook.com ([10.160.118.14]) by BN3PR0701MB1265.namprd07.prod.outlook.com ([10.160.118.14]) with mapi id 15.01.0256.013; Sun, 6 Sep 2015 03:31:08 +0000 From: Stephan Wenger To: Roni Even , 'Ben Campbell' Thread-Topic: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) Thread-Index: AQHQ5LSzVyEERmgMHkCq5MbBLEfk054sbLcAgACFXICAAYUsgP//8uuA Date: Sun, 6 Sep 2015 03:31:07 +0000 Message-ID: <950B06A2-11B2-43CF-B9F3-CAD52BB4A58F@stewe.org> References: <20150901124947.6862.19178.idtracker@ietfa.amsl.com> <1E1BD4D7-093D-4F44-81DE-8F9CF0F40572@stewe.org> <9ED14454-CCCC-4132-BC8A-47F3A1C2718A@nostrum.com> <01cc01d0e820$560c5270$0224f750$@gmail.com> In-Reply-To: <01cc01d0e820$560c5270$0224f750$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:646:c302:9122:4175:a0fb:f95b:5105] x-microsoft-exchange-diagnostics: 1; BN3PR0701MB1268; 5:eSi8JNd8fRjKLO4BybIH0yxgCWgZUqVpjuISIq0r17RS7HIyjnhj0afhbCeJ7VgOmuuP7977BErQWz4YsUiNk463QbVkCc4+0UPsJFzgT6iaCCXmYuajmJbABxsk94OXFX6dyNFe8kaFk3ISlLV3+w==; 24:Cj1xiSqcPs5ROSgTN7EGu0tx5T3L6vCZXNorh4BrJyx8AQp03ntOmKZ/9IEWKlYlewPmtpRUrFlLTzTiA8Yux56OGzxh7b2VpF5k8yj6wm4=; 20:TPGk+FX/ESBZxTDpfSzGbFpOCi7LYpVezu9Nbl99yBo3iuxut6U3Py4bj90y9Lc1Metv/AwQcGBdxI/U15B7ng== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0701MB1268; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:BN3PR0701MB1268; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0701MB1268; x-forefront-prvs: 06911FE69E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(479174004)(189002)(24454002)(199003)(62966003)(19580395003)(99286002)(5001830100001)(83716003)(82746002)(15975445007)(40100003)(92566002)(19580405001)(106116001)(5002640100001)(5001960100002)(5007970100001)(97736004)(189998001)(2900100001)(64706001)(2950100001)(36756003)(5004730100002)(5001770100001)(46102003)(102836002)(76176999)(81156007)(86362001)(5001860100001)(230783001)(105586002)(122556002)(106356001)(50986999)(68736005)(87936001)(54356999)(33656002)(4001540100001)(77156002)(101416001)(93886004)(10400500002)(77096005)(3826002)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0701MB1268; H:BN3PR0701MB1265.namprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <0C1083774241A84289F44DECCC2D48BA@namprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2015 03:31:07.6736 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0701MB1268 Archived-At: Cc: "payload@ietf.org" , "payload-chairs@ietf.org" , 'The IESG' , "draft-ietf-payload-rtp-h265@ietf.org" , 'Stephen Farrell' Subject: Re: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2015 03:31:15 -0000 DQoNCg0KDQpPbiA5LzUvMTUsIDE0OjE3LCAiUm9uaSBFdmVuIiA8cm9uLmV2ZW4udGx2QGdtYWls LmNvbT4gd3JvdGU6DQoNCj5IaSBTdGVwaGFuLA0KPkkgYW0gdHJ5aW5nIHRvIHJlbWVtYmVyIGJ1 dCB0aGlzIE5va2lhIElQUiB3YXMgc3VibWl0dGVkIERlY2VtYmVyIDIwMTQgYWZ0ZXIgd2Ugc2Vu dCB0aGUgZG9jdW1lbnQgdG8gcHVibGljYXRpb24gYW5kIHdlIGhhZCB0d28gbWVldGluZ3Mgc2lu Y2UgKERhbGxhcyBhbmQgUHJhZ3VlKS4gV2FzIGl0IGRpc2N1c3NlZCBiZWZvcmUgb24gZWFybGll ciB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudD8NCg0KVGhlIE5va2lhIElQUiB3YXMgZGlzY3Vzc2Vk IHdheSBlYXJsaWVyLCBwcm9iYWJseSBhcm91bmQgdGhlIEJlcmxpbiBJRVRGLiAgTGV0IG1lIGRp ZyBhIGJpdC4uLg0KU3RlcGhhbg0KDQo+Um9uaQ0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+RnJvbTogcGF5bG9hZCBbbWFpbHRvOnBheWxvYWQtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEJlbiBDYW1wYmVsbA0KPlNlbnQ6IFNhdHVyZGF5LCBTZXB0ZW1iZXIgMDUsIDIw MTUgMTowNSBBTQ0KPlRvOiBTdGVwaGFuIFdlbmdlcg0KPkNjOiBkcmFmdC1pZXRmLXBheWxvYWQt cnRwLWgyNjVAaWV0Zi5vcmc7IHBheWxvYWQtY2hhaXJzQGlldGYub3JnOyBUaGUgSUVTRzsgcGF5 bG9hZEBpZXRmLm9yZzsgU3RlcGhlbiBGYXJyZWxsDQo+U3ViamVjdDogUmU6IFtwYXlsb2FkXSBT dGVwaGVuIEZhcnJlbGwncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtaDI2NS0x NDogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4NCj5PbiA0IFNlcCAyMDE1LCBhdCAxNjow NywgU3RlcGhhbiBXZW5nZXIgd3JvdGU6DQo+DQo+Pj4gKDIpIFRoaXMgaXMganVzdCBhIHByb2Nl c3Mgbml0IHByb2JhYmx5LiBUaGUgc2hlcGhlcmQgd3JpdGUtdXAgDQo+Pj4gZG9lc24ndCBtZW50 aW9uIHRoZSBOb2tpYSBJUFIgZGVjbGFyYXRpb24uICBXZXJlIHRoZSBXRyBhbHNvIG9rIHdpdGgg DQo+Pj4gdGhhdCBvbmU/IFRoZSB3cml0ZS11cCBzZWVtcyB0byBwcmUtZGF0ZSB0aGF0IGxhdGVz dCBJUFIgZGVjbGFyYXRpb24sIA0KPj4+IHdoaWNoIGlzIGZyb20gYSBjb21wYW55IHRoYXQgc2Vl bXMgdG8gZW1wbG95IG9uZSBvZiB0aGUgYXV0aG9ycy4gVGhhdCANCj4+PiBpcyBvZGQgdGltaW5n IHJlYWxseSBzbyBjYW4gc29tZW9uZSBleHBsYWluIHRoZSBzZXF1ZW5jZSBvZiBldmVudHMgDQo+ Pj4gYW5kIHdoeSBhbGwgaXMgd2VsbD8NCj4+DQo+Pg0KPj4gSSB3aWxsIGxlYXZlIHRoZSBjaGFp cnMgYW5kIEJlbiB0byBzb3J0IHRoaXMgb3V0LiAgSG93ZXZlciwgSSByZW1lbWJlciANCj4+IHF1 aXRlIGNsZWFybHkgdGhhdCBJIG15c2VsZiBwb2ludGVkIG91dCBkdXJpbmcgSUVURiBwYXlsb2Fk IHNlc3Npb25zIA0KPj4gdGhlIE5va2lhIElQUiBhdCBsZWFzdCBvbmNlLCBpbmNsdWRpbmcgbXkg dW5kZXJzdGFuZGluZyBvZiB0aGUgc2NvcGUgDQo+PiBvZiBwcm90ZWN0aW9uIGFuZCBpdHMgbGlt aXRhdGlvbiB0byBjZXJ0YWluIG9wdGlvbmFsIG1vZGVzIG9mIA0KPj4gb3BlcmF0aW9uLiAgSSBk b27igJl0IGJlbGlldmUgdGhhdCB0aGVzZSBkaXNjdXNzaW9ucyB3ZXJlIG1pbnV0ZWQsIGJ1dCAN Cj4+IHRoZXkgcHJvYmFibHkgY2FuIGJlIGZvdW5kIGluIGF1ZGlvIHJlY29yZHMuICBJbiBvdGhl ciB3b3JkcywgeWVzLCB0aGUgDQo+PiBOb2tpYSBJUFIgd2FzIHJhaXNlZCBpbiB0aGUgV0csIGFu ZCBpbiBhIGxldmVsIG9mIGRldGFpbCByYXRoZXIgDQo+PiB1bmNvbW1vbiBmb3Igc3VjaCBkaXNj dXNzaW9ucy4gIFJlYWxseSwgbm8gcmVndWxhciBmb2xsb3dlciBvZiB0aGUgDQo+PiBwYXlsb2Fk IFdHIHNob3VsZCBiZSBzdXJwcmlzZWQgb2YgdGhpcy4NCj4NCj5UaGVyZSdzIGEgc2VwYXJhdGUg ZGlzY3Vzc2lvbiBvZiB0aGUgSVBSIGlzc3VlIChhbmQgdGhhdCBoYXMgdHVybmVkIHVwIGEgUXVh bENvbW0gZGlzY2xvc3VyZSB0aGF0IHdhcyBzaG93aW5nIGluIHRoZSB0cmFja2VyIGZvciB0aGUg c2FtZSByZWFzb24gdGhlIE5va2lhIG9uZSBkaWQgbm90LikgTXkgcGVyc29uYWwgb3BpbmlvbiBp cyB0aGF0IHdlIG5lZWQgdG8gZm9sbG93IGEgaGlnaGVyIHN0YW5kYXJkIHRoYW4gInBlb3BsZSBz aG91bGQgYmUgYXdhcmUvbm90IHN1cnByaXNlZCI7IHdlIHJlYWxseSBleHBsaWNpdCBXRyBkaXNj dXNzaW9uIGFib3V0IHdoZXRoZXIgaXQgd2FudHMgdG8gcHJvZ3Jlc3MgdGhlIGRyYWZ0IGluIHRo ZSBmYWNlIG9mIGEgZGlzY2xvc3VyZS4NCj4NCj5UaGF0IGJlaW5nIHNhaWQsIGRvIHlvdSBrbm93 IChvciBjYW4geW91IGd1ZXNzKSB3aGljaCBtZWV0aW5nIG1pZ2h0IGhhdmUgYW4gYXVkaW8gcmVj b3JkIG9mIHRoZSBkaXNjdXNzaW9uPw0KPg0KPlRoYW5rcyENCj4NCj5CZW4uDQo+DQo+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5wYXlsb2FkIG1haWxp bmcgbGlzdA0KPnBheWxvYWRAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3BheWxvYWQNCj4NCg== From nobody Sat Sep 5 21:18:50 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6601B30CC for ; Sat, 5 Sep 2015 21:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksfc_LRwKNkP for ; Sat, 5 Sep 2015 21:18:46 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE38E1B3059 for ; Sat, 5 Sep 2015 21:18:46 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t864IOjN020454 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 5 Sep 2015 23:18:34 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Roni Even" Date: Sat, 05 Sep 2015 23:18:23 -0500 Message-ID: <0529D407-785A-42ED-9828-32D25827FECF@nostrum.com> In-Reply-To: <950B06A2-11B2-43CF-B9F3-CAD52BB4A58F@stewe.org> References: <20150901124947.6862.19178.idtracker@ietfa.amsl.com> <1E1BD4D7-093D-4F44-81DE-8F9CF0F40572@stewe.org> <9ED14454-CCCC-4132-BC8A-47F3A1C2718A@nostrum.com> <01cc01d0e820$560c5270$0224f750$@gmail.com> <950B06A2-11B2-43CF-B9F3-CAD52BB4A58F@stewe.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-payload-rtp-h265@ietf.org, payload-chairs@ietf.org, payload@ietf.org, The IESG , Stephen Farrell Subject: Re: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2015 04:18:48 -0000 Hi Roni, It may have been buried in tall the emails, but my understanding is the Dec 2014 Nokia disclosure was an update of an earlier disclosure made against the pre-wg version of the draft. But because the tracker does not show payload-rtp-h265 as replacing the older version, it didn't apply the earlier discloser to the working group draft. Ben. On 5 Sep 2015, at 22:31, Stephan Wenger wrote: > On 9/5/15, 14:17, "Roni Even" wrote: > >> Hi Stephan, >> I am trying to remember but this Nokia IPR was submitted December >> 2014 after we sent the document to publication and we had two >> meetings since (Dallas and Prague). Was it discussed before on >> earlier version of the document? > > The Nokia IPR was discussed way earlier, probably around the Berlin > IETF. Let me dig a bit... > Stephan > >> Roni >> >> -----Original Message----- >> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Ben >> Campbell >> Sent: Saturday, September 05, 2015 1:05 AM >> To: Stephan Wenger >> Cc: draft-ietf-payload-rtp-h265@ietf.org; payload-chairs@ietf.org; >> The IESG; payload@ietf.org; Stephen Farrell >> Subject: Re: [payload] Stephen Farrell's Discuss on >> draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) >> >> On 4 Sep 2015, at 16:07, Stephan Wenger wrote: >> >>>> (2) This is just a process nit probably. The shepherd write-up >>>> doesn't mention the Nokia IPR declaration. Were the WG also ok >>>> with >>>> that one? The write-up seems to pre-date that latest IPR >>>> declaration, >>>> which is from a company that seems to employ one of the authors. >>>> That >>>> is odd timing really so can someone explain the sequence of events >>>> and why all is well? >>> >>> >>> I will leave the chairs and Ben to sort this out. However, I >>> remember >>> quite clearly that I myself pointed out during IETF payload sessions >>> the Nokia IPR at least once, including my understanding of the scope >>> of protection and its limitation to certain optional modes of >>> operation. I don’t believe that these discussions were minuted, >>> but >>> they probably can be found in audio records. In other words, yes, >>> the >>> Nokia IPR was raised in the WG, and in a level of detail rather >>> uncommon for such discussions. Really, no regular follower of the >>> payload WG should be surprised of this. >> >> There's a separate discussion of the IPR issue (and that has turned >> up a QualComm disclosure that was showing in the tracker for the same >> reason the Nokia one did not.) My personal opinion is that we need to >> follow a higher standard than "people should be aware/not surprised"; >> we really explicit WG discussion about whether it wants to progress >> the draft in the face of a disclosure. >> >> That being said, do you know (or can you guess) which meeting might >> have an audio record of the discussion? >> >> Thanks! >> >> Ben. >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >> From nobody Tue Sep 8 06:33:02 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D78B1A88E1; Tue, 8 Sep 2015 06:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kw1zpukwFb6h; Tue, 8 Sep 2015 06:32:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310491B3C68; Tue, 8 Sep 2015 06:32:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E5F41BE83; Tue, 8 Sep 2015 14:32:48 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWubC4wgC3Td; Tue, 8 Sep 2015 14:32:48 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AB1C8BE59; Tue, 8 Sep 2015 14:32:48 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1441719168; bh=PZmQutMiH+/j+chR/kSNkYo66tma5DEgloxNIKbXp1g=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=hHpd3eHv/nHIU56UtEU4cKfU+K134xIk+uq5j6bIppGdqmhZaCxNoo0cMgban51PF BqGKZWjbbwELWHBvjFGRA42Slb0qQIcsldeN4Oj5+tO0lEgXsjdnSpblyQ1czn+eno LelvZ2I8riJwiNOe1GrNA3V6oGTBHW6XiudSiVl0= To: Stephan Wenger , The IESG References: <20150901124947.6862.19178.idtracker@ietfa.amsl.com> <1E1BD4D7-093D-4F44-81DE-8F9CF0F40572@stewe.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 Message-ID: <55EEE380.5020604@cs.tcd.ie> Date: Tue, 8 Sep 2015 14:32:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1E1BD4D7-093D-4F44-81DE-8F9CF0F40572@stewe.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "payload-chairs@ietf.org" , "payload@ietf.org" , "draft-ietf-payload-rtp-h265@ietf.org" Subject: Re: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-h265-14: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 13:32:58 -0000 Hiya, Sorry for the slow response ... On 04/09/15 22:07, Stephan Wenger wrote: > Hi Stephen, all, With all respect due, this appears to us authors as > one or the more sloppy reviews of the security consideration section > and security features of the document. Hmm. I can see how a "please show your work, because I'm not sure it's been done" discuss may be irritating at this point in what was probably a very long and already irritating process, but I don't agree that sloppy is at all a good descriptor for that. Anyway, some more below, but maybe we should think about how best to resolve the discuss and not get too wrapped around blow-by-blow responses which could easily happen here and not get us too far. Could be that a call is the way to do that. If so, I'm happy to do one. (And do feel free to not respond to everything below.) > Please see our comments > inline. Regards, Stephan > > > > > > On 9/1/15, 05:49, "Stephen Farrell" > wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-payload-rtp-h265-14: Discuss >> >> [...] >> >> ---------------------------------------------------------------------- >> >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> >> (1) For a 99 page detailed specification, the security >> considerations are tremendously brief. There are two >> non-boilerplate paragraphs - one says developers "MUST exercise >> caution" (meaning what precisely?) > > The third paragraph says developers MUST use caution with respect to > a very specific codepoint in the codec spec, namely the user data SEI > messages. But also please see below. "MUST use caution" isn't really a sensible use of a 2119 MUST. It needs to be something a developer can interpret, and it's not clear to me that that is. (And also more below too.) > > >> and the other extolls the virtues of not encrypting. > > The fourth paragraph simply states that the middlebox called MANE as > used in this doc (and as used in many current video conferencing > systems) is incompatible with end-to-end encryption. The IETF tries > to solve that vulnerability in the perc WG. Until such solutions are > widely deployed, it’s probably appropriate to warn people of certain > features of MANEs. > > > >> For a 99 page specification of a highly non-trivial encoding >> scheme, I would have expected to see the results of a better >> analysis. Was that analysis done? > > To the extent an analysis is required for the RTP payload > specification, the answer is yes, it was done; and no, no > vulnerabilities beyond those mentioned were found. Great. Can you send me a pointer to where that was described on the wg list or in a meeting? > We neither > analyzed the security aspects of RTP itself, nor in much detail the > security aspects of H.265, That's the norm in the payload WG. However, this draft does not fit that normal pattern since it has such a large amount of new text. For example, I searched for the first substantive " must " in the document. That's on page 9, para 2 and says "must contain an end of bitstream NAL unit and..." (various other conditions) but that doesn't say what an implementer should do if those conditions are not met. And I could see crafted packets not meeting those conditions and perhaps leading to remote code execution. The subsequent paragraphs also generate security concerns, dealing as they do with random access - messing with whatever pointers are used for that could cause lots of implementation errors/crashes. Now, are either of those things new (in this draft) and not described in the ITU documents? I don't know is the answer, but presumably you do. I'd guess they probably are in the ITU specs in this case, but equally I might guess that the ITU specs also don't contain guidance as to how to handle failure cases. That lack of guidance does I think increase the liklihood of implementation error. And you're adding some guidance here, so I don't get why that guidance doesn't extend to security considerations. > although we point out the one > vulnerability that is perhaps not commonly known and well understood > in the third paragraph (the one with the “MUST exercise caution”). > > >> That should at least include consideration of the CVEs already >> published relating to H.264 [1] which include 34 CVEs relating to >> various kinds of remote-code-execution and DoS. > > We were not aware of the existence of CVEs allegedly related to H.264 Allegedly? This isn't a court, it's a DISCUSSion:-) > and its transport specs. Thanks for pointing it out. > > Upon brief review, none of the 34 CVEs relate to H.264 over RTP in > any way, shape, or form. So you'd not previously searched for related CVEs? That is one good way to find out what implementers have done wrong in the past and so are likely to do again. Not the only way, but one. > > Every one relates to an implementation problem, and NOT to a > specification problem. Some of them clearly are mischaracterized by > the search engine or the filers; certainly, problems with SMTP, RTSP, > file name parsing etc. have nothing to do with video codecs or RTP. > They are irrelevant here. Many appear to be duplicates, or at least > reporting the same source of a problem leading to different > vulnerabilities. Of those directly related to codec implementations, > they pretty much all refer to vulnerabilities that open when feeding > either non-compliant, or compliant but “evil” bitstreams to decoders. > Those are the only ones we possibly could do something about. That's fair. And what guidance is offered for that last kind of case? (Other than the one discussed below.) > > The second paragraph (one of those you labelled as “boilerplate”) > deals with exactly those vulnerabilities and recommends a solution. To an extent. DAO and data integrity do help yes, but RTP will often be used without those. At that point the implementer needs guidance. And the issue is less with "overload" and more with allowing remote code execution. > > There is very little we can recommend beyond what is in the second > paragraph to a codec implementer regarding the decoder’s reaction to > non-compliant bitstreams. The only thing that comes to mind is to > say that even in case of applied end-to-end security attackers may > feed non-compliant bitstreams to an unaware system, and that system > better does not crash and burn over those bitstreams but gracefully > discard them or something. With respect to “evil” bitstreams, we > could point out that the video codec standardization community has > long recognized their existence (for reasons completely unrelated to > security), and publishes a set of test “evil” bitstreams designed to I didn't know that. Do those include cases that might lead to remote code execution? (Just wondering.) Have you pointers? > check many of the stress points of a decoder implementation. It’s > quite obvious that many of the open source folks building decoders, > as well as some early commercial H.264 decoder implementations, did > not run tests against those bitstreams--or ran the tests, knew about > the vulnerability, but decided that performance is more important > than stability and security against theoretical threat scenarios. We > could point out that it is prudent for a decoder implementer to run > its implementation at least against published known “evil” > bitstreams. I think that would be worthwhile, esp. if as you say it could have helped avoid some implementation errors. > But that’s all we can possibly do with respect to codec > implementations. That's where I'm not sure and where the 99 pages aspect comes in. You've described so much about this, I can't see why you omit the security considerations. > > All the shmuh above is probably useful input for the security > considerations section of IETF video codecs as designed by netvc. > They do not necessarily belong to an RTP payload spec, but if you > prefer we will add them nevertheless. > > > >> If the authors here are asserting that this presumably more complex >> codec will have few vulnerabilities, then I would welcome seeing >> the justification for that statement. > > No one but us (in the third paragraph) has pointed out a security > vulnerability in spec space. We can’t really combat shoddy > implementation practices. Combat is the wrong word. What's needed here is to document the security considerations of the specification text that's in this document. > > >> (Note: In some cases with payload drafts, authors can fairly claim >> that the I-D does not describe the payload in detail and hence that >> the security considerations text need not be comprehensive as >> implementers are expected to find that elsewhere. In this case, the >> 99 pages strongly argues otherwise IMO - there are plenty of ways >> to go badly wrong implementing what is stated in this draft.) > > Agreed in principle. But we are not aware of anything that can go > wrong within the protocol designed in the 99 pages beyond what we > pointed out in the fourth paragraph--and yes, we looked. Again, if you could point out where that was described to the WG that'd be great. > > > >> To summarise: "MUST exercise caution" is not useful, can't you >> translate that into actionable advice to an implementer based on >> experience with security issues found with this and similar >> codecs? > > So let’s look in more detail at the “MUST exercise caution”. The > offending paragraph reads: “Decoders MUST exercise caution with > respect to the handling of user data SEI messages, particularly if > they contain active elements, and MUST restrict their domain of > applicability to the presentation of the bitstream.” We point out one > H.264/H.265 codec specific potential vulnerability perhaps not well > understood by some people (as it is pretty exotic)--the “user data > Supplementary Enhancement Information (SEI) message”. Video codec > implementers--the main audience for this spec--know what SEI messages > are, but not necessarily this one. The user data SEI allows an > encoder to embed into the video bitstream pretty much any bitstring > up to a certain (in many cases quite large) length. Machine code, > Javascript, ..., anything. Obviously, this can be dangerous. > However, it is also useful and used in practice in some of today’s > systems (though not necessarily with active content). Insofar, we do > not require a receiver to discard this potentially dangerous (but > often quite useful) data. Instead, we say that a decoder must be > careful around these bits, and restrict their use to the rendering > subsystem. If implemented correctly, the worse that would happen is > a messed up video picture. You suggest that “MUST exercise caution” > is not actionable, and upon reflection we agree. Informative > language appears to be more appropriate. We could remove the > “caution” language and just stay with the clearly actionable other > remedy, or we could soften the “caution” language to something like > “decoder implementers have to weight the potential benefits of using > active content against their dangers. One way to do so is to > restrict the domain of applicability to the presentation of the > bitstream.”. Does this address your concern? I'm not sure the latter (alone) is much better tbh. What's needed is something that a developer who is implementing the rest of this draft can easily comprehend. Explaining the trade-offs is a fine thing to do, but in the above, many implementers won't weigh costs/benefits, they'll just write their code;-) So explaining the attack (in a sentence), mentioning the trade offs (in a sentence) and then saying something like "to be safe do X." In this case, I'm not sure "restrict domain..." is a correct X, since active content could e.g. take over the entire screen in which case there is no really safe way to handle it unless you first check the specific content. I'd say that disabling all active content is really the only safe instruction that can be given, if that is practical (I'm not sure if it is). > > >> >> (2) This is just a process nit probably. The shepherd write-up >> doesn't mention the Nokia IPR declaration. Were the WG also ok >> with that one? The write-up seems to pre-date that latest IPR >> declaration, which is from a company that seems to employ one of >> the authors. That is odd timing really so can someone explain the >> sequence of events and why all is well? > > I will leave the chairs and Ben to sort this out. However, I > remember quite clearly that I myself pointed out during IETF payload > sessions the Nokia IPR at least once, including my understanding of > the scope of protection and its limitation to certain optional modes > of operation. I don’t believe that these discussions were minuted, > but they probably can be found in audio records. In other words, > yes, the Nokia IPR was raised in the WG, and in a level of detail > rather uncommon for such discussions. Really, no regular follower of > the payload WG should be surprised of this. Ben is handling this separately. > >> >> >> ---------------------------------------------------------------------- >> >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> >> >> - General: I was puzzled as to why there is so much text >> that is presumably non-normative explanatory text covering what is >> elsewehere in (I guess) ITU documents. It seems like there is a >> lot, but not enough, here for an implementer. > > The WG heard this comment before and discussed it. Cool - can you also send me a point to that discussion so I can understand it better? (It still puzzles me tbh.) > It is my > understanding of the WG consensus that the level of detail is about > right. For your information, the H.265 version 1 spec is an > extremely dense document (much denser than the payload format) and, > set out in 10 pt. Times Roman, spans 300 pages. We cover the core > codec only superficially, but dig in a bit deeper in those aspects > where we added signaling support for capability exchange (for > example, parallelization tools). > >> >> - 4.1: " The assignment of an RTP payload type for this new packet >> format is outside the scope of this document and will not be >> specified here. " Huh? That's confusing. For me at least. > > This is common text among many other RTP payload formats. > Historically, RTP payload formats (or RTP profiles) hard-coded the > RTP payload type for a media format. Today, the assignment of the > RTP payload type is handled dynamically by the call control protocol, > for example by SIP. I don’t think that this paragraph is confusing > to anyone familiar with RTP. > >> >> - p75 - why would md5 ever be most-preferred these days? Better to >> not say that, even in an example. Even better would be to deprecate >> md5 even for this non-security purpose to simplify code-audit. Or, >> if there is some reason why e.g. sha256 isn't suited then >> explaining that would also help for code-audits. > > The code point your comment relates to is available to negotiate the > capability to include a certain SEI message (namely the decoded > picture hash (DPH) SEI message) into the H.265 bitstream. We are > therefore restricted to the syntax of that SEI message. The DPH > offers the choice of an MD5 checksum, a 16 bit CRC or a 32 bit > add-until wraparound checksum. Please refer to the cited paragraphs > in H.265 to the available options. Of these, we recommend the most > sophisticated one (and this is inline with current implementation > practice; for example, the H.265 reference code includes DPHs using > the MD5 checksum). Speculating a bit why ITU and ISO/IEC uses these > (and not other, more sophisticated) checksums, I guess MD5 was chosen > as it is sufficient for the purpose. Including the DPH is mostly a > crude error detection tool. It’s unrelated to security. In any > case, it’s not up to a RTP payload format document to question the > design choices made by the payload standardizers. Bummer that they've kept md5. FWIW, in such cases I'd choose crc32 myself. Using md5 causes problems (i.e. cost) for folks doing security code audits when the auditor has to have it explained/documented why there is any md5 code still being used and why that isn't security sensitive and how one ensures no security sensitive bits of code re-use that md5 implementation. (It's generally a bad plan to continue to use broken crypto for anything I think. But people do do it.) Cheers, S. > From nobody Wed Sep 9 13:55:40 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC66F1B4551; Wed, 9 Sep 2015 13:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3A3jZS5J6vp8; Wed, 9 Sep 2015 13:55:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C69481B454B; Wed, 9 Sep 2015 13:55:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150909205537.27043.48137.idtracker@ietfa.amsl.com> Date: Wed, 09 Sep 2015 13:55:37 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-vp8-17.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 20:55:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for VP8 Video Authors : Patrik Westin Henrik F Lundin Michael Glover Justin Uberti Frank Galligan Filename : draft-ietf-payload-vp8-17.txt Pages : 28 Date : 2015-09-09 Abstract: This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-payload-vp8-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp8-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 9 14:02:04 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5471ACDEA for ; Wed, 9 Sep 2015 14:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.407 X-Spam-Level: X-Spam-Status: No, score=-0.407 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmAo1yWqFDzY for ; Wed, 9 Sep 2015 14:02:01 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83941B2AA0 for ; Wed, 9 Sep 2015 14:02:00 -0700 (PDT) Received: by iofh134 with SMTP id h134so37734359iof.0 for ; Wed, 09 Sep 2015 14:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=IIrwQ6rxl5KmYBspB6WR+W+cSSng1Q1XbCNs/IgTm2c=; b=ejXn7W4tJKgCID94Wv5Z91wQQljcpZ1XSEdpRIyftKjM2wQR/dgJbB0MDoMPYQznLf S5Kb2kWuzE1HJ69ONzqsNRi/hYS2hcydDmod2z0bkZ09JtAiUrpRQeFbfb01X/MI/0mp epVkjbDUuYw+6SY54z2fhstaQ/hGMfimOmIicYRbZOa3ztwhexeFm9REPveHioB/pMJN O/wQjHeNayfh7W0gpGzwM2+XJ62JtcZpcRMBawXQFBC3/8wWBWajwDwYiVE6MIRgI2Vz 9yM6kqeNVkEb3HtBth8Cm/zK7JMSrjhTpKnxNkOwWJ9Neds2HYq2S6+Kzb7RWuNQKJI6 mfZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=IIrwQ6rxl5KmYBspB6WR+W+cSSng1Q1XbCNs/IgTm2c=; b=W4KgmyoAtM0DwQD6YBIkq64pRTLmdll5hZnGp97NjBv3ctxVwOv/jQf9XlXFH54fX1 kyHAOZwohGPXI7MglRLmmEDY9B1/VerzgJy3qN5U6H4+9OQAoejghpun2Tmo+1UE1GTB EWKGSANg1zYKQicAABD1uC4M7FvIwk5QF03hksdZO+Te2nAeejyXrStiiSCQEA3WtgVu MQCgKw2+Fi5VeHS0xTM3PDNCVbwHyBAI/jiT1o52ZJ5raGIS5gQxxt+1ykPADhyAg260 iKRJyCtXne9yadAY+bqnK6tExq/Qq1jaKHnchOta40cHrXhuxAnSFhajHkIXIgwA/qqa 8JuA== X-Gm-Message-State: ALoCoQmTTd9GSfmYXRo13G6fSwrvVNK5KYlk9H/sa/yzbJgiTY27NaXN92h82X69qvHO2Nm35AOo MIME-Version: 1.0 X-Received: by 10.107.160.143 with SMTP id j137mr30004818ioe.13.1441832520084; Wed, 09 Sep 2015 14:02:00 -0700 (PDT) Received: by 10.64.162.165 with HTTP; Wed, 9 Sep 2015 14:01:59 -0700 (PDT) Date: Wed, 9 Sep 2015 23:01:59 +0200 Message-ID: From: Henrik Lundin To: "payload@ietf.org" , "draft-ietf-payload-vp8@tools.ietf.org" , Ben Campbell Content-Type: multipart/alternative; boundary=001a114043d62fb423051f56cb31 Archived-At: Subject: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 21:02:02 -0000 --001a114043d62fb423051f56cb31 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Payload WG: After the second Last Call, we have done a review of the document against the comments that were pointed out to us on this document and on previous versions of the document. We have made no technical changes to the document, but have added a number of grammar updates and clarifications. Some of the important clarifications are as follows: We have added a number of definitions that were previously only in referenced documents. With regard to indexes that start at random numbers and wrap, we=E2=80=99ve switched to consistently using =E2=80=9Cwrap=E2=80=9D. The text about not s= tarting at zero is just to say that starting at zero is not required; there is no security benefit that we know of. We have removed some material that was repeated from RFC 6386; it was clear that the explanation copied up was not sufficient for understanding, and we found it better to refer to the more complete specification in RFC 6386 for that material. The definition of the Y-bit and structure of temporal layers has been strengthened. SLI and RPSI have been explained with more links back to RFC 4585. We note that the text about pathological data noted in the sec-dir review comes from the RTP HOWTO - we have updated the copied text to be consistent with version -14 of the RTP HOWTO draft. The Gen-ART review suggested to add a definition of temporal base layer. We added an informal reference to an article on scalable video coding, and think that the general definitions of scalability found therein apply to this draft too. The Gen-ART review also suggested that the VER field in the VP8 Payload Header should be validated by the depacketizer. We disagree with this, and argue that the VER field should be verified by the VP8 decoder. For minor updates, please refer to the diff at https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-vp8-17. With this update, we believe the document is ready for publication. Sincerely, /Henrik --=20 Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41 --001a114043d62fb423051f56cb31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Payload WG:

After the second Last Call, we have don= e a review of the document against the comments that were pointed out to us= on this document and on previous versions of the document.

We have = made no technical changes to the document, but have added a number of gramm= ar updates and clarifications. Some of the important clarifications are as = follows:

We have added a number of definitions that were previously = only in referenced documents.

With regard to indexes that start at r= andom numbers and wrap, we=E2=80=99ve switched to consistently using =E2=80= =9Cwrap=E2=80=9D. The text about not starting at zero is just to say that s= tarting at zero is not required; there is no security benefit that we know = of.

We have removed some material that was repeated from RFC 6386; i= t was clear that the explanation copied up was not sufficient for understan= ding, and we found it better to refer to the more complete specification in= RFC 6386 for that material.

The definition of the Y-bit and structu= re of temporal layers has been strengthened.

SLI and RPSI have been = explained with more links back to RFC 4585.

We note that the text ab= out pathological data noted in the sec-dir review comes from the RTP HOWTO = - we have updated the copied text to be consistent with version -14 of the = RTP HOWTO draft.

The Gen-ART review suggested to add a definition of= temporal base layer. We added an informal reference to an article on scala= ble video coding, and think that the general definitions of scalability fou= nd therein apply to this draft too.

The Gen-ART review also suggeste= d that the VER field in the VP8 Payload Header should be validated by the d= epacketizer. We disagree with this, and argue that the VER field should be = verified by the VP8 decoder.

For minor updates, please refer to the = diff at https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-vp8-17.
With this update, we believe the document is ready for publication.
Sincerely,
/Henrik

--
Henrik Lundin=C2=A0|=C2=A0WebRTC Software Eng=C2=A0|=C2=A0hlundin@google.com=C2=A0|=C2=A0+46 70 646 13 41
<= font face=3D"'Times New Roman'" size=3D"3">
--001a114043d62fb423051f56cb31-- From nobody Wed Sep 9 15:12:40 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7221B401C; Wed, 9 Sep 2015 15:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9F1kdY115-s; Wed, 9 Sep 2015 15:12:38 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65061B3C80; Wed, 9 Sep 2015 15:12:38 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t89MCG0r006459 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 9 Sep 2015 17:12:27 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: payload@ietf.org, payload-chairs@ietf.org Date: Wed, 09 Sep 2015 17:12:16 -0500 Message-ID: <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-payload-vp8@tools.ietf.org, payload@ietf.org Subject: Re: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 22:12:39 -0000 On 9 Sep 2015, at 16:01, Henrik Lundin wrote: > We have made no technical changes to the document, but have added a > number of grammar updates and clarifications. Some of the important > clarifications are as follows: Payload participants: Please note that there are in fact changes to 2119 language in this version. I won't quibble about whether or not those count as "technical" changes, but please take a moment to review them. If people object to any of them please say so asap , as this draft will likely be on the agenda for the IESG telechat next week. Thanks! Ben. From nobody Wed Sep 9 15:18:18 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCEC1B2BE1 for ; Wed, 9 Sep 2015 15:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7jhvsf9OqPA for ; Wed, 9 Sep 2015 15:18:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3878F1B2ABD for ; Wed, 9 Sep 2015 15:18:16 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t89MI1HZ006905 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 9 Sep 2015 17:18:11 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Henrik Lundin" Date: Wed, 09 Sep 2015 17:18:00 -0500 Message-ID: <61C9844E-0751-4319-9F06-8303EA9B1318@nostrum.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-payload-vp8@tools.ietf.org, payload@ietf.org Subject: Re: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 22:18:17 -0000 Hi, Thanks for submitting this. I plan to put it on the agenda for the September 17 telechat. In the interim, I had a few comments when you sent me the diff a while back that I think still apply (copied below for reference) I sent a separate email to the payload list point out the changes to 2119 language. Thanks! Ben. > > This revision makes changes to normative language. Please make sure > those changes are mentioned on the working group list with enough time > for anyone to object prior to final approval. (This doesn't > necessarily need a WGLC unless the chairs wish it, but people should > at least see the changes and have a few days to complain if they don't > like it.) > > > -- section 3, Payload Type: "... the VP8 RTP payload profile MUST > assign a dynamic payload type number ..." > > If I read correctly, Colin Perkins objected to this change. Did you > consider his objection? > > -- 4.2 > > I didn't see anything addressing Elwyn's Gen-ART review question > about: “What happens if L=1 but both T=0 and K=0 so that there is no > TID value present? Or indeed if T=0 but K=1 so that the TID field is > there but 'MUST be ignored by the receiver' (definition of TID > field)?” Did I miss something? > On 9 Sep 2015, at 16:01, Henrik Lundin wrote: > Payload WG: > > After the second Last Call, we have done a review of the document > against > the comments that were pointed out to us on this document and on > previous > versions of the document. > > We have made no technical changes to the document, but have added a > number > of grammar updates and clarifications. Some of the important > clarifications > are as follows: > > We have added a number of definitions that were previously only in > referenced documents. > > With regard to indexes that start at random numbers and wrap, we’ve > switched to consistently using “wrap”. The text about not starting > at zero > is just to say that starting at zero is not required; there is no > security > benefit that we know of. > > We have removed some material that was repeated from RFC 6386; it was > clear > that the explanation copied up was not sufficient for understanding, > and we > found it better to refer to the more complete specification in RFC > 6386 for > that material. > > The definition of the Y-bit and structure of temporal layers has been > strengthened. > > SLI and RPSI have been explained with more links back to RFC 4585. > > We note that the text about pathological data noted in the sec-dir > review > comes from the RTP HOWTO - we have updated the copied text to be > consistent > with version -14 of the RTP HOWTO draft. > > The Gen-ART review suggested to add a definition of temporal base > layer. We > added an informal reference to an article on scalable video coding, > and > think that the general definitions of scalability found therein apply > to > this draft too. > > The Gen-ART review also suggested that the VER field in the VP8 > Payload > Header should be validated by the depacketizer. We disagree with this, > and > argue that the VER field should be verified by the VP8 decoder. > > For minor updates, please refer to the diff at > https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp8-17. > > With this update, we believe the document is ready for publication. > > Sincerely, > /Henrik > > -- > Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 > 13 41 From nobody Thu Sep 10 03:28:37 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813D61B646D; Thu, 10 Sep 2015 03:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEEsunDotOHc; Thu, 10 Sep 2015 03:28:33 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E87D1B62B2; Thu, 10 Sep 2015 03:28:33 -0700 (PDT) Received: from [130.209.247.112] (port=53062 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1ZZz5h-0005x4-Rx; Thu, 10 Sep 2015 11:28:31 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Colin Perkins In-Reply-To: <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> Date: Thu, 10 Sep 2015 11:28:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> References: <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.2104) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: payload-chairs@ietf.org, draft-ietf-payload-vp8@tools.ietf.org, payload@ietf.org Subject: Re: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 10:28:35 -0000 > On 9 Sep 2015, at 23:12, Ben Campbell wrote: >=20 > On 9 Sep 2015, at 16:01, Henrik Lundin wrote: >=20 >> We have made no technical changes to the document, but have added a = number of grammar updates and clarifications. Some of the important = clarifications are as follows: >=20 > Payload participants: Please note that there are in fact changes to = 2119 language in this version. I won't quibble about whether or not = those count as "technical" changes, but please take a moment to review = them. If people object to any of them please say so asap , as this draft = will likely be on the agenda for the IESG telechat next week. The new text about the Payload Type in Section 4.1 says: Payload type (PT): In line with the policy in Section 3 of [RFC3551], applications using the VP8 RTP payload profile MUST assign a dynamic payload type number to be used in each RTP session and provide a mechanism to indicate the mapping. See Section 6.2 for the mechanism to be used with the Session Description Protocol (SDP) [RFC4566]. This would be okay, except that RTP profiles that don=E2=80=99t derive = from RFC 3551 could be defined. A better wording might be: Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, or if that is not done, then a payload type in the dynamic range SHALL be chosen by means of an out-of-band signaling protocol. See Section 6.2 for the mechanism to be used with the Session Description Protocol (SDP) [RFC4566]. In Section 4.2, rather than add a note that =E2=80=9Cthis X bit is not = to be confused with the X bit in the RTP header=E2=80=9D, would it not = make sense to rename this X bit? Similarly for the M bit in the = extension data fields, and the P bit in the payload header (which = isn=E2=80=99t mentioned). Or, at least, annotate each mention of these = fields to say which X, M, or P bit it required (e.g., =E2=80=9Cthe P bit = in the payload header=E2=80=9D or =E2=80=9Cthe P bit in the RTP = header=E2=80=9D rather than =E2=80=9Cthe P bit=E2=80=9D). Colin --=20 Colin Perkins https://csperkins.org/ From nobody Thu Sep 10 09:24:58 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C9F1B33FA for ; Thu, 10 Sep 2015 09:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2Hm3NG7KECh for ; Thu, 10 Sep 2015 09:24:48 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 13DAE1B3CB3 for ; Thu, 10 Sep 2015 09:24:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E3BCA7C5A38 for ; Thu, 10 Sep 2015 18:24:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_lcPGKqaEHY for ; Thu, 10 Sep 2015 18:24:44 +0200 (CEST) Received: from [10.104.199.189] (unknown [167.220.101.68]) by mork.alvestrand.no (Postfix) with ESMTPSA id C2B4D7C5A27 for ; Thu, 10 Sep 2015 18:24:43 +0200 (CEST) Message-ID: <55F1AEC9.6050408@alvestrand.no> Date: Thu, 10 Sep 2015 09:24:41 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: payload@ietf.org References: <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> In-Reply-To: <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 16:24:55 -0000 On 09/10/2015 03:28 AM, Colin Perkins wrote: >> On 9 Sep 2015, at 23:12, Ben Campbell wrote: >> >> On 9 Sep 2015, at 16:01, Henrik Lundin wrote: >> >>> We have made no technical changes to the document, but have added a n= umber of grammar updates and clarifications. Some of the important clarif= ications are as follows: >> Payload participants: Please note that there are in fact changes to 21= 19 language in this version. I won't quibble about whether or not those c= ount as "technical" changes, but please take a moment to review them. If = people object to any of them please say so asap , as this draft will like= ly be on the agenda for the IESG telechat next week. > The new text about the Payload Type in Section 4.1 says: > > Payload type (PT): In line with the policy in Section 3 of > [RFC3551], applications using the VP8 RTP payload profile MUST > assign a dynamic payload type number to be used in each RTP > session and provide a mechanism to indicate the mapping. See > Section 6.2 for the mechanism to be used with the Session > Description Protocol (SDP) [RFC4566]. > > This would be okay, except that RTP profiles that don=E2=80=99t derive = from RFC 3551 could be defined. A better wording might be: > > Payload Type (PT): The assignment of an RTP payload type for this > packet format is outside the scope of this document and will not be > specified here. It is expected that the RTP profile for a particular= > class of applications will assign a payload type for this encoding, > or if that is not done, then a payload type in the dynamic range > SHALL be chosen by means of an out-of-band signaling protocol. See > Section 6.2 for the mechanism to be used with the Session Description= > Protocol (SDP) [RFC4566]. > > > In Section 4.2, rather than add a note that =E2=80=9Cthis X bit is not = to be confused with the X bit in the RTP header=E2=80=9D, would it not ma= ke sense to rename this X bit? We considered this option, but decided that having a large existing body of documentation outside of the IETF that refers to the "X bit" and having a payload type registration that called it something else, it ws better to keep the name and just make a note that it's different. > Similarly for the M bit in the extension data fields, and the P bit in= the payload header (which isn=E2=80=99t mentioned). Or, at least, annota= te each mention of these fields to say which X, M, or P bit it required (= e.g., =E2=80=9Cthe P bit in the payload header=E2=80=9D or =E2=80=9Cthe P= bit in the RTP header=E2=80=9D rather than =E2=80=9Cthe P bit=E2=80=9D).= This can be done, and probably should be done for any reference that occurs outside of the section describing the VP8 payload descriptor (section 4.2) - I couldn't find any such references. There is no P bit in the VP8 payload descriptor, but there is one in the VP8 payload header, which is why we missed warning about the name collision there. It's never referred to in text. > > Colin > > > > > > > --=20 Surveillance is pervasive. Go Dark. From nobody Fri Sep 11 09:51:01 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A0E1A90A6 for ; Fri, 11 Sep 2015 09:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCYl8AZc7NyS for ; Fri, 11 Sep 2015 09:50:57 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F1D61A8ADC for ; Fri, 11 Sep 2015 09:50:57 -0700 (PDT) Received: from [130.209.247.112] (port=50085 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1ZaRXK-0001Rf-HW; Fri, 11 Sep 2015 17:50:55 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Colin Perkins In-Reply-To: <55F1AEC9.6050408@alvestrand.no> Date: Fri, 11 Sep 2015 17:50:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> <55F1AEC9.6050408@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.2104) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: payload@ietf.org Subject: Re: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 16:50:59 -0000 > On 10 Sep 2015, at 17:24, Harald Alvestrand = wrote: >=20 > On 09/10/2015 03:28 AM, Colin Perkins wrote: >>> On 9 Sep 2015, at 23:12, Ben Campbell wrote: >>>=20 >>> On 9 Sep 2015, at 16:01, Henrik Lundin wrote: >>>=20 >>>> We have made no technical changes to the document, but have added a = number of grammar updates and clarifications. Some of the important = clarifications are as follows: >>> Payload participants: Please note that there are in fact changes to = 2119 language in this version. I won't quibble about whether or not = those count as "technical" changes, but please take a moment to review = them. If people object to any of them please say so asap , as this draft = will likely be on the agenda for the IESG telechat next week. >> The new text about the Payload Type in Section 4.1 says: >>=20 >> Payload type (PT): In line with the policy in Section 3 of >> [RFC3551], applications using the VP8 RTP payload profile MUST >> assign a dynamic payload type number to be used in each RTP >> session and provide a mechanism to indicate the mapping. See >> Section 6.2 for the mechanism to be used with the Session >> Description Protocol (SDP) [RFC4566]. >>=20 >> This would be okay, except that RTP profiles that don=E2=80=99t = derive from RFC 3551 could be defined. A better wording might be: >>=20 >> Payload Type (PT): The assignment of an RTP payload type for this >> packet format is outside the scope of this document and will not be >> specified here. It is expected that the RTP profile for a = particular >> class of applications will assign a payload type for this encoding, >> or if that is not done, then a payload type in the dynamic range >> SHALL be chosen by means of an out-of-band signaling protocol. See >> Section 6.2 for the mechanism to be used with the Session = Description >> Protocol (SDP) [RFC4566]. >>=20 >>=20 >> In Section 4.2, rather than add a note that =E2=80=9Cthis X bit is = not to be confused with the X bit in the RTP header=E2=80=9D, would it = not make sense to rename this X bit? >=20 > We considered this option, but decided that having a large existing = body > of documentation outside of the IETF that refers to the "X bit" and > having a payload type registration that called it something else, it = ws > better to keep the name and just make a note that it=E2=80=99s = different. Makes sense. >> Similarly for the M bit in the extension data fields, and the P bit = in the payload header (which isn=E2=80=99t mentioned). Or, at least, = annotate each mention of these fields to say which X, M, or P bit it = required (e.g., =E2=80=9Cthe P bit in the payload header=E2=80=9D or = =E2=80=9Cthe P bit in the RTP header=E2=80=9D rather than =E2=80=9Cthe P = bit=E2=80=9D). >=20 > This can be done, and probably should be done for any reference that > occurs outside of the section describing the VP8 payload descriptor > (section 4.2) - I couldn=E2=80=99t find any such references. For clarity, I=E2=80=99d suggest it be done for all references in that = section too.=20 > There is no P bit in the VP8 payload descriptor, but there is one in = the > VP8 payload header, which is why we missed warning about the name > collision there. It's never referred to in text. Sure, but I think it does need to be highlighted that there=E2=80=99s a = name collision. None of these name collisions are a big deal, my main comment was on the = wording around PT, but I do think they=E2=80=99d make things clearer. Colin --=20 Colin Perkins https://csperkins.org/ From nobody Sun Sep 13 15:31:37 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C58D1B3404; Sun, 13 Sep 2015 15:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmKBEKsWg84E; Sun, 13 Sep 2015 15:31:33 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 49AF61B33B9; Sun, 13 Sep 2015 15:31:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B41F37C5A76; Mon, 14 Sep 2015 00:31:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FN7OA8jLgEsP; Mon, 14 Sep 2015 00:31:29 +0200 (CEST) Received: from [IPv6:2620:0:1001:7800:e4d5:7f6a:393d:ab3e] (unknown [IPv6:2620:0:1001:7800:e4d5:7f6a:393d:ab3e]) by mork.alvestrand.no (Postfix) with ESMTPSA id 812117C5A75; Mon, 14 Sep 2015 00:31:28 +0200 (CEST) To: Colin Perkins , Ben Campbell References: <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> From: Harald Alvestrand Message-ID: <55F5F93E.1000909@alvestrand.no> Date: Sun, 13 Sep 2015 15:31:26 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: payload-chairs@ietf.org, payload@ietf.org, draft-ietf-payload-vp8@tools.ietf.org Subject: Re: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 22:31:36 -0000 On 09/10/2015 03:28 AM, Colin Perkins wrote: > The new text about the Payload Type in Section 4.1 says: > > Payload type (PT): In line with the policy in Section 3 of > [RFC3551], applications using the VP8 RTP payload profile MUST > assign a dynamic payload type number to be used in each RTP > session and provide a mechanism to indicate the mapping. See > Section 6.2 for the mechanism to be used with the Session > Description Protocol (SDP) [RFC4566]. > > This would be okay, except that RTP profiles that don’t derive from RFC 3551 could be defined. A better wording might be: > > Payload Type (PT): The assignment of an RTP payload type for this > packet format is outside the scope of this document and will not be > specified here. It is expected that the RTP profile for a particular > class of applications will assign a payload type for this encoding, > or if that is not done, then a payload type in the dynamic range > SHALL be chosen by means of an out-of-band signaling protocol. See > Section 6.2 for the mechanism to be used with the Session Description > Protocol (SDP) [RFC4566]. > One question about this suggestion (from a general considerations perspective): Is there any value at all in having this text in a payload type registration? What we want to say is that this document doesn't change any rules for payload type registration - it's simply not relevant to this memo. That would make the text shorter - we could stop after "will not be specified here" in Colin's suggested text. If the WG thinks the longer text has value, I'm happy to include it, but I'm even happier if we can leave it out. -- Surveillance is pervasive. Go Dark. From nobody Wed Sep 16 03:11:41 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C01E1AC3AB; Tue, 15 Sep 2015 11:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, J_CHICKENPOX_26=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvGD2LNfPxQC; Tue, 15 Sep 2015 11:59:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA3C1A1EFF; Tue, 15 Sep 2015 11:59:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150915185911.21707.81126.idtracker@ietfa.amsl.com> Date: Tue, 15 Sep 2015 11:59:11 -0700 Archived-At: X-Mailman-Approved-At: Wed, 16 Sep 2015 03:11:39 -0700 Cc: payload-chairs@ietf.org, draft-ietf-payload-vp8@ietf.org, payload@ietf.org Subject: [payload] Alissa Cooper's No Objection on draft-ietf-payload-vp8-17: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 18:59:12 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-payload-vp8-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- 4.2: Little confused as to why the I and L behavior is specified twice, e.g.: "I: PictureID present. When set to one, the PictureID MUST be present after the extension bit field and specified as below. Otherwise, PictureID MUST NOT be present." and "The PictureID extension: If the I bit is set to one, the PictureID extension field MUST be present, and MUST NOT be present otherwise." -- 4.2: Why would the index values TL0PICIDX and KEYIDX start at random values? -- 6.1: Seconding Pete's old comment that the normative requirements on use of max-fs and max-fr should appear somewhere other than the media type definition. From nobody Wed Sep 16 19:25:00 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26D11AC415; Wed, 16 Sep 2015 19:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqCpHpdsGpia; Wed, 16 Sep 2015 19:24:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED151AC3E2; Wed, 16 Sep 2015 19:24:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150917022433.25044.53666.idtracker@ietfa.amsl.com> Date: Wed, 16 Sep 2015 19:24:33 -0700 Archived-At: Cc: payload-chairs@ietf.org, draft-ietf-payload-vp8@ietf.org, payload@ietf.org Subject: [payload] Kathleen Moriarty's No Objection on draft-ietf-payload-vp8-17: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 02:24:59 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-payload-vp8-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Why is this a SHOULD: Applications SHOULD use one or more appropriate strong security mechanisms. Wouldn't it be more helpful to point out why you would use specific security mechanisms for security considerations? From nobody Wed Sep 16 21:05:00 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3590D1B2A9B; Wed, 16 Sep 2015 21:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpstRDCUvgco; Wed, 16 Sep 2015 21:04:58 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 418D61B2A97; Wed, 16 Sep 2015 21:04:58 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8H44kQs017678 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 16 Sep 2015 23:04:56 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Kathleen Moriarty" Date: Wed, 16 Sep 2015 23:04:45 -0500 Message-ID: In-Reply-To: <20150917022433.25044.53666.idtracker@ietfa.amsl.com> References: <20150917022433.25044.53666.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: payload-chairs@ietf.org, The IESG , payload@ietf.org, draft-ietf-payload-vp8@ietf.org Subject: Re: [payload] Kathleen Moriarty's No Objection on draft-ietf-payload-vp8-17: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 04:04:59 -0000 On 16 Sep 2015, at 21:24, Kathleen Moriarty wrote: > Why is this a SHOULD: > Applications SHOULD use one or more appropriate strong security > mechanisms. > > Wouldn't it be more helpful to point out why you would use specific > security mechanisms for security considerations? Hi Kathleen, That's part of the boilerplate for payload drafts. The idea is that the security requirements are specific to the application that uses RTP, not RTP itself or the related payload format. For example, WebRTC requires DTLS-SRTP. There's an open discussion on what should be required for point-to-point RTP sessions signaled via SIP (which I need to push forward.) This is discussed further in RFCs 7201 and 7202. Thanks! Ben. From nobody Thu Sep 17 03:46:15 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F2D1B2BF5; Thu, 17 Sep 2015 03:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXURGgW1gFAC; Thu, 17 Sep 2015 03:46:10 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22DED1B2CA6; Thu, 17 Sep 2015 03:46:10 -0700 (PDT) Received: by qgez77 with SMTP id z77so8983206qge.1; Thu, 17 Sep 2015 03:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rlfbGOBhlYvLiVfy5rM10fzbYarhDDctnXmNisfi+ik=; b=zb5Nz/GCnPPaZ5D7TXQBTtHULvnQ8PLA4xQCKKvzhWSnjVLGgk7OquOnHia5CY6JBn kDIwlWDxwD8vTqSqKgBp0gqqm8LPwO7QoTRgSPsijXRfEvcy17icfBia47HScOO1hGdF 0YkarsuhZZ/VaY85HVO1O6T69htpL87eY6MaP4wooQH9BFiFFMPWgiaMpb+mlkCJhGk3 lVM/qVXaM91hkRL/1QbeKQCSEDa5JBAh7M7jNy2Tz7cjddbun6jNy4DxWOpJNrMtdpF1 DbmgiEmXM6+Hzm2AVj2XLMAoa4MsYb59okEKYmASPFB7sLh6UlFSFmN8AeB46U/GhmZA Fhxw== X-Received: by 10.140.152.68 with SMTP id 65mr51055324qhy.16.1442486769291; Thu, 17 Sep 2015 03:46:09 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by smtp.gmail.com with ESMTPSA id p29sm982089qkp.48.2015.09.17.03.46.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Sep 2015 03:46:08 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: Date: Thu, 17 Sep 2015 06:46:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <63FAF756-A72B-4682-B401-050D5F460400@gmail.com> References: <20150917022433.25044.53666.idtracker@ietfa.amsl.com> To: Ben Campbell Archived-At: Cc: "payload-chairs@ietf.org" , The IESG , "payload@ietf.org" , "draft-ietf-payload-vp8@ietf.org" Subject: Re: [payload] Kathleen Moriarty's No Objection on draft-ietf-payload-vp8-17: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 10:46:12 -0000 Sent from my iPhone > On Sep 17, 2015, at 12:04 AM, Ben Campbell wrote: >=20 >> On 16 Sep 2015, at 21:24, Kathleen Moriarty wrote: >>=20 >> Why is this a SHOULD: >> Applications SHOULD use one or more appropriate strong security >> mechanisms. >>=20 >> Wouldn't it be more helpful to point out why you would use specific >> security mechanisms for security considerations? >=20 > Hi Kathleen, >=20 > That's part of the boilerplate for payload drafts. The idea is that the se= curity requirements are specific to the application that uses RTP, not RTP i= tself or the related payload format. For example, WebRTC requires DTLS-SRTP.= There's an open discussion on what should be required for point-to-point RT= P sessions signaled via SIP (which I need to push forward.) >=20 > This is discussed further in RFCs 7201 and 7202. >=20 > Thanks! >=20 > Ben. Thanks, Ben! Do you recall which draft we changed that in or was it unrelated, just an in= credibly similar sentence? Thanks, Kathleen=20= From nobody Thu Sep 17 06:38:29 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2301B2D78; Thu, 17 Sep 2015 06:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8nh8tjfrwiZ; Thu, 17 Sep 2015 06:38:24 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44AEB1B2BBF; Thu, 17 Sep 2015 06:38:24 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so27775884wic.0; Thu, 17 Sep 2015 06:38:22 -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=VPCIm/1s7c0mXKSzxvqdWf/QYDNg1m2ur91SgKYkpJk=; b=JBVSCjVTlhYUI7OlgaFZP7pmzxtq9GUh8mlJpcps8RTEFb2SY838egBS2f7lqIMmJJ IQu4PxoF4dv9ZmIjOLFWnvGIxfNkRqkhp/ATMUwyyrjyPoc1xMMvdYGE6PhgkarI7Xdu 9B1P41YN+WTxv15JPWzhgCVBbVrj4bzeV6UQM2M+h5jVm30hNR0LpCnweh6ipCBYTBzv iL4PYzHanUWOoct1qPn1gbv+BBs2lu3oLNSne2Er0wNgdPsmNkY2Y17fOQGh9ft3l/bU zEgOqwCTCubCLvziHZYFvc/hkTYm3Gca/Pv5jLAfQt31Xg1X1mbp+jFFtLezXOXIR/td FJJw== MIME-Version: 1.0 X-Received: by 10.180.105.196 with SMTP id go4mr7650761wib.36.1442497102776; Thu, 17 Sep 2015 06:38:22 -0700 (PDT) Received: by 10.28.214.213 with HTTP; Thu, 17 Sep 2015 06:38:22 -0700 (PDT) In-Reply-To: <63FAF756-A72B-4682-B401-050D5F460400@gmail.com> References: <20150917022433.25044.53666.idtracker@ietfa.amsl.com> <63FAF756-A72B-4682-B401-050D5F460400@gmail.com> Date: Thu, 17 Sep 2015 09:38:22 -0400 Message-ID: From: Kathleen Moriarty To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "payload-chairs@ietf.org" , The IESG , "payload@ietf.org" , "draft-ietf-payload-vp8@ietf.org" Subject: Re: [payload] Kathleen Moriarty's No Objection on draft-ietf-payload-vp8-17: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 13:38:26 -0000 Hi Ben, I was able to dig up the document we had this discussion on and the boilerplate appropriately reflects the outcome of the discussion from rfc7587. I knew I remembered the wording when I saw it, and it is what was agreed upon. Thanks, Kathleen On Thu, Sep 17, 2015 at 6:46 AM, Kathleen Moriarty wrote: > > > Sent from my iPhone > >> On Sep 17, 2015, at 12:04 AM, Ben Campbell wrote: >> >>> On 16 Sep 2015, at 21:24, Kathleen Moriarty wrote: >>> >>> Why is this a SHOULD: >>> Applications SHOULD use one or more appropriate strong security >>> mechanisms. >>> >>> Wouldn't it be more helpful to point out why you would use specific >>> security mechanisms for security considerations? >> >> Hi Kathleen, >> >> That's part of the boilerplate for payload drafts. The idea is that the = security requirements are specific to the application that uses RTP, not RT= P itself or the related payload format. For example, WebRTC requires DTLS-S= RTP. There's an open discussion on what should be required for point-to-poi= nt RTP sessions signaled via SIP (which I need to push forward.) >> >> This is discussed further in RFCs 7201 and 7202. >> >> Thanks! >> >> Ben. > > Thanks, Ben! > > Do you recall which draft we changed that in or was it unrelated, just an= incredibly similar sentence? > > Thanks, > Kathleen --=20 Best regards, Kathleen From nobody Thu Sep 17 13:56:11 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8357E1A0248; Thu, 17 Sep 2015 13:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0o95waIut8r; Thu, 17 Sep 2015 13:56:03 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 2750F1A02F1; Thu, 17 Sep 2015 13:56:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 042847C5AF4; Thu, 17 Sep 2015 22:56:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnzRypCmKarR; Thu, 17 Sep 2015 22:56:01 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:c145:6369:f3ab:8b60] (unknown [IPv6:2001:470:de0a:27:c145:6369:f3ab:8b60]) by mork.alvestrand.no (Postfix) with ESMTPSA id C91FB7C5AF6; Thu, 17 Sep 2015 22:56:00 +0200 (CEST) To: Alissa Cooper , The IESG References: <20150915185911.21707.81126.idtracker@ietfa.amsl.com> From: Harald Alvestrand X-Enigmail-Draft-Status: N1110 Message-ID: <55FB28E0.9000108@alvestrand.no> Date: Thu, 17 Sep 2015 22:56:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150915185911.21707.81126.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: payload-chairs@ietf.org, draft-ietf-payload-vp8@ietf.org, payload@ietf.org Subject: Re: [payload] Alissa Cooper's No Objection on draft-ietf-payload-vp8-17: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 20:56:06 -0000 Quick comment: Den 15. sep. 2015 20:59, skrev Alissa Cooper: > Alissa Cooper has entered the following ballot position for > draft-ietf-payload-vp8-17: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > -- 4.2: Little confused as to why the I and L behavior is specified > twice, e.g.: > > "I: PictureID present. When set to one, the PictureID MUST be present > after the extension bit field and specified as below. Otherwise, > PictureID MUST NOT be present." > > and > > "The PictureID extension: If the I bit is set to one, the PictureID > extension field MUST be present, and MUST NOT be present > otherwise." This was done to make each description complete; it doesn't really make a substantial difference. > > -- 4.2: Why would the index values TL0PICIDX and KEYIDX start at random > values? At one point we wondered if this was a security issue; after consulting with the people who did the implementation, we concluded that it was not, but existing code does it this way, and there was no reason to make the existing deployed base non-conformant. > -- 6.1: Seconding Pete's old comment that the normative requirements on > use of max-fs and max-fr should appear somewhere other than the media > type definition. I'll just have to respectfully disagree with Pete here; these parameters were added for use in SDP offer/answer negotiation, they have no references outside the media type definition, and are only useful within the context of media configuration, which is only done by using the media type definition. I do not see any reason to define these parameters or the requirements on them outside the media type definition. (The relationship between RTP payload types and SDP is an interesting one. These are two completely separate layers of protocol, and in my opinion the dividing line should be strengthened, not weakened. But this is an issue that has repercussions far outside the specialized field of RTP payload definitions, so I would prefer not to go further into that here.) Hope this helps! > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > From nobody Tue Sep 22 07:40:48 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC001A8A97 for ; Tue, 22 Sep 2015 07:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apm-K196lEKg for ; Tue, 22 Sep 2015 07:40:46 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C6C81A8A95 for ; Tue, 22 Sep 2015 07:40:46 -0700 (PDT) Received: from [172.20.10.2] (mobile-166-173-187-116.mycingular.net [166.173.187.116]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8MEebH1037471 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 22 Sep 2015 09:40:43 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-173-187-116.mycingular.net [166.173.187.116] claimed to be [172.20.10.2] From: "Ben Campbell" To: "Harald Alvestrand" Date: Tue, 22 Sep 2015 09:40:32 -0500 Message-ID: <4D9392D8-4790-41EB-9FC6-B7CC98895E10@nostrum.com> In-Reply-To: <55F1AEC9.6050408@alvestrand.no> References: <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> <55F1AEC9.6050408@alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: payload@ietf.org Subject: Re: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 14:40:48 -0000 Hi Harald, I will check with Alissa to see if her concerns have been addressed. Has there been closure on Elwyn's Gen-ART telechat review and on Colin's comments on the payload list? I was under the impression that at least Colin's comments might result in an update (although we can handle minor changes with RFC editor notes) Also, I had some comments a while back to which I do not recall seeing a response: > -- section 3, Payload Type: "... the VP8 RTP payload profile MUST > assign a dynamic payload type number ..." > > If I read correctly, Colin Perkins objected to this change. Did you > consider his objection? > > -- 4.2 > > I didn't see anything addressing Elwyn's Gen-ART (last call) review > question about: “What happens if L=1 but both T=0 and K=0 so that > there is no TID value present? Or indeed if T=0 but K=1 so that the > TID field is there but 'MUST be ignored by the receiver' (definition > of TID field)?” Did I miss something? Thanks! Ben. On 10 Sep 2015, at 11:24, Harald Alvestrand wrote: > On 09/10/2015 03:28 AM, Colin Perkins wrote: >>> On 9 Sep 2015, at 23:12, Ben Campbell wrote: >>> >>> On 9 Sep 2015, at 16:01, Henrik Lundin wrote: >>> >>>> We have made no technical changes to the document, but have added a >>>> number of grammar updates and clarifications. Some of the important >>>> clarifications are as follows: >>> Payload participants: Please note that there are in fact changes to >>> 2119 language in this version. I won't quibble about whether or not >>> those count as "technical" changes, but please take a moment to >>> review them. If people object to any of them please say so asap , as >>> this draft will likely be on the agenda for the IESG telechat next >>> week. >> The new text about the Payload Type in Section 4.1 says: >> >> Payload type (PT): In line with the policy in Section 3 of >> [RFC3551], applications using the VP8 RTP payload profile MUST >> assign a dynamic payload type number to be used in each RTP >> session and provide a mechanism to indicate the mapping. See >> Section 6.2 for the mechanism to be used with the Session >> Description Protocol (SDP) [RFC4566]. >> >> This would be okay, except that RTP profiles that don’t derive from >> RFC 3551 could be defined. A better wording might be: >> >> Payload Type (PT): The assignment of an RTP payload type for this >> packet format is outside the scope of this document and will not be >> specified here. It is expected that the RTP profile for a particular >> class of applications will assign a payload type for this encoding, >> or if that is not done, then a payload type in the dynamic range >> SHALL be chosen by means of an out-of-band signaling protocol. See >> Section 6.2 for the mechanism to be used with the Session Description >> Protocol (SDP) [RFC4566]. >> >> >> In Section 4.2, rather than add a note that “this X bit is not to >> be confused with the X bit in the RTP header”, would it not make >> sense to rename this X bit? > > We considered this option, but decided that having a large existing > body > of documentation outside of the IETF that refers to the "X bit" and > having a payload type registration that called it something else, it > ws > better to keep the name and just make a note that it's different. > >> Similarly for the M bit in the extension data fields, and the P bit >> in the payload header (which isn’t mentioned). Or, at least, >> annotate each mention of these fields to say which X, M, or P bit it >> required (e.g., “the P bit in the payload header” or “the P bit >> in the RTP header” rather than “the P bit”). > > This can be done, and probably should be done for any reference that > occurs outside of the section describing the VP8 payload descriptor > (section 4.2) - I couldn't find any such references. > > There is no P bit in the VP8 payload descriptor, but there is one in > the > VP8 payload header, which is why we missed warning about the name > collision there. It's never referred to in text. > > >> >> Colin >> >> >> >> >> >> >> > > > -- > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Tue Sep 22 09:30:19 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FB81B2BE4; Tue, 22 Sep 2015 09:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.799 X-Spam-Level: * X-Spam-Status: No, score=1.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MSGID_MULTIPLE_AT=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQSDuRlCOjg1; Tue, 22 Sep 2015 09:30:17 -0700 (PDT) Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768CC1A9111; Tue, 22 Sep 2015 09:30:17 -0700 (PDT) Received: from ClintonLT (rrcs-72-43-202-98.nys.biz.rr.com [72.43.202.98]) by host105.olm1.com (Postfix) with ESMTPSA id 26337B41806; Tue, 22 Sep 2015 12:31:36 -0400 (EDT) From: "Victor Demjanenko, Ph.D." To: References: <20150915185911.21707.81126.idtracker@ietfa.amsl.com> <55FB28E0.9000108@alvestrand.no> In-Reply-To: <55FB28E0.9000108@alvestrand.no> Date: Tue, 22 Sep 2015 12:30:12 -0400 Message-ID: <107801d0f553$f5327600$df976200$@demjanenko@vocal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdDxi3ic3xcG8NqOTn2QKqPgm/4TfwDxwL3Q Content-Language: en-us Archived-At: Cc: payload-chairs@ietf.org, "''Dave Satterlee \(Vocal\)''" Subject: Re: [payload] New Version Notification for draft-demjanenko-payload-melpe-04.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 16:30:18 -0000 Hi everyone, There were some outstanding editorial changes that were suggested prior to the last WG meeting that are addressed by this draft. Mostly the term "rate" has been replace by "bitrate", "bit-rate" or "bit rate" as appropriate. This is most relevant to SDP's conveyance of the speech coder's operating rate (its bit rate). Please let me know if other changes or clarifications would be helpful. As per the discussion at the last WG, we would like the chairs to ask for permission to adopt as a WG draft and advance toward an RFC. Thank you. Victor Demjanenko David Satterlee BTW, there is a draft-demjanenko-payload-melp-00.txt which is intentionally allowed to expire. There was a mismatch in names (melp vs melpe) which caused this inconsistency. No information is lost by the expiring draft. draft-demjanenko-payload-melpe-04.txt is our latest and most complete document. From nobody Tue Sep 22 10:32:42 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198161B2C41 for ; Tue, 22 Sep 2015 10:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrDpL4mDySR2 for ; Tue, 22 Sep 2015 10:32:38 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 028871ACD45 for ; Tue, 22 Sep 2015 10:32:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 15FDD7C5B37; Tue, 22 Sep 2015 19:32:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9W3OUxWISbh; Tue, 22 Sep 2015 19:32:34 +0200 (CEST) Received: from [IPv6:2620:0:1043:9:a82f:1c10:3aab:2955] (unknown [IPv6:2620:0:1043:9:a82f:1c10:3aab:2955]) by mork.alvestrand.no (Postfix) with ESMTPSA id C31677C5B36; Tue, 22 Sep 2015 19:32:34 +0200 (CEST) To: Ben Campbell References: <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> <55F1AEC9.6050408@alvestrand.no> <4D9392D8-4790-41EB-9FC6-B7CC98895E10@nostrum.com> From: Harald Alvestrand Message-ID: <560190B1.3040400@alvestrand.no> Date: Tue, 22 Sep 2015 19:32:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <4D9392D8-4790-41EB-9FC6-B7CC98895E10@nostrum.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: payload@ietf.org Subject: Re: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 17:32:41 -0000 On 09/22/2015 04:40 PM, Ben Campbell wrote: > Hi Harald, > > I will check with Alissa to see if her concerns have been addressed. > > Has there been closure on Elwyn's Gen-ART telechat review and on > Colin's comments on the payload list? I was under the impression that > at least Colin's comments might result in an update (although we can > handle minor changes with RFC editor notes) > > Also, I had some comments a while back to which I do not recall seeing > a response: > >> -- section 3, Payload Type: "... the VP8 RTP payload profile MUST >> assign a dynamic payload type number ..." >> >> If I read correctly, Colin Perkins objected to this change. Did you >> consider his objection? I asked in response if we can delete the whole thing about payload type assignment, since it's not a proper concern of the payload type. I did not get a response, so I thought it couldn't be important. >> >> -- 4.2 >> >> I didn't see anything addressing Elwyn's Gen-ART (last call) review >> question about: “What happens if L=1 but both T=0 and K=0 so that >> there is no TID value present? Or indeed if T=0 but K=1 so that the >> TID field is there but 'MUST be ignored by the receiver' (definition >> of TID field)?” Did I miss something? On this matter, we thought the text was clear that those streams would be illegal, and we don't specify the processing of illegal streams. But if it isn't clear that it's illegal, we may want to reconsider. > > Thanks! > > Ben. > > > On 10 Sep 2015, at 11:24, Harald Alvestrand wrote: > >> On 09/10/2015 03:28 AM, Colin Perkins wrote: >>>> On 9 Sep 2015, at 23:12, Ben Campbell wrote: >>>> >>>> On 9 Sep 2015, at 16:01, Henrik Lundin wrote: >>>> >>>>> We have made no technical changes to the document, but have added >>>>> a number of grammar updates and clarifications. Some of the >>>>> important clarifications are as follows: >>>> Payload participants: Please note that there are in fact changes to >>>> 2119 language in this version. I won't quibble about whether or not >>>> those count as "technical" changes, but please take a moment to >>>> review them. If people object to any of them please say so asap , >>>> as this draft will likely be on the agenda for the IESG telechat >>>> next week. >>> The new text about the Payload Type in Section 4.1 says: >>> >>> Payload type (PT): In line with the policy in Section 3 of >>> [RFC3551], applications using the VP8 RTP payload profile MUST >>> assign a dynamic payload type number to be used in each RTP >>> session and provide a mechanism to indicate the mapping. See >>> Section 6.2 for the mechanism to be used with the Session >>> Description Protocol (SDP) [RFC4566]. >>> >>> This would be okay, except that RTP profiles that don’t derive from >>> RFC 3551 could be defined. A better wording might be: >>> >>> Payload Type (PT): The assignment of an RTP payload type for this >>> packet format is outside the scope of this document and will not be >>> specified here. It is expected that the RTP profile for a particular >>> class of applications will assign a payload type for this encoding, >>> or if that is not done, then a payload type in the dynamic range >>> SHALL be chosen by means of an out-of-band signaling protocol. See >>> Section 6.2 for the mechanism to be used with the Session Description >>> Protocol (SDP) [RFC4566]. >>> >>> >>> In Section 4.2, rather than add a note that “this X bit is not to be >>> confused with the X bit in the RTP header”, would it not make sense >>> to rename this X bit? >> >> We considered this option, but decided that having a large existing body >> of documentation outside of the IETF that refers to the "X bit" and >> having a payload type registration that called it something else, it ws >> better to keep the name and just make a note that it's different. >> >>> Similarly for the M bit in the extension data fields, and the P bit >>> in the payload header (which isn’t mentioned). Or, at least, >>> annotate each mention of these fields to say which X, M, or P bit it >>> required (e.g., “the P bit in the payload header” or “the P bit in >>> the RTP header” rather than “the P bit”). >> >> This can be done, and probably should be done for any reference that >> occurs outside of the section describing the VP8 payload descriptor >> (section 4.2) - I couldn't find any such references. >> >> There is no P bit in the VP8 payload descriptor, but there is one in the >> VP8 payload header, which is why we missed warning about the name >> collision there. It's never referred to in text. >> >> >>> >>> Colin >>> >>> >>> >>> >>> >>> >>> >> >> >> -- >> Surveillance is pervasive. Go Dark. >> >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload -- Surveillance is pervasive. Go Dark. From nobody Tue Sep 22 10:43:44 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D47A1A911B for ; Tue, 22 Sep 2015 10:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtxT8HbpTU8h for ; Tue, 22 Sep 2015 10:43:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 192BD1A9114 for ; Tue, 22 Sep 2015 10:43:41 -0700 (PDT) Received: from [172.20.10.2] (mobile-166-173-187-116.mycingular.net [166.173.187.116]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8MHhWQK077498 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 22 Sep 2015 12:43:37 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-173-187-116.mycingular.net [166.173.187.116] claimed to be [172.20.10.2] From: "Ben Campbell" To: "Harald Alvestrand" Date: Tue, 22 Sep 2015 12:43:26 -0500 Message-ID: In-Reply-To: <560190B1.3040400@alvestrand.no> References: <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> <55F1AEC9.6050408@alvestrand.no> <4D9392D8-4790-41EB-9FC6-B7CC98895E10@nostrum.com> <560190B1.3040400@alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: payload@ietf.org Subject: Re: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 17:43:43 -0000 inline: On 22 Sep 2015, at 12:32, Harald Alvestrand wrote: > On 09/22/2015 04:40 PM, Ben Campbell wrote: >> Hi Harald, >> >> I will check with Alissa to see if her concerns have been addressed. >> >> Has there been closure on Elwyn's Gen-ART telechat review and on >> Colin's comments on the payload list? I was under the impression that >> at least Colin's comments might result in an update (although we can >> handle minor changes with RFC editor notes) I didn't see a response to the above. IIUC, these are distinct from Colin's and Elwyn's other points that I had copied below. >> >> Also, I had some comments a while back to which I do not recall >> seeing >> a response: >> >>> -- section 3, Payload Type: "... the VP8 RTP payload profile MUST >>> assign a dynamic payload type number ..." >>> >>> If I read correctly, Colin Perkins objected to this change. Did you >>> consider his objection? > I asked in response if we can delete the whole thing about payload > type > assignment, since it's not a proper concern of the payload type. I did > not get a response, so I thought it couldn't be important. It's probably worth poking Colin to make sure he's paying attention (I will do so.) But if we don't see a quick response, then I will agree with your assessment. >>> >>> -- 4.2 >>> >>> I didn't see anything addressing Elwyn's Gen-ART (last call) review >>> question about: “What happens if L=1 but both T=0 and K=0 so that >>> there is no TID value present? Or indeed if T=0 but K=1 so that the >>> TID field is there but 'MUST be ignored by the receiver' >>> (definition >>> of TID field)?” Did I miss something? > > On this matter, we thought the text was clear that those streams would > be illegal, and we don't specify the processing of illegal streams. > But > if it isn't clear that it's illegal, we may want to reconsider. I think that's a reasonable response, and a change is probably not needed. >> >> Thanks! >> >> Ben. >> >> >> On 10 Sep 2015, at 11:24, Harald Alvestrand wrote: >> >>> On 09/10/2015 03:28 AM, Colin Perkins wrote: >>>>> On 9 Sep 2015, at 23:12, Ben Campbell wrote: >>>>> >>>>> On 9 Sep 2015, at 16:01, Henrik Lundin wrote: >>>>> >>>>>> We have made no technical changes to the document, but have added >>>>>> a number of grammar updates and clarifications. Some of the >>>>>> important clarifications are as follows: >>>>> Payload participants: Please note that there are in fact changes >>>>> to >>>>> 2119 language in this version. I won't quibble about whether or >>>>> not >>>>> those count as "technical" changes, but please take a moment to >>>>> review them. If people object to any of them please say so asap , >>>>> as this draft will likely be on the agenda for the IESG telechat >>>>> next week. >>>> The new text about the Payload Type in Section 4.1 says: >>>> >>>> Payload type (PT): In line with the policy in Section 3 of >>>> [RFC3551], applications using the VP8 RTP payload profile MUST >>>> assign a dynamic payload type number to be used in each RTP >>>> session and provide a mechanism to indicate the mapping. See >>>> Section 6.2 for the mechanism to be used with the Session >>>> Description Protocol (SDP) [RFC4566]. >>>> >>>> This would be okay, except that RTP profiles that don’t derive >>>> from >>>> RFC 3551 could be defined. A better wording might be: >>>> >>>> Payload Type (PT): The assignment of an RTP payload type for this >>>> packet format is outside the scope of this document and will not be >>>> specified here. It is expected that the RTP profile for a >>>> particular >>>> class of applications will assign a payload type for this encoding, >>>> or if that is not done, then a payload type in the dynamic range >>>> SHALL be chosen by means of an out-of-band signaling protocol. See >>>> Section 6.2 for the mechanism to be used with the Session >>>> Description >>>> Protocol (SDP) [RFC4566]. >>>> >>>> >>>> In Section 4.2, rather than add a note that “this X bit is not to >>>> be >>>> confused with the X bit in the RTP header”, would it not make >>>> sense >>>> to rename this X bit? >>> >>> We considered this option, but decided that having a large existing >>> body >>> of documentation outside of the IETF that refers to the "X bit" and >>> having a payload type registration that called it something else, it >>> ws >>> better to keep the name and just make a note that it's different. >>> >>>> Similarly for the M bit in the extension data fields, and the P bit >>>> in the payload header (which isn’t mentioned). Or, at least, >>>> annotate each mention of these fields to say which X, M, or P bit >>>> it >>>> required (e.g., “the P bit in the payload header” or “the P >>>> bit in >>>> the RTP header” rather than “the P bit”). >>> >>> This can be done, and probably should be done for any reference that >>> occurs outside of the section describing the VP8 payload descriptor >>> (section 4.2) - I couldn't find any such references. >>> >>> There is no P bit in the VP8 payload descriptor, but there is one in >>> the >>> VP8 payload header, which is why we missed warning about the name >>> collision there. It's never referred to in text. >>> >>> >>>> >>>> Colin >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Surveillance is pervasive. Go Dark. >>> >>> >>> _______________________________________________ >>> payload mailing list >>> payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload > > > -- > Surveillance is pervasive. Go Dark. From nobody Tue Sep 22 10:50:35 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B38C1A9163; Tue, 22 Sep 2015 10:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYMhZ_M-1Z84; Tue, 22 Sep 2015 10:50:33 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E33F91A9110; Tue, 22 Sep 2015 10:50:32 -0700 (PDT) Received: from [172.20.10.2] (mobile-166-173-187-116.mycingular.net [166.173.187.116]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8MHoIDM084590 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 22 Sep 2015 12:50:24 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-173-187-116.mycingular.net [166.173.187.116] claimed to be [172.20.10.2] From: "Ben Campbell" To: "Colin Perkins" Date: Tue, 22 Sep 2015 12:50:13 -0500 Message-ID: In-Reply-To: <55F5F93E.1000909@alvestrand.no> References: <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> <55F5F93E.1000909@alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: payload-chairs@ietf.org, payload@ietf.org, draft-ietf-payload-vp8@tools.ietf.org Subject: Re: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 17:50:34 -0000 Colin, did Harald's response address your concern? Thanks! Ben. On 13 Sep 2015, at 17:31, Harald Alvestrand wrote: > On 09/10/2015 03:28 AM, Colin Perkins wrote: >> The new text about the Payload Type in Section 4.1 says: >> >> Payload type (PT): In line with the policy in Section 3 of >> [RFC3551], applications using the VP8 RTP payload profile MUST >> assign a dynamic payload type number to be used in each RTP >> session and provide a mechanism to indicate the mapping. See >> Section 6.2 for the mechanism to be used with the Session >> Description Protocol (SDP) [RFC4566]. >> >> This would be okay, except that RTP profiles that don’t derive from >> RFC 3551 could be defined. A better wording might be: >> >> Payload Type (PT): The assignment of an RTP payload type for this >> packet format is outside the scope of this document and will not be >> specified here. It is expected that the RTP profile for a particular >> class of applications will assign a payload type for this encoding, >> or if that is not done, then a payload type in the dynamic range >> SHALL be chosen by means of an out-of-band signaling protocol. See >> Section 6.2 for the mechanism to be used with the Session Description >> Protocol (SDP) [RFC4566]. >> > One question about this suggestion (from a general considerations > perspective): Is there any value at all in having this text in a > payload > type registration? > > What we want to say is that this document doesn't change any rules for > payload type registration - it's simply not relevant to this memo. > > That would make the text shorter - we could stop after "will not be > specified here" in Colin's suggested text. > > If the WG thinks the longer text has value, I'm happy to include it, > but > I'm even happier if we can leave it out. > > > > > -- > Surveillance is pervasive. Go Dark. From nobody Tue Sep 22 10:51:50 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CCB1A9140 for ; Tue, 22 Sep 2015 10:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDBJauGjBXjB for ; Tue, 22 Sep 2015 10:51:48 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76DB31A9110 for ; Tue, 22 Sep 2015 10:51:48 -0700 (PDT) Received: from [172.20.10.2] (mobile-166-173-187-116.mycingular.net [166.173.187.116]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8MHpdFb084984 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 22 Sep 2015 12:51:45 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-173-187-116.mycingular.net [166.173.187.116] claimed to be [172.20.10.2] From: "Ben Campbell" To: "Harald Alvestrand" Date: Tue, 22 Sep 2015 12:51:34 -0500 Message-ID: In-Reply-To: References: <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> <55F1AEC9.6050408@alvestrand.no> <4D9392D8-4790-41EB-9FC6-B7CC98895E10@nostrum.com> <560190B1.3040400@alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: payload@ietf.org Subject: Re: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 17:51:49 -0000 On 22 Sep 2015, at 12:43, Ben Campbell wrote: > Has there been closure on Elwyn's Gen-ART telechat review and on >>> Colin's comments on the payload list? I was under the impression >>> that >>> at least Colin's comments might result in an update (although we can >>> handle minor changes with RFC editor notes) > > > > I didn't see a response to the above. IIUC, these are distinct from > Colin's and Elwyn's other points that I had copied below. On re-reading the list, I think I was mistaken about the comments being distinct--never mind about this part. Thanks! Ben. From nobody Tue Sep 22 13:52:22 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFB81B2DF5 for ; Tue, 22 Sep 2015 13:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmFnp1XTJ-5T for ; Tue, 22 Sep 2015 13:52:18 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E791B2E09 for ; Tue, 22 Sep 2015 13:52:05 -0700 (PDT) Received: from [81.187.2.149] (port=48420 helo=[192.168.0.21]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1ZeUXh-00088L-9l; Tue, 22 Sep 2015 21:52:03 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Colin Perkins In-Reply-To: <560190B1.3040400@alvestrand.no> Date: Tue, 22 Sep 2015 21:51:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <88518539-9321-4616-A84F-736A1C9D2256@csperkins.org> References: <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> <55F1AEC9.6050408@alvestrand.no> <4D9392D8-4790-41EB-9FC6-B7CC98895E10@nostrum.com> <560190B1.3040400@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.2104) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: payload@ietf.org Subject: Re: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 20:52:21 -0000 > On 22 Sep 2015, at 18:32, Harald Alvestrand = wrote: >=20 > On 09/22/2015 04:40 PM, Ben Campbell wrote: >> Hi Harald, >>=20 >> I will check with Alissa to see if her concerns have been addressed. >>=20 >> Has there been closure on Elwyn's Gen-ART telechat review and on >> Colin's comments on the payload list? I was under the impression that >> at least Colin's comments might result in an update (although we can >> handle minor changes with RFC editor notes) >>=20 >> Also, I had some comments a while back to which I do not recall = seeing >> a response: >>=20 >>> -- section 3, Payload Type: "... the VP8 RTP payload profile MUST >>> assign a dynamic payload type number ..." >>>=20 >>> If I read correctly, Colin Perkins objected to this change. Did you >>> consider his objection? > I asked in response if we can delete the whole thing about payload = type > assignment, since it's not a proper concern of the payload type. I did > not get a response, so I thought it couldn=E2=80=99t be important. I thought the question was for others in the working group. My opinion = is that we do need text here, and I proposed something I thought = appropriate, although I=E2=80=99m open to other suggestions. The current = text does need to be changed, however. Colin >>>=20 >>> -- 4.2 >>>=20 >>> I didn't see anything addressing Elwyn's Gen-ART (last call) review >>> question about: =E2=80=9CWhat happens if L=3D1 but both T=3D0 and = K=3D0 so that >>> there is no TID value present? Or indeed if T=3D0 but K=3D1 so that = the >>> TID field is there but 'MUST be ignored by the receiver' = (definition >>> of TID field)?=E2=80=9D Did I miss something? >=20 > On this matter, we thought the text was clear that those streams would > be illegal, and we don't specify the processing of illegal streams. = But > if it isn't clear that it's illegal, we may want to reconsider. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>=20 >> On 10 Sep 2015, at 11:24, Harald Alvestrand wrote: >>=20 >>> On 09/10/2015 03:28 AM, Colin Perkins wrote: >>>>> On 9 Sep 2015, at 23:12, Ben Campbell wrote: >>>>>=20 >>>>> On 9 Sep 2015, at 16:01, Henrik Lundin wrote: >>>>>=20 >>>>>> We have made no technical changes to the document, but have added >>>>>> a number of grammar updates and clarifications. Some of the >>>>>> important clarifications are as follows: >>>>> Payload participants: Please note that there are in fact changes = to >>>>> 2119 language in this version. I won't quibble about whether or = not >>>>> those count as "technical" changes, but please take a moment to >>>>> review them. If people object to any of them please say so asap , >>>>> as this draft will likely be on the agenda for the IESG telechat >>>>> next week. >>>> The new text about the Payload Type in Section 4.1 says: >>>>=20 >>>> Payload type (PT): In line with the policy in Section 3 of >>>> [RFC3551], applications using the VP8 RTP payload profile MUST >>>> assign a dynamic payload type number to be used in each RTP >>>> session and provide a mechanism to indicate the mapping. See >>>> Section 6.2 for the mechanism to be used with the Session >>>> Description Protocol (SDP) [RFC4566]. >>>>=20 >>>> This would be okay, except that RTP profiles that don=E2=80=99t = derive from >>>> RFC 3551 could be defined. A better wording might be: >>>>=20 >>>> Payload Type (PT): The assignment of an RTP payload type for this >>>> packet format is outside the scope of this document and will not be >>>> specified here. It is expected that the RTP profile for a = particular >>>> class of applications will assign a payload type for this encoding, >>>> or if that is not done, then a payload type in the dynamic range >>>> SHALL be chosen by means of an out-of-band signaling protocol. See >>>> Section 6.2 for the mechanism to be used with the Session = Description >>>> Protocol (SDP) [RFC4566]. >>>>=20 >>>>=20 >>>> In Section 4.2, rather than add a note that =E2=80=9Cthis X bit is = not to be >>>> confused with the X bit in the RTP header=E2=80=9D, would it not = make sense >>>> to rename this X bit? >>>=20 >>> We considered this option, but decided that having a large existing = body >>> of documentation outside of the IETF that refers to the "X bit" and >>> having a payload type registration that called it something else, it = ws >>> better to keep the name and just make a note that it's different. >>>=20 >>>> Similarly for the M bit in the extension data fields, and the P bit >>>> in the payload header (which isn=E2=80=99t mentioned). Or, at = least, >>>> annotate each mention of these fields to say which X, M, or P bit = it >>>> required (e.g., =E2=80=9Cthe P bit in the payload header=E2=80=9D = or =E2=80=9Cthe P bit in >>>> the RTP header=E2=80=9D rather than =E2=80=9Cthe P bit=E2=80=9D). >>>=20 >>> This can be done, and probably should be done for any reference that >>> occurs outside of the section describing the VP8 payload descriptor >>> (section 4.2) - I couldn't find any such references. >>>=20 >>> There is no P bit in the VP8 payload descriptor, but there is one in = the >>> VP8 payload header, which is why we missed warning about the name >>> collision there. It's never referred to in text. >>>=20 >>>=20 >>>>=20 >>>> Colin >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>> --=20 >>> Surveillance is pervasive. Go Dark. >>>=20 >>>=20 >>> _______________________________________________ >>> payload mailing list >>> payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >=20 >=20 > --=20 > Surveillance is pervasive. Go Dark. >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload --=20 Colin Perkins https://csperkins.org/ From nobody Tue Sep 22 13:58:07 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9792B1A1B4A for ; Tue, 22 Sep 2015 13:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9t-Yvh33sQTU for ; Tue, 22 Sep 2015 13:58:02 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 455D41B2E3E for ; Tue, 22 Sep 2015 13:57:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 850697C5B44; Tue, 22 Sep 2015 22:57:49 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vqrqG7Yt5n9; Tue, 22 Sep 2015 22:57:47 +0200 (CEST) Received: from [100.81.6.162] (host-95-195-198-162.mobileonline.telia.com [95.195.198.162]) by mork.alvestrand.no (Postfix) with ESMTPSA id 598867C5B40; Tue, 22 Sep 2015 22:57:47 +0200 (CEST) User-Agent: K-9 Mail for Android In-Reply-To: <88518539-9321-4616-A84F-736A1C9D2256@csperkins.org> References: <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> <55F1AEC9.6050408@alvestrand.no> <4D9392D8-4790-41EB-9FC6-B7CC98895E10@nostrum.com> <560190B1.3040400@alvestrand.no> <88518539-9321-4616-A84F-736A1C9D2256@csperkins.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----3AXP5HRDGAEV8G4NKCEDVK7MSOTB24" Content-Transfer-Encoding: 8bit From: Harald Alvestrand Date: Tue, 22 Sep 2015 22:57:45 +0200 To: Colin Perkins Message-ID: <71734E21-F414-42AD-995F-384A8A719D4C@alvestrand.no> Archived-At: Cc: payload@ietf.org Subject: Re: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 20:58:05 -0000 ------3AXP5HRDGAEV8G4NKCEDVK7MSOTB24 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Would you be OK with the shorter version I suggested? Den 22. september 2015 22:51:55 CEST, skrev Colin Perkins : >> On 22 Sep 2015, at 18:32, Harald Alvestrand >wrote: >> >> On 09/22/2015 04:40 PM, Ben Campbell wrote: >>> Hi Harald, >>> >>> I will check with Alissa to see if her concerns have been addressed. >>> >>> Has there been closure on Elwyn's Gen-ART telechat review and on >>> Colin's comments on the payload list? I was under the impression >that >>> at least Colin's comments might result in an update (although we can >>> handle minor changes with RFC editor notes) >>> >>> Also, I had some comments a while back to which I do not recall >seeing >>> a response: >>> >>>> -- section 3, Payload Type: "... the VP8 RTP payload profile MUST >>>> assign a dynamic payload type number ..." >>>> >>>> If I read correctly, Colin Perkins objected to this change. Did you >>>> consider his objection? >> I asked in response if we can delete the whole thing about payload >type >> assignment, since it's not a proper concern of the payload type. I >did >> not get a response, so I thought it couldn’t be important. > >I thought the question was for others in the working group. My opinion >is that we do need text here, and I proposed something I thought >appropriate, although I’m open to other suggestions. The current text >does need to be changed, however. > >Colin > > > > > >>>> >>>> -- 4.2 >>>> >>>> I didn't see anything addressing Elwyn's Gen-ART (last call) review >>>> question about: “What happens if L=1 but both T=0 and K=0 so that >>>> there is no TID value present? Or indeed if T=0 but K=1 so that the >>>> TID field is there but 'MUST be ignored by the receiver' >(definition >>>> of TID field)?” Did I miss something? >> >> On this matter, we thought the text was clear that those streams >would >> be illegal, and we don't specify the processing of illegal streams. >But >> if it isn't clear that it's illegal, we may want to reconsider. >>> >>> Thanks! >>> >>> Ben. >>> >>> >>> On 10 Sep 2015, at 11:24, Harald Alvestrand wrote: >>> >>>> On 09/10/2015 03:28 AM, Colin Perkins wrote: >>>>>> On 9 Sep 2015, at 23:12, Ben Campbell wrote: >>>>>> >>>>>> On 9 Sep 2015, at 16:01, Henrik Lundin wrote: >>>>>> >>>>>>> We have made no technical changes to the document, but have >added >>>>>>> a number of grammar updates and clarifications. Some of the >>>>>>> important clarifications are as follows: >>>>>> Payload participants: Please note that there are in fact changes >to >>>>>> 2119 language in this version. I won't quibble about whether or >not >>>>>> those count as "technical" changes, but please take a moment to >>>>>> review them. If people object to any of them please say so asap , >>>>>> as this draft will likely be on the agenda for the IESG telechat >>>>>> next week. >>>>> The new text about the Payload Type in Section 4.1 says: >>>>> >>>>> Payload type (PT): In line with the policy in Section 3 of >>>>> [RFC3551], applications using the VP8 RTP payload profile MUST >>>>> assign a dynamic payload type number to be used in each RTP >>>>> session and provide a mechanism to indicate the mapping. See >>>>> Section 6.2 for the mechanism to be used with the Session >>>>> Description Protocol (SDP) [RFC4566]. >>>>> >>>>> This would be okay, except that RTP profiles that don’t derive >from >>>>> RFC 3551 could be defined. A better wording might be: >>>>> >>>>> Payload Type (PT): The assignment of an RTP payload type for this >>>>> packet format is outside the scope of this document and will not >be >>>>> specified here. It is expected that the RTP profile for a >particular >>>>> class of applications will assign a payload type for this >encoding, >>>>> or if that is not done, then a payload type in the dynamic range >>>>> SHALL be chosen by means of an out-of-band signaling protocol. See >>>>> Section 6.2 for the mechanism to be used with the Session >Description >>>>> Protocol (SDP) [RFC4566]. >>>>> >>>>> >>>>> In Section 4.2, rather than add a note that “this X bit is not to >be >>>>> confused with the X bit in the RTP header”, would it not make >sense >>>>> to rename this X bit? >>>> >>>> We considered this option, but decided that having a large existing >body >>>> of documentation outside of the IETF that refers to the "X bit" and >>>> having a payload type registration that called it something else, >it ws >>>> better to keep the name and just make a note that it's different. >>>> >>>>> Similarly for the M bit in the extension data fields, and the P >bit >>>>> in the payload header (which isn’t mentioned). Or, at least, >>>>> annotate each mention of these fields to say which X, M, or P bit >it >>>>> required (e.g., “the P bit in the payload header” or “the P bit in >>>>> the RTP header” rather than “the P bit”). >>>> >>>> This can be done, and probably should be done for any reference >that >>>> occurs outside of the section describing the VP8 payload descriptor >>>> (section 4.2) - I couldn't find any such references. >>>> >>>> There is no P bit in the VP8 payload descriptor, but there is one >in the >>>> VP8 payload header, which is why we missed warning about the name >>>> collision there. It's never referred to in text. >>>> >>>> >>>>> >>>>> Colin >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Surveillance is pervasive. Go Dark. >>>> >>>> >>>> _______________________________________________ >>>> payload mailing list >>>> payload@ietf.org >>>> https://www.ietf.org/mailman/listinfo/payload >> >> >> -- >> Surveillance is pervasive. Go Dark. >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > > > >-- >Colin Perkins >https://csperkins.org/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ------3AXP5HRDGAEV8G4NKCEDVK7MSOTB24 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Would you be OK with the shorter version I suggested?

Den 22. september 2015 22:51:55 CEST, skrev Colin Perkins <csp@csperkins.org>:
 On 22 Sep 2015, at 18:32, Harald Alvestrand <harald@alvestrand.no> wrote:
 
 On 09/22/2015 04:40 PM, Ben Campbell wrote:
 Hi Harald,
 
 I will check with Alissa to see if her concerns have been addressed.
 
 Has there been closure on Elwyn's Gen-ART telechat review and on
 Colin's comments on the payload list? I was under the impression that
 at least Colin's comments might result in an update (although we can
 handle minor changes with RFC editor notes)
 
 Also, I had some comments a while back to which I do not recall seeing
 a response:
 
 -- section 3, Payload Type: "... the VP8 RTP payload profile MUST
 assign a dynamic payload type number ..."
 
 If I read correctly, Colin Perkins objected to this change. Did you
 consider his objection?
 I asked in response if we can delete the whole thing about payload type
 assignment, since it's not a proper concern of the payload type. I did
 not get a response, so I thought it couldn’t be important.

I thought the question was for others in the working group. My opinion is that we do need text here, and I proposed something I thought appropriate, although I’m open to other suggestions. The current text does need to be changed, however.

Colin





 
 -- 4.2
 
 I didn't see anything addressing Elwyn's Gen-ART (last call) review
 question about: “What happens if L=1 but both T=0 and K=0 so that
 there is no TID value present? Or indeed if T=0 but K=1 so that the
 TID field is there but 'MUST be ignored by the receiver'  (definition
 of TID field)?” Did I miss something?
 
 On this matter, we thought the text was clear that those streams would
 be illegal, and we don't specify the processing of illegal streams. But
 if it isn't clear that it's illegal, we may want to reconsider.
 
 Thanks!
 
 Ben.
 
 
 On 10 Sep 2015, at 11:24, Harald
Alvestrand wrote:
 
 On 09/10/2015 03:28 AM, Colin Perkins wrote:
 On 9 Sep 2015, at 23:12, Ben Campbell <ben@nostrum.com> wrote:
 
 On 9 Sep 2015, at 16:01, Henrik Lundin wrote:
 
 We have made no technical changes to the document, but have added
 a number of grammar updates and clarifications. Some of the
 important clarifications are as follows:
 Payload participants: Please note that there are in fact changes to
 2119 language in this version. I
won't quibble about whether or not
 those count as "technical" changes, but please take a moment to
 review them. If people object to any of them please say so asap ,
 as this draft will likely be on the agenda for the IESG telechat
 next week.
 The new text about the Payload Type in Section 4.1 says:
 
 Payload type (PT):  In line with the policy in Section 3 of
  [RFC3551], applications using the VP8 RTP payload profile MUST
  assign a dynamic payload type number to be used in each RTP
  session and provide a mechanism to indicate the mapping.  See
  Section 6.2 for the mechanism to be used with the Session
  Description Protocol (SDP) [RFC4566].
 
 This would be okay, except that RTP profiles that don’t derive from
 RFC 3551 could be defined. A better wording might be:
 
 Payload Type (PT): The assignment of an RTP payload type for this
 packet format is outside the scope of
this document and will not be
 specified here.  It is expected that the RTP profile for a particular
 class of applications will assign a payload type for this encoding,
 or if that is not done, then a payload type in the dynamic range
 SHALL be chosen by means of an out-of-band signaling protocol. See
 Section 6.2 for the mechanism to be used with the Session Description
 Protocol (SDP) [RFC4566].
 
 
 In Section 4.2, rather than add a note that “this X bit is not to be
 confused with the X bit in the RTP header”, would it not make sense
 to rename this X bit?
 
 We considered this option, but decided that having a large existing body
 of documentation outside of the IETF that refers to the "X bit" and
 having a payload type registration that called it something else, it ws
 better to keep the name and just make a note that it's different.
 
 Similarly for the M bit in the extension data fields, and the P bit
 in the payload header (which isn’t mentioned). Or, at least,
 annotate each mention of these fields to say which X, M, or P bit it
 required (e.g., “the P bit in the payload header” or “the P bit in
 the RTP header” rather than “the P bit”).
 
 This can be done, and probably should be done for any reference that
 occurs outside of the section describing the VP8 payload descriptor
 (section 4.2) - I couldn't find any such references.
 
 There is no P bit in the VP8 payload descriptor, but there is one in the
 VP8 payload header, which is why we missed warning about the name
 collision there. It's never referred to in text.
 
 
 
 Colin
 
 
 
 
 
 
 
 
 
 -- 
 Surveillance is pervasive. Go Dark.
 
 

 payload mailing list
 payload@ietf.org
 https://www.ietf.org/mailman/listinfo/payload
 
 
 -- 
 Surveillance is pervasive. Go Dark.
 

 payload mailing list
 payload@ietf.org
 https://www.ietf.org/mailman/listinfo/payload



--
Sent from my Android device with K-9 Mail. Please excuse my brevity. ------3AXP5HRDGAEV8G4NKCEDVK7MSOTB24-- From nobody Tue Sep 22 14:01:01 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822641B2E53 for ; Tue, 22 Sep 2015 14:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-wloLYMNhfd for ; Tue, 22 Sep 2015 14:00:56 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907581B2E3E for ; Tue, 22 Sep 2015 14:00:56 -0700 (PDT) Received: from [81.187.2.149] (port=44225 helo=[192.168.0.21]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1ZeUgG-0000gK-G7; Tue, 22 Sep 2015 22:00:54 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_CB6F1A3F-3F42-4FD3-93E6-B98732CD44F4" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Colin Perkins In-Reply-To: <71734E21-F414-42AD-995F-384A8A719D4C@alvestrand.no> Date: Tue, 22 Sep 2015 22:00:42 +0100 Message-Id: <23B4B22E-DC89-4BC0-9F9D-404379C8CA28@csperkins.org> References: <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> <55F1AEC9.6050408@alvestrand.no> <4D9392D8-4790-41EB-9FC6-B7CC98895E10@nostrum.com> <560190B1.3040400@alvestrand.no> <88518539-9321-4616-A84F-736A1C9D2256@csperkins.org> <71734E21-F414-42AD-995F-384A8A719D4C@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.2104) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: payload@ietf.org Subject: Re: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 21:00:59 -0000 --Apple-Mail=_CB6F1A3F-3F42-4FD3-93E6-B98732CD44F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Remind me? > On 22 Sep 2015, at 21:57, Harald Alvestrand = wrote: >=20 > Would you be OK with the shorter version I suggested? >=20 > Den 22. september 2015 22:51:55 CEST, skrev Colin Perkins = : > On 22 Sep 2015, at 18:32, Harald Alvestrand = wrote: > =20 > On 09/22/2015 04:40 PM, Ben Campbell wrote: > Hi Harald, > =20 > I will check with Alissa to see if her concerns have been addressed. > =20 > Has there been closure on Elwyn's Gen-ART telechat review and on > Colin's comments on the payload list? I was under the impression that > at least Colin's comments might result in an update (although we can > handle minor changes with RFC editor notes) > =20 > Also, I had some comments a while back to which I do not recall = seeing > a response: > =20 > -- section 3, Payload Type: "... the VP8 RTP payload profile MUST > assign a dynamic payload type number ..." > =20 > If I read correctly, Colin Perkins objected to this change. Did you > consider his objection? > I asked in response if we can delete the whole thing about payload = type > assignment, since it's not a proper concern of the payload type. I = did > not get a response, so I thought it couldn=E2=80=99t be important. >=20 > I thought the question was for others in the working group. My opinion = is that we do need text here, and I proposed something I thought = appropriate, although I=E2=80=99m open to other suggestions. The current = text does need to be changed, however. >=20 > Colin >=20 >=20 >=20 >=20 >=20 > =20 > -- 4.2 > =20 > I didn't see anything addressing Elwyn's Gen-ART (last call) review > question about: =E2=80=9CWhat happens if L=3D1 but both T=3D0 and K=3D0= so that > there is no TID value present? Or indeed if T=3D0 but K=3D1 so that = the > TID field is there but 'MUST be ignored by the receiver' (definition > of TID field)?=E2=80=9D Did I miss something? > =20 > On this matter, we thought the text was clear that those streams = would > be illegal, and we don't specify the processing of illegal streams. = But > if it isn't clear that it's illegal, we may want to reconsider. > =20 > Thanks! > =20 > Ben. > =20 > =20 > On 10 Sep 2015, at 11:24, Harald > Alvestrand wrote: > =20 > On 09/10/2015 03:28 AM, Colin Perkins wrote: > On 9 Sep 2015, at 23:12, Ben Campbell wrote: > =20 > On 9 Sep 2015, at 16:01, Henrik Lundin wrote: > =20 > We have made no technical changes to the document, but have added > a number of grammar updates and clarifications. Some of the > important clarifications are as follows: > Payload participants: Please note that there are in fact changes to > 2119 language in this version. I > won't quibble about whether or not > those count as "technical" changes, but please take a moment to > review them. If people object to any of them please say so asap , > as this draft will likely be on the agenda for the IESG telechat > next week. > The new text about the Payload Type in Section 4.1 says: > =20 > Payload type (PT): In line with the policy in Section 3 of > [RFC3551], applications using the VP8 RTP payload profile MUST > assign a dynamic payload type number to be used in each RTP > session and provide a mechanism to indicate the mapping. See > Section 6.2 for the mechanism to be used with the Session > Description Protocol (SDP) [RFC4566]. > =20 > This would be okay, except that RTP profiles that don=E2=80=99t = derive from > RFC 3551 could be defined. A better wording might be: > =20 > Payload Type (PT): The assignment of an RTP payload type for this > packet format is outside the scope of > this document and will not be > specified here. It is expected that the RTP profile for a particular > class of applications will assign a payload type for this encoding, > or if that is not done, then a payload type in the dynamic range > SHALL be chosen by means of an out-of-band signaling protocol. See > Section 6.2 for the mechanism to be used with the Session Description > Protocol (SDP) [RFC4566]. > =20 > =20 > In Section 4.2, rather than add a note that =E2=80=9Cthis X bit is = not to be > confused with the X bit in the RTP header=E2=80=9D, would it not make = sense > to rename this X bit? > =20 > We considered this option, but decided that having a large existing = body > of documentation outside of the IETF that refers to the "X bit" and > having a payload type registration that called it something else, it = ws > better to keep the name and just make a note that it's different. > =20 > Similarly for the M bit in the extension data fields, and the P bit > in the payload header (which isn=E2=80=99t mentioned). Or, at least, > annotate each mention of these fields to say which X, M, or P bit it > required (e.g., =E2=80=9Cthe P bit in the payload header=E2=80=9D or = =E2=80=9Cthe P bit in > the RTP header=E2=80=9D rather than =E2=80=9Cthe P bit=E2=80=9D). > =20 > This can be done, and probably should be done for any reference that > occurs outside of the section describing the VP8 payload descriptor > (section 4.2) - I couldn't find any such references. > =20 > There is no P bit in the VP8 payload descriptor, but there is one in = the > VP8 payload header, which is why we missed warning about the name > collision there. It's never referred to in text. > =20 > =20 > =20 > Colin > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > --=20 > Surveillance is pervasive. Go Dark. > =20 > =20 >=20 > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload = > =20 > =20 > --=20 > Surveillance is pervasive. Go Dark. > =20 >=20 > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload = >=20 >=20 >=20 > --=20 > Sent from my Android device with K-9 Mail. Please excuse my brevity. --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_CB6F1A3F-3F42-4FD3-93E6-B98732CD44F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Remind me?

On 22 = Sep 2015, at 21:57, Harald Alvestrand <harald@alvestrand.no> wrote:

Would = you be OK with the shorter version I suggested?

Den 22. september 2015 22:51:55 = CEST, skrev Colin Perkins <csp@csperkins.org>:
 =
On 22 Sep 2015, at 18:32, Harald Alvestrand <harald@alvestrand.no> wrote:
 
 On 09/22/2015 04:40 PM, Ben Campbell wrote:
 Hi =
Harald,
 
 I will check with Alissa to see =
if her concerns have been addressed.
 
 Has =
there been closure on Elwyn's Gen-ART telechat review and on
 Colin's comments on the payload list? I was under the =
impression that
 at least Colin's comments might result in =
an update (although we can
 handle minor changes with RFC =
editor notes)
 
 Also, I had some comments a =
while back to which I do not recall seeing
 a response:
 
 -- section 3, Payload Type: "... the VP8 RTP payload profile =
MUST
 assign a dynamic payload type number ..."
 
 If I read correctly, Colin Perkins objected =
to this change. Did you
 consider his objection?
 I asked in response if we can =
delete the whole thing about payload type
 assignment, =
since it's not a proper concern of the payload type. I did
 =
not get a response, so I thought it couldn=E2=80=99t be important.

I thought the question was for =
others in the working group. My opinion is that we do need text here, =
and I proposed something I thought appropriate, although I=E2=80=99m =
open to other suggestions. The current text does need to be changed, =
however.

Colin





 
 -- 4.2
 
=
 I didn't see anything addressing Elwyn's Gen-ART (last call) review
 question about: =E2=80=9CWhat happens if L=3D1 but both T=3D0 =
and K=3D0 so that
 there is no TID value present? Or =
indeed if T=3D0 but K=3D1 so that the
 TID field is there =
but 'MUST be ignored by the receiver'  (definition
 of TID =
field)?=E2=80=9D Did I miss something?
 
 On this matter, we =
thought the text was clear that those streams would
 be =
illegal, and we don't specify the processing of illegal streams. But
 if it isn't clear that it's illegal, we may want to =
reconsider.
 
 Thanks!
 
 Ben.
 
 
 On 10 =
Sep 2015, at 11:24, Harald
Alvestrand wrote:
 
 On 09/10/2015 03:28 AM, Colin =
Perkins wrote:
 =
On 9 Sep 2015, at 23:12, Ben Campbell <ben@nostrum.com> =
wrote:
 
 On 9 Sep 2015, at 16:01, Henrik =
Lundin wrote:
 
 We have made no technical changes =
to the document, but have added
 a number of grammar =
updates and clarifications. Some of the
 important =
clarifications are as follows:
 Payload =
participants: Please note that there are in fact changes to
=
 2119 language in this version. I
won't quibble about whether or not
 those count as =
"technical" changes, but please take a moment to
 review =
them. If people object to any of them please say so asap ,
 =
as this draft will likely be on the agenda for the IESG telechat
 next week.
 The new text about =
the Payload Type in Section 4.1 says:
 
 =
Payload type (PT):  In line with the policy in Section 3 of
=
  [RFC3551], applications using the VP8 RTP payload profile MUST
  assign a dynamic payload type number to be used in each =
RTP
  session and provide a mechanism to indicate the =
mapping.  See
  Section 6.2 for the mechanism to be used =
with the Session
  Description Protocol (SDP) =
[RFC4566].
 
 This would be okay, except =
that RTP profiles that don=E2=80=99t derive from
 RFC 3551 =
could be defined. A better wording might be:
 
 Payload Type (PT): The assignment of an RTP payload type for =
this
 packet format is outside the scope of
this document and will not be
 specified here.  It is =
expected that the RTP profile for a particular
 class of =
applications will assign a payload type for this encoding,
 =
or if that is not done, then a payload type in the dynamic range
 SHALL be chosen by means of an out-of-band signaling =
protocol. See
 Section 6.2 for the mechanism to be used =
with the Session Description
 Protocol (SDP) [RFC4566].
 
 
 In Section 4.2, rather than =
add a note that =E2=80=9Cthis X bit is not to be
 confused =
with the X bit in the RTP header=E2=80=9D, would it not make sense
 to rename this X bit?
 
 We considered this option, but decided that having a large =
existing body
 of documentation outside of the IETF that =
refers to the "X bit" and
 having a payload type =
registration that called it something else, it ws
 better =
to keep the name and just make a note that it's different.
 =

 =
Similarly for the M bit in the extension data fields, and the P bit
 in the payload header (which isn=E2=80=99t mentioned). Or, =
at least,
 annotate each mention of these fields to say =
which X, M, or P bit it
 required (e.g., =E2=80=9Cthe P =
bit in the payload header=E2=80=9D or =E2=80=9Cthe P bit in
=
 the RTP header=E2=80=9D rather than =E2=80=9Cthe P bit=E2=80=9D).
 
 This can be done, and probably =
should be done for any reference that
 occurs outside of =
the section describing the VP8 payload descriptor
 =
(section 4.2) - I couldn't find any such references.
 
 There is no P bit in the VP8 payload descriptor, but there =
is one in the
 VP8 payload header, which is why we missed =
warning about the name
 collision there. It's never =
referred to in text.
 
 
 
 Colin
 
 =

 
 
 
 
 
 
 
 =
-- 
 Surveillance is pervasive. Go Dark.
 =

 

 payload =
mailing list
 payload@ietf.org
 https://www.ietf.org/mailman/listinfo/payload
 
 
 -- =

 Surveillance is pervasive. Go Dark.
 

 payload mailing list
 payload@ietf.org
 https://www.ietf.org/mailman/listinfo/payload



--
Sent from my Android device with K-9 Mail. Please excuse my = brevity.



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




= --Apple-Mail=_CB6F1A3F-3F42-4FD3-93E6-B98732CD44F4-- From nobody Tue Sep 22 22:41:13 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881241A010C for ; Tue, 22 Sep 2015 22:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6Xex6gpIFYW for ; Tue, 22 Sep 2015 22:41:08 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 49B651A00FF for ; Tue, 22 Sep 2015 22:41:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 71E1E7C566B; Wed, 23 Sep 2015 07:41:07 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNcxuXtajGzt; Wed, 23 Sep 2015 07:41:05 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:fd8f:78e5:30a2:7669]) by mork.alvestrand.no (Postfix) with ESMTPSA id 8F0CD7C425B; Wed, 23 Sep 2015 07:41:05 +0200 (CEST) To: Colin Perkins References: <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> <55F1AEC9.6050408@alvestrand.no> <4D9392D8-4790-41EB-9FC6-B7CC98895E10@nostrum.com> <560190B1.3040400@alvestrand.no> <88518539-9321-4616-A84F-736A1C9D2256@csperkins.org> <71734E21-F414-42AD-995F-384A8A719D4C@alvestrand.no> <23B4B22E-DC89-4BC0-9F9D-404379C8CA28@csperkins.org> From: Harald Alvestrand Message-ID: <56023B71.8080309@alvestrand.no> Date: Wed, 23 Sep 2015 07:41:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <23B4B22E-DC89-4BC0-9F9D-404379C8CA28@csperkins.org> Content-Type: multipart/alternative; boundary="------------030706060000070908050108" Archived-At: Cc: payload@ietf.org Subject: Re: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 05:41:11 -0000 This is a multi-part message in MIME format. --------------030706060000070908050108 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 09/22/2015 11:00 PM, Colin Perkins wrote: > Remind me? Suggested text (suggested in a way that was a bit hard to follow): "Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document and will not be specified here." I'm all for separation of concerns. > >> On 22 Sep 2015, at 21:57, Harald Alvestrand > > wrote: >> >> Would you be OK with the shorter version I suggested? >> >> Den 22. september 2015 22:51:55 CEST, skrev Colin Perkins >> >: >> >> On 22 Sep 2015, at 18:32, Harald Alvestrand >> > wrote: >> On 09/22/2015 04:40 PM, Ben Campbell wrote: >> >> Hi Harald, I will check with Alissa to see if her >> concerns have been addressed. Has there been closure on >> Elwyn's Gen-ART telechat review and on Colin's comments >> on the payload list? I was under the impression that at >> least Colin's comments might result in an update >> (although we can handle minor changes with RFC editor >> notes) Also, I had some comments a while back to which I >> do not recall seeing a response: >> >> -- section 3, Payload Type: "... the VP8 RTP payload >> profile MUST assign a dynamic payload type number >> ..." If I read correctly, Colin Perkins objected to >> this change. Did you consider his objection? >> >> I asked in response if we can delete the whole thing about >> payload type assignment, since it's not a proper concern of >> the payload type. I did not get a response, so I thought it >> couldn’t be important. >> >> >> I thought the question was for others in the working group. My opinion is that we do need text here, and I proposed something I thought appropriate, although I’m open to other suggestions. The current text does need to be changed, however. >> >> Colin >> >> >> >> >> >> -- 4.2 I didn't see anything addressing Elwyn's >> Gen-ART (last call) review question about: “What >> happens if L=1 but both T=0 and K=0 so that there is >> no TID value present? Or indeed if T=0 but K=1 so >> that the TID field is there but 'MUST be ignored by >> the receiver' (definition of TID field)?” Did I miss >> something? >> >> On this matter, we thought the text was clear that those >> streams would be illegal, and we don't specify the processing >> of illegal streams. But if it isn't clear that it's illegal, >> we may want to reconsider. >> >> Thanks! Ben. On 10 Sep 2015, at 11:24, Harald Alvestrand >> wrote: >> >> On 09/10/2015 03:28 AM, Colin Perkins wrote: >> >> On 9 Sep 2015, at 23:12, Ben Campbell >> > >> wrote: On 9 Sep 2015, at 16:01, Henrik Lundin >> wrote: >> >> We have made no technical changes to the >> document, but have added a number of >> grammar updates and clarifications. Some >> of the important clarifications are as >> follows: >> >> Payload participants: Please note that there >> are in fact changes to 2119 language in this >> version. I won't quibble about whether or not >> those count as "technical" changes, but >> please take a moment to review them. If >> people object to any of them please say so >> asap , as this draft will likely be on the >> agenda for the IESG telechat next week. >> >> The new text about the Payload Type in Section >> 4.1 says: Payload type (PT): In line with the >> policy in Section 3 of [RFC3551], applications >> using the VP8 RTP payload profile MUST assign a >> dynamic payload type number to be used in each >> RTP session and provide a mechanism to indicate >> the mapping. See Section 6.2 for the mechanism to >> be used with the Session Description Protocol >> (SDP) [RFC4566]. This would be okay, except that >> RTP profiles that don’t derive from RFC 3551 >> could be defined. A better wording might be: >> Payload Type (PT): The assignment of an RTP >> payload type for this packet format is outside >> the scope of this document and will not be >> specified here. It is expected that the RTP >> profile for a particular class of applications >> will assign a payload type for this encoding, or >> if that is not done, then a payload type in the >> dynamic range SHALL be chosen by means of an >> out-of-band signaling protocol. See Section 6.2 >> for the mechanism to be used with the Session >> Description Protocol (SDP) [RFC4566]. In Section >> 4.2, rather than add a note that “this X bit is >> not to be confused with the X bit in the RTP >> header”, would it not make sense to rename this X >> bit? >> >> We considered this option, but decided that having a >> large existing body of documentation outside of the >> IETF that refers to the "X bit" and having a payload >> type registration that called it something else, it >> ws better to keep the name and just make a note that >> it's different. >> >> Similarly for the M bit in the extension data >> fields, and the P bit in the payload header >> (which isn’t mentioned). Or, at least, annotate >> each mention of these fields to say which X, M, >> or P bit it required (e.g., “the P bit in the >> payload header” or “the P bit in the RTP header” >> rather than “the P bit”). >> >> This can be done, and probably should be done for any >> reference that occurs outside of the section >> describing the VP8 payload descriptor (section 4.2) - >> I couldn't find any such references. There is no P >> bit in the VP8 payload descriptor, but there is one >> in the VP8 payload header, which is why we missed >> warning about the name collision there. It's never >> referred to in text. >> >> Colin >> >> -- Surveillance is pervasive. Go Dark. >> ------------------------------------------------------------------------ >> payload mailing list payload@ietf.org >> >> https://www.ietf.org/mailman/listinfo/payload >> >> -- Surveillance is pervasive. Go Dark. >> ------------------------------------------------------------------------ >> payload mailing list payload@ietf.org >> >> https://www.ietf.org/mailman/listinfo/payload >> >> >> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. > -- > Colin Perkins > https://csperkins.org/ --------------030706060000070908050108 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 09/22/2015 11:00 PM, Colin Perkins wrote:
Remind me?
Suggested text (suggested in a way that was a bit hard to follow):

"Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document and will not be specified here."
I'm all for separation of concerns.

On 22 Sep 2015, at 21:57, Harald Alvestrand <harald@alvestrand.no> wrote:

Would you be OK with the shorter version I suggested?

Den 22. september 2015 22:51:55 CEST, skrev Colin Perkins <csp@csperkins.org>: 
 On 22 Sep 2015, at 18:32, Harald Alvestrand <harald@alvestrand.no> wrote:
 
 On 09/22/2015 04:40 PM, Ben Campbell wrote:

 Hi Harald,
 
 I will check with Alissa to see if her concerns have been addressed.
 
 Has there been closure on Elwyn's Gen-ART telechat review and on
 Colin's comments on the payload list? I was under the impression that
 at least Colin's comments might result in an update (although we can
 handle minor changes with RFC editor notes)
 
 Also, I had some comments a while back to which I do not recall seeing
 a response:
 

 -- section 3, Payload Type: "... the VP8 RTP payload profile MUST
 assign a dynamic payload type number ..."
 
 If I read correctly, Colin Perkins objected to this change. Did you
 consider his objection?

 I asked in response if we can delete the whole thing about payload type
 assignment, since it's not a proper concern of the payload type. I did
 not get a response, so I thought it couldn’t be important.


I thought the question was for others in the working group. My opinion is that we do need text here, and I proposed something I thought appropriate, although I’m open to other suggestions. The current text does need to be changed, however.

Colin






 
 -- 4.2
 
 I didn't see anything addressing Elwyn's Gen-ART (last call) review
 question about: “What happens if L=1 but both T=0 and K=0 so that
 there is no TID value present? Or indeed if T=0 but K=1 so that the
 TID field is there but 'MUST be ignored by the receiver'  (definition
 of TID field)?” Did I miss something?

 
 On this matter, we thought the text was clear that those streams would
 be illegal, and we don't specify the processing of illegal streams. But
 if it isn't clear that it's illegal, we may want to reconsider.

 
 Thanks!
 
 Ben.
 
 
 On 10 Sep 2015, at 11:24, Harald
Alvestrand wrote:
 

 On 09/10/2015 03:28 AM, Colin Perkins wrote:

 On 9 Sep 2015, at 23:12, Ben Campbell <ben@nostrum.com> wrote:
 
 On 9 Sep 2015, at 16:01, Henrik Lundin wrote:
 

 We have made no technical changes to the document, but have added
 a number of grammar updates and clarifications. Some of the
 important clarifications are as follows:

 Payload participants: Please note that there are in fact changes to
 2119 language in this version. I
won't quibble about whether or not
 those count as "technical" changes, but please take a moment to
 review them. If people object to any of them please say so asap ,
 as this draft will likely be on the agenda for the IESG telechat
 next week.

 The new text about the Payload Type in Section 4.1 says:
 
 Payload type (PT):  In line with the policy in Section 3 of
  [RFC3551], applications using the VP8 RTP payload profile MUST
  assign a dynamic payload type number to be used in each RTP
  session and provide a mechanism to indicate the mapping.  See
  Section 6.2 for the mechanism to be used with the Session
  Description Protocol (SDP) [RFC4566].
 
 This would be okay, except that RTP profiles that don’t derive from
 RFC 3551 could be defined. A better wording might be:
 
 Payload Type (PT): The assignment of an RTP payload type for this
 packet format is outside the scope of
this document and will not be
 specified here.  It is expected that the RTP profile for a particular
 class of applications will assign a payload type for this encoding,
 or if that is not done, then a payload type in the dynamic range
 SHALL be chosen by means of an out-of-band signaling protocol. See
 Section 6.2 for the mechanism to be used with the Session Description
 Protocol (SDP) [RFC4566].
 
 
 In Section 4.2, rather than add a note that “this X bit is not to be
 confused with the X bit in the RTP header”, would it not make sense
 to rename this X bit?

 
 We considered this option, but decided that having a large existing body
 of documentation outside of the IETF that refers to the "X bit" and
 having a payload type registration that called it something else, it ws
 better to keep the name and just make a note that it's different.
 

 Similarly for the M bit in the extension data fields, and the P bit
 in the payload header (which isn’t mentioned). Or, at least,
 annotate each mention of these fields to say which X, M, or P bit it
 required (e.g., “the P bit in the payload header” or “the P bit in
 the RTP header” rather than “the P bit”).

 
 This can be done, and probably should be done for any reference that
 occurs outside of the section describing the VP8 payload descriptor
 (section 4.2) - I couldn't find any such references.
 
 There is no P bit in the VP8 payload descriptor, but there is one in the
 VP8 payload header, which is why we missed warning about the name
 collision there. It's never referred to in text.
 
 

 
 Colin
 
 
 
 
 
 
 

 
 
 -- 
 Surveillance is pervasive. Go Dark.
 
 


 payload mailing list
 payload@ietf.org
 https://www.ietf.org/mailman/listinfo/payload

 
 
 -- 
 Surveillance is pervasive. Go Dark.
 


 payload mailing list
 payload@ietf.org
 https://www.ietf.org/mailman/listinfo/payload
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
Colin Perkins
--------------030706060000070908050108-- From nobody Wed Sep 23 00:14:37 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7441A6F7D for ; Wed, 23 Sep 2015 00:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AgnD3pwYAMq for ; Wed, 23 Sep 2015 00:14:35 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4059E1A6F64 for ; Wed, 23 Sep 2015 00:14:30 -0700 (PDT) Received: from [81.187.2.149] (port=41885 helo=[192.168.0.21]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1ZeeG3-000683-4m; Wed, 23 Sep 2015 08:14:27 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Colin Perkins In-Reply-To: <56023B71.8080309@alvestrand.no> Date: Wed, 23 Sep 2015 08:14:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6841FC81-0D81-479F-ACBC-4C56D1C55247@csperkins.org> References: <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> <55F1AEC9.6050408@alvestrand.no> <4D9392D8-4790-41EB-9FC6-B7CC98895E10@nostrum.com> <560190B1.3040400@alvestrand.no> <88518539-9321-4616-A84F-736A1C9D2256@csperkins.org> <71734E21-F414-42AD-995F-384A8A719D4C@alvestrand.no> <23B4B22E-DC89-4BC0-9F9D-404379C8CA28@csperkins.org> <56023B71.8080309@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.2104) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: payload@ietf.org Subject: Re: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 07:14:36 -0000 > On 23 Sep 2015, at 06:41, Harald Alvestrand = wrote: >=20 > On 09/22/2015 11:00 PM, Colin Perkins wrote: >> Remind me? > Suggested text (suggested in a way that was a bit hard to follow): >=20 > "Payload Type (PT): The assignment of an RTP payload type for this = packet format is outside the scope of this document and will not be = specified here." > I=E2=80=99m all for separation of concerns. Yes, that works for me. Colin From nobody Wed Sep 23 00:26:39 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B1F1A00EA for ; Wed, 23 Sep 2015 00:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWs7Qeuko3Eq for ; Wed, 23 Sep 2015 00:26:36 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 066511A00DB for ; Wed, 23 Sep 2015 00:26:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C83A97C5B4C; Wed, 23 Sep 2015 09:26:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egXugdhd39Ia; Wed, 23 Sep 2015 09:26:33 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:fd8f:78e5:30a2:7669]) by mork.alvestrand.no (Postfix) with ESMTPSA id 187317C5A0C; Wed, 23 Sep 2015 09:26:33 +0200 (CEST) To: Colin Perkins References: <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> <55F1AEC9.6050408@alvestrand.no> <4D9392D8-4790-41EB-9FC6-B7CC98895E10@nostrum.com> <560190B1.3040400@alvestrand.no> <88518539-9321-4616-A84F-736A1C9D2256@csperkins.org> <71734E21-F414-42AD-995F-384A8A719D4C@alvestrand.no> <23B4B22E-DC89-4BC0-9F9D-404379C8CA28@csperkins.org> <56023B71.8080309@alvestrand.no> <6841FC81-0D81-479F-ACBC-4C56D1C55247@csperkins.org> From: Harald Alvestrand Message-ID: <56025428.4030106@alvestrand.no> Date: Wed, 23 Sep 2015 09:26:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <6841FC81-0D81-479F-ACBC-4C56D1C55247@csperkins.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: payload@ietf.org Subject: Re: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 07:26:38 -0000 On 09/23/2015 09:14 AM, Colin Perkins wrote: >> On 23 Sep 2015, at 06:41, Harald Alvestrand wrote: >> >> On 09/22/2015 11:00 PM, Colin Perkins wrote: >>> Remind me? >> Suggested text (suggested in a way that was a bit hard to follow): >> >> "Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document and will not be specified here." >> I’m all for separation of concerns. > Yes, that works for me. > > Colin > Ben, based on the set of threads until now - can we publish an updated draft with this single change without revisiting the IESG, or would you prefer to handle this by an RFC Editor note? I don't think there are any other changes that we all agree on are improvements that matter. Harald From nobody Wed Sep 23 05:31:19 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C901B29C6 for ; Wed, 23 Sep 2015 05:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FalFjMk5n_-E for ; Wed, 23 Sep 2015 05:31:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B4B51B29CF for ; Wed, 23 Sep 2015 05:31:16 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8NCUt4i004681 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 23 Sep 2015 07:31:06 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Harald Alvestrand" Date: Wed, 23 Sep 2015 07:30:55 -0500 Message-ID: In-Reply-To: <56025428.4030106@alvestrand.no> References: <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> <55F1AEC9.6050408@alvestrand.no> <4D9392D8-4790-41EB-9FC6-B7CC98895E10@nostrum.com> <560190B1.3040400@alvestrand.no> <88518539-9321-4616-A84F-736A1C9D2256@csperkins.org> <71734E21-F414-42AD-995F-384A8A719D4C@alvestrand.no> <23B4B22E-DC89-4BC0-9F9D-404379C8CA28@csperkins.org> <56023B71.8080309@alvestrand.no> <6841FC81-0D81-479F-ACBC-4C56D1C55247@csperkins.org> <56025428.4030106@alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: Colin Perkins , payload@ietf.org Subject: Re: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 12:31:17 -0000 On 23 Sep 2015, at 2:26, Harald Alvestrand wrote: > On 09/23/2015 09:14 AM, Colin Perkins wrote: >>> On 23 Sep 2015, at 06:41, Harald Alvestrand >>> wrote: >>> >>> On 09/22/2015 11:00 PM, Colin Perkins wrote: >>>> Remind me? >>> Suggested text (suggested in a way that was a bit hard to follow): >>> >>> "Payload Type (PT): The assignment of an RTP payload type for this >>> packet format is outside the scope of this document and will not be >>> specified here." >>> I’m all for separation of concerns. >> Yes, that works for me. >> >> Colin >> > Ben, based on the set of threads until now - can we publish an updated > draft with this single change without revisiting the IESG, or would > you > prefer to handle this by an RFC Editor note? > > I don't think there are any other changes that we all agree on are > improvements that matter. Let's do the RFC Editor note. Do I understand correctly that this replaces the "Payload Type" definition in section 4.1 in it's entirety? That is: OLD: Payload type (PT): In line with the policy in Section 3 of [RFC3551], applications using the VP8 RTP payload profile MUST assign a dynamic payload type number to be used in each RTP session and provide a mechanism to indicate the mapping. See Section 6.2 for the mechanism to be used with the Session Description Protocol (SDP) [RFC4566]. NEW: Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document and will not be specified here." END: Ben. From nobody Wed Sep 23 06:26:07 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC551B2F3D for ; Wed, 23 Sep 2015 06:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulpvZiTKRfhT for ; Wed, 23 Sep 2015 06:26:03 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id F0E731B2E61 for ; Wed, 23 Sep 2015 06:26:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 2F43A7C5B54; Wed, 23 Sep 2015 15:26:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atENO5R0HlEc; Wed, 23 Sep 2015 15:26:01 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:fd8f:78e5:30a2:7669]) by mork.alvestrand.no (Postfix) with ESMTPSA id 777CE7C5B53; Wed, 23 Sep 2015 15:26:01 +0200 (CEST) To: Ben Campbell References: <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> <55F1AEC9.6050408@alvestrand.no> <4D9392D8-4790-41EB-9FC6-B7CC98895E10@nostrum.com> <560190B1.3040400@alvestrand.no> <88518539-9321-4616-A84F-736A1C9D2256@csperkins.org> <71734E21-F414-42AD-995F-384A8A719D4C@alvestrand.no> <23B4B22E-DC89-4BC0-9F9D-404379C8CA28@csperkins.org> <56023B71.8080309@alvestrand.no> <6841FC81-0D81-479F-ACBC-4C56D1C55247@csperkins.org> <56025428.4030106@alvestrand.no> From: Harald Alvestrand Message-ID: <5602A869.2090204@alvestrand.no> Date: Wed, 23 Sep 2015 15:26:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Colin Perkins , payload@ietf.org Subject: Re: [payload] New version of draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 13:26:06 -0000 On 09/23/2015 02:30 PM, Ben Campbell wrote: > On 23 Sep 2015, at 2:26, Harald Alvestrand wrote: > >> On 09/23/2015 09:14 AM, Colin Perkins wrote: >>>> On 23 Sep 2015, at 06:41, Harald Alvestrand >>>> wrote: >>>> >>>> On 09/22/2015 11:00 PM, Colin Perkins wrote: >>>>> Remind me? >>>> Suggested text (suggested in a way that was a bit hard to follow): >>>> >>>> "Payload Type (PT): The assignment of an RTP payload type for this >>>> packet format is outside the scope of this document and will not be >>>> specified here." >>>> I’m all for separation of concerns. >>> Yes, that works for me. >>> >>> Colin >>> >> Ben, based on the set of threads until now - can we publish an updated >> draft with this single change without revisiting the IESG, or would you >> prefer to handle this by an RFC Editor note? >> >> I don't think there are any other changes that we all agree on are >> improvements that matter. > > Let's do the RFC Editor note. > > Do I understand correctly that this replaces the "Payload Type" > definition in section 4.1 in it's entirety? That is: > > OLD: > Payload type (PT): In line with the policy in Section 3 of > [RFC3551], applications using the VP8 RTP payload profile MUST > assign a dynamic payload type number to be used in each RTP > session and provide a mechanism to indicate the mapping. See > Section 6.2 for the mechanism to be used with the Session > Description Protocol (SDP) [RFC4566]. > NEW: > Payload Type (PT): The assignment of an RTP payload type for this packet > format is outside the scope of this document and will not be > specified here." > END: > Yes, that was what I intended to propose. Thanks! From nobody Wed Sep 23 07:16:29 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04711A1EF1; Wed, 23 Sep 2015 07:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzfB2gAULnYK; Wed, 23 Sep 2015 07:16:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB7541A1BD9; Wed, 23 Sep 2015 07:16:26 -0700 (PDT) Received: from [172.20.10.2] (mobile-166-173-060-153.mycingular.net [166.173.60.153]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8NEGGWc015622 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 23 Sep 2015 09:16:22 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-173-060-153.mycingular.net [166.173.60.153] claimed to be [172.20.10.2] From: "Ben Campbell" To: "IESG IESG" Date: Wed, 23 Sep 2015 09:16:11 -0500 Message-ID: MIME-Version: 1.0 X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-payload-vp8.all@ietf.org, payload@ietf.org Subject: [payload] Approved: draft-ietf-payload-vp8-17 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 14:16:28 -0000 Hi IESG Secretary (BCC) draft-ietf-payload-vp8-17 is approved. There is one RFC Editor note. Thanks! Ben. From nobody Wed Sep 23 07:34:29 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CDA1A21C7; Wed, 23 Sep 2015 07:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wy1JQOlY1MHb; Wed, 23 Sep 2015 07:34:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 280C51A6EE9; Wed, 23 Sep 2015 07:34:24 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150923143424.2363.93952.idtracker@ietfa.amsl.com> Date: Wed, 23 Sep 2015 07:34:24 -0700 Archived-At: Cc: payload chair , payload mailing list , RFC Editor Subject: [payload] Protocol Action: 'RTP Payload Format for VP8 Video' to Proposed Standard (draft-ietf-payload-vp8-17.txt) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 14:34:27 -0000 The IESG has approved the following document: - 'RTP Payload Format for VP8 Video' (draft-ietf-payload-vp8-17.txt) as Proposed Standard This document is the product of the Audio/Video Transport Payloads Working Group. The IESG contact persons are Barry Leiba, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ Technical Summary This document specifies the RTP payload format for the VP8 video codec. The VP8 codec supports various applications ranging from low-bitrate peer-to-peer to high-bitrate videoconferencing applications. Working Group Summary The WGLC process was run twice and bunch of comments were addressed in the latest version. After the second WGLC, there were some comments submitted by Cullen Jennings and one of the authors responded in the list. At this time, we are proceeding with publication request. If there are further comments, they can be submitted during the IETF LC. The draft has been through IESG evaluation, and a second IETF last call due to a normative downref. It is going through a second IESG evaluation due to the long time that has passed since the first time. Document Quality The VP8 codec has been used in various applications (most notably by Google). Earlier versions of codec were used by Skype. The media subtype registration review was requested on 11/28/2012. Personnel Ali Begen is the document shepherd. Ben Campbell is the responsible AD. RFC Editor Note Please replace the definition of "Payload Type" definition in section 4.1:: OLD: Payload type (PT): In line with the policy in Section 3 of [RFC3551], applications using the VP8 RTP payload profile MUST assign a dynamic payload type number to be used in each RTP session and provide a mechanism to indicate the mapping. See Section 6.2 for the mechanism to be used with the Session Description Protocol (SDP) [RFC4566]. NEW: Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document and will not be specified here." END From nobody Wed Sep 30 16:17:03 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16651AC444 for ; Wed, 30 Sep 2015 16:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.823 X-Spam-Level: *** X-Spam-Status: No, score=3.823 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_SUMOF=1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQql4g1sA5rS for ; Wed, 30 Sep 2015 16:16:56 -0700 (PDT) Received: from mx0a-00195501.pphosted.com (mx0a-00195501.pphosted.com [67.231.149.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2D5F1AC43B for ; Wed, 30 Sep 2015 16:16:55 -0700 (PDT) Received: from pps.filterd (m0072270.ppops.net [127.0.0.1]) by mx0a-00195501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t8UNDGQX014772; Wed, 30 Sep 2015 16:16:50 -0700 Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0189.outbound.protection.outlook.com [207.46.163.189]) by mx0a-00195501.pphosted.com with ESMTP id 1x8q8u0f8x-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Sep 2015 16:16:50 -0700 Received: from SN1PR05MB1885.namprd05.prod.outlook.com (10.162.131.147) by SN1PR05MB1885.namprd05.prod.outlook.com (10.162.131.147) with Microsoft SMTP Server (TLS) id 15.1.280.20; Wed, 30 Sep 2015 23:16:47 +0000 Received: from SN1PR05MB1885.namprd05.prod.outlook.com ([10.162.131.147]) by SN1PR05MB1885.namprd05.prod.outlook.com ([10.162.131.147]) with mapi id 15.01.0280.017; Wed, 30 Sep 2015 23:16:47 +0000 From: Thomas Edwards To: "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-01.txt Thread-Index: AQHQnmBo2igjoW8PJEmqD+1jgv1L1p2c6owAgLkPfYA= Date: Wed, 30 Sep 2015 23:16:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Edwards@fox.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [216.205.246.229] x-microsoft-exchange-diagnostics: 1; SN1PR05MB1885; 5:P74ebt40mpbNWlXQTgluBT8SZmSg9nWaKE3l+PKHFUPT5A9yMWRYRqhUrNPDIE72LJ1e8p7StU93hHx+N4qibbuQBYr7FO5RIwSRVJrKHS+jR/v/sFuJOpBik5fJSMbF2eZP4q3YMlZih4NUmZhSNA==; 24:7MFFogAFGJWPAdtBwCvSdOP5OTdgXJVx8XTPrnc/0tlfXEHVTBLPtqluHVPqf62BQ8vY45m2NuF+hdmkN3VHYet54snh/eXUEBEUMBWorwM=; 20:3Ewmk/clr7/VRj2I4G8vCwDkgbP/sF5dBxEEwXaNyw4ml/6GByLJVh4ViJMOmgOSJYQYPDUkU17vg4ohlflFvA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR05MB1885; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:SN1PR05MB1885; BCL:0; PCL:0; RULEID:; SRVR:SN1PR05MB1885; x-forefront-prvs: 071518EF63 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(199003)(24454002)(377454003)(189002)(81156007)(97736004)(106356001)(230783001)(86362001)(5001860100001)(15975445007)(36756003)(77096005)(11100500001)(2351001)(99286002)(2950100001)(77156002)(68736005)(62966003)(2900100001)(105586002)(102836002)(16236675004)(5002640100001)(4001350100001)(10400500002)(5004730100002)(189998001)(5001960100002)(110136002)(5007970100001)(66066001)(19580395003)(64706001)(83506001)(19580405001)(92566002)(101416001)(46102003)(50986999)(76176999)(4001540100001)(106116001)(5008740100001)(5001830100001)(40100003)(87936001)(122556002)(2501003)(54356999)(5890100001)(19617315012)(99936001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR05MB1885; H:SN1PR05MB1885.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fox.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_004_D23182C43AD29thomasedwardsfoxcom_" MIME-Version: 1.0 X-OriginatorOrg: fox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2015 23:16:46.6468 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB1885 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-01_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1509300294 Archived-At: Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 23:17:02 -0000 --_004_D23182C43AD29thomasedwardsfoxcom_ Content-Type: multipart/alternative; boundary="_000_D23182C43AD29thomasedwardsfoxcom_" --_000_D23182C43AD29thomasedwardsfoxcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe that Kevin Gross pointed out some important issues in draft-ietf-= payload-rtp-ancillary-01, and I would like to ask the Payload WG to allow m= e to update the I-D to draft-ietf-rtp-ancillary-02. A draft is attached. Also addition to some off-list comments: To "An ANC packet with the header fields Line_Number of 0x7FF and Horizonta= l_Offset of 0xFFF SHALL be considered to be carried without any specific lo= cation within the field or frame" add ", and in such a case the "C" field w= ill be ignored." My replies to Kevin inline starting with "TE>". -Thomas Edwards FOX From: Kevin Gross > Date: Thursday, June 4, 2015 at 3:13 PM To: FNG > Cc: "payload@ietf.org" > Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-01.txt Thomas, I have some additional comments on your draft: Abstract: Consider providing a definition for "KLV" early on TE> I will get rid of "KLV Metadata", as it is a very rare use case. 1 Introduction: Jargon attenuation s/carriage of metadata within the bit stream multiplex of a Serial Digital = Interface/carriage of metadata within the bit stream of a Serial Digital In= terface Payload does not describe s/This RTP payload supports ANC data packets/This memo describes an RTP pay= load which supports ANC data packets Quotes unnecessary s/restored to their "original" locations/restored to their original locatio= ns Other wording improvements s/This payload could be used by itself, or used along with a range of RTP v= ideo formats. In particular, it has been specifically designed so that it c= ould be used/This ANC payload can be used by itself, or used along with a r= ange of RTP video formats. In particular, it has been designed so that it c= ould be used TE> Wording improvements accepted 2.1 Payload Header Definitions Is there a justification you can provide for including Extended Header Sequ= ence Number. Video payload protocols potentially require this because there= may be many packets per video frame. I don't think that's the case for ANC= . What is the maximum realistic rate for ANC data? TE> It depends on what type of ANC data is mapped. There could easily be s= everal hundred ANC packets per frame if embedded audio is carried in RTP. = There can be as much as 563 Mbps of ANC space in 720p50 HD-SDI. I have had= many inconclusive discussions with experts on this, and my intuition is th= at too many bits is better than too few bits when it comes to potential seq= uence number over-run, so I would prefer to leave the extended sequence num= ber in. We need some additional information about the ANC format to complete this d= raft. How do we find the beginning of each ANC packet in the payload? Where= in an ANC packet is the Ancillary Data Flag (ADF)? TE> The Ancillary Data Flag is not present in the payload because it is a p= roperty of an SDI interface involved, and has no bearing on the ANC packet = data. In all digital component interfaces I am aware of it is 000h 3FFh 3F= Fh. I will add "It should be noted that the ancillary data flag (ADF) word= is not specifically carried in this RTP payload. The ADF may be specified= in a document defining an interconnecting digital video interface, otherwi= se a default ADF is specified by SMPTE ST 292-1 [ST292]." Where do DID values come from? TE> "The fields DID, SDID, Data_Count, User_Data_Words, and Checksum_Word r= epresent the 10-bit words carried in the ANC data packet, as per SMPTE ST 2= 91" Based on what I've cleaned from the draft, it seems that we don't need both= Length and ANC_Count. It seems like either would be sufficient to determin= e where payload data stops. You could possibly do without either and use th= e Length field in the UDP header to know when data ends. TE> I prefer the RTP ANC payload parser to know how large the ANC data pack= et payload is without having to refer to higher level network information. = Hopefully that is not an RTP anti-pattern. ANC_Count does not directly te= ll you a size, only the number of ANC packets present, which would have to = be iterated through as ANC packets may have different lengths. It is not clear to me what happens at (next ANC data packet). Is there anot= her DID here or do we get a new Line_Number or something else? We need a be= tter description of what an ANC data packet is. TE> I thought I was being clear with the statement "And for each ANC data p= acket in the payload, the following header fields MUST be present:" but ind= eed I am less clear regarding DID,SDID,etc. I will add "For each ANC data = packet in the payload, immediately after the ANC data packet header fields,= the following data fields MUST be present, with the fields DID, SDID, Dat= a_Count, User_Data_Words, and Checksum_Word representing the 10-bit words c= arried in the ANC data packet, as per SMPTE ST 291-1:" There's something off in Checksum_Word description, "The lower 8 bits of Ch= ecksum_Word, corresponding to bits b8 (MSB) through b0 (LSB) of the 10-bit = data count word". b8 through b0 is 9 bits. TE> Agreed. I will replace with description "It consists of 10 bits, where= bits b8 (MSB) through b0 (LSB) define the checksum value and bit b9 is the= inverse (logical NOT) of bit b8." Kevin Gross - AVA Networks On Wed, Jun 3, 2015 at 6:50 PM, Thomas Edwards > wrote: Based on input from SMPTE members, the following changes were made in the new draft-ietf-payload-rtp-ancillary: 1) Made this explicitly clear: "If more than 255 ANC data packets need to be carried in a field or frame, additional RTP packets carrying ANC data may be sent with the same RTP timestamp but with different sequence numbers." 2) Added a "don't care" value of 0xFFF to Horizontal_Offset to indicate if the ANC data is carried without any specific location within the line. 3) Made this explicitly clear: "An ANC packet with the header fields Line_Number of 0x7FF and Horizontal_Offset of 0xFFF SHALL be considered to be carried without any specific location within the field or frame." 4) Made this explicitly clear: "When reconstructing an SDI signal based on this payload, it is important to place ANC packets into the locations indicated by the ANC payload header fields Line_Number and Horizontal_Offset, and also to follow the requirements of SMPTE ST 291-1 [ST291] Section 7 "Ancillary Data Space Formatting (Component or Composite Interface)", which include rules on the placement of initial ANC data into allowed spaces as well as the contiguity of ANC data packet sequences within those spaces in order to assure that the resulting ANC packets in the SDI signal are valid." 5) A more clear example of multiple DID_SDID parameters in SDP. 6) Minor editorial nits. If there is any concern with these changes, please let me know! -Thomas -- Thomas Edwards VP Engineering & Development FOX Networks Engineering and Operations thomas.edwards@fox.com Phone: +1.310.369.6696 10201 West Pico Blvd. Los Angeles, CA 90035 _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload --_000_D23182C43AD29thomasedwardsfoxcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
I believe that Kevin Gross pointed out some important issues in d= raft-ietf-payload-rtp-ancillary-01, and I would like to ask the Payload WG = to allow me to update the I-D to draft-ietf-rtp-ancillary-02.  A draft= is attached.

Also addition to some off-list comments:

To "An ANC packet with the header fields Line_Number of 0x7FF and= Horizontal_Offset of 0xFFF SHALL be considered to be carried without any s= pecific location within the field or frame" add ", and in such a case the "C" field will be ignored."= ;

My replies to Kevin inline starting with "TE>".

-Thomas Edwards
 FOX

From: Kevin Gross <kevin.gross@avanw.com>
Date: Thursday, June 4, 2015 at 3:1= 3 PM
To: FNG <thomas.edwards@fox.com>
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] I-D Action: = draft-ietf-payload-rtp-ancillary-01.txt

Thomas,

I have some additional comments on your draft:


Abstract:

Consider providing a definition for "KLV" early on

TE> I will get rid of &qu= ot;KLV Metadata", as it is a very rare use case.

1 Introduction:

Jargon attenuation
s/carriage of me= tadata within the bit stream&nbs= p;multiplex of a Serial Digital Interface/carriage of metadata within the bit stream of = a Serial Digital Interface

Payload does not= describe
s/This RTP payload supports AN= C data packets/This mem= o describes an = RTP payload which supports ANC data packets

Quotes unnecessa= ry
s/restored to their "or= iginal" locations/restored to their original= locations

Other wording im= provements
s/This payload could be used b= y itself, or used along with a r= ange of RTP video formats. In particular, it has been specifically d= esigned so that it could be used/This ANC payload can be used by itself, or used along with a r= ange of RTP video formats. In particular, it has been designed so th= at it could be used

TE> Wordin= g improvements accepted

2.1 Payload Head= er Definitions

Is there a justi= fication you can provide for including Extended Header Sequence Number. Vid= eo payload protocols potentially require this because there may be many pac= kets per video frame. I don't think that's the case for ANC. What is the maximum realistic rate for ANC data?<= /span>

TE> It depends on what type of= ANC data is mapped.  There could easily be several hundred ANC packet= s per frame if embedded audio is carried in RTP.  There can be as much= as 563 Mbps of ANC space in 720p50 HD-SDI.  I have had many inconclusive discussions with experts on this, and my intuit= ion is that too many bits is better than too few bits when it comes to pote= ntial sequence number over-run, so I would prefer to leave the extended seq= uence number in.

We need s= ome additional information about the ANC format to complete this draft. How= do we find the beginning of each ANC packet in the payload? Where in an AN= C packet is the Ancillary Data Flag (ADF)?

TE> The Ancillary Data Flag is= not present in the payload because it is a property of an SDI interface in= volved, and has no bearing on the ANC packet data.  In all digital com= ponent interfaces I am aware of it is 000h 3FFh 3FFh.  I will add "It should be noted that the ancil= lary data flag (ADF) word is not specifically carried in this RTP payload. =  The ADF may be specified in a document defining an interconnecting di= gital video interface, otherwise a default ADF is specified by SMPTE ST 292-1 [ST292]."

Where do DID values come from?

TE> "The fields DID, SDID, Data_Count, User_Data_Words, and Chec= ksum_Word represent the 10-bit words carried in the ANC data packet, as per= SMPTE ST 291"

Based on what I'= ve cleaned from the draft, it seems that we don't need both Length and ANC_= Count. It seems like either would be sufficient to determine where payload = data stops. You could possibly do without either and use the Length field in the UDP header to know when dat= a ends.

TE> I prefer the RTP ANC payload parser to know how large the ANC dat= a packet payload is without having to refer to higher level network informa= tion.  Hopefully that is not an RTP anti-pattern.  ANC_Count does= not directly tell you a size, only the number of ANC packets present, which would have to be iterated through as ANC pac= kets may have different lengths.

It is not= clear to me what happens at (next ANC data packet). Is there another DID h= ere or do we get a new Line_Number or something else? We need a better desc= ription of what an ANC data packet is.

TE> I thought I was being clear with the statement "= And for each ANC data packet in the payload, the following header fields MU= ST be present:" but indeed I am less clear regarding DID,SDID,etc.  I will add "For each ANC data packet in the payload, immediately after the ANC data packet head= er fields, the following  data fields MUST be present, with the fields DID, SDID, Data_Count,&nb= sp;User_Data_Words, and = Checksum_Word representing the 10-bit words carried in the ANC data packet, as per SMPTE ST 291-1:"

There's s= omething off in Checksum_Word description, "The lower 8 bits o= f Checksum_Word, corresponding to bits b8 (MSB) through= b0 (LSB) of the 10-bit data count word". b8 through b0 is 9 bits.

TE> Agreed.  I will replace with description "It consists o= f 10 bits, where bits b8 (MSB) through b0 (LSB) define the checksum value a= nd bit b9 is the inverse (logical NOT) of bit b8." 


Kevin Gross - AVA Networks

On Wed, Jun 3, 2015 at 6:50 PM, Thomas Edwards <= span dir=3D"ltr"> <Thomas.Edwa= rds@fox.com> wrote:
Based on input from SMPTE members, the following changes were made in the new draft-ietf-payload-rtp-ancillary:

1) Made this explicitly clear:

"If more than 255 ANC data packets need to be carried in a field or fr= ame,
additional RTP packets carrying ANC data may be sent with the same RTP
timestamp but with different sequence numbers."

2) Added a "don't care" value of 0xFFF to Horizontal_Offset to in= dicate if
the ANC data is carried without any specific location within the line.

3) Made this explicitly clear:

"An ANC packet with the header fields Line_Number of 0x7FF and
Horizontal_Offset of 0xFFF SHALL be considered to be carried without any specific location within the field or frame."

4) Made this explicitly clear:

"When reconstructing an SDI signal based on this payload, it is
important to place ANC packets into the locations indicated by the  &n= bsp; ANC
payload header fields Line_Number and Horizontal_Offset, and also  &nb= sp; to
follow the requirements of SMPTE ST 291-1 [ST291] Section 7    &q= uot;Ancillary
Data Space Formatting (Component or Composite Interface)",   = ; which
include rules on the placement of initial ANC data into allowed   = ; spaces
as well as the contiguity of ANC data packet sequences within    = those
spaces in order to assure that the resulting ANC packets in the   = ; SDI
signal are valid."

5) A more clear example of multiple DID_SDID parameters in SDP.

6) Minor editorial nits.

If there is any concern with these changes, please let me know!

-Thomas

--
Thomas Edwards
VP Engineering & Development
FOX Networks Engineering and Operations
thomas.edwards@fox.com
Phone: +1.= 310.369.6696
10201 West Pico Blvd.
Los Angeles, CA 90035

_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org= /mailman/listinfo/payload

 --_000_D23182C43AD29thomasedwardsfoxcom_-- --_004_D23182C43AD29thomasedwardsfoxcom_ Content-Type: text/plain; name="draft-ietf-payload-rtp-ancillary-02 draft.txt" Content-Description: draft-ietf-payload-rtp-ancillary-02 draft.txt Content-Disposition: attachment; filename="draft-ietf-payload-rtp-ancillary-02 draft.txt"; size=27664; creation-date="Wed, 30 Sep 2015 23:16:46 GMT"; modification-date="Wed, 30 Sep 2015 23:16:46 GMT" Content-ID: Content-Transfer-Encoding: base64 CgoKCkEvViBUcmFuc3BvcnQgUGF5bG9hZHMgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAg ICAgICAgICAgVC4gRWR3YXJkcwpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGT1gKSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgT2N0b2JlciAyMDE1CkV4cGly ZXM6IEFwcmlsIDMsIDIwMTYKCgogICAgICAgICAgICAgIFJUUCBQYXlsb2FkIGZvciBTTVBURSBT VCAyOTEgQW5jaWxsYXJ5IERhdGEKICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1wYXlsb2Fk LXJ0cC1hbmNpbGxhcnktMDIKCkFic3RyYWN0CgogICBUaGlzIG1lbW8gZGVzY3JpYmVzIGFuIFJU UCBQYXlsb2FkIGZvcm1hdCBmb3IgU01QVEUgQW5jaWxsYXJ5IGRhdGEsCiAgIGFzIGRlZmluZWQg YnkgU01QVEUgU1QgMjkxLTEuICBTTVBURSBBbmNpbGxhcnkgZGF0YSBpcyBnZW5lcmFsbHkgdXNl ZAogICBhbG9uZyB3aXRoIHByb2Zlc3Npb25hbCB2aWRlbyBmb3JtYXRzIHRvIGNhcnJ5IGEgcmFu Z2Ugb2YgYW5jaWxsYXJ5CiAgIGRhdGEgdHlwZXMsIGluY2x1ZGluZyB0aW1lIGNvZGUsIENsb3Nl ZCBDYXB0aW9uaW5nLCBhbmQgdGhlIEFjdGl2ZQogICBGb3JtYXQgRGVzY3JpcHRpb24gKEFGRCku CgpTdGF0dXMgb2YgVGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRl ZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFu ZCBCQ1AgNzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRo ZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBv dGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJ bnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQogICBEcmFmdHMg aXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIElu dGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Yg c2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQg Ynkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0 byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRl IHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0 LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEFwcmlsIDMsIDIwMTYuCgpDb3B5cmlnaHQgTm90aWNlCgog ICBDb3B5cmlnaHQgKGMpIDIwMTUgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmll ZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBU aGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExl Z2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKICAgKGh0dHA6Ly90 cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAg IHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3Vt ZW50cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3Ry aWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50 cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVk IEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBU cnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBh cwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgoKCkVkd2FyZHMg ICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAzLCAyMDE2ICAgICAgICAgICAgICAgICBb UGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgIFJUUCBQYXlsb2FkIGZvciBBbmNpbGxhcnkg RGF0YSAgICAgICAgIE9jdG9iZXIgMjAxNQoKClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50 cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDIKICAgICAxLjEuICBSZXF1aXJlbWVudHMgTGFuZ3VhZ2UgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgIDIuICBSVFAgUGF5bG9hZCBGb3JtYXQgZm9yIFNNUFRF IFNUIDI5MSBBbmNpbGxhcnkgRGF0YSAgLiAuIC4gLiAuICAgMwogICAgIDIuMS4gIFBheWxvYWQg SGVhZGVyIERlZmluaXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAg My4gIFBheWxvYWQgRm9ybWF0IFBhcmFtZXRlcnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA3CiAgICAgMy4xLiAgTWVkaWEgVHlwZSBEZWZpbml0aW9uIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOAogICAgIDMuMi4gIE1hcHBpbmcgdG8gU0RQICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDkKICAgICAzLjMuICBP ZmZlci9BbnN3ZXIgTW9kZWwgYW5kIERlY2xhcmF0aXZlIENvbnNpZGVyYXRpb25zIC4gLiAuIC4g IDEwCiAgIDQuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAxMAogICA1LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTAKICAgNi4gIFJlZmVyZW5jZXMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExCiAgICAg Ni4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAxMQogICAgIDYuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTEKICAgQXV0aG9yJ3MgQWRkcmVzcyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyCgoxLiAgSW50cm9kdWN0 aW9uCgogICBUaGlzIG1lbW8gZGVzY3JpYmVzIGFuIFJUUCBQYXlsb2FkIGZvcm1hdCBmb3IgdGhl IFNvY2lldHkgb2YgTW90aW9uCiAgIFBpY3R1cmUgYW5kIFRlbGV2aXNpb24gRW5naW5lZXJzIChT TVBURSkgQW5jaWxsYXJ5IGRhdGEgKEFOQyksIGFzCiAgIGRlZmluZWQgYnkgU01QVEUgU1QgMjkx LTEgW1NUMjkxXS4gIEFOQyBjYW4gY2FycnkgYSByYW5nZSBvZiBkYXRhCiAgIHR5cGVzLCBpbmNs dWRpbmcgdGltZSBjb2RlLCBDbG9zZWQgQ2FwdGlvbmluZywgYW5kIHRoZSBBY3RpdmUgRm9ybWF0 CiAgIERlc2NyaXB0aW9uIChBRkQpLgoKICAgQU5DIGlzIGdlbmVyYWxseSBhc3NvY2lhdGVkIHdp dGggdGhlIGNhcnJpYWdlIG9mIG1ldGFkYXRhIHdpdGhpbiB0aGUKICAgYml0IHN0cmVhbSBvZiBh IFNlcmlhbCBEaWdpdGFsIEludGVyZmFjZSAoU0RJKSBzdWNoIGFzIFNNUFRFIFNUIDI1OQogICBb U1QyNTldLCB0aGUgc3RhbmRhcmQgZGVmaW5pdGlvbiAoU0QpIFNlcmlhbCBEaWdpdGFsIEludGVy ZmFjZSAod2l0aAogICBBTkMgZGF0YSBpbnNlcnRlZCBhcyBwZXIgU01QVEUgU1QgMTI1IFtTVDEy NV0pLCBvciBTTVBURSBTVCAyOTItMQogICBbU1QyOTJdLCB0aGUgMS41IEdiL3MgU2VyaWFsIERp Z2l0YWwgSW50ZXJmYWNlIGZvciBoaWdoIGRlZmluaXRpb24KICAgKEhEKSB0ZWxldmlzaW9uIGFw cGxpY2F0aW9ucy4KCiAgIEFOQyBkYXRhIHBhY2tldCBwYXlsb2FkIGRlZmluaXRpb25zIGZvciBh IHNwZWNpZmljIGFwcGxpY2F0aW9uIGFyZQogICBzcGVjaWZpZWQgYnkgYSBTTVBURSBTdGFuZGFy ZCwgUmVjb21tZW5kZWQgUHJhY3RpY2UsIFJlZ2lzdGVyZWQKICAgRGlzY2xvc3VyZSBEb2N1bWVu dCwgb3IgYnkgYSBkb2N1bWVudCBnZW5lcmF0ZWQgYnkgYW5vdGhlcgogICBvcmdhbml6YXRpb24s IGEgY29tcGFueSwgb3IgYW4gaW5kaXZpZHVhbCAoYW4gRW50aXR5KS4gIFdoZW4gYQogICBwYXls b2FkIGZvcm1hdCBpcyByZWdpc3RlcmVkIHdpdGggU01QVEUsIGFuIGFwcGxpY2F0aW9uIGRvY3Vt ZW50CiAgIGRlc2NyaWJpbmcgdGhlIHBheWxvYWQgZm9ybWF0IGlzIHJlcXVpcmVkLCBhbmQgdGhl IHJlZ2lzdGVyZWQKICAgYW5jaWxsYXJ5IGRhdGEgcGFja2V0IGlzIGlkZW50aWZpZWQgYnkgYSBy ZWdpc3RlcmVkIGRhdGEKICAgaWRlbnRpZmljYXRpb24gd29yZC4KCiAgIFRoaXMgbWVtbyBkZXNj cmliZXMgYW4gUlRQIHBheWxvYWQgdGhhdCBzdXBwb3J0cyBBTkMgZGF0YSBwYWNrZXRzCiAgIHJl Z2FyZGxlc3Mgb2Ygd2hldGhlciB0aGV5IG9yaWdpbmF0ZSBmcm9tIGFuIFNEIG9yIEhEIGludGVy ZmFjZSwgb3IKICAgaWYgdGhlIEFOQyBkYXRhIHBhY2tldCBpcyBmcm9tIHRoZSB2ZXJ0aWNhbCBh bmNpbGxhcnkgc3BhY2UgKFZBTkMpIG9yCiAgIHRoZSBob3Jpem9udGFsIGFuY2lsbGFyeSBzcGFj ZSAoSEFOQyksIG9yIGlmIHRoZSBBTkMgcGFja2V0IGlzCiAgIGxvY2F0ZWQgaW4gdGhlIGx1bWEg KFkpIG9yIGNvbG9yLWRpZmZlcmVuY2UgKEMpIGNoYW5uZWwuICBTdWZmaWNpZW50CiAgIGluZm9y bWF0aW9uIGlzIHByb3ZpZGVkIHRvIGVuYWJsZSB0aGUgQU5DIHBhY2tldHMgYXQgdGhlIG91dHB1 dCBvZgoKCgoKRWR3YXJkcyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDMsIDIwMTYg ICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgUlRQIFBheWxv YWQgZm9yIEFuY2lsbGFyeSBEYXRhICAgICAgICAgT2N0b2JlciAyMDE1CgoKICAgdGhlIGRlY29k ZXIgdG8gYmUgcmVzdG9yZWQgdG8gdGhlaXIgb3JpZ2luYWwgbG9jYXRpb25zIGluIHRoZSBzZXJp YWwKICAgZGlnaXRhbCB2aWRlbyBzaWduYWwgcmFzdGVyIChpZiB0aGF0IGlzIGRlc2lyZWQpLgoK ICAgSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgdGhlIGFuY2lsbGFyeSBkYXRhIGZsYWcgKEFERikg d29yZCBpcyBub3QKICAgc3BlY2lmaWNhbGx5IGNhcnJpZWQgaW4gdGhpcyBSVFAgcGF5bG9hZC4g IFRoZSBBREYgbWF5IGJlIHNwZWNpZmllZAogICBpbiBhIGRvY3VtZW50IGRlZmluaW5nIGFuIGlu dGVyY29ubmVjdGluZyBkaWdpdGFsIHZpZGVvIGludGVyZmFjZSwKICAgb3RoZXJ3aXNlIGEgZGVm YXVsdCBBREYgaXMgc3BlY2lmaWVkIGJ5IFNNUFRFIFNUIDI5MS0xIFtTVDI5MV0uCgogICBUaGlz IEFOQyBwYXlsb2FkIGNhbiBiZSB1c2VkIGJ5IGl0c2VsZiwgb3IgdXNlZCBhbG9uZyB3aXRoIGEg cmFuZ2Ugb2YKICAgUlRQIHZpZGVvIGZvcm1hdHMuICBJbiBwYXJ0aWN1bGFyLCBpdCBoYXMgYmVl biBkZXNpZ25lZCBzbyB0aGF0IGl0CiAgIGNvdWxkIGJlIHVzZWQgYWxvbmcgd2l0aCBSRkMgNDE3 NSBbUkZDNDE3NV0gIlJUUCBQYXlsb2FkIEZvcm1hdCBmb3IKICAgVW5jb21wcmVzc2VkIFZpZGVv IiBvciBSRkMgNTM3MSBbUkZDNTM3MV0gIlJUUCBQYXlsb2FkIEZvcm1hdCBmb3IKICAgSlBFRyAy MDAwIFZpZGVvIFN0cmVhbXMuIgoKICAgVGhlIGRhdGEgbW9kZWwgaW4gdGhpcyBkb2N1bWVudCBm b3IgdGhlIEFOQyBkYXRhIFJUUCBwYXlsb2FkIGlzIGJhc2VkCiAgIG9uIHRoZSBkYXRhIG1vZGVs IG9mIFNNUFRFIFNUIDIwMzggW1NUMjAzOF0sIHdoaWNoIHN0YW5kYXJkaXplcyB0aGUKICAgY2Fy cmlhZ2Ugb2YgQU5DIGRhdGEgcGFja2V0cyBpbiBhbiBNUEVHLTIgVHJhbnNwb3J0IFN0cmVhbS4K CjEuMS4gIFJlcXVpcmVtZW50cyBMYW5ndWFnZQoKICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJN VVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAiU0hPVUxEIiwg IlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhp cwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAy MTE5IFtSRkMyMTE5XS4KCjIuICBSVFAgUGF5bG9hZCBGb3JtYXQgZm9yIFNNUFRFIFNUIDI5MSBB bmNpbGxhcnkgRGF0YQoKICAgVGhlIGZvcm1hdCBvZiBhbiBSVFAgcGFja2V0IGNvbnRhaW5pbmcg U01QVEUgU1QgMjkxIEFuY2lsbGFyeSBEYXRhIGlzCiAgIHNob3duIGJlbG93OgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCkVkd2FyZHMgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAzLCAy MDE2ICAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAgIFJUUCBQ YXlsb2FkIGZvciBBbmNpbGxhcnkgRGF0YSAgICAgICAgIE9jdG9iZXIgMjAxNQoKCiAgICAgMCAg ICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAg MwogICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgfFY9MnxQfFh8IENDICAgIHxNfCAgICBQ VCAgICAgICB8ICAgICAgICBzZXF1ZW5jZSBudW1iZXIgICAgICAgIHwKICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwog ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB0aW1lc3RhbXAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8CiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICB8ICAgICAgICAgICBzeW5jaHJvbml6YXRp b24gc291cmNlIChTU1JDKSBpZGVudGlmaWVyICAgICAgICAgICAgfAogICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAg ICAgfCAgIEV4dGVuZGVkIFNlcXVlbmNlIE51bWJlciAgICB8ICAgICAgICAgICAgTGVuZ3RoICAg ICAgICAgICAgIHwKICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgIHwgQU5DX0NvdW50ICAgICB8Q3wgICBMaW5l X051bWJlciAgICAgICB8ICAgSG9yaXpvbnRhbF9PZmZzZXQgICB8CiAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAg ICB8ICAgICAgICBESUQgICAgICAgIHwgICAgICAgIFNESUQgICAgICAgfCAgIERhdGFfQ291bnQg ICAgICB8IFIgfAogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICBVc2VyX0RhdGFfV29yZHMuLi4KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgIHwgICBDaGVja3N1bV9Xb3Jk ICAgfG9jdGV0X2FsaWdufCAgICAobmV4dCBBTkMgZGF0YSBwYWNrZXQpLi4uCiAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsKCgogICAgICAgICAgICAgRmlndXJlIDE6IFNNUFRFIEFuY2lsbGFyeSBEYXRhIFJUUCBQYWNr ZXQgRm9ybWF0CgogICBSVFAgcGFja2V0IGhlYWRlciBmaWVsZHMgU0hBTEwgYmUgaW50ZXJwcmV0 ZWQgYXMgcGVyIFJGQyAzNTUwCiAgIFtSRkMzNTUwXSwgd2l0aCB0aGUgZm9sbG93aW5nIHNwZWNp ZmljczoKCiAgIFRpbWVzdGFtcDogMzIgYml0cwogICAgICAgICAgIFRoZSB0aW1lc3RhbXAgZmll bGQgaXMgaW50ZXJwcmV0ZWQgaW4gYSBzaW1pbGFyIGZhc2hpb24gdG8KICAgICAgICAgICBSRkMg NDE3NSBbUkZDNDE3NV06CgogICAgICAgICAgIEZvciBwcm9ncmVzc2l2ZSBzY2FuIHZpZGVvLCB0 aGUgdGltZXN0YW1wIFNIQUxMIGRlbm90ZSB0aGUKICAgICAgICAgICBzYW1wbGluZyBpbnN0YW50 IG9mIHRoZSBmcmFtZSB0byB3aGljaCB0aGUgYW5jaWxsYXJ5IGRhdGEgaW4KICAgICAgICAgICB0 aGUgUlRQIHBhY2tldCBiZWxvbmdzLiAgUGFja2V0cyBNVVNUIE5PVCBpbmNsdWRlIEFOQyBkYXRh CiAgICAgICAgICAgZnJvbSBtdWx0aXBsZSBmcmFtZXMsIGFuZCBhbGwgcGFja2V0cyB3aXRoIEFO QyBkYXRhIGJlbG9uZ2luZwogICAgICAgICAgIHRvIHRoZSBzYW1lIGZyYW1lIE1VU1QgaGF2ZSB0 aGUgc2FtZSB0aW1lc3RhbXAuCgogICAgICAgICAgIEZvciBpbnRlcmxhY2VkIHZpZGVvLCB0aGUg dGltZXN0YW1wIFNIQUxMIGRlbm90ZSB0aGUgc2FtcGxpbmcKICAgICAgICAgICBpbnN0YW50IG9m IHRoZSBmaWVsZCB0byB3aGljaCB0aGUgYW5jaWxsYXJ5IGRhdGEgaW4gdGhlIFJUUAogICAgICAg ICAgIHBhY2tldCBiZWxvbmdzLiAgUGFja2V0cyBNVVNUIE5PVCBpbmNsdWRlIEFOQyBkYXRhIGZy b20KICAgICAgICAgICBtdWx0aXBsZSBmaWVsZHMsIGFuZCBhbGwgcGFja2V0cyBiZWxvbmdpbmcg dG8gdGhlIHNhbWUgZmllbGQKICAgICAgICAgICBNVVNUIGhhdmUgdGhlIHNhbWUgdGltZXN0YW1w LgoKICAgICAgICAgICBBIDkwLWtIeiB0aW1lc3RhbXAgU0hPVUxEIGJlIHVzZWQgaW4gYm90aCBj YXNlcy4gIElmIHRoZQogICAgICAgICAgIHNhbXBsaW5nIGluc3RhbnQgZG9lcyBub3QgY29ycmVz cG9uZCB0byBhbiBpbnRlZ2VyIHZhbHVlIG9mCiAgICAgICAgICAgdGhlIGNsb2NrLCB0aGUgdmFs dWUgU0hBTEwgYmUgdHJ1bmNhdGVkIHRvIHRoZSBuZXh0IGxvd2VzdAogICAgICAgICAgIGludGVn ZXIsIHdpdGggbm8gYW1iaWd1aXR5LgoKICAgTWFya2VyIGJpdCAoTSk6IDEgYml0CgoKCkVkd2Fy ZHMgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAzLCAyMDE2ICAgICAgICAgICAgICAg ICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgIFJUUCBQYXlsb2FkIGZvciBBbmNpbGxh cnkgRGF0YSAgICAgICAgIE9jdG9iZXIgMjAxNQoKCiAgICAgICAgICAgVGhlIG1hcmtlciBiaXQg c2V0IHRvICIxIiBTSEFMTCBpbmRpY2F0ZSB0aGUgbGFzdCBSVFAgcGFja2V0CiAgICAgICAgICAg Y29udGFpbmluZyBBTkMgZGF0YSBmb3IgYSBmcmFtZSAoZm9yIHByb2dyZXNzaXZlIHNjYW4gdmlk ZW8pCiAgICAgICAgICAgb3IgdGhlIGxhc3QgUlRQIHBhY2tldCBjb250YWluaW5nIEFOQyBkYXRh IGZvciBhIGZpZWxkIChmb3IKICAgICAgICAgICBpbnRlcmxhY2VkIHZpZGVvKS4KCjIuMS4gIFBh eWxvYWQgSGVhZGVyIERlZmluaXRpb25zCgogICBUaGUgQU5DIFJUUCBwYXlsb2FkIGhlYWRlciBm aWVsZHMgYXJlIGRlZmluZWQgYXM6CgogICBFeHRlbmRlZCBTZXF1ZW5jZSBOdW1iZXI6IDE2IGJp dHMKICAgICAgICAgICBUaGUgaGlnaCBvcmRlciBiaXRzIG9mIHRoZSBleHRlbmRlZCAzMi1iaXQg c2VxdWVuY2UgbnVtYmVyLAogICAgICAgICAgIGluIG5ldHdvcmsgYnl0ZSBvcmRlci4gIFRoaXMg aXMgdGhlIHNhbWUgYXMgdGhlIEV4dGVuZGVkCiAgICAgICAgICAgU2VxdWVuY2UgTnVtYmVyIGZp ZWxkIGluIFJGQyA0MTc1IFtSRkM0MTc1XS4KCiAgIExlbmd0aDogMTYgYml0cwogICAgICAgICAg IE51bWJlciBvZiBvY3RldHMgb2YgdGhlIEFOQyBSVFAgcGF5bG9hZCwgYmVnaW5uaW5nIHdpdGgg dGhlCiAgICAgICAgICAgIkMiIGJpdCBvZiB0aGUgZmlyc3QgQU5DIHBhY2tldCBkYXRhLgoKICAg QU5DX0NvdW50OiA4IGJpdHMKICAgICAgICAgICBUaGlzIGZpZWxkIGlzIHRoZSBjb3VudCBvZiB0 aGUgdG90YWwgbnVtYmVyIG9mIEFOQyBkYXRhCiAgICAgICAgICAgcGFja2V0cyBjYXJyaWVkIGlu IHRoZSBSVFAgcGF5bG9hZC4gIEEgc2luZ2xlIEFOQyBSVFAgcGFja2V0CiAgICAgICAgICAgcGF5 bG9hZCBTSEFMTCBOT1QgY2FycnkgbW9yZSB0aGFuIDI1NSBBTkMgZGF0YSBwYWNrZXRzLgogICAg ICAgICAgIElmIG1vcmUgdGhhbiAyNTUgQU5DIGRhdGEgcGFja2V0cyBuZWVkIHRvIGJlIGNhcnJp ZWQgaW4gYQogICAgICAgICAgIGZpZWxkIG9yIGZyYW1lLCBhZGRpdGlvbmFsIFJUUCBwYWNrZXRz IGNhcnJ5aW5nIEFOQyBkYXRhIG1heQogICAgICAgICAgIGJlIHNlbnQgd2l0aCB0aGUgc2FtZSBS VFAgdGltZXN0YW1wIGJ1dCB3aXRoIGRpZmZlcmVudAogICAgICAgICAgIHNlcXVlbmNlIG51bWJl cnMuCgogICBGb3IgZWFjaCBBTkMgZGF0YSBwYWNrZXQgaW4gdGhlIHBheWxvYWQsIHRoZSBmb2xs b3dpbmcgQU5DIGRhdGEKICAgcGFja2V0IGhlYWRlciBmaWVsZHMgTVVTVCBiZSBwcmVzZW50OgoK ICAgQzogMSBiaXQKICAgICAgICAgICBGb3IgSEQgc2lnbmFscywgdGhpcyBmbGFnLCB3aGVuIHNl dCB0byAiMSIsIGluZGljYXRlcyB0aGF0CiAgICAgICAgICAgdGhlIEFOQyBkYXRhIGNvcnJlc3Bv bmRzIHRvIHRoZSBjb2xvci1kaWZmZXJlbmNlIGNoYW5uZWwgKEMpLgogICAgICAgICAgIFdoZW4g c2V0IHRvICIwIiwgdGhpcyBmbGFnIGluZGljYXRlcyB0aGF0IHRoZSBBTkMgZGF0YQogICAgICAg ICAgIGNvcnJlc3BvbmRzIHRvIHRoZSBsdW1hIChZKSBjaGFubmVsLiAgRm9yIFNEIHNpZ25hbHMs IHRoaXMKICAgICAgICAgICBmbGFnIFNIQUxMIGJlIHNldCB0byAiMCIuCgogICBMaW5lX051bWJl cjogMTEgYml0cwogICAgICAgICAgIFRoaXMgZmllbGQgY29udGFpbnMgdGhlIGxpbmUgbnVtYmVy IChhcyBkZWZpbmVkIGluIElUVS1SCiAgICAgICAgICAgQlQuMTcwMCBbQlQxNzAwXSBmb3IgU0Qg dmlkZW8gb3IgSVRVLVIgQlQuMTEyMCBbQlQxMTIwXSBmb3IKICAgICAgICAgICBIRCB2aWRlbykg dGhhdCBjb3JyZXNwb25kcyB0byB0aGUgbG9jYXRpb24gb2YgdGhlIEFOQyBkYXRhCiAgICAgICAg ICAgcGFja2V0LiAgQSB2YWx1ZSBvZiAweDdGRiAoYWxsIGJpdHMgaW4gdGhlIGZpZWxkIGFyZSAn MScpCiAgICAgICAgICAgU0hBTEwgaW5kaWNhdGUgdGhhdCB0aGUgQU5DIGRhdGEgaXMgY2Fycmll ZCB3aXRob3V0IGEKICAgICAgICAgICBzcGVjaWZpYyBsaW5lIGxvY2F0aW9uIHdpdGhpbiB0aGUg ZmllbGQgb3IgZnJhbWUuCgogICAgICAgICAgIE5vdGUgdGhhdCB0aGUgbGluZXMgdGhhdCBhcmUg YXZhaWxhYmxlIHRvIGNvbnZleSBBTkMgZGF0YSBhcmUKICAgICAgICAgICBhcyBkZWZpbmVkIGlu IHRoZSBhcHBsaWNhYmxlIHNhbXBsZSBzdHJ1Y3R1cmUgc3BlY2lmaWNhdGlvbgogICAgICAgICAg IChlLmcuLCBTTVBURSAyNzRNIFtTVDI3NF0sIFNNUFRFIFNUIDI5NiBbU1QyOTZdLCBJVFUtUiBC VC42NTYKCgoKRWR3YXJkcyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDMsIDIwMTYg ICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgUlRQIFBheWxv YWQgZm9yIEFuY2lsbGFyeSBEYXRhICAgICAgICAgT2N0b2JlciAyMDE1CgoKICAgICAgICAgICBb QlQ2NTZdKSBhbmQgbWF5IGJlIGZ1cnRoZXIgcmVzdHJpY3RlZCBwZXIgU01QVEUgUlAgMTY4CiAg ICAgICAgICAgW1JQMTY4XS4KCiAgIEhvcml6b250YWxfT2Zmc2V0OiAxMiBiaXRzCiAgICAgICAg ICAgVGhpcyBmaWVsZCBkZWZpbmVzIHRoZSBsb2NhdGlvbiBvZiB0aGUgQU5DIHBhY2tldCByZWxh dGl2ZSB0bwogICAgICAgICAgIHRoZSBzdGFydCBvZiBhY3RpdmUgdmlkZW8gKFNBVikuICBBIHZh bHVlIG9mIDAgbWVhbnMgdGhhdCB0aGUKICAgICAgICAgICBBbmNpbGxhcnkgRGF0YSBGbGFnIChB REYpIG9mIHRoZSBBTkMgcGFja2V0IGJlZ2lucwogICAgICAgICAgIGltbWVkaWF0ZWx5IGZvbGxv d2luZyBTQVYuICBGb3IgSEQsIHRoaXMgU0hBTEwgYmUgaW4gdW5pdHMgb2YKICAgICAgICAgICBs dW1hIHNhbXBsZSBudW1iZXJzIGFzIHNwZWNpZmllZCBieSB0aGUgZGVmaW5pbmcgZG9jdW1lbnQg b2YKICAgICAgICAgICB0aGUgcGFydGljdWxhciBpbWFnZSAoZS5nLiwgU01QVEUgMjc0TSBbU1Qy NzRdIGZvciAxOTIwIHgKICAgICAgICAgICAxMDgwIGFjdGl2ZSBpbWFnZXMsIG9yIFNNUFRFIFNU IDI5NiBbU1QyOTZdIGZvciAxMjgwIHggNzIwCiAgICAgICAgICAgcHJvZ3Jlc3NpdmUgYWN0aXZl IGltYWdlcykuICBGb3IgU0QsIHRoaXMgU0hBTEwgYmUgaW4gdW5pdHMKICAgICAgICAgICBvZiAo MjdNSHopIG11bHRpcGxleGVkIHdvcmQgbnVtYmVycywgYXMgc3BlY2lmaWVkIGluIFNNUFRFIFNU CiAgICAgICAgICAgMTI1IFtTVDEyNV0uICBBIHZhbHVlIG9mIDB4RkZGIChhbGwgYml0cyBpbiB0 aGUgZmllbGQgYXJlCiAgICAgICAgICAgJzEnKSBTSEFMTCBpbmRpY2F0ZSB0aGF0IHRoZSBBTkMg ZGF0YSBpcyBjYXJyaWVkIHdpdGhvdXQgYW55CiAgICAgICAgICAgc3BlY2lmaWMgbG9jYXRpb24g d2l0aGluIHRoZSBsaW5lLgoKICAgICAgICAgICBOb3RlIHRoYXQgSEFOQyBzcGFjZSBpbiB0aGUg ZGlnaXRhbCBibGFua2luZyBhcmVhIHdpbGwKICAgICAgICAgICBnZW5lcmFsbHkgaGF2ZSBoaWdo ZXIgbHVtYSBzYW1wbGUgbnVtYmVycyB0aGFuIGFueSBzYW1wbGVzIGluCiAgICAgICAgICAgdGhl IGFjdGl2ZSBkaWdpdGFsIGxpbmUuCgogICBBbiBBTkMgcGFja2V0IHdpdGggdGhlIGhlYWRlciBm aWVsZHMgTGluZV9OdW1iZXIgb2YgMHg3RkYgYW5kCiAgIEhvcml6b250YWxfT2Zmc2V0IG9mIDB4 RkZGIFNIQUxMIGJlIGNvbnNpZGVyZWQgdG8gYmUgY2FycmllZCB3aXRob3V0CiAgIGFueSBzcGVj aWZpYyBsb2NhdGlvbiB3aXRoaW4gdGhlIGZpZWxkIG9yIGZyYW1lLCBhbmQgaW4gc3VjaCBhIGNh c2UKICAgdGhlICJDIiBmaWVsZCB3aWxsIGJlIGlnbm9yZWQuCgogICBGb3IgZWFjaCBBTkMgZGF0 YSBwYWNrZXQgaW4gdGhlIHBheWxvYWQsIGltbWVkaWF0ZWx5IGFmdGVyIHRoZSBBTkMKICAgZGF0 YSBwYWNrZXQgaGVhZGVyIGZpZWxkcywgdGhlIGZvbGxvd2luZyBkYXRhIGZpZWxkcyBNVVNUIGJl IHByZXNlbnQsCiAgIHdpdGggdGhlIGZpZWxkcyBESUQsIFNESUQsIERhdGFfQ291bnQsIFVzZXJf RGF0YV9Xb3JkcywgYW5kCiAgIENoZWNrc3VtX1dvcmQgcmVwcmVzZW50aW5nIHRoZSAxMC1iaXQg d29yZHMgY2FycmllZCBpbiB0aGUgQU5DIGRhdGEKICAgcGFja2V0LCBhcyBwZXIgU01QVEUgU1Qg MjkxLTEgW1NUMjkxXToKCiAgIERJRDogMTAgYml0cwogICAgICAgICAgIERhdGEgSWRlbnRpZmlj YXRpb24gV29yZAoKICAgU0RJRDogMTAgYml0cwogICAgICAgICAgIFNlY29uZGFyeSBEYXRhIElk ZW50aWZpY2F0aW9uIFdvcmQuICBVc2VkIG9ubHkgZm9yIGEgIlR5cGUgMiIKICAgICAgICAgICBB TkMgZGF0YSBwYWNrZXQuICBOb3RlIHRoYXQgaW4gYSAiVHlwZSAxIiBBTkMgZGF0YSBwYWNrZXQs CiAgICAgICAgICAgdGhpcyB3b3JkIHdpbGwgYWN0dWFsbHkgY2FycnkgdGhlIERhdGEgQmxvY2sg TnVtYmVyIChEQk4pLgoKICAgRGF0YV9Db3VudDogMTAgYml0cwogICAgICAgICAgIFRoZSBsb3dl ciA4IGJpdHMgb2YgRGF0YV9Db3VudCwgY29ycmVzcG9uZGluZyB0byBiaXRzIGI3CiAgICAgICAg ICAgKE1TQikgdGhyb3VnaCBiMCAoTFNCKSBvZiB0aGUgMTAtYml0IERhdGFfQ291bnQgd29yZCwg Y29udGFpbgogICAgICAgICAgIHRoZSBhY3R1YWwgY291bnQgb2YgMTAtYml0IHdvcmRzIGluIFVz ZXJfRGF0YV9Xb3Jkcy4gIEJpdCBiOAogICAgICAgICAgIGlzIHRoZSBldmVuIHBhcml0eSBmb3Ig Yml0cyBiNyB0aHJvdWdoIGIwLCBhbmQgYml0IGI5IGlzIHRoZQogICAgICAgICAgIGludmVyc2Ug KGxvZ2ljYWwgTk9UKSBvZiBiaXQgYjguCgogICBSOiAyIHJlc2VydmVkIGJpdHMKCgoKRWR3YXJk cyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDMsIDIwMTYgICAgICAgICAgICAgICAg IFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgUlRQIFBheWxvYWQgZm9yIEFuY2lsbGFy eSBEYXRhICAgICAgICAgT2N0b2JlciAyMDE1CgoKICAgICAgICAgICBSIGlzIGEgZmllbGQgb2Yg dHdvIHJlc2VydmVkIGJpdHMgdGhhdCBNVVNUIGJlIHNldCB0byB6ZXJvLgoKICAgVXNlcl9EYXRh X1dvcmRzOiBpbnRlZ2VyIG51bWJlciBvZiAxMCBiaXQgd29yZHMKICAgICAgICAgICBVc2VyX0Rh dGFfV29yZHMgKFVEVykgYXJlIHVzZWQgdG8gY29udmV5IGluZm9ybWF0aW9uIG9mIGEKICAgICAg ICAgICB0eXBlIGFzIGlkZW50aWZpZWQgYnkgdGhlIERJRCB3b3JkIG9yIHRoZSBESUQgYW5kIFNE SUQgd29yZHMuCiAgICAgICAgICAgVGhlIG51bWJlciBvZiAxMC1iaXQgd29yZHMgaW4gdGhlIFVE VyBpcyBkZWZpbmVkIGJ5IHRoZQogICAgICAgICAgIERhdGFfQ291bnQgZmllbGQuCgogICBDaGVj a3N1bV9Xb3JkOiAxMCBiaXRzCiAgICAgICAgICAgVGhlIENoZWNrc3VtX1dvcmQgY2FuIGJlIHVz ZWQgdG8gZGV0ZXJtaW5lIHRoZSB2YWxpZGl0eSBvZgogICAgICAgICAgIHRoZSBBTkMgZGF0YSBw YWNrZXQgZnJvbSB0aGUgRElEIHdvcmQgdGhyb3VnaCB0aGUgVURXLiAgSXQKICAgICAgICAgICBj b25zaXN0cyBvZiAxMCBiaXRzLCB3aGVyZSBiaXRzIGI4IChNU0IpIHRocm91Z2ggYjAgKExTQikK ICAgICAgICAgICBkZWZpbmUgdGhlIGNoZWNrc3VtIHZhbHVlIGFuZCBiaXQgYjkgaXMgdGhlIGlu dmVyc2UgKGxvZ2ljYWwKICAgICAgICAgICBOT1QpIG9mIGJpdCBiOC4gIFRoZSBjaGVja3N1bSB2 YWx1ZSBpcyBlcXVhbCB0byB0aGUgbmluZQogICAgICAgICAgIGxlYXN0IHNpZ25pZmljYW50IGJp dHMgb2YgdGhlIHN1bSBvZiB0aGUgbmluZSBsZWFzdAogICAgICAgICAgIHNpZ25pZmljYW50IGJp dHMgb2YgdGhlIERJRCB3b3JkLCB0aGUgU0RJRCB3b3JkLCB0aGUKICAgICAgICAgICBEYXRhX0Nv dW50IHdvcmQsIGFuZCBhbGwgVXNlcl9EYXRhX1dvcmRzIGluIHRoZSBBTkMgZGF0YQogICAgICAg ICAgIHBhY2tldC4gIFRoZSBjaGVja3N1bSBpcyBpbml0aWFsaXplZCB0byB6ZXJvIGJlZm9yZQog ICAgICAgICAgIGNhbGN1bGF0aW9uLCBhbmQgYW55IGVuZCBjYXJyeSByZXN1bHRpbmcgZnJvbSB0 aGUgY2hlY2tzdW0KICAgICAgICAgICBjYWxjdWxhdGlvbiBpcyBpZ25vcmVkLgoKICAgb2N0ZXRf YWxpZ246IDAtNyBiaXRzIGFzIG5lZWRlZCB0byBjb21wbGV0ZSBvY3RldAogICAgICAgICAgIE9j dGV0IGFsaWduIGNvbnRhaW5zIGVub3VnaCAiMCIgYml0cyBhcyBuZWVkZWQgdG8gY29tcGxldGUK ICAgICAgICAgICB0aGUgbGFzdCBvY3RldCBvZiBhbiBBTkMgcGFja2V0J3MgZGF0YSBpbiB0aGUg UlRQIHBheWxvYWQuCiAgICAgICAgICAgVGhpcyBlbnN1cmVzIHRoYXQgdGhlIG5leHQgQU5DIHBh Y2tldCdzIGRhdGEgaW4gdGhlIFJUUAogICAgICAgICAgIHBheWxvYWQgYmVnaW5zIG9jdGV0LWFs aWduZWQgZGVzcGl0ZSBBTkMgcGFja2V0cyBiZWluZyBtYWRlCiAgICAgICAgICAgdXAgb2YgMTAt Yml0IHdvcmRzLiAgSWYgYW4gQU5DIGRhdGEgcGFja2V0IGluIHRoZSBSVFAgcGF5bG9hZAogICAg ICAgICAgIGVuZHMgYWxpZ25lZCB3aXRoIGFuIG9jdGV0LCB0aGVyZSBpcyBubyBuZWVkIHRvIGFk ZCBhbnkgb2N0ZXQKICAgICAgICAgICBhbGlnbm1lbnQgYml0cy4KCiAgIFdoZW4gcmVjb25zdHJ1 Y3RpbmcgYW4gU0RJIHNpZ25hbCBiYXNlZCBvbiB0aGlzIHBheWxvYWQsIGl0IGlzCiAgIGltcG9y dGFudCB0byBwbGFjZSBBTkMgcGFja2V0cyBpbnRvIHRoZSBsb2NhdGlvbnMgaW5kaWNhdGVkIGJ5 IHRoZQogICBBTkMgcGF5bG9hZCBoZWFkZXIgZmllbGRzIExpbmVfTnVtYmVyIGFuZCBIb3Jpem9u dGFsX09mZnNldCwgYW5kIGFsc28KICAgdG8gZm9sbG93IHRoZSByZXF1aXJlbWVudHMgb2YgU01Q VEUgU1QgMjkxLTEgW1NUMjkxXSBTZWN0aW9uIDcKICAgIkFuY2lsbGFyeSBEYXRhIFNwYWNlIEZv cm1hdHRpbmcgKENvbXBvbmVudCBvciBDb21wb3NpdGUgSW50ZXJmYWNlKSIsCiAgIHdoaWNoIGlu Y2x1ZGUgcnVsZXMgb24gdGhlIHBsYWNlbWVudCBvZiBpbml0aWFsIEFOQyBkYXRhIGludG8gYWxs b3dlZAogICBzcGFjZXMgYXMgd2VsbCBhcyB0aGUgY29udGlndWl0eSBvZiBBTkMgZGF0YSBwYWNr ZXQgc2VxdWVuY2VzIHdpdGhpbgogICB0aG9zZSBzcGFjZXMgaW4gb3JkZXIgdG8gYXNzdXJlIHRo YXQgdGhlIHJlc3VsdGluZyBBTkMgcGFja2V0cyBpbiB0aGUKICAgU0RJIHNpZ25hbCBhcmUgdmFs aWQuCgozLiAgUGF5bG9hZCBGb3JtYXQgUGFyYW1ldGVycwoKICAgVGhpcyBSVFAgcGF5bG9hZCBm b3JtYXQgaXMgaWRlbnRpZmllZCB1c2luZyB0aGUgdmlkZW8vc21wdGUyOTEgbWVkaWEKICAgdHlw ZSwgd2hpY2ggaXMgcmVnaXN0ZXJlZCBpbiBhY2NvcmRhbmNlIHdpdGggUkZDIDQ4NTUgW1JGQzQ4 NTVdLCBhbmQKICAgdXNpbmcgdGhlIHRlbXBsYXRlIG9mIFJGQyA0Mjg4IFtSRkM0Mjg4XS4KCiAg IE5vdGUgdGhhdCB0aGUgTWVkaWEgVHlwZSBEZWZpbml0aW9uIGlzIGluIHRoZSAidmlkZW8iIHRy ZWUgZHVlIHRvIHRoZQogICBleHBlY3RlZCB1c2Ugb2YgU01QVEUgU1QgMjkxIEFuY2lsbGFyeSBE YXRhIHdpdGggdmlkZW8gZm9ybWF0cy4KCgoKRWR3YXJkcyAgICAgICAgICAgICAgICAgICBFeHBp cmVzIEFwcmlsIDMsIDIwMTYgICAgICAgICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgUlRQIFBheWxvYWQgZm9yIEFuY2lsbGFyeSBEYXRhICAgICAgICAgT2N0b2JlciAy MDE1CgoKMy4xLiAgTWVkaWEgVHlwZSBEZWZpbml0aW9uCgogICBUeXBlIG5hbWU6IHZpZGVvCgog ICBTdWJ0eXBlIG5hbWU6IHNtcHRlMjkxCgogICBSZXF1aXJlZCBwYXJhbWV0ZXJzOgoKICAgICAg UmF0ZTogUlRQIHRpbWVzdGFtcCBjbG9jayByYXRlLgoKICAgT3B0aW9uYWwgcGFyYW1ldGVyczoK CiAgICAgIERJRF9TRElEOiBEYXRhIGlkZW50aWZpY2F0aW9uIGFuZCBTZWNvbmRhcnkgZGF0YSBp ZGVudGlmaWNhdGlvbgogICAgICB3b3Jkcy4KCiAgICAgIFRoZSBwcmVzZW5jZSBvZiB0aGUgRElE X1NESUQgcGFyYW1ldGVycyBzaWduYWxzIHRoYXQgYWxsIGFuY2lsbGFyeQogICAgICBkYXRhIHBh Y2tldHMgb2YgdGhpcyBzdHJlYW0gYXJlIG9mIGEgcGFydGljdWxhciB0eXBlIG9yIHR5cGVzLAog ICAgICBpLmUuLCBsYWJlbGVkIHdpdGggYSBwYXJ0aWN1bGFyIERJRHMgYW5kIFNESURzLiAgVGhl IERJRF9TRElECiAgICAgIHBhcmFtZXRlciBjb25zaXN0cyBvZiB0aGUgRElEIGFuZCBTRElEIHZh bHVlcyBpbiB0aGF0IG9yZGVyCiAgICAgIHNlcGFyYXRlZCBieSBhIGNvbW1hLCB3aXRoIHRoZSBE SUQvU0RJRCBwYWlyIHByZWNlZGVkIGJ5IGEgJ3snIGFuZAogICAgICBmb2xsb3dlZCBieSBhICd9 Jy4KCiAgICAgIERJRCBhbmQgU0RJRCB2YWx1ZXMgc2hvdWxkIGJlIHNwZWNpZmllZCBpbiBoZXhh ZGVjaW1hbCB3aXRoIGEgIjB4IgogICAgICBwcmVmaXggKHN1Y2ggYXMgIjB4NjEiKS4gIEZvciBl eGFtcGxlLCBFSUEgNjA4IENsb3NlZCBDYXB0aW9uIGRhdGEKICAgICAgd291bGQgYmUgc2lnbmFs bGVkIHdpdGggdGhlIHBhcmFtZXRlciBESURfU0RJRD17MHg2MSwweDAyfS4gIElmCiAgICAgIERJ RF9TRElEIGlzIG5vdCBzcGVjaWZpZWQsIHRoZW4gdGhlIGFuY2lsbGFyeSBkYXRhIHN0cmVhbSBt YXkKICAgICAgcG90ZW50aWFsbHkgY29udGFpbiBhbmNpbGxhcnkgZGF0YSBwYWNrZXRzIG9mIGFu eSB0eXBlLgoKICAgICAgTXVsdGlwbGUgRElEX1NESUQgcGFyYW1ldGVycyBtYXkgYmUgc3BlY2lm aWVkIChzZXBhcmF0ZWQgYnkKICAgICAgc2VtaWNvbG9ucykgdG8gc2lnbmFsIHRoZSBwcmVzZW5j ZSBvZiBtdWx0aXBsZSB0eXBlcyBvZiBBTkMgZGF0YQogICAgICBpbiB0aGUgc3RyZWFtLiAgRElE X1NESUQ9ezB4NjEsMHgwMn07RElEX1NESUQ9ezB4NDEsMHgwNX0sIGZvcgogICAgICBleGFtcGxl LCBzaWduYWxzIHRoZSBwcmVzZW5jZSBvZiBFSUEgNjA4IENsb3NlZCBDYXB0aW9ucyBhcyB3ZWxs CiAgICAgIGFzIEFGRC9CYXIgRGF0YS4KCiAgICAgIERJRCBhbmQgU0RJRCB2YWx1ZXMgb2YgU01Q VEUgUmVnaXN0ZXJlZCBBTkMgcGFja2V0IHR5cGVzIGNhbiBiZQogICAgICBmb3VuZCBvbiB0aGUg U01QVEUgUmVnaXN0cnkgZm9yIERhdGEgSWRlbnRpZmljYXRpb24gV29yZAogICAgICBBc3NpZ25t ZW50cyBhdDoKCiAgICAgIGh0dHA6Ly93d3cuc21wdGUtcmEub3JnL1MyOTEvUzI5MV9yZWcuaHRt bAoKICAgICAgRElEIGFuZCBTRElEIHZhbHVlcyBjYW4gYmUgcmVnaXN0ZXJlZCB3aXRoIFNNUFRF IGFzIHBlciBTTVBURSBTVAogICAgICAyOTEtMSBbU1QyOTFdLgoKICAgRW5jb2RpbmcgY29uc2lk ZXJhdGlvbnM6IFRoaXMgbWVkaWEgdHlwZSBpcyBmcmFtZWQgYW5kIGJpbmFyeTsgc2VlCiAgIFNl Y3Rpb24gNC44IG9mIFJGQyA0Mjg4IFtSRkM0Mjg4XS4KCiAgIFNlY3VyaXR5IGNvbnNpZGVyYXRp b25zOiBTZWUgU2VjdGlvbiA1IG9mIFt0aGlzIFJGQ10KCgoKCkVkd2FyZHMgICAgICAgICAgICAg ICAgICAgRXhwaXJlcyBBcHJpbCAzLCAyMDE2ICAgICAgICAgICAgICAgICBbUGFnZSA4XQoMCklu dGVybmV0LURyYWZ0ICAgICAgIFJUUCBQYXlsb2FkIGZvciBBbmNpbGxhcnkgRGF0YSAgICAgICAg IE9jdG9iZXIgMjAxNQoKCiAgIEludGVyb3BlcmFiaWxpdHkgY29uc2lkZXJhdGlvbnM6IERhdGEg aXRlbXMgaW4gc21wdGUyOTEgY2FuIGJlIHZlcnkKICAgZGl2ZXJzZS4gIFJlY2VpdmVycyBtaWdo dCBvbmx5IGJlIGNhcGFibGUgb2YgaW50ZXJwcmV0aW5nIGEgc3Vic2V0IG9mCiAgIHRoZSBwb3Nz aWJsZSBkYXRhIGl0ZW1zLiAgU29tZSBpbXBsZW1lbnRhdGlvbnMgbWF5IGNhcmUgYWJvdXQgdGhl CiAgIGxvY2F0aW9uIG9mIHRoZSBBTkMgZGF0YSBwYWNrZXRzIGluIHRoZSBTREkgcmFzdGVyLCBi dXQgb3RoZXIKICAgaW1wbGVtZW50YXRpb25zIG1heSBub3QgY2FyZS4KCiAgIFB1Ymxpc2hlZCBz cGVjaWZpY2F0aW9uOiBbdGhpcyBSRkNdCgogICBBcHBsaWNhdGlvbnMgdGhhdCB1c2UgdGhpcyBt ZWRpYSB0eXBlOiBEZXZpY2VzIHRoYXQgc3RyZWFtIHJlYWwtdGltZQogICBwcm9mZXNzaW9uYWwg dmlkZW8sIGVzcGVjaWFsbHkgdGhvc2UgdGhhdCBtdXN0IGludGVyb3BlcmF0ZSB3aXRoCiAgIGxl Z2FjeSBzZXJpYWwgZGlnaXRhbCBpbnRlcmZhY2VzIChTREkpLgoKICAgQWRkaXRpb25hbCBJbmZv cm1hdGlvbjogbm9uZQoKICAgUGVyc29uICYgZW1haWwgYWRkcmVzcyB0byBjb250YWN0IGZvciBm dXJ0aGVyIGluZm9ybWF0aW9uOiBULgogICBFZHdhcmRzIDx0aG9tYXMuZWR3YXJkc0Bmb3guY29t PiwgSUVURiBQYXlsb2FkIFdvcmtpbmcgR3JvdXAKICAgPHBheWxvYWRAaWV0Zi5vcmc+CgogICBJ bnRlbmRlZCB1c2FnZTogQ09NTU9OCgogICBSZXN0cmljdGlvbnMgb24gdXNhZ2U6IFRoaXMgbWVk aWEgdHlwZSBkZXBlbmRzIG9uIFJUUCBmcmFtaW5nLCBhbmQKICAgaGVuY2UgaXMgb25seSBkZWZp bmVkIGZvciB0cmFuc2ZlciB2aWEgUlRQIFJGQyAzNTUwIFtSRkMzNTUwXS4KICAgVHJhbnNwb3J0 IHdpdGhpbiBvdGhlciBmcmFtaW5nIHByb3RvY29scyBpcyBub3QgZGVmaW5lZCBhdCB0aGlzIHRp bWUuCgogICBBdXRob3I6IFQuICBFZHdhcmRzIDx0aG9tYXMuZWR3YXJkc0Bmb3guY29tPgoKICAg Q2hhbmdlIGNvbnRyb2xsZXI6IElFVEYgQXVkaW8vVmlkZW8gVHJhbnNwb3J0IFBheWxvYWRzIHdv cmtpbmcgZ3JvdXAKICAgZGVsZWdhdGVkIGZyb20gdGhlIElFU0cuCgozLjIuICBNYXBwaW5nIHRv IFNEUAoKICAgVGhlIG1hcHBpbmcgb2YgdGhlIGFib3ZlIGRlZmluZWQgcGF5bG9hZCBmb3JtYXQg bWVkaWEgdHlwZSBhbmQgaXRzCiAgIHBhcmFtZXRlcnMgU0hBTEwgYmUgZG9uZSBhY2NvcmRpbmcg dG8gU2VjdGlvbiAzIG9mIFJGQyA0ODU1CiAgIFtSRkM0ODU1XS4KCiAgIG8gIFRoZSB0eXBlIG5h bWUgKCJ2aWRlbyIpIGdvZXMgaW4gU0RQICJtPSIgYXMgdGhlIG1lZGlhIG5hbWUuCgogICBvICBU aGUgc3VidHlwZSBuYW1lICgic21wdGUyOTEiKSBnb2VzIGluIFNEUCAiYT1ydHBtYXAiIGFzIHRo ZQogICAgICBlbmNvZGluZyBuYW1lLgoKICAgbyAgVGhlIG9wdGlvbmFsIERJRF9TRElEIHBhcmFt ZXRlcnMgZ28gaW4gdGhlIFNEUCAiYT1mbXRwIiBhdHRyaWJ1dGUKICAgICAgYXMgYSBzZW1pY29s b24tc2VwYXJhdGVkIGxpc3Qgb2YgcGFyYW1ldGVyPXZhbHVlIHBhaXJzLgoKICAgQSBzYW1wbGUg U0RQIG1hcHBpbmcgZm9yIGFuY2lsbGFyeSBkYXRhIGlzIGFzIGZvbGxvd3M6CgogICBtPXZpZGVv IDMwMDAwIFJUUC9BVlAgMTEyCiAgIGE9cnRwbWFwOjExMiBzbXB0ZTI5MS85MDAwMAogICBhPWZt dHA6MTEyIERJRF9TRElEPXsweDYxLDB4MDJ9O0RJRF9TRElEPXsweDQxLDB4MDV9CgoKCkVkd2Fy ZHMgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAzLCAyMDE2ICAgICAgICAgICAgICAg ICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAgIFJUUCBQYXlsb2FkIGZvciBBbmNpbGxh cnkgRGF0YSAgICAgICAgIE9jdG9iZXIgMjAxNQoKCiAgIEluIHRoaXMgZXhhbXBsZSwgYSBkeW5h bWljIHBheWxvYWQgdHlwZSAxMTIgaXMgdXNlZCBmb3IgYW5jaWxsYXJ5CiAgIGRhdGEuICBUaGUg OTAga0h6IFJUUCB0aW1lc3RhbXAgcmF0ZSBpcyBzcGVjaWZpZWQgaW4gdGhlICJhPXJ0cG1hcCIK ICAgbGluZSBhZnRlciB0aGUgc3VidHlwZS4gIFRoZSBSVFAgc2FtcGxpbmcgY2xvY2sgaXMgOTAg a0h6LiAgSW4gdGhlCiAgICJhPWZtdHA6IiBsaW5lLCBESUQgMHg2MSBhbmQgU0RJRCAweDAyIGFy ZSBzcGVjaWZpZWQgKHJlZ2lzdGVyZWQgdG8KICAgRUlBIDYwOCBDbG9zZWQgQ2FwdGlvbiBEYXRh IGJ5IFNNUFRFKSwgYW5kIGFsc28gRElEIDB4NDEgYW5kIFNESUQKICAgMHgwNSAocmVnaXN0ZXJl ZCB0byBBRkQvQmFyIERhdGEpLgoKMy4zLiAgT2ZmZXIvQW5zd2VyIE1vZGVsIGFuZCBEZWNsYXJh dGl2ZSBDb25zaWRlcmF0aW9ucwoKICAgV2hlbiBvZmZlcmluZyBTTVBURSBTVCAyOTEgQW5jaWxs YXJ5IGRhdGEgb3ZlciBSVFAgdXNpbmcgdGhlIFNlc3Npb24KICAgRGVzY3JpcHRpb24gUHJvdG9j b2wgKFNEUCkgaW4gYW4gT2ZmZXIvQW5zd2VyIG1vZGVsIFtSRkMzMjY0XSBvciBpbiBhCiAgIGRl Y2xhcmF0aXZlIG1hbm5lciAoZS5nLiwgU0RQIGluIHRoZSBSZWFsLVRpbWUgU3RyZWFtaW5nIFBy b3RvY29sCiAgIChSVFNQKSBbUkZDMjMyNl0gb3IgdGhlIFNlc3Npb24gQW5ub3VuY2VtZW50IFBy b3RvY29sIChTQVApCiAgIFtSRkMyOTc0XSksIHRoZSBvZmZlcmVyIGNvdWxkIHByb3ZpZGUgYSBs aXN0IG9mIHN0cmVhbXMgYXZhaWxhYmxlCiAgIHdpdGggc3BlY2lmaWMgRElEICYgU0RJRHMsIGFu ZCB0aGUgYW5zd2VyZXIgY291bGQgc3BlY2lmeSB3aGljaAogICBzdHJlYW1zIHdpdGggc3BlY2lm aWMgRElEICYgU0RJRHMgaXQgd291bGQgbGlrZSB0byBhY2NlcHQuCgo0LiAgSUFOQSBDb25zaWRl cmF0aW9ucwoKICAgT25lIG1lZGlhIHR5cGUgKHZpZGVvL3NtcHRlMjkxKSBoYXMgYmVlbiBkZWZp bmVkIGFuZCBuZWVkcwogICByZWdpc3RyYXRpb24gaW4gdGhlIG1lZGlhIHR5cGVzIHJlZ2lzdHJ5 LiAgU2VlIFNlY3Rpb24gMy4xCgo1LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFJUUCBw YWNrZXRzIHVzaW5nIHRoZSBwYXlsb2FkIGZvcm1hdCBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNh dGlvbgogICBhcmUgc3ViamVjdCB0byB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZGlzY3Vz c2VkIGluIHRoZSBSVFAKICAgc3BlY2lmaWNhdGlvbiBbUkZDMzU1MF0gYW5kIGFueSBhcHBsaWNh YmxlIFJUUCBwcm9maWxlLCBlLmcuLCBBVlAKICAgW1JGQzM1NTFdLgoKICAgVG8gYXZvaWQgcG90 ZW50aWFsIGJ1ZmZlciBvdmVyZmxvdyBhdHRhY2tzLCByZWNlaXZlcnMgc2hvdWxkIHRha2UKICAg Y2FyZSB0byB2YWxpZGF0ZSB0aGF0IHRoZSBBTkMgcGFja2V0cyBpbiB0aGUgUlRQIHBheWxvYWQg YXJlIG9mIHRoZQogICBhcHByb3ByaWF0ZSBsZW5ndGggKHVzaW5nIHRoZSBEYXRhX0NvdW50IGZp ZWxkKSBmb3IgdGhlIEFOQyBkYXRhIHR5cGUKICAgc3BlY2lmaWVkIGJ5IERJRCAmIFNESUQuICBB bHNvIHRoZSBDaGVja3N1bV9Xb3JkIHNob3VsZCBiZSBjaGVja2VkCiAgIGFnYWluc3QgdGhlIEFO QyBkYXRhIHBhY2tldCB0byBlbnN1cmUgdGhhdCBpdHMgZGF0YSBoYXMgbm90IGJlZW4KICAgZGFt YWdlZCBpbiB0cmFuc2l0LgoKICAgU29tZSByZWNlaXZlcnMgd2lsbCBzaW1wbHkgbW92ZSB0aGUg QU5DIGRhdGEgcGFja2V0IGJpdHMgZnJvbSB0aGUgUlRQCiAgIHBheWxvYWQgaW50byBhIHNlcmlh bCBkaWdpdGFsIGludGVyZmFjZSAoU0RJKS4gIEl0IG1heSBzdGlsbCBiZSBhCiAgIGdvb2QgaWRl YSBmb3IgdGhlc2UgInJlLWVtYmVkZGVycyIgdG8gcGVyZm9ybSB0aGUgYWJvdmUgbWVudGlvbmVk CiAgIHZhbGlkaXR5IHRlc3RzIHRvIGF2b2lkIGRvd25zdHJlYW0gU0RJIHN5c3RlbXMgZnJvbSBi ZWNvbWluZyBjb25mdXNlZAogICBieSBiYWQgQU5DIHBhY2tldHMsIHdoaWNoIGNvdWxkIGJlIHVz ZWQgZm9yIGEgZGVuaWFsIG9mIHNlcnZpY2UKICAgYXR0YWNrLgoKICAgIlJlLWVtYmVkZGVycyIg aW50byBTREkgc2hvdWxkIGFsc28gZG91YmxlIGNoZWNrIHRoYXQgdGhlIExpbmVfTnVtYmVyCiAg IGFuZCBIb3Jpem9udGFsX09mZnNldCBsZWFkcyB0byB0aGUgQU5DIGRhdGEgcGFja2V0IGJlaW5n IGluc2VydGVkCiAgIGludG8gYSBsZWdhbCBhcmVhIHRvIGNhcnJ5IGFuY2lsbGFyeSBkYXRhIGlu IHRoZSBTREkgdmlkZW8gYml0IHN0cmVhbQogICBvZiB0aGUgb3V0cHV0IHZpZGVvIGZvcm1hdC4K CgoKCkVkd2FyZHMgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAzLCAyMDE2ICAgICAg ICAgICAgICAgIFtQYWdlIDEwXQoMCkludGVybmV0LURyYWZ0ICAgICAgIFJUUCBQYXlsb2FkIGZv ciBBbmNpbGxhcnkgRGF0YSAgICAgICAgIE9jdG9iZXIgMjAxNQoKCjYuICBSZWZlcmVuY2VzCgo2 LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW0JUMTEyMF0gICBJVFUtUiwgIkJULjExMjAt OCwgRGlnaXRhbCBJbnRlcmZhY2VzIGZvciBIRFRWIFN0dWRpbwogICAgICAgICAgICAgIFNpZ25h bHMiLCBKYW51YXJ5IDIwMTIuCgogICBbQlQxNzAwXSAgIElUVS1SLCAiQlQuMTcwMCwgQ2hhcmFj dGVyaXN0aWNzIG9mIENvbXBvc2l0ZSBWaWRlbwogICAgICAgICAgICAgIFNpZ25hbHMgZm9yIENv bnZlbnRpb25hbCBBbmFsb2d1ZSBUZWxldmlzaW9uIFN5c3RlbXMiLAogICAgICAgICAgICAgIEZl YnJ1YXJ5IDIwMDUuCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1 c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIs IEJDUCAxNCwgUkZDIDIxMTksCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzIxMTksIE1h cmNoIDE5OTcsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9y ZmMyMTE5Pi4KCiAgIFtSRkMzNTUwXSAgU2NodWx6cmlubmUsIEguLCBDYXNuZXIsIFMuLCBGcmVk ZXJpY2ssIFIuLCBhbmQgVi4KICAgICAgICAgICAgICBKYWNvYnNvbiwgIlJUUDogQSBUcmFuc3Bv cnQgUHJvdG9jb2wgZm9yIFJlYWwtVGltZQogICAgICAgICAgICAgIEFwcGxpY2F0aW9ucyIsIFNU RCA2NCwgUkZDIDM1NTAsIERPSSAxMC4xNzQ4Ny9SRkMzNTUwLAogICAgICAgICAgICAgIEp1bHkg MjAwMywgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMzNTUwPi4KCiAgIFtSRkM0 Mjg4XSAgRnJlZWQsIE4uIGFuZCBKLiBLbGVuc2luLCAiTWVkaWEgVHlwZSBTcGVjaWZpY2F0aW9u cyBhbmQKICAgICAgICAgICAgICBSZWdpc3RyYXRpb24gUHJvY2VkdXJlcyIsIFJGQyA0Mjg4LCBE T0kgMTAuMTc0ODcvUkZDNDI4OCwKICAgICAgICAgICAgICBEZWNlbWJlciAyMDA1LCA8aHR0cDov L3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzQyODg+LgoKICAgW1JGQzQ4NTVdICBDYXNuZXIs IFMuLCAiTWVkaWEgVHlwZSBSZWdpc3RyYXRpb24gb2YgUlRQIFBheWxvYWQKICAgICAgICAgICAg ICBGb3JtYXRzIiwgUkZDIDQ4NTUsIERPSSAxMC4xNzQ4Ny9SRkM0ODU1LCBGZWJydWFyeSAyMDA3 LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNDg1NT4u CgogICBbU1QyOTFdICAgIFNNUFRFLCAiU1QgMjkxLTE6MjAxMSwgQW5jaWxsYXJ5IERhdGEgUGFj a2V0IGFuZCBTcGFjZQogICAgICAgICAgICAgIEZvcm1hdHRpbmciLCAyMDExLgoKNi4yLiAgSW5m b3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW0JUNjU2XSAgICBJVFUtUiwgIkJULjY1Ni01LCBJbnRl cmZhY2VzIGZvciBEaWdpdGFsIENvbXBvbmVudCBWaWRlbwogICAgICAgICAgICAgIFNpZ25hbHMg aW4gNTI1LUxpbmUgYW5kIDYyNS1MaW5lIFRlbGV2aXNpb24gU3lzdGVtcwogICAgICAgICAgICAg IE9wZXJhdGluZyBhdCB0aGUgNDoyOjIgTGV2ZWwgb2YgUmVjb21tZW5kYXRpb24gSVRVLVIKICAg ICAgICAgICAgICBCVC42MDEiLCBEZWNlbWJlciAyMDA3LgoKICAgW1JGQzIzMjZdICBTY2h1bHpy aW5uZSwgSC4sIFJhbywgQS4sIGFuZCBSLiBMYW5waGllciwgIlJlYWwgVGltZQogICAgICAgICAg ICAgIFN0cmVhbWluZyBQcm90b2NvbCAoUlRTUCkiLCBSRkMgMjMyNiwKICAgICAgICAgICAgICBE T0kgMTAuMTc0ODcvUkZDMjMyNiwgQXByaWwgMTk5OCwKICAgICAgICAgICAgICA8aHR0cDovL3d3 dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzIzMjY+LgoKICAgW1JGQzI5NzRdICBIYW5kbGV5LCBN LiwgUGVya2lucywgQy4sIGFuZCBFLiBXaGVsYW4sICJTZXNzaW9uCiAgICAgICAgICAgICAgQW5u b3VuY2VtZW50IFByb3RvY29sIiwgUkZDIDI5NzQsIERPSSAxMC4xNzQ4Ny9SRkMyOTc0LAogICAg ICAgICAgICAgIE9jdG9iZXIgMjAwMCwgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9y ZmMyOTc0Pi4KCgoKCkVkd2FyZHMgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAzLCAy MDE2ICAgICAgICAgICAgICAgIFtQYWdlIDExXQoMCkludGVybmV0LURyYWZ0ICAgICAgIFJUUCBQ YXlsb2FkIGZvciBBbmNpbGxhcnkgRGF0YSAgICAgICAgIE9jdG9iZXIgMjAxNQoKCiAgIFtSRkMz MjY0XSAgUm9zZW5iZXJnLCBKLiBhbmQgSC4gU2NodWx6cmlubmUsICJBbiBPZmZlci9BbnN3ZXIg TW9kZWwKICAgICAgICAgICAgICB3aXRoIFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNE UCkiLCBSRkMgMzI2NCwKICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDMzI2NCwgSnVuZSAy MDAyLAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjMzI2 ND4uCgogICBbUkZDMzU1MV0gIFNjaHVsenJpbm5lLCBILiBhbmQgUy4gQ2FzbmVyLCAiUlRQIFBy b2ZpbGUgZm9yIEF1ZGlvIGFuZAogICAgICAgICAgICAgIFZpZGVvIENvbmZlcmVuY2VzIHdpdGgg TWluaW1hbCBDb250cm9sIiwgU1REIDY1LCBSRkMgMzU1MSwKICAgICAgICAgICAgICBET0kgMTAu MTc0ODcvUkZDMzU1MSwgSnVseSAyMDAzLAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1l ZGl0b3Iub3JnL2luZm8vcmZjMzU1MT4uCgogICBbUkZDNDE3NV0gIEdoYXJhaSwgTC4gYW5kIEMu IFBlcmtpbnMsICJSVFAgUGF5bG9hZCBGb3JtYXQgZm9yCiAgICAgICAgICAgICAgVW5jb21wcmVz c2VkIFZpZGVvIiwgUkZDIDQxNzUsIERPSSAxMC4xNzQ4Ny9SRkM0MTc1LAogICAgICAgICAgICAg IFNlcHRlbWJlciAyMDA1LCA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzQxNzU+ LgoKICAgW1JGQzUzNzFdICBGdXRlbW1hLCBTLiwgSXRha3VyYSwgRS4sIGFuZCBBLiBMZXVuZywg IlJUUCBQYXlsb2FkCiAgICAgICAgICAgICAgRm9ybWF0IGZvciBKUEVHIDIwMDAgVmlkZW8gU3Ry ZWFtcyIsIFJGQyA1MzcxLAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM1MzcxLCBPY3Rv YmVyIDIwMDgsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9y ZmM1MzcxPi4KCiAgIFtSUDE2OF0gICAgU01QVEUsICJSUCAxNjg6MjAwOSwgRGVmaW5pdGlvbiBv ZiBWZXJ0aWNhbCBJbnRlcnZhbAogICAgICAgICAgICAgIFN3aXRjaGluZyBQb2ludCBmb3IgU3lu Y2hyb25vdXMgVmlkZW8gU3dpdGNoaW5nIiwgMjAwOS4KCiAgIFtTVDEyNV0gICAgU01QVEUsICJT VCAxMjU6MjAxMywgU0RUViBDb21wb25lbnQgVmlkZW8gU2lnbmFsIENvZGluZwogICAgICAgICAg ICAgIDQ6NDo0IGFuZCA0OjI6MiBmb3IgMTMuNSBNSHogYW5kIDE4IE1IeiBTeXN0ZW1zIiwgMjAx My4KCiAgIFtTVDIwMzhdICAgU01QVEUsICJTVCAyMDM4OjIwMDgsIENhcnJpYWdlIG9mIEFuY2ls bGFyeSBEYXRhIFBhY2tldHMKICAgICAgICAgICAgICBpbiBhbiBNUEVHLTIgVHJhbnNwb3J0IFN0 cmVhbSIsIDIwMDguCgogICBbU1QyNTldICAgIFNNUFRFLCAiU1QgMjU5OjIwMDgsIFNEVFYgRGln aXRhbCBTaWduYWwvRGF0YSAtIFNlcmlhbAogICAgICAgICAgICAgIERpZ2l0YWwgSW50ZXJmYWNl IiwgMjAwOC4KCiAgIFtTVDI3NF0gICAgU01QVEUsICJTVCAyNzQ6MjAwOCwgMTkyMCB4IDEwODAg SW1hZ2UgU2FtcGxlIFN0cnVjdHVyZSwKICAgICAgICAgICAgICBEaWdpdGFsIFJlcHJlc2VudGF0 aW9uIGFuZCBEaWdpdGFsIFRpbWluZyBSZWZlcmVuY2UKICAgICAgICAgICAgICBTZXF1ZW5jZXMg Zm9yIE11bHRpcGxlIFBpY3R1cmUgUmF0ZXMiLCAyMDA4LgoKICAgW1NUMjkyXSAgICBTTVBURSwg IlNUIDI5Mi0xOjIwMTIsIDEuNSBHYi9zIFNpZ25hbC9EYXRhIFNlcmlhbAogICAgICAgICAgICAg IEludGVyZmFjZSIsIDIwMTIuCgogICBbU1QyOTZdICAgIFNNUFRFLCAiU1QgMjk2OjIwMTIsIDEy ODAgeCA3MjAgUHJvZ3Jlc3NpdmUgSW1hZ2UgNDoyOjIKICAgICAgICAgICAgICBhbmQgNDo0OjQg U2FtcGxlIFN0cnVjdHVyZSAtIEFuYWxvZyBhbmQgRGlnaXRhbAogICAgICAgICAgICAgIFJlcHJl c2VudGF0aW9uIGFuZCBBbmFsb2cgSW50ZXJmYWNlIiwgMjAxMi4KCkF1dGhvcidzIEFkZHJlc3MK CgoKCgoKCgpFZHdhcmRzICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMywgMjAxNiAg ICAgICAgICAgICAgICBbUGFnZSAxMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICBSVFAgUGF5bG9h ZCBmb3IgQW5jaWxsYXJ5IERhdGEgICAgICAgICBPY3RvYmVyIDIwMTUKCgogICBUaG9tYXMgRy4g RWR3YXJkcwogICBGT1gKICAgMTAyMDEgVy4gUGljbyBCbHZkLgogICBMb3MgQW5nZWxlcywgQ0Eg IDkwMDM1CiAgIFVTQQoKICAgUGhvbmU6ICsxIDMxMCAzNjkgNjY5NgogICBFbWFpbDogdGhvbWFz LmVkd2FyZHNAZm94LmNvbQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKRWR3YXJkcyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDMsIDIwMTYgICAgICAg ICAgICAgICAgW1BhZ2UgMTNdCg== --_004_D23182C43AD29thomasedwardsfoxcom_--