From ron.even.tlv@gmail.com Sat Oct 13 10:42:53 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643B221F8484; Sat, 13 Oct 2012 10:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHdHFAmqD2mF; Sat, 13 Oct 2012 10:42:51 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0F921F848F; Sat, 13 Oct 2012 10:42:50 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id fm10so250822wgb.1 for ; Sat, 13 Oct 2012 10:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=13P1b3uCyHB6NS+oK7Ltvlk6nuwylO6k2t+cBcSeg2c=; b=Od2Ly/yqDSraKXnm6iDVb+gxIQ7cyOekpO/uKoVE108qWk7y+DzPNN4/hF5rCMAw9t VL49eLHuNJgwzID+hefkYRznH9No/OofcZ++5yHskgqVlqDQIoPA9uNo641WtJfbUQMG gCfnA2BeiN9IYS+3MwZ084rWkI8eJ6bBjpfXwngQr/E31qLxy0FEHRQJNm/aT7i5eTpr D2UFYbrGBK6iY08x+spIXyq8rMEHuFyZJ6u1aiS+FF1evg/RIHHEEL3SxcSUG71Y739X Q/E0R/TMfFSEVjbE5jmRzKUbBmXmc5piFOAOtJp1nWptHBCAHyTZLy25adpPG9YBNN4P Pn6g== Received: by 10.216.211.19 with SMTP id v19mr4598994weo.91.1350150169777; Sat, 13 Oct 2012 10:42:49 -0700 (PDT) Received: from RoniE (bzq-79-176-243-9.red.bezeqint.net. [79.176.243.9]) by mx.google.com with ESMTPS id w8sm4203687wif.4.2012.10.13.10.42.46 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 13 Oct 2012 10:42:48 -0700 (PDT) From: "Roni Even" To: "'Robert Sparks'" Date: Sat, 13 Oct 2012 19:40:41 +0200 Message-ID: <022a01cda969$dfe290c0$9fa7b240$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_022B_01CDA97A.A36CC050" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2pad2O5iw3AlJxRE2NnnsSkcemUA== Content-Language: en-us Cc: iesg-secretary@ietf.org, payload@ietf.org Subject: [payload] Request for publication of draft-ietf-avt-rtp-evrc-nw-07 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 17:42:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_022B_01CDA97A.A36CC050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Robert, I'd like to request that draft-ietf-avt-rtp-evrc-nw-07, RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) I've reviewed the draft in detail, and the Payload working groups were given the opportunity to comment. The draft is documented in sufficient detail to meet the registration requirements, and doesn't conflict with other work in Payload. Accordingly, please consider it for publication. Thanks, Roni Even (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This is a standard track RFC. It is an RTP payload specification for a 3GPP2 codec. The title page header indicates it. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document specifies real-time transport protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as e-mail. Working Group Summary: This document went through two working group last call. As a result of the first one there were proposals to add some technical changes that were consented in the second working group last call. Document Quality: This is a payload specification for a 3GPP2 codec and it was reviewed by a couple of people in the payload working group. Personnel: Roni Even is the Document Shepherd and the Responsible Area Director is Robert Sparks. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd reviewed the document very carefully in version -03 during the WG last call. He has since reviewed the changes with each new version. A second WG last call was done to verify all changes with the WG before requesting publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document got a good review for an RTP payload specification by people who had interest in this work. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No need for any such review. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes, the shepherd has confirmed with all authors. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR disclosure https://datatracker.ietf.org/ipr/1766/ . The payload mailing list was notified as well as the draft author. There were no concerns. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? A typical payload specification will be interesting to some of the WG participants who have interest in using this codec with RTP. As such this document had a review from individuals who have such interest and contributed text that was added after the first WGLC. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No real ID nits in this document. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The media subtype registration was reviewed by the shepherd and a request to review was sent to ietf-type mailing list. http://www.ietf.org/mail-archive/web/ietf-types/current/msg01598.html. No comments. (13) Have all references within this document been identified as either normative or informative? yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? no (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. no (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No change to other documents already published. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document adds a new media subtype EVRC-NW. The document shepherd verified that the registration template are according to RFC 4855 and RFC4288 and that they are consistent with the body of the document. No new IANA registries are defined. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new IANA registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No formal language. ------=_NextPart_000_022B_01CDA97A.A36CC050 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

=  

Hi = Robert,

I'd like to request that = draft-ietf-avt-rtp-evrc-nw-07, RTP payload format for Enhanced Variable = Rate Narrowband-Wideband Codec (EVRC-NW)

I've reviewed the draft in detail, and the =  Payload working groups were given the opportunity to comment. The = draft is documented in sufficient detail to meet the registration = requirements, and doesn't conflict with other work in Payload. = Accordingly, please consider it for publication.

 

Thanks,

Roni = Even

 

 

(1) What type of RFC is = being requested (BCP, Proposed Standard, Internet Standard, = Informational, Experimental, or Historic)? Why is this the proper type = of RFC? Is this type of RFC indicated in the title page header? =

This is a standard track RFC. =

It is an RTP payload specification for a 3GPP2 = codec.

The title page header indicates = it.

(2) The IESG approval = announcement includes a Document Announcement Write-Up. Please provide = such a Document Announcement Write-Up. Recent examples can be found in = the "Action" announcements for approved documents. The = approval announcement contains the following sections:

Technical = Summary:

This document = specifies real-time transport protocol (RTP) payload   formats = to be used for the Enhanced Variable Rate Narrowband-Wideband Codec = (EVRC-NW).  Three media type registrations are included for EVRC-NW = RTP payload formats.  In addition, a file format is specified for = transport of EVRC-NW speech data in storage mode applications such as = e-mail.

=

Working Group Summary:

This document went through = two working group last call. As a result of the first one there were = proposals to add some technical changes that were consented in the = second working group last call.

Document = Quality:

This is a payload specification for a 3GPP2 codec = and it was reviewed by a couple of people in the payload working = group.

Personnel:

Roni Even is the Document Shepherd and the Responsible Area Director = is Robert Sparks.

(3) Briefly describe the review of this document = that was performed by the Document Shepherd. If this version of the = document is not ready for publication, please explain why the document = is being forwarded to the IESG.

The shepherd reviewed the document very carefully in version -03 = during
the WG last call. He has since reviewed the changes with each = new version.
A second WG last call was done to verify all changes = with the WG before requesting publication.

(4) Does the document Shepherd have any concerns = about the depth or breadth of the reviews that have been performed? =

This document got a good review for an RTP payload = specification by people who had interest in this = work.

(5) Do portions of the document need review from a = particular or from broader perspective, e.g., security, operational = complexity, AAA, DNS, DHCP, XML, or internationalization? If so, = describe the review that took place.

No need for any such = review.

(6) Describe any specific concerns or issues that = the Document Shepherd has with this document that the Responsible Area = Director and/or the IESG should be aware of? For example, perhaps he or = she is uncomfortable with certain parts of the document, or has concerns = whether there really is a need for it. In any event, if the WG has = discussed those issues and has indicated that it still wishes to advance = the document, detail those concerns here.

No = concerns

(7) Has each author confirmed that any and all = appropriate IPR disclosures required for full conformance with the = provisions of BCP 78 and BCP 79 have already been filed. If not, explain = why?

Yes, the shepherd has confirmed with all authors.

(8) Has an IPR disclosure been filed that = references this document? If so, summarize any WG discussion and = conclusion regarding the IPR disclosures.

There is one IPR = disclosure https://datatracker.ietf.= org/ipr/1766/ . The payload mailing list was notified as well as the = draft author. There were no concerns.

(9) How solid is the WG = consensus behind this document? Does it represent the strong concurrence = of a few individuals, with others being silent, or does the WG as a = whole understand and agree with it?

A typical payload = specification will be interesting to some of the WG participants who = have interest in using this codec with RTP. As such this document had a = review from individuals who have such interest and contributed text that = was added after the first WGLC.

(10) Has anyone threatened = an appeal or otherwise indicated extreme discontent? If so, please = summarise the areas of conflict in separate email messages to the = Responsible Area Director. (It should be in a separate email because = this questionnaire is publicly available.)

No

(11) Identify any ID nits = the Document Shepherd has found in this document. (See = http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). = Boilerplate checks are not enough; this check needs to be thorough. =

No real ID nits in this = document.

(12) Describe how the document meets any required = formal review criteria, such as the MIB Doctor, media type, and URI type = reviews.

The media subtype registration was reviewed by the = shepherd and a request to review was sent to ietf-type mailing list. =  http://www.ietf.org/mail-archive/web/ietf-types/current/msg01598.ht= ml. No comments.

(13) Have all references within this document been = identified as either normative or informative?

yes

(14) Are there normative = references to documents that are not ready for advancement or are = otherwise in an unclear state? If such normative references exist, what = is the plan for their completion?

no

(15) Are there downward = normative references references (see RFC 3967)? If so, list these = downward references to support the Area Director in the Last Call = procedure.

no

(16) Will publication of this document change the = status of any existing RFCs? Are those RFCs listed on the title page = header, listed in the abstract, and discussed in the introduction? If = the RFCs are not listed in the Abstract and Introduction, explain why, = and point to the part of the document where the relationship of this = document to the other RFCs is discussed. If this information is not in = the document, explain why the WG considers it unnecessary. =

No change to other documents already published.

(17) Describe the Document Shepherd's review of = the IANA considerations section, especially with regard to its = consistency with the body of the document. Confirm that all protocol = extensions that the document makes are associated with the appropriate = reservations in IANA registries. Confirm that any referenced IANA = registries have been clearly identified. Confirm that newly created IANA = registries include a detailed specification of the initial contents for = the registry, that allocations procedures for future registrations are = defined, and a reasonable name for the new registry has been suggested = (see RFC 5226).

This document adds a new media subtype EVRC-NW. = The document shepherd verified that the registration template are = according to RFC 4855 and RFC4288 and that they are consistent with the = body of the document.

No new IANA registries are = defined.

 

(18) List any new IANA = registries that require Expert Review for future allocations. Provide = any public guidance that the IESG would find useful in selecting the = IANA Experts for these new registries.

No new IANA = registries.

(19) Describe reviews and automated checks = performed by the Document Shepherd to validate sections of the document = written in a formal language, such as XML code, BNF rules, MIB = definitions, etc.

No formal = language.

 

------=_NextPart_000_022B_01CDA97A.A36CC050-- From 2mkristensen@gmail.com Mon Oct 15 06:26:50 2012 Return-Path: <2mkristensen@gmail.com> X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31A721F8753 for ; Mon, 15 Oct 2012 06:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KiHNtYyu3Ip for ; Mon, 15 Oct 2012 06:26:50 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF1E421F8789 for ; Mon, 15 Oct 2012 06:26:49 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so6036368oag.31 for ; Mon, 15 Oct 2012 06:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=NvRi5h/WAOFFOnt9bD4e8QawebDefFTgcmJt6VGMXns=; b=BFPfd//alZHFEkRaMDc6vW3KKW6iyIexXeuZw45D/f/6bv9wuPQdEra/kC7CY7LZq2 KtcMbhy8EH/sSVsUpzfQDIDe6pwNg06mGBmZy3IZb3BlVSY71RvpBfhH7uk9p9L+vgP0 DNmxluo7t6Hyul+8UFsmFsjXM1wc41x0Bsm+lAZHUlAYDY7mYtGlnBABoU4J/bHMMRGz w1QVA1bqMjksO0eMtiHUgEQVE4OI+pSH9laTpPHZ+YqheXx0N2t41pW1t8sXImLS0C8Q OYEznNIGjScQbSoGbskMCwKyRdlI5nWA0MgvSkQ0tnvkPG9oDLhtUVTWIgNcgThVx6q/ ajPA== MIME-Version: 1.0 Received: by 10.60.171.84 with SMTP id as20mr9517290oec.63.1350307609520; Mon, 15 Oct 2012 06:26:49 -0700 (PDT) Received: by 10.182.232.67 with HTTP; Mon, 15 Oct 2012 06:26:49 -0700 (PDT) Date: Mon, 15 Oct 2012 15:26:49 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: IETF Payload WG Content-Type: text/plain; charset=ISO-8859-1 Cc: Tom Kristensen , Roni Even Subject: [payload] Reviving max-fps draft - Re: [AVT] Definition of max-fps - related to draft-kristensen-avt-rtp-h241param discussion X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 13:26:51 -0000 As a heads up: I'm about to submit a revival version of the H.241 max-fps draft, fixed according to this previous discussion and mailing-list conclussions in the AVT WG. Therefore, I've digged up the old thread. Cf. thread starting with: http://www.ietf.org/mail-archive/web/avt/current/msg13902.html -- Tom > On 27/11/2010, Roni Even wrote: >> Hi Guys, >> >> I am OK too. I will see when we can progress it. >> >> Roni Even >> >> AVT co-chair >> >> >> >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Mo >> Zanaty (mzanaty) >> Sent: Saturday, November 27, 2010 4:52 AM >> To: Stephen Botzko; Ye-Kui Wang >> Cc: Tom Kristensen; IETF AVT WG; Tom Kristensen >> Subject: Re: [AVT] Definition of max-fps - related to >> draft-kristensen-avt-rtp-h241param discussion >> >> >> >> I also support this and agree with the text. >> >> >> >> Mo >> >> >> >> _____ >> >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of >> Stephen Botzko >> Sent: Friday, November 26, 2010 9:32 PM >> To: Ye-Kui Wang >> Cc: Tom Kristensen; IETF AVT WG; Tom Kristensen >> Subject: Re: [AVT] Definition of max-fps - related to >> draft-kristensen-avt-rtp-h241param discussion >> >> >> >> Fine with me, I support this. >> >> BR, Stephen Botzko >> >> On Fri, Nov 26, 2010 at 6:05 PM, Ye-Kui Wang >> wrote: >> >> >> Basically OK to me, as an individual, co-author of RFC3984bis and >> co-author >> of the SVC draft. What do AVT Chairs' and others think? >> >> BR, YK >> >> >>> -----Original Message----- >>> From: Tom Kristensen [mailto:tom.kristensen@tandberg.com] >>> Sent: Tuesday, November 23, 2010 4:00 AM >>> To: 'IETF AVT WG' >>> Cc: Ye-Kui Wang; Mo Zanaty (mzanaty); Charles Eckel >>> (eckelcu); Tom Kristensen >>> Subject: Definition of max-fps - related to >>> draft-kristensen-avt-rtp-h241param discussion >>> >>> AVT folks in general, >>> YK, Mo and Charles in particular; >>> >>> You'll find my suggestion for text defining max-fps aimed for >>> inclusion in RFC3984bis, as proposed by YK Wang. Please, >>> change the text as needed for clarity, correctness and so on. >>> >>> I earlier assumed it was too late to have any chance >>> including max-fps in RFC3984bis, but as long as it's fine >>> with YK Wang, the other authors of RFC3984bis, the authors of >>> the SVC draft (where RFC3984bis is a normative reference) and >>> the AVT chairs - I agree that having max-fps in RFC3984bis >>> together with the rest of the "fmtp parameters" for H.264 is >>> the best and indeed the ideal solution. >>> >>> >>> Proposal text: >>> ------ >>> max-fps: The value of max-fps is an integer indicating >>> the maximum frame rate in units of hundredths of frames per >>> second that can be efficiently received. The signaled >>> highest level is conveyed in the value of the >>> profile-level-id parameter or the max-recv-level parameter. >>> The max-fps parameter MAY be used to signal that the receiver >>> has a constraint in that it is capable of decoding video at a >>> lower frame rate than is implied by the signaled highest >>> level and, if present, one or more of the parameters >>> max-mbps, max-smbps or max-fs. >>> >>> Notice that the value of max-fps is not necessarily >>> the frame rate at which the maximum frame size can be sent, >>> it constitutes a constraint on maximum frame rate for all resolutions. >>> >>> Informational note: The max-fps parameter is >>> semantically different from max-mbps, max-smbps, max-fs, >>> max-cpb, max-dpb, and max-br in that max-fps is used to >>> signal a constraint, lowering the maximum frame rate from >>> what is implied by the signaled MaxMBPS and MaxFS. >>> >>> The encoder MUST use a frame rate equal to or less >>> than this value. In cases where the max-fps parameter is >>> absent, or not understood, the encoder is free to choose any >>> frame rate according to the highest signaled level and any >>> signaled optional parameters. >>> ------ >>> >>> >>> Some comments: >>> >>> - Not possible to align with the "extending above level" >>> semantics of existing max-* parameters. >>> >>> - If integrated in RFC3984bis; may need to mention max-fps in >>> Section 14. Backward Compatibility to RFC 3984 >>> >>> - Don't see a need to add text pointing out the absolute >>> maximum picture rate of 172 fps for all levels, as the >>> encoder obviously has to follow the H.264 spec. (MaxMBPS/MaxFS) here. >>> >>> - Don't mention a=framerate in RFC3984bis, as the SDP >>> attribute applies to all video codecs in general anyway. >>> >>> - Nobody raised any need for having the H.241 "... or the >>> maximum picture rate that can be sent" semantics in SDP land >>> during the discussion. Therefore, max-fps MUST NOT be present >>> when the direction attribute is sendonly. max-fps is not >>> usable as stream property (in declarative descriptions). >>> >>> >>> -- Tom >>> >> >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> >> >> >> > > > -- > # Cisco | http://www.cisco.com/telepresence/ > ## tomkrist@cisco.com | http://www.tandberg.com > ### | http://folk.uio.no/tomkri/ > -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ From 2mkristensen@gmail.com Mon Oct 15 22:06:31 2012 Return-Path: <2mkristensen@gmail.com> X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD4C21F88F1 for ; Mon, 15 Oct 2012 22:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6z+w7YXPmqO for ; Mon, 15 Oct 2012 22:06:26 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4113521F88EE for ; Mon, 15 Oct 2012 22:06:22 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so6928834obq.31 for ; Mon, 15 Oct 2012 22:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=vfgdzx/S83yuNOvtvtiBUjkQZVNIxwFM+d2KDvB19Gk=; b=afyhFdjgz3ONLz47jwBDSiOJVRhjKN0YcgJJvY3VhahBEyE8zytdK5ObPyP7q/TYTr L78hCEk+Su+MQpp3botSMj0feZTBCZ+U9lmCPg2zDKx7yLhaBZw9DsFASM4aEVPCX6Pj SgA23nC5QWb2Sg6Jvqq23nHw6R9kx/AFDkYIe1GnLDlWbXF00vZheCSyYWLvNZsuugCr U8uXy9j1npsUSpi/vkGRA+dltvJXbbAWGYh4OGAfGyjYaemrwxisjWwphG6VUkk2CPoW 7QoQHSSbAKXNfwD+GZWAj81ab4otR07PGPvOFHjFgGEN4wPyzxOT9jLYonPZlZ8lTh8t 9Q2w== MIME-Version: 1.0 Received: by 10.60.169.234 with SMTP id ah10mr11641076oec.12.1350363981861; Mon, 15 Oct 2012 22:06:21 -0700 (PDT) Received: by 10.182.232.67 with HTTP; Mon, 15 Oct 2012 22:06:21 -0700 (PDT) Date: Tue, 16 Oct 2012 07:06:21 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: IETF Payload WG Content-Type: text/plain; charset=ISO-8859-1 Cc: Tom Kristensen Subject: [payload] FYI - I-D Action: draft-kristensen-payload-rtp-h241param-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 05:06:32 -0000 This draft was reworked, after a period in zombie state, and submitted yesterday. Comments are welcomed! -- Tom On 15/10/2012, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Additional H.241 Parameter in the RTP Payload Format for > H.264 Video > Author(s) : Tom Kristensen > Malcolm Walters > Filename : draft-kristensen-payload-rtp-h241param-00.txt > Pages : 12 > Date : 2012-10-15 > > Abstract: > As systems increasingly are able to run video at 60 frames per > second, there is a need to signal desired frame rate to optimise > resolution choices and to avoid unnecessary resource or energy usage. > This document updates RFC6184 and defines a new optional parameter > addressing recent extensions currently supported in H.323 systems: > The signalling of the maximum frames per second that can be > efficiently received or that can be sent. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-kristensen-payload-rtp-h241param > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-kristensen-payload-rtp-h241param-00 > > > 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 > -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ From internet-drafts@ietf.org Thu Oct 18 03:22:03 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E661921F85A4; Thu, 18 Oct 2012 03:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pr6PgbNd6+8D; Thu, 18 Oct 2012 03:22:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF81621F859E; Thu, 18 Oct 2012 03:22:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121018102202.24058.10256.idtracker@ietfa.amsl.com> Date: Thu, 18 Oct 2012 03:22:02 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-avt-rtp-isac-02.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 10:22:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP Payload Format for the iSAC Codec Author(s) : Tina le Grand Paul E. Jones Pascal Huart Turaj Zakizadeh Shabestary Harald Alvestrand Filename : draft-ietf-avt-rtp-isac-02.txt Pages : 14 Date : 2012-10-18 Abstract: iSAC is a proprietary wideband speech and audio codec developed by Global IP Solutions (now part of Google), suitable for use in Voice over IP applications. This document describes the payload format for iSAC generated bit streams within a Real-Time Protocol (RTP) packet. Also included here are the necessary details for the use of iSAC with the Session Description Protocol (SDP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-isac There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avt-rtp-isac-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-rtp-isac-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From harald@alvestrand.no Thu Oct 18 03:24:57 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE1521F8540 for ; Thu, 18 Oct 2012 03:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.398 X-Spam-Level: X-Spam-Status: No, score=-110.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ort8ZBCsy7Eu for ; Thu, 18 Oct 2012 03:24:57 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4D08921F8539 for ; Thu, 18 Oct 2012 03:24:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B441139E0F3 for ; Thu, 18 Oct 2012 12:24:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfaMuDgrFd92 for ; Thu, 18 Oct 2012 12:24:52 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 3B34839E04C for ; Thu, 18 Oct 2012 12:24:52 +0200 (CEST) Message-ID: <507FD8F3.1000506@alvestrand.no> Date: Thu, 18 Oct 2012 12:24:51 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: "payload@ietf.org" Content-Type: multipart/alternative; boundary="------------000307070000040800020700" Subject: [payload] ISAC draft, ready for WG last call X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 10:24:57 -0000 This is a multi-part message in MIME format. --------------000307070000040800020700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I guess most people have forgotten about this, but still, we should be able to close off one more dangling draft... I have now completed adding a description of superwideband mode to this draft, with the help of my new co-author Turaj Shabestary. I think this should be ready for last call and IANA registration. Over to the chairs.... Harald A new version of I-D, draft-ietf-avt-rtp-isac-02.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-ietf-avt-rtp-isac Revision: 02 Title: RTP Payload Format for the iSAC Codec Creation date: 2012-10-18 WG ID: payload Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-isac-02.txt Status: http://datatracker.ietf.org/doc/draft-ietf-avt-rtp-isac Htmlized: http://tools.ietf.org/html/draft-ietf-avt-rtp-isac-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-avt-rtp-isac-02 Abstract: iSAC is a proprietary wideband speech and audio codec developed by Global IP Solutions (now part of Google), suitable for use in Voice over IP applications. This document describes the payload format for iSAC generated bit streams within a Real-Time Protocol (RTP) packet. Also included here are the necessary details for the use of iSAC with the Session Description Protocol (SDP). --------------000307070000040800020700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I guess most people have forgotten about this, but still, we should be able to close off one more dangling draft... I have now completed adding a description of superwideband mode to this draft, with the help of my new co-author Turaj Shabestary.

I think this should be ready for last call and IANA registration.
Over to the chairs....

                 Harald

A new version of I-D, draft-ietf-avt-rtp-isac-02.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Filename:        draft-ietf-avt-rtp-isac
Revision:        02
Title:           RTP Payload Format for the iSAC Codec
Creation date:   2012-10-18
WG ID:           payload
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-isac-02.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-avt-rtp-isac
Htmlized:        http://tools.ietf.org/html/draft-ietf-avt-rtp-isac-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-avt-rtp-isac-02

Abstract:
   iSAC is a proprietary wideband speech and audio codec developed by
   Global IP Solutions (now part of Google), suitable for use in Voice
   over IP applications.  This document describes the payload format for
   iSAC generated bit streams within a Real-Time Protocol (RTP) packet.
   Also included here are the necessary details for the use of iSAC with
   the Session Description Protocol (SDP).



--------------000307070000040800020700-- From internet-drafts@ietf.org Fri Oct 19 13:42:28 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1782021F87E2; Fri, 19 Oct 2012 13:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9sEYMSnATCZ; Fri, 19 Oct 2012 13:42:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9828921F879D; Fri, 19 Oct 2012 13:42:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121019204227.29423.8117.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2012 13:42:27 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-vp8-06.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 20:42:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP Payload Format for VP8 Video Author(s) : Patrik Westin Henrik F Lundin Michael Glover Justin Uberti Frank Galligan Filename : draft-ietf-payload-vp8-06.txt Pages : 29 Date : 2012-10-19 Abstract: This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-vp8 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-vp8-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-vp8-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rjsparks@nostrum.com Wed Oct 24 07:27:08 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B9D21F8ACD for ; Wed, 24 Oct 2012 07:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Q7MfV7+pozu for ; Wed, 24 Oct 2012 07:27:07 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4FB21F8AC9 for ; Wed, 24 Oct 2012 07:27:07 -0700 (PDT) Received: from unnumerable.local ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9OER6bf058627 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 24 Oct 2012 09:27:07 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <5087FABC.6010902@nostrum.com> Date: Wed, 24 Oct 2012 09:27:08 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: payload@ietf.org References: <5086FAD4.8070301@nostrum.com> In-Reply-To: <5086FAD4.8070301@nostrum.com> X-Forwarded-Message-Id: <5086FAD4.8070301@nostrum.com> Content-Type: multipart/alternative; boundary="------------060506070002030000000404" Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 14:27:08 -0000 This is a multi-part message in MIME format. --------------060506070002030000000404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Forwarding this to the correct list. RjS -------- Original Message -------- Subject: AD Review: draft-ietf-avt-rtp-evrc-nw-07 Date: Tue, 23 Oct 2012 15:15:16 -0500 From: Robert Sparks To: draft-ietf-avt-rtp-evrc-nw@tools.ietf.org, avt@ietf.org, avtcore-chairs@ietf.org CC: Gonzalo Camarillo Summary: The document should be revised before IETF LC. Primary Concern: - This document needs to point to RFC6562, at least in the security considerations section and possibly in section 11. I think the reference needs to be normative. Minor Concerns and Nits: - Section 8 refers backto a "mapping" in Section 4, but it's not clear that there's a mapping there. I suggest adding a note that ToC values are taken from the value column in the table of section 4. - This sentence from Section 6.1 does not parse well: The EVRC-NW interleaved/bundled format defines an encoding capability identification flag, which is used to signal the far end of a communication session of the instantaneous local EVRC-NW wideband/ narrowband encoding capability. Would this replacement work? The EVRC-NW interleaved/bundled format defines an encoding capability identification flag, which is used to signal the current local EVRC-NW wideband/narrowband encoding capability to the far end of a communication session. - in Section 9.1.1: When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be used. In all other contexts, the file format defined in Section 8 SHALL be used. See Section 6 for details for EVRC-NW. It needs to be clearer that you are talking about Section 7 and 6 of _this_ document. I suggest saying "Section 8 of RFCXXXX" and "Section 6 of RFCXXXX" and add a note to the RFC Editor asking them to replace XXXX with the RFC number of this document. - Section 5 paragraph 1: Suggest s/in a manner consistent with/as specified in/ --------------060506070002030000000404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Forwarding this to the correct list.

RjS


-------- Original Message --------
Subject: AD Review: draft-ietf-avt-rtp-evrc-nw-07
Date: Tue, 23 Oct 2012 15:15:16 -0500
From: Robert Sparks <rjsparks@nostrum.com>
To: draft-ietf-avt-rtp-evrc-nw@tools.ietf.org, avt@ietf.org, avtcore-chairs@ietf.org
CC: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> 


Summary: The document should be revised before IETF LC.

Primary Concern:

- This document needs to point to RFC6562, at least in the security 
considerations section and
possibly in section 11. I think the reference needs to be normative.

Minor Concerns and Nits:

- Section 8 refers backto a "mapping" in Section 4, but it's not clear 
that there's a mapping there.
I suggest adding a note that ToC values are taken from the value column 
in the table of section 4.

- This sentence from Section 6.1 does not parse well:
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the far end of a
     communication session of the instantaneous local EVRC-NW wideband/
     narrowband encoding capability.
  Would this replacement work?
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the current local EVRC-NW
     wideband/narrowband encoding capability to the far end of a 
communication
     session.

- in Section 9.1.1:
     When this media type is used in the context of transfer over RTP, the
     RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be
     used.  In all other contexts, the file format defined in Section 8
     SHALL be used.  See Section 6 for details for EVRC-NW.
  It needs to be clearer that you are talking about Section 7 and 6 of 
_this_ document.
  I suggest saying "Section 8 of RFCXXXX" and "Section 6 of RFCXXXX" 
and add a note
  to the RFC Editor asking them to replace XXXX with the RFC number of 
this document.

- Section 5 paragraph 1: Suggest s/in a manner consistent with/as 
specified in/



--------------060506070002030000000404-- From chung.cheung.chu@ericsson.com Thu Oct 25 14:26:19 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E4821F869B for ; Thu, 25 Oct 2012 14:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEr5iLwURjI2 for ; Thu, 25 Oct 2012 14:26:18 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5655E21F85C0 for ; Thu, 25 Oct 2012 14:26:18 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q9PLTF5g002018; Thu, 25 Oct 2012 16:29:30 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.98]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 25 Oct 2012 17:26:07 -0400 From: Chung Cheung Chu To: Robert Sparks , "payload@ietf.org" Date: Thu, 25 Oct 2012 17:26:07 -0400 Thread-Topic: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07 Thread-Index: Ac2x87OVg/K8w/DBRbKx2XqneIovYABAm01g Message-ID: <26490BBDEEACA14EA1A0070367B3ADBDC42E2FBFA7@EUSAACMS0702.eamcs.ericsson.se> References: <5086FAD4.8070301@nostrum.com> <5087FABC.6010902@nostrum.com> In-Reply-To: <5087FABC.6010902@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_26490BBDEEACA14EA1A0070367B3ADBDC42E2FBFA7EUSAACMS0702e_" MIME-Version: 1.0 Subject: Re: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 21:26:19 -0000 --_000_26490BBDEEACA14EA1A0070367B3ADBDC42E2FBFA7EUSAACMS0702e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert, Regarding the comment below relating to a text from Ericsson, I agree that = the proposed change does improve the readability of the sentence. Thank yo= u. However, I notice that the word "current" has been suggested to replace= "instantaneous". The word "Instantaneous" was chosen deliberately to refle= ct explicitly the dynamic nature of the encoding capability in a call sessi= on. Unless there is a strong objection, I would counter-propose to keep th= e use of "instantaneous" instead of "current". - This sentence from Section 6.1 does not parse well: The EVRC-NW interleaved/bundled format defines an encoding capability identification flag, which is used to signal the far end of a communication session of the instantaneous local EVRC-NW wideband/ narrowband encoding capability. Would this replacement work? The EVRC-NW interleaved/bundled format defines an encoding capability identification flag, which is used to signal the current local EVRC-NW wideband/narrowband encoding capability to the far end of a communication session. Regards, CC Chung-Cheung Chu Ericsson This Communication is Confidential. We only send and receive email on the = basis of the terms set out at www.ericsson.com/email_disclaimer. ________________________________ From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Robert Sparks Sent: October-24-12 10:27 AM To: payload@ietf.org Subject: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07 Forwarding this to the correct list. RjS -------- Original Message -------- Subject: AD Review: draft-ietf-avt-rtp-evrc-nw-07 Date: Tue, 23 Oct 2012 15:15:16 -0500 From: Robert Sparks To: draft-ietf-avt-rtp-evrc-nw@tools.ietf.org, avt@ietf.org, avtcore-chairs= @ietf.org CC: Gonzalo Camarillo Summary: The document should be revised before IETF LC. Primary Concern: - This document needs to point to RFC6562, at least in the security considerations section and possibly in section 11. I think the reference needs to be normative. Minor Concerns and Nits: - Section 8 refers backto a "mapping" in Section 4, but it's not clear that there's a mapping there. I suggest adding a note that ToC values are taken from the value column in the table of section 4. - This sentence from Section 6.1 does not parse well: The EVRC-NW interleaved/bundled format defines an encoding capability identification flag, which is used to signal the far end of a communication session of the instantaneous local EVRC-NW wideband/ narrowband encoding capability. Would this replacement work? The EVRC-NW interleaved/bundled format defines an encoding capability identification flag, which is used to signal the current local EVRC-NW wideband/narrowband encoding capability to the far end of a communication session. - in Section 9.1.1: When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be used. In all other contexts, the file format defined in Section 8 SHALL be used. See Section 6 for details for EVRC-NW. It needs to be clearer that you are talking about Section 7 and 6 of _this_ document. I suggest saying "Section 8 of RFCXXXX" and "Section 6 of RFCXXXX" and add a note to the RFC Editor asking them to replace XXXX with the RFC number of this document. - Section 5 paragraph 1: Suggest s/in a manner consistent with/as specified in/ --_000_26490BBDEEACA14EA1A0070367B3ADBDC42E2FBFA7EUSAACMS0702e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Robert,
 
R= egarding=20 the comment below relating to a text from Ericsson, I agree that the propos= ed=20 change does improve the readability of the sentence.  Thank you.  However, I notice t= hat the=20 word "current" has been suggested to replace "instantaneous". <= FONT=20 face=3DArial>The word "Instantaneous" was chosen deliberatel= y to=20 reflect explicitly the dynamic nature of the encoding capability = in a=20 call session.  Unless there is a strong objection, I would counter-pro= pose=20 to keep the use of "instantaneous" instead of "current".

- This sen= tence from=20 Section 6.1 does not parse well:
     The EVRC-NW=20 interleaved/bundled format defines an encoding=20 capability
     identification flag, which is used t= o=20 signal the far end of a
     communication session o= f the=20 instantaneous local EVRC-NW wideband/
     narrowban= d=20 encoding capability.
  Would this replacement=20 work?
     The EVRC-NW interleaved/bundled format de= fines=20 an encoding capability
     identification flag, whi= ch is=20 used to signal the current local EVRC-NW
    =20 wideband/narrowband encoding capability to the far end of a=20
communication
    =20 session.

Regards,<= /FONT>=20

CC=

Chung-Che= ung=20 Chu 
Ericsson

This=20 Communication is Confidential.  We only send and receive email on the = basis=20 of the terms set out at www.ericsson.com/email_disclaimer.

 

From: payload-bounces@ietf.org=20 [mailto:payload-bounces@ietf.org] On Behalf Of Robert=20 Sparks
Sent: October-24-12 10:27 AM
To:=20 payload@ietf.org
Subject: [payload] Fwd: AD Review:=20 draft-ietf-avt-rtp-evrc-nw-07

Forwarding this to the correct list.

RjS


-------- Original Message ------= --=20
Subject: AD Review: draft-ietf-avt-rtp-evrc-nw-07
Date: Tue, 23 Oct 2012 15:15:16 -0500
From: Robert Sparks <rjsparks@nostrum.com>=
To: draft-ietf-= avt-rtp-evrc-nw@tools.ietf.org,=20 avt@ietf.org, avtcore-chairs@ietf.org
CC: Gonzalo Camarillo <Gonzalo.Camarillo@= ericsson.com>


Summary: The doc=
ument should be revised before IETF LC.

Primary Concern:

- This document needs to point to RFC6562, at least in the security=20
considerations section and
possibly in section 11. I think the reference needs to be normative.

Minor Concerns and Nits:

- Section 8 refers backto a "mapping" in Section 4, but it's not clear=20
that there's a mapping there.
I suggest adding a note that ToC values are taken from the value column=20
in the table of section 4.

- This sentence from Section 6.1 does not parse well:
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the far end of a
     communication session of the instantaneous local EVRC-NW wideband/
     narrowband encoding capability.
  Would this replacement work?
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the current local EVRC-NW
     wideband/narrowband encoding capability to the far end of a=20
communication
     session.

- in Section 9.1.1:
     When this media type is used in the context of transfer over RTP, the
     RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be
     used.  In all other contexts, the file format defined in Section 8
     SHALL be used.  See Section 6 for details for EVRC-NW.
  It needs to be clearer that you are talking about Section 7 and 6 of=20
_this_ document.
  I suggest saying "Section 8 of RFCXXXX" and "Section 6 of RFCXXXX"=20
and add a note
  to the RFC Editor asking them to replace XXXX with the RFC number of=20
this document.

- Section 5 paragraph 1: Suggest s/in a manner consistent with/as=20
specified in/



--_000_26490BBDEEACA14EA1A0070367B3ADBDC42E2FBFA7EUSAACMS0702e_-- From rjsparks@nostrum.com Thu Oct 25 14:50:16 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF3821F858F for ; Thu, 25 Oct 2012 14:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.157 X-Spam-Level: X-Spam-Status: No, score=-102.157 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0t6DaGoGVm1i for ; Thu, 25 Oct 2012 14:50:15 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5C22F21F8567 for ; Thu, 25 Oct 2012 14:50:15 -0700 (PDT) Received: from unnumerable.local (pool-173-57-93-208.dllstx.fios.verizon.net [173.57.93.208]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9PLoBBh065048 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 25 Oct 2012 16:50:11 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <5089B412.9010505@nostrum.com> Date: Thu, 25 Oct 2012 16:50:10 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Chung Cheung Chu References: <5086FAD4.8070301@nostrum.com> <5087FABC.6010902@nostrum.com> <26490BBDEEACA14EA1A0070367B3ADBDC42E2FBFA7@EUSAACMS0702.eamcs.ericsson.se> In-Reply-To: <26490BBDEEACA14EA1A0070367B3ADBDC42E2FBFA7@EUSAACMS0702.eamcs.ericsson.se> Content-Type: multipart/alternative; boundary="------------060408080101010901040909" Received-SPF: pass (nostrum.com: 173.57.93.208 is authenticated by a trusted mechanism) Cc: "payload@ietf.org" Subject: Re: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 21:50:17 -0000 This is a multi-part message in MIME format. --------------060408080101010901040909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The important part is in the restructuring of the sentence. That said, I don't agree that instantaneous is the appropriate word to use here, and it's usually a warning sign that the text needs clarification when arguing about choosing words that have similar meanings. (Exactly what instant is this instantaneous capability describing?) So perhaps this instead: The EVRC-NW interleaved/bundled format defines an encoding capability identification flag, which is used to signal the local EVRC-NW wideband/narrowband encoding capability at the time of construction of an RTP packet to the far end of a communication session. RjS On 10/25/12 4:26 PM, Chung Cheung Chu wrote: > Hi Robert, > Regarding the comment below relating to a text from Ericsson, I agree > that the proposed change does improve the readability of the sentence. > Thank you. However, I notice that the word "current" has been > suggested to replace "instantaneous". The word "Instantaneous" was > chosen deliberately to reflect explicitly the dynamic nature of the > encoding capability in a call session. Unless there is a strong > objection, I would counter-propose to keep the use of "instantaneous" > instead of "current". > > - This sentence from Section 6.1 does not parse well: > The EVRC-NW interleaved/bundled format defines an encoding capability > identification flag, which is used to signal the far end of a > communication session of the instantaneous local EVRC-NW wideband/ > narrowband encoding capability. > Would this replacement work? > The EVRC-NW interleaved/bundled format defines an encoding capability > identification flag, which is used to signal the current local > EVRC-NW > wideband/narrowband encoding capability to the far end of a > communication > session. > > Regards, > > CC > > Chung-Cheung Chu > Ericsson > > /This Communication is Confidential. We only send and receive email > on the basis of the terms set out at www.ericsson.com/email_disclaimer./ > > > ------------------------------------------------------------------------ > *From:* payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] *On > Behalf Of *Robert Sparks > *Sent:* October-24-12 10:27 AM > *To:* payload@ietf.org > *Subject:* [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07 > > Forwarding this to the correct list. > > RjS > > > -------- Original Message -------- > Subject: AD Review: draft-ietf-avt-rtp-evrc-nw-07 > Date: Tue, 23 Oct 2012 15:15:16 -0500 > From: Robert Sparks > To: draft-ietf-avt-rtp-evrc-nw@tools.ietf.org, avt@ietf.org, > avtcore-chairs@ietf.org > CC: Gonzalo Camarillo > > > > Summary: The document should be revised before IETF LC. > > Primary Concern: > > - This document needs to point to RFC6562, at least in the security > considerations section and > possibly in section 11. I think the reference needs to be normative. > > Minor Concerns and Nits: > > - Section 8 refers backto a "mapping" in Section 4, but it's not clear > that there's a mapping there. > I suggest adding a note that ToC values are taken from the value column > in the table of section 4. > > - This sentence from Section 6.1 does not parse well: > The EVRC-NW interleaved/bundled format defines an encoding capability > identification flag, which is used to signal the far end of a > communication session of the instantaneous local EVRC-NW wideband/ > narrowband encoding capability. > Would this replacement work? > The EVRC-NW interleaved/bundled format defines an encoding capability > identification flag, which is used to signal the current local EVRC-NW > wideband/narrowband encoding capability to the far end of a > communication > session. > > - in Section 9.1.1: > When this media type is used in the context of transfer over RTP, the > RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be > used. In all other contexts, the file format defined in Section 8 > SHALL be used. See Section 6 for details for EVRC-NW. > It needs to be clearer that you are talking about Section 7 and 6 of > _this_ document. > I suggest saying "Section 8 of RFCXXXX" and "Section 6 of RFCXXXX" > and add a note > to the RFC Editor asking them to replace XXXX with the RFC number of > this document. > > - Section 5 paragraph 1: Suggest s/in a manner consistent with/as > specified in/ > > > --------------060408080101010901040909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
The important part is in the restructuring of the sentence.

That said, I don't agree that instantaneous is the appropriate word to use here, and it's usually a warning sign that the text needs clarification when arguing about choosing words that have similar meanings. (Exactly what instant is this instantaneous capability describing?)

So perhaps this instead:
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the local EVRC-NW
     wideband/narrowband encoding capability at the time of construction of an RTP packet
     to the far end of a communication session.

RjS

On 10/25/12 4:26 PM, Chung Cheung Chu wrote:
Hi Robert,
 
Regarding the comment below relating to a text from Ericsson, I agree that the proposed change does improve the readability of the sentence.  Thank you.  However, I notice that the word "current" has been suggested to replace "instantaneous". The word "Instantaneous" was chosen deliberately to reflect explicitly the dynamic nature of the encoding capability in a call session.  Unless there is a strong objection, I would counter-propose to keep the use of "instantaneous" instead of "current".

- This sentence from Section 6.1 does not parse well:
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the far end of a
     communication session of the instantaneous local EVRC-NW wideband/
     narrowband encoding capability.
  Would this replacement work?
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the current local EVRC-NW
     wideband/narrowband encoding capability to the far end of a
communication
     session.

Regards,

CC

Chung-Cheung Chu 
Ericsson

This Communication is Confidential.  We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer.

 

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Robert Sparks
Sent: October-24-12 10:27 AM
To: payload@ietf.org
Subject: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07

Forwarding this to the correct list.

RjS


-------- Original Message --------
Subject: AD Review: draft-ietf-avt-rtp-evrc-nw-07
Date: Tue, 23 Oct 2012 15:15:16 -0500
From: Robert Sparks <rjsparks@nostrum.com>
To: draft-ietf-avt-rtp-evrc-nw@tools.ietf.org, avt@ietf.org, avtcore-chairs@ietf.org
CC: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> 


Summary: The document should be revised before IETF LC.

Primary Concern:

- This document needs to point to RFC6562, at least in the security 
considerations section and
possibly in section 11. I think the reference needs to be normative.

Minor Concerns and Nits:

- Section 8 refers backto a "mapping" in Section 4, but it's not clear 
that there's a mapping there.
I suggest adding a note that ToC values are taken from the value column 
in the table of section 4.

- This sentence from Section 6.1 does not parse well:
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the far end of a
     communication session of the instantaneous local EVRC-NW wideband/
     narrowband encoding capability.
  Would this replacement work?
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the current local EVRC-NW
     wideband/narrowband encoding capability to the far end of a 
communication
     session.

- in Section 9.1.1:
     When this media type is used in the context of transfer over RTP, the
     RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be
     used.  In all other contexts, the file format defined in Section 8
     SHALL be used.  See Section 6 for details for EVRC-NW.
  It needs to be clearer that you are talking about Section 7 and 6 of 
_this_ document.
  I suggest saying "Section 8 of RFCXXXX" and "Section 6 of RFCXXXX" 
and add a note
  to the RFC Editor asking them to replace XXXX with the RFC number of 
this document.

- Section 5 paragraph 1: Suggest s/in a manner consistent with/as 
specified in/




--------------060408080101010901040909-- From chung.cheung.chu@ericsson.com Fri Oct 26 08:53:31 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E9321F8574 for ; Fri, 26 Oct 2012 08:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDCAbVx8I2N3 for ; Fri, 26 Oct 2012 08:53:28 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id F39BF21F85D5 for ; Fri, 26 Oct 2012 08:53:27 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q9QFuL2d006721; Fri, 26 Oct 2012 10:56:45 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.98]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 26 Oct 2012 11:53:10 -0400 From: Chung Cheung Chu To: Robert Sparks , "payload@ietf.org" Date: Fri, 26 Oct 2012 11:53:09 -0400 Thread-Topic: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07 Thread-Index: Ac2y+r86Ys6NQm7OTyyaasRoN7ulwQAltBqA Message-ID: <26490BBDEEACA14EA1A0070367B3ADBDC42E38C6F6@EUSAACMS0702.eamcs.ericsson.se> References: <5086FAD4.8070301@nostrum.com> <5087FABC.6010902@nostrum.com> <26490BBDEEACA14EA1A0070367B3ADBDC42E2FBFA7@EUSAACMS0702.eamcs.ericsson.se> <5089B412.9010505@nostrum.com> In-Reply-To: <5089B412.9010505@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_26490BBDEEACA14EA1A0070367B3ADBDC42E38C6F6EUSAACMS0702e_" MIME-Version: 1.0 Subject: Re: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 15:53:31 -0000 --_000_26490BBDEEACA14EA1A0070367B3ADBDC42E38C6F6EUSAACMS0702e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert, The suggested text is good. I am okay with it. Thank you. Regards, CC Chung-Cheung Chu ECN: 810-16713 External: +514-461-6713 or +514 345-7900 x46489 This Communication is Confidential. We only send and receive email on the = basis of the terms set out at www.ericsson.com/email_disclaimer. ________________________________ From: Robert Sparks [mailto:rjsparks@nostrum.com] Sent: October-25-12 5:50 PM To: Chung Cheung Chu Cc: payload@ietf.org; Fang, Zheng Subject: Re: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07 The important part is in the restructuring of the sentence. That said, I don't agree that instantaneous is the appropriate word to use = here, and it's usually a warning sign that the text needs clarification whe= n arguing about choosing words that have similar meanings. (Exactly what in= stant is this instantaneous capability describing?) So perhaps this instead: The EVRC-NW interleaved/bundled format defines an encoding capability identification flag, which is used to signal the local EVRC-NW wideband/narrowband encoding capability at the time of construction of= an RTP packet to the far end of a communication session. RjS On 10/25/12 4:26 PM, Chung Cheung Chu wrote: Hi Robert, Regarding the comment below relating to a text from Ericsson, I agree that = the proposed change does improve the readability of the sentence. Thank yo= u. However, I notice that the word "current" has been suggested to replace= "instantaneous". The word "Instantaneous" was chosen deliberately to refle= ct explicitly the dynamic nature of the encoding capability in a call sessi= on. Unless there is a strong objection, I would counter-propose to keep th= e use of "instantaneous" instead of "current". - This sentence from Section 6.1 does not parse well: The EVRC-NW interleaved/bundled format defines an encoding capability identification flag, which is used to signal the far end of a communication session of the instantaneous local EVRC-NW wideband/ narrowband encoding capability. Would this replacement work? The EVRC-NW interleaved/bundled format defines an encoding capability identification flag, which is used to signal the current local EVRC-NW wideband/narrowband encoding capability to the far end of a communication session. Regards, CC Chung-Cheung Chu Ericsson This Communication is Confidential. We only send and receive email on the = basis of the terms set out at www.ericsson.com/email_disclaimer. ________________________________ From: payload-bounces@ietf.org [mailto:pay= load-bounces@ietf.org] On Behalf Of Robert Sparks Sent: October-24-12 10:27 AM To: payload@ietf.org Subject: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07 Forwarding this to the correct list. RjS -------- Original Message -------- Subject: AD Review: draft-ietf-avt-rtp-evrc-nw-07 Date: Tue, 23 Oct 2012 15:15:16 -0500 From: Robert Sparks To: draft-ietf-avt-rtp-evrc-nw@tools.ietf.org, avt@ietf.org, avtcore-chairs= @ietf.org CC: Gonzalo Camarillo Summary: The document should be revised before IETF LC. Primary Concern: - This document needs to point to RFC6562, at least in the security considerations section and possibly in section 11. I think the reference needs to be normative. Minor Concerns and Nits: - Section 8 refers backto a "mapping" in Section 4, but it's not clear that there's a mapping there. I suggest adding a note that ToC values are taken from the value column in the table of section 4. - This sentence from Section 6.1 does not parse well: The EVRC-NW interleaved/bundled format defines an encoding capability identification flag, which is used to signal the far end of a communication session of the instantaneous local EVRC-NW wideband/ narrowband encoding capability. Would this replacement work? The EVRC-NW interleaved/bundled format defines an encoding capability identification flag, which is used to signal the current local EVRC-NW wideband/narrowband encoding capability to the far end of a communication session. - in Section 9.1.1: When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be used. In all other contexts, the file format defined in Section 8 SHALL be used. See Section 6 for details for EVRC-NW. It needs to be clearer that you are talking about Section 7 and 6 of _this_ document. I suggest saying "Section 8 of RFCXXXX" and "Section 6 of RFCXXXX" and add a note to the RFC Editor asking them to replace XXXX with the RFC number of this document. - Section 5 paragraph 1: Suggest s/in a manner consistent with/as specified in/ --_000_26490BBDEEACA14EA1A0070367B3ADBDC42E38C6F6EUSAACMS0702e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Robert,
 
The suggested text is good.  I am okay with i= t. =20 Thank you.

Regards,<= /FONT>=20

CC=

Chung-Che= ung=20 Chu
ECN:       810-16713=20
External= :=20 +514-461-6713   or   +514 345-7900 x46489=

This=20 Communication is Confidential.  We only send and receive email on the = basis=20 of the terms set out at www.ericsson.com/email_disclaimer.

 

From: Robert Sparks=20 [mailto:rjsparks@nostrum.com]
Sent: October-25-12 5:50=20 PM
To: Chung Cheung Chu
Cc: payload@ietf.org; Fang,=20 Zheng
Subject: Re: [payload] Fwd: AD Review:=20 draft-ietf-avt-rtp-evrc-nw-07

The important part is in the restructuring of = the=20 sentence.

That said, I don't agree that instantaneous is the appropr= iate=20 word to use here, and it's usually a warning sign that the text needs=20 clarification when arguing about choosing words that have similar meanings.= =20 (Exactly what instant is this instantaneous capability describing?)

= So=20 perhaps this instead:
     The EVRC-NW=20 interleaved/bundled format defines an encoding=20 capability
     identification flag, which is used t= o=20 signal the local EVRC-NW
     wideband/narrowband=20 encoding capability at the time of construction of an RTP=20 packet
     to the far end of a communication=20 session.

RjS

On 10/25/12 4:26 PM, Chung Cheung Chu=20 wrote:
<= SPAN=20 class=3D577241721-25102012>Hi Robert,
<= SPAN=20 class=3D577241721-25102012> 
Regarding=20 the comment below relating to a text from Ericsson, I agree that the prop= osed=20 change does improve the readability of the sentence.  Thank you.  However, I notice= that=20 the word "current" has been suggested to replace=20 "instantaneous". The word=20 "Instantaneous" was chosen deliberately to reflect explicitly the dy= namic=20 nature of the encoding capability in a call session.  Unless th= ere=20 is a strong objection, I would counter-propose to keep the use of=20 "instantaneous" instead of "current".

-=20 This sentence from Section 6.1 does not parse=20 well:
     The EVRC-NW interleaved/bundled format= =20 defines an encoding capability
     identification= =20 flag, which is used to signal the far end of a
    = ;=20 communication session of the instantaneous local EVRC-NW=20 wideband/
     narrowband encoding=20 capability.
  Would this replacement work?
   &= nbsp;=20 The EVRC-NW interleaved/bundled format defines an encoding=20 capability
     identification flag, which is used= to=20 signal the current local EVRC-NW
    =20 wideband/narrowband encoding capability to the far end of a=20
communication
     session.

<= /DIV>

Regards,

CC=20

Chung-C= heung=20 Chu 
Ericsson

This Communication is Confidential.  We onl= y send=20 and receive email on the basis of the terms set out at www.ericsson.com/email_= disclaimer.

 

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org<= /A>]=20 On Behalf Of Robert Sparks
Sent: October-24-12 10:27=20 AM
To: payload@ietf.org
Subject:= =20 [payload] Fwd: AD Review:=20 draft-ietf-avt-rtp-evrc-nw-07

Forwarding this to the= =20 correct list.

RjS


-------- Original Message ----= ----=20
Subject: AD Review: draft-ietf-avt-rtp-evrc-nw-07
Date: Tue, 23 Oct 2012 15:15:16 -0500
From: Robert Sparks <rjsparks@nostrum.com>
To: draft-ietf-avt-rtp-evrc-nw@tools.ietf.org<= /A>, avt@ietf.org, avtcore-chairs@ietf.org
CC: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>= 


Summary: The document should be revi=
sed before IETF LC.

Primary Concern:

- This document needs to point to RFC6562, at least in the security=20
considerations section and
possibly in section 11. I think the reference needs to be normative.

Minor Concerns and Nits:

- Section 8 refers backto a "mapping" in Section 4, but it's not clear=20
that there's a mapping there.
I suggest adding a note that ToC values are taken from the value column=20
in the table of section 4.

- This sentence from Section 6.1 does not parse well:
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the far end of a
     communication session of the instantaneous local EVRC-NW wideband/
     narrowband encoding capability.
  Would this replacement work?
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the current local EVRC-NW
     wideband/narrowband encoding capability to the far end of a=20
communication
     session.

- in Section 9.1.1:
     When this media type is used in the context of transfer over RTP, the
     RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be
     used.  In all other contexts, the file format defined in Section 8
     SHALL be used.  See Section 6 for details for EVRC-NW.
  It needs to be clearer that you are talking about Section 7 and 6 of=20
_this_ document.
  I suggest saying "Section 8 of RFCXXXX" and "Section 6 of RFCXXXX"=20
and add a note
  to the RFC Editor asking them to replace XXXX with the RFC number of=20
this document.

- Section 5 paragraph 1: Suggest s/in a manner consistent with/as=20
specified in/




--_000_26490BBDEEACA14EA1A0070367B3ADBDC42E38C6F6EUSAACMS0702e_-- From roni.even@mail01.huawei.com Wed Oct 31 23:16:08 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F2C21F8514; Wed, 31 Oct 2012 23:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.714 X-Spam-Level: X-Spam-Status: No, score=-0.714 tagged_above=-999 required=5 tests=[AWL=1.885, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2xBpFUDhKZ1; Wed, 31 Oct 2012 23:16:07 -0700 (PDT) Received: from hwsga02-in.huaweimarine.com (hwsga02-in.huaweimarine.com [119.145.15.224]) by ietfa.amsl.com (Postfix) with ESMTP id F2AC321F8512; Wed, 31 Oct 2012 23:16:06 -0700 (PDT) Received: from szxpml203-edg.exmail.huawei.com ([172.17.1.119]) by hwsga02-in.huaweimarine.com (MOS 4.1.3-GA) with ESMTP id ADY21888; Thu, 1 Nov 2012 14:15:57 +0800 X-Mirapoint-Received-SPF: 172.17.1.119 szxpml203-edg.exmail.huawei.com 5 none X-Mirapoint-Received-SPF: 172.17.1.119 szxpml203-edg.exmail.huawei.com 5 none Received: from SZXPML404-HUB.exmail.huawei.com (10.82.67.165) by szxpml203-edg.exmail.huawei.com (172.24.2.14) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 1 Nov 2012 14:15:51 +0800 Received: from SZXPML504-MBS.exmail.huawei.com ([169.254.4.23]) by szxpml404-hub.exmail.huawei.com ([10.82.67.165]) with mapi id 14.01.0323.003; Thu, 1 Nov 2012 14:15:57 +0800 From: Roni Even To: "avt@ietf.org" Thread-Topic: Help the NomCom: Community Feedback Thread-Index: AQHNt97j4JrgNy9bZEyKGtuNqTSwvZfUgOR/ Date: Thu, 1 Nov 2012 06:15:56 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C205B62262@szxpml504-mbs.exmail.huawei.com> References: <20121101031318.29487.88368.idtracker@ietfa.amsl.com> In-Reply-To: <20121101031318.29487.88368.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: [payload] FW: Help the NomCom: Community Feedback X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 06:16:08 -0000 fyi ________________________________________ From: wgchairs-bounces@ietf.org [wgchairs-bounces@ietf.org] on behalf of No= mCom Chair [nomcom-chair@ietf.org] Sent: Thursday, November 01, 2012 5:13 AM To: Working Group Chairs Subject: Help the NomCom: Community Feedback The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before Sunday, November 4. The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12@ietf.org. Additionally, the NomCom is happy to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair@ietf.org=