From stewe@stewe.org Mon Oct 2 18:29:41 2023 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BFAC14CE2B; Mon, 2 Oct 2023 18:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steweorg.onmicrosoft.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8XPW8ahnkai; Mon, 2 Oct 2023 18:29:39 -0700 (PDT) Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam02on2122.outbound.protection.outlook.com [40.107.212.122]) (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 939C8C14CF1B; Mon, 2 Oct 2023 18:29:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mF68DB0FxGQD6a8etr+N8Qj5b+pxZ8MzWjbkT5mqQ34qrWriGEgANPXb1gtw99ukIKSFgMk2iGAQlKGLujDAhGZkW2j8TrpFNOF1Qv9A+NU8FuZy9Yy04DwnrjzC/23/zALVXKLeoBUnJq/d0nc/WzwIzwx8x45ulHHLU/3uB+I8f+cfjN/XkGcRTGLQuTlWo+HIExVx0gerQ/W9Rg4n8vX4/AubQW3PuW5h9HqT2osZ5zasCmxnvMzhWR4V0jIROf2SJB3YRwPMmNwRlVrzyrTwfJcz0jtosxXIWVsG/5KGm3Ty6y7ym0/XiCu6oyCipT82meXJdiBe+/5dcwQljw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9lRFIG7W+D03qAeFk2GLWdWdsr2DyhfzbAa+cqXdHYg=; b=n4FcrZFqhI3CkW6PS7xkDTVQ28hXKk4iW+GmaLBOI1Zg+CODwBUTsBCnsgKZsn/zt+xJ5rOKSY/L4t9aUkvpY1rE7YtlvpCksJ152RtwAUCW9wyAsuMqxZl5AoiOcgSmguV50gmFGfqpkPWl6PB57KNHnXZHL4JF2PXSnDaQISCoFYbve3lpYIfqQJMLPvlvg8hI4rnd19iMRJYcyZBDtqId3xa0INqB1hr9ZZVFCQmSZ9xMIeBSVbRKWW3XQp9PkQaYkQTTHQcjvoIVO4/FjNTIhKzLXRIlcGf+xsqEhW1kt1ize4ZnUSKSdpptpWfR4hub0BGvKHg2MBo+KROm3Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=stewe.org; dmarc=pass action=none header.from=stewe.org; dkim=pass header.d=stewe.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=steweorg.onmicrosoft.com; s=selector2-steweorg-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9lRFIG7W+D03qAeFk2GLWdWdsr2DyhfzbAa+cqXdHYg=; b=o/H43yCVX/atPnB4z9vZSW26iDGzxgxhcnioy9o/pVqDn5cjp4tJyINghFkJXriWV0K9n/jEQIFquaZE1nVeMTMBOxZfyywZMJMhUfV5Y0T1umnou0qi68Ut7iTI8g65aWVcXOEWgCqP4Jz8PGkFU3n5VaVUwCFJPFRpHS43B7I= Received: from PH0PR17MB4908.namprd17.prod.outlook.com (2603:10b6:510:d6::23) by PH0PR17MB4879.namprd17.prod.outlook.com (2603:10b6:510:8d::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6813.28; Tue, 3 Oct 2023 01:29:34 +0000 Received: from PH0PR17MB4908.namprd17.prod.outlook.com ([fe80::ffdf:9632:4eca:3ec6]) by PH0PR17MB4908.namprd17.prod.outlook.com ([fe80::ffdf:9632:4eca:3ec6%6]) with mapi id 15.20.6838.024; Tue, 3 Oct 2023 01:29:34 +0000 From: Stephan Wenger To: Marc Blanchet , "art@ietf.org" CC: "avt@ietf.org" , "draft-ietf-avtcore-rtp-evc.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Artart last call review of draft-ietf-avtcore-rtp-evc-05 Thread-Index: AQHZ87RQCGRGQg/Wk0mGFSp+qzocWbA3Q6b6 Date: Tue, 3 Oct 2023 01:29:34 +0000 Message-ID: References: <169608837112.58081.125583710398807954@ietfa.amsl.com> In-Reply-To: <169608837112.58081.125583710398807954@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=stewe.org; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PH0PR17MB4908:EE_|PH0PR17MB4879:EE_ x-ms-office365-filtering-correlation-id: 930bedcc-6ff9-4985-40e9-08dbc3b03310 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LfzdyuuRtc/HunkRwuSzTouG9Tz8WvX3sA//WWe+3c/mD0YAEy4jwaMJaXSE6mEY5cpuISGKYkG1DOQgAy797n2Bqq/tdLuehyXUXpGA5P66zx3pj2NC0F5OIVpbCUnpnLqYi7ngaGqjKyjUfgdNhy4R7/az3ij7GnyBUwfcVqB3eiYQ8Bcm1E7qM7zzwM8Eb7kHJrWYRYeKsE5aTOhhD4DPPEAHYeVL24gOw6peWfa6y8hVBrC7mUXofD+rZ5tOK1pqX7uMvuJBsgXkjlYtm3pSKOo8VgFDYhg1ELmuZXeZXac16HOA/aXq1RWPJ0oppYPUnDJS2nYDn2gJszkVqRdDvpzYVOGikh24Zm02lWMybBPefBMxZfRVNp6TYHQdcWrKIw+gFSiLYEsMDDONCvLsxGXFjJtaSCJykLHg9U2bDjq80tqJG/2kjMjtcnuj9zuvoCvVNLVlt2xRbXVKtS70ubfURoeOOkdV1Ht6sjvMtkx6UeYrFO7cdqvEXznb9mLgIiGXlnqjretVsTh2N9nwKUkbzoPYyXURqgaEDJpvxyZBglSCGjQEOURyulQCAmKdPI6wUC2GpHozrwdkNfDSOmL/BXCLr6zcWbbM5PG+5fv1X8tLzjyfS1QUG+Cw x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR17MB4908.namprd17.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376002)(366004)(136003)(39830400003)(346002)(396003)(230922051799003)(1800799009)(186009)(64100799003)(451199024)(71200400001)(66574015)(38070700005)(38100700002)(478600001)(83380400001)(9686003)(6506007)(55016003)(66899024)(53546011)(7696005)(122000001)(4326008)(33656002)(2906002)(5660300002)(86362001)(52536014)(8676002)(8936002)(54906003)(110136005)(66476007)(66556008)(66946007)(41300700001)(76116006)(66446008)(64756008)(316002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?W2Sraxa9SoTrBFfUGTbN4AujNjorRFrgx/W0rZdB2JY1ClDCiFwbcEw9?= =?Windows-1252?Q?HDq1rmW5Wp8nwIi4dLebde1HDyW4w/kIOAS9lWndHVhAZfLf9nPSApUW?= =?Windows-1252?Q?WkuQE4f1sxFK7K1grY2LD86wMmISHW35yt0rMoM5a+U676HINrTqsI1P?= =?Windows-1252?Q?Hf+zROOxuPAmEu1Aa7Pg0xO+M3V/fIubJS0d1laR3pXzK6ZnYsbOG4m1?= =?Windows-1252?Q?tHjhd2NNMJitvWH67WGa4bnGXd0E/52SfV1oFQTFj55knjInhR8ifo8g?= =?Windows-1252?Q?D3AeuA02iSGKvUUxozuN1PSCQrB4oVdZhBXD5yzmNTM6Obg74Z/um4a8?= =?Windows-1252?Q?LYmkEwVkArdFxijg5MCs0A5BdS0NcwRSqfmD0BefU0UgJSrms26IitpT?= =?Windows-1252?Q?O+DOibyD4pXJRKPb+Ep0NQo7/G/c5GNVn3SFEymgQkLP9RZY+RPONSJD?= =?Windows-1252?Q?DIgkDnZUFimZr7isDy6AeguxAJ8J3SShnkNH6YOZCoLHA116JXS63qRL?= =?Windows-1252?Q?VFEFxkP4qVaBwcHKLUAa0W1uHCTigVwcJqSiCw1yWg7HKXmBTA7/dm6U?= =?Windows-1252?Q?0FquA1tYzxZrzehdDIfYezMtllakluLx9aFWNuN5JDEh6xNDxBbXuzWO?= =?Windows-1252?Q?mGarjf9JSQQAERPrGFv+GW5/JzxJFOMvKaJRHFTDIcf5Uja8wW5zYZ9U?= =?Windows-1252?Q?saGzn1LMa7GwSGwW+eTQPkggPpwgDpB7qyKIVkGGwyeMdGi/MJCMnRwV?= =?Windows-1252?Q?wM76gzgJHzdgrBZe1AYkFJVcGoXR+bt/IKdLziBclkn47mI08juoyUuo?= =?Windows-1252?Q?sjyi8GHtURLnhlainX8O94DzCn+SSgl7/JJz1XAq6GBRlz0LmUkiB2/9?= =?Windows-1252?Q?mfPJkm5VtHaJz1Q03Ldj554ti1YUswo8Hma8+VWuF7KLmhTZyhkXeutk?= =?Windows-1252?Q?VkOT0QKAk5et4JNkBubmNZo7r6yayTz+cYqlpHrFWQGqYTV/NXEXjuE+?= =?Windows-1252?Q?6JDrr8qiROrIzfWAUFzUVSntKYLpUlHeAvo3Zep28VEOgnSwM1wjidvL?= =?Windows-1252?Q?jt9UCWJzZvCRtBYG8EZVe1F/6rf+xouMQhu/3P1HsQqowBjRRtIOKQTt?= =?Windows-1252?Q?YveoJkdQcdIcKAodL4XDH6oB6dC8gtjn2+QkEQoHwQY8Si4Ecw59tlLO?= =?Windows-1252?Q?TtPM2aJ4vJv7krjXfV4D/7gz8IfUxasbH/rpXFZOmQ2G53ZTcCxhy/nT?= =?Windows-1252?Q?QgZYhqkFPImWzGJ+r1w5e6VEmLnIbr9LreP/UuVkXOIYPYPBeroyPUI7?= =?Windows-1252?Q?O9OLIsuTgj0dFPdMjteJsyn2Q8Ynb2WXdjFT2gajUNTthI4vnOvHCb02?= =?Windows-1252?Q?2HLXCafK/iGBMjm5ELSUcTe6+T7iqUzn/nRG86AWXumCsdNXCMkxFc+R?= =?Windows-1252?Q?kzPQYiC+qpYCAtgpJbHzm342VwqDOC5CxCDzyJJBl50LIpHHe3XZI+OE?= =?Windows-1252?Q?yqPyVnOb3uPDo3UII0+DfHQj78oQNpE6IhRS5xNBeXgORpPr08Ffv+26?= =?Windows-1252?Q?P1upGUQJ/C5wcqJfyidihgtczEVcjnAZAm+Tm9wKmU/ZoCGjjd1zmqlJ?= =?Windows-1252?Q?1YxE4dw5CVY9qEYdHwwbx1tU2o5cUrroROeAkmFIV6j1xnl3ddOdAMru?= =?Windows-1252?Q?g7wwYTqhm2jofiTZPi3CevvS00kwgb3BqRb8JoKZdC7VYkuUAZJw7IR4?= =?Windows-1252?Q?z/ER2uGHm4DC5qGP/5/uC5PIdPzs1nZcWzkyydpb?= Content-Type: multipart/alternative; boundary="_000_PH0PR17MB4908F4D41D43D8EF74EC591DAEC4APH0PR17MB4908namp_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR17MB4908.namprd17.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 930bedcc-6ff9-4985-40e9-08dbc3b03310 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2023 01:29:34.1075 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BzH5EBEzUYKBOYCPunQAmW+KUq/IIrqkmDOLuGxDg23o6axraY8EB+lY3vR/MQtd X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR17MB4879 Archived-At: Subject: Re: [AVTCORE] Artart last call review of draft-ietf-avtcore-rtp-evc-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2023 01:29:41 -0000 --_000_PH0PR17MB4908F4D41D43D8EF74EC591DAEC4APH0PR17MB4908namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Marc, all, We appreciate your review. Please see inline. Unless we hear otherwise, w= e will address the issues labelled as =93FIX=94 only in our working copy. Stephan From: Marc Blanchet via Datatracker Date: Saturday, September 30, 2023 at 08:39 To: art@ietf.org Cc: avt@ietf.org , draft-ietf-avtcore-rtp-evc.all@ietf.org , last-call@ietf.org Subject: Artart last call review of draft-ietf-avtcore-rtp-evc-05 Reviewer: Marc Blanchet Review result: Ready with Nits I've been assigned as ART reviewer for this draft. I am no expert in RTP payload, so this review did not verify the validity of the technical soluti= on, if is sound or not, etc., while I did read it with the most diligence I cou= ld. with the i18n eye, since no user/generic strings seems to be used, don't se= e any i18n issues. Comments (not really substantive to the protocol): - section 7.3.2.1: "An implementation SHOULD be able to understand all medi= a type parameters (including all optional media type parameters), even if it doesn't support the functionality related to the parameter. ". This sentenc= e seems weird to me. If a new media type parameter is defined and the implementation is already used in the field, then there is no way that the implementation will be able to understand that parameter. Maybe I=92m not understanding the context here. A comment like this has come up before, but we claim the sentence is clear = to those implementing payload formats. To explain, all parameters defined = in the media type registration are optional. That means, they do not need = to be included in the SDP that=92s being used in negotiation, and senders w= ho don=92t plan to ever send an optional parameter obviously do not have to= implement the sending of it. However, that does not mean that a receiver = is at the same liberty. A receiver really SHOULD implement receiving, and = parsing all optional parameters and ideally have application logic that dec= ides whether it can possibly accept a media stream advertised with a parame= ter that it=92s sending part would never send. It=92s common implementatio= n practice to take shortcuts here, which is why we provide the aforemention= ed guidance. However, nothing seriously breaks if an implementer does not = follow the recommendation, as there are defaults for each optional paramete= r. Worst case, the media would fall back to a basic interoperability mode = (like: small picture size, relatively low frame rate). Also, there are val= id reasons for not implementing the SDP part of the RFC at all, for example= if the session negotiation is conducted using Jingle or something. Theref= ore, SHOULD seems to be right. - section 9: "the RTP packet is RECOMMENDED but NOT REQUIRED based on the thoughts". Should this be rephrased using SHOULD = and MUST NOT to use RFC2119 wording? FIX: RECOMMENDED and REQUIRED are both RFC2119 keywords. We should lower-c= ase the =93NOT=94 in =93NOT REQUIRED=94. Otherwise, I think this is a styl= e question only. - section 9: "For example, it would be a bad and insecure implementation practice to forward any JavaScript a decoder implementation detects to a web browser.". Cannot parse this sentence. Mayb= e it is missing a =AB to =BB or something. Or it is me. FIX: I=92m not an English native speaker, nor is any one of my co-authors. = However, the sentence seems fine. That said, we could rephrase to =93For = example, forwarding all received JavaScript code detected by a decoder impl= ementation to a web-browser unchecked would be a bad and insecure implement= ation practice.=94. Does that work better for you? Note that there are go= od and valid reasons for receiving and forwarding Javascript. I have seen = a prototype doing just that to get a display set up. But we want to guide = away from a na=EFve implementation that find a string in an SEI message, fi= gures out it may be Javascript, and forwards it without having a clear idea= what=92s going on and from whom that Javascript comes and what it is inten= ded to do. - section 10: Congestion Control. is after the Security section. Typically, Security is the last sec= tion before IANA. No big issue here. Maybe RTP docs do ordering differently. Mor= e an observation than real issue. Thanks. In this, like in many other places, we follow the VVC payload that= became an RFC 9328 not a year ago. I don=92t mind moving sections around,= but also do not see a necessity. Nits: - s/MPGEG-2/MPEG-2/ (unless MPGEG is something I don't know) FIX. Typo, will be fixed. - section 7.3.2.1, figure 11: the values "O" and "X" are not used in the ta= ble. maybe remove them? FIX: Leftover from RFC9328, VVC payload format. Will be removed. Orthography suggestions (also depends on UK vs US orthographies): - s/neighbor/neighbour/ - s/signaled/signalled/ - s/signaling/signalling/ - s/behavior/behaviour/ We prefer the US spelling as that is what ISO/IEC is using=97and this paylo= ad format is there to transport data according to an ISO/IEC spec. --_000_PH0PR17MB4908F4D41D43D8EF74EC591DAEC4APH0PR17MB4908namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Marc, all,

We appreciate your rev= iew.  Please see inline.  Unless we hear otherwise, we will addre= ss the issues labelled as =93FIX=94 only in our working copy.

Stephan

 

From: Marc Blanchet via Datatracker <norepl= y@ietf.org>
Date: Saturday, September 30, 2023 at 08:39
To: art@ietf.org <art@ietf.org>
Cc: avt@ietf.org <avt@ietf.org>, draft-ietf-avtcore-rtp-evc.al= l@ietf.org <draft-ietf-avtcore-rtp-evc.all@ietf.org>, last-call@ietf.= org <last-call@ietf.org>
Subject: Artart last call review of draft-ietf-avtcore-rtp-evc-05

Reviewer: Marc Blanchet
Review result: Ready with Nits

I've been assigned as ART reviewer for this draft. I am no expert in RTP payload, so this review did not verify the validity of the technical soluti= on,
if is sound or not, etc., while I did read it with the most diligence I cou= ld.

with the i18n eye, since no user/generic strings seems to be used, don't se= e
any i18n issues.

Comments (not really substantive to the protocol):
- section 7.3.2.1: "An implementation SHOULD be able to understand all= media
type parameters (including all optional media type parameters), even if it<= br> doesn't support the functionality related to the parameter. ". This se= ntence
seems weird to me. If a new media type parameter is defined and the
implementation is already used in the field, then there is no way that the<= br> implementation will be able to understand that parameter. Maybe I=92m not understanding the context here.

A comment like this has come up before, but we claim the sentence = is clear to those implementing payload formats.  To explain, all param= eters defined in the media type registration are optional.  That means, they do not need to be included in the SDP= that=92s being used in negotiation, and senders who don=92t plan to ever s= end an optional parameter obviously do not have to implement the sending of= it.  However, that does not mean that a receiver is at the same liberty.  A receiver really SHOULD implement = receiving, and parsing all optional parameters and ideally have application= logic that decides whether it can possibly accept a media stream advertise= d with a parameter that it=92s sending part would never send.  It=92s common implementation practice to take= shortcuts here, which is why we provide the aforementioned guidance. = However, nothing seriously breaks if an implementer does not follow the re= commendation, as there are defaults for each optional parameter.  Worst case, the media would fall back to a basic= interoperability mode (like: small picture size, relatively low frame rate= ).  Also, there are valid reasons for not implementing the SDP part of= the RFC at all, for example if the session negotiation is conducted using Jingle or something.  Therefore, SHOUL= D seems to be right.

- section 9: "the RTP packet is RECOMMENDED but
NOT REQUIRED based on the thoughts". Should this be rephrased using SH= OULD and
MUST NOT to use RFC2119 wording?

FIX: RECOMMENDED and REQUIRED are both RFC2119 keywords.  We= should lower-case the =93NOT=94 in =93NOT REQUIRED=94.  Otherwise, I think this is a style question only.

- section 9: "For example, it would be a bad
and insecure implementation practice to forward any JavaScript a decoder implementation detects to a web browser.". Cannot parse this sentence.= Maybe it
is missing a =AB to =BB or something. Or it is me.

FIX: I=92m not an English native speaker, nor is any one of my co= -authors.  However, the sentence seems fine.  That said, we could rephrase to =93For example, forwarding all received Ja= vaScript code detected by a decoder implementation to a web-browser uncheck= ed would be a bad and insecure implementation practice.=94.  Does that= work better for you?  Note that there are good and valid reasons for receiving and forwarding Javascript.  I ha= ve seen a prototype doing just that to get a display set up.  But we w= ant to guide away from a na=EFve implementation that find a string in an SE= I message, figures out it may be Javascript, and forwards it without having a clear idea what=92s going on and from who= m that Javascript comes and what it is intended to do.

- section 10: Congestion
Control. is after the Security section. Typically, Security is the last sec= tion
before IANA. No big issue here. Maybe RTP docs do ordering differently. Mor= e an
observation than real issue.

Thanks.  In this, like in many other places, we follow the VV= C payload that became an RFC 9328 not a year ago.  I don=92t mind movi= ng sections around, but also do not see a necessity.


Nits:
- s/MPGEG-2/MPEG-2/ (unless MPGEG is something I don't know)

FIX.  Typo, will be fixed.


- section 7.3.2.1, figure 11: the values "O" and "X" ar= e not used in the table.
maybe remove them?

FIX: Leftover from RFC9328, VVC payload format.  Will be rem= oved.



Orthography suggestions (also depends on UK vs US orthographies):
- s/neighbor/neighbour/
- s/signaled/signalled/
- s/signaling/signalling/
- s/behavior/behaviour/

We prefer the US spelling as that is what ISO/IEC is using=97and t= his payload format is there to transport data according to an ISO/IEC spec.=



--_000_PH0PR17MB4908F4D41D43D8EF74EC591DAEC4APH0PR17MB4908namp_--