From nobody Sun May 3 08:54:56 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1874D1A6F3B; Sun, 3 May 2015 08:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3, 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 vYMtS9VgqUXD; Sun, 3 May 2015 08:54:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2320B1A6F39; Sun, 3 May 2015 08:54:51 -0700 (PDT) Received: from [10.10.1.5] (173.192.103.19-static.reverse.softlayer.com [173.192.103.19]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t43Fsn6b099739 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 May 2015 10:54:51 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 173.192.103.19-static.reverse.softlayer.com [173.192.103.19] claimed to be [10.10.1.5] From: "Ben Campbell" To: draft-ietf-avtext-rtp-grouping-taxonomy.all@ietf.org, avtext@ietf.org Date: Sun, 03 May 2015 16:54:49 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: [avtext] AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2015 15:54:56 -0000 Hi, Here's my AD Evaluation of draft-ietf-avtext-rtp-grouping-taxonomy-06. Nothing here is sufficient to delay the IETF last call, but I'd like to at least see a response to the subtsantive comments. Thanks! Ben. ---------------- Substantive Comments: -- I do not object to this being informational per se, but I wonder if people expect it to be normatively references by future standards track documents. Remember that a reference should be normative if it is needed to understand the dependent document. Terminology references often fall squarely into that category. If the answer is yes, has there been any considerations that this draft may need to be standards track? -- Along the same lines, all the references informational. Could a reader be expected to understand this draft without reading _any_ of the references? I recognize this may not be important for an informational draft that is not a technical specification. But it may be more important if standards track docs normatively reference this doc. Nits and Editorial Comments: -- Abstract: "... attempts to define..." Is there a concern that it may not have succeeded? :-) -- Section 1, 1st sentence: Do you think RTP terminology will continue to be confusing and inconsistent after this draft is published? Also, please expand RTP in the first use in the body. (In addition to the abstract.) -- 2.1.2: Do you consider the meaning of the term "Media" to be clear enough that it doesn't need a definition here? I find it hard to parse the following sentence: "This data is due to its periodical sampling, or at least being timed asynchronous events, some form of a stream of media data. " -- 2.1.2, 2nd bullet list entry: s/support/supports -- 2.1.4, first sentence I find the sentence hard to parse: -- 2.1.5 Was the "raw stream" not also time-progressing? -- 2.1.9, first bullet list entry: I can't parse the sentence. Is there a missing word towards the end? -- 2.1.18 "... alarm subsequent transformations ... " Do you mean "alert"? -- 2.2.3, first bullet list entry: is the SIP URI example assumed to be an Address of Record? If so, it might be worth mentioning that, since a SIP URI could also point to a device, and a participant might have more than one. -- 3.7, last paragraph, 2nd sentence: Sentence is convoluted and hard to read. Please consider splitting it into multiple simpler sentences. -- 3.8, first paragraph, 2nd sentence: Convoluted sentence. -- 3.9, last paragraph: Convoluted sentence. -- 3.10, last paragaph, last sentence: Convoluted sentence. -- 3.11, last paragraph : "This requires to either use..." Missing noun? ("This requires XXX to use either", or "This requires the use of either...") 3.13, first paragraph, last sentence: I can’t parse the sentence—is there a word missing? (i.e. “… and smaller number of flow based…”)? From nobody Mon May 4 07:31:13 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1481A1A77; Mon, 4 May 2015 07:31:10 -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 dqHYee-agjgT; Mon, 4 May 2015 07:31:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5C11A1A32; Mon, 4 May 2015 07:31:09 -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.0.2.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150504143109.21850.16736.idtracker@ietfa.amsl.com> Date: Mon, 04 May 2015 07:31:09 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] Last Call: (A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources) to Informational RFC X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 14:31:10 -0000 The IESG has received a request from the Audio/Video Transport Extensions WG (avtext) to consider the following document: - 'A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-05-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The terminology about, and associations among, Real-Time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed relationships among RTP sources, and attempts to define common terminology for discussing protocol entities and their relationships. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon May 4 10:46:16 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2771A870F for ; Mon, 4 May 2015 10:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 R1q_5UYSR0yQ for ; Mon, 4 May 2015 10:46:12 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0107.outbound.protection.outlook.com [207.46.100.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3031B1A8706 for ; Mon, 4 May 2015 10:46:12 -0700 (PDT) Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) with Microsoft SMTP Server (TLS) id 15.1.148.16; Mon, 4 May 2015 17:46:10 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0148.019; Mon, 4 May 2015 17:46:10 +0000 From: Stephan Wenger To: "avtext@ietf.org" Thread-Topic: Stephan's patent disclosure needs against draft-berger-avtext-framemarking-00 Thread-Index: AQHQhpI0KAM7dkF47EGIzSaX9iZ7Iw== Date: Mon, 4 May 2015 17:46:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [160.79.220.22] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1276; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR0701MB1276; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1276; x-forefront-prvs: 05669A7924 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(450100001)(230783001)(2900100001)(46102003)(50986999)(54356999)(107886002)(122556002)(110136002)(86362001)(40100003)(5001960100002)(92566002)(99286002)(77156002)(2501003)(106116001)(66066001)(102836002)(62966003)(36756003)(87936001)(229853001)(2351001)(2656002)(16236675004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1276; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D16D289B53ED0stewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2015 17:46:09.6580 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1276 Archived-At: Subject: [avtext] Stephan's patent disclosure needs against draft-berger-avtext-framemarking-00 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 17:46:15 -0000 --_000_D16D289B53ED0stewesteweorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi AVTEXT, In Dallas, during the AVTEXT session, I made a remark that I may have to di= sclose IPR against draft-berger-avtext-framemarking-00. I have since revie= wed the cases in question, and came to the conclusion that, at this point i= n time, I do not have personal knowledge of IPR related to this draft that = I would need to disclose. Sorry for the false alarm. Regards, Stephan --_000_D16D289B53ED0stewesteweorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <963080DEC0E1B3438966C054290E2030@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi AVTEXT,
In Dallas, during the AVTEXT session, I made a remark that I may have = to disclose IPR against draft-berger-avtext-framemarking-00.  I have s= ince reviewed the cases in question, and came to the conclusion that, at th= is point in time, I do not have personal knowledge of IPR related to this draft that I would need to disclose.
Sorry for the false alarm.
Regards,
Stephan
--_000_D16D289B53ED0stewesteweorg_-- From nobody Mon May 4 21:33:20 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960A21A90DE for ; Mon, 4 May 2015 21:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.21 X-Spam-Level: X-Spam-Status: No, score=-12.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 zjC1ofRp3fiT for ; Mon, 4 May 2015 21:33:15 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19471A90BA for ; Mon, 4 May 2015 21:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10385; q=dns/txt; s=iport; t=1430800395; x=1432009995; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=InV+hxXbaOBen0BaHVe2zNshsMxBO+ECgnpgfrdfSE8=; b=EJqw0MtiJ0uXUa5jUpKLBfMsT0G9hvi1v74XpiVCdc5of/tKGHNKvx2y KYKd/7rSv2NqdK/C28fGCjbOZGx2nMmlHzJ3fj8sgEmg9yaFcEXXHl/Ky 6cirf7nKPHccaQ2vuGr0pMa4T44GVJMghKPMTf7xIjS/FMqXapkJda2+h g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ATBQBsR0hV/4kNJK1cgwxTXMUTgjsBCYU3TgKBN0wBAQEBAQGBC4QhAQEEAQEBawsQAgEINQoHJwsUEQIEDgWIKw3GKAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEizmFAQQHgxeBFgWGU4kPgiuEEYZBgSSDUoJyjjYjg3RvgkUBAQE X-IronPort-AV: E=Sophos;i="5.13,370,1427760000"; d="scan'208,217";a="9226964" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP; 05 May 2015 04:33:15 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t454XDRZ032206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 May 2015 04:33:14 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.45]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Mon, 4 May 2015 23:33:13 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Ben Campbell Thread-Topic: [avtext] AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 Thread-Index: AQHQhbmCgRDECA8cB0+ccD2V/f+JvZ1szb75 Date: Tue, 5 May 2015 04:33:13 +0000 Message-ID: <0E3DA6F1-7E6D-4AFE-8CEC-8B86B91ED32A@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_0E3DA6F17E6D4AFE8CEC8B86B91ED32Aciscocom_" MIME-Version: 1.0 Archived-At: Cc: "avtext@ietf.org" , "draft-ietf-avtext-rtp-grouping-taxonomy.all@ietf.org" Subject: Re: [avtext] AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 04:33:17 -0000 --_000_0E3DA6F17E6D4AFE8CEC8B86B91ED32Aciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks, Ben. I'll let Bo, as editor, comment on the editorials/nits but I'= ll offer my perspective on the two major issues you raise. Responses inline... On May 3, 2015, at 11:55 PM, Ben Campbell > wrote: Hi, Here's my AD Evaluation of draft-ietf-avtext-rtp-grouping-taxonomy-06. Noth= ing here is sufficient to delay the IETF last call, but I'd like to at leas= t see a response to the subtsantive comments. Thanks! Ben. ---------------- Substantive Comments: -- I do not object to this being informational per se, but I wonder if peop= le expect it to be normatively references by future standards track documen= ts. Remember that a reference should be normative if it is needed to unders= tand the dependent document. Terminology references often fall squarely int= o that category. If the answer is yes, has there been any considerations th= at this draft may need to be standards track? There seems to be some subjectivity here based on some related discussions = in the past with Pete Resnick on similar type documents. This can, does and= will have documents referencing it normatively. In fact, there is a docum= ent with the RFC Editor now that is being held up because of a normative re= ference to this document (as you are likely familiar: https://datatracker.i= etf.org/doc/draft-ietf-dart-dscp-rtp/). From that perspective I think this= is Standards Track, but again, -- Along the same lines, all the references informational. Could a reader b= e expected to understand this draft without reading _any_ of the references= ? I recognize this may not be important for an informational draft that is = not a technical specification. But it may be more important if standards tr= ack docs normatively reference this doc. Nits and Editorial Comments: -- Abstract: "... attempts to define..." Is there a concern that it may not have succeeded? :-) -- Section 1, 1st sentence: Do you think RTP terminology will continue to be confusing and inconsistent= after this draft is published? Also, please expand RTP in the first use in= the body. (In addition to the abstract.) -- 2.1.2: Do you consider the meaning of the term "Media" to be clear enough that it = doesn't need a definition here? I find it hard to parse the following sentence: "This data is due to its periodical sampling, or at least being timed async= hronous events, some form of a stream of media data. " -- 2.1.2, 2nd bullet list entry: s/support/supports -- 2.1.4, first sentence I find the sentence hard to parse: -- 2.1.5 Was the "raw stream" not also time-progressing? -- 2.1.9, first bullet list entry: I can't parse the sentence. Is there a missing word towards the end? -- 2.1.18 "... alarm subsequent transformations ... " Do you mean "alert"? -- 2.2.3, first bullet list entry: is the SIP URI example assumed to be an Address of Record? If so, it might = be worth mentioning that, since a SIP URI could also point to a device, and= a participant might have more than one. -- 3.7, last paragraph, 2nd sentence: Sentence is convoluted and hard to read. Please consider splitting it into = multiple simpler sentences. -- 3.8, first paragraph, 2nd sentence: Convoluted sentence. -- 3.9, last paragraph: Convoluted sentence. -- 3.10, last paragaph, last sentence: Convoluted sentence. -- 3.11, last paragraph : "This requires to either use..." Missing noun? ("This requires XXX to use either", or "This requires the us= e of either...") 3.13, first paragraph, last sentence: I can=92t parse the sentence=97is there a word missing? (i.e. =93=85 and sm= aller number of flow based=85=94)? _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext --_000_0E3DA6F17E6D4AFE8CEC8B86B91ED32Aciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thanks, Ben.  I'll let Bo, as editor, comment on the editorials/n= its but I'll offer my perspective on the two major issues you raise.

Responses inline...

On May 3, 2015, at 11:55 PM, Ben Campbell <ben@nostrum.com> wrote:

Hi,

Here's my AD Evaluation of draft-ietf-avtext-rtp-grouping-taxonomy-06= . Nothing here is sufficient to delay the IETF last call, but I'd like to a= t least see a response to the subtsantive comments.

Thanks!

Ben.

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

Substantive Comments:

-- I do not object to this being informational per se, but I wonder i= f people expect it to be normatively references by future standards track d= ocuments. Remember that a reference should be normative if it is needed to = understand the dependent document. Terminology references often fall squarely into that category. If the answ= er is yes, has there been any considerations that this draft may need to be= standards track?

There seems to be some subjectivity here based on some related discussions = in the past with Pete Resnick on similar type documents. This can, does and= will have documents referencing it normatively.  In fact, there is a = document with the RFC Editor now that is being held up because of a normative reference to this document (as you= are likely familiar: https://datatracker.ietf.org/doc/draft-ietf-dart-dsc= p-rtp/).  From that perspective I think this is Standards Track, but again,

-- Along the same lines, all the references informa= tional. Could a reader be expected to understand this draft without reading= _any_ of the references? I recognize this may not be important for an info= rmational draft that is not a technical specification. But it may be more important if standards track docs normat= ively reference this doc.


Nits and Editorial Comments:

-- Abstract: "... attempts to define..."

Is there a concern that it may not have succeeded?  :-)
-- Section 1, 1st sentence:

Do you think RTP terminology will continue to be confusing and incons= istent after this draft is published? Also, please expand RTP in the first = use in the body. (In addition to the abstract.)

-- 2.1.2:

Do you consider the meaning of the term "Media" to be clear= enough that it doesn't need a definition here?

I find it hard to parse the following sentence:

"This data is due to its periodical sampling, or at least being = timed asynchronous events, some form of a stream of media data. "

-- 2.1.2, 2nd bullet list entry:

s/support/supports

-- 2.1.4, first sentence

I find the sentence hard to parse:

-- 2.1.5

Was the "raw stream" not also time-progressing?

-- 2.1.9, first bullet list entry:

I can't parse the sentence. Is there a missing word towards the end?<= /span>

-- 2.1.18 "... alarm subsequent transformations ... "

Do you mean "alert"?

-- 2.2.3, first bullet list entry:

is the SIP URI example assumed to be an Address of Record? If so, it = might be worth mentioning that, since a SIP URI could also point to a devic= e, and a participant might have more than one.

-- 3.7, last paragraph, 2nd sentence:

Sentence is convoluted and hard to read. Please consider splitting it= into multiple simpler sentences.

-- 3.8, first paragraph, 2nd sentence:

Convoluted sentence.

-- 3.9, last paragraph:

Convoluted sentence.

-- 3.10, last paragaph, last sentence:

Convoluted sentence.

-- 3.11, last paragraph : "This requires to either use..."<= /span>

Missing noun?  ("This requires XXX to use either", or = "This requires the use of either...")

3.13, first paragraph, last sentence:

I can=92t parse the sentence=97is there a word missing? (i.e. =93=85 = and smaller number of flow based=85=94)?


_______________________________________________
avtext mailing list
avtext@ietf.org
https://www.= ietf.org/mailman/listinfo/avtext
--_000_0E3DA6F17E6D4AFE8CEC8B86B91ED32Aciscocom_-- From nobody Mon May 4 21:39:22 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF95A1A90DE for ; Mon, 4 May 2015 21:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.21 X-Spam-Level: X-Spam-Status: No, score=-12.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 J5xsonjEQl6y for ; Mon, 4 May 2015 21:39:17 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D24AF1A90A2 for ; Mon, 4 May 2015 21:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11573; q=dns/txt; s=iport; t=1430800757; x=1432010357; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sb2uf+weffHILoFXFQMU7lT3Lhy8Xef5FC0c8N3iMb8=; b=l6WI3RCOA+zqLR9l+SpKXngJ0Lkn1qnK4/xcXhfphJ38SxPsXpr5DER6 UckIP9yB11wP6m6/tFe//2DKz2DBAxxwZmUwUq8+YjyByjx5S4tUUEdgR d3So72Js+QGt04vm2WRk7E6rVvhkju/P/MEVovZGU6NzaGFwqkjO/hYoR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ATBQDISEhV/5RdJa1cgwxTXMUTgjsBCYU3TgKBN0wBAQEBAQGBC4QhAQEEAQEBawsQAgE9CgcnCxQRAgQOBYgrDcYlAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSQOgQHgxeBFgWGU4kPgiuEEYZBgSSDUoJyjjYjg3RvgkUBAQE X-IronPort-AV: E=Sophos;i="5.13,370,1427760000"; d="scan'208,217";a="413945564" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-1.cisco.com with ESMTP; 05 May 2015 04:39:16 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t454dFIS009584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 May 2015 04:39:15 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.45]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Mon, 4 May 2015 23:39:15 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Ben Campbell Thread-Topic: [avtext] AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 Thread-Index: AQHQhbmCgRDECA8cB0+ccD2V/f+JvZ1szb75gAABsOM= Date: Tue, 5 May 2015 04:39:14 +0000 Message-ID: <7098F21E-7DA7-45B8-B953-048ABE0A86A9@cisco.com> References: , <0E3DA6F1-7E6D-4AFE-8CEC-8B86B91ED32A@cisco.com> In-Reply-To: <0E3DA6F1-7E6D-4AFE-8CEC-8B86B91ED32A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7098F21E7DA745B8B953048ABE0A86A9ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "avtext@ietf.org" , "draft-ietf-avtext-rtp-grouping-taxonomy.all@ietf.org" Subject: [avtext] AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 04:39:20 -0000 --_000_7098F21E7DA745B8B953048ABE0A86A9ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry, writing this on phone and hit send prematurely. Thanks, Ben. I'll let Bo, as editor, comment on the editorials/nits but I'= ll offer my perspective on the two major issues you raise. Responses inline... On May 3, 2015, at 11:55 PM, Ben Campbell > wrote: Hi, Here's my AD Evaluation of draft-ietf-avtext-rtp-grouping-taxonomy-06. Noth= ing here is sufficient to delay the IETF last call, but I'd like to at leas= t see a response to the subtsantive comments. Thanks! Ben. ---------------- Substantive Comments: -- I do not object to this being informational per se, but I wonder if peop= le expect it to be normatively references by future standards track documen= ts. Remember that a reference should be normative if it is needed to unders= tand the dependent document. Terminology references often fall squarely int= o that category. If the answer is yes, has there been any considerations th= at this draft may need to be standards track? There seems to be some subjectivity here based on some related discussions = in the past with Pete Resnick on similar type documents. This can, does and= will have documents referencing it normatively. In fact, there is a docum= ent with the RFC Editor now that is being held up because of a normative re= ference to this document (as you are likely familiar: https://datatracker.i= etf.org/doc/draft-ietf-dart-dscp-rtp/). From that perspective I think this= is Standards Track, but again, thi seems a matter of opinion and I'm fine = either way. -- Along the same lines, all the references informational. Could a reader b= e expected to understand this draft without reading _any_ of the references= ? I recognize this may not be important for an informational draft that is = not a technical specification. But it may be more important if standards tr= ack docs normatively reference this doc. Again, I agree that there are Normative references, though I think for the = purpose of a taxonomy document they can be used sparingly and there is I ne= ed to delay publication with a normative reference to an I-D. Cheers, Gonzalo Nits and Editorial Comments: -- Abstract: "... attempts to define..." Is there a concern that it may not have succeeded? :-) -- Section 1, 1st sentence: Do you think RTP terminology will continue to be confusing and inconsistent= after this draft is published? Also, please expand RTP in the first use in= the body. (In addition to the abstract.) -- 2.1.2: Do you consider the meaning of the term "Media" to be clear enough that it = doesn't need a definition here? I find it hard to parse the following sentence: "This data is due to its periodical sampling, or at least being timed async= hronous events, some form of a stream of media data. " -- 2.1.2, 2nd bullet list entry: s/support/supports -- 2.1.4, first sentence I find the sentence hard to parse: -- 2.1.5 Was the "raw stream" not also time-progressing? -- 2.1.9, first bullet list entry: I can't parse the sentence. Is there a missing word towards the end? -- 2.1.18 "... alarm subsequent transformations ... " Do you mean "alert"? -- 2.2.3, first bullet list entry: is the SIP URI example assumed to be an Address of Record? If so, it might = be worth mentioning that, since a SIP URI could also point to a device, and= a participant might have more than one. -- 3.7, last paragraph, 2nd sentence: Sentence is convoluted and hard to read. Please consider splitting it into = multiple simpler sentences. -- 3.8, first paragraph, 2nd sentence: Convoluted sentence. -- 3.9, last paragraph: Convoluted sentence. -- 3.10, last paragaph, last sentence: Convoluted sentence. -- 3.11, last paragraph : "This requires to either use..." Missing noun? ("This requires XXX to use either", or "This requires the us= e of either...") 3.13, first paragraph, last sentence: I can=92t parse the sentence=97is there a word missing? (i.e. =93=85 and sm= aller number of flow based=85=94)? _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext --_000_7098F21E7DA745B8B953048ABE0A86A9ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Sorry, writing this on phone and hit send prematurely.


Thanks, Ben.  I'll let Bo, as editor, comment on the editorials/n= its but I'll offer my perspective on the two major issues you raise.

Responses inline...

On May 3, 2015, at 11:55 PM, Ben Campbell <ben@nostrum.com> wrote:

Hi,

Here's my AD Evaluation of draft-ietf-avtext-rtp-grouping-taxonomy-06= . Nothing here is sufficient to delay the IETF last call, but I'd like to a= t least see a response to the subtsantive comments.

Thanks!

Ben.

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

Substantive Comments:

-- I do not object to this being informational per se, but I wonder i= f people expect it to be normatively references by future standards track d= ocuments. Remember that a reference should be normative if it is needed to = understand the dependent document. Terminology references often fall squarely into that category. If the answ= er is yes, has there been any considerations that this draft may need to be= standards track?

There seems to be some subjectivity here based on some related discuss= ions in the past with Pete Resnick on similar type documents. This can, doe= s and will have documents referencing it normatively.  In fact, there = is a document with the RFC Editor now that is being held up because of a normative reference to this document (a= s you are likely familiar: https://datatracker.ietf.org/doc/draft-ietf-dar= t-dscp-rtp/).  From that perspective I think this is Standards Track, but again, thi seems a matter of opinion = and I'm fine either way.

-- Along the same lines, all the references informa= tional. Could a reader be expected to understand this draft without reading= _any_ of the references? I recognize this may not be important for an info= rmational draft that is not a technical specification. But it may be more important if standards track docs normat= ively reference this doc.

Again, I agree that there are Normative references, though I think for the = purpose of a taxonomy document they can be used sparingly and there is I ne= ed to delay publication with a normative reference to an I-D.

Cheers,

Gonzalo


Nits and Editorial Comments:

-- Abstract: "... attempts to define..."

Is there a concern that it may not have succeeded?  :-)
-- Section 1, 1st sentence:

Do you think RTP terminology will continue to be confusing and incons= istent after this draft is published? Also, please expand RTP in the first = use in the body. (In addition to the abstract.)

-- 2.1.2:

Do you consider the meaning of the term "Media" to be clear= enough that it doesn't need a definition here?

I find it hard to parse the following sentence:

"This data is due to its periodical sampling, or at least being = timed asynchronous events, some form of a stream of media data. "

-- 2.1.2, 2nd bullet list entry:

s/support/supports

-- 2.1.4, first sentence

I find the sentence hard to parse:

-- 2.1.5

Was the "raw stream" not also time-progressing?

-- 2.1.9, first bullet list entry:

I can't parse the sentence. Is there a missing word towards the end?<= /span>

-- 2.1.18 "... alarm subsequent transformations ... "

Do you mean "alert"?

-- 2.2.3, first bullet list entry:

is the SIP URI example assumed to be an Address of Record? If so, it = might be worth mentioning that, since a SIP URI could also point to a devic= e, and a participant might have more than one.

-- 3.7, last paragraph, 2nd sentence:

Sentence is convoluted and hard to read. Please consider splitting it= into multiple simpler sentences.

-- 3.8, first paragraph, 2nd sentence:

Convoluted sentence.

-- 3.9, last paragraph:

Convoluted sentence.

-- 3.10, last paragaph, last sentence:

Convoluted sentence.

-- 3.11, last paragraph : "This requires to either use..."<= /span>

Missing noun?  ("This requires XXX to use either", or = "This requires the use of either...")

3.13, first paragraph, last sentence:

I can=92t parse the sentence=97is there a word missing? (i.e. =93=85 = and smaller number of flow based=85=94)?


_______________________________________________
avtext mailing list
avtext@ietf.org
https://www.= ietf.org/mailman/listinfo/avtext
--_000_7098F21E7DA745B8B953048ABE0A86A9ciscocom_-- From nobody Tue May 5 02:39:49 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0471B1A701C for ; Tue, 5 May 2015 02:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 5zhVhE4g-Ef3 for ; Tue, 5 May 2015 02:39:43 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 3E1941A6FFF for ; Tue, 5 May 2015 02:39:42 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id B6A7D5799BA01; Tue, 5 May 2015 09:39:39 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t459de21004808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 May 2015 11:39:41 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 5 May 2015 11:39:40 +0200 From: "DRAGE, Keith (Keith)" To: Stephan Wenger , "avtext@ietf.org" Thread-Topic: Stephan's patent disclosure needs against draft-berger-avtext-framemarking-00 Thread-Index: AQHQhpI0KAM7dkF47EGIzSaX9iZ7I51tHOQg Date: Tue, 5 May 2015 09:39:40 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B6970EDCD@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B6970EDCDFR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Subject: Re: [avtext] Stephan's patent disclosure needs against draft-berger-avtext-framemarking-00 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 09:39:45 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B6970EDCDFR712WXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you or completing on that. Keith ________________________________ From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: 04 May 2015 18:46 To: avtext@ietf.org Subject: [avtext] Stephan's patent disclosure needs against draft-berger-av= text-framemarking-00 Hi AVTEXT, In Dallas, during the AVTEXT session, I made a remark that I may have to di= sclose IPR against draft-berger-avtext-framemarking-00. I have since revie= wed the cases in question, and came to the conclusion that, at this point i= n time, I do not have personal knowledge of IPR related to this draft that = I would need to disclose. Sorry for the false alarm. Regards, Stephan --_000_949EF20990823C4C85C18D59AA11AD8B6970EDCDFR712WXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thank you or compl= eting on that.
&nbs= p;
Keith

From: avtext [mailto:avtext-bounces= @ietf.org] On Behalf Of Stephan Wenger
Sent: 04 May 2015 18:46
To: avtext@ietf.org
Subject: [avtext] Stephan's patent disclosure needs against draft-be= rger-avtext-framemarking-00

Hi AVTEXT,
In Dallas, during the AVTEXT session, I made a remark that I may have = to disclose IPR against draft-berger-avtext-framemarking-00.  I have s= ince reviewed the cases in question, and came to the conclusion that, at th= is point in time, I do not have personal knowledge of IPR related to this draft that I would need to disclose.
Sorry for the false alarm.
Regards,
Stephan
--_000_949EF20990823C4C85C18D59AA11AD8B6970EDCDFR712WXCHMBA11z_-- From nobody Tue May 5 02:39:51 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21EA1A6FFF; Tue, 5 May 2015 02:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.61 X-Spam-Level: X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3, RCVD_IN_DNSWL_HI=-5, 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 Fe8cj68_-TB5; Tue, 5 May 2015 02:39:43 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 3E1E71A7014; Tue, 5 May 2015 02:39:42 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 338C3F0F87552; Tue, 5 May 2015 09:39:39 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t459deoo002620 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 May 2015 11:39:41 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 5 May 2015 11:39:40 +0200 From: "DRAGE, Keith (Keith)" To: Ben Campbell , "draft-ietf-avtext-rtp-grouping-taxonomy.all@ietf.org" , "avtext@ietf.org" Thread-Topic: AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 Thread-Index: AQHQhbmEtivykdBpzEWwqEZBdyAwDJ1tGJJw Date: Tue, 5 May 2015 09:39:39 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B6970EDC6@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [avtext] AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 09:39:45 -0000 In regard to the critical questions here, on whether this is a normative do= cument, and whether standards track documents will need to make reference t= o this document. 1) I would appreciate input as to whether there are other statements about = the distinction between normative and informative references other than RFC= 7322 (which is in itself informative!). What essentially boils down to two= lines here do not really make things crystal clear to me. 2) Other SDO's have different approaches. The original ISO rules I believe = made the terminology clause of documents normative. ETSI in updating those = rules for its own use have made such section informative (I believe because= terminology sections are required to contain no normative requirements). 3) The underlying terminology definition for all RFCs is Websters dictionar= y. Is this normative material? As document shepherd for this document, I had no problem with the "Informat= ional" status of this document based on the fact that it contained no norma= tive provisions.=20 A document referencing this document will therefore not be able to import a= ny normative provisions. Therefore at that level any references to the docu= ment can be informative.=20 The problem comes with the second part of "essential to implementing or und= erstanding the content of the RFC" (RFC 7322). At what level to understandi= ng the content does a reference to terminology have to become normative? I'= d note that in existing RFCs many more normative references would be requir= ed, and many informative references become normative, if a very rigorous in= terpretation of this part is made. Conclusion. I need more input, and list discussion would be appreciated. Keith > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: 03 May 2015 16:55 > To: draft-ietf-avtext-rtp-grouping-taxonomy.all@ietf.org;=20 > avtext@ietf.org > Subject: AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 >=20 > Hi, >=20 > Here's my AD Evaluation of=20 > draft-ietf-avtext-rtp-grouping-taxonomy-06.=20 > Nothing here is sufficient to delay the IETF last call, but=20 > I'd like to at least see a response to the subtsantive comments. >=20 > Thanks! >=20 > Ben. >=20 > ---------------- >=20 > Substantive Comments: >=20 > -- I do not object to this being informational per se, but I=20 > wonder if people expect it to be normatively references by=20 > future standards track documents. Remember that a reference=20 > should be normative if it is needed to understand the=20 > dependent document. Terminology references often fall=20 > squarely into that category. If the answer is yes, has there=20 > been any considerations that this draft may need to be=20 > standards track? >=20 > -- Along the same lines, all the references informational.=20 > Could a reader be expected to understand this draft without=20 > reading _any_ of the references? I recognize this may not be=20 > important for an informational draft that is not a technical=20 > specification. But it may be more important if standards=20 > track docs normatively reference this doc. >=20 >=20 > Nits and Editorial Comments: >=20 > -- Abstract: "... attempts to define..." >=20 > Is there a concern that it may not have succeeded? :-) >=20 > -- Section 1, 1st sentence: >=20 > Do you think RTP terminology will continue to be confusing=20 > and inconsistent after this draft is published? Also, please=20 > expand RTP in the first use in the body. (In addition to the=20 > abstract.) >=20 > -- 2.1.2: >=20 > Do you consider the meaning of the term "Media" to be clear=20 > enough that it doesn't need a definition here? >=20 > I find it hard to parse the following sentence: >=20 > "This data is due to its periodical sampling, or at least=20 > being timed asynchronous events, some form of a stream of=20 > media data. " >=20 > -- 2.1.2, 2nd bullet list entry: >=20 > s/support/supports >=20 > -- 2.1.4, first sentence >=20 > I find the sentence hard to parse: >=20 > -- 2.1.5 >=20 > Was the "raw stream" not also time-progressing? >=20 > -- 2.1.9, first bullet list entry: >=20 > I can't parse the sentence. Is there a missing word towards the end? >=20 > -- 2.1.18 "... alarm subsequent transformations ... " >=20 > Do you mean "alert"? >=20 > -- 2.2.3, first bullet list entry: >=20 > is the SIP URI example assumed to be an Address of Record? If=20 > so, it might be worth mentioning that, since a SIP URI could=20 > also point to a device, and a participant might have more than one. >=20 > -- 3.7, last paragraph, 2nd sentence: >=20 > Sentence is convoluted and hard to read. Please consider=20 > splitting it into multiple simpler sentences. >=20 > -- 3.8, first paragraph, 2nd sentence: >=20 > Convoluted sentence. >=20 > -- 3.9, last paragraph: >=20 > Convoluted sentence. >=20 > -- 3.10, last paragaph, last sentence: >=20 > Convoluted sentence. >=20 > -- 3.11, last paragraph : "This requires to either use..." >=20 > Missing noun? ("This requires XXX to use either", or "This=20 > requires the use of either...") >=20 > 3.13, first paragraph, last sentence: >=20 > I can't parse the sentence-is there a word missing? (i.e. "...=20 > and smaller number of flow based...")? >=20 >=20 > = From nobody Tue May 5 04:04:05 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE741A8A9D; Tue, 5 May 2015 04:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3, 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 AKL0WFbMAvjX; Tue, 5 May 2015 04:04:01 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9E3B71A8ADA; Tue, 5 May 2015 03:59:07 -0700 (PDT) Received: from [10.10.1.5] (mpdedicated.com [50.97.142.159] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t45AvlS3049876 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2015 05:57:49 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mpdedicated.com [50.97.142.159] (may be forged) claimed to be [10.10.1.5] From: "Ben Campbell" To: "DRAGE, Keith (Keith)" Date: Tue, 05 May 2015 11:57:48 +0100 Message-ID: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6970EDC6@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B6970EDC6@FR712WXCHMBA11.zeu.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "avtext@ietf.org" , "draft-ietf-avtext-rtp-grouping-taxonomy.all@ietf.org" Subject: Re: [avtext] AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 11:04:03 -0000 I have some discussion with other ADs on this. The rules are a bit subjective. On my two questions: 1) Does this draft need to be standards track: It's not necessary at this point. It might have made things slightly easier for future drafts that need to reference it, but its probably not worth changing at this point in the process. We have a process for allowing normative references to lower maturity documents. Doing so to incorporate terminology from informational docs is a common use for this. 2) Do any of the references in this draft need to be normative? tl;dr: Informative dependencies of the form of "See [XXX] for term definitions" have been attractive targets for discuss positions for the currently sitting IESG. Long Answer: I agree we have not been consistent about this. But there is considerable risk one or more sitting ADs will consider the complete lack of normative references as a red flag. If that really is the right thing to do, we will need to be prepared to defend it. The "essential to understand" rule should be considered. Whether a given dependency for terminology purposes should be normative really depends on whether that terminology is necessary to understand this doc. The authors and working group are probably in the best position to judge if this applies to any specific dependency. The fact that this draft is itself informational doesn't really change anything, although there's some vagueness about how that rule applies for drafts that do not contain specifications. (It's also vague whether "terminology" can count as specification.) I realize here that some of the impetus to avoid normative references comes from the fact that many of the dependencies are to works-in-progress. But in general, that should not be the deciding factor, except in cases where the decision would have been a coin flip otherwise. Thanks! Ben. On 5 May 2015, at 10:39, DRAGE, Keith (Keith) wrote: > In regard to the critical questions here, on whether this is a > normative document, and whether standards track documents will need to > make reference to this document. > > 1) I would appreciate input as to whether there are other statements > about the distinction between normative and informative references > other than RFC 7322 (which is in itself informative!). What > essentially boils down to two lines here do not really make things > crystal clear to me. > > 2) Other SDO's have different approaches. The original ISO rules I > believe made the terminology clause of documents normative. ETSI in > updating those rules for its own use have made such section > informative (I believe because terminology sections are required to > contain no normative requirements). > > 3) The underlying terminology definition for all RFCs is Websters > dictionary. Is this normative material? > > As document shepherd for this document, I had no problem with the > "Informational" status of this document based on the fact that it > contained no normative provisions. > > A document referencing this document will therefore not be able to > import any normative provisions. Therefore at that level any > references to the document can be informative. > > The problem comes with the second part of "essential to implementing > or understanding the content of the RFC" (RFC 7322). At what level to > understanding the content does a reference to terminology have to > become normative? I'd note that in existing RFCs many more normative > references would be required, and many informative references become > normative, if a very rigorous interpretation of this part is made. > > Conclusion. I need more input, and list discussion would be > appreciated. > > Keith > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: 03 May 2015 16:55 >> To: draft-ietf-avtext-rtp-grouping-taxonomy.all@ietf.org; >> avtext@ietf.org >> Subject: AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 >> >> Hi, >> >> Here's my AD Evaluation of >> draft-ietf-avtext-rtp-grouping-taxonomy-06. >> Nothing here is sufficient to delay the IETF last call, but >> I'd like to at least see a response to the subtsantive comments. >> >> Thanks! >> >> Ben. >> >> ---------------- >> >> Substantive Comments: >> >> -- I do not object to this being informational per se, but I >> wonder if people expect it to be normatively references by >> future standards track documents. Remember that a reference >> should be normative if it is needed to understand the >> dependent document. Terminology references often fall >> squarely into that category. If the answer is yes, has there >> been any considerations that this draft may need to be >> standards track? >> >> -- Along the same lines, all the references informational. >> Could a reader be expected to understand this draft without >> reading _any_ of the references? I recognize this may not be >> important for an informational draft that is not a technical >> specification. But it may be more important if standards >> track docs normatively reference this doc. >> >> >> Nits and Editorial Comments: >> >> -- Abstract: "... attempts to define..." >> >> Is there a concern that it may not have succeeded? :-) >> >> -- Section 1, 1st sentence: >> >> Do you think RTP terminology will continue to be confusing >> and inconsistent after this draft is published? Also, please >> expand RTP in the first use in the body. (In addition to the >> abstract.) >> >> -- 2.1.2: >> >> Do you consider the meaning of the term "Media" to be clear >> enough that it doesn't need a definition here? >> >> I find it hard to parse the following sentence: >> >> "This data is due to its periodical sampling, or at least >> being timed asynchronous events, some form of a stream of >> media data. " >> >> -- 2.1.2, 2nd bullet list entry: >> >> s/support/supports >> >> -- 2.1.4, first sentence >> >> I find the sentence hard to parse: >> >> -- 2.1.5 >> >> Was the "raw stream" not also time-progressing? >> >> -- 2.1.9, first bullet list entry: >> >> I can't parse the sentence. Is there a missing word towards the end? >> >> -- 2.1.18 "... alarm subsequent transformations ... " >> >> Do you mean "alert"? >> >> -- 2.2.3, first bullet list entry: >> >> is the SIP URI example assumed to be an Address of Record? If >> so, it might be worth mentioning that, since a SIP URI could >> also point to a device, and a participant might have more than one. >> >> -- 3.7, last paragraph, 2nd sentence: >> >> Sentence is convoluted and hard to read. Please consider >> splitting it into multiple simpler sentences. >> >> -- 3.8, first paragraph, 2nd sentence: >> >> Convoluted sentence. >> >> -- 3.9, last paragraph: >> >> Convoluted sentence. >> >> -- 3.10, last paragaph, last sentence: >> >> Convoluted sentence. >> >> -- 3.11, last paragraph : "This requires to either use..." >> >> Missing noun? ("This requires XXX to use either", or "This >> requires the use of either...") >> >> 3.13, first paragraph, last sentence: >> >> I can't parse the sentence-is there a word missing? (i.e. "... >> and smaller number of flow based...")? >> >> >> From nobody Tue May 5 04:04:29 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECBE1A88E6; Tue, 5 May 2015 04:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3, 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 etRnj6WrzNah; Tue, 5 May 2015 04:04:25 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 BFE961A88ED; Tue, 5 May 2015 03:59:22 -0700 (PDT) Received: from [10.10.1.5] (mpdedicated.com [50.97.142.159] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t45AxHoH050016 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2015 05:59:19 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mpdedicated.com [50.97.142.159] (may be forged) claimed to be [10.10.1.5] From: "Ben Campbell" To: "Gonzalo Salgueiro (gsalguei)" Date: Tue, 05 May 2015 11:59:18 +0100 Message-ID: <621CBE29-88FF-4D06-80A0-695F688A07BF@nostrum.com> In-Reply-To: <7098F21E-7DA7-45B8-B953-048ABE0A86A9@cisco.com> References: <0E3DA6F1-7E6D-4AFE-8CEC-8B86B91ED32A@cisco.com> <7098F21E-7DA7-45B8-B953-048ABE0A86A9@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "avtext@ietf.org" , "draft-ietf-avtext-rtp-grouping-taxonomy.all@ietf.org" Subject: Re: [avtext] AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 11:04:26 -0000 Hi Gonzalo, I saw Keith's mail first, and replied to it. Please let me know if that failed to cover anything from your email. Thanks! Ben. On 5 May 2015, at 5:39, Gonzalo Salgueiro (gsalguei) wrote: > Sorry, writing this on phone and hit send prematurely. > > > Thanks, Ben. I'll let Bo, as editor, comment on the editorials/nits > but I'll offer my perspective on the two major issues you raise. > > Responses inline... > > On May 3, 2015, at 11:55 PM, Ben Campbell > > wrote: > > Hi, > > Here's my AD Evaluation of draft-ietf-avtext-rtp-grouping-taxonomy-06. > Nothing here is sufficient to delay the IETF last call, but I'd like > to at least see a response to the subtsantive comments. > > Thanks! > > Ben. > > ---------------- > > Substantive Comments: > > -- I do not object to this being informational per se, but I wonder if > people expect it to be normatively references by future standards > track documents. Remember that a reference should be normative if it > is needed to understand the dependent document. Terminology references > often fall squarely into that category. If the answer is yes, has > there been any considerations that this draft may need to be standards > track? > > There seems to be some subjectivity here based on some related > discussions in the past with Pete Resnick on similar type documents. > This can, does and will have documents referencing it normatively. In > fact, there is a document with the RFC Editor now that is being held > up because of a normative reference to this document (as you are > likely familiar: > https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/). From > that perspective I think this is Standards Track, but again, thi seems > a matter of opinion and I'm fine either way. > > -- Along the same lines, all the references informational. Could a > reader be expected to understand this draft without reading _any_ of > the references? I recognize this may not be important for an > informational draft that is not a technical specification. But it may > be more important if standards track docs normatively reference this > doc. > > Again, I agree that there are Normative references, though I think for > the purpose of a taxonomy document they can be used sparingly and > there is I need to delay publication with a normative reference to an > I-D. > > Cheers, > > Gonzalo > > > Nits and Editorial Comments: > > -- Abstract: "... attempts to define..." > > Is there a concern that it may not have succeeded? :-) > > -- Section 1, 1st sentence: > > Do you think RTP terminology will continue to be confusing and > inconsistent after this draft is published? Also, please expand RTP in > the first use in the body. (In addition to the abstract.) > > -- 2.1.2: > > Do you consider the meaning of the term "Media" to be clear enough > that it doesn't need a definition here? > > I find it hard to parse the following sentence: > > "This data is due to its periodical sampling, or at least being timed > asynchronous events, some form of a stream of media data. " > > -- 2.1.2, 2nd bullet list entry: > > s/support/supports > > -- 2.1.4, first sentence > > I find the sentence hard to parse: > > -- 2.1.5 > > Was the "raw stream" not also time-progressing? > > -- 2.1.9, first bullet list entry: > > I can't parse the sentence. Is there a missing word towards the end? > > -- 2.1.18 "... alarm subsequent transformations ... " > > Do you mean "alert"? > > -- 2.2.3, first bullet list entry: > > is the SIP URI example assumed to be an Address of Record? If so, it > might be worth mentioning that, since a SIP URI could also point to a > device, and a participant might have more than one. > > -- 3.7, last paragraph, 2nd sentence: > > Sentence is convoluted and hard to read. Please consider splitting it > into multiple simpler sentences. > > -- 3.8, first paragraph, 2nd sentence: > > Convoluted sentence. > > -- 3.9, last paragraph: > > Convoluted sentence. > > -- 3.10, last paragaph, last sentence: > > Convoluted sentence. > > -- 3.11, last paragraph : "This requires to either use..." > > Missing noun? ("This requires XXX to use either", or "This requires > the use of either...") > > 3.13, first paragraph, last sentence: > > I can’t parse the sentence—is there a word missing? (i.e. “… > and smaller number of flow based…”)? > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Tue May 5 04:30:05 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D814B1A8A8A; Tue, 5 May 2015 04:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 yxvVXVVPNhpH; Tue, 5 May 2015 04:30:01 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF86F1A8A7C; Tue, 5 May 2015 04:30:00 -0700 (PDT) X-AuditID: c1b4fb30-f798d6d0000009ec-ae-5548a9b64fbe Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 75.5E.02540.6B9A8455; Tue, 5 May 2015 13:29:59 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.210.2; Tue, 5 May 2015 13:29:58 +0200 Message-ID: <5548A9B5.60401@ericsson.com> Date: Tue, 5 May 2015 13:29:57 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , Ben Campbell , "draft-ietf-avtext-rtp-grouping-taxonomy.all@ietf.org" , "avtext@ietf.org" References: <949EF20990823C4C85C18D59AA11AD8B6970EDC6@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6970EDC6@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUyM+Jvje72lR6hBju7GS0+3rvBajG/8zS7 xZezn5gsnjaeZXRg8Wh9tpfVY8mSn0wes3Y+YQlgjuKySUnNySxLLdK3S+DKWPnsL1PBUcGK VxPnsTYw9vN1MXJySAiYSBw9tIsFwhaTuHBvPVsXIxeHkMBRRon1x/+wQDjLGCX+7djODlLF K6Ap0bS1CayDRUBFYtu6G4wgNpuAhcTNH41sILaoQJTExK+HWCDqBSVOznwCNkhE4CujxJkf 81hBEsIC3hIbd+xjgtjQzyixqKmTGSTBKRAr8W9LG9A2Dg5mAXuJB1vLQMLMAvISzVtng5UI CWhLNDR1sE5gFJiFZMcshI5ZSDoWMDKvYhQtTi1Oyk03MtJLLcpMLi7Oz9PLSy3ZxAgM24Nb fhvsYHz53PEQowAHoxIPr4KKR6gQa2JZcWXuIUZpDhYlcV4740MhQgLpiSWp2ampBalF8UWl OanFhxiZODilGhj1hOWUunYYq0w7wLK25vNsdqMzvg0bbk5P/1w5962Ls4S6Veu6y9VMG12/ urcXHSoveduneU9q/bWgGcFe0WpV4Qcr8hn6pvze8Pzpa5XLlhURXCecezlFbfvETIyalh77 zLLt7uPl94ImGjRGxe5NPjLBYs/HngeLA1Wm+EQvO2pqlya9XEuJpTgj0VCLuag4EQAmKK9y PAIAAA== Archived-At: Subject: Re: [avtext] AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 11:30:04 -0000 Hi, I am of the view that this type of documents should continue to be informational. Yes, it creates a terminology that is useful in other documents to provide clear message to the reader. However, it is still just a possible way of describing a small part of the world. Even when using this document, along the line: "Informative dependencies of the form of "See [XXX] for term definitions" have been attractive targets for discuss positions for the currently sitting IESG." I still believe using this as an informational reference is fine. I would note that we use informational reference to protocols also in some situations, its the usage of the term that matters. I think the difference really. For example: This protocol is a high layer foo that can be used over any reliable protocol, such as TCP, SCTP, etc. Then TCP and SCTP is informative. In most cases this general terminology isn't used in such a strict fashion that it must be a normative statement. I also think we need to consider the long term implications if we think that anything that provides a definition of any term that is needed to be understand must be normative and the document must be standards track. Then we will have extremely few uses for informational documents. I do note that this discussion similarly applies to the AVTCORE Topologies document. That is a document which provides a general understanding of what something means, but not always pin-point precise. This documents predecessor RFC 5117 has been cited at least by 14 other RFCs. More than half of these are standard tracks document. I can't remember that we have had any issues with its status. It is also not listed in the downref registry. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue May 5 07:10:04 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417101AD06C; Tue, 5 May 2015 07:09:57 -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 tfIBnJj85ZM9; Tue, 5 May 2015 07:09:54 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 27BF61ACEFC; Tue, 5 May 2015 07:09:17 -0700 (PDT) Received: from [10.10.1.6] (50.97.94.35-static.reverse.softlayer.com [50.97.94.35]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t45E9ABM068531 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2015 09:09:12 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 50.97.94.35-static.reverse.softlayer.com [50.97.94.35] claimed to be [10.10.1.6] From: "Ben Campbell" To: "Magnus Westerlund" Date: Tue, 05 May 2015 15:09:11 +0100 Message-ID: <028B6043-F353-4BAB-9742-3E8E09CBAA07@nostrum.com> In-Reply-To: <5548A9B5.60401@ericsson.com> References: <949EF20990823C4C85C18D59AA11AD8B6970EDC6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5548A9B5.60401@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "avtext@ietf.org" , "draft-ietf-avtext-rtp-grouping-taxonomy.all@ietf.org" Subject: Re: [avtext] AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 14:09:57 -0000 To be clear, I don't think this needs to change to standards track. My main concern is that _this_ draft has no normative dependencies. There are at least some sections that seem, on the surface, to require the reader to read the referenced document to understand the section. This will almost certainly get questioned during IESG review. (I have seen a number of DISCUSS positions on informational "terminology" references. I am open to arguments that this is not true for any specific reference, but I haven't seen such an argument yet. And of course, the related issue is that many of those currently informational dependencies point to works-in-progress. On 5 May 2015, at 12:29, Magnus Westerlund wrote: > Hi, > > I am of the view that this type of documents should continue to be > informational. Yes, it creates a terminology that is useful in other > documents to provide clear message to the reader. However, it is still > just a possible way of describing a small part of the world. > > Even when using this document, along the line: > > "Informative dependencies of the form of "See [XXX] for term > definitions" have been attractive targets for discuss positions for > the currently sitting IESG." > > I still believe using this as an informational reference is fine. I > would note that we use informational reference to protocols also in > some situations, its the usage of the term that matters. I think the > difference really. For example: This protocol is a high layer foo that > can be used over any reliable protocol, such as TCP, SCTP, etc. Then > TCP and SCTP is informative. > > In most cases this general terminology isn't used in such a strict > fashion that it must be a normative statement. > > I also think we need to consider the long term implications if we > think that anything that provides a definition of any term that is > needed to be understand must be normative and the document must be > standards track. Then we will have extremely few uses for > informational documents. > > I do note that this discussion similarly applies to the AVTCORE > Topologies document. That is a document which provides a general > understanding of what something means, but not always pin-point > precise. This documents predecessor RFC 5117 has been cited at least > by 14 other RFCs. More than half of these are standard tracks > document. I can't remember that we have had any issues with its > status. It is also not listed in the downref registry. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From nobody Tue May 5 09:23:17 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972AA1B2F77; Tue, 5 May 2015 09:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-2.3, 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 qTOOEigcGbUZ; Tue, 5 May 2015 09:23:13 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B199B1B2F7B; Tue, 5 May 2015 09:09:59 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-50-5548eb55c757 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 49.87.04401.55BE8455; Tue, 5 May 2015 18:09:57 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.101]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0210.002; Tue, 5 May 2015 18:09:57 +0200 From: Bo Burman To: Ben Campbell , "draft-ietf-avtext-rtp-grouping-taxonomy.all@ietf.org" , "avtext@ietf.org" Thread-Topic: AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 (editorials) Thread-Index: AdCHTKzbI4o52Q1nR42EtHq8LGBxXw== Date: Tue, 5 May 2015 16:09:56 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+JvjW7oa49Qg4nz5S0+3rvBajG/8zS7 xZezn5gcmD2WLPnJ5DFr5xOWAKYoLpuU1JzMstQifbsEroyLG9azFRyzr2jqaGRpYPxi28XI ySEhYCLxeNlzRghbTOLCvfVsXYxcHEICRxkl7r1ezQSSEBJYzCgx8bYHiM0moCExf8ddRpAi EYE9jBLnG3ezgCSEBQIlJm6eww5iiwgESTQ+OcEEYetJNLUfAbNZBFQknrT+YgOxeQV8JabN mcgMYjMKyErc/34PbA6zgLjErSfzmSAuEpBYsuc8M4QtKvHy8T/WLkYOIFtJYtrWNBCTWUBT Yv0ufYhORYkp3Q/ZIaYLSpyc+YRlAqPwLCRDZyF0zELSMQtJxwJGllWMosWpxUm56UbGeqlF mcnFxfl5enmpJZsYgcF/cMtv1R2Ml984HmIU4GBU4uFVUPEIFWJNLCuuzD3EKM3BoiTOa2d8 KERIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDI5e5Es9d99Tv2W9uvj29bne69JVP1XVXk1WW 8NUd2tbA9E2rNbT2kertgq0emd3l+7/qMrq9mFC1cB93n8iq7sye0JsT4sPXvNyS+7Q4gumD 6/ymhjyXX4Gbfqsuso1rirv7zfT20SNdNR9m1m59MFmvTHDpJ7aZK1mNfq1XstSLvbvP68XJ pUosxRmJhlrMRcWJAOPIdWJfAgAA Archived-At: Subject: Re: [avtext] AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 (editorials) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 16:23:16 -0000 SGksDQoNClBsZWFzZSBmaW5kIG15IHJlc3BvbnNlcyB0byB5b3VyIGVkaXRvcmlhbCBjb21tZW50 cyBpbmxpbmUgYmVsb3csIHN0YXJ0aW5nIGEgbmV3IHRocmVhZCB0byBsZWF2ZSBzdWJzdGFudGl2 ZSBjb21tZW50cyBpbiB0aGUgb3JpZ2luYWwgdGhyZWFkLg0KIA0KQ2hlZXJzLA0KQm8NCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW4gQ2FtcGJlbGwgW21haWx0bzpi ZW5Abm9zdHJ1bS5jb21dDQo+IFNlbnQ6IGRlbiAzIG1haiAyMDE1IDE3OjU1DQo+IFRvOiBkcmFm dC1pZXRmLWF2dGV4dC1ydHAtZ3JvdXBpbmctdGF4b25vbXkuYWxsQGlldGYub3JnOyBhdnRleHRA aWV0Zi5vcmcNCj4gU3ViamVjdDogQUQgRXZhbCBvZiBkcmFmdC1pZXRmLWF2dGV4dC1ydHAtZ3Jv dXBpbmctdGF4b25vbXktMDYNCj4gDQo+IEhpLA0KPiANCj4gSGVyZSdzIG15IEFEIEV2YWx1YXRp b24gb2YgZHJhZnQtaWV0Zi1hdnRleHQtcnRwLWdyb3VwaW5nLXRheG9ub215LTA2Lg0KPiBOb3Ro aW5nIGhlcmUgaXMgc3VmZmljaWVudCB0byBkZWxheSB0aGUgSUVURiBsYXN0IGNhbGwsIGJ1dCBJ J2QgbGlrZSB0byBhdCBsZWFzdCBzZWUgYSByZXNwb25zZSB0byB0aGUgc3VidHNhbnRpdmUgY29t bWVudHMuDQo+IA0KPiBUaGFua3MhDQo+IA0KPiBCZW4uDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0t DQo+IA0KPiBTdWJzdGFudGl2ZSBDb21tZW50czoNCj4gDQo+IC0tIEkgZG8gbm90IG9iamVjdCB0 byB0aGlzIGJlaW5nIGluZm9ybWF0aW9uYWwgcGVyIHNlLCBidXQgSSB3b25kZXIgaWYgcGVvcGxl IGV4cGVjdCBpdCB0byBiZSBub3JtYXRpdmVseSByZWZlcmVuY2VzIGJ5DQo+IGZ1dHVyZSBzdGFu ZGFyZHMgdHJhY2sgZG9jdW1lbnRzLiBSZW1lbWJlciB0aGF0IGEgcmVmZXJlbmNlIHNob3VsZCBi ZSBub3JtYXRpdmUgaWYgaXQgaXMgbmVlZGVkIHRvIHVuZGVyc3RhbmQgdGhlDQo+IGRlcGVuZGVu dCBkb2N1bWVudC4gVGVybWlub2xvZ3kgcmVmZXJlbmNlcyBvZnRlbiBmYWxsIHNxdWFyZWx5IGlu dG8gdGhhdCBjYXRlZ29yeS4gSWYgdGhlIGFuc3dlciBpcyB5ZXMsIGhhcyB0aGVyZSBiZWVuDQo+ IGFueSBjb25zaWRlcmF0aW9ucyB0aGF0IHRoaXMgZHJhZnQgbWF5IG5lZWQgdG8gYmUgc3RhbmRh cmRzIHRyYWNrPw0KPiANCj4gLS0gQWxvbmcgdGhlIHNhbWUgbGluZXMsIGFsbCB0aGUgcmVmZXJl bmNlcyBpbmZvcm1hdGlvbmFsLiBDb3VsZCBhIHJlYWRlciBiZSBleHBlY3RlZCB0byB1bmRlcnN0 YW5kIHRoaXMgZHJhZnQgd2l0aG91dA0KPiByZWFkaW5nIF9hbnlfIG9mIHRoZSByZWZlcmVuY2Vz PyBJIHJlY29nbml6ZSB0aGlzIG1heSBub3QgYmUgaW1wb3J0YW50IGZvciBhbiBpbmZvcm1hdGlv bmFsIGRyYWZ0IHRoYXQgaXMgbm90IGEgdGVjaG5pY2FsDQo+IHNwZWNpZmljYXRpb24uIEJ1dCBp dCBtYXkgYmUgbW9yZSBpbXBvcnRhbnQgaWYgc3RhbmRhcmRzIHRyYWNrIGRvY3Mgbm9ybWF0aXZl bHkgcmVmZXJlbmNlIHRoaXMgZG9jLg0KPiANCj4gDQo+IE5pdHMgYW5kIEVkaXRvcmlhbCBDb21t ZW50czoNCj4gDQo+IC0tIEFic3RyYWN0OiAiLi4uIGF0dGVtcHRzIHRvIGRlZmluZS4uLiINCj4g DQo+IElzIHRoZXJlIGEgY29uY2VybiB0aGF0IGl0IG1heSBub3QgaGF2ZSBzdWNjZWVkZWQ/ICA6 LSkNCltCb0JdIE5vIDopIEkgZXhwZWN0IHRoaXMgdGV4dCB0byBiZSBhIHJlbW5hbnQgZnJvbSBl YXJseSBkcmFmdCBzdGFnZXMuIFdpbGwgcmUtZm9ybXVsYXRlLiBHb29kIGNhdGNoLg0KDQo+IA0K PiAtLSBTZWN0aW9uIDEsIDFzdCBzZW50ZW5jZToNCj4gDQo+IERvIHlvdSB0aGluayBSVFAgdGVy bWlub2xvZ3kgd2lsbCBjb250aW51ZSB0byBiZSBjb25mdXNpbmcgYW5kIGluY29uc2lzdGVudCBh ZnRlciB0aGlzIGRyYWZ0IGlzIHB1Ymxpc2hlZD8NCltCb0JdIE5vLiBQcm9iYWJseSBzYW1lIHJl YXNvbiBhcyBhYm92ZS4gV2lsbCBmaW5kIGEgYmV0dGVyIGZvcm11bGF0aW9uLg0KDQogQWxzbywg cGxlYXNlDQo+IGV4cGFuZCBSVFAgaW4gdGhlIGZpcnN0IHVzZSBpbiB0aGUgYm9keS4gKEluIGFk ZGl0aW9uIHRvIHRoZSBhYnN0cmFjdC4pDQpbQm9CXSBPSy4gSSBhbHNvIHRoaW5rIGl0IGFwcHJv cHJpYXRlIHRvIGFkZCBhIHJlZmVyZW5jZSB0byBSRkMgMzU1MCBoZXJlLg0KDQo+IA0KPiAtLSAy LjEuMjoNCj4gDQo+IERvIHlvdSBjb25zaWRlciB0aGUgbWVhbmluZyBvZiB0aGUgdGVybSAiTWVk aWEiIHRvIGJlIGNsZWFyIGVub3VnaCB0aGF0IGl0IGRvZXNuJ3QgbmVlZCBhIGRlZmluaXRpb24g aGVyZT8NCltCb0JdIFRoZSB2ZXJ5IGZpcnN0IHNlbnRlbmNlIG9mIDIuMSBzdGFydHMgd2l0aCAi SW4gdGhlIGNvbnRleHQgb2YgdGhpcyBtZW1vLCBNZWRpYSBpcy4uLiIuIElzIHRoYXQgbm90IHN1 ZmZpY2llbnQ/IEkgdGhpbmsgdGhhdCBpcyBzdWZmaWNpZW50bHkgY2xlYXIuDQoNCj4gDQo+IEkg ZmluZCBpdCBoYXJkIHRvIHBhcnNlIHRoZSBmb2xsb3dpbmcgc2VudGVuY2U6DQo+IA0KPiAiVGhp cyBkYXRhIGlzIGR1ZSB0byBpdHMgcGVyaW9kaWNhbCBzYW1wbGluZywgb3IgYXQgbGVhc3QgYmVp bmcgdGltZWQgYXN5bmNocm9ub3VzIGV2ZW50cywgc29tZSBmb3JtIG9mIGEgc3RyZWFtIG9mIG1l ZGlhDQo+IGRhdGEuICINCltCb0JdIE1heWJlIHJlLWFycmFuZ2luZyB0aGUgc2VudGVuY2UgbWFr ZXMgaXQgbW9yZSBjbGVhcjogIlRoaXMgZGF0YSBpcyBzb21lIGZvcm0gb2Ygc3RyZWFtIG9mIG1l ZGlhIGRhdGEsIGR1ZSB0byBpdHMgcGVyaW9kaWNhbCBzYW1wbGluZyBvciBhcyBhIHNldCBvZiB0 aW1lZCBhc3luY2hyb25vdXMgZXZlbnRzIj8NCg0KPiANCj4gLS0gMi4xLjIsIDJuZCBidWxsZXQg bGlzdCBlbnRyeToNCj4gDQo+IHMvc3VwcG9ydC9zdXBwb3J0cw0KW0JvQl0gT0sNCg0KPiANCj4g LS0gMi4xLjQsIGZpcnN0IHNlbnRlbmNlDQo+IA0KPiBJIGZpbmQgdGhlIHNlbnRlbmNlIGhhcmQg dG8gcGFyc2U6DQpbQm9CXSBXaGF0IGFib3V0IHJlLWFycmFuZ2luZyBpdCA6ICJBIE1lZGlhIFNv dXJjZSBpcyB0aGUgbG9naWNhbCBzb3VyY2Ugb2YgYSB0aW1lIHByb2dyZXNzaW5nLCBkaWdpdGFs IG1lZGlhIHN0cmVhbSBjYWxsZWQgYSBTb3VyY2UgU3RyZWFtLCBzeW5jaHJvbml6ZWQgdG8gYSBy ZWZlcmVuY2UgY2xvY2siPw0KDQo+IA0KPiAtLSAyLjEuNQ0KPiANCj4gV2FzIHRoZSAicmF3IHN0 cmVhbSIgbm90IGFsc28gdGltZS1wcm9ncmVzc2luZz8NCltCb0JdIFllcywgYnV0IG9ubHkgaW1w bGljaXRseSBhcyAiaW4gZ2VuZXJhbCBjaGFuZ2luZyBvdmVyIHRpbWUiLCBzaW5jZSB0aGVyZSBp cyBubyBleHBsaWNpdCB0aW1lIGluZm9ybWF0aW9uIGNvbm5lY3RlZCB0byB0aGUgcmF3IHN0cmVh bS4NCg0KPiANCj4gLS0gMi4xLjksIGZpcnN0IGJ1bGxldCBsaXN0IGVudHJ5Og0KPiANCj4gSSBj YW4ndCBwYXJzZSB0aGUgc2VudGVuY2UuIElzIHRoZXJlIGEgbWlzc2luZyB3b3JkIHRvd2FyZHMg dGhlIGVuZD8NCltCb0JdIFN1Z2dlc3QgcmUtZm9ybXVsYXRpbmcgdG8gIlRoZSBNZWRpYSBQYWNr ZXRpemVyIHNlbGVjdHMgd2hpY2ggU3luY2hyb25pemF0aW9uIHNvdXJjZShzKSAoU1NSQykgYW5k IFJUUCBTZXNzaW9ucyB0byB1c2UiDQoNCj4gDQo+IC0tIDIuMS4xOCAiLi4uIGFsYXJtIHN1YnNl cXVlbnQgdHJhbnNmb3JtYXRpb25zIC4uLiAiDQo+IA0KPiBEbyB5b3UgbWVhbiAiYWxlcnQiPw0K W0JvQl0gWWVzLg0KDQo+IA0KPiAtLSAyLjIuMywgZmlyc3QgYnVsbGV0IGxpc3QgZW50cnk6DQo+ IA0KPiBpcyB0aGUgU0lQIFVSSSBleGFtcGxlIGFzc3VtZWQgdG8gYmUgYW4gQWRkcmVzcyBvZiBS ZWNvcmQ/IElmIHNvLCBpdCBtaWdodCBiZSB3b3J0aCBtZW50aW9uaW5nIHRoYXQsIHNpbmNlIGEg U0lQIFVSSQ0KPiBjb3VsZCBhbHNvIHBvaW50IHRvIGEgZGV2aWNlLCBhbmQgYSBwYXJ0aWNpcGFu dCBtaWdodCBoYXZlIG1vcmUgdGhhbiBvbmUuDQpbQm9CXSBXaGlsZSB0aGUgVVJJIF9jYW5fIGJl IGFuIEFPUiwgSSB0aGluayB0aGF0IFBhcnRpY2lwYW50IGNhbiBqdXN0IGFzIHdlbGwgYmUgaWRl bnRpZmllZCBieSBhIHNwZWNpZmljIGRldmljZSBVUkkgYW5kIHN0aWxsIGZ1bGZpbCB0aGUgb3Ro ZXIgbGlzdGVkIGNoYXJhY3RlcmlzdGljcyBvZiBhIFBhcnRpY2lwYW50LiBUaGVyZWZvcmUsIGFu ZCB1bmxlc3MgeW91IGhhdmUgb3RoZXIgY29uY2VybnMgd2l0aCB0aGlzLCBJJ2QgbGlrZSB0byBr ZWVwIHRoZSBVUkkgInVuc3BlY2lmaWMiLiBBIHNpbmdsZSBBT1IgY291bGQgYmUgdXNlZCB0byBy ZWFjaCBvbmUgb3V0IG9mIHBvdGVudGlhbGx5IG1hbnkgUGFydGljaXBhbnRzLCBidXQgb25seSBv bmUgUGFydGljaXBhbnQgd291bGQgYWN0dWFsbHkgZW5kIHVwIGJlaW5nIHRoZSB0YXJnZXQgb2Yg c3VjaCBhZGRyZXNzaW5nLCBldmVuIGlmIGl0IGlzIHJlYWNoZWQgdGhyb3VnaCBvbmUgb3IgbW9y ZSBpbmRpcmVjdGlvbnMuIElmIG11bHRpcGxlICJlbnRpdGllcyIgYWN0dWFsbHkgYW5zd2VyIHRv IHRoZSBhZGRyZXNzaW5nIGFuZCBhcmUgYWxsIGluY2x1ZGVkIGludG8gdGhlIGNvbmZlcmVuY2Us IEknZCBwcmVmZXIgdG8gZGVmaW5lIHRoZW0gYXMgYSAiZGlzdHJpYnV0ZWQgUGFydGljaXBhbnQi IGNvbnNpc3Rpbmcgb2YgbXVsdGlwbGUgRW5kcG9pbnRzIGJlbG9uZ2luZyB0byB0aGUgc2FtZSBh ZGRyZXNzLg0KDQo+IA0KPiAtLSAzLjcsIGxhc3QgcGFyYWdyYXBoLCAybmQgc2VudGVuY2U6DQo+ IA0KPiBTZW50ZW5jZSBpcyBjb252b2x1dGVkIGFuZCBoYXJkIHRvIHJlYWQuIFBsZWFzZSBjb25z aWRlciBzcGxpdHRpbmcgaXQgaW50byBtdWx0aXBsZSBzaW1wbGVyIHNlbnRlbmNlcy4NCltCb0Jd IFdoYXQgYWJvdXQgc2ltcGxpZnlpbmcgaXQgc2xpZ2h0bHkgdG8gIiBXaGVuIHVzaW5nIGRpZmZl cmVudCBSVFAgU2Vzc2lvbnMgKE1STVQpLCBhIHNpbmdsZSBSVFAgU3RyZWFtIHBlciBNZWRpYSBF bmNvZGVyLCBhbmQgYSBzaW5nbGUgTWVkaWEgU291cmNlIGluIGVhY2ggUlRQIFNlc3Npb24sIGNv bW1vbiBTU1JDIGFuZCBDTkFNRXMgY2FuIGJlIHVzZWQgdG8gaWRlbnRpZnkgdGhlIGNvbW1vbiBN ZWRpYSBTb3VyY2UiPyBUaGUgcmVtb3ZlZCB0ZXh0ICh0aGF0IGRpZmZlcmVudCBSVFAgU2Vzc2lv bnMgaW1wbHkgZGlmZmVyZW50IE1lZGlhIFRyYW5zcG9ydHMpIHNob3VsZCBhbHJlYWR5IGJlIGNs ZWFyIGZyb20gb3RoZXIgdGV4dCBpbiB0aGUgZHJhZnQuDQoNCj4gDQo+IC0tIDMuOCwgZmlyc3Qg cGFyYWdyYXBoLCAybmQgc2VudGVuY2U6DQo+IA0KPiBDb252b2x1dGVkIHNlbnRlbmNlLg0KW0Jv Ql0gT0suIFdpbGwgc3BsaXQuDQoNCj4gDQo+IC0tIDMuOSwgbGFzdCBwYXJhZ3JhcGg6DQo+IA0K PiBDb252b2x1dGVkIHNlbnRlbmNlLg0KW0JvQl0gT0suIFdpbGwgc3BsaXQuDQoNCj4gDQo+IC0t IDMuMTAsIGxhc3QgcGFyYWdhcGgsIGxhc3Qgc2VudGVuY2U6DQo+IA0KPiBDb252b2x1dGVkIHNl bnRlbmNlLg0KW0JvQl0gT0ssIHdpbGwgcmUtZm9ybXVsYXRlLg0KDQo+IA0KPiAtLSAzLjExLCBs YXN0IHBhcmFncmFwaCA6ICJUaGlzIHJlcXVpcmVzIHRvIGVpdGhlciB1c2UuLi4iDQo+IA0KPiBN aXNzaW5nIG5vdW4/ICAoIlRoaXMgcmVxdWlyZXMgWFhYIHRvIHVzZSBlaXRoZXIiLCBvciAiVGhp cyByZXF1aXJlcyB0aGUgdXNlIG9mIGVpdGhlci4uLiIpDQpbQm9CXSBUaGUgbGF0dGVyLiBXaWxs IGNoYW5nZS4NCg0KPiANCj4gMy4xMywgZmlyc3QgcGFyYWdyYXBoLCBsYXN0IHNlbnRlbmNlOg0K PiANCj4gSSBjYW7igJl0IHBhcnNlIHRoZSBzZW50ZW5jZeKAlGlzIHRoZXJlIGEgd29yZCBtaXNz aW5nPyAoaS5lLiDigJzigKYgYW5kIHNtYWxsZXIgbnVtYmVyIG9mIGZsb3cgYmFzZWTigKbigJ0p Pw0KPiANCltCb0JdIEkgdGhpbmsgeW91IGZvdW5kIGFuIGFwcHJvcHJpYXRlIG1pc3Npbmcgd29y ZC4gVGhhbmtzLg0KDQo= From nobody Wed May 6 01:25:28 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7DA1A8AE9; Wed, 6 May 2015 01:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 L12ed3mA93oT; Wed, 6 May 2015 01:25:26 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3371C1A8AD1; Wed, 6 May 2015 01:25:24 -0700 (PDT) X-AuditID: c1b4fb30-f798d6d0000009ec-3c-5549cff2071b Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 18.24.02540.2FFC9455; Wed, 6 May 2015 10:25:22 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.210.2; Wed, 6 May 2015 10:25:22 +0200 Message-ID: <5549CFF1.8070304@ericsson.com> Date: Wed, 6 May 2015 10:25:21 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ben Campbell References: <949EF20990823C4C85C18D59AA11AD8B6970EDC6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5548A9B5.60401@ericsson.com> <028B6043-F353-4BAB-9742-3E8E09CBAA07@nostrum.com> In-Reply-To: <028B6043-F353-4BAB-9742-3E8E09CBAA07@nostrum.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvje6n856hBhd+21h8vHeD1WJ+52l2 iy9nPzFZPG08y+jA4tH6bC+rx5IlP5k8Zu18whLAHMVlk5Kak1mWWqRvl8CV8X66WcEkwYpv C+4xNjB+5e1i5OSQEDCRuPdiFSOELSZx4d56ti5GLg4hgaOMEkuPtbOCJIQEljFKNFxWBLF5 BbQlZt55zQRiswioSGw7/oIZxGYTsJC4+aORDcQWFYiSmPj1EAtEvaDEyZlPwGwRASWJ581b WUAWMAtcZZTYeuAm2CBhAW+JjTv2MUFsfsAosff8IrCpnAL2Ev9a94BNZQbaMHP+eUYIW16i eetsZojrtCUamjpYJzAKzkKycBaSlllIWhYwMq9iFC1OLU7KTTcy0kstykwuLs7P08tLLdnE CAzng1t+G+xgfPnc8RCjAAejEg/vglLPUCHWxLLiytxDjNIcLErivHbGh0KEBNITS1KzU1ML Uovii0pzUosPMTJxcEo1MHIo737a++hNkPg2Z4sDu+v0PsStzr/avXih8NRfj16fc5XrCwtr lP/X2ftmoY3safbvzw7Kby5sjDEp+1HPtf+jndCt+c5KqTwP9qXwy5f3/qg+37Xemjn32saM C5lZwlpMVzYyXV6YyB4iaxPe/ORWUsXKvzq6gRuLRWZPuyJtyx98oGa+ohJLcUaioRZzUXEi ADkXQdFIAgAA Archived-At: Cc: "avtext@ietf.org" , "draft-ietf-avtext-rtp-grouping-taxonomy.all@ietf.org" Subject: Re: [avtext] AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 08:25:28 -0000 Ben Campbell skrev den 2015-05-05 16:09: > To be clear, I don't think this needs to change to standards track. > > My main concern is that _this_ draft has no normative dependencies. > There are at least some sections that seem, on the surface, to require > the reader to read the referenced document to understand the section. > This will almost certainly get questioned during IESG review. (I have > seen a number of DISCUSS positions on informational "terminology" > references. > > I am open to arguments that this is not true for any specific reference, > but I haven't seen such an argument yet. > > And of course, the related issue is that many of those currently > informational dependencies point to works-in-progress. > If this is the case for this document, I think the IESG members are misinterpreting the current IESG statement. I would note that the emphasis in the text is clearly on specifying technology. "Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work." "Informative references are not required to implement the technology in the RFC." "Note 3: The normative/informative distinction is relevant in any document that amounts to a technical specification, even if its intended status is Experimental or Informational." This document clearly do not specify a technology that can be implemented. It provides a description of components, many in an abstract way, and how their relation can be described. Thus enabling a technology to be more precise in the description for when it applies. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri May 8 08:43:58 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7008A1A908A; Fri, 8 May 2015 08:43:57 -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 3WkLyWKS_dow; Fri, 8 May 2015 08:43:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 375AB1A9091; Fri, 8 May 2015 08:43:54 -0700 (PDT) Received: from [10.10.1.3] (50.97.94.43-static.reverse.softlayer.com [50.97.94.43]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t48FgU3H093358 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 May 2015 10:42:31 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 50.97.94.43-static.reverse.softlayer.com [50.97.94.43] claimed to be [10.10.1.3] From: "Ben Campbell" To: "Magnus Westerlund" Date: Fri, 08 May 2015 16:42:30 +0100 Message-ID: In-Reply-To: <5549CFF1.8070304@ericsson.com> References: <949EF20990823C4C85C18D59AA11AD8B6970EDC6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5548A9B5.60401@ericsson.com> <028B6043-F353-4BAB-9742-3E8E09CBAA07@nostrum.com> <5549CFF1.8070304@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "avtext@ietf.org" , "draft-ietf-avtext-rtp-grouping-taxonomy.all@ietf.org" Subject: Re: [avtext] AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 15:43:57 -0000 On 6 May 2015, at 9:25, Magnus Westerlund wrote: > Ben Campbell skrev den 2015-05-05 16:09: >> To be clear, I don't think this needs to change to standards track. >> >> My main concern is that _this_ draft has no normative dependencies. >> There are at least some sections that seem, on the surface, to >> require >> the reader to read the referenced document to understand the section. >> This will almost certainly get questioned during IESG review. (I have >> seen a number of DISCUSS positions on informational "terminology" >> references. >> >> I am open to arguments that this is not true for any specific >> reference, >> but I haven't seen such an argument yet. >> >> And of course, the related issue is that many of those currently >> informational dependencies point to works-in-progress. >> > > If this is the case for this document, I think the IESG members are > misinterpreting the current IESG statement. I would note that the > emphasis in the text is clearly on specifying technology. > > "Normative references specify documents that must be read to > understand or implement the technology in the new RFC, or whose > technology must be present for the technology in the new RFC to work." > > "Informative references are not required to implement the technology > in the RFC." > > "Note 3: The normative/informative distinction is relevant in any > document that amounts to a technical specification, even if its > intended status is Experimental or Informational." > > This document clearly do not specify a technology that can be > implemented. It provides a description of components, many in an > abstract way, and how their relation can be described. Thus enabling a > technology to be more precise in the description for when it applies. I agree that the IESG statement speaks to "specifications". But some ADs believe we should apply similar approaches to all drafts, where the standard is "if you have to read that to understand this it should be normative". (I am personally on the fence on this.) ** In any case, I am not going to block the draft on this point--I only mean to point out the potential for a DISCUSS.** This may be mostly moot, though. I went back through the draft on a per-reference basis. The only references I find problematic are RFCs 3350 and 4566, and I-D.ietf-clue-framework. It would be no problem making the RFC references normative if the authors choose to do so. The clue framework is trickier, since that is still in progress--but is has at least been pubreqed. And the only reason I think it might need to be normative is that Section 4 imports terms from it without local descriptions. That section locally describes the terms imported from the other drafts. If the authors were to add local descriptions for the clue framework terms, it would be easier to justify that reference as informational. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From nobody Mon May 11 00:54:05 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECB91A1EF4; Mon, 11 May 2015 00:54:02 -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 W8q5OlKrqeoF; Mon, 11 May 2015 00:54:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D081A1C03; Mon, 11 May 2015 00:54:00 -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.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150511075400.7021.4740.idtracker@ietfa.amsl.com> Date: Mon, 11 May 2015 00:54:00 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 07:54:02 -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 Extensions Working Group of the IETF. Title : RTP Header Extension for RTCP Source Description Items Authors : Magnus Westerlund Bo Burman Roni Even Mo Zanaty Filename : draft-ietf-avtext-sdes-hdr-ext-01.txt Pages : 14 Date : 2015-05-11 Abstract: Source Description (SDES) items are normally transported in RTP control protocol (RTCP). In some cases it can be beneficial to speed up the delivery of these items. Mainly when a new source (SSRC) joins an RTP session and the receivers needs this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry SDES items. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-sdes-hdr-ext-01 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 Mon May 11 01:03:42 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475611A1C03 for ; Mon, 11 May 2015 01:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 6W53q5Pk3FVw for ; Mon, 11 May 2015 01:03:39 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BFDE1A1EB7 for ; Mon, 11 May 2015 01:03:38 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-ee-555062583c10 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 64.CD.28096.85260555; Mon, 11 May 2015 10:03:36 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.210.2; Mon, 11 May 2015 10:03:35 +0200 Message-ID: <55506257.9040804@ericsson.com> Date: Mon, 11 May 2015 10:03:35 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "avtext@ietf.org" References: <20150511075400.7021.4740.idtracker@ietfa.amsl.com> In-Reply-To: <20150511075400.7021.4740.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3RjciKSDU4MdDaYuP926wOjB6LFny kymAMYrLJiU1J7MstUjfLoEro2HpeeaC19IV8z+1MTUwnhHtYuTkkBAwkehcto4ZwhaTuHBv PVsXIxeHkMBRRonfJ44zQjjLGSU6Xp9lAqniFdCW2PhgFRuIzSKgKrH39m92EJtNwELi5o9G sLioQJTExK+HWCDqBSVOznwCZosIqEvcmX4BrEZYwE6iYcNJsJlCAvYSP66cBopzcHAKOEjs ucAPYjIDhR9sLQOpYBaQl2jeOpsZolpboqGpg3UCo8AsJAtmIXTMQtKxgJF5FaNocWpxcW66 kZFealFmcnFxfp5eXmrJJkZg+B3c8ttqB+PB546HGAU4GJV4eB9c8Q8VYk0sK67MPcQozcGi JM5rZ3woREggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjUtmUHZPlw/1+3vApM/ZTeD/3ReQR YV3WdT/ORR7JZJj8XNDr/I7gDO+1rBpT1lqE/5U6r/zG/+PxW0Ebd6tvy+D5X2EowJEqwKVt Vu77+ETBQ3UrvlfLteSjPE2Kxc09luQe3xFbcrjwq8nT42+m9AjqObyc/udRvFyK8vRPX9Wm qjbI5JxSYinOSDTUYi4qTgQAcNNXnSACAAA= Archived-At: Subject: Re: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 08:03:41 -0000 WG, This update performs a number of changes to the document. - Makes it clearer that SDES header extensions is not suitable for all type of header extensions. - Removes references to SRCNAME and APPID as the future of these are uncertain, and this document is planned to be finished before the end of the year. - Expanded transmission considerations and some tips on what RTCP information that can be used to determine successful or at least failure to deliver. - Discussion of how to avoid update flaps, a issue when sending both in RTP and RTCP. - Much clarified registration rules and actual registration - Various editorial updates. We authors would really appreciate a review of this. The timeplan is basically one more update before Prague and then hopefully a WG last call. To be able to do that we need your feedback on the changes and if something is still missing. Cheers Magnus Westerlund (For the authors) internet-drafts@ietf.org skrev den 2015-05-11 09:54: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF. > > Title : RTP Header Extension for RTCP Source Description Items > Authors : Magnus Westerlund > Bo Burman > Roni Even > Mo Zanaty > Filename : draft-ietf-avtext-sdes-hdr-ext-01.txt > Pages : 14 > Date : 2015-05-11 > > Abstract: > Source Description (SDES) items are normally transported in RTP > control protocol (RTCP). In some cases it can be beneficial to speed > up the delivery of these items. Mainly when a new source (SSRC) > joins an RTP session and the receivers needs this source's identity, > relation to other sources, or its synchronization context, all of > which may be fully or partially identified using SDES items. To > enable this optimization, this document specifies a new RTP header > extension that can carry SDES items. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-sdes-hdr-ext-01 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue May 12 13:40:52 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEAE1AD072; Tue, 12 May 2015 13:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 1Zu558SxydB4; Tue, 12 May 2015 13:40:48 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 AB0991AD071; Tue, 12 May 2015 13:40:48 -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.1/8.14.9) with ESMTPSA id t4CKeYqn043968 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 May 2015 15:40:44 -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: "Bo Burman" Date: Tue, 12 May 2015 15:40:34 -0500 Message-ID: <55B14DB1-CE6B-4366-AFF2-02963FDC9EB7@nostrum.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "avtext@ietf.org" , "draft-ietf-avtext-rtp-grouping-taxonomy.all@ietf.org" Subject: Re: [avtext] AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 (editorials) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 20:40:50 -0000 Hi, more comments inline. I will delete sections that do not seem to need further discussion. On 5 May 2015, at 11:09, Bo Burman wrote: [...] >> -- 2.1.2: >> >> Do you consider the meaning of the term "Media" to be clear enough >> that it doesn't need a definition here? > [BoB] The very first sentence of 2.1 starts with "In the context of > this memo, Media is...". Is that not sufficient? I think that is > sufficiently clear. > Oops, I forgot that was there by the time I got to 2.1.2. It's fine like it is. >> >> I find it hard to parse the following sentence: >> >> "This data is due to its periodical sampling, or at least being timed >> asynchronous events, some form of a stream of media >> data. " > [BoB] Maybe re-arranging the sentence makes it more clear: "This data > is some form of stream of media data, due to its periodical sampling > or as a set of timed asynchronous events"? I'm still not following it. Do you mean something to the effect of "This stream is considered 'Media', because it includes data that is periodically sampled, or made up of a set of timed asynchronous events."? [...] >> -- 2.1.4, first sentence >> >> I find the sentence hard to parse: > [BoB] What about re-arranging it : "A Media Source is the logical > source of a time progressing, digital media stream called a Source > Stream, synchronized to a reference clock"? The ordering of the clauses is still confusing. How about" "A Media Source is the logical source of a time progressing digital media stream synchronized to a reference clock. This stream is called a "Source Stream". > >> >> -- 2.1.5 >> >> Was the "raw stream" not also time-progressing? > [BoB] Yes, but only implicitly as "in general changing over time", > since there is no explicit time information connected to the raw > stream. I read "time-progressing" to mean exactly "changing over time". The rest of the sentence talks about clock-synchronization, so maybe the term "time-progressing" could be dropped? > >> >> -- 2.1.9, first bullet list entry: >> >> I can't parse the sentence. Is there a missing word towards the end? > [BoB] Suggest re-formulating to "The Media Packetizer selects which > Synchronization source(s) (SSRC) and RTP Sessions to use" That's better, thanks. [...] >> >> -- 2.2.3, first bullet list entry: >> >> is the SIP URI example assumed to be an Address of Record? If so, it >> might be worth mentioning that, since a SIP URI >> could also point to a device, and a participant might have more than >> one. > [BoB] While the URI _can_ be an AOR, I think that Participant can just > as well be identified by a specific device URI and still fulfil the > other listed characteristics of a Participant. Therefore, and unless > you have other concerns with this, I'd like to keep the URI > "unspecific". A single AOR could be used to reach one out of > potentially many Participants, but only one Participant would actually > end up being the target of such addressing, even if it is reached > through one or more indirections. If multiple "entities" actually > answer to the addressing and are all included into the conference, I'd > prefer to define them as a "distributed Participant" consisting of > multiple Endpoints belonging to the same address. If I have a human with more than one device, is the participant the human, or a device? If the answer is "the human", then only an AoR would seem to support the property of "reachable by a single address". Or does "reachable by a single address" mean you _can_ reach the participant with a single address (and no more information), not that the participant is _only_ reachable by a single address? >> >> -- 3.7, last paragraph, 2nd sentence: >> >> Sentence is convoluted and hard to read. Please consider splitting it >> into multiple simpler sentences. > [BoB] What about simplifying it slightly to " When using different RTP > Sessions (MRMT), a single RTP Stream per Media Encoder, and a single > Media Source in each RTP Session, common SSRC and CNAMEs can be used > to identify the common Media Source"? The removed text (that different > RTP Sessions imply different Media Transports) should already be clear > from other text in the draft. That helps, thanks. [...] From nobody Wed May 13 06:37:23 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3938C1B2AC7; Wed, 13 May 2015 06:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 U8w4ilSX_Lrd; Wed, 13 May 2015 06:37:20 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2B71B2AC3; Wed, 13 May 2015 06:37:18 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-f7-5553538cc4a2 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6C.21.04401.C8353555; Wed, 13 May 2015 15:37:17 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.66]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0210.002; Wed, 13 May 2015 15:37:16 +0200 From: Bo Burman To: Ben Campbell Thread-Topic: AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 (editorials) Thread-Index: AdCHTKzbI4o52Q1nR42EtHq8LGBxXwFlnSQAACYFSeA= Date: Wed, 13 May 2015 13:37:15 +0000 Message-ID: References: <55B14DB1-CE6B-4366-AFF2-02963FDC9EB7@nostrum.com> In-Reply-To: <55B14DB1-CE6B-4366-AFF2-02963FDC9EB7@nostrum.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+JvrW5vcHCowddJ3BYf791gtZjfeZrd 4svZT0wOzB5Llvxk8pi18wlLAFMUl01Kak5mWWqRvl0CV8b/js2sBQdsKi6tXcLWwDjNoIuR k0NCwETi1/TpzBC2mMSFe+vZQGwhgaOMEnN+pnYxcgHZixklLn64zwKSYBPQkJi/4y4jiC0i oCTxvHkrC0gRs8AsRom9SxeBFQkLBEpM3DyHHaIoSKLxyQkmCNtKYt/n42BxFgFViXfdV8AG 8Qr4Ssxv6mKC2NbEKHH77FOwBk4Be4mOLWfBhjIKyErc/34PzGYWEJe49WQ+E8TZAhJL9pyH ekFU4uXjf6wQtqLE1enLmSDqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gmMIrNQjJ2FpKWWUha ZiFpWcDIsopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMJoObvmtuoPx8hvHQ4wCHIxKPLwK G4JChVgTy4orcw8xSnOwKInz2hkfChESSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAmPJjy3vZ a9a/lRm/f/z5YbnEi7frWGIsVr9kYP/2fzqXgu/GLdrP21r2r26vP7b1fN2OLQxie8uuf/D5 b8vd9U9f1f2z5qtC9wb5zZvuBrkJrqyvDQqwEiq0/ugtenvLXI4DLGGZ+Qx+6SUrtm+4+GbF 8ryLU6bFHwwRd6rdr3qyfPduH2YWByWW4oxEQy3mouJEAOMXmiaHAgAA Archived-At: Cc: "avtext@ietf.org" , "draft-ietf-avtext-rtp-grouping-taxonomy.all@ietf.org" Subject: Re: [avtext] AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 (editorials) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 13:37:22 -0000 Hi, my responses inline. Cheers, Bo > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: den 12 maj 2015 22:41 > To: Bo Burman > Cc: draft-ietf-avtext-rtp-grouping-taxonomy.all@ietf.org; avtext@ietf.org > Subject: Re: AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 (edito= rials) >=20 > Hi, more comments inline. I will delete sections that do not seem to need= further discussion. >=20 > On 5 May 2015, at 11:09, Bo Burman wrote: >=20 > [...] >=20 > >> -- 2.1.2: > >> > >> Do you consider the meaning of the term "Media" to be clear enough > >> that it doesn't need a definition here? > > [BoB] The very first sentence of 2.1 starts with "In the context of > > this memo, Media is...". Is that not sufficient? I think that is > > sufficiently clear. > > >=20 > Oops, I forgot that was there by the time I got to 2.1.2. It's fine like = it is. [BoB] OK >=20 > >> > >> I find it hard to parse the following sentence: > >> > >> "This data is due to its periodical sampling, or at least being timed > >> asynchronous events, some form of a stream of media data. " > > [BoB] Maybe re-arranging the sentence makes it more clear: "This data > > is some form of stream of media data, due to its periodical sampling > > or as a set of timed asynchronous events"? >=20 > I'm still not following it. Do you mean something to the effect of "This = stream is considered 'Media', because it includes > data that is periodically sampled, or made up of a set of timed asynchron= ous events."? [BoB] Yes. I'll happily adopt that formulation if it is more clear. >=20 > [...] >=20 > >> -- 2.1.4, first sentence > >> > >> I find the sentence hard to parse: > > [BoB] What about re-arranging it : "A Media Source is the logical > > source of a time progressing, digital media stream called a Source > > Stream, synchronized to a reference clock"? >=20 > The ordering of the clauses is still confusing. How about" >=20 > "A Media Source is the logical source of a time progressing digital media= stream synchronized to a reference clock. This > stream is called a "Source Stream". [BoB] Good! >=20 > > > >> > >> -- 2.1.5 > >> > >> Was the "raw stream" not also time-progressing? > > [BoB] Yes, but only implicitly as "in general changing over time", > > since there is no explicit time information connected to the raw > > stream. >=20 > I read "time-progressing" to mean exactly "changing over time". The rest > of the sentence talks about clock-synchronization, so maybe the term > "time-progressing" could be dropped? [BoB] I have no problem with that. >=20 > > > >> > >> -- 2.1.9, first bullet list entry: > >> > >> I can't parse the sentence. Is there a missing word towards the end? > > [BoB] Suggest re-formulating to "The Media Packetizer selects which > > Synchronization source(s) (SSRC) and RTP Sessions to use" >=20 > That's better, thanks. > [...] >=20 > >> > >> -- 2.2.3, first bullet list entry: > >> > >> is the SIP URI example assumed to be an Address of Record? If so, it > >> might be worth mentioning that, since a SIP URI > >> could also point to a device, and a participant might have more than > >> one. > > [BoB] While the URI _can_ be an AOR, I think that Participant can just > > as well be identified by a specific device URI and still fulfil the > > other listed characteristics of a Participant. Therefore, and unless > > you have other concerns with this, I'd like to keep the URI > > "unspecific". A single AOR could be used to reach one out of > > potentially many Participants, but only one Participant would actually > > end up being the target of such addressing, even if it is reached > > through one or more indirections. If multiple "entities" actually > > answer to the addressing and are all included into the conference, I'd > > prefer to define them as a "distributed Participant" consisting of > > multiple Endpoints belonging to the same address. >=20 > If I have a human with more than one device, is the participant the > human, or a device? If the answer is "the human", then only an AoR would > seem to support the property of "reachable by a single address". Or does > "reachable by a single address" mean you _can_ reach the participant > with a single address (and no more information), not that the > participant is _only_ reachable by a single address? [BoB] For the scope of "Participant", I mean that you _can_ reach the parti= cipant with a single _signaling_ address (and no more information). I say "= signaling" here, because a single signaling address could encompass several= other addresses in another address space, like different media IP addresse= s and ports. Quoting the bullet text in the draft, for reference: "A single signaling-addressable entity, using an application-specific signa= ling address space, for example a SIP URI." A human user could possess several different devices that he or she could p= otentially use to participate in a "Conference". I however expect a single = instance of actual participation to include a choice of which device to use= that particular time. While the chosen device can be addressed by an AOR, = it can very likely also be addressed by the device-specific address. The participant is _defined_ to be a _single_ entity in the signaling addre= ss space by that bullet text, such that if you would have to use several di= fferent addresses, they would represent different participants. There's an = intentional fuzziness here, both because it becomes problematic to make a v= ery precise definition, and I also don't think it has to be better defined = to be able to constructively use the term "participant". Let me try to provide an example; assume a human user being addressed by a = single AOR and choosing to answer a single call at _several different_ devi= ces. Are those devices (all representing a single human user, and AOR) to b= e considered a single or multiple participants in the conference? It should= be clear that each device can in turn make use of several media (non-signa= ling) addresses, and I expect that each device is also (in addition to the = AOR) addressable by a device-specific signaling address (connected to the A= OR). If the "application" only deals with AOR addresses, all of the devices= are (with the definition above) part of the same participant. If the "appl= ication" instead deals with SIP URIs, each device is a participant in the c= onference (with that same definition), and the fact that they all convey me= dia to and from the same human user is a secondary aspect. Any devices belo= nging to that same AOR, but that are not connected to the conference are of= course not participants in it. I think that the existing text is still correct, although I admit that it m= ight be a bit minimalistic. What clarifications do you think we need to add= to properly reflect what I said above, without being that verbose? I welco= me your text proposals! >=20 >=20 > >> > >> -- 3.7, last paragraph, 2nd sentence: > >> > >> Sentence is convoluted and hard to read. Please consider splitting it > >> into multiple simpler sentences. > > [BoB] What about simplifying it slightly to " When using different RTP > > Sessions (MRMT), a single RTP Stream per Media Encoder, and a single > > Media Source in each RTP Session, common SSRC and CNAMEs can be used > > to identify the common Media Source"? The removed text (that different > > RTP Sessions imply different Media Transports) should already be clear > > from other text in the draft. >=20 > That helps, thanks. >=20 > [...] >=20 From nobody Thu May 14 12:22:11 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1674C1B2F53; Thu, 14 May 2015 12:22: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 S31yH2_MczVz; Thu, 14 May 2015 12:22:04 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 1C33D1ACDE2; Thu, 14 May 2015 12:22:01 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4EJM0kq006060 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 May 2015 14:22:00 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <5554F5D3.7080204@nostrum.com> Date: Thu, 14 May 2015 14:21:55 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: General Area Review Team , avtext@ietf.org, "ietf@ietf.org" , draft-ietf-avtext-rtp-grouping-taxonomy@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [avtext] Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 19:22:06 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-avtext-rtp-grouping-taxonomy-06 Reviewer: Robert Sparks Review Date: 14 May 2015 IETF LC End Date: 18 May 2015 IESG Telechat date: Not currently scheduled Summary: This draft is on the right track, but has open issues. This draft has clearly helped progress conversations across several working groups, particularly around grouping streams. It's good that it was put together. I worry a little about the timing of publishing it as an RFC now (is that driven by other documents wanting to reference this normatively?) rather than keeping most of it as a living document somewhere. That said, I don't think publishing it as an RFC is going to hurt anything, but since future readers aren't going to be focusing so hard on the current conversations, I want to check on a couple of things: Major issues: I'm surprised that there is no mention of how SRTP fits into the vocabulary this document builds. Would it be a mistake for someone to think of SRTP as what this document calls a transformation? Are there any consequences of using SRTP on one or more of the streams being associated that impact how you would talk about the association? (There are certainly consequences about which elements can see into the various streams). Minor issues: The title says this document is about grouping. While conversations around grouping motivated the document, the text goes well beyond describing grouping. The abstract and introduction don't contain the word 'grouping'; instead, they cast the document as being about describing sources, but the document goes well beyond a taxonomy of sources. It suggest reworking these sections to reflect what the document ended up being. Nits/editorial comments: In more-or-less document order: The document call out the possibility of loops, but no discussion shows the use of one. What motivated calling out the possibility? The use of "Characteristics" is inconsistent across the sections. Sometimes the bullets list things that could be used to classify a thing, and sometimes they appear to be a set of observations about the thing. It's hard to tell whether the lists are intended to be complete or exclusive, depending on the section. Perhaps these should be worked mostly back into the prose, leaving points here that are specific to clarifying the taxonomy? "The actually used codec is also an important factor in many communication systems." is unclear. What's this trying to say? In 2.1.10, 2nd paragraph, is "at least some content" accurate? What about the edge cases where encoding results in an empty stream (an audio stream that is silent, where the codec does silence suppression resulting in no bits out for example). You're still going to be emitting RTCP. Is this section saying that the RTP stream doesn't qualify as a Source stream? In 2.2.1 it's not clear what "ensure Endpoint Identification" means. Did you mean something like 'establish' instead of 'ensure'? At the end of the first paragraph of 3.6, you point forward to 3.12 for a discussion of other considerations effecting which usage is desirable. 3.12 doesn't talk about that. It only talks about how you separate the streams. What is "other considerations" supposed to be pointing to? Very tiny nits and suggestions: 2.1.4 paragraph 1 : s/as NTP synchronized/as an NTP synchronized clock/ 2.1.4 last bullet : In "At any point, it", the word 'it' is ambiguous. 2.1.6 Characteristics bullet: This isn't a characteristic of a Media encoder. The sentence is almost a cyclic definition. I suggest removing the characteristics section from this (or saying something different). 2.1.19 "the Media Transport's transformation" is ambiguous. Which one? Did you mean "the combination of of the transport sender, network transport, and transport receiver transformations", or something like it? 3.5 Consider clarifying "mono encoder" 3.6 last sentence: s/This to/This is to/ or s/This to enable/This enables/ From nobody Thu May 14 12:45:46 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F751A8883; Thu, 14 May 2015 12:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 69SU4XRCWngX; Thu, 14 May 2015 12:45:43 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 CEE201A8A95; Thu, 14 May 2015 12:45:19 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 4987EB6B1A427; Thu, 14 May 2015 19:45:14 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t4EJjGQ7020401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 May 2015 21:45:17 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 14 May 2015 21:45:16 +0200 From: "DRAGE, Keith (Keith)" To: Robert Sparks , General Area Review Team , "avtext@ietf.org" , "ietf@ietf.org" , "draft-ietf-avtext-rtp-grouping-taxonomy@ietf.org" Thread-Topic: [avtext] Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 Thread-Index: AQHQjntmIFqzjxv9gEqsVSy8mIEVTZ173v7w Date: Thu, 14 May 2015 19:45:14 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B6971577E@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <5554F5D3.7080204@nostrum.com> In-Reply-To: <5554F5D3.7080204@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [avtext] Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 19:45:45 -0000 In regard to the summary comment, I would like to confirm that the issue of= when to publish was extensively discussed in the working group and between= the working group chairs and the authors. It was agreed that nothing would= be achieved by waiting and therefore there was consensus to move forward. The remainder I will leave to the document editor. Keith=20 AVTEXT working group co-chair > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of=20 > Robert Sparks > Sent: 14 May 2015 20:22 > To: General Area Review Team; avtext@ietf.org; ietf@ietf.org;=20 > draft-ietf-avtext-rtp-grouping-taxonomy@ietf.org > Subject: [avtext] Genart LC review:=20 > draft-ietf-avtext-rtp-grouping-taxonomy-06 >=20 > I am the assigned Gen-ART reviewer for this draft. For=20 > background on Gen-ART, please see the FAQ at >=20 > . >=20 > Please resolve these comments along with any other Last Call=20 > comments you may receive. >=20 > Document: draft-ietf-avtext-rtp-grouping-taxonomy-06 > Reviewer: Robert Sparks > Review Date: 14 May 2015 > IETF LC End Date: 18 May 2015 > IESG Telechat date: Not currently scheduled >=20 > Summary: This draft is on the right track, but has open issues. >=20 > This draft has clearly helped progress conversations across=20 > several working groups, particularly around grouping streams.=20 > It's good that it was put together. I worry a little about=20 > the timing of publishing it as an RFC now (is that driven by=20 > other documents wanting to reference this normatively?)=20 > rather than keeping most of it as a living document=20 > somewhere. That said, I don't think publishing it as an RFC=20 > is going to hurt anything, but since future readers aren't=20 > going to be focusing so hard on the current conversations, I=20 > want to check on a couple of things: >=20 > Major issues: >=20 > I'm surprised that there is no mention of how SRTP fits into=20 > the vocabulary this document builds. Would it be a mistake=20 > for someone to think of SRTP as what this document calls a=20 > transformation? Are there any consequences of using SRTP on=20 > one or more of the streams being associated that impact how=20 > you would talk about the association? (There are certainly=20 > consequences about which elements can see into the various streams). >=20 > Minor issues: >=20 > The title says this document is about grouping. While=20 > conversations around grouping motivated the document, the=20 > text goes well beyond describing grouping. > The abstract and introduction don't contain the word=20 > 'grouping'; instead, they cast the document as being about=20 > describing sources, but the document goes well beyond a=20 > taxonomy of sources. It suggest reworking these sections to=20 > reflect what the document ended up being. >=20 > Nits/editorial comments: >=20 > In more-or-less document order: >=20 > The document call out the possibility of loops, but no=20 > discussion shows the use of one. What motivated calling out=20 > the possibility? >=20 > The use of "Characteristics" is inconsistent across the=20 > sections. Sometimes the bullets list things that could be=20 > used to classify a thing, and sometimes they appear to be a=20 > set of observations about the thing. It's hard to tell=20 > whether the lists are intended to be complete or exclusive,=20 > depending on the section. Perhaps these should be worked=20 > mostly back into the prose, leaving points here that are=20 > specific to clarifying the taxonomy? >=20 > "The actually used codec is also an important factor in many=20 > communication systems." > is unclear. What's this trying to say? >=20 > In 2.1.10, 2nd paragraph, is "at least some content"=20 > accurate? What about the edge cases where encoding results in=20 > an empty stream (an audio stream that is silent, where the=20 > codec does silence suppression resulting in no bits out for=20 > example). You're still going to be emitting RTCP. Is this=20 > section saying that the RTP stream doesn't qualify as a Source stream? >=20 > In 2.2.1 it's not clear what "ensure Endpoint Identification"=20 > means. Did you mean something like 'establish' instead of 'ensure'? >=20 > At the end of the first paragraph of 3.6, you point forward=20 > to 3.12 for a discussion of other considerations effecting=20 > which usage is desirable. > 3.12 doesn't talk about that. It only talks about how you=20 > separate the streams. What is "other considerations" supposed=20 > to be pointing to? >=20 > Very tiny nits and suggestions: > 2.1.4 paragraph 1 : s/as NTP synchronized/as an NTP=20 > synchronized clock/ > 2.1.4 last bullet : In "At any point, it", the word 'it' is ambiguous. > 2.1.6 Characteristics bullet: This isn't a characteristic of=20 > a Media encoder. > The sentence is almost a cyclic definition. I suggest=20 > removing the > characteristics section from this (or saying something=20 > different). > 2.1.19 "the Media Transport's transformation" is ambiguous. Which one? > Did you mean "the combination of of the transport=20 > sender, network > transport, and transport receiver transformations",=20 > or something > like it? > 3.5 Consider clarifying "mono encoder" > 3.6 last sentence: s/This to/This is to/ or s/This to=20 > enable/This enables/ >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > = From nobody Thu May 14 13:48:12 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF431A885B; Thu, 14 May 2015 13:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_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 wSfikTCsUUaG; Thu, 14 May 2015 13:44:23 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 C38E21A886F; Thu, 14 May 2015 13:44:22 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t4EKgIAM008474 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 May 2015 16:42:19 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t4EKgIAM008474 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1431636140; bh=swKFMfaDX1XUbr7GuhWknChNxC0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=I8lLxKkQrjHsLsdVkNf0zlBHibskNZZQslaFqUCFU/o4BGj/aSVGSHfSKv0tHbeyR dwQ74Udpma1PqtC4zPZ585Unvo1ELW4r+8rMM63ii67NRImjh4O2x0+6n8fTtf8cPQ DwQzkyAb08bXmTLkvortijOI1VFBt7rnIBs1+XYU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t4EKgIAM008474 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd06.lss.emc.com (RSA Interceptor); Thu, 14 May 2015 16:41:57 -0400 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t4EKg4eZ011408 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 May 2015 16:42:04 -0400 Received: from MXHUB208.corp.emc.com (10.253.68.34) by mxhub12.corp.emc.com (10.254.92.107) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 14 May 2015 16:42:03 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.21]) by MXHUB208.corp.emc.com ([10.253.68.34]) with mapi id 14.03.0224.002; Thu, 14 May 2015 16:42:03 -0400 From: "Black, David" To: "DRAGE, Keith (Keith)" , Robert Sparks , General Area Review Team , "avtext@ietf.org" , "ietf@ietf.org" , "draft-ietf-avtext-rtp-grouping-taxonomy@ietf.org" Thread-Topic: [avtext] Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 Thread-Index: AQHQjn6bZa2X3G67gE61UEetOrO3Sp177l7w Date: Thu, 14 May 2015 20:42:02 +0000 Message-ID: References: <5554F5D3.7080204@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B6971577E@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6971577E@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: X-Mailman-Approved-At: Thu, 14 May 2015 13:48:12 -0700 Cc: "Black, David" Subject: Re: [avtext] Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 20:44:27 -0000 As an author of the only draft in the RFC Editor queue that's waiting on this taxonomy draft, (that would be draft-ietf-dart-dscp-rtp) I certainly did not put any pressure on anyone to rush publication of this taxonomy draft. The normative reference that's causing the dart draft to wait for this taxonomy draft exists because it's important a single set of terminology be used with consensus on what the terms mean. IMHO, getting RFC content right is much more important than getting RFCs published quickly. Thanks, --David > -----Original Message----- > From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of DRAGE, Keith > (Keith) > Sent: Thursday, May 14, 2015 3:45 PM > To: Robert Sparks; General Area Review Team; avtext@ietf.org; ietf@ietf.o= rg; > draft-ietf-avtext-rtp-grouping-taxonomy@ietf.org > Subject: Re: [Gen-art] [avtext] Genart LC review: draft-ietf-avtext-rtp- > grouping-taxonomy-06 >=20 > In regard to the summary comment, I would like to confirm that the issue = of > when to publish was extensively discussed in the working group and betwee= n the > working group chairs and the authors. It was agreed that nothing would be > achieved by waiting and therefore there was consensus to move forward. >=20 > The remainder I will leave to the document editor. >=20 > Keith > AVTEXT working group co-chair >=20 > > -----Original Message----- > > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of > > Robert Sparks > > Sent: 14 May 2015 20:22 > > To: General Area Review Team; avtext@ietf.org; ietf@ietf.org; > > draft-ietf-avtext-rtp-grouping-taxonomy@ietf.org > > Subject: [avtext] Genart LC review: > > draft-ietf-avtext-rtp-grouping-taxonomy-06 > > > > I am the assigned Gen-ART reviewer for this draft. For > > background on Gen-ART, please see the FAQ at > > > > . > > > > Please resolve these comments along with any other Last Call > > comments you may receive. > > > > Document: draft-ietf-avtext-rtp-grouping-taxonomy-06 > > Reviewer: Robert Sparks > > Review Date: 14 May 2015 > > IETF LC End Date: 18 May 2015 > > IESG Telechat date: Not currently scheduled > > > > Summary: This draft is on the right track, but has open issues. > > > > This draft has clearly helped progress conversations across > > several working groups, particularly around grouping streams. > > It's good that it was put together. I worry a little about > > the timing of publishing it as an RFC now (is that driven by > > other documents wanting to reference this normatively?) > > rather than keeping most of it as a living document > > somewhere. That said, I don't think publishing it as an RFC > > is going to hurt anything, but since future readers aren't > > going to be focusing so hard on the current conversations, I > > want to check on a couple of things: > > > > Major issues: > > > > I'm surprised that there is no mention of how SRTP fits into > > the vocabulary this document builds. Would it be a mistake > > for someone to think of SRTP as what this document calls a > > transformation? Are there any consequences of using SRTP on > > one or more of the streams being associated that impact how > > you would talk about the association? (There are certainly > > consequences about which elements can see into the various streams). > > > > Minor issues: > > > > The title says this document is about grouping. While > > conversations around grouping motivated the document, the > > text goes well beyond describing grouping. > > The abstract and introduction don't contain the word > > 'grouping'; instead, they cast the document as being about > > describing sources, but the document goes well beyond a > > taxonomy of sources. It suggest reworking these sections to > > reflect what the document ended up being. > > > > Nits/editorial comments: > > > > In more-or-less document order: > > > > The document call out the possibility of loops, but no > > discussion shows the use of one. What motivated calling out > > the possibility? > > > > The use of "Characteristics" is inconsistent across the > > sections. Sometimes the bullets list things that could be > > used to classify a thing, and sometimes they appear to be a > > set of observations about the thing. It's hard to tell > > whether the lists are intended to be complete or exclusive, > > depending on the section. Perhaps these should be worked > > mostly back into the prose, leaving points here that are > > specific to clarifying the taxonomy? > > > > "The actually used codec is also an important factor in many > > communication systems." > > is unclear. What's this trying to say? > > > > In 2.1.10, 2nd paragraph, is "at least some content" > > accurate? What about the edge cases where encoding results in > > an empty stream (an audio stream that is silent, where the > > codec does silence suppression resulting in no bits out for > > example). You're still going to be emitting RTCP. Is this > > section saying that the RTP stream doesn't qualify as a Source stream? > > > > In 2.2.1 it's not clear what "ensure Endpoint Identification" > > means. Did you mean something like 'establish' instead of 'ensure'? > > > > At the end of the first paragraph of 3.6, you point forward > > to 3.12 for a discussion of other considerations effecting > > which usage is desirable. > > 3.12 doesn't talk about that. It only talks about how you > > separate the streams. What is "other considerations" supposed > > to be pointing to? > > > > Very tiny nits and suggestions: > > 2.1.4 paragraph 1 : s/as NTP synchronized/as an NTP > > synchronized clock/ > > 2.1.4 last bullet : In "At any point, it", the word 'it' is ambiguous. > > 2.1.6 Characteristics bullet: This isn't a characteristic of > > a Media encoder. > > The sentence is almost a cyclic definition. I suggest > > removing the > > characteristics section from this (or saying something > > different). > > 2.1.19 "the Media Transport's transformation" is ambiguous. Which one? > > Did you mean "the combination of of the transport > > sender, network > > transport, and transport receiver transformations", > > or something > > like it? > > 3.5 Consider clarifying "mono encoder" > > 3.6 last sentence: s/This to/This is to/ or s/This to > > enable/This enables/ > > > > > > > > > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Mon May 18 02:38:31 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D2B1A8853; Mon, 18 May 2015 02:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 rW9wQZjFLP4M; Mon, 18 May 2015 02:38:24 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252001A884D; Mon, 18 May 2015 02:38:22 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-c2-5559b30d916d Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BB.37.17665.D03B9555; Mon, 18 May 2015 11:38:21 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.210.2; Mon, 18 May 2015 11:38:02 +0200 Message-ID: <5559B2FA.20801@ericsson.com> Date: Mon, 18 May 2015 11:38:02 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Robert Sparks , General Area Review Team , , "ietf@ietf.org" , References: <5554F5D3.7080204@nostrum.com> In-Reply-To: <5554F5D3.7080204@nostrum.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM2J7lC7v5shQgyNdYhYf791gtZjbf4PZ 4uqrzywWzzbOZ7G4NqeRzYHVY8mSn0wes3Y+YQlgiuKySUnNySxLLdK3S+DKmDVjNnvBLb6K j6tWsDcwvuHuYuTkkBAwkbjd9Z8NwhaTuHBvPZDNxSEkcIRRon3vCkYIZzmjxPHzxxhBqngF NCVO9/9gBbFZBFQl9s3ezwxiswlYSNz80Qg2SVQgSmLi10MsEPWCEidnPmEBGSQicJBRYumx +WCDhAU8JU7sXgdWJCSgJbFxxl+wOKeAtsTp6QvBbGagoTPnn4ey5SWat85mhqjXlmho6mCd wCgwC8mOWUhaZiFpWcDIvIpRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMHAPbvmtu4Nx9WvH Q4wCHIxKPLwJ/JGhQqyJZcWVuYcYpTlYlMR5vbpCQoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFw SjUwlpnv3xDis9AzNeLG2y+pG/56K87tkS9reyF16cxmyc0Ob8XW+CQx7fP48NQ+kuFfQ8xl i9gFubcc6gW1Wfn39sX73DV0bp24g9vuhoPy7QTW4IKpln858zZpN9hGbmI93czxYu7ZtK+N 8S+WWd4SOPlJp2ryTtvYrI0zU/afFPRmTvok/eiXEktxRqKhFnNRcSIAr7wqQz0CAAA= Archived-At: Subject: Re: [avtext] Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 09:38:26 -0000 Robert Sparks skrev den 2015-05-14 21:21: > Major issues: > > I'm surprised that there is no mention of how SRTP fits into the > vocabulary this > document builds. Would it be a mistake for someone to think of SRTP as what > this document calls a transformation? Are there any consequences of > using SRTP > on one or more of the streams being associated that impact how you would > talk about > the association? (There are certainly consequences about which elements > can see > into the various streams). > Yes, encryption is clearly a transformation. And there are cases where the order of the encryption and other transformations, like FEC, do matter. Thus, I agree that it is an significant oversight to not include security. So SRTP is an Securing / Protection (as it is not only Encryption) transformation that operates on Source RTP Streams or Redundancy RTP Streams to create Secured Source RTP Streams or Secured Redundancy RTP Stream. If one looks on something like ISMAcrypt that operates on a special form of packetized encoded streams, i.e. payload created, but not RTP headers, we get into further distinctions that we so far haven't needed to have. I don't know how well we must ensure that something like ISMAcrypt is clearly defined, because then we do need to split the RTP packetization transformation into two parts. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed May 20 13:25:50 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315B01A9084; Wed, 20 May 2015 13:25: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 mSHaZjZbyJj9; Wed, 20 May 2015 13:25:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8B61B1A8BBD; Wed, 20 May 2015 13:25:47 -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.1/8.14.9) with ESMTPSA id t4KKPXPs050349 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 May 2015 15:25:43 -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: "Magnus Westerlund" , "Robert Sparks" Date: Wed, 20 May 2015 15:25:33 -0500 Message-ID: <8469C57F-5864-4B9E-9A3B-428DDB4101FD@nostrum.com> In-Reply-To: <5559B2FA.20801@ericsson.com> References: <5554F5D3.7080204@nostrum.com> <5559B2FA.20801@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: General Area Review Team , avtext@ietf.org, draft-ietf-avtext-rtp-grouping-taxonomy@ietf.org, "ietf@ietf.org" Subject: Re: [avtext] Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 20:25:49 -0000 Magnus and Robert: Is there an action implied here? I see that Magnus agreed that there was an oversight in regards to security, but it's not clear to me what action (if any) is planned. Thanks! Ben. On 18 May 2015, at 4:38, Magnus Westerlund wrote: > Robert Sparks skrev den 2015-05-14 21:21: > >> Major issues: >> >> I'm surprised that there is no mention of how SRTP fits into the >> vocabulary this >> document builds. Would it be a mistake for someone to think of SRTP >> as what >> this document calls a transformation? Are there any consequences of >> using SRTP >> on one or more of the streams being associated that impact how you >> would >> talk about >> the association? (There are certainly consequences about which >> elements >> can see >> into the various streams). >> > > Yes, encryption is clearly a transformation. And there are cases where > the order of the encryption and other transformations, like FEC, do > matter. Thus, I agree that it is an significant oversight to not > include security. > > So SRTP is an Securing / Protection (as it is not only Encryption) > transformation that operates on Source RTP Streams or Redundancy RTP > Streams to create Secured Source RTP Streams or Secured Redundancy RTP > Stream. > > If one looks on something like ISMAcrypt that operates on a special > form of packetized encoded streams, i.e. payload created, but not RTP > headers, we get into further distinctions that we so far haven't > needed to have. > > I don't know how well we must ensure that something like ISMAcrypt is > clearly defined, because then we do need to split the RTP > packetization transformation into two parts. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Wed May 20 13:39:25 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4421A90C2; Wed, 20 May 2015 13:39: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 6fsrwGAkpV8Z; Wed, 20 May 2015 13:39:21 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8EA811A90C3; Wed, 20 May 2015 13:39:21 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4KKdHS2051630 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 May 2015 15:39:17 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <555CF0F0.5000502@nostrum.com> Date: Wed, 20 May 2015 15:39:12 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ben Campbell , Magnus Westerlund References: <5554F5D3.7080204@nostrum.com> <5559B2FA.20801@ericsson.com> <8469C57F-5864-4B9E-9A3B-428DDB4101FD@nostrum.com> In-Reply-To: <8469C57F-5864-4B9E-9A3B-428DDB4101FD@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: General Area Review Team , avtext@ietf.org, draft-ietf-avtext-rtp-grouping-taxonomy@ietf.org, "ietf@ietf.org" Subject: Re: [avtext] Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 20:39:23 -0000 On 5/20/15 3:25 PM, Ben Campbell wrote: > Magnus and Robert: Is there an action implied here? I see that Magnus > agreed that there was an oversight in regards to security, but it's > not clear to me what action (if any) is planned. I think Magnus was sketching out proposed new text for the document. > > Thanks! > > Ben. > > On 18 May 2015, at 4:38, Magnus Westerlund wrote: > >> Robert Sparks skrev den 2015-05-14 21:21: >> >>> Major issues: >>> >>> I'm surprised that there is no mention of how SRTP fits into the >>> vocabulary this >>> document builds. Would it be a mistake for someone to think of SRTP >>> as what >>> this document calls a transformation? Are there any consequences of >>> using SRTP >>> on one or more of the streams being associated that impact how you >>> would >>> talk about >>> the association? (There are certainly consequences about which elements >>> can see >>> into the various streams). >>> >> >> Yes, encryption is clearly a transformation. And there are cases >> where the order of the encryption and other transformations, like >> FEC, do matter. Thus, I agree that it is an significant oversight to >> not include security. >> >> So SRTP is an Securing / Protection (as it is not only Encryption) >> transformation that operates on Source RTP Streams or Redundancy RTP >> Streams to create Secured Source RTP Streams or Secured Redundancy >> RTP Stream. >> >> If one looks on something like ISMAcrypt that operates on a special >> form of packetized encoded streams, i.e. payload created, but not RTP >> headers, we get into further distinctions that we so far haven't >> needed to have. >> >> I don't know how well we must ensure that something like ISMAcrypt is >> clearly defined, because then we do need to split the RTP >> packetization transformation into two parts. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> avtext mailing list >> avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext From nobody Thu May 21 02:33:12 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655971A90E8; Thu, 21 May 2015 02:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 qvFAgsQGu3Up; Thu, 21 May 2015 02:33:08 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B08D1A90B8; Thu, 21 May 2015 02:33:07 -0700 (PDT) X-AuditID: c1b4fb30-f798d6d0000009ec-de-555da651f4bb Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F3.57.02540.156AD555; Thu, 21 May 2015 11:33:05 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.210.2; Thu, 21 May 2015 11:33:04 +0200 Message-ID: <555DA650.3030808@ericsson.com> Date: Thu, 21 May 2015 11:33:04 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Robert Sparks , Ben Campbell References: <5554F5D3.7080204@nostrum.com> <5559B2FA.20801@ericsson.com> <8469C57F-5864-4B9E-9A3B-428DDB4101FD@nostrum.com> <555CF0F0.5000502@nostrum.com> In-Reply-To: <555CF0F0.5000502@nostrum.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+JvrW7gsthQg7+XNSw+3rvBajG/8zS7 xdz+G8wWV199ZrF4tnE+i8W1OY1sDmweS5b8ZPKYtfMJSwBTFJdNSmpOZllqkb5dAlfG7dsq BWfYKzY1zWZpYJzA1sXIySEhYCLxZ9dVVghbTOLCvfVAcS4OIYGjjBLbz5xkgXCWM0ps6D/J DlLFK6AtMf/CbBYQm0VAVaL9bidYnE3AQuLmj0awqaICURJTH69jgagXlDg58wmYLSLgIbH9 /T+wbcwCsxklVn7KBLGFBYIkru/qZwaxhQRmMUr8+pkCYnMC7TozqYEJot5CYub884wQtrxE 89bZUPXaEg1NHawTGAVnIVk3C0nLLCQtCxiZVzGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIE hvXBLb8NdjC+fO54iFGAg1GJh1fBJjZUiDWxrLgy9xCjNAeLkjivZ1dIqJBAemJJanZqakFq UXxRaU5q8SFGJg5OqQbGjkblh8YznW48FAqcZ/lZpHmR1hXn336PmFfc03N6nflu2+HrZ1M1 /hVvebWT+eYF2bDDRgsDam6aMM50qjGrn+ORLlAT42lf9O2TgZjUHMsZkzIeWfzkczuu9uEw z+QoxWUKNTY3z//unHoo++2lSFfuqY3XTi+24nsXID1x8o/Dj49elf7PrcRSnJFoqMVcVJwI AAiD5z5MAgAA Archived-At: Cc: General Area Review Team , avtext@ietf.org, draft-ietf-avtext-rtp-grouping-taxonomy@ietf.org, "ietf@ietf.org" Subject: Re: [avtext] Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 09:33:10 -0000 Robert Sparks skrev den 2015-05-20 22:39: > > > On 5/20/15 3:25 PM, Ben Campbell wrote: >> Magnus and Robert: Is there an action implied here? I see that Magnus >> agreed that there was an oversight in regards to security, but it's >> not clear to me what action (if any) is planned. > I think Magnus was sketching out proposed new text for the document. Well, I didn't promised text. But, I am working with Bo, so he can produce a proposal for addressing this. cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu May 21 10:02:44 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FEC1A0062; Thu, 21 May 2015 10:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ixyD5BhLTWJE; Thu, 21 May 2015 10:02:40 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9B11A0056; Thu, 21 May 2015 10:02:39 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-46-555e0fad274b Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E5.BD.17665.DAF0E555; Thu, 21 May 2015 19:02:37 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.30]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0210.002; Thu, 21 May 2015 19:02:36 +0200 From: Bo Burman To: Magnus Westerlund , Robert Sparks , General Area Review Team , "avtext@ietf.org" , "ietf@ietf.org" , "draft-ietf-avtext-rtp-grouping-taxonomy@ietf.org" Thread-Topic: Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 Thread-Index: AQHQjntFWS39iWtHHkSOeprIEz9gWZ2BXi0AgAVTNsA= Date: Thu, 21 May 2015 17:02:35 +0000 Message-ID: References: <5554F5D3.7080204@nostrum.com> <5559B2FA.20801@ericsson.com> In-Reply-To: <5559B2FA.20801@ericsson.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvre5a/rhQgxV75C0+3rvBajG3/waz xdVXn1ksnm2cz2JxbU4jmwOrx5IlP5k8Zu18whLAFMVlk5Kak1mWWqRvl8CVMfnaffaCNoWK 39vnsTYwzpHvYuTkkBAwkXg09wUjhC0mceHeerYuRi4OIYGjjBLvtp1lhHAWM0r8/vSEGaSK TUBDYv6Ou2AdIgL7mCR+vIsCsYUFPCWudCxjhYh7AU1tZe9i5ACyrSTen5UECbMIqEqcOr2d HcTmFfCV+Pz4AViJkICHRPfjXJAwp4CWxPSmq2DTGQVkJe5/v8cCYjMLiEvcejKfCeJOAYkl e84zQ9iiEi8f/2MFGSMhoCQxbWsaiMksoCmxfpc+RKeixJTuh1BLBSVOznzCMoFRdBaSobMQ OmYh6ZiFpGMBI8sqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMDoObjlt+4OxtWvHQ8xCnAw KvHwKtjEhgqxJpYVV+YeYpTmYFES5/XqCgkVEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwOjo I7dtwfxDJWZL917r5m414jabO0fsxeKsXBHvc9daqiuNpHedZYx7/7d6t1/y06By/vK0QkvW Ka6VzRI1bJuWquh9dGFddlT03CsRu8A6s2mGym95w0r7tnQX6+7gfZ1TF3CqbUJ68M+zV0Xf 6hbO2/ZQ+7VO5I8b3V8Kgh8XGDE9zhJtVmIpzkg01GIuKk4EAFp9rZl/AgAA Archived-At: Subject: Re: [avtext] Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:02:42 -0000 SSBhZ3JlZSB0aGF0IHRoZXJlIHNob3VsZCBiZSB0ZXh0IGV4cGxpY2l0bHkgZGlzY3Vzc2luZyBT UlRQLCBhbmQgaGF2aW5nIGl0IGFzIGEgc2VwYXJhdGUgdHJhbnNmb3JtYXRpb24gaXMgbGlrZWx5 IHRoZSBiZXN0IG9wdGlvbi4NCg0KT25lIHJlYXNvbiB0byBrZWVwIGl0IGFzIGEgc2VwYXJhdGUg dHJhbnNmb3JtYXRpb24gaXMgdG8gYmUgYWJsZSB0byBkZXNjcmliZSB0aGUgcmVsYXRpb24gdG8g dGhlIFJUUC1iYXNlZCBSZWR1bmRhbmN5IHRyYW5zZm9ybWF0aW9uLiBUaGF0IHdvdWxkIG5vdCBi ZSBwb3NzaWJsZSBpZiBTUlRQIHdlcmUgdG8gYmUgZGVzY3JpYmVkIGFzIGFuIGNvbmZpZ3VyYXRp b24gb3B0aW9uIHRvIHRoZSBNZWRpYSBQYWNrZXRpemVyLCBmb3IgZXhhbXBsZS4gTmV3IDIuMS54 IHN1Yi1zZWN0aW9ucyBmb3IgdGhhdCB0cmFuc2Zvcm1hdGlvbiBhbmQgdGhlIHJlc3VsdGluZyBz dHJlYW0gd2lsbCBiZSBuZWVkZWQsIGFzIHdlbGwgYXMgYW4gdXBkYXRlIHRvIHRoZSBtZWRpYSBj aGFpbiBmaWd1cmVzLiBJIHdpbGwgd29yayB3aXRoIE1hZ251cywgbXkgY28tYXV0aG9ycyBhbmQg dGhlIFdHLCBhbmQgY29tZSB1cCB3aXRoIGEgdGV4dCBwcm9wb3NhbC4NCg0KSSB3aWxsIHJlc3Bv bmQgdG8gdGhlIG90aGVyIGNvbW1lbnRzIGluIHRoZSBzZXBhcmF0ZSB0aHJlYWQsIHJlZHVjaW5n IHRoZSBzZW5kbGlzdCBzb21ld2hhdC4NCg0KQ2hlZXJzLA0KQm8gQg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hZ251cyBXZXN0ZXJsdW5kIFttYWlsdG86bWFnbnVz Lndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tXQ0KPiBTZW50OiBkZW4gMTggbWFqIDIwMTUgMTE6MzgN Cj4gVG86IFJvYmVydCBTcGFya3M7IEdlbmVyYWwgQXJlYSBSZXZpZXcgVGVhbTsgYXZ0ZXh0QGll dGYub3JnOyBpZXRmQGlldGYub3JnOyBkcmFmdC1pZXRmLWF2dGV4dC1ydHAtZ3JvdXBpbmctDQo+ IHRheG9ub215QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBHZW5hcnQgTEMgcmV2aWV3OiBkcmFm dC1pZXRmLWF2dGV4dC1ydHAtZ3JvdXBpbmctdGF4b25vbXktMDYNCj4gDQo+IFJvYmVydCBTcGFy a3Mgc2tyZXYgZGVuIDIwMTUtMDUtMTQgMjE6MjE6DQo+IA0KPiA+IE1ham9yIGlzc3VlczoNCj4g Pg0KPiA+IEknbSBzdXJwcmlzZWQgdGhhdCB0aGVyZSBpcyBubyBtZW50aW9uIG9mIGhvdyBTUlRQ IGZpdHMgaW50byB0aGUNCj4gPiB2b2NhYnVsYXJ5IHRoaXMgZG9jdW1lbnQgYnVpbGRzLiBXb3Vs ZCBpdCBiZSBhIG1pc3Rha2UgZm9yIHNvbWVvbmUgdG8NCj4gPiB0aGluayBvZiBTUlRQIGFzIHdo YXQgdGhpcyBkb2N1bWVudCBjYWxscyBhIHRyYW5zZm9ybWF0aW9uPyBBcmUgdGhlcmUNCj4gPiBh bnkgY29uc2VxdWVuY2VzIG9mIHVzaW5nIFNSVFAgb24gb25lIG9yIG1vcmUgb2YgdGhlIHN0cmVh bXMgYmVpbmcNCj4gPiBhc3NvY2lhdGVkIHRoYXQgaW1wYWN0IGhvdyB5b3Ugd291bGQgdGFsayBh Ym91dCB0aGUgYXNzb2NpYXRpb24/DQo+ID4gKFRoZXJlIGFyZSBjZXJ0YWlubHkgY29uc2VxdWVu Y2VzIGFib3V0IHdoaWNoIGVsZW1lbnRzIGNhbiBzZWUgaW50bw0KPiA+IHRoZSB2YXJpb3VzIHN0 cmVhbXMpLg0KPiA+DQo+IA0KPiBZZXMsIGVuY3J5cHRpb24gaXMgY2xlYXJseSBhIHRyYW5zZm9y bWF0aW9uLiBBbmQgdGhlcmUgYXJlIGNhc2VzIHdoZXJlIHRoZSBvcmRlciBvZiB0aGUgZW5jcnlw dGlvbiBhbmQgb3RoZXINCj4gdHJhbnNmb3JtYXRpb25zLCBsaWtlIEZFQywgZG8gbWF0dGVyLiBU aHVzLCBJIGFncmVlIHRoYXQgaXQgaXMgYW4gc2lnbmlmaWNhbnQgb3ZlcnNpZ2h0IHRvIG5vdCBp bmNsdWRlIHNlY3VyaXR5Lg0KPiANCj4gU28gU1JUUCBpcyBhbiBTZWN1cmluZyAvIFByb3RlY3Rp b24gKGFzIGl0IGlzIG5vdCBvbmx5IEVuY3J5cHRpb24pIHRyYW5zZm9ybWF0aW9uIHRoYXQgb3Bl cmF0ZXMgb24gU291cmNlIFJUUCBTdHJlYW1zIG9yDQo+IFJlZHVuZGFuY3kgUlRQIFN0cmVhbXMg dG8gY3JlYXRlIFNlY3VyZWQgU291cmNlIFJUUCBTdHJlYW1zIG9yIFNlY3VyZWQgUmVkdW5kYW5j eSBSVFAgU3RyZWFtLg0KPiANCj4gSWYgb25lIGxvb2tzIG9uIHNvbWV0aGluZyBsaWtlIElTTUFj cnlwdCB0aGF0IG9wZXJhdGVzIG9uIGEgc3BlY2lhbCBmb3JtIG9mIHBhY2tldGl6ZWQgZW5jb2Rl ZCBzdHJlYW1zLCBpLmUuIHBheWxvYWQNCj4gY3JlYXRlZCwgYnV0IG5vdCBSVFAgaGVhZGVycywg d2UgZ2V0IGludG8gZnVydGhlciBkaXN0aW5jdGlvbnMgdGhhdCB3ZSBzbyBmYXIgaGF2ZW4ndCBu ZWVkZWQgdG8gaGF2ZS4NCj4gDQo+IEkgZG9uJ3Qga25vdyBob3cgd2VsbCB3ZSBtdXN0IGVuc3Vy ZSB0aGF0IHNvbWV0aGluZyBsaWtlIElTTUFjcnlwdCBpcyBjbGVhcmx5IGRlZmluZWQsIGJlY2F1 c2UgdGhlbiB3ZSBkbyBuZWVkIHRvDQo+IHNwbGl0IHRoZSBSVFAgcGFja2V0aXphdGlvbiB0cmFu c2Zvcm1hdGlvbiBpbnRvIHR3byBwYXJ0cy4NCj4gDQo+IENoZWVycw0KPiANCj4gTWFnbnVzIFdl c3Rlcmx1bmQNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gU2VydmljZXMsIE1lZGlhIGFuZCBOZXR3 b3JrIGZlYXR1cmVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFhNDQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+ IEbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+ IFNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRA ZXJpY3Nzb24uY29tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K From nobody Thu May 21 10:17:34 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D061A0084; Thu, 21 May 2015 10:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 sSSciEPKo_z3; Thu, 21 May 2015 10:17:30 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C551A0092; Thu, 21 May 2015 10:17:25 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-f6-555e13235a79 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BB.FE.17665.3231E555; Thu, 21 May 2015 19:17:23 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.30]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0210.002; Thu, 21 May 2015 19:17:22 +0200 From: Bo Burman To: Robert Sparks , "avtext@ietf.org" , "draft-ietf-avtext-rtp-grouping-taxonomy@ietf.org" Thread-Topic: Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 Thread-Index: AQHQjntFWS39iWtHHkSOeprIEz9gWZ2GDY0w Date: Thu, 21 May 2015 17:17:22 +0000 Message-ID: References: <5554F5D3.7080204@nostrum.com> In-Reply-To: <5554F5D3.7080204@nostrum.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM+Jvra6ycFyowbzPRhYf791gtZjbf4PZ 4tqcRjYHZo8lS34yecza+YQlgCmKyyYlNSezLLVI3y6BK2PFls2sBe/6GCuaP+g2MM7oZuxi 5OSQEDCReHfsAxuELSZx4d56IJuLQ0jgKKPEkWM/WCGcxYwS63Y1soJUsQloSMzfcZcRJCEi sINRYsHkw2DtzAJmEld7b7CD2MICnhJXOpaBNYgIeEk8mtvKDmEbSRxbfAiomYODRUBVYvGH WBCTV8BXYmWjN0iFkICWxMYZf8GO4xTQljg9fSGYzSggK3H/+z0WiE3iEreezGeCOFpAYsme 88wQtqjEy8f/WEFGSggoSUzbmgZiMgtoSqzfpQ/RqSgxpfsh2C28AoISJ2c+YZnAKDYLydBZ CB2zkHTMQtKxgJFlFaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZgFB3c8lt3B+Pq146HGAU4 GJV4eBVsYkOFWBPLiitzDzFKc7AoifN6dYWECgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBk etBw2fPDn7lR5+YYmHxbNuf1Fps0u8bdpxr+Bd2eUpvyOdNv7+yPnp+V77iIrypR2611dslq xnPyxqxa5vvVCnjPXRaqef5S6Ugj8yGmtBtBdTm/8rx1F878brSGzfKSQ7ow87H7TrvZEpq0 RfXKXGeuELyj+Fngft+5jfdE57a+Vfx7wqZYiaU4I9FQi7moOBEACYEVaYMCAAA= Archived-At: Subject: Re: [avtext] Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:17:33 -0000 VGhhbmsgeW91IGZvciB0aGUgcmV2aWV3IGFuZCB5b3VyIGNvbW1lbnRzISBQbGVhc2UgZmluZCBt eSBhbnN3ZXJzIGlubGluZSBiZWxvdy4NCg0KQ2hlZXJzLA0KQm8gQg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJvYmVydCBTcGFya3MgW21haWx0bzpyanNwYXJrc0Bu b3N0cnVtLmNvbV0NCj4gU2VudDogZGVuIDE0IG1haiAyMDE1IDIxOjIyDQo+IFRvOiBHZW5lcmFs IEFyZWEgUmV2aWV3IFRlYW07IGF2dGV4dEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgZHJhZnQt aWV0Zi1hdnRleHQtcnRwLWdyb3VwaW5nLXRheG9ub215QGlldGYub3JnDQo+IFN1YmplY3Q6IEdl bmFydCBMQyByZXZpZXc6IGRyYWZ0LWlldGYtYXZ0ZXh0LXJ0cC1ncm91cGluZy10YXhvbm9teS0w Ng0KPiANCj4gSSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFm dC4gRm9yIGJhY2tncm91bmQgb24gR2VuLUFSVCwgcGxlYXNlIHNlZSB0aGUgRkFRIGF0DQo+IA0K PiA8aHR0cDovL3dpa2kudG9vbHMuaWV0Zi5vcmcvYXJlYS9nZW4vdHJhYy93aWtpL0dlbkFydGZh cT4uDQo+IA0KPiBQbGVhc2UgcmVzb2x2ZSB0aGVzZSBjb21tZW50cyBhbG9uZyB3aXRoIGFueSBv dGhlciBMYXN0IENhbGwgY29tbWVudHMgeW91IG1heSByZWNlaXZlLg0KPiANCj4gRG9jdW1lbnQ6 IGRyYWZ0LWlldGYtYXZ0ZXh0LXJ0cC1ncm91cGluZy10YXhvbm9teS0wNg0KPiBSZXZpZXdlcjog Um9iZXJ0IFNwYXJrcw0KPiBSZXZpZXcgRGF0ZTogMTQgTWF5IDIwMTUNCj4gSUVURiBMQyBFbmQg RGF0ZTogMTggTWF5IDIwMTUNCj4gSUVTRyBUZWxlY2hhdCBkYXRlOiBOb3QgY3VycmVudGx5IHNj aGVkdWxlZA0KPiANCj4gU3VtbWFyeTogVGhpcyBkcmFmdCBpcyBvbiB0aGUgcmlnaHQgdHJhY2ss IGJ1dCBoYXMgb3BlbiBpc3N1ZXMuDQo+IA0KPiBUaGlzIGRyYWZ0IGhhcyBjbGVhcmx5IGhlbHBl ZCBwcm9ncmVzcyBjb252ZXJzYXRpb25zIGFjcm9zcyBzZXZlcmFsIHdvcmtpbmcgZ3JvdXBzLCBw YXJ0aWN1bGFybHkgYXJvdW5kIGdyb3VwaW5nIHN0cmVhbXMuDQo+IEl0J3MgZ29vZCB0aGF0IGl0 IHdhcyBwdXQgdG9nZXRoZXIuIEkgd29ycnkgYSBsaXR0bGUgYWJvdXQgdGhlIHRpbWluZyBvZiBw dWJsaXNoaW5nIGl0IGFzIGFuIFJGQyBub3cgKGlzIHRoYXQgZHJpdmVuIGJ5IG90aGVyDQo+IGRv Y3VtZW50cyB3YW50aW5nIHRvIHJlZmVyZW5jZSB0aGlzIG5vcm1hdGl2ZWx5PykgcmF0aGVyIHRo YW4ga2VlcGluZyBtb3N0IG9mIGl0IGFzIGEgbGl2aW5nIGRvY3VtZW50IHNvbWV3aGVyZS4gVGhh dA0KPiBzYWlkLCBJIGRvbid0IHRoaW5rIHB1Ymxpc2hpbmcgaXQgYXMgYW4gUkZDIGlzIGdvaW5n IHRvIGh1cnQgYW55dGhpbmcsIGJ1dCBzaW5jZSBmdXR1cmUgcmVhZGVycyBhcmVuJ3QgZ29pbmcg dG8gYmUgZm9jdXNpbmcgc28NCj4gaGFyZCBvbiB0aGUgY3VycmVudCBjb252ZXJzYXRpb25zLCBJ IHdhbnQgdG8gY2hlY2sgb24gYSBjb3VwbGUgb2YgdGhpbmdzOg0KW0JvQl0gQXMgS2VpdGggYWxz byBwb2ludGVkIG91dCwgdGhpcyB3YXMgZGlzY3Vzc2VkIGluIHRoZSBXRyBhbmQgdGhlIGNvbmNs dXNpb24gdGhlcmUgd2FzIHRoYXQgdGhlcmUgc2VlbXMgdG8gYmUgbm8gcG9pbnQgaW4gZGVsYXlp bmcgcHVibGljYXRpb24uIEkgZG9uJ3QgdGhpbmsgdGhlIFdHIHJlY2VudGx5IGRpc2N1c3NlZCBu b3QgcHVibGlzaGluZyBpdCBhdCBhbGwsIGJ1dCBnaXZlbiB0aGF0IHNldmVyYWwgZHJhZnRzIGFs cmVhZHkgcmVmZXJlbmNlIGl0LCB0b2RheSAxNCAoMiBvZiB3aGljaCBub3JtYXRpdmVseSksIHRo ZSBpbmZvcm1hdGlvbiBpbiB0aGUgZG9jdW1lbnQgYXBwZWFycyBib3RoIGRlc2lyYWJsZSBhbmQg dXNlZnVsIGluIHRoZSBJRVRGIGNvbnRleHQuDQoNCj4gDQo+IE1ham9yIGlzc3VlczoNCj4gDQo+ IEknbSBzdXJwcmlzZWQgdGhhdCB0aGVyZSBpcyBubyBtZW50aW9uIG9mIGhvdyBTUlRQIGZpdHMg aW50byB0aGUgdm9jYWJ1bGFyeSB0aGlzIGRvY3VtZW50IGJ1aWxkcy4gV291bGQgaXQgYmUgYSBt aXN0YWtlDQo+IGZvciBzb21lb25lIHRvIHRoaW5rIG9mIFNSVFAgYXMgd2hhdCB0aGlzIGRvY3Vt ZW50IGNhbGxzIGEgdHJhbnNmb3JtYXRpb24/IEFyZSB0aGVyZSBhbnkgY29uc2VxdWVuY2VzIG9m IHVzaW5nIFNSVFANCj4gb24gb25lIG9yIG1vcmUgb2YgdGhlIHN0cmVhbXMgYmVpbmcgYXNzb2Np YXRlZCB0aGF0IGltcGFjdCBob3cgeW91IHdvdWxkIHRhbGsgYWJvdXQgdGhlIGFzc29jaWF0aW9u PyAoVGhlcmUgYXJlDQo+IGNlcnRhaW5seSBjb25zZXF1ZW5jZXMgYWJvdXQgd2hpY2ggZWxlbWVu dHMgY2FuIHNlZSBpbnRvIHRoZSB2YXJpb3VzIHN0cmVhbXMpLg0KW0JvQl0gKFRoaXMgd2FzIGFs c28gc2VudCBpbiBhIHNlcGFyYXRlIG1haWwpLiBJIGFncmVlIHRoYXQgdGhlcmUgc2hvdWxkIGJl IHRleHQgZXhwbGljaXRseSBkaXNjdXNzaW5nIFNSVFAsIGFuZCBoYXZpbmcgaXQgYXMgYSBzZXBh cmF0ZSB0cmFuc2Zvcm1hdGlvbiBpcyBsaWtlbHkgdGhlIGJlc3Qgb3B0aW9uLiBPbmUgcmVhc29u IHRvIGtlZXAgaXQgc2VwYXJhdGUgaXMgdG8gYmUgYWJsZSB0byBkZXNjcmliZSB0aGUgcmVsYXRp b24gdG8gdGhlIFJUUC1iYXNlZCBSZWR1bmRhbmN5IHRyYW5zZm9ybWF0aW9uLiBUaGF0IHdvdWxk IG5vdCBiZSBwb3NzaWJsZSBpZiBTUlRQIHdlcmUgdG8gYmUgZGVzY3JpYmVkIGFzIGFuIGNvbmZp Z3VyYXRpb24gb3B0aW9uIHRvIHRoZSBNZWRpYSBQYWNrZXRpemVyLCBmb3IgZXhhbXBsZS4gTmV3 IDIuMS54IHN1Yi1zZWN0aW9ucyBmb3IgdGhhdCB0cmFuc2Zvcm1hdGlvbiBhbmQgdGhlIHJlc3Vs dGluZyBzdHJlYW0gd2lsbCBiZSBuZWVkZWQsIGFzIHdlbGwgYXMgYW4gdXBkYXRlIHRvIHRoZSBt ZWRpYSBjaGFpbiBmaWd1cmVzLiBJIHdpbGwgd29yayB3aXRoIE1hZ251cyAod2hvIGFsc28gY29t bWVudGVkIGFib3V0IHRoYXQpLCBteSBjby1hdXRob3JzIGFuZCB0aGUgV0csIGFuZCBjb21lIHVw IHdpdGggYSB0ZXh0IHByb3Bvc2FsLg0KDQpBZGRpdGlvbmFsIGNvbW1lbnRzOg0KSSBoYXZlIGEg c2xpZ2h0IG5hbWluZyBwcm9ibGVtIGZvciB0aGF0IHRyYW5zZm9ybWF0aW9uLCBmb3Igc2V2ZXJh bCByZWFzb25zOg0KMSkgSSBuZWVkIHNlcGFyYXRlIG5hbWVzIGZvciBmb3J3YXJkIGFuZCByZXZl cnNlIHRyYW5zZm9ybXMsDQoyKSBpdCBpbnZvbHZlcyBib3RoIGVuY3J5cHRpb24gYW5kIGF1dGhl bnRpY2F0aW9uLCBhbmQNCjMpIEkgd2FudCB0byBrZWVwIHRoZSBuYW1lIHNob3J0LCBidXQgeWV0 IHN1ZmZpY2llbnRseSBkZXNjcmlwdGl2ZS4NCg0KT25lIG9wdGlvbiB3b3VsZCBiZSB0byBjYWxs IGl0ICJSVFAtYmFzZWQgU2VjdXJpdHkiLCBzcGVjaWZpY2FsbHkgaGF2aW5nIGEgcmVmZXJlbmNl IHRvIFJUUCBzaW1pbGFyIHRvICJSVFAtYmFzZWQgUmVkdW5kYW5jeSIuIEkgaG93ZXZlciB0aGVu IGdldCBwcm9ibGVtcyB3aXRoIHdoYXQgdG8gY2FsbCB0aGUgcmV2ZXJzZSB0cmFuc2Zvcm1hdGlv bjsgSSBkb24ndCB0aGluayBhbnl0aGluZyB3aXRoICJkZS1zZWN1cml0eSIgb3IgInVuc2VjdXJl IiB3b3Jrcy4gIlByb3RlY3QiIGFuZCAidW5wcm90ZWN0IiBjb3VsZCBwb3NzaWJseSB3b3JrLCBi dXQgcnVucyB0aGUgcmlzayBvZiBiZWluZyBtaXN0YWtlbiBmb3Igd2hhdCB3ZSBvdGhlcndpc2Ug Y2FsbCAicmVkdW5kYW5jeSIsIGxpa2UgRkVDLiBJIGNhbm5vdCBjb21lIHRvIHRoaW5rIG9mIGFu eXRoaW5nIGJldHRlciB0aGFuICJSVFAtYmFzZWQgRW5jcnlwdGlvbiIgYW5kICJSVFAtYmFzZWQg RGVjcnlwdGlvbiIsIGFuZCB0aGluayB0aGF0ICJSVFAtYmFzZWQgRW5jcnlwdGlvbiBhbmQgQXV0 aGVudGljYXRpb24iIGFuZCAiUlRQLWJhc2VkIERlY3J5cHRpb24gYW5kIEF1dGhlbnRpY2F0aW9u IiBhcmUgZmFyIHRvbyBsb25nLg0KDQpDby1hdXRob3JzOiB5b3VyIHN1Z2dlc3Rpb25zIGFyZSB3 ZWxjb21lIQ0KDQo+IA0KPiBNaW5vciBpc3N1ZXM6DQo+IA0KPiBUaGUgdGl0bGUgc2F5cyB0aGlz IGRvY3VtZW50IGlzIGFib3V0IGdyb3VwaW5nLiBXaGlsZSBjb252ZXJzYXRpb25zIGFyb3VuZCBn cm91cGluZyBtb3RpdmF0ZWQgdGhlIGRvY3VtZW50LCB0aGUgdGV4dA0KPiBnb2VzIHdlbGwgYmV5 b25kIGRlc2NyaWJpbmcgZ3JvdXBpbmcuDQo+IFRoZSBhYnN0cmFjdCBhbmQgaW50cm9kdWN0aW9u IGRvbid0IGNvbnRhaW4gdGhlIHdvcmQgJ2dyb3VwaW5nJzsgaW5zdGVhZCwgdGhleSBjYXN0IHRo ZSBkb2N1bWVudCBhcyBiZWluZyBhYm91dA0KPiBkZXNjcmliaW5nIHNvdXJjZXMsIGJ1dCB0aGUg ZG9jdW1lbnQgZ29lcyB3ZWxsIGJleW9uZCBhIHRheG9ub215IG9mIHNvdXJjZXMuIEl0IHN1Z2dl c3QgcmV3b3JraW5nIHRoZXNlIHNlY3Rpb25zIHRvDQo+IHJlZmxlY3Qgd2hhdCB0aGUgZG9jdW1l bnQgZW5kZWQgdXAgYmVpbmcuDQpbQm9CXSBXaGF0IGFib3V0IGp1c3QgcmVtb3ZpbmcgImdyb3Vw aW5nIiBmcm9tIHRoZSB0aXRsZT8NCg0KUHJvcG9zYWwgZm9yIGFic3RyYWN0Og0KT0xEOg0KICAg VGhlIHRlcm1pbm9sb2d5IGFib3V0LCBhbmQgYXNzb2NpYXRpb25zIGFtb25nLCBSZWFsLVRpbWUg VHJhbnNwb3J0DQogICBQcm90b2NvbCAoUlRQKSBzb3VyY2VzIGNhbiBiZSBjb21wbGV4IGFuZCBz b21ld2hhdCBvcGFxdWUuICBUaGlzDQogICBkb2N1bWVudCBkZXNjcmliZXMgYSBudW1iZXIgb2Yg ZXhpc3RpbmcgYW5kIHByb3Bvc2VkIHJlbGF0aW9uc2hpcHMNCiAgIGFtb25nIFJUUCBzb3VyY2Vz LCBhbmQgYXR0ZW1wdHMgdG8gZGVmaW5lIGNvbW1vbiB0ZXJtaW5vbG9neSBmb3INCiAgIGRpc2N1 c3NpbmcgcHJvdG9jb2wgZW50aXRpZXMgYW5kIHRoZWlyIHJlbGF0aW9uc2hpcHMuDQpORVc6DQog ICBUaGUgdGVybWlub2xvZ3kgYWJvdXQsIGFuZCBhc3NvY2lhdGlvbnMgYW1vbmcsIFJlYWwtVGlt ZSBUcmFuc3BvcnQNCiAgIFByb3RvY29sIChSVFApIHNvdXJjZXMgY2FuIGJlIGNvbXBsZXggYW5k IHNvbWV3aGF0IG9wYXF1ZS4gIFRoaXMNCiAgIGRvY3VtZW50IGRlc2NyaWJlcyBhIG51bWJlciBv ZiBleGlzdGluZyBhbmQgcHJvcG9zZWQgcHJvcGVydGllcyBhbmQNCiAgIHJlbGF0aW9uc2hpcHMg YW1vbmcgUlRQIHNvdXJjZXMsIGFuZCBkZWZpbmVzIGNvbW1vbiB0ZXJtaW5vbG9neSBmb3INCiAg IGRpc2N1c3NpbmcgcHJvdG9jb2wgZW50aXRpZXMgYW5kIHRoZWlyIHJlbGF0aW9uc2hpcHMuDQoN ClByb3Bvc2FsIGZvciBJbnRyb2R1Y3Rpb246DQpPTEQ6DQogICBUaGUgZXhpc3RpbmcgdGF4b25v bXkgb2Ygc291cmNlcyBpbiBSVFAgaXMgb2Z0ZW4gcmVnYXJkZWQgYXMNCiAgIGNvbmZ1c2luZyBh bmQgaW5jb25zaXN0ZW50LiAgQ29uc2VxdWVudGx5LCBhIGRlZXAgdW5kZXJzdGFuZGluZyBvZg0K ICAgaG93IHRoZSBkaWZmZXJlbnQgdGVybXMgcmVsYXRlIHRvIGVhY2ggb3RoZXIgYmVjb21lcyBh IHJlYWwNCiAgIGNoYWxsZW5nZS4gIEZyZXF1ZW50bHkgY2l0ZWQgZXhhbXBsZXMgb2YgdGhpcyBj b25mdXNpb24gYXJlICgxKSBob3cNCiAgIGRpZmZlcmVudCBwcm90b2NvbHMgdGhhdCBtYWtlIHVz ZSBvZiBSVFAgdXNlIHRoZSBzYW1lIHRlcm1zIHRvDQogICBzaWduaWZ5IGRpZmZlcmVudCB0aGlu Z3MgYW5kICgyKSBob3cgdGhlIGNvbXBsZXhpdGllcyBhZGRyZXNzZWQgYXQNCiAgIG9uZSBsYXll ciBhcmUgb2Z0ZW4gZ2xvc3NlZCBvdmVyIG9yIGlnbm9yZWQgYXQgYW5vdGhlci4NCg0KICAgVGhp cyBkb2N1bWVudCBhdHRlbXB0cyB0byBwcm92aWRlIHNvbWUgY2xhcml0eSBieSByZXZpZXdpbmcg dGhlDQogICBzZW1hbnRpY3Mgb2YgdmFyaW91cyBhc3BlY3RzIG9mIHNvdXJjZXMgaW4gUlRQLiAg QXMgYW4gb3JnYW5pemluZw0KICAgbWVjaGFuaXNtLCBpdCBhcHByb2FjaGVzIHRoaXMgYnkgZGVz Y3JpYmluZyB2YXJpb3VzIHdheXMgdGhhdCBSVFANCiAgIHNvdXJjZXMgY2FuIGJlIGdyb3VwZWQg YW5kIGFzc29jaWF0ZWQgdG9nZXRoZXIuDQpORVc6DQogICBUaGUgZXhpc3RpbmcgdGF4b25vbXkg b2Ygc291cmNlcyBpbiBSZWFsLVRpbWUgVHJhbnNwb3J0IFByb3RvY29sDQogICAoUlRQKSBbUkZD MzU1MF0gaGFzIHByZXZpb3VzbHkgb2Z0ZW4gYmVlbiByZWdhcmRlZCBhcyBjb25mdXNpbmcgYW5k DQogICBpbmNvbnNpc3RlbnQuICBDb25zZXF1ZW50bHksIGEgZGVlcCB1bmRlcnN0YW5kaW5nIG9m IGhvdyB0aGUNCiAgIGRpZmZlcmVudCB0ZXJtcyByZWxhdGUgdG8gZWFjaCBvdGhlciBiZWNvbWVz IGEgcmVhbCBjaGFsbGVuZ2UuDQogICBGcmVxdWVudGx5IGNpdGVkIGV4YW1wbGVzIG9mIHRoaXMg Y29uZnVzaW9uIGFyZSAoMSkgaG93IGRpZmZlcmVudA0KICAgcHJvdG9jb2xzIHRoYXQgbWFrZSB1 c2Ugb2YgUlRQIHVzZSB0aGUgc2FtZSB0ZXJtcyB0byBzaWduaWZ5DQogICBkaWZmZXJlbnQgdGhp bmdzIGFuZCAoMikgaG93IHRoZSBjb21wbGV4aXRpZXMgYWRkcmVzc2VkIGF0IG9uZSBsYXllcg0K ICAgYXJlIG9mdGVuIGdsb3NzZWQgb3ZlciBvciBpZ25vcmVkIGF0IGFub3RoZXIuDQoNCiAgIFRo aXMgZG9jdW1lbnQgcHJvdmlkZXMgc29tZSBjbGFyaXR5IGJ5IHJldmlld2luZyB0aGUgc2VtYW50 aWNzIG9mDQogICB2YXJpb3VzIGFzcGVjdHMgb2Ygc291cmNlcyBpbiBSVFAuICBBcyBhbiBvcmdh bml6aW5nIG1lY2hhbmlzbSwgaXQNCiAgIGFwcHJvYWNoZXMgdGhpcyBieSBkZXNjcmliaW5nIHZh cmlvdXMgd2F5cyB0aGF0IFJUUCBzb3VyY2VzIGFyZQ0KICAgdHJhbnNmb3JtZWQgb24gdGhlaXIg d2F5IGJldHdlZW4gc2VuZGVyIGFuZCByZWNlaXZlciwgYW5kIGhvdyB0aGV5DQogICBjYW4gYmUg Z3JvdXBlZCBhbmQgYXNzb2NpYXRlZCB0b2dldGhlci4NCg0KPiANCj4gTml0cy9lZGl0b3JpYWwg Y29tbWVudHM6DQo+IA0KPiBJbiBtb3JlLW9yLWxlc3MgZG9jdW1lbnQgb3JkZXI6DQo+IA0KPiBU aGUgZG9jdW1lbnQgY2FsbCBvdXQgdGhlIHBvc3NpYmlsaXR5IG9mIGxvb3BzLCBidXQgbm8gZGlz Y3Vzc2lvbiBzaG93cyB0aGUgdXNlIG9mIG9uZS4gV2hhdCBtb3RpdmF0ZWQgY2FsbGluZyBvdXQg dGhlDQo+IHBvc3NpYmlsaXR5Pw0KW0JvQl0gSWYgSSByZW1lbWJlciBjb3JyZWN0bHksIGl0IHdh cyB0aGUgcmVzdWx0IG9mIGFuIGVhcmx5IGRlc2lnbiBkaXNjdXNzaW9uIGZvciB0aGUgbWVkaWEg Y2hhaW4gY29uY2VwdCB0aGF0IGNvbmNsdWRlZCB3ZSBzaG91bGQgbm90IHJ1bGUgb3V0IGxvb3Bz LCBpZiB3ZSBmb3VuZCB0aGVtIHRvIGJlIG5lY2Vzc2FyeS4gQXMgaXQgdHVybmVkIG91dCwgaXQg c2VlbXMgd2UgaGF2ZSBubyBvYnZpb3VzIHVzZSBmb3IgaXQuIEkgc3VnZ2VzdCBzaW1wbHkgcmVt b3ZpbmcgdGhhdCBsYXR0ZXIgcGFydCBvZiB0aGUgc2VudGVuY2Ugd2hlcmUgaXQgaXMgbWVudGlv bmVkLg0KDQo+IA0KPiBUaGUgdXNlIG9mICJDaGFyYWN0ZXJpc3RpY3MiIGlzIGluY29uc2lzdGVu dCBhY3Jvc3MgdGhlIHNlY3Rpb25zLiBTb21ldGltZXMgdGhlIGJ1bGxldHMgbGlzdCB0aGluZ3Mg dGhhdCBjb3VsZCBiZSB1c2VkIHRvDQo+IGNsYXNzaWZ5IGEgdGhpbmcsIGFuZCBzb21ldGltZXMg dGhleSBhcHBlYXIgdG8gYmUgYSBzZXQgb2Ygb2JzZXJ2YXRpb25zIGFib3V0IHRoZSB0aGluZy4g SXQncyBoYXJkIHRvIHRlbGwgd2hldGhlciB0aGUgbGlzdHMNCj4gYXJlIGludGVuZGVkIHRvIGJl IGNvbXBsZXRlIG9yIGV4Y2x1c2l2ZSwgZGVwZW5kaW5nIG9uIHRoZSBzZWN0aW9uLiBQZXJoYXBz IHRoZXNlIHNob3VsZCBiZSB3b3JrZWQgbW9zdGx5IGJhY2sgaW50bw0KPiB0aGUgcHJvc2UsIGxl YXZpbmcgcG9pbnRzIGhlcmUgdGhhdCBhcmUgc3BlY2lmaWMgdG8gY2xhcmlmeWluZyB0aGUgdGF4 b25vbXk/DQpbQm9CXSBUaGUgbGlzdCBpcyBub3QgaW50ZW5kZWQgdG8gYmUgY29tcGxldGUsIGFu ZCB5b3UgYXJlIHJpZ2h0IHRoYXQgdGhlIGJ1bGxldCBpbmZvcm1hdGlvbiBjb250ZW50IGlzIGlu Y29uc2lzdGVudC4gSSBhbHNvIGFncmVlIHRoYXQgZ2VuZXJhbCBvYnNlcnZhdGlvbnMgYXJlIGJl dHRlciBwbGFjZWQgYXMgYm9keSB0ZXh0LCBhcyBhcmUgcHJvYmFibHkgYW55ICJsaXN0IiB3aXRo IG9ubHkgYSBzaW5nbGUgYnVsbGV0Lg0KDQpPbmUgb2YgdGhlIHJlYXNvbnMgdG8gaGF2ZSBhIGJ1 bGxldCBsaXN0IGluIHRoZSBmaXJzdCBwbGFjZSB3YXMgdGhhdCBmb3Igc29tZSBzZWN0aW9ucywg dGhlcmUgd2VyZSBtdWx0aXBsZSBzZW50ZW5jZXMgd2l0aCBwaWVjZXMgb2YgdXNlZnVsIGluZm9y bWF0aW9uIChsaWtlIGNsYXNzaWZpY2F0aW9uKSBhbmQgb2JzZXJ2YXRpb25zIGFyb3VuZCB0aGUg dGhpbmcsIGJ1dCB0aG9zZSBzZW50ZW5jZXMgcHJvdmlkZWQgYSB3ZWFrIGxvZ2ljIGZsb3cgaW4g cHJvc2UgdGV4dCwgd2hpY2ggY291bGQgaGFtcGVyIHRoZSByZWFkZXIncyB1bmRlcnN0YW5kaW5n LiBBbiBlYXN5ICJmaXgiIHdhcyB0byBjbGVhcmx5IHNlcGFyYXRlIHRoZW0gaW50byBhIGJ1bGxl dCBsaXN0LCBidXQgdGhlICJjaGFyYWN0ZXJpc3RpY3MiIGhlYWRpbmcgZm9yIHRoYXQgbGlzdCBw cm9iYWJseSB0dXJuZWQgb3V0IHRvIGJlIGFuIGlsbCBmaXQgZm9yIHRoZSBhY3R1YWwgY29udGVu dHMuIERvIHlvdSB0aGluayBpdCBwcmVmZXJhYmxlIHRvIGNvbnZlcnQgYWxsIG9mIHRoZSBidWxs ZXQgbGlzdHMgaW50byBtb3JlIHZlcmJvc2UgcHJvc2UsIGFuZCB3b3VsZCBiZW5lZml0IHRoZSB0 ZXh0IGFzIGEgd2hvbGU/DQoNCj4gDQo+ICJUaGUgYWN0dWFsbHkgdXNlZCBjb2RlYyBpcyBhbHNv IGFuIGltcG9ydGFudCBmYWN0b3IgaW4gbWFueSBjb21tdW5pY2F0aW9uIHN5c3RlbXMuIg0KPiBp cyB1bmNsZWFyLiBXaGF0J3MgdGhpcyB0cnlpbmcgdG8gc2F5Pw0KW0JvQl0gSXQgdHJpZXMgdG8g aGlnaGxpZ2h0IHRoYXQgdGhlIGNvZGVjIHR5cGUgKG5vdCBtZWRpYSB0eXBlLCBsaWtlICJ2aWRl byIsIGJ1dCBmb3JtYXQsIGxpa2UgIkguMjY1IikgaXMgYXMgaW1wb3J0YW50IGFzIG90aGVyIHBy b3BlcnRpZXMgbGlrZSBiaXRyYXRlLCByZXNvbHV0aW9uLCBiYW5kd2lkdGggZXRjLiBJIGd1ZXNz IHlvdSBjb3VsZCBqdXN0IGFzIHdlbGwgaW5jbHVkZSAiY29kZWMiIGFzIG9uZSBpdGVtIGFtb25n IHRoZSBsaXN0ZWQgcHJvcGVydGllcywgYW5kIHJlbW92ZSB0aGUgbGFzdCBzZW50ZW5jZS4gRG8g eW91IHRoaW5rIHRoYXQgd291bGQgYmUgc3VmZmljaWVudGx5IGNsZWFyPw0KDQo+IA0KPiBJbiAy LjEuMTAsIDJuZCBwYXJhZ3JhcGgsIGlzICJhdCBsZWFzdCBzb21lIGNvbnRlbnQiIGFjY3VyYXRl PyBXaGF0IGFib3V0IHRoZSBlZGdlIGNhc2VzIHdoZXJlIGVuY29kaW5nIHJlc3VsdHMgaW4gYW4N Cj4gZW1wdHkgc3RyZWFtIChhbiBhdWRpbyBzdHJlYW0gdGhhdCBpcyBzaWxlbnQsIHdoZXJlIHRo ZSBjb2RlYyBkb2VzIHNpbGVuY2Ugc3VwcHJlc3Npb24gcmVzdWx0aW5nIGluIG5vIGJpdHMgb3V0 IGZvcg0KPiBleGFtcGxlKS4gWW91J3JlIHN0aWxsIGdvaW5nIHRvIGJlIGVtaXR0aW5nIFJUQ1Au IElzIHRoaXMgc2VjdGlvbiBzYXlpbmcgdGhhdCB0aGUgUlRQIHN0cmVhbSBkb2Vzbid0IHF1YWxp ZnkgYXMgYSBTb3VyY2UNCj4gc3RyZWFtPw0KW0JvQl0gSSB0aGluayB0aGF0ICJhdCBsZWFzdCBz b21lIiwgYXMgb3Bwb3NlZCB0byAiYWx3YXlzIGEgY29tcGxldGUiLCBpcyBpbnRlbmRlZCB0byBj b3ZlciB0aGUgY2FzZSB3aGVyZSBhbiBFbmNvZGVkIFN0cmVhbSBpcyBzcGxpdCBvbnRvIG11bHRp cGxlIFNvdXJjZSBSVFAgU3RyZWFtcy4gSSBkb24ndCB0aGluayB3ZSBoYXZlIGEgY29uY3JldGUg ZXhhbXBsZSBvZiB0aGF0IGluIHRoZSByZXN0IG9mIHRoZSB0ZXh0LCBidXQgYWxsIGV4ZW1wbGlm aWVkIG9yIGRlcGljdGVkIE1lZGlhIFBhY2tldGl6ZXIgdHJhbnNmb3JtcyBhbGwgaGF2ZSBhIHNp bmdsZSBvdXRwdXQuIERvIHlvdSB0aGluayB3ZSBzaG91bGQgZXhwbGljaXRseSBkaXNhbGxvdyB0 aGF0IGFuIEVuY29kZWQgU3RyZWFtIGlzIHNwbGl0IG9udG8gc2V2ZXJhbCBTb3VyY2UgUlRQIFN0 cmVhbXMgYnkgdGhlIE1lZGlhIFBhY2tldGl6ZXI/DQoNCkZvciB0aGUgZXh0cmVtZSBlZGdlIGNh c2Ugd2hlcmUgbm8gb3V0cHV0IGF0IGFsbCBpcyBwcm9kdWNlZCBmcm9tIHRoZSBtZWRpYSBlbmNv ZGVyLCB0aGVyZSBpcyBubyBlbmNvZGVkIHN0cmVhbS4gU2hvdWxkIGEgbWVkaWEgcGFja2V0aXpl ciB3aXRob3V0IGFueSBpbnB1dCB3aGF0c29ldmVyIGFueXdheSBwcm9kdWNlIGFuIFJUUCBzdHJl YW0/IEkgYmVsaWV2ZSB0aGF0IGRlY2lzaW9uIG11c3QgYmUgbGVmdCB1cCB0byB0aGUgaW5kaXZp ZHVhbCBSVFAgZm9ybWF0IHNwZWNpZmljYXRpb24gZm9yIHRoZSB1c2VkIGNvZGVjLCBkZXRhaWwg aW1wbGVtZW50YXRpb24gY29uc2lkZXJhdGlvbnMgbGlrZSBSVFAga2VlcC1hbGl2ZSwgYW5kIGl0 IGlzIGhhcmQgdG8gbWFuZGF0ZSBhbnkgYmVoYXZpb3IuIEFuICJhY3RpdmUiIG1lZGlhIHBhY2tl dGl6ZXIgd2l0aG91dCBpbnB1dCB3aWxsIHByb2R1Y2UgUlRDUCBzZW5kZXIgcmVwb3J0cyBmb3Ig YSBjb3VwbGUgb2YgUlRDUCBpbnRlcnZhbHMsIGJ1dCB3aWxsIHRoZW4gcmV2ZXJ0IHRvIHNlbmRp bmcgb25seSByZWNlaXZlciByZXBvcnRzLiBUaG9zZSByZWNlaXZlciByZXBvcnRzIGFyZSBmaXJz dGx5IGNvbnRyb2wgaW5mb3JtYXRpb24sIG5vdCBtZWRpYSwgYW5kIGFyZSBzZWNvbmRseSBub3Qg ZGlyZWN0bHkgcmVsYXRlZCB0byB0aGUgKHNpbGVudCkgZm9yd2FyZCBkaXJlY3Rpb24gUlRQIHN0 cmVhbS4NCg0KSSBkb24ndCB1bmRlcnN0YW5kIHlvdXIgcXVlc3Rpb24gaWYgYW4gUlRQIHN0cmVh bSB3b3VsZCBub3QgcXVhbGlmeSBhcyBhIHNvdXJjZSBzdHJlYW0/IERvIHlvdSByYXRoZXIgbWVh biB0byBhc2sgaWYgYW4gUlRDUCBzdHJlYW0gaXMgbm90IGEgc291cmNlIHN0cmVhbT8gSW4gdGhh dCBjYXNlLCBJIHdvdWxkIGxpa2UgdG8gc2F5IHllcywgaXQgaXMgc3RyaWN0bHkgbm90IHBhcnQg b2YgdGhlIHNvdXJjZSBzdHJlYW0gaXRzZWxmIGJ1dCBjb250cm9sIGluZm9ybWF0aW9uIHJlbGF0 ZWQgdG8gdGhlIHNvdXJjZSBzdHJlYW0uIERvIHlvdSB0aGluayB0aGlzIGxldmVsIG9mIFJUUC9S VENQIGRldGFpbGVkIGNvbnNpZGVyYXRpb25zIGlzIGltcG9ydGFudCB0byBpbmNsdWRlIGluIHRo ZSB0ZXh0Pw0KDQo+IA0KPiBJbiAyLjIuMSBpdCdzIG5vdCBjbGVhciB3aGF0ICJlbnN1cmUgRW5k cG9pbnQgSWRlbnRpZmljYXRpb24iIG1lYW5zLiBEaWQgeW91IG1lYW4gc29tZXRoaW5nIGxpa2Ug J2VzdGFibGlzaCcgaW5zdGVhZCBvZg0KPiAnZW5zdXJlJz8NCltCb0JdIFllcywgJ2VzdGFibGlz aCcgb3IgJ3Byb3ZpZGUnIGFyZSBwcm9iYWJseSBiZXR0ZXIgd29yZHMuDQoNCj4gDQo+IEF0IHRo ZSBlbmQgb2YgdGhlIGZpcnN0IHBhcmFncmFwaCBvZiAzLjYsIHlvdSBwb2ludCBmb3J3YXJkIHRv IDMuMTIgZm9yIGEgZGlzY3Vzc2lvbiBvZiBvdGhlciBjb25zaWRlcmF0aW9ucyBlZmZlY3Rpbmcg d2hpY2gNCj4gdXNhZ2UgaXMgZGVzaXJhYmxlLg0KPiAzLjEyIGRvZXNuJ3QgdGFsayBhYm91dCB0 aGF0LiBJdCBvbmx5IHRhbGtzIGFib3V0IGhvdyB5b3Ugc2VwYXJhdGUgdGhlIHN0cmVhbXMuIFdo YXQgaXMgIm90aGVyIGNvbnNpZGVyYXRpb25zIiBzdXBwb3NlZA0KPiB0byBiZSBwb2ludGluZyB0 bz8NCltCb0JdIEdvb2QgY2F0Y2guIEkgdGhpbmsgdGhpcyB3YXMgcG9pbnRpbmcgdG8gdGV4dCB0 aGF0IGlzIGZvciBzb21lIHJlYXNvbiBubyBsb25nZXIgdGhlcmUgaW4gMy4xMi4gT25lIG1ham9y IHJlYXNvbiB0byB1c2Ugc2VwYXJhdGUgTWVkaWEgVHJhbnNwb3J0cyBpcyB0byBtYWtlIHVzZSBv ZiBkaWZmZXJlbnQgUXVhbGl0eSBvZiBTZXJ2aWNlIHByb3ZpZGVkIGJ5IHRoZSBNZWRpYSBUcmFu c3BvcnQuIEknbGwgYWRkIHNvbWUgYnJpZWYgdGV4dCBvbiB0aGF0IGhlcmUgaW4gMy42IGluc3Rl YWQgYW5kIHBvaW50IHRvIDMuMTIgZm9yIGNvbnNpZGVyYXRpb25zIHRoYXQgc2hvdWxkIGJlIG1h ZGUgd2hlbiBzZXBhcmF0aW5nIFJUUCBzdHJlYW1zLg0KDQo+IA0KPiBWZXJ5IHRpbnkgbml0cyBh bmQgc3VnZ2VzdGlvbnM6DQo+IDIuMS40IHBhcmFncmFwaCAxIDogcy9hcyBOVFAgc3luY2hyb25p emVkL2FzIGFuIE5UUCBzeW5jaHJvbml6ZWQgY2xvY2svDQpbQm9CXSBPSy4NCg0KPiAyLjEuNCBs YXN0IGJ1bGxldCA6IEluICJBdCBhbnkgcG9pbnQsIGl0IiwgdGhlIHdvcmQgJ2l0JyBpcyBhbWJp Z3VvdXMuDQpbQm9CXSBPSy4gV2lsbCByZXBsYWNlIHdpdGggImEgTWVkaWEgU291cmNlIi4gVGhp cyBzaW5nbGUgYnVsbGV0IHdpbGwgYWxzbyBiZSByZXdvcmtlZCBpbnRvIHByb3NlIHRleHQsIGlu IGxpbmUgd2l0aCB3aGF0IGlzIHN0YXRlZCBhYm92ZS4NCg0KPiAyLjEuNiBDaGFyYWN0ZXJpc3Rp Y3MgYnVsbGV0OiBUaGlzIGlzbid0IGEgY2hhcmFjdGVyaXN0aWMgb2YgYSBNZWRpYSBlbmNvZGVy Lg0KPiAgICAgICAgVGhlIHNlbnRlbmNlIGlzIGFsbW9zdCBhIGN5Y2xpYyBkZWZpbml0aW9uLiBJ IHN1Z2dlc3QgcmVtb3ZpbmcgdGhlDQo+ICAgICAgICBjaGFyYWN0ZXJpc3RpY3Mgc2VjdGlvbiBm cm9tIHRoaXMgKG9yIHNheWluZyBzb21ldGhpbmcgZGlmZmVyZW50KS4NCltCb0JdIE9LLiBXaWxs IHJlbW92ZSwgYXMgdGhlIHNhbWUgaW5mb3JtYXRpb24gaXMgYWxyZWFkeSBwcmVzZW50IGluIHBy b3NlIHRleHQuDQoNCj4gMi4xLjE5ICJ0aGUgTWVkaWEgVHJhbnNwb3J0J3MgdHJhbnNmb3JtYXRp b24iIGlzIGFtYmlndW91cy4gV2hpY2ggb25lPw0KPiAgICAgICAgIERpZCB5b3UgbWVhbiAidGhl IGNvbWJpbmF0aW9uIG9mIG9mIHRoZSB0cmFuc3BvcnQgc2VuZGVyLCBuZXR3b3JrDQo+ICAgICAg ICAgdHJhbnNwb3J0LCBhbmQgdHJhbnNwb3J0IHJlY2VpdmVyIHRyYW5zZm9ybWF0aW9ucyIsIG9y IHNvbWV0aGluZw0KPiAgICAgICAgIGxpa2UgaXQ/DQpbQm9CXSBZZXMsIG1vdGl2YXRlZCBieSBz ZWN0aW9uIDIuMS4xMyBkZXNjcmliaW5nICJNZWRpYSBUcmFuc3BvcnQiIGFzIGFuIGFnZ3JlZ2F0 ZSB0cmFuc2Zvcm1hdGlvbiB0ZXJtIGFuZCBhbHNvIHByb3ZpZGluZyB0aGUgZGV0YWlsaW5nIG9m IGl0LiBXb3VsZCBpdCBiZSBzdWZmaWNpZW50IHRvIGluY2x1ZGUgYSByZWZlcmVuY2UgdG8gMi4x LjEzPw0KDQo+IDMuNSBDb25zaWRlciBjbGFyaWZ5aW5nICJtb25vIGVuY29kZXIiDQpbQm9CXSBX aGF0IGFib3V0ICJzaW5nbGUtY2hhbm5lbCAobW9ubykgZW5jb2RlciI/DQoNCj4gMy42IGxhc3Qg c2VudGVuY2U6IHMvVGhpcyB0by9UaGlzIGlzIHRvLyBvciBzL1RoaXMgdG8gZW5hYmxlL1RoaXMg ZW5hYmxlcy8NCltCb0JdIE9LLg0KDQo= From nobody Thu May 21 10:30:58 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E641A00F7 for ; Thu, 21 May 2015 10:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, USER_IN_DEF_DKIM_WL=-7.5] 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 b18mFTNt_ya4 for ; Thu, 21 May 2015 10:30:56 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38FC41A000B for ; Thu, 21 May 2015 10:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3112; q=dns/txt; s=iport; t=1432229456; x=1433439056; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AZoB7Ge/Tc8Zvr1NKVmRyzpgYCdh/MmJotUoYJSz4R8=; b=EfVkxrSw6UkW8afILiDvn2b725V0IULUq0F/Vk4Y88BJnr9mlGJdxm31 ISfGL2th0fhpSiolsmZAlaUzRSB+PDqDQH2J4coZIVvA5cx7DIQ69Vxoa KzT9P9R3OnQ72E8vq7A3KrzEyvXFqNn/Sfg6VeNDwjG4yDv8BLf7sAwWD Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AMBADBFV5V/4oNJK1cgxCBOIMZvw1mCYdQAhyBLjgUAQEBAQEBAYEKhCMBAQMBIxE+BxACAQgaAiYCAgIwFRACBA6IKQiuHqQQAQEBAQEBAQEBAQEBAQEBAQEBARmBIYkXgQKEMwEBHTMHgmgvgRYFi02HLYsHgSiOGoQCg1kjg3iBezqBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,470,1427760000"; d="scan'208";a="152136084" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP; 21 May 2015 17:30:55 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t4LHUts4005576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 May 2015 17:30:55 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.17]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 21 May 2015 12:30:55 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Bo Burman Thread-Topic: Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 Thread-Index: AQHQjntNHWqq3Svn20Obc5LkBHEzGZ2HCtoAgAADyAA= Date: Thu, 21 May 2015 17:30:54 +0000 Message-ID: <23BF0514-C848-4E36-8484-798FF8E18415@cisco.com> References: <5554F5D3.7080204@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.222.60] Content-Type: text/plain; charset="utf-8" Content-ID: <08D2EDF6C5799C44BF04B39615568AF1@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "avtext@ietf.org" , "draft-ietf-avtext-rtp-grouping-taxonomy@ietf.org" Subject: Re: [avtext] Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:30:57 -0000 PHNuaXA+DQoNCj4+IE1ham9yIGlzc3VlczoNCj4+IA0KPj4gSSdtIHN1cnByaXNlZCB0aGF0IHRo ZXJlIGlzIG5vIG1lbnRpb24gb2YgaG93IFNSVFAgZml0cyBpbnRvIHRoZSB2b2NhYnVsYXJ5IHRo aXMgZG9jdW1lbnQgYnVpbGRzLiBXb3VsZCBpdCBiZSBhIG1pc3Rha2UNCj4+IGZvciBzb21lb25l IHRvIHRoaW5rIG9mIFNSVFAgYXMgd2hhdCB0aGlzIGRvY3VtZW50IGNhbGxzIGEgdHJhbnNmb3Jt YXRpb24/IEFyZSB0aGVyZSBhbnkgY29uc2VxdWVuY2VzIG9mIHVzaW5nIFNSVFANCj4+IG9uIG9u ZSBvciBtb3JlIG9mIHRoZSBzdHJlYW1zIGJlaW5nIGFzc29jaWF0ZWQgdGhhdCBpbXBhY3QgaG93 IHlvdSB3b3VsZCB0YWxrIGFib3V0IHRoZSBhc3NvY2lhdGlvbj8gKFRoZXJlIGFyZQ0KPj4gY2Vy dGFpbmx5IGNvbnNlcXVlbmNlcyBhYm91dCB3aGljaCBlbGVtZW50cyBjYW4gc2VlIGludG8gdGhl IHZhcmlvdXMgc3RyZWFtcykuDQo+IFtCb0JdIChUaGlzIHdhcyBhbHNvIHNlbnQgaW4gYSBzZXBh cmF0ZSBtYWlsKS4gSSBhZ3JlZSB0aGF0IHRoZXJlIHNob3VsZCBiZSB0ZXh0IGV4cGxpY2l0bHkg ZGlzY3Vzc2luZyBTUlRQLCBhbmQgaGF2aW5nIGl0IGFzIGEgc2VwYXJhdGUgdHJhbnNmb3JtYXRp b24gaXMgbGlrZWx5IHRoZSBiZXN0IG9wdGlvbi4gT25lIHJlYXNvbiB0byBrZWVwIGl0IHNlcGFy YXRlIGlzIHRvIGJlIGFibGUgdG8gZGVzY3JpYmUgdGhlIHJlbGF0aW9uIHRvIHRoZSBSVFAtYmFz ZWQgUmVkdW5kYW5jeSB0cmFuc2Zvcm1hdGlvbi4gVGhhdCB3b3VsZCBub3QgYmUgcG9zc2libGUg aWYgU1JUUCB3ZXJlIHRvIGJlIGRlc2NyaWJlZCBhcyBhbiBjb25maWd1cmF0aW9uIG9wdGlvbiB0 byB0aGUgTWVkaWEgUGFja2V0aXplciwgZm9yIGV4YW1wbGUuIE5ldyAyLjEueCBzdWItc2VjdGlv bnMgZm9yIHRoYXQgdHJhbnNmb3JtYXRpb24gYW5kIHRoZSByZXN1bHRpbmcgc3RyZWFtIHdpbGwg YmUgbmVlZGVkLCBhcyB3ZWxsIGFzIGFuIHVwZGF0ZSB0byB0aGUgbWVkaWEgY2hhaW4gZmlndXJl cy4gSSB3aWxsIHdvcmsgd2l0aCBNYWdudXMgKHdobyBhbHNvIGNvbW1lbnRlZCBhYm91dCB0aGF0 KSwgbXkgY28tYXV0aG9ycyBhbmQgdGhlIFdHLCBhbmQgY29tZSB1cCB3aXRoIGEgdGV4dCBwcm9w b3NhbC4NCj4gDQo+IEFkZGl0aW9uYWwgY29tbWVudHM6DQo+IEkgaGF2ZSBhIHNsaWdodCBuYW1p bmcgcHJvYmxlbSBmb3IgdGhhdCB0cmFuc2Zvcm1hdGlvbiwgZm9yIHNldmVyYWwgcmVhc29uczoN Cj4gMSkgSSBuZWVkIHNlcGFyYXRlIG5hbWVzIGZvciBmb3J3YXJkIGFuZCByZXZlcnNlIHRyYW5z Zm9ybXMsDQo+IDIpIGl0IGludm9sdmVzIGJvdGggZW5jcnlwdGlvbiBhbmQgYXV0aGVudGljYXRp b24sIGFuZA0KPiAzKSBJIHdhbnQgdG8ga2VlcCB0aGUgbmFtZSBzaG9ydCwgYnV0IHlldCBzdWZm aWNpZW50bHkgZGVzY3JpcHRpdmUuDQo+IA0KPiBPbmUgb3B0aW9uIHdvdWxkIGJlIHRvIGNhbGwg aXQgIlJUUC1iYXNlZCBTZWN1cml0eSIsIHNwZWNpZmljYWxseSBoYXZpbmcgYSByZWZlcmVuY2Ug dG8gUlRQIHNpbWlsYXIgdG8gIlJUUC1iYXNlZCBSZWR1bmRhbmN5Ii4gSSBob3dldmVyIHRoZW4g Z2V0IHByb2JsZW1zIHdpdGggd2hhdCB0byBjYWxsIHRoZSByZXZlcnNlIHRyYW5zZm9ybWF0aW9u OyBJIGRvbid0IHRoaW5rIGFueXRoaW5nIHdpdGggImRlLXNlY3VyaXR5IiBvciAidW5zZWN1cmUi IHdvcmtzLiAiUHJvdGVjdCIgYW5kICJ1bnByb3RlY3QiIGNvdWxkIHBvc3NpYmx5IHdvcmssIGJ1 dCBydW5zIHRoZSByaXNrIG9mIGJlaW5nIG1pc3Rha2VuIGZvciB3aGF0IHdlIG90aGVyd2lzZSBj YWxsICJyZWR1bmRhbmN5IiwgbGlrZSBGRUMuIEkgY2Fubm90IGNvbWUgdG8gdGhpbmsgb2YgYW55 dGhpbmcgYmV0dGVyIHRoYW4gIlJUUC1iYXNlZCBFbmNyeXB0aW9uIiBhbmQgIlJUUC1iYXNlZCBE ZWNyeXB0aW9uIiwgYW5kIHRoaW5rIHRoYXQgIlJUUC1iYXNlZCBFbmNyeXB0aW9uIGFuZCBBdXRo ZW50aWNhdGlvbiIgYW5kICJSVFAtYmFzZWQgRGVjcnlwdGlvbiBhbmQgQXV0aGVudGljYXRpb24i IGFyZSBmYXIgdG9vIGxvbmcuDQo+IA0KPiBDby1hdXRob3JzOiB5b3VyIHN1Z2dlc3Rpb25zIGFy ZSB3ZWxjb21lIQ0KDQpJIHRoaW5rICJSVFAtYmFzZWQgRW5jcnlwdGlvbi9EZWNyeXB0aW9u4oCd IGlzIHRoZSBsb2dpY2FsIGNob2ljZSBhbmQgdGhlIG9uZSBJIHdvdWxkIGhhdmUgY29tZSB1cCB3 aXRoIGluZGVwZW5kZW50bHkuDQoNCkNoZWVycywNCg0KR29uemFsbw0KDQo8c25pcD4= From nobody Thu May 21 12:28:12 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3921A893C; Thu, 21 May 2015 12:28:10 -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 b-UmPcjspvTo; Thu, 21 May 2015 12:28:07 -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 7DE2D1A8924; Thu, 21 May 2015 12:28:04 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4LJS0il073549 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Thu, 21 May 2015 14:28:01 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <555E31BB.50003@nostrum.com> Date: Thu, 21 May 2015 14:27:55 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Bo Burman , "avtext@ietf.org" , "draft-ietf-avtext-rtp-grouping-taxonomy@ietf.org" References: <5554F5D3.7080204@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [avtext] Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 19:28:10 -0000 On 5/21/15 12:17 PM, Bo Burman wrote: > Thank you for the review and your comments! Please find my answers inline below. > > Cheers, > Bo B > >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@nostrum.com] >> Sent: den 14 maj 2015 21:22 >> To: General Area Review Team; avtext@ietf.org; ietf@ietf.org; draft-ietf-avtext-rtp-grouping-taxonomy@ietf.org >> Subject: Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 >> >> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at >> >> . >> >> Please resolve these comments along with any other Last Call comments you may receive. >> >> Document: draft-ietf-avtext-rtp-grouping-taxonomy-06 >> Reviewer: Robert Sparks >> Review Date: 14 May 2015 >> IETF LC End Date: 18 May 2015 >> IESG Telechat date: Not currently scheduled >> >> Summary: This draft is on the right track, but has open issues. >> >> This draft has clearly helped progress conversations across several working groups, particularly around grouping streams. >> It's good that it was put together. I worry a little about the timing of publishing it as an RFC now (is that driven by other >> documents wanting to reference this normatively?) rather than keeping most of it as a living document somewhere. That >> said, I don't think publishing it as an RFC is going to hurt anything, but since future readers aren't going to be focusing so >> hard on the current conversations, I want to check on a couple of things: > [BoB] As Keith also pointed out, this was discussed in the WG and the conclusion there was that there seems to be no point in delaying publication. I don't think the WG recently discussed not publishing it at all, but given that several drafts already reference it, today 14 (2 of which normatively), the information in the document appears both desirable and useful in the IETF context. > >> Major issues: >> >> I'm surprised that there is no mention of how SRTP fits into the vocabulary this document builds. Would it be a mistake >> for someone to think of SRTP as what this document calls a transformation? Are there any consequences of using SRTP >> on one or more of the streams being associated that impact how you would talk about the association? (There are >> certainly consequences about which elements can see into the various streams). > [BoB] (This was also sent in a separate mail). I agree that there should be text explicitly discussing SRTP, and having it as a separate transformation is likely the best option. One reason to keep it separate is to be able to describe the relation to the RTP-based Redundancy transformation. That would not be possible if SRTP were to be described as an configuration option to the Media Packetizer, for example. New 2.1.x sub-sections for that transformation and the resulting stream will be needed, as well as an update to the media chain figures. I will work with Magnus (who also commented about that), my co-authors and the WG, and come up with a text proposal. > > Additional comments: > I have a slight naming problem for that transformation, for several reasons: > 1) I need separate names for forward and reverse transforms, > 2) it involves both encryption and authentication, and > 3) I want to keep the name short, but yet sufficiently descriptive. > > One option would be to call it "RTP-based Security", specifically having a reference to RTP similar to "RTP-based Redundancy". I however then get problems with what to call the reverse transformation; I don't think anything with "de-security" or "unsecure" works. "Protect" and "unprotect" could possibly work, but runs the risk of being mistaken for what we otherwise call "redundancy", like FEC. I cannot come to think of anything better than "RTP-based Encryption" and "RTP-based Decryption", and think that "RTP-based Encryption and Authentication" and "RTP-based Decryption and Authentication" are far too long. > > Co-authors: your suggestions are welcome! > >> Minor issues: >> >> The title says this document is about grouping. While conversations around grouping motivated the document, the text >> goes well beyond describing grouping. >> The abstract and introduction don't contain the word 'grouping'; instead, they cast the document as being about >> describing sources, but the document goes well beyond a taxonomy of sources. It suggest reworking these sections to >> reflect what the document ended up being. > [BoB] What about just removing "grouping" from the title? So, this, and the changes proposed below make the title, introduction, and abstract consistent, but strengthens the notion that this document is about sources. I don't think it's only (or even mainly) about sources anymore. Would it be wrong to change the title to "A Taxonomy of Semantics and Mechanisms for the Real-Time Transport Protocol (RTP)"? If that's right, then the changes to the abstract and introduction are going to take more work. > > Proposal for abstract: > OLD: > The terminology about, and associations among, Real-Time Transport > Protocol (RTP) sources can be complex and somewhat opaque. This > document describes a number of existing and proposed relationships > among RTP sources, and attempts to define common terminology for > discussing protocol entities and their relationships. > NEW: > The terminology about, and associations among, Real-Time Transport > Protocol (RTP) sources can be complex and somewhat opaque. This > document describes a number of existing and proposed properties and > relationships among RTP sources, and defines common terminology for > discussing protocol entities and their relationships. > > Proposal for Introduction: > OLD: > The existing taxonomy of sources in RTP is often regarded as > confusing and inconsistent. Consequently, a deep understanding of > how the different terms relate to each other becomes a real > challenge. Frequently cited examples of this confusion are (1) how > different protocols that make use of RTP use the same terms to > signify different things and (2) how the complexities addressed at > one layer are often glossed over or ignored at another. > > This document attempts to provide some clarity by reviewing the > semantics of various aspects of sources in RTP. As an organizing > mechanism, it approaches this by describing various ways that RTP > sources can be grouped and associated together. > NEW: > The existing taxonomy of sources in Real-Time Transport Protocol > (RTP) [RFC3550] has previously often been regarded as confusing and > inconsistent. Consequently, a deep understanding of how the > different terms relate to each other becomes a real challenge. > Frequently cited examples of this confusion are (1) how different > protocols that make use of RTP use the same terms to signify > different things and (2) how the complexities addressed at one layer > are often glossed over or ignored at another. > > This document provides some clarity by reviewing the semantics of > various aspects of sources in RTP. As an organizing mechanism, it > approaches this by describing various ways that RTP sources are > transformed on their way between sender and receiver, and how they > can be grouped and associated together. > >> Nits/editorial comments: >> >> In more-or-less document order: >> >> The document call out the possibility of loops, but no discussion shows the use of one. What motivated calling out the >> possibility? > [BoB] If I remember correctly, it was the result of an early design discussion for the media chain concept that concluded we should not rule out loops, if we found them to be necessary. As it turned out, it seems we have no obvious use for it. I suggest simply removing that latter part of the sentence where it is mentioned. wfm > >> The use of "Characteristics" is inconsistent across the sections. Sometimes the bullets list things that could be used to >> classify a thing, and sometimes they appear to be a set of observations about the thing. It's hard to tell whether the lists >> are intended to be complete or exclusive, depending on the section. Perhaps these should be worked mostly back into >> the prose, leaving points here that are specific to clarifying the taxonomy? > [BoB] The list is not intended to be complete, and you are right that the bullet information content is inconsistent. I also agree that general observations are better placed as body text, as are probably any "list" with only a single bullet. > > One of the reasons to have a bullet list in the first place was that for some sections, there were multiple sentences with pieces of useful information (like classification) and observations around the thing, but those sentences provided a weak logic flow in prose text, which could hamper the reader's understanding. An easy "fix" was to clearly separate them into a bullet list, but the "characteristics" heading for that list probably turned out to be an ill fit for the actual contents. Do you think it preferable to convert all of the bullet lists into more verbose prose, and would benefit the text as a whole? The right balance is probably in the middle. Many of the lists would benefit from being pulled back into the prose. Those that really are lists of characteristics should probably remain as lists. > >> "The actually used codec is also an important factor in many communication systems." >> is unclear. What's this trying to say? > [BoB] It tries to highlight that the codec type (not media type, like "video", but format, like "H.265") is as important as other properties like bitrate, resolution, bandwidth etc. I guess you could just as well include "codec" as one item among the listed properties, and remove the last sentence. Do you think that would be sufficiently clear? I think that would help. > >> In 2.1.10, 2nd paragraph, is "at least some content" accurate? What about the edge cases where encoding results in an >> empty stream (an audio stream that is silent, where the codec does silence suppression resulting in no bits out for >> example). You're still going to be emitting RTCP. Is this section saying that the RTP stream doesn't qualify as a Source >> stream? > [BoB] I think that "at least some", as opposed to "always a complete", is intended to cover the case where an Encoded Stream is split onto multiple Source RTP Streams. I think we missed each other a little here - your response suggests bigger changes than I would have expected. I think we should back up a little, and focus on clarifying what "at least some content" meant. From your response, I take it that you were trying to shine the light on the cases where the stream carries only some of the overall interesting data. My (mis-)read was that it was requiring that there be some bits. > I don't think we have a concrete example of that in the rest of the text, but all exemplified or depicted Media Packetizer transforms all have a single output. Do you think we should explicitly disallow that an Encoded Stream is split onto several Source RTP Streams by the Media Packetizer? No. > > For the extreme edge case where no output at all is produced from the media encoder, there is no encoded stream. Should a media packetizer without any input whatsoever anyway produce an RTP stream? I believe that decision must be left up to the individual RTP format specification for the used codec, detail implementation considerations like RTP keep-alive, and it is hard to mandate any behavior. An "active" media packetizer without input will produce RTCP sender reports for a couple of RTCP intervals, but will then revert to sending only receiver reports. Those receiver reports are firstly control information, not media, and are secondly not directly related to the (silent) forward direction RTP stream. > > I don't understand your question if an RTP stream would not qualify as a source stream? More evidence that we missed each other. My point is simple. I think the text as written will cause confusion with silence-suppressed streams. Clarifying "at least some content" will fix that, I hope. > Do you rather mean to ask if an RTCP stream is not a source stream? In that case, I would like to say yes, it is strictly not part of the source stream itself but control information related to the source stream. Do you think this level of RTP/RTCP detailed considerations is important to include in the text? No - I wasn't trying to go that direction at all. > >> In 2.2.1 it's not clear what "ensure Endpoint Identification" means. Did you mean something like 'establish' instead of >> 'ensure'? > [BoB] Yes, 'establish' or 'provide' are probably better words. > >> At the end of the first paragraph of 3.6, you point forward to 3.12 for a discussion of other considerations effecting which >> usage is desirable. >> 3.12 doesn't talk about that. It only talks about how you separate the streams. What is "other considerations" supposed >> to be pointing to? > [BoB] Good catch. I think this was pointing to text that is for some reason no longer there in 3.12. One major reason to use separate Media Transports is to make use of different Quality of Service provided by the Media Transport. I'll add some brief text on that here in 3.6 instead and point to 3.12 for considerations that should be made when separating RTP streams. > >> Very tiny nits and suggestions: >> 2.1.4 paragraph 1 : s/as NTP synchronized/as an NTP synchronized clock/ > [BoB] OK. > >> 2.1.4 last bullet : In "At any point, it", the word 'it' is ambiguous. > [BoB] OK. Will replace with "a Media Source". This single bullet will also be reworked into prose text, in line with what is stated above. > >> 2.1.6 Characteristics bullet: This isn't a characteristic of a Media encoder. >> The sentence is almost a cyclic definition. I suggest removing the >> characteristics section from this (or saying something different). > [BoB] OK. Will remove, as the same information is already present in prose text. > >> 2.1.19 "the Media Transport's transformation" is ambiguous. Which one? >> Did you mean "the combination of of the transport sender, network >> transport, and transport receiver transformations", or something >> like it? > [BoB] Yes, motivated by section 2.1.13 describing "Media Transport" as an aggregate transformation term and also providing the detailing of it. Would it be sufficient to include a reference to 2.1.13? How about something like "the Media Transport's aggregate transformation (see section 2.1.13)" > >> 3.5 Consider clarifying "mono encoder" > [BoB] What about "single-channel (mono) encoder"? Yes - that will help. > >> 3.6 last sentence: s/This to/This is to/ or s/This to enable/This enables/ > [BoB] OK. > From nobody Fri May 22 09:05:04 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3421A1BB4; Fri, 22 May 2015 09:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Q0IaXQc2Yz8g; Fri, 22 May 2015 09:04:57 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 223971A1B6A; Fri, 22 May 2015 09:04:55 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-f0-555f53a63a08 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E2.62.04401.6A35F555; Fri, 22 May 2015 18:04:54 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.30]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0210.002; Fri, 22 May 2015 18:04:53 +0200 From: Bo Burman To: Robert Sparks , "avtext@ietf.org" , "draft-ietf-avtext-rtp-grouping-taxonomy@ietf.org" Thread-Topic: Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 Thread-Index: AQHQjntFWS39iWtHHkSOeprIEz9gWZ2GDY0wgACsboCAAXAZwA== Date: Fri, 22 May 2015 16:04:52 +0000 Message-ID: References: <5554F5D3.7080204@nostrum.com> <555E31BB.50003@nostrum.com> In-Reply-To: <555E31BB.50003@nostrum.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+Jvre6y4PhQg/WrZC0+3rvBajG3/waz xbU5jWwOzB5Llvxk8pi18wlLAFMUl01Kak5mWWqRvl0CV8aKpU3sBbtcKk6/aWdpYLzh1MXI ySEhYCJxee9SNghbTOLCvfVgtpDAUUaJta3BXYxcQPZiRonNl7exgCTYBDQk5u+4ywiSEBHY wSixYPJhsA5mATOJq7032EFsYQFPiSsdy1hBbBEBL4lHc1vZIWwniQmf/4HVswioSvQ1f2UC sXkFfCWW/t/HCrGtl1Hi8LbDYM2cApoSq+b+AbMZBWQl7n+/xwKxTFzi1pP5TBBnC0gs2XOe GcIWlXj5+B9QPQeQrSQxbWsaiMkMNGb9Ln2ITkWJKd0P2SHWCkqcnPmEZQKj2CwkQ2chdMxC 0jELSccCRpZVjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWbGIFxdHDLb9UdjJffOB5iFOBgVOLh fXA0LlSINbGsuDL3EKM0B4uSOK9nV0iokEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkb9N5N+ LAjhlpepF5XNntB0bOGU37lmB3hDPng3F272t1t3R6iU/fsOwdMFxZ+YDzu2fG2UFthqufH4 4oT6Bedr/siElr54v1LYjHna23MP5j5XFppnlB8euE6Z8fju43y1vxSelHzc+PW2t95mdW2B Js4kNddc45NL12uuvvfh/b2Npk0X7KcrsRRnJBpqMRcVJwIAnGhz4YQCAAA= Archived-At: Subject: Re: [avtext] Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 16:05:03 -0000 TW9yZSByZXNwb25zZXMgaW5saW5lLCBjdXR0aW5nIGF3YXkgcGFydHMgdGhhdCBJIGNvbnNpZGVy IGFscmVhZHkgY29uY2x1ZGVkLg0KDQpDaGVlcnMsDQpCbyBCDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9iZXJ0IFNwYXJrcyBbbWFpbHRvOnJqc3BhcmtzQG5vc3Ry dW0uY29tXQ0KPiBTZW50OiBkZW4gMjEgbWFqIDIwMTUgMjE6MjgNCj4gVG86IEJvIEJ1cm1hbjsg YXZ0ZXh0QGlldGYub3JnOyBkcmFmdC1pZXRmLWF2dGV4dC1ydHAtZ3JvdXBpbmctdGF4b25vbXlA aWV0Zi5vcmcNCj4gQ2M6IE1hZ251cyBXZXN0ZXJsdW5kDQo+IFN1YmplY3Q6IFJlOiBHZW5hcnQg TEMgcmV2aWV3OiBkcmFmdC1pZXRmLWF2dGV4dC1ydHAtZ3JvdXBpbmctdGF4b25vbXktMDYNCj4g DQo+IE9uIDUvMjEvMTUgMTI6MTcgUE0sIEJvIEJ1cm1hbiB3cm90ZToNCj4gPiBUaGFuayB5b3Ug Zm9yIHRoZSByZXZpZXcgYW5kIHlvdXIgY29tbWVudHMhIFBsZWFzZSBmaW5kIG15IGFuc3dlcnMg aW5saW5lIGJlbG93Lg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IEJvIEINCj4gPg0KPiA+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBSb2JlcnQgU3BhcmtzIFttYWlsdG86 cmpzcGFya3NAbm9zdHJ1bS5jb21dDQo+ID4+IFNlbnQ6IGRlbiAxNCBtYWogMjAxNSAyMToyMg0K PiA+PiBUbzogR2VuZXJhbCBBcmVhIFJldmlldyBUZWFtOyBhdnRleHRAaWV0Zi5vcmc7IGlldGZA aWV0Zi5vcmc7DQo+ID4+IGRyYWZ0LWlldGYtYXZ0ZXh0LXJ0cC1ncm91cGluZy10YXhvbm9teUBp ZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBHZW5hcnQgTEMgcmV2aWV3OiBkcmFmdC1pZXRmLWF2dGV4 dC1ydHAtZ3JvdXBpbmctdGF4b25vbXktMDYNCj4gPj4NCg0KPHNuaXA+DQoNCj4gPj4gTWlub3Ig aXNzdWVzOg0KPiA+Pg0KPiA+PiBUaGUgdGl0bGUgc2F5cyB0aGlzIGRvY3VtZW50IGlzIGFib3V0 IGdyb3VwaW5nLiBXaGlsZSBjb252ZXJzYXRpb25zDQo+ID4+IGFyb3VuZCBncm91cGluZyBtb3Rp dmF0ZWQgdGhlIGRvY3VtZW50LCB0aGUgdGV4dCBnb2VzIHdlbGwgYmV5b25kIGRlc2NyaWJpbmcg Z3JvdXBpbmcuDQo+ID4+IFRoZSBhYnN0cmFjdCBhbmQgaW50cm9kdWN0aW9uIGRvbid0IGNvbnRh aW4gdGhlIHdvcmQgJ2dyb3VwaW5nJzsNCj4gPj4gaW5zdGVhZCwgdGhleSBjYXN0IHRoZSBkb2N1 bWVudCBhcyBiZWluZyBhYm91dCBkZXNjcmliaW5nIHNvdXJjZXMsDQo+ID4+IGJ1dCB0aGUgZG9j dW1lbnQgZ29lcyB3ZWxsIGJleW9uZCBhIHRheG9ub215IG9mIHNvdXJjZXMuIEl0IHN1Z2dlc3Qg cmV3b3JraW5nIHRoZXNlIHNlY3Rpb25zIHRvIHJlZmxlY3Qgd2hhdCB0aGUNCj4gZG9jdW1lbnQg ZW5kZWQgdXAgYmVpbmcuDQo+ID4gW0JvQl0gV2hhdCBhYm91dCBqdXN0IHJlbW92aW5nICJncm91 cGluZyIgZnJvbSB0aGUgdGl0bGU/DQo+IFNvLCB0aGlzLCBhbmQgdGhlIGNoYW5nZXMgcHJvcG9z ZWQgYmVsb3cgbWFrZSB0aGUgdGl0bGUsIGludHJvZHVjdGlvbiwgYW5kIGFic3RyYWN0IGNvbnNp c3RlbnQsIGJ1dCBzdHJlbmd0aGVucyB0aGUNCj4gbm90aW9uIHRoYXQgdGhpcyBkb2N1bWVudCBp cyBhYm91dCBzb3VyY2VzLg0KPiBJIGRvbid0IHRoaW5rIGl0J3Mgb25seSAob3IgZXZlbiBtYWlu bHkpIGFib3V0IHNvdXJjZXMgYW55bW9yZS4NCltCb0JdIFdoaWxlIHRoZSBkb2N1bWVudCBpcyBu b3Qgc3RyaWN0bHkgY29uZmluZWQgdG8gZGVzY3JpYmluZyBqdXN0ICJSVFAgc291cmNlcyIsIEkg ZG8gY29uc2lkZXIgdGhlIGN1cnJlbnQgZG9jdW1lbnQgY29udGVudHMgdG8gYmUgbWFpbmx5IGFi b3V0IHRoZSAiUlRQIHNvdXJjZXMiIGFuZCBob3cgdGhleSBhcmUgdXNlZCwgc3RhbmRhbG9uZSBv ciBpbiByZWxhdGlvbiB0byBvdGhlciAiUlRQIHNvdXJjZXMiLiBXaXRoIHRoZSB2YWd1ZSB0ZXJt ICJSVFAgc291cmNlcyIsIEkgbWVhbiB0aGUgbWVkaWEgdGhpbmdzIHRoYXQgY2FuIGJlIHRyYW5z cG9ydGVkIGZyb20gb25lIGVuZCBvZiBhIG5ldHdvcmsgdG8gYW5vdGhlciBieSBSVFAuIFRoZSBk b2N1bWVudCBjb250ZW50cyBhbHNvIGluY2x1ZGUgYSBkaXNjdXNzaW9uIGFib3V0IHRoZSBjb250 ZXh0IGluIHdoaWNoIHN1Y2ggIlJUUCBzb3VyY2VzIiBleGlzdCBhbmQgYSBoaWVyYXJjaHkgb2Yg bmFtZWQgZW50aXRpZXMgdGhhdCBjYW4gZ2VuZXJhdGUgb3IgY29uc3VtZSB0aGVtLg0KDQpXaXRo IHRoYXQgY2xhcmlmaWNhdGlvbiAoSSBob3BlKSBpbiBtaW5kLCBjb3VsZCB5b3UgZWxhYm9yYXRl IGEgYml0IG9uIHdoeSB5b3UgdGhpbmsgdGhlIGRvY3VtZW50IGlzIG5vdCBvbmx5IGFib3V0IFJU UCBzb3VyY2VzPyBNYXliZSB0aGVyZSBpcyBhIGJldHRlciBuYW1lIGZvciB0aGUgc2NvcGUgSSBk ZXNjcmliZSBhYm92ZSwgYnV0IEkgaGF2ZSBubyBiZXR0ZXIgc3VnZ2VzdGlvbi4NCg0KPiBXb3Vs ZCBpdCBiZSB3cm9uZyB0byBjaGFuZ2UgdGhlIHRpdGxlIHRvICJBIFRheG9ub215IG9mIFNlbWFu dGljcyBhbmQgTWVjaGFuaXNtcyBmb3IgdGhlIFJlYWwtVGltZSBUcmFuc3BvcnQNCj4gUHJvdG9j b2wgKFJUUCkiPw0KW0JvQl0gV2hpbGUgdGhhdCBpcyBjZXJ0YWlubHkgcG9zc2libGUsIEkgdGhp bmsgaXQgaW5zdGVhZCBoaW50cyBhIHNjb3BlIHRoYXQgaXMgd2F5IHRvbyB3aWRlIGZvciB0aGUg Y3VycmVudCBjb250ZW50cywgc3VnZ2VzdGluZyB0aGF0IHRoZSBwcm92aWRlZCB0YXhvbm9teSBp cyAiUlRQLWNvbXBsZXRlIi4gV2Ugd291bGQgYXJndWFibHkgbmVlZCB0byBpbmNsdWRlIGJldHRl ciB0YXhvbm9teSBmb3IgbWFueSBvdGhlciBhc3BlY3RzIG9mIFJUUCBhcyB3ZWxsIHRoYXQgd2Ug ZGlkIG5vdCBsb29rIGludG8sIGxpa2UgdGltZSBzdGFtcGluZywgUlRDUCByZXBvcnRpbmcsIGNv bnRyaWJ1dGluZyBzb3VyY2VzLCBSVFAgaGVhZGVyIGV4dGVuc2lvbnMsIGV0Yy4NCg0KPiBJZiB0 aGF0J3MgcmlnaHQsIHRoZW4gdGhlIGNoYW5nZXMgdG8gdGhlIGFic3RyYWN0IGFuZCBpbnRyb2R1 Y3Rpb24gYXJlIGdvaW5nIHRvIHRha2UgbW9yZSB3b3JrLg0KW0JvQl0gSWYgc28sIHRoYXQgd291 bGRuJ3QgYmUgYSBwcm9ibGVtLCBidXQgYXMgc2FpZCBhYm92ZSBJIGRvbid0ICh5ZXQpIGFncmVl IHdpdGggeW91Lg0KDQo8c25pcD4NCg0KPiA+DQo+ID4+IEluIDIuMS4xMCwgMm5kIHBhcmFncmFw aCwgaXMgImF0IGxlYXN0IHNvbWUgY29udGVudCIgYWNjdXJhdGU/IFdoYXQNCj4gPj4gYWJvdXQg dGhlIGVkZ2UgY2FzZXMgd2hlcmUgZW5jb2RpbmcgcmVzdWx0cyBpbiBhbiBlbXB0eSBzdHJlYW0g KGFuDQo+ID4+IGF1ZGlvIHN0cmVhbSB0aGF0IGlzIHNpbGVudCwgd2hlcmUgdGhlIGNvZGVjIGRv ZXMgc2lsZW5jZSBzdXBwcmVzc2lvbg0KPiA+PiByZXN1bHRpbmcgaW4gbm8gYml0cyBvdXQgZm9y IGV4YW1wbGUpLiBZb3UncmUgc3RpbGwgZ29pbmcgdG8gYmUgZW1pdHRpbmcgUlRDUC4gSXMgdGhp cyBzZWN0aW9uIHNheWluZyB0aGF0IHRoZSBSVFAgc3RyZWFtDQo+IGRvZXNuJ3QgcXVhbGlmeSBh cyBhIFNvdXJjZSBzdHJlYW0/DQo+ID4gW0JvQl0gSSB0aGluayB0aGF0ICJhdCBsZWFzdCBzb21l IiwgYXMgb3Bwb3NlZCB0byAiYWx3YXlzIGEgY29tcGxldGUiLCBpcyBpbnRlbmRlZCB0byBjb3Zl ciB0aGUgY2FzZSB3aGVyZSBhbiBFbmNvZGVkDQo+IFN0cmVhbSBpcyBzcGxpdCBvbnRvIG11bHRp cGxlIFNvdXJjZSBSVFAgU3RyZWFtcy4NCj4gSSB0aGluayB3ZSBtaXNzZWQgZWFjaCBvdGhlciBh IGxpdHRsZSBoZXJlIC0geW91ciByZXNwb25zZSBzdWdnZXN0cyBiaWdnZXIgY2hhbmdlcyB0aGFu IEkgd291bGQgaGF2ZSBleHBlY3RlZC4NCj4gDQo+IEkgdGhpbmsgd2Ugc2hvdWxkIGJhY2sgdXAg YSBsaXR0bGUsIGFuZCBmb2N1cyBvbiBjbGFyaWZ5aW5nIHdoYXQgImF0IGxlYXN0IHNvbWUgY29u dGVudCIgbWVhbnQuDQo+ICBGcm9tIHlvdXIgcmVzcG9uc2UsIEkgdGFrZSBpdCB0aGF0IHlvdSB3 ZXJlIHRyeWluZyB0byBzaGluZSB0aGUgbGlnaHQgb24gdGhlIGNhc2VzIHdoZXJlIHRoZSBzdHJl YW0gY2FycmllcyBvbmx5IHNvbWUgb2YNCj4gdGhlIG92ZXJhbGwgaW50ZXJlc3RpbmcgZGF0YS4N CltCb0JdIFllcw0KDQo+IE15IChtaXMtKXJlYWQgd2FzIHRoYXQgaXQgd2FzIHJlcXVpcmluZyB0 aGF0IHRoZXJlIGJlIHNvbWUgYml0cy4NCj4gDQo+ID4gICBJIGRvbid0IHRoaW5rIHdlIGhhdmUg YSBjb25jcmV0ZSBleGFtcGxlIG9mIHRoYXQgaW4gdGhlIHJlc3Qgb2YgdGhlIHRleHQsIGJ1dCBh bGwgZXhlbXBsaWZpZWQgb3IgZGVwaWN0ZWQgTWVkaWENCj4gUGFja2V0aXplciB0cmFuc2Zvcm1z IGFsbCBoYXZlIGEgc2luZ2xlIG91dHB1dC4gRG8geW91IHRoaW5rIHdlIHNob3VsZCBleHBsaWNp dGx5IGRpc2FsbG93IHRoYXQgYW4gRW5jb2RlZCBTdHJlYW0gaXMgc3BsaXQNCj4gb250byBzZXZl cmFsIFNvdXJjZSBSVFAgU3RyZWFtcyBieSB0aGUgTWVkaWEgUGFja2V0aXplcj8NCj4gTm8uDQpb Qm9CXSBHb29kDQoNCj4gPg0KPiA+IEZvciB0aGUgZXh0cmVtZSBlZGdlIGNhc2Ugd2hlcmUgbm8g b3V0cHV0IGF0IGFsbCBpcyBwcm9kdWNlZCBmcm9tIHRoZSBtZWRpYSBlbmNvZGVyLCB0aGVyZSBp cyBubyBlbmNvZGVkIHN0cmVhbS4NCj4gU2hvdWxkIGEgbWVkaWEgcGFja2V0aXplciB3aXRob3V0 IGFueSBpbnB1dCB3aGF0c29ldmVyIGFueXdheSBwcm9kdWNlIGFuIFJUUCBzdHJlYW0/IEkgYmVs aWV2ZSB0aGF0IGRlY2lzaW9uIG11c3QgYmUNCj4gbGVmdCB1cCB0byB0aGUgaW5kaXZpZHVhbCBS VFAgZm9ybWF0IHNwZWNpZmljYXRpb24gZm9yIHRoZSB1c2VkIGNvZGVjLCBkZXRhaWwgaW1wbGVt ZW50YXRpb24gY29uc2lkZXJhdGlvbnMgbGlrZSBSVFAga2VlcC0NCj4gYWxpdmUsIGFuZCBpdCBp cyBoYXJkIHRvIG1hbmRhdGUgYW55IGJlaGF2aW9yLiBBbiAiYWN0aXZlIiBtZWRpYSBwYWNrZXRp emVyIHdpdGhvdXQgaW5wdXQgd2lsbCBwcm9kdWNlIFJUQ1Agc2VuZGVyDQo+IHJlcG9ydHMgZm9y IGEgY291cGxlIG9mIFJUQ1AgaW50ZXJ2YWxzLCBidXQgd2lsbCB0aGVuIHJldmVydCB0byBzZW5k aW5nIG9ubHkgcmVjZWl2ZXIgcmVwb3J0cy4gVGhvc2UgcmVjZWl2ZXIgcmVwb3J0cyBhcmUNCj4g Zmlyc3RseSBjb250cm9sIGluZm9ybWF0aW9uLCBub3QgbWVkaWEsIGFuZCBhcmUgc2Vjb25kbHkg bm90IGRpcmVjdGx5IHJlbGF0ZWQgdG8gdGhlIChzaWxlbnQpIGZvcndhcmQgZGlyZWN0aW9uIFJU UCBzdHJlYW0uDQo+ID4NCj4gPiBJIGRvbid0IHVuZGVyc3RhbmQgeW91ciBxdWVzdGlvbiBpZiBh biBSVFAgc3RyZWFtIHdvdWxkIG5vdCBxdWFsaWZ5IGFzIGEgc291cmNlIHN0cmVhbT8NCj4gTW9y ZSBldmlkZW5jZSB0aGF0IHdlIG1pc3NlZCBlYWNoIG90aGVyLiBNeSBwb2ludCBpcyBzaW1wbGUu IEkgdGhpbmsgdGhlIHRleHQgYXMgd3JpdHRlbiB3aWxsIGNhdXNlIGNvbmZ1c2lvbiB3aXRoDQo+ IHNpbGVuY2Utc3VwcHJlc3NlZCBzdHJlYW1zLg0KPiBDbGFyaWZ5aW5nICJhdCBsZWFzdCBzb21l IGNvbnRlbnQiIHdpbGwgZml4IHRoYXQsIEkgaG9wZS4NCltCb0JdIEFncmVlLiBJIGhvd2V2ZXIg aGF2ZSBhIHByb2JsZW0gdG8gZmluZCBhIGdvb2Qgd29yZGluZy4gU2lsZW5jZSBzdXBwcmVzc2Vk IHN0cmVhbXMgZGVmaW5pdGVseSBxdWFsaWZ5IGFzIFNvdXJjZSBTdHJlYW1zLCBubyBhcmd1bWVu dCB0aGVyZS4gV2hhdCBhYm91dCAiLi4udGhhdCBzZW5kcyBhdCBsZWFzdCBzb21lIGNvbnRlbnQg YXQgc29tZSBwb2ludCBkdXJpbmcgaXRzIGxpZmV0aW1lLi4uIiBvciBzb21ldGhpbmcgc2ltaWxh cj8gVGhhdCB3YXksIGEgc291cmNlIHRoYXQgaXMgc2lsZW50IGZvciBpdHMgZW50aXJlIGxpZmV0 aW1lIGFuZCBuZXZlciBzZW5kcyBfYW55XyBkYXRhIHdpbGwgbm90IGJlIGNsYXNzaWZpZWQgYXMg YSBzb3VyY2UgKGRpc3JlZ2FyZGluZyBSVENQKSwgYnV0IHRoYXQgc2hvdWxkIG5vdCBwb3NlIGEg cHJvYmxlbSwgSSBndWVzcz8NCg0KPiA+IERvIHlvdSByYXRoZXIgbWVhbiB0byBhc2sgaWYgYW4g UlRDUCBzdHJlYW0gaXMgbm90IGEgc291cmNlIHN0cmVhbT8gSW4gdGhhdCBjYXNlLCBJIHdvdWxk IGxpa2UgdG8gc2F5IHllcywgaXQgaXMgc3RyaWN0bHkgbm90DQo+IHBhcnQgb2YgdGhlIHNvdXJj ZSBzdHJlYW0gaXRzZWxmIGJ1dCBjb250cm9sIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gdGhlIHNv dXJjZSBzdHJlYW0uIERvIHlvdSB0aGluayB0aGlzIGxldmVsIG9mIFJUUC9SVENQDQo+IGRldGFp bGVkIGNvbnNpZGVyYXRpb25zIGlzIGltcG9ydGFudCB0byBpbmNsdWRlIGluIHRoZSB0ZXh0Pw0K PiBObyAtIEkgd2Fzbid0IHRyeWluZyB0byBnbyB0aGF0IGRpcmVjdGlvbiBhdCBhbGwuDQpbQm9C XSBPSw0KDQo8c25pcD4NCg0K From nobody Tue May 26 13:26:19 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EC71B312F for ; Tue, 26 May 2015 13:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 YpQWZmkeTQ24 for ; Tue, 26 May 2015 13:26:15 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 68EA61B312E for ; Tue, 26 May 2015 13:26:15 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id C5743DC559F63 for ; Tue, 26 May 2015 20:26:08 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t4QKQCMI015284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 26 May 2015 22:26:12 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 26 May 2015 22:26:12 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Thread-Topic: AVTEXT scheduling for Prague Thread-Index: AdCX8jQeTFZ5679iSr2fOT6xkspZRw== Date: Tue, 26 May 2015 20:26:11 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B6971D5E0@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [avtext] AVTEXT scheduling for Prague X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 20:26:17 -0000 (As WG co-chair) We suspect that AVTEXT will need to meet in Prague, but we need to guage ho= w much time we need, given that we underestimated the amount of proposed ne= w work last time. If you are planning on submitting either a new author draft or a revision o= f an existing author draft that you think should be discussed, could you se= nd a mail to the WG chairs as soon as possible. If you want to communicate = the same information to the list, that is also fine. Do this even if you are only 50% sure that you will do so. We can hammer ou= t the agenda for unsure requests later. Regards Keith= From nobody Wed May 27 00:01:12 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAD41A87CD for ; Wed, 27 May 2015 00:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 NuaiYcxIJDN6 for ; Wed, 27 May 2015 00:01:09 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4C6C1A87C7 for ; Wed, 27 May 2015 00:01:08 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-97-55656bb28fd6 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 13.51.17665.2BB65655; Wed, 27 May 2015 09:01:07 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.210.2; Wed, 27 May 2015 09:01:06 +0200 Message-ID: <55656BB1.3090805@ericsson.com> Date: Wed, 27 May 2015 09:01:05 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , "avtext@ietf.org" References: <949EF20990823C4C85C18D59AA11AD8B6971D5E0@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6971D5E0@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyM+Jvre7m7NRQg80TWS0+3rvBavG08Syj A5NH67O9rB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp49raTpWAVT8Xqy6cYGxhfcXYxcnJICJhI 9B28yAxhi0lcuLeerYuRi0NI4CijxP+rLSwQznJGiZ4FD8GqeAW0JWb8vckKYrMIqEosXfAI LM4mYCFx80cjG4gtKhAlMfXxOhaIekGJkzOfANkcHCICSRKvjvKAhIUFjCR2H7wGNkZIIEbi 0pE7YGM4BWIlPv65zgpSzixgL/FgaxlImFlAXqJ562xmiHJtiYamDtYJjAKzkCyYhdAxC0nH AkbmVYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBIXlwy2/dHYyrXzseYhTgYFTi4VVUTQ0V Yk0sK67MPcQozcGiJM7r1RUSKiSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFxHntEjslneY7v 5zUXqpzTuTFn5QlOmwmqW4uSWI7ej1WKVlmlzXO1JOLFyg43ufs5CmbileKTf12PPrQ38dfz 1FKTsMZlDmsmxSZNirz8+CVnfdPylNczGO+HH/M9eW1/3+LP9w36Oyxm/TcWmRIbpfur7I1E xP3TqcLeTct1s/2UtXUfFdspsRRnJBpqMRcVJwIA5AYr/SoCAAA= Archived-At: Subject: Re: [avtext] AVTEXT scheduling for Prague X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 07:01:11 -0000 DRAGE, Keith (Keith) skrev den 2015-05-26 22:26: > (As WG co-chair) > > We suspect that AVTEXT will need to meet in Prague, but we need to > guage how much time we need, given that we underestimated the amount > of proposed new work last time. > > If you are planning on submitting either a new author draft or a > revision of an existing author draft that you think should be > discussed, could you send a mail to the WG chairs as soon as > possible. If you want to communicate the same information to the > list, that is also fine. > > Do this even if you are only 50% sure that you will do so. We can > hammer out the agenda for unsure requests later. > I want to request 15 minutes to discuss draft-ietf-avtext-sdes-hdr-ext-01. That is in anticipation of some feedback on the updates done that may need discussion. However, to be clear we authors aim for a WG last call shortly after Prague. To make that happen we would really prefer to get feedback before the Prague document deadline so that we can attempt to address them prior to the meeting. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu May 28 17:51:05 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CE41AD055 for ; Thu, 28 May 2015 17:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, USER_IN_DEF_DKIM_WL=-7.5] 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 Li5mZsNN1DtJ for ; Thu, 28 May 2015 17:51:02 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BCE81AD049 for ; Thu, 28 May 2015 17:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=929; q=dns/txt; s=iport; t=1432860662; x=1434070262; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=VNy2t9+7JxIshEfPA6GGHA9EarZQ990bud33+MANAYE=; b=cXJzf/C3ODIeD4eNTxjHJWf+yo63OtiTwSAi+BL+DRAzl7vzzMy+H4nW nq1Q+CwgIBdCvGAwAKdErYolnIpiG35RVgXT5ev2IXGf/nMlDu+DLWFkU LKz64IrSSl/KIiiJiiN57GSK2VqklI2Wgeca9fMncfkYrilNFz3wHhpXG g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AKBQCIt2dV/5tdJa1cgxBUXga+BoFQCoUtghQ5EwEBAQEBAQGBCoQjAQEEAQEBNzQdAQg2NwsnBAESiC0N1goBAQEBAQUBAQEBARkEi0OENAEBhQQFkwiLD5cvI2GDF2+BDDqBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,514,1427760000"; d="scan'208";a="154244846" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 29 May 2015 00:50:50 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t4T0oov8020811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 00:50:50 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Thu, 28 May 2015 19:50:50 -0500 From: "Mo Zanaty (mzanaty)" To: "DRAGE, Keith (Keith)" , "avtext@ietf.org" Thread-Topic: [avtext] AVTEXT scheduling for Prague Thread-Index: AQHQmamBwDs5Way3KU+UMy0f2TlvsA== Date: Fri, 29 May 2015 00:50:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.0.150423 x-originating-ip: [64.100.32.216] Content-Type: text/plain; charset="us-ascii" Content-ID: <203137966C0A9B439557344013971B41@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [avtext] AVTEXT scheduling for Prague X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 00:51:03 -0000 I would like to request 15 minutes for draft-berger-avtext-framemarking. S pozdravem, Mo On 5/26/15, 4:26 PM, DRAGE, Keith (Keith) wrote: (As WG co-chair) We suspect that AVTEXT will need to meet in Prague, but we need to guage how much time we need, given that we underestimated the amount of proposed new work last time. If you are planning on submitting either a new author draft or a revision of an existing author draft that you think should be discussed, could you send a mail to the WG chairs as soon as possible. If you want to communicate the same information to the list, that is also fine. Do this even if you are only 50% sure that you will do so. We can hammer out the agenda for unsure requests later. Regards Keith _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext