From nobody Mon Mar 5 14:56:37 2018 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D6D12711E; Mon, 5 Mar 2018 14:56:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: payload@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152029059049.12741.13074353861832773120@ietfa.amsl.com> Date: Mon, 05 Mar 2018 14:56:30 -0800 Archived-At: Subject: [payload] I-D Action: draft-ietf-payload-vp9-05.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 05 Mar 2018 22:56:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads WG of the IETF. Title : RTP Payload Format for VP9 Video Authors : Justin Uberti Stefan Holmer Magnus Flodman Jonathan Lennox Danny Hong Filename : draft-ietf-payload-vp9-05.txt Pages : 23 Date : 2018-03-05 Abstract: This memo describes an RTP payload format for the VP9 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. It includes provisions for temporal and spatial scalability. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-vp9/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-payload-vp9-05 https://datatracker.ietf.org/doc/html/draft-ietf-payload-vp9-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp9-05 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 Mar 5 15:05:49 2018 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 9B13A120227 for ; Mon, 5 Mar 2018 15:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=vidyo-com.20150623.gappssmtp.com 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 2yy3rJbG8moT for ; Mon, 5 Mar 2018 15:05:46 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 2A8C012711E for ; Mon, 5 Mar 2018 15:05:45 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id d26so22443017qtk.10 for ; Mon, 05 Mar 2018 15:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vidyo-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=dxSoV6eLaSj8lO768oXTVZ8TQmeqAG1c6d7op7VBPaU=; b=PDHAB0R3EgBIMkxzI3pLPmz6Z0fBWkduDsK7rBOma1mADEKAIaaIsK2V1OuP4BIOIX ho41u0H0cS0Nz/Yoe6AlmR0VE1A7wGSuN8PV8rvHulZPJkybNBwPqcJz9QOYY4frflEP UK3myEuQ/MznrgbEUm65M7F9wYeGRvuvrjiieP8hNwrcqm9Juzr2vOenIrIhTNEeteMg SmgBI1lQfIK5iqQOxi605vLZcwttf7NxQB9HopGJ8/J3zp+mjFSjlNDVvCGFooH07Sbu yV1+CSta8uLBfJFpJbs3p2wHVRjyLAaWUrp/CFcPBVYBk2QH5Cw6ol83L0843XHK6tcw zFMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=dxSoV6eLaSj8lO768oXTVZ8TQmeqAG1c6d7op7VBPaU=; b=Qfr+S4b7113v4FXqnmW9Ci6lYOXHvMJUrkQlPJc1iB7nfHCnsrrzzPEbJm4wyUoufS 5muw33pEZumQ9LDAnyavkqHpHehELn/gKblb4k0MhnLajVSY9pLirPC4INH5ABwFFzGv zRFIxo/dmatXiTe60Bi/vBAPjZ6ORccBnwgK6OVPetS1WZtCjSmPZK/+4CzeLpB4DxXn iAzVlG0O7OCKXyjOS6M2pjRsT/8StiEpnpgtwXHwZTrUCt5uiuNhLXCM3vR+w24dtptX p/c8+eFOGJcRz97AREFxXElSDf8KvTOiD2/CrmsEjQxk7qv3Tu/NZOGVS7GL8r1eN5gZ B8Eg== X-Gm-Message-State: AElRT7EZEHyKCNYrWgC98X2sJtIKXJRyjwNKBnmQSGSW9TIr8yPD4CTV LgzvVmTzkLkDfCvl6CsuP6HeiFahtxE= X-Google-Smtp-Source: AG47ELs2fa8KDmSqYmr+ma6OZ17jesTN5oowaJ/kiGCbf3Ox7gpjyr8aZsiw28WM3tReUDsPI/0JaQ== X-Received: by 10.200.39.217 with SMTP id x25mr24629791qtx.266.1520291143997; Mon, 05 Mar 2018 15:05:43 -0800 (PST) Received: from [172.16.2.142] ([160.79.219.114]) by smtp.gmail.com with ESMTPSA id j10sm9124808qtb.50.2018.03.05.15.05.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Mar 2018 15:05:43 -0800 (PST) From: Jonathan Lennox Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 5 Mar 2018 18:05:42 -0500 References: <152029059049.12741.13074353861832773120@ietfa.amsl.com> To: "payload@ietf.org" In-Reply-To: <152029059049.12741.13074353861832773120@ietfa.amsl.com> Message-Id: <09EBE34C-329A-4DB5-A85D-E5907968DFF8@vidyo.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [payload] I-D Action: draft-ietf-payload-vp9-05.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 05 Mar 2018 23:05:48 -0000 This version has some relatively minor changes following comments from = Tim Terriberry. Notably, this version defines how altrefs (frames/pictures with = show_frame=3D=3D0) are handled, and some requirements should be clearer. Comments are welcome. > On Mar 5, 2018, at 5:56 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Audio/Video Transport Payloads WG of = the IETF. >=20 > Title : RTP Payload Format for VP9 Video > Authors : Justin Uberti > Stefan Holmer > Magnus Flodman > Jonathan Lennox > Danny Hong > Filename : draft-ietf-payload-vp9-05.txt > Pages : 23 > Date : 2018-03-05 >=20 > Abstract: > This memo describes an RTP payload format for the VP9 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. It includes provisions for temporal and spatial > scalability. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-payload-vp9/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-payload-vp9-05 > https://datatracker.ietf.org/doc/html/draft-ietf-payload-vp9-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-vp9-05 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 From nobody Mon Mar 5 15:11:22 2018 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 79F0D126BFD; Mon, 5 Mar 2018 15:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 CtbggAeOR4le; Mon, 5 Mar 2018 15:11:20 -0800 (PST) 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 F187D120227; Mon, 5 Mar 2018 15:11:16 -0800 (PST) Received: from [10.0.1.10] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w25NBFtM054590 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 5 Mar 2018 17:11:16 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.10] From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_1BCFA395-CE95-4797-9E62-59AFEFD3AC83"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <91D7A133-DB5E-4CA7-A519-A46CA6A18EA8@nostrum.com> Date: Mon, 5 Mar 2018 17:11:14 -0600 To: draft-ietf-payload-rtp-vc2hq.all@ietf.org, payload@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [payload] AD Evaluation of draft-ietf-payload-rtp-vc2hq-04 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 05 Mar 2018 23:11:21 -0000 --Apple-Mail=_1BCFA395-CE95-4797-9E62-59AFEFD3AC83 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Here is my AD Evaluation of draft-ietf-payload-rtp-vc2hq-04. It=E2=80=99s = mostly in good shape, but I do have some comments and questions. I would = like to discuss at least my substantive comments before IETF LC. Thanks! Ben. *** Substantive Comments: =C2=A74.1: =E2=80=9C A Sequence Header packet SHOULD have the same = timestamp as the next picture which will follow it in the stream. An = End of Sequence packet SHOULD have the same timestamp as the previous = picture which appeared in the stream.=E2=80=9D Why are those SHOULDs not MUSTs? Do you envision circumstances where it = might be reasonable to violate them? What are the consequences if you = do? =C2=A74.2, definitions of I and F: Same question as for =C2=A74.1. - Slice Prefix Bytes and Slice Size Scaler: Both contain disclaimers = saying =E2=80=9Cunlikely to be too large.=E2=80=9D But IIUC, there are = normative requirements later in the draft that prevent them from ever = being to large. If my understanding is correct, it would be helpful to = clarify this here. (Otherwise reviewers may see =E2=80=9Cunlikely to be = =E2=80=9C as a red flag.) - This section is inconsistent about using normative keywords for field = contents. Most do, but starting with =E2=80=9CFragment Length=E2=80=9D = they are stated descriptively. For matters of definition, I am okay with = either approach but it would be good to be consistent. =C2=A74.4: "Every High Quality Picture Fragment MUST contain no more = than 65535 slices.=E2=80=9D This seems non-constraining giving the following requirement that it = must not contain over 65535 bytes. =C2=A75: =E2=80=9C The circuit breakers is to be implemented and = followed.=E2=80=9D Was there a reason not to use a MUST here? (also it seems like there=E2=80= =99s a missing word after =E2=80=9Cbreakers=E2=80=9D) - =E2=80=9C If used on a closed network which has been correctly = provisioned for the expected data rates then profile MAY be used without = congestion control, but on the open internet some sort of congestion = control approach MUST be taken.=E2=80=9D That sort of statement is dangerous; code that is intended for use in = private networks has a habit of escaping onto the internet. Is the code = supposed to know? Would it make sense to require implementations to = default to using congestion control unless explicitly configured = otherwise? *** Editorial Comments and Nits: =C2=A72: Please consider using the new boilerplate from RFC 8175. There = are a few lowercase instances of =E2=80=9Cshould=E2=80=9D and = =E2=80=9Cmust=E2=80=9D. At least some of the =E2=80=9Cshould=E2=80=9D = instances to not appear to be normative. =C2=A73: " Each High Quality Fragment data unit contains either a set of = parameters for a picture or a series of coded Slices. Does this mean =E2=80=9Cset of parameters for (a picture or a series of = coded slices), or (set of parameters for a picture) or (a series of = coded slices)? Also it would be good to clarify in =C2=A73 that only fragments are used = with this payload format. =C2=A74: Caption for figure 2: The text describes figure 2 as =E2=80=9C=E2= =80=A6 carries the Picture Fragment containing the VC-2 Transform = Parameters for a Picture. It would help to mention that (perhaps in a = shortened form) in the caption. =C2=A74.4: =E2=80=9C If a Sequence intended for tranmission does not = conform to these restrictions then it MAY be possible to simply convert = it=E2=80=A6" This seems like a statement of fact rather than a grant of permission. = As such, it should not use the 2119 keyword. --Apple-Mail=_1BCFA395-CE95-4797-9E62-59AFEFD3AC83 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlqdzpIACgkQgFZKbJXz 1A1yZw/+P7rNKa/af0YWVwMHHmSbxkFn0B+oq+RWhWaBrxVzBX4o5KTO/ETmbQ7C d+tMTQC/6wKnNRw9LoxM/QJq8lxzdXG+g/0upR/wxYwRjFHEVXP/P2Wa1s9nZWfX mvv+pYy5ul0ipKphTl5oZvt4CIKGdbojFekKVtgjFIWxax31l8j+sblzq7EIOXwN ZwCZ+qV4MHnEtDfCsJ8kOdKAqU1uJO11FEUFHsgSwahlcMn2+9vZhvRE86B7Rz2D C4vNgxQV9axVT9eIzTw4DqoYCSKlcEtrBT2JkEsYeXTJWKwlC0S7RYTLL8IyO5HV FhZ+j1/M4eV23rNAMvFZsQygqL2BFMRmI9OGcisP7iZLDCC67X+GyMnfcsWFhpBv Hj+D19Vxwbct6+An7eSMqv2wkdGEddRdlPnd+2ZW4jcpHhUUSz2kMbpkMV9GotnD uK0oIaLKTegcKv4isBtYekLv2o7z7vblSyr4067P8my4t0/Dj2wsA2Msk2OpTjm6 559rEDuazC0JY/fCNMvwjJmISuFFy+z2Bd0QqwipOqvuZxfvyHDjYK7fpeeVQVCZ 8RVfumes6BnGB0VJJZeAglJyP4e0C9YOyeHuZWUTy8oLmkjsfLvx9tfLpLwfD0Gr 2dblo+SDiC/Ms08eFG887KT9XPmlUbQvZBO+yMVn0Z3RZE5p2Kw= =itjG -----END PGP SIGNATURE----- --Apple-Mail=_1BCFA395-CE95-4797-9E62-59AFEFD3AC83-- From nobody Mon Mar 5 16:00:27 2018 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD9112EB65; Mon, 5 Mar 2018 16:00:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: payload@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152029441913.12703.13355590059495356037@ietfa.amsl.com> Date: Mon, 05 Mar 2018 16:00:19 -0800 Archived-At: Subject: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-06.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 06 Mar 2018 00:00:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads WG of the IETF. Title : RTP Payload Format for Flexible Forward Error Correction (FEC) Authors : Mo Zanaty Varun Singh Ali Begen Giridhar Mandyam Filename : draft-ietf-payload-flexible-fec-scheme-06.txt Pages : 38 Date : 2018-03-05 Abstract: This document defines new RTP payload formats for the Forward Error Correction (FEC) packets that are generated by the non-interleaved and interleaved parity codes from a source media encapsulated in RTP. These parity codes are systematic codes, where a number of FEC repair packets are generated from a set of source packets. These repair packets are sent in a redundancy RTP stream separate from the source RTP stream that carries the source packets. RTP source packets that were lost in transmission can be reconstructed using the source and repair packets that were received. The non-interleaved and interleaved parity codes which are defined in this specification offer a good protection against random and bursty packet losses, respectively, at a cost of decent complexity. The RTP payload formats that are defined in this document address the scalability issues experienced with the earlier specifications including RFC 2733, RFC 5109 and SMPTE 2022-1, and offer several improvements. Due to these changes, the new payload formats are not backward compatible with the earlier specifications, but endpoints that do not implement this specification can still work by simply ignoring the FEC repair packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-06 https://datatracker.ietf.org/doc/html/draft-ietf-payload-flexible-fec-scheme-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-flexible-fec-scheme-06 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 Mar 5 23:16:32 2018 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 C1333126CF6; Mon, 5 Mar 2018 23:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.063 X-Spam-Level: X-Spam-Status: No, score=-3.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 J4tVbfe36jWw; Mon, 5 Mar 2018 23:16:28 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 7D7BF124217; Mon, 5 Mar 2018 23:16:28 -0800 (PST) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id BD04B125F818E; Tue, 6 Mar 2018 07:16:24 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 6 Mar 2018 07:16:26 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0361.001; Tue, 6 Mar 2018 15:16:12 +0800 From: "Roni Even (A)" To: "payload@ietf.org" CC: "payload-chairs@ietf.org" Thread-Topic: Payload agenda for IETF 101 Thread-Index: AdO1GjvKPSglRKTARoaUxWJIYYmC4g== Date: Tue, 6 Mar 2018 07:16:11 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD86A7EC@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.71] Content-Type: multipart/mixed; boundary="_005_6E58094ECC8D8344914996DAD28F1CCD86A7ECDGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [payload] Payload agenda for IETF 101 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 06 Mar 2018 07:16:31 -0000 --_005_6E58094ECC8D8344914996DAD28F1CCD86A7ECDGGEMM506MBXchina_ Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD86A7ECDGGEMM506MBXchina_" --_000_6E58094ECC8D8344914996DAD28F1CCD86A7ECDGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Attached is the draft agenda for the IETF meeting in London. We have two individual RTP payload drafts that we would like to adopt they = are: https://tools.ietf.org/id/draft-df-stecker-expertenforum-payload-tetra-00.t= xt https://tools.ietf.org/id/draft-demjanenko-payload-tsvcis-00.txt There is new version of the flexible FEC addressing comments from WGLC (we = will have a second one) https://tools.ietf.org/id/draft-ietf-payload-flexible-fec-scheme-06.txt There is also a new version of the VP9 RTP payload https://tools.ietf.org/id/draft-ietf-payload-vp9-05.txt Please review the documents before the meeting Thanks Roni Even Payload WG co-chair --_000_6E58094ECC8D8344914996DAD28F1CCD86A7ECDGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Attached is the draft agenda for the IETF meeting in= London.

 

We have two individual RTP payload drafts that we wo= uld like to adopt they are:

 

https://tools.ietf.org/id/draft-df-st= ecker-expertenforum-payload-tetra-00.txt

 

https://tools.ietf.org/id/draft-demjanenko-payload= -tsvcis-00.txt

 

 

There is new version of the flexible FEC addressing = comments from WGLC (we will have a second one)

https://tools.ietf.org/id/draft-ietf-payloa= d-flexible-fec-scheme-06.txt

 

There is also a new version of the VP9 RTP payload

 

https://tools.ietf.org/id/draft-ietf-payload-vp9-05.txt=

 

 

Please review the documents before the meeting<= /o:p>

 

Thanks

Roni Even Payload WG co-chair

--_000_6E58094ECC8D8344914996DAD28F1CCD86A7ECDGGEMM506MBXchina_-- --_005_6E58094ECC8D8344914996DAD28F1CCD86A7ECDGGEMM506MBXchina_ Content-Type: text/plain; name="p1803.txt" Content-Description: p1803.txt Content-Disposition: attachment; filename="p1803.txt"; size=844; creation-date="Tue, 06 Mar 2018 06:38:35 GMT"; modification-date="Tue, 06 Mar 2018 06:39:23 GMT" Content-Transfer-Encoding: base64 QXVkaW8vVmlkZW8gVHJhbnNwb3J0IFBheW9hZHMgIChQYXlsb2FkKSBXb3JraW5nIEdyb3VwDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0K Q0hBSVJTOiAgQWxpIEJlZ2VuICAgICAgIDxhbGkuYmVnZW5AbmV0d29ya2VkLm1lZGlhPg0KICAg ICAgICAgUm9uaSBFdmVuICAgICAgICAgPHJvbmkuZXZlbkBodWF3ZWkuY29tPg0KDQpBR0VOREEN Cg0KVGh1cnNkYXksIDIyIE1hcmNoIDIwMTggYXQgMTQ6MTUtMTU6MDAgKFp1cmljaCBBKQ0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KMTQ6MTUgICBQ YXlsb2FkIFdHIHN0YXR1cyB1cGRhdGUgICAgICAgICAgICAgICAgICAgICAgICAgICAgKENoYWly cywgMTApDQogICAgICAgIHJldmlldyBkcmFmdC1kZi1zdGVja2VyLWV4cGVydGVuZm9ydW0tcGF5 bG9hZC10ZXRyYS0wMA0KDQoxNDoyNSAgIFJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgRmxleGlibGUg RkVDICAgICAgICAgICAgICAoTW8gWmFuYXR5LCAxNSkNCiAgICAgICAgZHJhZnQtaWV0Zi1wYXls b2FkLWZsZXhpYmxlLWZlYy1zY2hlbWUtMDYNCg0KMTQ6NDAgICBSVFAgUGF5bG9hZCBGb3JtYXQg Zm9yIFZQOSBWaWRlbyAgICAgICAgICAgKEpvbmF0aGFuIExlbm5veCwgMTApDQogICAgICAgIGRy YWZ0LWlldGYtcGF5bG9hZC12cDktMDUNCg0KMTQ6NTAgICBSVFAgUGF5bG9hZCBGb3JtYXQgZm9y IFRTVkNJUyBDb2RlYyAgICAgICAoVmljdG9yIERlbWphbmVua28sIDUpDQogICAgICAgIGRyYWZ0 LWRlbWphbmVua28tcGF5bG9hZC10c3ZjaXMtMDANCg0KMTQ6NTUgICBFbmQNCg== --_005_6E58094ECC8D8344914996DAD28F1CCD86A7ECDGGEMM506MBXchina_ Content-Type: text/html; name="p1803.html" Content-Description: p1803.html Content-Disposition: attachment; filename="p1803.html"; size=1559; creation-date="Tue, 06 Mar 2018 06:38:35 GMT"; modification-date="Tue, 06 Mar 2018 06:42:31 GMT" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5BdWRpby9WaWRlbyBUcmFuc3BvcnQgUGF5b2FkcyAgKFBh eWxvYWQpIFdvcmtpbmcgR3JvdXAgQWdlbmRhPC90aXRsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29s b3I9IiNmZmZmZmYiPjxoMT5BdWRpby9WaWRlbyBUcmFuc3BvcnQgUGF5b2FkcyAgKFBheWxvYWQp IFdvcmtpbmcgR3JvdXAgQWdlbmRhPC9oMT4NCjxocj4NCjxwPg0KPGgzPg0KQ2hhaXJzOiBBbGkg QmVnZW4gICAgICAgPGFsaS5iZWdlbkBuZXR3b3JrZWQubWVkaWE+LCBSb25pIEV2ZW4gICAgICAg ICA8cm9uaS5ldmVuQGh1YXdlaS5jb20+DQo8L2gzPg0KPHA+DQo8aDI+VGh1cnNkYXksIDIyIE1h cmNoIDIwMTggYXQgMTQ6MTUtMTU6MDAgKFp1cmljaCBBKTwvaDI+DQo8cD4NCjx0YWJsZSBib3Jk ZXI9IjAiIGNlbGxwYWRkaW5nPSI1Ij4NCjx0cj4NCjx0aCBhbGlnbj0ibGVmdCI+MTQ6MTUNCjx0 aCBhbGlnbj0ibGVmdCI+UGF5bG9hZCBXRyBzdGF0dXMgdXBkYXRlPHRoIGFsaWduPSJsZWZ0Ij5D aGFpcnMNCjx0cj4NCjx0ZCBhbGlnbj0ibGVmdCI+DQo8dGQgYWxpZ249ImxlZnQiPlJldmlldyA8 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtZGYtc3RlY2tlci1leHBlcnRl bmZvcnVtLXBheWxvYWQtdGV0cmEtMDAiPiBkcmFmdC1kZi1zdGVja2VyLWV4cGVydGVuZm9ydW0t cGF5bG9hZC10ZXRyYS0wMDwvYT4NCjx0cj4NCjx0aCBhbGlnbj0ibGVmdCI+MTQ6MjUNCjx0aCBh bGlnbj0ibGVmdCI+UlRQIFBheWxvYWQgRm9ybWF0IGZvciBGbGV4aWJsZSBGRUM8dGggYWxpZ249 ImxlZnQiPk1vIFphbmF0eQ0KPHRyPg0KPHRkIGFsaWduPSJsZWZ0Ij4NCjx0ZCBhbGlnbj0ibGVm dCI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlldGYtcGF5bG9hZC1m bGV4aWJsZS1mZWMtc2NoZW1lLTA2Ij5kcmFmdC1pZXRmLXBheWxvYWQtZmxleGlibGUtZmVjLXNj aGVtZS0wNjwvYT4NCjx0cj4NCjx0aCBhbGlnbj0ibGVmdCI+MTQ6NDANCjx0aCBhbGlnbj0ibGVm dCI+UlRQIFBheWxvYWQgRm9ybWF0IGZvciBWUDkgVmlkZW88dGggYWxpZ249ImxlZnQiPkpvbmF0 aGFuIExlbm5veA0KPHRyPg0KPHRkIGFsaWduPSJsZWZ0Ij4NCjx0ZCBhbGlnbj0ibGVmdCI+PGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlldGYtcGF5bG9hZC12cDktMDUi PmRyYWZ0LWlldGYtcGF5bG9hZC12cDktMDU8L2E+DQo8dHI+DQo8dGggYWxpZ249ImxlZnQiPjE0 OjUwDQo8dGggYWxpZ249ImxlZnQiPlJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgVFNWQ0lTIENvZGVj PHRoIGFsaWduPSJsZWZ0Ij5WaWN0b3IgRGVtamFuZW5rbw0KPHRyPg0KPHRkIGFsaWduPSJsZWZ0 Ij4NCjx0ZCBhbGlnbj0ibGVmdCI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2Ry YWZ0LWRlbWphbmVua28tcGF5bG9hZC10c3ZjaXMtMDAiPmRyYWZ0LWRlbWphbmVua28tcGF5bG9h ZC10c3ZjaXMtMDA8L2E+DQo8dHI+DQo8dGggYWxpZ249ImxlZnQiPjE0OjU1DQo8dGggYWxpZ249 ImxlZnQiPkVuZDwvdGFibGU+DQo= --_005_6E58094ECC8D8344914996DAD28F1CCD86A7ECDGGEMM506MBXchina_-- From nobody Mon Mar 5 23:49:51 2018 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 E9E3C120724; Mon, 5 Mar 2018 23:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.063 X-Spam-Level: X-Spam-Status: No, score=-3.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 qnubtgh6ARed; Mon, 5 Mar 2018 23:49:44 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 DC02E124239; Mon, 5 Mar 2018 23:49:43 -0800 (PST) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 31D21FFD14C20; Tue, 6 Mar 2018 07:49:40 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 6 Mar 2018 07:49:42 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0361.001; Tue, 6 Mar 2018 15:49:25 +0800 From: "Roni Even (A)" To: "Roni Even (A)" , "payload@ietf.org" CC: "payload-chairs@ietf.org" Thread-Topic: Payload agenda for IETF 101 -update Thread-Index: AdO1H5yIbMX9/8A1TDavylEu4jRBzA== Date: Tue, 6 Mar 2018 07:49:25 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD86A834@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.71] Content-Type: multipart/mixed; boundary="_005_6E58094ECC8D8344914996DAD28F1CCD86A834DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [payload] Payload agenda for IETF 101 -update X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 06 Mar 2018 07:49:46 -0000 --_005_6E58094ECC8D8344914996DAD28F1CCD86A834DGGEMM506MBXchina_ Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD86A834DGGEMM506MBXchina_" --_000_6E58094ECC8D8344914996DAD28F1CCD86A834DGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Small update on the agenda From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even (A) Sent: Tuesday, March 06, 2018 9:16 AM To: payload@ietf.org Cc: payload-chairs@ietf.org Subject: [payload] Payload agenda for IETF 101 Hi, Attached is the draft agenda for the IETF meeting in London. We have two individual RTP payload drafts that we would like to adopt they = are: https://tools.ietf.org/id/draft-df-stecker-expertenforum-payload-tetra-00.t= xt https://tools.ietf.org/id/draft-demjanenko-payload-tsvcis-00.txt There is new version of the flexible FEC addressing comments from WGLC (we = will have a second one) https://tools.ietf.org/id/draft-ietf-payload-flexible-fec-scheme-06.txt There is also a new version of the VP9 RTP payload https://tools.ietf.org/id/draft-ietf-payload-vp9-05.txt Please review the documents before the meeting Thanks Roni Even Payload WG co-chair --_000_6E58094ECC8D8344914996DAD28F1CCD86A834DGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Small update on the ag= enda

 

From: payload = [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even (A)
Sent: Tuesday, March 06, 2018 9:16 AM
To: payload@ietf.org
Cc: payload-chairs@ietf.org
Subject: [payload] Payload agenda for IETF 101

 

Hi,

Attached is the draft agenda for the IETF meeting in= London.

 

We have two individual RTP payload drafts that we wo= uld like to adopt they are:

 

https://tools.ietf.org/id/draft-df-st= ecker-expertenforum-payload-tetra-00.txt

 

https://tools.ietf.org/id/draft-demjanenko-payload= -tsvcis-00.txt

 

 

There is new version of the flexible FEC addressing = comments from WGLC (we will have a second one)

https://tools.ietf.org/id/draft-ietf-payloa= d-flexible-fec-scheme-06.txt

 

There is also a new version of the VP9 RTP payload

 

https://tools.ietf.org/id/draft-ietf-payload-vp9-05.txt=

 

 

Please review the documents before the meeting<= /o:p>

 

Thanks

Roni Even Payload WG co-chair

--_000_6E58094ECC8D8344914996DAD28F1CCD86A834DGGEMM506MBXchina_-- --_005_6E58094ECC8D8344914996DAD28F1CCD86A834DGGEMM506MBXchina_ Content-Type: text/plain; name="p1803f.txt" Content-Description: p1803f.txt Content-Disposition: attachment; filename="p1803f.txt"; size=917; creation-date="Tue, 06 Mar 2018 06:33:57 GMT"; modification-date="Tue, 06 Mar 2018 06:33:57 GMT" Content-Transfer-Encoding: base64 QXVkaW8vVmlkZW8gVHJhbnNwb3J0IFBheW9hZHMgIChQYXlsb2FkKSBXb3JraW5nIEdyb3VwDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0K Q0hBSVJTOiAgQWxpIEJlZ2VuICAgICAgIDxhbGkuYmVnZW5AbmV0d29ya2VkLm1lZGlhPg0KICAg ICAgICAgUm9uaSBFdmVuICAgICAgICAgPHJvbmkuZXZlbkBodWF3ZWkuY29tPg0KDQpBR0VOREEN Cg0KVGh1cnNkYXksIDIyIE1hcmNoIDIwMTggYXQgMTQ6MTUtMTU6MDAgKFp1cmljaCBBKQ0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KMTQ6MTUgICBQ YXlsb2FkIFdHIHN0YXR1cyB1cGRhdGUgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChDaGFp cnMsIDUpDQoNCjE0OjIwICAgUlRQIFBheWxvYWQgRm9ybWF0IGZvciBGbGV4aWJsZSBGRUMgICAg ICAgICAgICAgIChNbyBaYW5hdHksIDE1KQ0KICAgICAgICBkcmFmdC1pZXRmLXBheWxvYWQtZmxl eGlibGUtZmVjLXNjaGVtZS0wNg0KDQoxNDozNSAgIFJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgVlA5 IFZpZGVvICAgICAgICAgICAoSm9uYXRoYW4gTGVubm94LCAxMCkNCiAgICAgICAgZHJhZnQtaWV0 Zi1wYXlsb2FkLXZwOS0wNQ0KDQoxNDo0NSAgIFJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgVFNWQ0lT IENvZGVjICAgICAgIChWaWN0b3IgRGVtamFuZW5rbywgNSkNCiAgICAgICAgZHJhZnQtZGVtamFu ZW5rby1wYXlsb2FkLXRzdmNpcy0wMA0KDQoxNDo1MCAgIFJUUCBQYXlsb2FkIEZvcm1hdCBmb3Ig dGhlIFRFVFJBIEF1ZGlvIENvZGVjKEFuZHJlYXMgUmVpc2VuYmF1ZXIsIDUpDQogICAgICAgIGRy YWZ0LWRmLXN0ZWNrZXItZXhwZXJ0ZW5mb3J1bS1wYXlsb2FkLXRldHJhLTAwDQoNCjE0OjU1ICAg RW5kDQo= --_005_6E58094ECC8D8344914996DAD28F1CCD86A834DGGEMM506MBXchina_ Content-Type: text/html; name="p1803f.html" Content-Description: p1803f.html Content-Disposition: attachment; filename="p1803f.html"; size=1680; creation-date="Tue, 06 Mar 2018 06:33:57 GMT"; modification-date="Tue, 06 Mar 2018 06:33:57 GMT" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5BdWRpby9WaWRlbyBUcmFuc3BvcnQgUGF5b2FkcyAgKFBh eWxvYWQpIFdvcmtpbmcgR3JvdXAgQWdlbmRhPC90aXRsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29s b3I9IiNmZmZmZmYiPjxoMT5BdWRpby9WaWRlbyBUcmFuc3BvcnQgUGF5b2FkcyAgKFBheWxvYWQp IFdvcmtpbmcgR3JvdXAgQWdlbmRhPC9oMT4NCjxocj4NCjxwPg0KPGgzPg0KQ2hhaXJzOiBBbGkg QmVnZW4gICAgICAgPGFsaS5iZWdlbkBuZXR3b3JrZWQubWVkaWE+LCBSb25pIEV2ZW4gICAgICAg ICA8cm9uaS5ldmVuQGh1YXdlaS5jb20+DQo8L2gzPg0KPHA+DQo8aDI+VGh1cnNkYXksIDIyIE1h cmNoIDIwMTggYXQgMTQ6MTUtMTU6MDAgKFp1cmljaCBBKTwvaDI+DQo8cD4NCjx0YWJsZSBib3Jk ZXI9IjAiIGNlbGxwYWRkaW5nPSI1Ij4NCjx0cj4NCjx0aCBhbGlnbj0ibGVmdCI+MTQ6MTUNCjx0 aCBhbGlnbj0ibGVmdCI+UGF5bG9hZCBXRyBzdGF0dXMgdXBkYXRlPHRoIGFsaWduPSJsZWZ0Ij5D aGFpcnMNCjx0cj4NCjx0aCBhbGlnbj0ibGVmdCI+MTQ6MjANCjx0aCBhbGlnbj0ibGVmdCI+UlRQ IFBheWxvYWQgRm9ybWF0IGZvciBGbGV4aWJsZSBGRUM8dGggYWxpZ249ImxlZnQiPk1vIFphbmF0 eQ0KPHRyPg0KPHRkIGFsaWduPSJsZWZ0Ij4NCjx0ZCBhbGlnbj0ibGVmdCI+PGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlldGYtcGF5bG9hZC1mbGV4aWJsZS1mZWMtc2No ZW1lLTA2Ij5kcmFmdC1pZXRmLXBheWxvYWQtZmxleGlibGUtZmVjLXNjaGVtZS0wNjwvYT4NCjx0 cj4NCjx0aCBhbGlnbj0ibGVmdCI+MTQ6MzUNCjx0aCBhbGlnbj0ibGVmdCI+UlRQIFBheWxvYWQg Rm9ybWF0IGZvciBWUDkgVmlkZW88dGggYWxpZ249ImxlZnQiPkpvbmF0aGFuIExlbm5veA0KPHRy Pg0KPHRkIGFsaWduPSJsZWZ0Ij4NCjx0ZCBhbGlnbj0ibGVmdCI+PGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2lkL2RyYWZ0LWlldGYtcGF5bG9hZC12cDktMDUiPmRyYWZ0LWlldGYtcGF5 bG9hZC12cDktMDU8L2E+DQo8dHI+DQo8dGggYWxpZ249ImxlZnQiPjE0OjQ1DQo8dGggYWxpZ249 ImxlZnQiPlJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgVFNWQ0lTIENvZGVjPHRoIGFsaWduPSJsZWZ0 Ij5WaWN0b3IgRGVtamFuZW5rbw0KPHRyPg0KPHRkIGFsaWduPSJsZWZ0Ij4NCjx0ZCBhbGlnbj0i bGVmdCI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWRlbWphbmVua28t cGF5bG9hZC10c3ZjaXMtMDAiPmRyYWZ0LWRlbWphbmVua28tcGF5bG9hZC10c3ZjaXMtMDA8L2E+ DQo8dHI+DQo8dGggYWxpZ249ImxlZnQiPjE0OjUwDQo8dGggYWxpZ249ImxlZnQiPlJUUCBQYXls b2FkIEZvcm1hdCBmb3IgdGhlIFRFVFJBIEF1ZGlvIENvZGVjPHRoIGFsaWduPSJsZWZ0Ij5BbmRy ZWFzIFJlaXNlbmJhdWVyDQo8dHI+DQo8dGQgYWxpZ249ImxlZnQiPg0KPHRkIGFsaWduPSJsZWZ0 Ij48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtZGYtc3RlY2tlci1leHBl cnRlbmZvcnVtLXBheWxvYWQtdGV0cmEtMDAiPmRyYWZ0LWRmLXN0ZWNrZXItZXhwZXJ0ZW5mb3J1 bS1wYXlsb2FkLXRldHJhLTAwPC9hPg0KPHRyPg0KPHRoIGFsaWduPSJsZWZ0Ij4xNDo1NQ0KPHRo IGFsaWduPSJsZWZ0Ij5FbmQ8L3RhYmxlPg0K --_005_6E58094ECC8D8344914996DAD28F1CCD86A834DGGEMM506MBXchina_-- From nobody Wed Mar 7 03:00:56 2018 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 35B17126CE8; Wed, 7 Mar 2018 03:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 FwLJXqoPCwVt; Wed, 7 Mar 2018 03:00:52 -0800 (PST) Received: from mailout0.cwwtf.bbc.co.uk (mailout0.cwwtf.bbc.co.uk [132.185.160.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B416D129C6C; Wed, 7 Mar 2018 03:00:51 -0800 (PST) Received: from BGB01XI1003.national.core.bbc.co.uk ([10.184.50.53]) by mailout0.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w27B0nZG024472; Wed, 7 Mar 2018 11:00:49 GMT Received: from BGB01XUD1007.national.core.bbc.co.uk ([10.161.14.5]) by BGB01XI1003.national.core.bbc.co.uk ([10.184.50.53]) with mapi id 14.03.0361.001; Wed, 7 Mar 2018 11:00:43 +0000 From: James Barrett To: Ben Campbell CC: "draft-ietf-payload-rtp-vc2hq.all@ietf.org" , "payload@ietf.org" Thread-Index: AQHTtNdIj7NgDEP+KEGUCPjh/Dwjm6PEnV4A Date: Wed, 7 Mar 2018 11:00:42 +0000 Message-ID: <48814733-6800-4BAD-9AA8-0AF67A28B550@bbc.co.uk> References: <91D7A133-DB5E-4CA7-A519-A46CA6A18EA8@nostrum.com> In-Reply-To: <91D7A133-DB5E-4CA7-A519-A46CA6A18EA8@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes x-originating-ip: [10.10.48.249] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23704.006 x-tm-as-result: No--22.806200-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_3b0650fb-9321-49e7-8bec-8775642a98f0_" X-EXCLAIMER-MD-CONFIG: 1cd3ac1c-62e5-43f2-8404-6b688271c769 Archived-At: Subject: Re: [payload] AD Evaluation of draft-ietf-payload-rtp-vc2hq-04 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 07 Mar 2018 11:00:54 -0000 --_3b0650fb-9321-49e7-8bec-8775642a98f0_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BFOn 5 Mar 2018, at 23:11, Ben Campbell wrote: >=20 > Hi, >=20 > Here is my AD Evaluation of draft-ietf-payload-rtp-vc2hq-04. It???s mostl= y in good shape, but I do have some comments and questions. I would like to= discuss at least my substantive comments before IETF LC. >=20 > Thanks! >=20 > Ben. >=20 > *** Substantive Comments: >=20 > ??4.1: ??? A Sequence Header packet SHOULD have the same timestamp as the= next picture which will follow it in the stream. An End of Sequence packe= t SHOULD have the same timestamp as the previous picture which appeared in = the stream.??? >=20 > Why are those SHOULDs not MUSTs? Do you envision circumstances where it m= ight be reasonable to violate them? What are the consequences if you do? I honestly can???t think of any real consequences for violating this, but s= ince these packets need to have some value for timestamp it seemed reasonab= le to make a recommendation. > ??4.2, definitions of I and F: Same question as for ??4.1. Yes, these should probably be MUST. > - Slice Prefix Bytes and Slice Size Scaler: Both contain disclaimers sayi= ng ???unlikely to be too large.??? But IIUC, there are normative requiremen= ts later in the draft that prevent them from ever being to large. If my und= erstanding is correct, it would be helpful to clarify this here. (Otherwise= reviewers may see ???unlikely to be ??? as a red flag.) Ok, I???ll clarify that. > - This section is inconsistent about using normative keywords for field c= ontents. Most do, but starting with ???Fragment Length??? they are stated d= escriptively. For matters of definition, I am okay with either approach but= it would be good to be consistent. Ok, I???ll fix them all to use normative keywords. > ??4.4: "Every High Quality Picture Fragment MUST contain no more than 655= 35 slices.??? >=20 > This seems non-constraining giving the following requirement that it must= not contain over 65535 bytes. Fair point. Maybe I should just list the bytes limit and then add the expla= nation ???and hence cannot contain over 65535 slices either???. > ??5: ??? The circuit breakers is to be implemented and followed.??? > Was there a reason not to use a MUST here? (also it seems like there???s = a missing word after ???breakers???) Yeah, that seems wrong.=20 > - ??? If used on a closed network which has been correctly provisioned fo= r the expected data rates then profile MAY be used without congestion contr= ol, but on the open internet some sort of congestion control approach MUST = be taken.??? >=20 > That sort of statement is dangerous; code that is intended for use in pri= vate networks has a habit of escaping onto the internet. Is the code suppos= ed to know? Would it make sense to require implementations to default to u= sing congestion control unless explicitly configured otherwise? How about a change to the same sort of wording used in RFC 8130? "Since UDP does not provide congestion control, applications that use RTP over UDP SHOULD implement their own congestion control above the UDP layer [RFC8085] and MAY also implement a transport circuit breaker [RFC8083]. Work in the RMCAT working group [RMCAT] describes the interactions and conceptual interfaces necessary between the application components that relate to congestion control, including the RTP layer, the higher-level media codec control layer, and the lower-level transport interface, as well as components dedicated to congestion control functions." > *** Editorial Comments and Nits: >=20 > ??2: Please consider using the new boilerplate from RFC 8175. There are a= few lowercase instances of ???should??? and ???must???. At least some of t= he ???should??? instances to not appear to be normative Do you mean 8174? If so then yes, that makes sense. > ??3: " Each High Quality Fragment data unit contains either a set of para= meters for a picture or a series of coded Slices. >=20 > Does this mean ???set of parameters for (a picture or a series of coded s= lices), or (set of parameters for a picture) or (a series of coded slices)? >=20 > Also it would be good to clarify in ??3 that only fragments are used with= this payload format. It means the latter. Yes I will reword to be clearer. > ??4: Caption for figure 2: The text describes figure 2 as ?????? carries = the Picture Fragment containing the VC-2 Transform Parameters for a Picture= . It would help to mention that (perhaps in a shortened form) in the captio= n. ok. > ??4.4: ??? If a Sequence intended for tranmission does not conform to the= se restrictions then it MAY be possible to simply convert it???" >=20 > This seems like a statement of fact rather than a grant of permission. As= such, it should not use the 2119 keyword. Yes, how about: ???Informative note: Some streams which do not meet these restrictions can = be converted into streams which do without the need to reencode the encoded= data simply by adjusting the distribution of slices into fragments, others= cannot.??? Should I submit a revised draft with the above changes made? -- James P. Weaver (n?? Barrett) Research Engineer BBC R&D North Lab, Floor 5 Dock House, MediaCity, M50 2LH Tel: +44(0)30 3040-9521 e-mail: james.barrett@bbc.co.uk ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and=20 may contain personal views which are not the views of the BBC unless specif= ically stated. If you have received it in=20 error, please delete it from your system. Do not use, copy or disclose the=20 information in any way nor act in reliance on it and notify the sender=20 immediately. Please note that the BBC monitors e-mails=20 sent or received. Further communication will signify your consent to=20 this. -----------------------------= --_3b0650fb-9321-49e7-8bec-8775642a98f0_ Content-Type: message/rfc822 Received: from BGB01XUD1007.national.core.bbc.co.uk ([10.161.14.5]) by BGB01XI1003.national.core.bbc.co.uk ([10.184.50.53]) with mapi id 14.03.0361.001; Wed, 7 Mar 2018 11:00:43 +0000 From: James Barrett To: Ben Campbell CC: "draft-ietf-payload-rtp-vc2hq.all@ietf.org" , "payload@ietf.org" Subject: Re: AD Evaluation of draft-ietf-payload-rtp-vc2hq-04 Thread-Index: AQHTtNdIj7NgDEP+KEGUCPjh/Dwjm6PEnV4A Date: Wed, 7 Mar 2018 11:00:42 +0000 Message-ID: <48814733-6800-4BAD-9AA8-0AF67A28B550@bbc.co.uk> References: <91D7A133-DB5E-4CA7-A519-A46CA6A18EA8@nostrum.com> In-Reply-To: <91D7A133-DB5E-4CA7-A519-A46CA6A18EA8@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 04 X-MS-Exchange-Organization-AuthSource: BGB01XI1003.national.core.bbc.co.uk X-MS-Has-Attach: yes X-MS-Exchange-Organization-SCL: -1 X-MS-Exchange-Organization-AVStamp-Mailbox: SMEXzs^g;1411500;0;This mail has been scanned by Trend Micro ScanMail for Microsoft Exchange; X-MS-TNEF-Correlator: x-ms-exchange-organization-originalsize: 28496 x-ms-exchange-organization-originalarrivaltime: 07 Mar 2018 11:00:42.6476 (UTC) x-ms-exchange-organization-messagesource: StoreDriver x-ms-exchange-organization-messagedirectionality: Originating x-ms-exchange-forest-messagescope: 00000000-0000-0000-0000-000000000000 x-ms-exchange-organization-messagescope: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Organization-BCC: x-ms-exchange-organization-transport-properties: DeliveryPriority=Normal x-ms-exchange-organization-originalclientipaddress: 10.10.48.249 x-originating-ip: [10.10.48.249] x-ms-exchange-organization-originalserveripaddress: 10.184.50.52 x-ms-exchange-organization-messagelatency: SRV=BGB01XUD1007.national.core.bbc.co.uk:TOTAL=0 x-ms-exchange-organization-hygienepolicy: Standard x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-ms-exchange-organization-recipient-limit-verified: True x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23704.006 x-tm-as-result: No--22.806200-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No x-ms-exchange-forest-rulesexecuted: BGB01XI1003 x-ms-exchange-organization-rules-execution-history: Marianne Proudfoot mail storm%%%Infosec Redirection BBCIS-17-0083%%%Infosec Redirection Request - Investigation%%%mightydeals mail loop%%%InfoSec Redirect_SOC18-123%%%Infosec Redirection request%%%Infosec Redirection Request - FOR37%%%Infosec Redirection Request - FOR-24%%%midlandstoday Email loop%%%Infosec Redirection FOR-97 @ziggo.nl%%%Infosec Redirection Request - FOR-27%%%SafeSenders Newsweaver%%%Infosec Redirection Rule - Do NOT Remove%%%Infosec Redirection Rule 2 - Whaling - Do NOT Remove%%%radcliffe&maconie AR Loop%%%ActivityMaker@bbc.co.uk OOO Loop%%%BBC Board Mails Prefix%%%INC000001347172%%%EMT/State51 Mail Loop%%%All in the Mind Email loop%%%Southeasttoday Email loop%%%Jeremy Vine Show email loop%%%Musicfeedback NDR loop%%%looknorth Email loop%%%Look North Spam War%%%My Pension Email loop with Mailer-Daemon@hosting-e.gsi.gov.uk%%%LookNorth Spam Block%%%Mypension Loop%%%MyPension Email Loop%%%LookEastEmail%%%AbusiveMailBlock%%%YoungDancer Mail Loops%%%INC000001354049%%%EmailStormBlock for rozina.breen@bbc.co.uk%%%bbc.com junk mail%%%Re-direct requested by infosec - Andrea walker 12/12/3013%%%SpamCheck - info@afrodisia.pt%%%Phishing emails - Updated 12/12/2013%%%soc-5256%%%2nd NGA Payroll Mail Loop Issue%%%NGA-Payroll Mail Loop%%%MusicFeedback Mail Loop%%%LOGMEIN phishing email%%%French Holidays Spam%%%Points of View Read Reciept%%%Spam Block Request by Robert Naylor%%%Spam block for Simon Derry%%%support-instant%%%Tarpitting for BBC Scotland Spam%%%francesco.campiglio%%%Breakfast.tv spam rule%%%IDAM redirect%%%Desmond Carrington PF EBay block rule%%%IDAM Redirect (2)%%%Bacon Loop 2%%%Sharepoint Teamsite Filter Domain Filter%%%Mailer-Daemon@da1.terra.kiev.ua to DVDenquiry%%%Temp for sport.interactive@bbc.co.uk%%%Infosec redirect Sun 02/08/2015 11:38%%%DL01nrsche@bbc.co.uk Mail Storm x-ms-exchange-organization-processed-by-journaling: Journal Agent Content-Type: multipart/signed; boundary="Apple-Mail=_6F93BE7A-EA37-4B95-9755-88DF6E264698"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-MS-Exchange-Organization-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 --Apple-Mail=_6F93BE7A-EA37-4B95-9755-88DF6E264698 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 5 Mar 2018, at 23:11, Ben Campbell wrote: >=20 > Hi, >=20 > Here is my AD Evaluation of draft-ietf-payload-rtp-vc2hq-04. It=E2=80=99= s mostly in good shape, but I do have some comments and questions. I = would like to discuss at least my substantive comments before IETF LC. >=20 > Thanks! >=20 > Ben. >=20 > *** Substantive Comments: >=20 > =C2=A74.1: =E2=80=9C A Sequence Header packet SHOULD have the same = timestamp as the next picture which will follow it in the stream. An = End of Sequence packet SHOULD have the same timestamp as the previous = picture which appeared in the stream.=E2=80=9D >=20 > Why are those SHOULDs not MUSTs? Do you envision circumstances where = it might be reasonable to violate them? What are the consequences if you = do? I honestly can=E2=80=99t think of any real consequences for violating = this, but since these packets need to have some value for timestamp it = seemed reasonable to make a recommendation. > =C2=A74.2, definitions of I and F: Same question as for =C2=A74.1. Yes, these should probably be MUST. > - Slice Prefix Bytes and Slice Size Scaler: Both contain disclaimers = saying =E2=80=9Cunlikely to be too large.=E2=80=9D But IIUC, there are = normative requirements later in the draft that prevent them from ever = being to large. If my understanding is correct, it would be helpful to = clarify this here. (Otherwise reviewers may see =E2=80=9Cunlikely to be = =E2=80=9C as a red flag.) Ok, I=E2=80=99ll clarify that. > - This section is inconsistent about using normative keywords for = field contents. Most do, but starting with =E2=80=9CFragment Length=E2=80=9D= they are stated descriptively. For matters of definition, I am okay = with either approach but it would be good to be consistent. Ok, I=E2=80=99ll fix them all to use normative keywords. > =C2=A74.4: "Every High Quality Picture Fragment MUST contain no more = than 65535 slices.=E2=80=9D >=20 > This seems non-constraining giving the following requirement that it = must not contain over 65535 bytes. Fair point. Maybe I should just list the bytes limit and then add the = explanation =E2=80=9Cand hence cannot contain over 65535 slices = either=E2=80=9D. > =C2=A75: =E2=80=9C The circuit breakers is to be implemented and = followed.=E2=80=9D > Was there a reason not to use a MUST here? (also it seems like = there=E2=80=99s a missing word after =E2=80=9Cbreakers=E2=80=9D) Yeah, that seems wrong.=20 > - =E2=80=9C If used on a closed network which has been correctly = provisioned for the expected data rates then profile MAY be used without = congestion control, but on the open internet some sort of congestion = control approach MUST be taken.=E2=80=9D >=20 > That sort of statement is dangerous; code that is intended for use in = private networks has a habit of escaping onto the internet. Is the code = supposed to know? Would it make sense to require implementations to = default to using congestion control unless explicitly configured = otherwise? How about a change to the same sort of wording used in RFC 8130? "Since UDP does not provide congestion control, applications that use RTP over UDP SHOULD implement their own congestion control above the UDP layer [RFC8085] and MAY also implement a transport circuit breaker [RFC8083]. Work in the RMCAT working group [RMCAT] describes the interactions and conceptual interfaces necessary between the application components that relate to congestion control, including the RTP layer, the higher-level media codec control layer, and the lower-level transport interface, as well as components dedicated to congestion control functions." > *** Editorial Comments and Nits: >=20 > =C2=A72: Please consider using the new boilerplate from RFC 8175. = There are a few lowercase instances of =E2=80=9Cshould=E2=80=9D and = =E2=80=9Cmust=E2=80=9D. At least some of the =E2=80=9Cshould=E2=80=9D = instances to not appear to be normative Do you mean 8174? If so then yes, that makes sense. > =C2=A73: " Each High Quality Fragment data unit contains either a set = of parameters for a picture or a series of coded Slices. >=20 > Does this mean =E2=80=9Cset of parameters for (a picture or a series = of coded slices), or (set of parameters for a picture) or (a series of = coded slices)? >=20 > Also it would be good to clarify in =C2=A73 that only fragments are = used with this payload format. It means the latter. Yes I will reword to be clearer. > =C2=A74: Caption for figure 2: The text describes figure 2 as =E2=80=9C=E2= =80=A6 carries the Picture Fragment containing the VC-2 Transform = Parameters for a Picture. It would help to mention that (perhaps in a = shortened form) in the caption. ok. > =C2=A74.4: =E2=80=9C If a Sequence intended for tranmission does not = conform to these restrictions then it MAY be possible to simply convert = it=E2=80=A6" >=20 > This seems like a statement of fact rather than a grant of permission. = As such, it should not use the 2119 keyword. Yes, how about: =E2=80=9CInformative note: Some streams which do not meet these = restrictions can be converted into streams which do without the need to = reencode the encoded data simply by adjusting the distribution of slices = into fragments, others cannot.=E2=80=9D Should I submit a revised draft with the above changes made? -- James P. Weaver (n=C3=A9 Barrett) Research Engineer BBC R&D North Lab, Floor 5 Dock House, MediaCity, M50 2LH Tel: +44(0)30 3040-9521 e-mail: james.barrett@bbc.co.uk --Apple-Mail=_6F93BE7A-EA37-4B95-9755-88DF6E264698 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEzjCCBMow ggOyoAMCAQICCGz7ca4TIOMLMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJHQjEPMA0GA1UE BwwGTG9uZG9uMSkwJwYDVQQKDCBCcml0aXNoIEJyb2FkY2FzdGluZyBDb3Jwb3JhdGlvbjEXMBUG A1UECwwORk1UIEdyZWVuaG91c2UxLDAqBgNVBAMMI0JCQyBHcmVlbmhvdXNlIERldmVsb3BtZW50 IFN0YWZmIENBMB4XDTE3MDUxMTEwMDE0NloXDTE4MDUxMTEwMDE0NlowgcMxJjAkBgkqhkiG9w0B CQEWF2phbWVzLmJhcnJldHRAYmJjLmNvLnVrMRUwEwYDVQQDDAxKYW1lcyBXZWF2ZXIxJzAlBgNV BAsMHkJCQyAtIFJlc2VhcmNoIGFuZCBEZXZlbG9wbWVudDEpMCcGA1UECgwgQnJpdGlzaCBCcm9h ZGNhc3RpbmcgQ29ycG9yYXRpb24xITAfBgNVBAcMGE1lZGlhQ2l0eSwgU2FsZm9yZCBRdWF5czEL MAkGA1UEBhMCR0IwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC0QJgFEXTp1RI/CUXm BgUutmqTHYjjfZofdy4NYyW7O4NkoOvCeguqs1zvEIy0J9VLNYpDytnAnoGPpAsW2o4FExG7WoN2 RyITvChqsCqiVxkv4RxB5nWyD721gJvnyhKEZM3rv0C/sJdO9IkMhtBlxdnvOjI8+/6totWMWlT5 UAbV3DHKrlFxNtsxJbVS0Lil1x9XYF79eFwNR7/Yw4wGKQilBLUw1D3NPYeilDJ6y7ZMlCYLRPZZ VK0o/PNVM9PaDlrlmSI3pud2NyTlPKLnphnHRloIGU/k5SwVzZQg1kfxfCBkD9UGJqhyt35AqCKU P6q7Ehqx5+bpFeyjmO5xAgMBAAGjgfIwge8wHQYDVR0OBBYEFAGag8RARbfyEOVZNqcGw9J8Uu19 MAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAUM4RuLxYJqP4h91t1VT0SZGDYuUQwDwYDVR0PAQH/BAUD Awf/gDCBkAYDVR0lBIGIMIGFBgRVHSUABggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMDBggr BgEFBQcDBAYIKwYBBQUHAwgGCisGAQQBgjcUAgIGCCsGAQUFBwMJBgorBgEEAYI3CgMEBgsrBgEE AYI3CgMEAQYIKwYBBQUHAxEGCCsGAQUFBwMPBggrBgEFBQcDEDANBgkqhkiG9w0BAQUFAAOCAQEA Tt444c/PLM3ORRl39yASPYKBhZr9i+fCUKlPEVZESYMhrOp24olinj/m0ONyNXG5PNA+dCgRNemN lU6kMI2QUqojSYuOC1ScpeGPIoew/dYU8rpYc3ozVE61792rJS7S8N4WPf06C1rqNOS0fnwFQAIN ZS6+jGG3HcH9EgYj+QmNf9NteXEkZPIu55n40xxAaUlip/orgf7JST0XEfirXYhFkxqyYSig9sM1 nRkXxMqOsp1kqwYUbSCXd4xXUA9LIHhMDFeWQCvtAbW+ADYCpRV6BiwJeOeyBx72KMkg1hsvD7QX 72MEyN5UYf9phoMUn9yzgOar8ya7vNLqcIxuADGCA4owggOGAgEBMIGdMIGQMQswCQYDVQQGEwJH QjEPMA0GA1UEBwwGTG9uZG9uMSkwJwYDVQQKDCBCcml0aXNoIEJyb2FkY2FzdGluZyBDb3Jwb3Jh dGlvbjEXMBUGA1UECwwORk1UIEdyZWVuaG91c2UxLDAqBgNVBAMMI0JCQyBHcmVlbmhvdXNlIERl dmVsb3BtZW50IFN0YWZmIENBAghs+3GuEyDjCzAJBgUrDgMCGgUAoIIBwTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAzMDcxMTAwMzlaMCMGCSqGSIb3DQEJBDEW BBRYGYxvu5GcTmS2xh86G3DzSLEnGzCBrgYJKwYBBAGCNxAEMYGgMIGdMIGQMQswCQYDVQQGEwJH QjEPMA0GA1UEBwwGTG9uZG9uMSkwJwYDVQQKDCBCcml0aXNoIEJyb2FkY2FzdGluZyBDb3Jwb3Jh dGlvbjEXMBUGA1UECwwORk1UIEdyZWVuaG91c2UxLDAqBgNVBAMMI0JCQyBHcmVlbmhvdXNlIERl dmVsb3BtZW50IFN0YWZmIENBAghs+3GuEyDjCzCBsAYLKoZIhvcNAQkQAgsxgaCggZ0wgZAxCzAJ BgNVBAYTAkdCMQ8wDQYDVQQHDAZMb25kb24xKTAnBgNVBAoMIEJyaXRpc2ggQnJvYWRjYXN0aW5n IENvcnBvcmF0aW9uMRcwFQYDVQQLDA5GTVQgR3JlZW5ob3VzZTEsMCoGA1UEAwwjQkJDIEdyZWVu aG91c2UgRGV2ZWxvcG1lbnQgU3RhZmYgQ0ECCGz7ca4TIOMLMA0GCSqGSIb3DQEBAQUABIIBACtb lFEVvhM9XfTyKm28APaGpZKp1kWxAL4a/gZEikMSa/UOdQbgUZRbr1XY5c3eO3tq20ZL2jW3mX0D cbaZDvWHoNLsuVLW4FGLfAyHZtll7YMhYsjzEg8PHo8HY2AyLDW3+P1O16CljqdIh58aYl65S0m5 aFNeqGzEpEdcPJMtwZ9LZgRSgHP+TS/Z2rSSgbwYy/nYKkbU+yN1QN6C/jvp0qp5GGHnlBmGuBHU ar91QrVyrHzLb0zEXaMcy2KHsaZljsOafKrxQIxI+mH8AfojTuj1EyC7PPJ80PTpzyMaQ1i9IE7P w1yWGNt5C7K8IZbqoJWv+ziy4T+hE4l288YAAAAAAAA= --Apple-Mail=_6F93BE7A-EA37-4B95-9755-88DF6E264698-- --_3b0650fb-9321-49e7-8bec-8775642a98f0_-- From nobody Tue Mar 13 00:59:15 2018 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DCB12D778 for ; Tue, 13 Mar 2018 00:59:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.75.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152092795373.4661.10117418260193513208.idtracker@ietfa.amsl.com> Date: Tue, 13 Mar 2018 00:59:13 -0700 From: IETF Secretariat Archived-At: Subject: [payload] Milestones changed for payload WG X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 13 Mar 2018 07:59:14 -0000 Changed milestone "submit RTP Payload Format for VC-2 HQ Profile Video", resolved as "Done". URL: https://datatracker.ietf.org/wg/payload/about/ From nobody Tue Mar 13 01:00:15 2018 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E0512D77D for ; Tue, 13 Mar 2018 01:00:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.75.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152092801352.4681.5440988707854326429.idtracker@ietfa.amsl.com> Date: Tue, 13 Mar 2018 01:00:13 -0700 From: IETF Secretariat Archived-At: Subject: [payload] Milestones changed for payload WG X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 13 Mar 2018 08:00:14 -0000 Changed milestone "Submit RTP Payload Format for Non-Interleaved and Interleaved Parity FEC", set due date to May 2018 from March 2017. URL: https://datatracker.ietf.org/wg/payload/about/ From nobody Tue Mar 13 01:00:47 2018 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE6D12D77D for ; Tue, 13 Mar 2018 01:00:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.75.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152092804583.4608.15117722725509974630.idtracker@ietfa.amsl.com> Date: Tue, 13 Mar 2018 01:00:45 -0700 From: IETF Secretariat Archived-At: Subject: [payload] Milestones changed for payload WG X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 13 Mar 2018 08:00:46 -0000 Changed milestone "Submit RTP Payload Format for VP9 Video for Proposed Standard", set due date to July 2018 from March 2017. URL: https://datatracker.ietf.org/wg/payload/about/ From nobody Sun Mar 18 02:47:40 2018 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 199361200FC for ; Sun, 18 Mar 2018 02:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 pyCDZpsShm7S for ; Sun, 18 Mar 2018 02:47:32 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 77589127077 for ; Sun, 18 Mar 2018 02:47:32 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0C9C093F4E38F for ; Sun, 18 Mar 2018 09:47:29 +0000 (GMT) Received: from DGGEMM423-HUB.china.huawei.com (10.1.198.40) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sun, 18 Mar 2018 09:47:30 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by dggemm423-hub.china.huawei.com ([10.1.198.40]) with mapi id 14.03.0361.001; Sun, 18 Mar 2018 17:47:22 +0800 From: "Roni Even (A)" To: "Mo Zanaty (mzanaty)" , Jonathan Lennox , "'Victor Demjanenko, Ph.D.'" , REISENBAUER Andreas CC: "payload@ietf.org" , "Ali C. Begen" Thread-Topic: Slides for Payload session Thread-Index: AdO+nZI0FoH/ZJhHTzKjF3vBKPQsEQ== Date: Sun, 18 Mar 2018 09:47:22 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD86CD05@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.91.2] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD86CD05DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [payload] Slides for Payload session X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2018 09:47:34 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD86CD05DGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi guys, Please send the WG chairs slides for your presentation by Wednesday. I allocated time for the WG documents (FEC and VP9) and for tetra and tsvci= s individual drafts. If you do not intend to present in person please send a slide or two to the= WG chairs and we will present them for you. For the individual drafts the plan is to ask for adoption Roni Even (A) Payload WG co-chair --_000_6E58094ECC8D8344914996DAD28F1CCD86CD05DGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi guys,

Please send the WG chairs slides for your presentati= on by Wednesday.

I allocated time for the WG documents (FEC and VP9) = and for tetra and tsvcis individual drafts.

If you do not intend to present in person please sen= d a slide or two to the WG chairs and we will present them for you.

For the individual drafts the plan is to ask for ado= ption

Roni Even (A)

Payload WG co-chair

 

--_000_6E58094ECC8D8344914996DAD28F1CCD86CD05DGGEMM506MBXchina_-- From nobody Sun Mar 18 03:30:54 2018 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 84D5E127077 for ; Sun, 18 Mar 2018 03:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 hy4b-eVgdFYL for ; Sun, 18 Mar 2018 03:30:50 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 AF037127599 for ; Sun, 18 Mar 2018 03:30:49 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 4313B2866C323 for ; Sun, 18 Mar 2018 10:30:46 +0000 (GMT) Received: from DGGEMM424-HUB.china.huawei.com (10.1.198.41) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sun, 18 Mar 2018 10:30:47 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by dggemm424-hub.china.huawei.com ([10.1.198.41]) with mapi id 14.03.0361.001; Sun, 18 Mar 2018 18:30:41 +0800 From: "Roni Even (A)" To: "payload@ietf.org" Thread-Topic: review of draft-df-stecker-expertenforum-payload-tetra-00 Thread-Index: AdO+noCKXg3hAn4dTqCwB52K75Au8w== Date: Sun, 18 Mar 2018 10:30:41 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD86CD40@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.91.2] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD86CD40DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [payload] review of draft-df-stecker-expertenforum-payload-tetra-00 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2018 10:30:53 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD86CD40DGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I read the draft and have some comments. 1. in the abstract you can remove the sentence about the storage mode and i= n the first sentence remove "to be used" 2. In the introduction (section 1 ) add the reference to TETRA in the first= sentence. 3. In section 3 what are E1 lines? 4. Last secntence of section 3 - Is it used, what is the use case for carr= ying OSTE in RTP where there is timing information is RTP. 5. In section 4 "or together within one RTP frame " maybe say RTP packet. 6. For clarity maybe move section 4.4 before section 4.2 (or include 4.4 i= n the beginning of 4.2) 7. About the note at the end of 4.3 , what out of scope means? Is it meant = to say MUST be ignored by the RTP receiver? 8. In section 4.2.4 "This bit may be set to "1" if an encryption or a decr= yption operation could not be performed successfully". Since this is the s= ent RTP stream, I can understand cannot encrypt this half block, what does= it mean cannot decrypt. 9. In section 4.2.4 -" If a receiver decides to forward the TETRA audio dat= a to OSTE or FSTE" . How is the decision made and should he forward this= sub block or the whole audio stream? 10. in section 6 maybe use the following text "Since UDP does not provide c= ongestion control, applications that use RTP over UDP SHOULD implement the= ir own congestion control above the UDP layer [RFC8085] and MAY also im= plement a transport circuit breaker [RFC8083]. Work in the RMCAT working group [RMCAT] describes the interactions and conceptual interfaces necessary between the applic= ation components that relate to congestion control, including the RTP lay= er, the higher-level media codec control layer, and the lower-level transport interface, as well as components dedicated to co= ngestion control functions." 11. section 7 use "per the media type registration template from RFC 6838= [RFC6838]." 12. in section 7.1 - drgw-fe - Why do you need to specify it here and regi= ster this parameter. If you are sending rtp payload with subtype name tetra= it is this rtp payload. 13. In section 7.1 - security consideration should say see section 10 of R= FCXXXX (this RFC) and a note to RFC editor to replace RFCXXXX with the numb= er of this RFC 14. In section 8 - we do not use the term MIME but media type or media subt= ype. 15. in the example at the end of section 8 the a=3Dfmtp:99 is not needed if= you do not have any optional parameters. 16. in 8.1 add reference to RFC3264. Also about maxptime. Do they need to = be symmetric, is it allowed to use values that are not 60? 17. In section 8.2 Multiple TETRA rtpmap values MAY be used to convey TETRA= -coded voice at different packet rates. Does not work if you want to use p= time and maxptime since there can be one for media section, it is a=3Dmaxpt= ime:60 and not a=3Drtpmap:xx ptime:60 18. in section 9 add at the end of first sentence "from section 7.1" Roni Even as individual ________________________________ --_000_6E58094ECC8D8344914996DAD28F1CCD86CD40DGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I read the draft and have some comments.<= /p>

 

1. in the abstract you can remove the sentence about= the storage mode and in the first sentence remove “to be used”

 

2. In the introduction (section 1 ) add the referenc= e to TETRA in the first sentence.

 

3. In section 3 what are E1 lines?

 

4. Last secntence of section 3 -  Is it used, w= hat is the use case for carrying  OSTE in RTP where there is timing in= formation is RTP.

 

5.  In section 4 “or together  withi= n one RTP frame “ maybe say RTP packet.

 

6.  For clarity maybe move section 4.4 before s= ection 4.2 (or include 4.4 in the beginning of 4.2)

 

7. About the note at the end of 4.3 , what out of sc= ope means? Is it meant to say MUST be ignored by the RTP receiver?

 

8.  In section 4.2.4 “This bit may be set= to "1" if an encryption or a decryption operation could not be p= erformed successfully”.  Since this is the sent RTP stream, &nbs= p;I can understand cannot encrypt this half block, what does it mean cannot decrypt.

 

9. In section 4.2.4 –“ If a receiver dec= ides to forward the TETRA audio data to   OSTE or FSTE” &nb= sp;. How is the decision made and should he forward this sub block or the w= hole audio stream?

 

10. in section 6 maybe use the following text “= ;Since UDP does not provide congestion control,= applications that use  RTP over UD= P SHOULD implement their own congestion control above the

   UDP layer [= RFC8085] and MAY als= o implement a transport circuit  breaker [RFC8083].  Work in the RMCAT working group [RMCAT] describes

   the interac= tions and conceptual interfaces necessary between the  application com= ponents that relate to congestion control, including   the RTP la= yer, the higher-level media codec control layer, and the<= /p>

   lower-level= transport interface, as well as components dedicated to   conges= tion control functions.”

 =

11. section 7 use “= ;per the media type   registra= tion template from RFC 6838 [RFC6838].”

 =

12.  in section 7.1= – drgw-fe - Why do you need to specify it here and register this parameter. If you are = sending rtp payload with subtype name tetra it is this rtp payload.

 

13.  In section 7.1 – security considerat= ion should say see section 10 of RFCXXXX (this RFC) and a note to RFC edito= r to replace RFCXXXX with the number of this RFC

 

14. In section 8 – we do not use the term MIME= but media type or media subtype.

 

15. in the example at the end of section 8 the a=3Df= mtp:99 is not needed if you do not have any optional parameters.=

 

16.  in 8.1 add reference to RFC3264. Also abou= t maxptime. Do they need to be symmetric, is it allowed to use values that = are not 60?

 

17. In section 8.2 Multiple TETRA rtpmap values MAY = be used to convey TETRA-coded voice at different packet  rates. Does n= ot work if you want to use ptime and maxptime since there can be one for me= dia section, it is a=3Dmaxptime:60 and not a=3Drtpmap:xx ptime:60

 

18. in section 9 add at the end of first sentence &#= 8220;from section 7.1”

 

 

 

Roni Even as individual

 

 

 

 

 =

 =

 

 

 

 

 

 

 

 

--_000_6E58094ECC8D8344914996DAD28F1CCD86CD40DGGEMM506MBXchina_-- From nobody Sun Mar 18 14:42:52 2018 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 4082812D7E8 for ; Sun, 18 Mar 2018 14:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 85qFLTKj-lT2 for ; Sun, 18 Mar 2018 14:42:47 -0700 (PDT) Received: from mail2.frequentis.com (mail2.frequentis.com [195.20.158.51]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 843FD12D7E2 for ; Sun, 18 Mar 2018 14:42:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.48,327,1517871600"; d="scan'208,217";a="2480126" Received: from vie190nt.frequentis.frq ([172.16.1.190]) by mail2.frequentis.com with ESMTP; 18 Mar 2018 22:42:44 +0100 Received: from vie196nt.frequentis.frq ([172.16.1.196]) by vie190nt.frequentis.frq ([172.16.1.190]) with mapi id 14.03.0382.000; Sun, 18 Mar 2018 22:42:44 +0100 From: REISENBAUER Andreas To: "Roni Even (A)" , "payload@ietf.org" Thread-Topic: review of draft-df-stecker-expertenforum-payload-tetra-00 Thread-Index: AdO+noCKXg3hAn4dTqCwB52K75Au8wAUKH0A Date: Sun, 18 Mar 2018 21:42:43 +0000 Message-ID: <57EBEC5709E45848A81811BD60151DBA0124489A9B@vie196nt> References: <6E58094ECC8D8344914996DAD28F1CCD86CD40@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD86CD40@DGGEMM506-MBX.china.huawei.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.254.163] Content-Type: multipart/alternative; boundary="_000_57EBEC5709E45848A81811BD60151DBA0124489A9Bvie196nt_" MIME-Version: 1.0 Archived-At: Subject: Re: [payload] review of draft-df-stecker-expertenforum-payload-tetra-00 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2018 21:42:50 -0000 --_000_57EBEC5709E45848A81811BD60151DBA0124489A9Bvie196nt_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good evening Roni, Thank you for your careful review! Do you think I should push an update of the draft as "draft-df-stecker-expe= rtenforum-payload-tetra-01" _before_ we see each other in London? At least I prepared a version here, which is almost "ready-to-ship" Would be great if you can find some minutes for a short face to face meetin= g in London. I will arrive at Wednesday 21st afternoon I took your bullets as a checklist and put some comments on All the best Andreas From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even (A) Sent: Sonntag, 18. M=E4rz 2018 11:31 To: payload@ietf.org Subject: [payload] review of draft-df-stecker-expertenforum-payload-tetra-0= 0 Hi, I read the draft and have some comments. 1. in the abstract you can remove the sentence about the storage mode and i= n the first sentence remove "to be used" done 2. In the introduction (section 1 ) add the reference to TETRA in the first= sentence. done 3. In section 3 what are E1 lines? Reformulated Corrected another error here as well - reference to [3] instead of ETS 300 = 395... 4. Last secntence of section 3 - Is it used, what is the use case for carr= ying OSTE in RTP where there is timing information is RTP. The idea here is: Source of the signal typically is the mobile unit Signal is propagated over the air and via TETRA ground infrastructure (circ= uit switched) towards the gateway where it is converted to RTP Information sink consumes RTP (fully agree timing information is derived fr= om RTP) But as data corruption may also have happened along the entire communicatio= n line (including the over the air section) it would be good, if sink is in= formed about end-2-end codec packets delivery to provide best audio quality 5. In section 4 "or together within one RTP frame " maybe say RTP packet. ACK 6. For clarity maybe move section 4.4 before section 4.2 (or include 4.4 i= n the beginning of 4.2) Totally makes sense - moved 4.4 7. About the note at the end of 4.3 , what out of scope means? Is it meant = to say MUST be ignored by the RTP receiver? Have you got an idea how we could handle this? The meaning of those bits is not entirely clear - could also be a matter of= who is the receiver... So could be used to tunnel some information from source to sink along the e= ntire infrastructure Treating them as reserved? 8. In section 4.2.4 "This bit may be set to "1" if an encryption or a decr= yption operation could not be performed successfully". Since this is the s= ent RTP stream, I can understand cannot encrypt this half block, what does= it mean cannot decrypt. Originally we intended to support encrypted TETRA payload via RTP as well (= maybe I'll come back later with another draft which adds this payload) Signal flow is: Mobile does encryption (audio encryption in addition to TET= RA over the air encryption) - air transport - TETRA network - proprietary T= ETRA ground infrastructure interface (circuit mode 2Mbit/s lines) - gateway= (doing the decryption and conversion to RTP) - RTP - control room So in this sense it is decryption towards RTP which might fail for whatever= reason Or it is encryption of the RTP receiver towards TDM infrastructure (indicat= ion towards TDM which is outside the scope of what we specify here) Tried to clarify it a little bit 9. In section 4.2.4 -" If a receiver decides to forward the TETRA audio dat= a to OSTE or FSTE" . How is the decision made and should he forward this= sub block or the whole audio stream? Strongly related to point 8 - tried to clarify both 10. in section 6 maybe use the following text "Since UDP does not provide c= ongestion control, applications that use RTP over UDP SHOULD implement the= ir own congestion control above the UDP layer [RFC8085] and MAY also im= plement a transport circuit breaker [RFC8083]. Work in the RMCAT working group [RMCAT] describes the interactions and conceptual interfaces necessary between the applic= ation components that relate to congestion control, including the RTP lay= er, the higher-level media codec control layer, and the lower-level transport interface, as well as components dedicated to co= ngestion control functions." Verbally incorporated your proposal 11. section 7 use "per the media type registration template from RFC 6838= [RFC6838]." changed 12. in section 7.1 - drgw-fe - Why do you need to specify it here and regi= ster this parameter. If you are sending rtp payload with subtype name tetra= it is this rtp payload. Uuups - forgot to remove this - we have introduced this parameter to be pre= pared for any incompatible changes to be introduced while becoming an RFC (= hopefully). As we are already using the payload as drafted here Simply deleted now 13. In section 7.1 - security consideration should say see section 10 of R= FCXXXX (this RFC) and a note to RFC editor to replace RFCXXXX with the numb= er of this RFC Do you think it is enough simply to refer to section 10 (without noting "th= is RFC") as I've done it several times within this draft already? If OK thi= s would save the efforts for the note ... 14. In section 8 - we do not use the term MIME but media type or media subt= ype. changed 15. in the example at the end of section 8 the a=3Dfmtp:99 is not needed if= you do not have any optional parameters. correct - removed 16. in 8.1 add reference to RFC3264. Also about maxptime. Do they need to = be symmetric, is it allowed to use values that are not 60? Integer multiples of 30ms are allowed, no need to be symmetric - clarified = in the document 17. In section 8.2 Multiple TETRA rtpmap values MAY be used to convey TETRA= -coded voice at different packet rates. Does not work if you want to use p= time and maxptime since there can be one for media section, it is a=3Dmaxpt= ime:60 and not a=3Drtpmap:xx ptime:60 uuups - wishful thinking - thank you - corrected, we simply reject the opti= on for the receiver to select ptime 18. in section 9 add at the end of first sentence "from section 7.1" done Roni Even as individual --_000_57EBEC5709E45848A81811BD60151DBA0124489A9Bvie196nt_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Good evening Roni,

Thank you for your car= eful review!

Do you think I should = push an update of the draft as “draft-df-stecker-expertenforum-payloa= d-tetra-01” _before_ we see each other in London?

At least I prepared a = version here, which is almost “ready-to-ship”=

 

Would be great if you = can find some minutes for a short face to face meeting in London. I will ar= rive at Wednesday 21st afternoon

 

I took your bullets as= a checklist and put some comments on

 

All the best

Andreas

 

From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even (A)
Sent: Sonntag, 18. M=E4rz 2018 11:31
To: payload@ietf.org
Subject: [payload] review of draft-df-stecker-expertenforum-payload-= tetra-00

 

Hi,

I read the draft and have some = comments.

 

1. in the abstract you can remo= ve the sentence about the storage mode and in the first sentence remove = 220;to be used”

done

 

2. In the introduction (section= 1 ) add the reference to TETRA in the first sentence.

done

&n= bsp;

3. In section 3 what are E1 lin= es?

Reformu= lated

Correct= ed another error here as well – reference to [3] instead of ETS 300 3= 95…

&n= bsp;

4. Last secntence of section 3 = -  Is it used, what is the use case for carrying  OSTE in RTP whe= re there is timing information is RTP.

The ide= a here is:

Source = of the signal typically is the mobile unit

Signal = is propagated over the air and via TETRA ground infrastructure (circuit swi= tched) towards the gateway where it is converted to RTP

Informa= tion sink consumes RTP (fully agree timing information is derived from RTP)=

But as = data corruption may also have happened along the entire communication line = (including the over the air section) it would be good, if sink is informed = about end-2-end codec packets delivery to provide best audio quality

 

5.  In section 4 “or= together  within one RTP frame “ maybe say RTP packet.

ACK

&n= bsp;

6.  For clarity maybe move= section 4.4 before section 4.2 (or include 4.4 in the beginning of 4.2)

Totally= makes sense – moved 4.4

 

7. About the note at the end of= 4.3 , what out of scope means? Is it meant to say MUST be ignored by the R= TP receiver?

Have yo= u got an idea how we could handle this?

The mea= ning of those bits is not entirely clear – could also be a matter of = who is the receiver…

So coul= d be used to tunnel some information from source to sink along the entire i= nfrastructure

Treatin= g them as reserved?

&n= bsp;

8.  In section 4.2.4 ̶= 0;This bit may be set to "1" if an encryption or a decryption ope= ration could not be performed successfully”.  Since this is the = sent RTP stream,  I can understand cannot encrypt this half block, wha= t does it mean cannot decrypt.

Origina= lly we intended to support encrypted TETRA payload via RTP as well (maybe I= ’ll come back later with another draft which adds this payload)<= /o:p>

Signal = flow is: Mobile does encryption (audio encryption in addition to TETRA over= the air encryption) – air transport – TETRA network – pr= oprietary TETRA ground infrastructure interface (circuit mode 2Mbit/s lines) – gateway (doing the decryption and conversion t= o RTP) – RTP – control room

So in t= his sense it is decryption towards RTP which might fail for whatever reason=

Or it i= s encryption of the RTP receiver towards TDM infrastructure (indication tow= ards TDM which is outside the scope of what we specify here)

Tried t= o clarify it a little bit

&n= bsp;

9. In section 4.2.4 –R= 20; If a receiver decides to forward the TETRA audio data to   OS= TE or FSTE”  . How is the decision made and should he forward th= is sub block or the whole audio stream?

Strongl= y related to point 8 – tried to clarify both

&n= bsp;

10. in section 6 maybe use the = following text “Since UDP does not provid= e congestion control, applications that use  RTP over UDP SHOULD imple= ment their own congestion control above the

 &nb= sp; UDP layer [RFC8085] and MAY also implement a transport circuit  breaker [RFC8083].  Work in the RMCAT= working group [RMCAT] describes

 &nb= sp; the interactions and conceptual interfaces necessary between the  = application components that relate to congestion control, including &n= bsp; the RTP layer, the higher-level media codec control layer, and the

 &nb= sp; lower-level transport interface, as well as components dedicated to&nbs= p;  congestion control functions.”

Verball= y incorporated your proposal

&nbs= p;

11. secti= on 7 use “per the media type   registration template from RFC 6838 [RFC6838].”

changed=

&n= bsp;

12. = in section 7.1 – drgw-fe - Why do you need to specify it here and register= this parameter. If you are sending rtp payload with subtype name tetra it = is this rtp payload.

Uuups &= #8211; forgot to remove this – we have introduced this parameter to b= e prepared for any incompatible changes to be introduced while becoming an = RFC (hopefully). As we are already using the payload as drafted here

Simply = deleted now

 

13.  In section 7.1 –= ; security consideration should say see section 10 of RFCXXXX (this RFC) an= d a note to RFC editor to replace RFCXXXX with the number of this RFC<= /o:p>

Do you = think it is enough simply to refer to section 10 (without noting “thi= s RFC”) as I’ve done it several times within this draft already= ? If OK this would save the efforts for the note …<= /p>

 

14. In section 8 – we do = not use the term MIME but media type or media subtype.

changed=

&n= bsp;

15. in the example at the end o= f section 8 the a=3Dfmtp:99 is not needed if you do not have any optional p= arameters.

correct= – removed

&n= bsp;

16.  in 8.1 add reference = to RFC3264. Also about maxptime. Do they need to be symmetric, is it allowe= d to use values that are not 60?

Integer= multiples of 30ms are allowed, no need to be symmetric – clarified i= n the document

 

17. In section 8.2 Multiple TET= RA rtpmap values MAY be used to convey TETRA-coded voice at different packe= t  rates. Does not work if you want to use ptime and maxptime since th= ere can be one for media section, it is a=3Dmaxptime:60 and not a=3Drtpmap:xx ptime:60

uuups &= #8211; wishful thinking – thank you – corrected, we simply reje= ct the option for the receiver to select ptime

 

18. in section 9 add at the end= of first sentence “from section 7.1”

done

 

 

Roni Even as individual

 

 

 

 

&nbs= p;

&nbs= p;

 

 

 

 

 

 

 

 

--_000_57EBEC5709E45848A81811BD60151DBA0124489A9Bvie196nt_-- From nobody Wed Mar 21 06:10:57 2018 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 CDAAF12DA1C for ; Wed, 21 Mar 2018 06:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 jUSvC-Vh9rYj for ; Wed, 21 Mar 2018 06:10:52 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 A00A612DA3E for ; Wed, 21 Mar 2018 06:10:45 -0700 (PDT) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id EBAADCB278A30 for ; Wed, 21 Mar 2018 13:10:41 +0000 (GMT) Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 21 Mar 2018 13:10:43 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0361.001; Wed, 21 Mar 2018 21:10:39 +0800 From: "Roni Even (A)" To: "Mo Zanaty (mzanaty)" , Jonathan Lennox , REISENBAUER Andreas CC: "payload@ietf.org" , "Ali C. Begen" Thread-Topic: Slides for Payload session - reminder Thread-Index: AdPBFgGEvD/qfhGsQ7W3E5T5AJqkHA== Date: Wed, 21 Mar 2018 13:10:39 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD86DED3@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.93.136] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD86DED3DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [payload] Slides for Payload session - reminder X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2018 13:10:55 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD86DED3DGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi guys, Please send the WG chairs slides for your presentation by Wednesday. I allocated time for the WG documents (FEC and VP9) and for tetra and tsvci= s individual drafts. If you do not intend to present in person please send a slide or two to the= WG chairs and we will present them for you. For the individual drafts the plan is to ask for adoption Roni Even (A) Payload WG co-chair --_000_6E58094ECC8D8344914996DAD28F1CCD86DED3DGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi guys,

Please send the WG chairs slides for your presentati= on by Wednesday.

I allocated time for the WG documents (FEC and VP9) = and for tetra and tsvcis individual drafts.

If you do not intend to present in person please sen= d a slide or two to the WG chairs and we will present them for you.

For the individual drafts the plan is to ask for ado= ption

Roni Even (A)

Payload WG co-chair

 

--_000_6E58094ECC8D8344914996DAD28F1CCD86DED3DGGEMM506MBXchina_-- From nobody Thu Mar 22 06:22:15 2018 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A5C127010; Thu, 22 Mar 2018 06:22:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: payload@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.76.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152172493355.5628.6536911758234880946@ietfa.amsl.com> Date: Thu, 22 Mar 2018 06:22:13 -0700 Archived-At: Subject: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-07.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 22 Mar 2018 13:22:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads WG of the IETF. Title : RTP Payload Format for Flexible Forward Error Correction (FEC) Authors : Mo Zanaty Varun Singh Ali Begen Giridhar Mandyam Filename : draft-ietf-payload-flexible-fec-scheme-07.txt Pages : 39 Date : 2018-03-22 Abstract: This document defines new RTP payload formats for the Forward Error Correction (FEC) packets that are generated by the non-interleaved and interleaved parity codes from source media encapsulated in RTP. These parity codes are systematic codes, where a number of FEC repair packets are generated from a set of source packets from one or more source RTP streams. These FEC repair packets are sent in a redundancy RTP stream separate from the source RTP stream(s) that carries the source packets. RTP source packets that were lost in transmission can be reconstructed using the source and repair packets that were received. The non-interleaved and interleaved parity codes which are defined in this specification offer a good protection against random and bursty packet losses, respectively, at a cost of decent complexity. The RTP payload formats that are defined in this document address the scalability issues experienced with the earlier specifications including RFC 2733, RFC 5109 and SMPTE 2022-1, and offer several improvements. Due to these changes, the new payload formats are not backward compatible with the earlier specifications, but endpoints that do not implement this specification can still work by simply ignoring the FEC repair packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-07 https://datatracker.ietf.org/doc/html/draft-ietf-payload-flexible-fec-scheme-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-flexible-fec-scheme-07 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 Thu Mar 22 09:41:26 2018 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 49536127010; Thu, 22 Mar 2018 09:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 DHLox_G5WRSW; Thu, 22 Mar 2018 09:41:18 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 98B74124B17; Thu, 22 Mar 2018 09:41:18 -0700 (PDT) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 0481E9E12100D; Thu, 22 Mar 2018 16:41:15 +0000 (GMT) Received: from DGGEMM424-HUB.china.huawei.com (10.1.198.41) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 22 Mar 2018 16:41:16 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by dggemm424-hub.china.huawei.com ([10.1.198.41]) with mapi id 14.03.0361.001; Fri, 23 Mar 2018 00:41:12 +0800 From: "Roni Even (A)" To: "payload@ietf.org" CC: "rtcweb@ietf.org" Thread-Topic: Second WGLC on draft-ietf-payload-flexible-fec-scheme Thread-Index: AdPB++FNFyNr/SHZTm6JnPXdmrK5pg== Date: Thu, 22 Mar 2018 16:41:11 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD86E663@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.83.153] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD86E663DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [payload] Second WGLC on draft-ietf-payload-flexible-fec-scheme X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 22 Mar 2018 16:41:20 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD86E663DGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I would like to start a three week second WGLC on RTP Payload Format for Fl= exible Forward Error Correction in draft-ietf-payload-flexible-fec-scheme-0= 7. The WGLC will end on April 11th , 2018 Note that the first WGLC was on the 05 version and the 06,07 are increment= al updates. The slides from the IETF 101 payload session describe the changes see https= ://datatracker.ietf.org/meeting/101/materials/slides-101-payload-flexible-f= ec-00 . Please send comments to the payload mailing list. The double posting is to notify RTCweb WG that the second WGLC has starte= d since this document is needed for RTCweb Roni Even Payload WG co-chair --_000_6E58094ECC8D8344914996DAD28F1CCD86E663DGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I would like to start a three week second WGLC on RTP Payload Format for Flexible Forward Error Correction in draft-ietf-payload-flexible-fec-scheme-07.

The WGLC will end on April 11th , 2018

 

Note that the first WGLC was on the 05 version  = ;and the 06,07 are incremental updates.

The slides from the IETF 101 payload session describ= e the changes see https://datatracker.ietf.org/meeting/101/materials/slides-101-payload-flexi= ble-fec-00 .

 

Please send comments to the payload mailing list.

The double posting is to  notify RTCweb WG that the second  WGLC has started since this d= ocument is needed for RTCweb

 =

 =

Roni Even

Payload WG co-chair=

 

--_000_6E58094ECC8D8344914996DAD28F1CCD86E663DGGEMM506MBXchina_-- From nobody Sat Mar 24 02:40:59 2018 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 3911B127909 for ; Sat, 24 Mar 2018 02:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 t8-xjs583jJe for ; Sat, 24 Mar 2018 02:40:56 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 AC6EB12785F for ; Sat, 24 Mar 2018 02:40:56 -0700 (PDT) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 693CA21D1A11; Sat, 24 Mar 2018 09:40:53 +0000 (GMT) Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sat, 24 Mar 2018 09:40:54 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0361.001; Sat, 24 Mar 2018 17:40:51 +0800 From: "Roni Even (A)" To: Stephen Botzko , Brian Baldino , Rasmus Brandt , Boris Grozev , Magnus Westerlund CC: "payload@ietf.org" , Jonathan Lennox Thread-Topic: Please review of draft-ietf-payload-flexible-fec-scheme-07 Thread-Index: AdPDU6qkEnhW8KLPR4i+RyDdM6tiLg== Date: Sat, 24 Mar 2018 09:40:51 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD86EAC5@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.81.163] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD86EAC5DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [payload] Please review of draft-ietf-payload-flexible-fec-scheme-07 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 24 Mar 2018 09:40:58 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD86EAC5DGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi guys, I would like to thanks you for the good feedback you provided for the 05 v= ersion in the WGLC. We started a second WGLC and the WG chairs will appreciate your help review= ing the 07 version now that it is in the second WGLC so that we can send th= e document for publication. This document is part of the dependencies for RTCweb and may even be the la= st one in the dependency list. Please review and send comments to the payload list Thanks Roni Even (A) Payload WG co-chair --_000_6E58094ECC8D8344914996DAD28F1CCD86EAC5DGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi guys,

I would like  to thanks you for the good feedba= ck you provided for the 05 version in the WGLC.

We started a second WGLC and the WG chairs will appr= eciate your help reviewing the 07 version now that it is in the second WGLC= so that we can send the document for publication.

This document is part of the dependencies for RTCweb= and may even be the last one in the dependency list.

Please review and send comments to the payload  = ;list

 

Thanks

Roni Even (A)

Payload WG co-chair

 

--_000_6E58094ECC8D8344914996DAD28F1CCD86EAC5DGGEMM506MBXchina_-- From nobody Sat Mar 24 09:19:53 2018 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 B0FBF1272E1 for ; Sat, 24 Mar 2018 09:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 sR_rzpTeK_XJ for ; Sat, 24 Mar 2018 09:19:51 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 2E0621200C5 for ; Sat, 24 Mar 2018 09:19:51 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 72AF7E05EC51D for ; Sat, 24 Mar 2018 16:19:47 +0000 (GMT) Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sat, 24 Mar 2018 16:19:48 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0361.001; Sun, 25 Mar 2018 00:19:43 +0800 From: "Roni Even (A)" To: "payload@ietf.org" Thread-Topic: IETF 101 meeting notes Thread-Index: AdPDizqV6x8k+fbyQ166vkJtXvJLyw== Date: Sat, 24 Mar 2018 16:19:42 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD86EB7F@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.90.151] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD86EB7FDGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [payload] IETF 101 meeting notes X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 24 Mar 2018 16:19:52 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD86EB7FDGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I uploaded the payload session meeting notes. Please review and see if ther= e comments https://datatracker.ietf.org/meeting/101/materials/minutes-101-payload-00 Thanks Roni Even (A) Payload WG co-chair --_000_6E58094ECC8D8344914996DAD28F1CCD86EB7FDGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I uploaded the payload session meeting notes. Please= review and see if there comments

https://datatracker.ietf.org/meeting/101/= materials/minutes-101-payload-00

 

Thanks

Roni Even (A) Payload WG co-chair

--_000_6E58094ECC8D8344914996DAD28F1CCD86EB7FDGGEMM506MBXchina_-- From nobody Sat Mar 24 09:24:25 2018 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 E41D812D0C3 for ; Sat, 24 Mar 2018 09:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 AyQ4_63-1DvT for ; Sat, 24 Mar 2018 09:24:22 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 C6942127698 for ; Sat, 24 Mar 2018 09:24:22 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A301A37C87108 for ; Sat, 24 Mar 2018 16:24:19 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sat, 24 Mar 2018 16:24:21 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0361.001; Sun, 25 Mar 2018 00:24:16 +0800 From: "Roni Even (A)" To: "payload@ietf.org" Thread-Topic: adopting RTP Payload Format for TSVCIS Codec as a milestone Thread-Index: AdPDjCcuVqXuycMuQKyyyU/YpLs0uA== Date: Sat, 24 Mar 2018 16:24:15 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD86EB98@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.90.151] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD86EB98DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [payload] adopting RTP Payload Format for TSVCIS Codec as a milestone X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 24 Mar 2018 16:24:24 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD86EB98DGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, At the IETF101 payload session there were no objections to adopt RTP Paylo= ad Format for TSVCIS Codec as an PAYLOAD WG milestone based on https://tool= s.ietf.org/id/draft-demjanenko-payload-tsvcis-00.txt The chairs would like to confirm it. Please send feedback to the list by April 2nd Thanks Roni Even Payload WG co-chair --_000_6E58094ECC8D8344914996DAD28F1CCD86EB98DGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

At the IETF101 payload session  there were no o= bjections to adopt RTP Payload Format for TSVCIS Codec as an PAYLOAD WG mil= estone based on https://tools.ietf.org/id/draft-demjanenko-payload-tsvcis-00.txt

 

The chairs would like to confirm it.

Please send feedback to the list by April 2nd

 

Thanks

Roni Even Payload WG co-chair

--_000_6E58094ECC8D8344914996DAD28F1CCD86EB98DGGEMM506MBXchina_-- From nobody Sat Mar 24 09:27:05 2018 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 A5D7012D7E4 for ; Sat, 24 Mar 2018 09:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 ckuodz9GiMWe for ; Sat, 24 Mar 2018 09:27:00 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 5DF1712D0C3 for ; Sat, 24 Mar 2018 09:26:51 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 20A9D2AC0BC03 for ; Sat, 24 Mar 2018 16:26:47 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sat, 24 Mar 2018 16:26:47 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0361.001; Sun, 25 Mar 2018 00:26:33 +0800 From: "Roni Even (A)" To: "payload@ietf.org" Thread-Topic: adopting RTP Payload Format for the TETRA Audio Codec as a payload WG milestone Thread-Index: AdPDjLE+RTNZ5W5jRoOkrgPZrivVlA== Date: Sat, 24 Mar 2018 16:26:34 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD86EBAF@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.90.151] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD86EBAFDGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [payload] adopting RTP Payload Format for the TETRA Audio Codec as a payload WG milestone X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 24 Mar 2018 16:27:04 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD86EBAFDGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, At the IETF101 payload session there were no objections to adopt RTP Paylo= ad Format for the TETRA Audio Codec as an PAYLOAD WG milestone based on ht= tps://tools.ietf.org/html/draft-df-stecker-expertenforum-payload-tetra-00 The chairs would like to confirm it. Please send feedback to the list by April 2nd Thanks Roni Even Payload WG co-chair --_000_6E58094ECC8D8344914996DAD28F1CCD86EBAFDGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

At the IETF101 payload session  there were no o= bjections to adopt RTP Payload Format for the T= ETRA Audio Codec  as an PAYLOAD WG milestone based on https://tools.ietf.org/html/draft-df-stecker-expertenforum-payload-tetra-00=

 

The chairs would like to confirm it.

Please send feedback to the list by April 2nd

 

Thanks

Roni Even Payload WG co-chair

 

--_000_6E58094ECC8D8344914996DAD28F1CCD86EBAFDGGEMM506MBXchina_-- From nobody Wed Mar 28 07:25:13 2018 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 8078612711B for ; Wed, 28 Mar 2018 07:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 4IUGKq2p8f4X for ; Wed, 28 Mar 2018 07:25:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 001B01270FC for ; Wed, 28 Mar 2018 07:25:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C7395B82180; Wed, 28 Mar 2018 07:24:51 -0700 (PDT) To: thomas.edwards@fox.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, ali.begen@networked.media, roni.even@huawei.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: amalizia@matrox.com, payload@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180328142451.C7395B82180@rfc-editor.org> Date: Wed, 28 Mar 2018 07:24:51 -0700 (PDT) Archived-At: Subject: [payload] [Editorial Errata Reported] RFC8331 (5310) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2018 14:25:12 -0000 The following errata report has been submitted for RFC8331, "RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5310 -------------------------------------- Type: Editorial Reported by: Anthony Malizia Section: 2, Figure 1 Original Text ------------- Data_Count=0x84 Data_Count-0x105 Corrected Text -------------- Data_Count=0x104 Data_Count-0x205 Notes ----- In the example described in section 2, the first ANC packet is said to have 4 User_Data_Words, and the second packet is said to have 5 User_Data_Words. The values in Figure 1 for the Data_Count fields do not have the correct parity bits according to the definition of Data_Count described in section 2.1. 4 = 0b0000'0100, with parity bits 0b01'0000'0100 = 0x104 5 = 0b0000'0101, with parity bits 0b10'0000'0101 = 0x205 Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8331 (draft-ietf-payload-rtp-ancillary-14) -------------------------------------- Title : RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data Publication Date : February 2018 Author(s) : T. Edwards Category : PROPOSED STANDARD Source : Audio/Video Transport Payloads Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Wed Mar 28 08:33:52 2018 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 ADDF1120047 for ; Wed, 28 Mar 2018 08:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 P5eRI7vFTjPx for ; Wed, 28 Mar 2018 08:33:48 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA811275AB for ; Wed, 28 Mar 2018 08:33:46 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w2SFXW30056199 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 28 Mar 2018 10:33:33 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D5DA83B8-B1A5-4788-8ABF-73DA701556C2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 28 Mar 2018 10:32:33 -0500 In-Reply-To: <20180328142451.C7395B82180@rfc-editor.org> Cc: Alexey Melnikov , Adam Roach , "Ali C. Begen" , "Roni Even (A)" , amalizia@matrox.com To: thomas.edwards@fox.com, payload@ietf.org References: <20180328142451.C7395B82180@rfc-editor.org> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [payload] [Editorial Errata Reported] RFC8331 (5310) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2018 15:33:51 -0000 --Apple-Mail=_D5DA83B8-B1A5-4788-8ABF-73DA701556C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Thomas and PAYLOAD participants: What do you think; is the errata report correct? Seems like it is = borderline between editorial and technical. Thanks! Ben. > On Mar 28, 2018, at 9:24 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC8331, > "RTP Payload for Society of Motion Picture and Television Engineers = (SMPTE) ST 291-1 Ancillary Data". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5310 >=20 > -------------------------------------- > Type: Editorial > Reported by: Anthony Malizia >=20 > Section: 2, Figure 1 >=20 > Original Text > ------------- > Data_Count=3D0x84 >=20 > Data_Count-0x105 >=20 > Corrected Text > -------------- > Data_Count=3D0x104 >=20 > Data_Count-0x205 >=20 > Notes > ----- > In the example described in section 2, the first ANC packet is said to = have 4 User_Data_Words, and the second packet is said to have 5 = User_Data_Words. The values in Figure 1 for the Data_Count fields do = not have the correct parity bits according to the definition of = Data_Count described in section 2.1. >=20 > 4 =3D 0b0000'0100, with parity bits 0b01'0000'0100 =3D 0x104 >=20 > 5 =3D 0b0000'0101, with parity bits 0b10'0000'0101 =3D 0x205 >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC8331 (draft-ietf-payload-rtp-ancillary-14) > -------------------------------------- > Title : RTP Payload for Society of Motion Picture and = Television Engineers (SMPTE) ST 291-1 Ancillary Data > Publication Date : February 2018 > Author(s) : T. Edwards > Category : PROPOSED STANDARD > Source : Audio/Video Transport Payloads > Area : Applications and Real-Time > Stream : IETF > Verifying Party : IESG --Apple-Mail=_D5DA83B8-B1A5-4788-8ABF-73DA701556C2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlq7tZEACgkQgFZKbJXz 1A3+RRAAlqOnO2o70bhHJXvdchCX78Ip7GqAVtS7exdzPcR5i/Yea1yDNCo/ErYr 26EcB2P7Bc3GqIC3xjqRA+nTRtgdkcjt+2ua5nb0UImXYHWx65KxBVsCHiiTdAkZ L/kIBT/E6lrTCRnEI83Wz8lr3iwaF1ut9uObS3G27B73Ve3rM9ATBITDU/7ubRN0 Y3JHEnpvmAgxZYiIfVPEhTdUK2nvyGxxPHrkQmNMMS3shPNFuzSIvgW4/zmq4OwL csxYznOTBhPNs+Jx+Zm0Xz1RIdsBC6WaIRdS7+iVRxlZ8dQ/kwtTP658zLPpd18x Di7i3BOLBqjg7NxxmX2gQMN1qpK4GyDoXj4u6XBsCeW4aKIXn3ILH1myMHzl1utm CmD34Efr/px2kfX6NmkLpORkJ6DhSKFdN2AQ/eFABo423eegPTehYOzE7XthR+r3 FBmyNMXytS/02NafUBeh4ntO4XwzzUclz9RTqHz3f8lM6yjmn3pEgIYhHNXtE0Ar NnZCjDoIEKFx95/PozPTKdm/rCsXcxZ9p/nhJy/OPkbghI/hBM4hBnj20XHeZHrh mtvx5cqmqjsdYrm6o+n/hQ4L6sn18x3207q18Hf2v6VglaQlOgeV9etLxYIbQTSh u7ETNGtXcNTxA181hkRlur8IXAwSKrcyoR/QqHYzOwRUOSy7H9M= =8RLg -----END PGP SIGNATURE----- --Apple-Mail=_D5DA83B8-B1A5-4788-8ABF-73DA701556C2-- From nobody Thu Mar 29 14:40:56 2018 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 1678F12D7F6 for ; Thu, 29 Mar 2018 14:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=foxgroupinc.onmicrosoft.com 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 9OUsdgyiEruj for ; Thu, 29 Mar 2018 14:40:51 -0700 (PDT) Received: from mx0a-00195501.pphosted.com (mx0b-00195501.pphosted.com [67.231.157.160]) (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 5140D12762F for ; Thu, 29 Mar 2018 14:40:51 -0700 (PDT) Received: from pps.filterd (m0087373.ppops.net [127.0.0.1]) by mx0b-00195501.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2TLebDw029308; Thu, 29 Mar 2018 14:40:41 -0700 Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0053.outbound.protection.outlook.com [207.46.163.53]) by mx0b-00195501.pphosted.com with ESMTP id 2h17mvr6mg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 29 Mar 2018 14:40:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=FoxGroupInc.onmicrosoft.com; s=selector1-fox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=K6tKFRv/Aob7OTwdsHIiGqE5AcvKdjyCqt1WZHU0wEo=; b=gcnGSSzvEwSDSaCf1asu5gqTjAe4Y4C1TliE/LvoqqM94/TZXJAuUL0r1d9bAq9scdH8BBzVXmV4s80IRDzIbe1YaqPQwgFPy1509Jd1swfzInM9ZK/jINi6WvA9WEFTzo9flKHtXwUOajieiT55Z6lbG3/ylcSKp63T0gFx/zs= Received: from MWHPR05MB3056.namprd05.prod.outlook.com (10.173.228.138) by MWHPR05MB3375.namprd05.prod.outlook.com (10.174.175.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.631.5; Thu, 29 Mar 2018 21:40:39 +0000 Received: from MWHPR05MB3056.namprd05.prod.outlook.com ([fe80::a933:1c48:6df6:a9d6]) by MWHPR05MB3056.namprd05.prod.outlook.com ([fe80::a933:1c48:6df6:a9d6%3]) with mapi id 15.20.0631.014; Thu, 29 Mar 2018 21:40:39 +0000 From: Thomas Edwards To: Ben Campbell , "payload@ietf.org" CC: Alexey Melnikov , Adam Roach , "Ali C. Begen" , "Roni Even (A)" , "amalizia@matrox.com" Thread-Topic: [Editorial Errata Reported] RFC8331 (5310) Thread-Index: AQHTxqCYwCvY+oYLWEqU1Qg+awonjaPlxrmAgAGD04A= Date: Thu, 29 Mar 2018 21:40:38 +0000 Message-ID: <57635D0E-277C-491A-9828-45DDA12B966A@foxeg.com> References: <20180328142451.C7395B82180@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-originating-ip: [216.205.246.243] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR05MB3375; 7:lOy3G6RoSbUPyaReYudeeLU+HKsgwSdLQ13V3WDaQmdLBW2M70j/Yp6cgbjTGv55xPRc54uVPX6n/hIGr6JGO9tvhI1+2jmPCYv+BVblJIoajMDMR3TqLI+QB6YrqV2v6vH9jRO7tMBHD7LxbhmCvCRS7nFIl22daApYUfttLMilV/Y4a3Ae4gHuioaSaT7sNNaQMTlVx+eEJnEeW/j9OTjghYG3++2jBij5sZ5Z2b222ZQX2PuwVd8JV2kuGKja; 20:UFciSfVH4m9njAanFB+UxQViBON5M3UTCWSfaCTq174HMsVc0bYAHxYMGTaRrh6nZTtpGpK1bqsUL6NmjRYmtWs8yXn4IyPuU2byMnLzqlXJKUwdM8SaJ1KBbB1m0YjaRTw0AsFupIdZuyTesm8kwn2qdSI6mY7LotusJ/vOuhk= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ecb09195-9009-4498-35db-08d595bdb6c2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MWHPR05MB3375; x-ms-traffictypediagnostic: MWHPR05MB3375: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR05MB3375; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB3375; x-forefront-prvs: 0626C21B10 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(396003)(346002)(366004)(39380400002)(189003)(199004)(486005)(7736002)(316002)(186003)(305945005)(83716003)(26005)(25786009)(3846002)(2906002)(966005)(478600001)(66066001)(72206003)(76176011)(6116002)(2900100001)(82746002)(446003)(476003)(1720100001)(11346002)(486005)(33896004)(8936002)(33656002)(81156014)(5250100002)(110136005)(6512007)(6306002)(105586002)(9686003)(6246003)(54906003)(106356001)(6436002)(99286004)(2501003)(81166006)(102836004)(8676002)(97736004)(229853002)(68736007)(6486002)(36756003)(86362001)(53936002)(8666007)(58126008)(6506007)(3280700002)(3660700001)(14454004)(5660300001)(53546011)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR05MB3375; H:MWHPR05MB3056.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: K/Ztm4NSk3eOmST+mcExb96PfTnYuKW6rMp5KfvHJFDS9BhX5a8XPbxB7M9FJOaTEMusJEFCbhDRneWFK6s5EEvmAQID7ixGq1xQB3rAkT803QqHrPen7vikO05Y0wv11HIqRxAHfnPedxHPnOmkOT1ROsWMbjLhjNlhpNC7xODuzXulEhbxW6bGKEzU2HuwTuqUIbgwq7pYlqhEyb1FHhlGxBb7jvLAVAf6Bxu7aNukx1iIZU79uB7Zw3Ui7bAqJIOWdYOZGkEhDlnHbf4jPrLCu6R8ykMk3lszl3IFkOtR57pAvpC1AVF1hXkLfqVXqnma7T2e/KSJDWQmUc6WN/zgYY8ya0Egm0hkT96+ACvSwlVM6edQ5/kkzOY/ETa1iIbwv2wx/GAhFWsYaeBnEU7ok1Jr2rrG2C3FdgH3ji0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: fox.com X-MS-Exchange-CrossTenant-Network-Message-Id: ecb09195-9009-4498-35db-08d595bdb6c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2018 21:40:38.7989 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3375 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-29_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803290224 Archived-At: Subject: Re: [payload] [Editorial Errata Reported] RFC8331 (5310) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 29 Mar 2018 21:40:54 -0000 SW5kZWVkLCBJIGZhaWxlZCBpbiBwcm9wZXJseSBhZGRpbmcgdGhlIHR3byBwYXJpdHkgYml0cyB0 byB0aGUgRGF0YV9Db3VudCBpbiBGaWd1cmUgMSEgIEFudGhvbnkgaXMgY29ycmVjdC4NCg0KLVRo b21hcw0KDQrvu79PbiAzLzI4LzE4LCA4OjMzIEFNLCAiQmVuIENhbXBiZWxsIiA8YmVuQG5vc3Ry dW0uY29tPiB3cm90ZToNCg0KICAgIEhpIFRob21hcyBhbmQgUEFZTE9BRCBwYXJ0aWNpcGFudHM6 DQogICAgDQogICAgV2hhdCBkbyB5b3UgdGhpbms7IGlzIHRoZSBlcnJhdGEgcmVwb3J0IGNvcnJl Y3Q/IFNlZW1zIGxpa2UgaXQgaXMgYm9yZGVybGluZSBiZXR3ZWVuIGVkaXRvcmlhbCBhbmQgdGVj aG5pY2FsLg0KICAgIA0KICAgIFRoYW5rcyENCiAgICANCiAgICBCZW4uDQogICAgDQogICAgPiBP biBNYXIgMjgsIDIwMTgsIGF0IDk6MjQgQU0sIFJGQyBFcnJhdGEgU3lzdGVtIDxyZmMtZWRpdG9y QHJmYy1lZGl0b3Iub3JnPiB3cm90ZToNCiAgICA+IA0KICAgID4gVGhlIGZvbGxvd2luZyBlcnJh dGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgUkZDODMzMSwNCiAgICA+ICJSVFAgUGF5 bG9hZCBmb3IgU29jaWV0eSBvZiBNb3Rpb24gUGljdHVyZSBhbmQgVGVsZXZpc2lvbiBFbmdpbmVl cnMgKFNNUFRFKSBTVCAyOTEtMSBBbmNpbGxhcnkgRGF0YSIuDQogICAgPiANCiAgICA+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiBZb3UgbWF5IHJldmlldyB0 aGUgcmVwb3J0IGJlbG93IGFuZCBhdDoNCiAgICA+IGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcv ZXJyYXRhL2VpZDUzMTANCiAgICA+IA0KICAgID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCiAgICA+IFR5cGU6IEVkaXRvcmlhbA0KICAgID4gUmVwb3J0ZWQgYnk6IEFu dGhvbnkgTWFsaXppYSA8YW1hbGl6aWFAbWF0cm94LmNvbT4NCiAgICA+IA0KICAgID4gU2VjdGlv bjogMiwgRmlndXJlIDENCiAgICA+IA0KICAgID4gT3JpZ2luYWwgVGV4dA0KICAgID4gLS0tLS0t LS0tLS0tLQ0KICAgID4gRGF0YV9Db3VudD0weDg0DQogICAgPiANCiAgICA+IERhdGFfQ291bnQt MHgxMDUNCiAgICA+IA0KICAgID4gQ29ycmVjdGVkIFRleHQNCiAgICA+IC0tLS0tLS0tLS0tLS0t DQogICAgPiBEYXRhX0NvdW50PTB4MTA0DQogICAgPiANCiAgICA+IERhdGFfQ291bnQtMHgyMDUN CiAgICA+IA0KICAgID4gTm90ZXMNCiAgICA+IC0tLS0tDQogICAgPiBJbiB0aGUgZXhhbXBsZSBk ZXNjcmliZWQgaW4gc2VjdGlvbiAyLCB0aGUgZmlyc3QgQU5DIHBhY2tldCBpcyBzYWlkIHRvIGhh dmUgNCBVc2VyX0RhdGFfV29yZHMsIGFuZCB0aGUgc2Vjb25kIHBhY2tldCBpcyBzYWlkIHRvIGhh dmUgNSBVc2VyX0RhdGFfV29yZHMuICBUaGUgdmFsdWVzIGluIEZpZ3VyZSAxIGZvciB0aGUgRGF0 YV9Db3VudCBmaWVsZHMgZG8gbm90IGhhdmUgdGhlIGNvcnJlY3QgcGFyaXR5IGJpdHMgYWNjb3Jk aW5nIHRvIHRoZSBkZWZpbml0aW9uIG9mIERhdGFfQ291bnQgZGVzY3JpYmVkIGluIHNlY3Rpb24g Mi4xLg0KICAgID4gDQogICAgPiA0ID0gMGIwMDAwJzAxMDAsIHdpdGggcGFyaXR5IGJpdHMgMGIw MScwMDAwJzAxMDAgPSAweDEwNA0KICAgID4gDQogICAgPiA1ID0gMGIwMDAwJzAxMDEsIHdpdGgg cGFyaXR5IGJpdHMgMGIxMCcwMDAwJzAxMDEgPSAweDIwNQ0KICAgID4gDQogICAgPiBJbnN0cnVj dGlvbnM6DQogICAgPiAtLS0tLS0tLS0tLS0tDQogICAgPiBUaGlzIGVycmF0dW0gaXMgY3VycmVu dGx5IHBvc3RlZCBhcyAiUmVwb3J0ZWQiLiBJZiBuZWNlc3NhcnksIHBsZWFzZQ0KICAgID4gdXNl ICJSZXBseSBBbGwiIHRvIGRpc2N1c3Mgd2hldGhlciBpdCBzaG91bGQgYmUgdmVyaWZpZWQgb3IN CiAgICA+IHJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwgdGhlIHZlcmlmeWlu ZyBwYXJ0eQ0KICAgID4gY2FuIGxvZyBpbiB0byBjaGFuZ2UgdGhlIHN0YXR1cyBhbmQgZWRpdCB0 aGUgcmVwb3J0LCBpZiBuZWNlc3NhcnkuDQogICAgPiANCiAgICA+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiBSRkM4MzMxIChkcmFmdC1pZXRmLXBheWxvYWQt cnRwLWFuY2lsbGFyeS0xNCkNCiAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQogICAgPiBUaXRsZSAgICAgICAgICAgICAgIDogUlRQIFBheWxvYWQgZm9yIFNvY2ll dHkgb2YgTW90aW9uIFBpY3R1cmUgYW5kIFRlbGV2aXNpb24gRW5naW5lZXJzIChTTVBURSkgU1Qg MjkxLTEgQW5jaWxsYXJ5IERhdGENCiAgICA+IFB1YmxpY2F0aW9uIERhdGUgICAgOiBGZWJydWFy eSAyMDE4DQogICAgPiBBdXRob3IocykgICAgICAgICAgIDogVC4gRWR3YXJkcw0KICAgID4gQ2F0 ZWdvcnkgICAgICAgICAgICA6IFBST1BPU0VEIFNUQU5EQVJEDQogICAgPiBTb3VyY2UgICAgICAg ICAgICAgIDogQXVkaW8vVmlkZW8gVHJhbnNwb3J0IFBheWxvYWRzDQogICAgPiBBcmVhICAgICAg ICAgICAgICAgIDogQXBwbGljYXRpb25zIGFuZCBSZWFsLVRpbWUNCiAgICA+IFN0cmVhbSAgICAg ICAgICAgICAgOiBJRVRGDQogICAgPiBWZXJpZnlpbmcgUGFydHkgICAgIDogSUVTRw0KICAgIA0K ICAgIA0KDQo= From nobody Thu Mar 29 14:55:40 2018 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 B937C126B6D; Thu, 29 Mar 2018 14:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 bYJmbNHixrDX; Thu, 29 Mar 2018 14:55:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7104124BFA; Thu, 29 Mar 2018 14:55:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 923E6B82102; Thu, 29 Mar 2018 14:55:15 -0700 (PDT) To: amalizia@matrox.com, thomas.edwards@fox.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ben@nostrum.com, iesg@ietf.org, payload@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180329215515.923E6B82102@rfc-editor.org> Date: Thu, 29 Mar 2018 14:55:15 -0700 (PDT) Archived-At: Subject: [payload] [Errata Verified] RFC8331 (5310) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 29 Mar 2018 21:55:39 -0000 The following errata report has been verified for RFC8331, "RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5310 -------------------------------------- Status: Verified Type: Editorial Reported by: Anthony Malizia Date Reported: 2018-03-28 Verified by: Ben Campbell (IESG) Section: 2, Figure 1 Original Text ------------- Data_Count=0x84 Data_Count-0x105 Corrected Text -------------- Data_Count=0x104 Data_Count-0x205 Notes ----- In the example described in section 2, the first ANC packet is said to have 4 User_Data_Words, and the second packet is said to have 5 User_Data_Words. The values in Figure 1 for the Data_Count fields do not have the correct parity bits according to the definition of Data_Count described in section 2.1. 4 = 0b0000'0100, with parity bits 0b01'0000'0100 = 0x104 5 = 0b0000'0101, with parity bits 0b10'0000'0101 = 0x205 -------------------------------------- RFC8331 (draft-ietf-payload-rtp-ancillary-14) -------------------------------------- Title : RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data Publication Date : February 2018 Author(s) : T. Edwards Category : PROPOSED STANDARD Source : Audio/Video Transport Payloads Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Thu Mar 29 14:56:15 2018 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 92F4B127136 for ; Thu, 29 Mar 2018 14:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 0ZsfDxUiXrxn for ; Thu, 29 Mar 2018 14:56:11 -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 BDA3E126B6D for ; Thu, 29 Mar 2018 14:56:11 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w2TLu0dt055735 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 29 Mar 2018 16:56:01 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Message-Id: <8766C0BA-B79D-41EA-A71F-E05BFC6B42D4@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_CC4737E9-A183-4BF1-954A-F3104CACE41F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 29 Mar 2018 16:55:59 -0500 In-Reply-To: <57635D0E-277C-491A-9828-45DDA12B966A@foxeg.com> Cc: "payload@ietf.org" , Alexey Melnikov , Adam Roach , "Ali C. Begen" , "Roni Even (A)" , "amalizia@matrox.com" To: Thomas Edwards References: <20180328142451.C7395B82180@rfc-editor.org> <57635D0E-277C-491A-9828-45DDA12B966A@foxeg.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [payload] [Editorial Errata Reported] RFC8331 (5310) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 29 Mar 2018 21:56:14 -0000 --Apple-Mail=_CC4737E9-A183-4BF1-954A-F3104CACE41F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, I marked it as verified. Ben. > On Mar 29, 2018, at 4:40 PM, Thomas Edwards = wrote: >=20 > Indeed, I failed in properly adding the two parity bits to the = Data_Count in Figure 1! Anthony is correct. >=20 > -Thomas >=20 > =EF=BB=BFOn 3/28/18, 8:33 AM, "Ben Campbell" wrote: >=20 > Hi Thomas and PAYLOAD participants: >=20 > What do you think; is the errata report correct? Seems like it is = borderline between editorial and technical. >=20 > Thanks! >=20 > Ben. >=20 >> On Mar 28, 2018, at 9:24 AM, RFC Errata System = wrote: >>=20 >> The following errata report has been submitted for RFC8331, >> "RTP Payload for Society of Motion Picture and Television Engineers = (SMPTE) ST 291-1 Ancillary Data". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5310 >>=20 >> -------------------------------------- >> Type: Editorial >> Reported by: Anthony Malizia >>=20 >> Section: 2, Figure 1 >>=20 >> Original Text >> ------------- >> Data_Count=3D0x84 >>=20 >> Data_Count-0x105 >>=20 >> Corrected Text >> -------------- >> Data_Count=3D0x104 >>=20 >> Data_Count-0x205 >>=20 >> Notes >> ----- >> In the example described in section 2, the first ANC packet is said = to have 4 User_Data_Words, and the second packet is said to have 5 = User_Data_Words. The values in Figure 1 for the Data_Count fields do = not have the correct parity bits according to the definition of = Data_Count described in section 2.1. >>=20 >> 4 =3D 0b0000'0100, with parity bits 0b01'0000'0100 =3D 0x104 >>=20 >> 5 =3D 0b0000'0101, with parity bits 0b10'0000'0101 =3D 0x205 >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC8331 (draft-ietf-payload-rtp-ancillary-14) >> -------------------------------------- >> Title : RTP Payload for Society of Motion Picture and = Television Engineers (SMPTE) ST 291-1 Ancillary Data >> Publication Date : February 2018 >> Author(s) : T. Edwards >> Category : PROPOSED STANDARD >> Source : Audio/Video Transport Payloads >> Area : Applications and Real-Time >> Stream : IETF >> Verifying Party : IESG >=20 >=20 >=20 --Apple-Mail=_CC4737E9-A183-4BF1-954A-F3104CACE41F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlq9YO8ACgkQgFZKbJXz 1A3cNg//f6eyi9wiw+ecVq6d8pXibwH3n4GSXv1TyS4aC+bGiYDYIo738dJC2DZV NT0MzpiUz2/m/c+sPIq4s9MwWasjHJf9ULJlV/3OTsAl91ywkCAKgKT1ZHjN6IUF /wNFheWPwecqEDdyf2mBq8yeSQHePbTG+hiSoHGnGxhfKT1rQi6t4g+mNbqPvUw2 Zi/K2VJeeCKFNnd5CvjlFnEhrSCPiFXNK/v2bDdANy/krpR34+6oVQlW8HF/oWwc ++zzKK0qAuWFBpJBSJVfFOCn05vJhu0qpWN9StkoQ3m+3thr+Pvjo4WWKu3QSjRn GD4+4D9ZZ3TytL1kWtZuZSWBE6xbZa1uaGmsutlRTKjxduDzqYRA4NMusnaI7uuQ rHbEk6PaLAgv7wVMZx9tRNuCs96pBc3V7w/0mrazfaxxrXzGFlEzfeK1qNcFLmgV 7CjWaDY4459nQQAi4fpB+Ll7UyYprdOrw3R6Rj6XsejqR5OfyUZByhLtUcSSy/2S eLm0MP+S+4yoA5SBl46576X19+19gUuSQUvuRTkpm0vsVkJrazd0D0a89YyJEBR5 mz/AS4Etv7P2l4JKibE9HQEHb3lHO94AlDH8WEWILmRn1xcxR+hFK2wyzce4OabG 34C2vA2SApehcuezTHW+f/acrq9nO1R8biNcyn+UsOtlpxvNWxo= =YkvB -----END PGP SIGNATURE----- --Apple-Mail=_CC4737E9-A183-4BF1-954A-F3104CACE41F--