[AVTCORE] Re: [IANA #1434463] expert review for draft-ietf-avtcore-rtp-v3c-12 (sdp-parameters)

["Lauri Ilola (Nokia)" <[e-mail]>]

Hello David,

We've implemented all of the suggestions you mention below in v14 of the draft. Additionally we are working on integrating all of the comments from the telechat. It'll take some time as there was quite a lot of discussion.

There was also a question specific to IANA considerations section in the draft. The IANA considerations in 10.1  reference the media type registration information in 7.1. This practice and structure is similar to RFC6186 and RFC7798. The question was, if IANA prefers this structure over moving all of the media type registration related text directly under IANA considerations section? This would result in quite a large reorganization of data in the specification, but would be doable. I was wondering if you had any preference on the structure? 

Kind Regards,
-Lauri

-----Original Message-----
From: David Dong via RT <[e-mail]> 
Sent: Tuesday, January 27, 2026 1:52 AM
Cc: Lauri Ilola (Nokia) <[e-mail]>; [e-mail]; fandreas=[e-mail]
Subject: [IANA #1434463] expert review for draft-ietf-avtcore-rtp-v3c-12 (sdp-parameters)


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



Hi Lauri,

Just checking in on this update; thank you.

Best regards,

David Dong
IANA Services Sr. Specialist

On Fri Dec 19 06:32:12 2025, [e-mail] wrote:
> Hi Flemming,
>
> Thanks for the suggestion. It will be done. It indeed sounds better as 
> you propose it.
>
> Kind Regards,
> -Lauri
>
> From: Flemming Andreasen (fandreas)
> <fandreas=[e-mail]>
> Sent: Thursday, December 18, 2025 10:30 PM
> To: Lauri Ilola (Nokia) <[e-mail]>; drafts-expert-review- 
> [e-mail]
> Cc: [e-mail]
> Subject: Re: [IANA #1434463] expert review for draft-ietf-avtcore-rtp-
> v3c-12 (sdp-parameters)
>
> Et saa usein sähköpostia osoitteesta
> fandreas=[e-mail]<mailto:fandreas=[e-mail]>.
> Lue, miksi tämä on
> tärkeää<https://aka.ms/LearnAboutSenderIdentification>
>
>
> CAUTION: This is an external email. Please be very careful when 
> clicking links or opening attachments. See the URL nok.it/ext for 
> additional information.
>
>
> Hi Lauri
>
> Thank you for the updates. I would suggest also replacing the phrase 
> "remove media line" with "reject media line" to avoid any ambiguity 
> and for consistency with RFC 3264 terminology. Other than that, 
> everything looks good.
>
> Thanks
>
> -- Flemming
> On 12/17/25 4:40 AM, Lauri Ilola (Nokia) wrote:
> Hi Flemming.
>
> Thank you for the further review. I’ve implemented the following 
> changes to address the remaining comments.
>
> > a) The current text suggests the answerer may simply omit media 
> > lines, however that is not compliant with RFC 3264, which states you 
> > set the port to 0.
>
> Text was updated to clarify that removing the media lines is done by 
> setting the port to zero in the answer. E.g.,
> - * remove media line in which one or more of the parameter values are 
> not supported.
> + * remove media line in which one or more of the parameter values are
> not supported by setting the port to zero in the answer.
>
> > b) The text uses the term "receiver" in a few instances instead of 
> > the proper term "answerer".
>
>
> Proper terminology was updated through-out the Offer and answer 
> considerations section.
>
> > c) The multicast text suggests the answerer could choose a different 
> > payload type. While RFC 3264 does not explicitly state that it MUST 
> > NOT, it is difficult to see how that would work in practice, as 
> > alluded to in RFC 3264 Section 6.2.
>
> I’ve added more restrictions for setting the payload type in the 
> answer, proposing to keep the same payload types. I hope this is more 
> practical.
>
> - * To simplify the handling and matching of these configurations, the 
> same RTP payload type number used in the offer SHOULD also be used in 
> the answer, as specified in {{RFC3264}}. An answer MUST NOT contain a 
> payload type number used in the offer unless the configuration is the 
> same as in the offer.
> + * To simplify the handling and matching of these configurations, the
> same RTP payload type number used in the offer MUST also be used in 
> the answer.
>
> Let me know if you have any further suggestions. All implemented 
> changes are found in PR #46 
> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> hub.com%2Fietf-wg-avtcore%2Fdraft-&data=05%7C02%7Clauri.ilola%40nokia.
> com%7Ca52f84c157a44b53709808de5d35f596%7C5d4717519675428d917b70f44f963
> 0b0%7C0%7C0%7C639050683517326401%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc
> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo
> yfQ%3D%3D%7C0%7C%7C%7C&sdata=0ETO2tOwZy1XV3rVyZxjXsTZD1TfBGUPGFalFLzPe
> %2Fs%3D&reserved=0
> ietf-avtcore-rtp-v3c/pull/46/files)
>
> Kind Regards,
> -Lauri
>
> From: Flemming Andreasen (fandreas)
> <fandreas=[e-mail]><mailto:fandreas=40cisco.com@dmar
> c.ietf.org>
> Sent: Tuesday, December 16, 2025 5:50 PM
> To: [e-mail]<mailto:drafts-expert-review-
> [e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: [AVTCORE] Re: [IANA #1434463] expert review for draft-ietf-
> avtcore-rtp-v3c-12 (sdp-parameters)
>
> Et saa usein sähköpostia osoitteesta
> fandreas=[e-mail]<mailto:fandreas=[e-mail]>.
> Lue, miksi tämä on
> tärkeää<https://aka.ms/LearnAboutSenderIdentification>
>
>
> CAUTION: This is an external email. Please be very careful when 
> clicking links or opening attachments. See the URL nok.it/ext for 
> additional information.
>
>
> Hi David.
>
> My first comment regarding attribute-syntax is resolved.
>
> The offer/answer considerations need a bit more work though:
> a) The current text suggests the answerer may simply omit media lines, 
> however that is not compliant with RFC 3264, which states you set the 
> port to 0.
> b) The text uses the term "receiver" in a few instances instead of the 
> proper term "answerer".
> c) The multicast text suggests the answerer could choose a different 
> payload type. While RFC 3264 does not explicitly state that it MUST 
> NOT, it is difficult to see how that would work in practice, as 
> alluded to in RFC 3264 Section 6.2.
>
> Thanks
>
> -- Flemming
>
>
>
> On 12/9/25 12:53 PM, David Dong via RT wrote:
>
> Hi Flemming,
>
>
>
> Please see the below response from the authors. Could you let us know 
> if this addresses the issues?
>
>
>
> --
>
>
>
>
>
>
>
> Thank you for your suggestions. We have implemented improvements to 
> the specification as you have suggested.
>
>
>
>
>
>
>
> 1.The attribute-syntax should provide additional details on the format 
> of the byte-string. Based on the later example, it seems each entry in 
> the semi-colon separated list follows the fmtp format of "name=value", 
> however it should be clarified here. Also, use of white-space should 
> be clarified.
>
>
>
>
>
>
>
> The specification was changed to:
>
>
>
> ~~~
>
>
>
> v3cfmtp-value = byte-string
>
>
>
> ; Notes:
>
>
>
> ; - The V3C format parameters are V3C media type parameters and
>
>
>
> ;   need to reflect their syntax.
>
>
>
> ; - "byte-string" is as defined in RFC 4566.
>
>
>
> ~~~~
>
>
>
>
>
>
>
> Attribute semantics: "v3cfmtp-value" is a byte-string, as defined in 
> {{RFC4566}}, which MUST contain at least one V3C specific media format 
> parameter as a "parameter=value"-pair as defined in this memo.
> Multiple semicolon-separated V3C media "parameter=value"-pairs MAY be 
> stored in the byte-string to be conveyed by SDP and given unchanged to 
> the media tool that will use this format. White spaces in the byte- 
> string SHALL be ignored.
>
>
>
>
>
>
>
> I hope this addresses your first comment.
>
>
>
>
>
>
>
> 2. The offer/answer considerations are lacking. There needs to be 
> additional procedures describing how the paramter is used in 
> offer/answer, and in particular whether values are declarative (each 
> side declares values independently and if so which direction do they 
> apply to, i.e. send or receieve) or negotiated (i.e. the two sides 
> need to agree on the values, and if so, do they need to be identical).
> For further offer/answer details, refer to RFC 3264. RFC 9071 provides 
> example offer/answer considerations as well.
>
>
>
>
>
>
>
> We’ve updated and clarified the offer answer considerations.
>
>
>
>
>
>
>
> ## Offer and answer considerations
>
>
>
>
>
>
>
> ### Unicast
>
>
>
>
>
>
>
> This section describes the negotiation of unicast streaming using the 
> offer/answer model as described in {{RFC3264}}. V3C coded content 
> consists of an atlas bitstream and one or more video coded bitstreams, 
> together known as V3C components. Atlas and video bitstreams are 
> represented as separate media lines in the SDP.
>
>
>
>
>
>
>
> During the session negotiation the offerer lists all V3C components 
> available and informs the receiver which media lines SHOULD be 
> consumed together. The receiver CAN select V3C components as suggested 
> by the offerer, or select a subset of the V3C components by omitting 
> the undesired media lines in the answer. This allows the receiver to 
> consume a subset of the V3C components in scenarios where it is fully 
> or partially ignorant of the V3C coding scheme.
>
>
>
>
>
>
>
> The following limitations and rules pertaining to the V3C atlas 
> component media configuration apply:
>
>
>
> * The parameters identifying the V3C atlas component media 
> configuration is identified by v3c-ptl-level-idc, v3c-ptl-tier-flag, 
> v3c-ptl-codec-idc, and v3c-ptl-toolset-idc. These media configuration 
> parameters, except level-id, MUST be used symmetrically.
>
>
>
> * Send only properties, identified by sprop-prefix, are considered 
> declarative and SHOULD be omitted in the answers.
>
>
>
>
>
>
>
> The answerer MUST structure its answer according to one of the 
> following two options:
>
>
>
> * maintain all configuration parameters with the values remaining the 
> same as in the offer for the media format (payload type), with the 
> exception that the value of v3c-ptl-level-idc is changeable as long as 
> the highest level indicated by the answer is not higher than that 
> indicated by the offer, or
>
>
>
> * remove media line in which one or more of the parameter values are 
> not supported.
>
>
>
>
>
>
>
> The following limitations and rules pertaining to the V3C video 
> component media configuration apply:
>
>
>
> * The parameters identifying a video coded V3C component media 
> configuration format are according to the respective RTP video payload 
> specification.
>
>
>
>
>
>
>
> The answerer MUST structure its answer according to one of the 
> following two options:
>
>
>
> * maintain all configuration parameters with the values remaining the 
> same as in the offer for the media format (payload type), with the 
> exceptions specified in the respective RTP video payload 
> specification;
>
>
>
> * remove the video coded V3C component media line completely when one 
> or more of the parameter values are not supported.
>
>
>
>
>
>
>
> To simplify handling and matching of these configurations, the same 
> RTP payload type number used in the offer SHOULD also be used in the 
> answer, as specified in {{RFC3264}}.
>
>
>
>
>
>
>
> An example of an offer which only sends V3C content. The following 
> example contains video components as three different versions (H.264, 
> H.265, H.266). Further differences between the alternatives would be 
> signaled as part of the media attribute parameters, as is the practice 
> with regular video streams.
>
>
>
>
>
>
>
> ### Multicast
>
>
>
> For bitstreams being delivered over multicast, the following rules
> apply:
>
>
>
> * The atlas V3C component media configuration is identified by v3c- 
> ptl-level-idc, v3c-ptl-tier-flag, v3c-ptl-codec-idc, and v3c-ptl- 
> toolset-idc. These atlas format configuration parameters MUST be used 
> symmetrically; that is, the answerer MUST either maintain all 
> configuration parameters or remove the media line, including any 
> associated video coded V3C component media lines. This implies that 
> v3c-ptl-level-idc for offer/answer in multicast is not changeable.
>
>
>
> * The video coded V3C component media configuration format is 
> according the respective RTP video payload specification.
>
>
>
> * To simplify the handling and matching of these configurations, the 
> same RTP payload type number used in the offer SHOULD also be used in 
> the answer, as specified in {{RFC3264}}. An answer MUST NOT contain a 
> payload type number used in the offer unless the configuration is the 
> same as in the offer.
>
>
>
> * Parameter sets received MUST be associated with the originating 
> source and MUST only be used in decoding the incoming bitstream from 
> the same source.
>
>
>
>
>
>
>
> I hope the proposed changes will resolve your comments. Let us know if 
> further clarifications are needed. Appreciate the suggestions and 
> feedback.
>
>
>
>
>
>
>
> --
>
>
>
> Best regards,
>
>
>
> David Dong
>
> IANA Services Sr. Specialist
>
>
>
> On Mon Oct 20 20:49:28 2025,
> [e-mail]<mailto:[e-mail]> wrote:
>
> I have reviewed the proposed IANA registration, and I have the
>
> following comments:
>
>
>
> 1) The attribute-syntax should provide additional details on the
>
> format of the byte-string. Based on the later example, it seems each
>
> entry in the semi-colon separated list follows the fmtp format of
>
> "name=value", however it should be clarified here. Also, use of white-
>
> space should be clarified.
>
>
>
> 2) The offer/answer considerations are lacking. There needs to be
>
> additional procedures describing how the paramter is used in
>
> offer/answer, and in particular whether values are declarative (each
>
> side declares values independently and if so which direction do they
>
> apply to, i.e. send or receieve) or negotiated (i.e. the two sides
>
> need to agree on the values, and if so, do they need to be identical).
>
> For further offer/answer details, refer to RFC 3264. RFC 9071 provides
>
> example offer/answer considerations as well.
>
>
>
> Thanks
>
>
>
> -- Flemming
>
>
>
>
>
>
>
> On 10/15/25 8:04 PM, David Dong via RT wrote:
>
>
>
> Dear Flemming Andreasen (cc: avtcore wg),
>
>
>
> As the designated expert for the attribute-name (formerly "att-field")
>
> registry, can you review the proposed registration in draft-ietf-
>
> avtcore-rtp-v3c-12 for us? Please see
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-v3c/
>
>
>
> The due date is October 29th.
>
>
>
> If this is OK, when the IESG approves the document for publication,
>
> we'll make the registration at:
>
>
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> iana.org%2Fassignments%2Fsdp-parameters%2F&data=05%7C02%7Clauri.ilola%
> 40nokia.com%7Ca52f84c157a44b53709808de5d35f596%7C5d4717519675428d917b7
> 0f44f9630b0%7C0%7C0%7C639050683517350005%7CUnknown%7CTWFpbGZsb3d8eyJFb
> XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI
> sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8SWo9yqAQ%2FVW6PUFV9Qn8RM7CgtYhzh
> P5wXb5FzP7eM%3D&reserved=0
>
>
>
> With thanks,
>
>
>
> David Dong
>
> IANA Services Sr. Specialist
>
>
>
>
>
>
>
>