[AVTCORE] Re: Mohamed Boucadair's Discuss on draft-ietf-avtcore-rtp-v3c-14: (with DISCUSS and COMMENT)

[[e-mail]]

Re-, 

Thanks Lauri.

For the record, with these latest changes, I consider that all my DISCUSS points as closed.

Cheers,
Med

> -----Message d'origine-----
> De : Lauri Ilola (Nokia) <[e-mail]>
> Envoyé : vendredi 16 janvier 2026 13:11
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail]; draft-ietf-avtcore-
> [e-mail]; [e-mail]; [e-mail]
> Objet : RE: Mohamed Boucadair's Discuss on draft-ietf-avtcore-rtp-
> v3c-14: (with DISCUSS and COMMENT)
> 
> 
> Hi Med!
> 
> Thanks for the concrete suggestions. This sounds good to me. Much
> appreciated.
> 
> > [Med] I'm not suggesting to remove that part (as this is needed
> to perform the decoding). My suggestion is that before you dig
> into the description if the fields, you add few sentence that
> basically says:
> 
> > * Some of the fields described here are conditional (that is,
> they may not be present) as a function of the values of some
> relevant parameters.
> > * These parameters are listed in Section X.
> > * These parameters are assumed to be available prior to send
> wire packets.
> 
> > Let me know if this is not clear enough.
> 
> This sounds reasonable to me. A preamble like this can be added.
> This is a good suggestion. We'll add the following text before the
> Figure 4:
> 
> "Some of the fields described here are conditional and their
> presence is indicated through the relevant parameters as defined
> in Section 7.2. These parameters are assumed to be made available
> prior to sending any RTP packets."
> 
> > > [Lauri] This would likely be another implementation specific
> > > decision made independently by the receiver or the sender.
> > > Receiver can choose to quit the stream if the packet loss
> becomes an
> > > issue. At the same time, the sender could decide to drop a
> receiver,
> > > if the reports it receives indicate unacceptably high packet
> loss in
> > > its view.
> 
> > [Med] I ack this may left to an implementation, however, I do
> see a value if these are provided as examples (no
> recommendations).
> 
> We could add the following clarification under Section 8. The text
> is provided as an example without making a recommendation.
> 
> "As an example, both the sender and the receiver may have their
> own definition for an acceptable packet loss rate. In such a case
> the receiver may decide to quit a stream when it finds the packet
> loss rate too high. Similarly the sender may decide to drop a
> receiver when the reports it receives indicate packet loss rates
> that are too high from its perspective. These decisions may be
> made independently either by the receiver and or the sender."
> 
> > > [Med] I may be missing some pieces here but, assuming a
> multicast
> > > distribution tree is in place, loss may happen in parts of the
> > > distribution tree. The sender may not have the full visibility
> of
> > > that distribution.
> >
> > [Lauri] This is an interesting question. I think there may be
> > solutions for this, but these would perhaps go beyond what an
> RTP
> > payload specification would need to cover.
> 
> > [Med] CC should ideally cover both as unicast and multicast
> cases are discussed in the spec, but I think I would be fine if we
> simply state that applicability to multicast case is out of scope.
> Would that be OK with you?
> 
> That sounds reasonable to me. I can add a sentence at the end or
> beginning of CC section:
> 
> "This section only applies for unicast streaming, leaving
> considerations for multicast streaming out of scope."
> 
> Kind Regards,
> -Lauri
> 
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Friday, January 16, 2026 1:32 PM
> To: Lauri Ilola (Nokia) <[e-mail]>; The IESG
> <[e-mail]>
> Cc: [e-mail]; [e-mail]; draft-ietf-avtcore-rtp-
> [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Mohamed Boucadair's Discuss on draft-ietf-avtcore-
> rtp-v3c-14: (with DISCUSS and COMMENT)
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Lauri Ilola (Nokia) <[e-mail]> Envoyé :
> vendredi 16
> > janvier 2026 12:17 À : BOUCADAIR Mohamed INNOV/NET
> > <[e-mail]>; The IESG <[e-mail]> Cc :
> > [e-mail]; [e-mail]; draft-ietf-avtcore-
> > [e-mail]; [e-mail]; [e-mail]
> Objet
> > : RE: Mohamed Boucadair's Discuss on draft-ietf-avtcore-rtp-
> > v3c-14: (with DISCUSS and COMMENT)
> >
> >
> > Hello Med!
> >
> > Please see the responses on the open topics below.
> >
> > >
> > > > Several conditional parameters are accompanied with
> narrative
> > > text such the following:
> > >
> > > > CURRENT:
> > > >   The DONL field, when present, specifies the value of the
> 16-
> > > bit
> > > >   decoding order number of the contained NAL unit.  If
> sprop-
> > > max-don-
> > > >   diff is greater than 0 for any of the RTP streams, the
> DONL
> > > field
> > > >   MUST be present, and the variable DONL for the contained
> NAL
> > > unit is
> > > >   derived as equal to the value of the DONL field.
> > >
> > > > The sprop-max-don-diff parameter is not defined (at this
> > stage)
> > > and it is really hard to follow. This is event exacerbated as
> > there is
> > > not adequate to describe how these parameters are intended to
> be
> > used
> > > and access for encoding/decoding, how this is linked to a
> > session,
> > > etc.
> > >
> > > > Some more words to explain this is needed, IMO.
> > >
> > > I see. Would the following definition help alleviate the
> > concerns:
> > >
> > > "The DONL field, when present, specifies the value of the 16-
> bit
> > > decoding order number of the contained NAL unit. The decoding
> > order
> > > number indicates the order in which the received NAL units
> > should be
> > > reordered to form a bitstream that can be successfully
> decoded.
> > If
> > > sprop-max-don-diff is greater than 0 for any of the RTP
> streams,
> > the
> > > DONL field MUST be present, otherwise the DONL field MUST NOT
> be
> > > present."
> > >
> > > I believe similar update to section 5.4.3. would be needed.
> The
> > > derivation of DONL value is provided in detail in section 5.5.
> >
> > [Med] This is an enhancement, but still the decoding part
> depends on a
> > parameter that is not introduced at this stage of the spec
> > (sprop-max-don-diff). One way to address this is to consider
> including
> > a preamble that first points to these parameters and their
> intended
> > use. Please note that the section with the parameters is not
> clear
> > about the parameters, their scope, whether these are local,
> whether
> > default values are supported (and if so call these out), etc
> >
> > [Lauri] We can of course remove the language related to the
> parameter
> > from the definition. I do feel however that there is value in
> > explaining when this optional field should be present.
> > Explaining that without using the parameter would not perhaps
> serve
> > the reader. What if we add reference to the parameter that would
> take
> > the reader to the parameter in the specification?
> 
> [Med] I'm not suggesting to remove that part (as this is needed to
> perform the decoding). My suggestion is that before you dig into
> the description if the fields, you add few sentence that basically
> says:
> 
> * Some of the fields described here are conditional (that is, they
> may not be present) as a function of the values of some relevant
> parameters.
> * These parameters are listed in Section X.
> * These parameters are assumed to be available prior to send wire
> packets.
> 
> Let me know if this is not clear enough.
> 
> >
> > > > # NUT values and interop
> > >
> > > > CURRENT:
> > > >   The NAL unit type
> > > >   (NUT) for the NAL unit header contained in the RTP payload
> > > header
> > > >   MUST be equal to 56, which falls in the unspecified range
> of
> > > the NAL
> > > >   unit types defined in [ISO.IEC.23090-5].
> > >
> > > > There are several NUT values used in the spec. The reasoning
> > for
> > > picking these values is not clear to me.
> > >
> > > > Also, the above excerpt suggests that this is selected in
> the
> > > spec not in the ISO-IEC specs. Shouldn't this be also
> discussed
> > there
> > > to avoid conflicts? Or that's not a concern?
> > >
> > > Because the RTP payload always starts with the "RTP payload
> > header",
> > > where the NAL unit header of the contained NAL unit is
> exposed,
> > we
> > > need to reserve specific NAL unit type (NUT) values for the
> > > aggregation packet and fragmentation packet that don't
> conflict
> > with
> > > the NAL units types defined in ISO/IEC 23090-5.
> > > ISO/IEC 23090-5 defines NUT values in range [56,63] as
> > "unspecified",
> > > which guarantees that there is no conflict in the V3C NAL unit
> > > bitstream level.
> >
> > [Med] As I don't have access to the base spec, I trust you here.
> I
> > understand that these there is no interoperability concern here
> and
> > that uncoordinated selection of NUT values are not problematic
> from an
> > operational standpoint.
> >
> > [Med] Please let me know if my understand is not OK.
> >
> > [Lauri] You are correct that it would be problematic to allow
> use of
> > any NUT value due to possible conflicts, which is why we decided
> to
> > fix these values. These values will not conflict with the V3C
> NAL unit
> > type values
> >
> 
> [Med] ACK.
> 
> > > > # Congestion control measure
> > >
> > > > CURRENT:
> > > >    If a best-effort service is being used, users of this
> > payload
> > > format
> > > >    MUST monitor packet loss to ensure that the packet loss
> > rate
> > > is
> > > >    within an acceptable range.
> > >
> > > > ## Why is this specific to BE?
> > >
> > > I suppose this would apply for many other cases. In this text
> we
> > only
> > > consider BE however. We could remove the "If a best-effort
> > service is
> > > being used, " from the beginning of the sentence, if needed.
> >
> > > [Med] The text should reflect that. It is really not clear why
> > is this not applicable to other class of services, PDBs.
> >
> > [Lauri] We'll then remove the restriction from the beginning of
> the
> > sentence.
> 
> [Med] Thanks.
> 
> >
> >  The current text is pretty standard boilerplate text for
> > > other NAL-unit based RTP payload specifications such as
> RFC6184
> > and
> > > RFC7798. Let me know what you prefer.
> > >
> > > > ## BTW, if this is BE, how the acceptable rate is known?
> > >
> > > The acceptable packet loss rate should really be use case
> > specific, I
> > > would say. For one use case 1% packet loss may be
> unacceptable,
> > > whereas for others up to 5% could be acceptable.
> >
> > [Med] My question is how that is made known to the endpoint.
> >
> > [Lauri] This would likely be another implementation specific
> decision
> > made independently by the receiver or the sender.
> > Receiver can choose to quit the stream if the packet loss
> becomes an
> > issue. At the same time, the sender could decide to drop a
> receiver,
> > if the reports it receives indicate unacceptably high packet
> loss in
> > its view.
> 
> [Med] I ack this may left to an implementation, however, I do see
> a value if these are provided as examples (no recommendations).
> 
> >
> > > > ## How this is supposed to be monitored for the multicast
> > case?
> > >
> > > It would be the task of the receivers to monitor their packet
> > loss and
> > > report it back to the sender.
> >
> > [Med] I may be missing some pieces here but, assuming a
> multicast
> > distribution tree is in place, loss may happen in parts of the
> > distribution tree. The sender may not have the full visibility
> of that
> > distribution.
> >
> > [Lauri] This is an interesting question. I think there may be
> > solutions for this, but these would perhaps go beyond what an
> RTP
> > payload specification would need to cover.
> 
> [Med] CC should ideally cover both as unicast and multicast cases
> are discussed in the spec, but I think I would be fine if we
> simply state that applicability to multicast case is out of scope.
> Would that be OK with you?
> 
> >
> > Let me know if you have any further questions.
> >
> > Kind Regards,
> > -Lauri
> >
> > -----Original Message-----
> > From: [e-mail]
> <[e-mail]>
> > Sent: Friday, January 16, 2026 10:34 AM
> > To: Lauri Ilola (Nokia) <[e-mail]>; The IESG
> > <[e-mail]>
> > Cc: [e-mail]; [e-mail]; draft-ietf-avtcore-
> rtp-
> > [e-mail]; [e-mail]; [e-mail]
> > Subject: RE: Mohamed Boucadair's Discuss on draft-ietf-avtcore-
> > rtp-v3c-14: (with DISCUSS and COMMENT)
> >
> > Hi Lauri,
> >
> > Thank you for the follow-up.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Lauri Ilola (Nokia) <[e-mail]> Envoyé :
> > mercredi 14
> > > janvier 2026 12:35 À : BOUCADAIR Mohamed INNOV/NET
> > > <[e-mail]>; The IESG <[e-mail]> Cc :
> > > [e-mail]; [e-mail]; draft-ietf-avtcore-
> > > [e-mail]; [e-mail];
> [e-mail]
> > Objet
> > > : RE: Mohamed Boucadair's Discuss on draft-ietf-avtcore-rtp-
> > > v3c-14: (with DISCUSS and COMMENT)
> > >
> > >
> > > Hello Med!
> > >
> > > Thank you for your thorough review and detailed questions. Let
> > me try
> > > to address the DISCUSS first, and I'll come back to you later
> > with the
> > > responses to COMMENTs.
> > >
> > > > It seems the version cited in the document was Withdrawn
> > > (Edition 1,
> > > > 2023). A new version is available: ISO/IEC 23090-12:2025
> > ISO/IEC
> > > 23090-12:2025 - Information technology - Coded representation
> of
> > > immersive media - Part 12: MPEG immersive video Are there
> > > changes/implications that need to be echoed in the current
> spec?
> > > > ## Notes
> > > > ### I'm listing this as a DISCUSS as that reference is not
> > > freely available (at least I couldn't find it) so that I can
> > check the
> > > change logs or similar.
> > >
> > > We should indeed update the reference to the newer edition
> >
> > [Med] ACK
> >
> > , it
> > > seems that the second edition is pretty recent. In terms of
> the
> > > updates in edition two, the primary focus of second edition
> was
> > to
> > > improve coding efficiency by introducing new tools for example
> > for
> > > coding depth values in video frames and defining patch
> margins.
> > It
> > > seems that the changes are limited to: "colourized geometry,
> > capture
> > > device information, patch margins, background views, static
> > background
> > > atlases, support for decoder-side depth estimation, chroma
> > dynamic
> > > range modification, piecewise linear normalized disparity
> > > quantization, and linear depth quantization".
> > >
> > > I went through the second edition and it seems that the high
> > level
> > > data structures, such as the ones referred in this draft,
> remain
> > > unchanged. So in terms of th updates needed, it looks to me
> that
> > > simply updating the reference to the second version would be
> > > sufficient.
> >
> > [Med] Thank you for checking. I consider this point closed.
> >
> > >
> > > > Several conditional parameters are accompanied with
> narrative
> > > text such the following:
> > >
> > > > CURRENT:
> > > >   The DONL field, when present, specifies the value of the
> 16-
> > > bit
> > > >   decoding order number of the contained NAL unit.  If
> sprop-
> > > max-don-
> > > >   diff is greater than 0 for any of the RTP streams, the
> DONL
> > > field
> > > >   MUST be present, and the variable DONL for the contained
> NAL
> > > unit is
> > > >   derived as equal to the value of the DONL field.
> > >
> > > > The sprop-max-don-diff parameter is not defined (at this
> > stage)
> > > and it is really hard to follow. This is event exacerbated as
> > there is
> > > not adequate to describe how these parameters are intended to
> be
> > used
> > > and access for encoding/decoding, how this is linked to a
> > session,
> > > etc.
> > >
> > > > Some more words to explain this is needed, IMO.
> > >
> > > I see. Would the following definition help alleviate the
> > concerns:
> > >
> > > "The DONL field, when present, specifies the value of the 16-
> bit
> > > decoding order number of the contained NAL unit. The decoding
> > order
> > > number indicates the order in which the received NAL units
> > should be
> > > reordered to form a bitstream that can be successfully
> decoded.
> > If
> > > sprop-max-don-diff is greater than 0 for any of the RTP
> streams,
> > the
> > > DONL field MUST be present, otherwise the DONL field MUST NOT
> be
> > > present."
> > >
> > > I believe similar update to section 5.4.3. would be needed.
> The
> > > derivation of DONL value is provided in detail in section 5.5.
> >
> > [Med] This is an enhancement, but still the decoding part
> depends on a
> > parameter that is not introduced at this stage of the spec
> > (sprop-max-don-diff). One way to address this is to consider
> including
> > a preamble that first points to these parameters and their
> intended
> > use. Please note that the section with the parameters is not
> clear
> > about the parameters, their scope, whether these are local,
> whether
> > default values are supported (and if so call these out), etc.
> >
> > >
> > > > # Padding
> > > > Please add a note about the RTP padding in the narrative
> text.
> > >
> > > I can add a text like this at the end of 5.4.2, after the
> Figure
> > 5 in
> > > 5.4.3, and after the Figure 7 in 5.4.4:
> > >
> > > "The presence of the "OPTIONAL RTP padding" is indicated by
> the
> > > padding (P) bit in the RTP header. As defined in {{RFC3550}}
> the
> > last
> > > octet of the padding contains a count of how many padding
> octets
> > > should be ignored, including itself."
> > >
> > > I decided to add the clarification in text rather than as a
> > note,
> > > because of the reference to RFC3550. Let me know if you want
> to
> > > reword.
> >
> > [Med] OK.
> >
> > >
> > > > # F bit
> > >
> > > > CURRENT:
> > > >   The fields in the payload header are set as follows.  The
> F
> > > bit MUST
> > > >   be equal to 0 if the F bit of each aggregated NAL unit is
> > > equal to
> > > >   zero; otherwise, it MUST be equal to 1.
> > >
> > > > In which case this can be set to "1"? 5.3 says that it is
> > always
> > > set to 0.
> > >
> > > Similar comment was raised by Éric Vyncke, hopefully this
> change
> > of
> > > definition in 5.3 would address your question as well.
> > >
> > > "F: the nal_forbidden_zero_bit as specified in [ISO.IEC.23090-
> 5]
> > is
> > > equal to 0. A value equal to 1 indicates that the payload may
> > contain
> > > errors or syntax violations."
> > >
> > > The intention is to remain compatible with other NAL unit
> based
> > > systems that use the F value for the above mentioned reason.
> >
> > [Med] Thank you.
> >
> > >
> > > > # NUT values and interop
> > >
> > > > CURRENT:
> > > >   The NAL unit type
> > > >   (NUT) for the NAL unit header contained in the RTP payload
> > > header
> > > >   MUST be equal to 56, which falls in the unspecified range
> of
> > > the NAL
> > > >   unit types defined in [ISO.IEC.23090-5].
> > >
> > > > There are several NUT values used in the spec. The reasoning
> > for
> > > picking these values is not clear to me.
> > >
> > > > Also, the above excerpt suggests that this is selected in
> the
> > > spec not in the ISO-IEC specs. Shouldn't this be also
> discussed
> > there
> > > to avoid conflicts? Or that's not a concern?
> > >
> > > Because the RTP payload always starts with the "RTP payload
> > header",
> > > where the NAL unit header of the contained NAL unit is
> exposed,
> > we
> > > need to reserve specific NAL unit type (NUT) values for the
> > > aggregation packet and fragmentation packet that don't
> conflict
> > with
> > > the NAL units types defined in ISO/IEC 23090-5.
> > > ISO/IEC 23090-5 defines NUT values in range [56,63] as
> > "unspecified",
> > > which guarantees that there is no conflict in the V3C NAL unit
> > > bitstream level.
> >
> > [Med] As I don't have access to the base spec, I trust you here.
> I
> > understand that these there is no interoperability concern here
> and
> > that uncoordinated selection of NUT values are not problematic
> from an
> > operational standpoint.
> >
> > Please let me know if my understand is not OK.
> >
> > >
> > > > # Congestion control measure
> > >
> > > > CURRENT:
> > > >    If a best-effort service is being used, users of this
> > payload
> > > format
> > > >    MUST monitor packet loss to ensure that the packet loss
> > rate
> > > is
> > > >    within an acceptable range.
> > >
> > > > ## Why is this specific to BE?
> > >
> > > I suppose this would apply for many other cases. In this text
> we
> > only
> > > consider BE however. We could remove the "If a best-effort
> > service is
> > > being used, " from the beginning of the sentence, if needed.
> >
> > [Med] The text should reflect that. It is really not clear why
> is this
> > not applicable to other class of services, PDBs.
> >
> >
> >  The current text is pretty standard boilerplate text for
> > > other NAL-unit based RTP payload specifications such as
> RFC6184
> > and
> > > RFC7798. Let me know what you prefer.
> > >
> > > > ## BTW, if this is BE, how the acceptable rate is known?
> > >
> > > The acceptable packet loss rate should really be use case
> > specific, I
> > > would say. For one use case 1% packet loss may be
> unacceptable,
> > > whereas for others up to 5% could be acceptable.
> >
> > [Med] My question is how that is made known to the endpoint.
> >
> > >
> > > > ## How this is supposed to be monitored for the multicast
> > case?
> > >
> > > It would be the task of the receivers to monitor their packet
> > loss and
> > > report it back to the sender.
> >
> > [Med] I may be missing some pieces here but, assuming a
> multicast
> > distribution tree is in place, loss may happen in parts of the
> > distribution tree. The sender may not have the full visibility
> of that
> > distribution.
> >
> > >
> > > I hope these responses help to address your DISCUSS. Let me
> know
> > if
> > > you would like me to provide more details.
> > >
> > > Kind Regards,
> > > -Lauri
> > >
> > > -----Original Message-----
> > > From: Mohamed Boucadair via Datatracker <[e-mail]>
> > > Sent: Tuesday, January 13, 2026 1:54 PM
> > > To: The IESG <[e-mail]>
> > > Cc: [e-mail]; [e-mail]; draft-ietf-avtcore-
> > rtp-
> > > [e-mail]; [e-mail]; [e-mail]
> > > Subject: Mohamed Boucadair's Discuss on draft-ietf-avtcore-
> rtp-
> > > v3c-14: (with DISCUSS and COMMENT)
> > >
> > >
> > > 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.
> > >
> > >
> > >
> > > Mohamed Boucadair has entered the following ballot position
> for
> > > draft-ietf-avtcore-rtp-v3c-14: Discuss
> > >
> > > When responding, please keep the subject line intact and reply
> > to all
> > > email addresses included in the To and CC lines. (Feel free to
> > cut
> > > this introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> > >
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> fra0
> >
> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C7f36e771eacb4b
> 9497
> >
> f508de54f86adf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639041
> 6231
> >
> 12544473%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL
> jAuM
> >
> DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
> 7C&s
> > data=Qb71clVanEurHFxBe3kvPgVffR3oreNKoVZQlSzz0Fs%3D&reserved=0
> >
> 1.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252F
> &dat
> >
> a=05%7C02%7Clauri.ilola%40nokia.com%7C09592230831a4fcce6a808de54f2
> d51b
> >
> %7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C639041599094006509%7
> CUnk
> >
> nown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlA
> iOiJ
> >
> XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mpHpN
> %2F3
> > fYZEwt0aQsXNnDsznVvgRXZ7bePZCQwwO6ho%3D&reserved=0
> > fra0
> > >
> >
> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cb913a75b8d9646
> > 1578
> > >
> >
> 6308de54f0c013%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639041
> > 5901
> > >
> >
> 52324926%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL
> > jAuM
> > >
> >
> DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
> > 7C&s
> > >
> data=6F4fD8EVkjW0MQEirkb%2FnJ1kRBmd0HkJpZkI6DnEh1c%3D&reserved=0
> > >
> >
> 1.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252F
> > &dat
> > >
> >
> a=05%7C02%7Clauri.ilola%40nokia.com%7Cff63153912d14348ab2b08de54da
> > 3c62
> > >
> >
> %7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C639041493488856799%7
> > CUnk
> > >
> >
> nown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlA
> > iOiJ
> > >
> >
> XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ANB29
> > JbpG
> > > m7OfTD4dhxRHs%2FB7n8s5%2Fa7VFKpitv7PxU%3D&reserved=0
> > >
> >
> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
> %2F&
> >
> data=05%7C02%7Cmohamed.boucadair%40orange.com%7C7f36e771eacb4b9497
> f508
> >
> de54f86adf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390416231
> 1257
> >
> 3138%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM
> DAwM
> >
> CIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s
> data
> > =J3TUGbpdLujDv4OviF8xCj4C%2BWTDbuYex8uz3AYlquU%3D&reserved=0
> >
> data=05%7C02%7Clauri.ilola%40nokia.com%7C09592230831a4fcce6a808de5
> 4f2d
> >
> 51b%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C63904159909404782
> 2%7C
> >
> Unknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIs
> IlAi
> >
> OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rX
> HotM
> > QOsvYiVeKnZZKgxTvGVQ3L46dTRROtdjDCCpg%3D&reserved=0
> > ww.i
> > >
> >
> etf.org%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cb913a75
> > b8d9
> > >
> >
> 64615786308de54f0c013%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7
> > C639
> > >
> >
> 041590152364735%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl
> > YiOi
> > >
> >
> IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0
> > %7C%
> > >
> >
> 7C%7C&sdata=EFxjehM%2B83I4EeMX2CCJrg%2FkYpzjpIItzW5S%2BvlW9Aw%3D&r
> > eser
> > > ved=0%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-
> > > ballot-
> > >
> >
> positions%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C41a66
> > >
> >
> eb33b6c44e7942408de536114a0%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0
> > >
> >
> %7C0%7C639039873589240767%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki
> > >
> >
> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj
> > >
> >
> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=JItYNTrCK5lR%2FSohTx4Iwzf%2FUAJ0JY%2
> > > BAg1NVlr94IA0%3D&reserved=0
> > > for more information about how to handle DISCUSS and COMMENT
> > > positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found
> > > here:
> > >
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> fra0
> >
> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C7f36e771eacb4b
> 9497
> >
> f508de54f86adf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639041
> 6231
> >
> 12589932%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL
> jAuM
> >
> DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
> 7C&s
> >
> data=oLLqNcrIX%2Bb0q%2FLy2TeEGHF8%2B0hDVfWpimGK%2Baay5cE%3D&reserv
> ed=0
> >
> 1.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252F
> &dat
> >
> a=05%7C02%7Clauri.ilola%40nokia.com%7C09592230831a4fcce6a808de54f2
> d51b
> >
> %7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C639041599094082447%7
> CUnk
> >
> nown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlA
> iOiJ
> >
> XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=gGB8W
> Jg6f
> > Jky9ArMXFdXwpWRnYry%2B8TeH1luJfSXTpQ%3D&reserved=0
> > fra0
> > >
> >
> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cb913a75b8d9646
> > 1578
> > >
> >
> 6308de54f0c013%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639041
> > 5901
> > >
> >
> 52389022%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL
> > jAuM
> > >
> >
> DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
> > 7C&s
> > >
> data=uIMPuaUPlOnV5zYjQQRpw%2Fc0qFsNEOBVttFOHNEi6ec%3D&reserved=0
> > >
> >
> 1.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252F
> > &dat
> > >
> >
> a=05%7C02%7Clauri.ilola%40nokia.com%7Cff63153912d14348ab2b08de54da
> > 3c62
> > >
> >
> %7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C639041493488881326%7
> > CUnk
> > >
> >
> nown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlA
> > iOiJ
> > >
> >
> XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7Issi
> > wyfU
> > > Jinanbo%2Ba0NADInx%2BGP%2FNJommAAM0w5jeI%3D&reserved=0
> > > datatracker.ietf.org%2Fdoc%2Fdraft-ietf-avtcore-rtp-
> > >
> >
> v3c%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C41a66eb33b6
> > >
> >
> c44e7942408de536114a0%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7
> > >
> >
> C639039873589289654%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW
> > >
> >
> UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3
> > >
> >
> D%3D%7C0%7C%7C%7C&sdata=WVaxQiHM6jmWGVCFXKIvnzbBmtUesvsD1u8ZOyd0By
> > > w%3D&reserved=0
> > >
> > >
> > >
> > > --------------------------------------------------------------
> --
> > --
> > > ----
> > > DISCUSS:
> > > --------------------------------------------------------------
> --
> > --
> > > ----
> > >
> > > Hi Lauri and Lukasz,
> > >
> > > Thank you for the effort put into this specification.
> > >
> > > Please find below some comments for discussion.
> > >
> > > # Latest ISO.IEC version
> > >
> > > CURRENT:
> > >    [ISO.IEC.23090-12]
> > >               ISO/IEC, "Information technology --- Coded
> > > representation
> > >               of immersive media --- Part 12: MPEG Immersive
> > video
> > >               (MIV)", ISO/IEC 23090-12, 2022,
> > >
> > >
> >
> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Ffra
> >
> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C7f36e771eacb4b
> 9497
> >
> f508de54f86adf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639041
> 6231
> >
> 12606816%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL
> jAuM
> >
> DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
> 7C&s
> > data=E9TH7dFSOpNcNTzT3yOyDVtKjRTeoD3EJ833LFncfSs%3D&reserved=0
> >
> 01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252
> 52&d
> >
> ata=05%7C02%7Clauri.ilola%40nokia.com%7C09592230831a4fcce6a808de54
> f2d5
> >
> 1b%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C639041599094106958
> %7CU
> >
> nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI
> lAiO
> >
> iJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Pdq
> fQCl
> > 1jJhqbcuiMbHIVysK7tSDZbebnO3Q%2Fxwp4H8%3D&reserved=0
> > Ffra
> > >
> >
> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cb913a75b8d9646
> > 1578
> > >
> >
> 6308de54f0c013%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639041
> > 5901
> > >
> >
> 52407170%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL
> > jAuM
> > >
> >
> DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
> > 7C&s
> > >
> data=ARgS8y5AMZq4zlazFVWzntzU9fl4BFZHAN7nkX%2BQ320%3D&reserved=0
> > >
> >
> 01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252
> > 52&d
> > >
> >
> ata=05%7C02%7Clauri.ilola%40nokia.com%7Cff63153912d14348ab2b08de54
> > da3c
> > >
> >
> 62%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C639041493488898565
> > %7CU
> > >
> >
> nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI
> > lAiO
> > >
> >
> iJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=77v
> > qMTO
> > > 5NPEWjK0%2Bzmn5zCq4qtU50pZu9NDuXKEpHuk%3D&reserved=0
> > >
> >
> Fwww.iso.org%2Fstandard%2F79113.html&data=05%7C02%7Cmohamed.boucad
> > >
> >
> air%40orange.com%7C41a66eb33b6c44e7942408de536114a0%7C90c7a20af34b
> > >
> >
> 40bfbc48b9253b6f5d20%7C0%7C0%7C639039873589320373%7CUnknown%7CTWFp
> > >
> >
> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi
> > >
> >
> IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=luo4eY4PHpFr
> > > uVDXNP0ilmXX7x3R5PCI%2FtUcQC3QNfg%3D&reserved=0>.
> > >
> > > It seems the version cited in the document was Withdrawn
> > (Edition 1,
> > > 2023). A new version is available: ISO/IEC 23090-12:2025
> ISO/IEC
> > > 23090-12:2025 - Information technology - Coded representation
> of
> > > immersive media - Part 12:
> > > MPEG immersive video
> > >
> > > Are there changes/implications that need to be echoed in the
> > current
> > > spec?
> > >
> > > ## Notes
> > >
> > > ### I'm listing this as a DISCUSS as that reference is not
> > freely
> > > available (at least I couldn't find it) so that I can check
> the
> > change
> > > logs or similar.
> > >
> > > ### Section 4 is really helpful, especially that the source is
> > not
> > > freely available. Thanks for supplying that one. I assume that
> > the
> > > content of that section was reviewed by other WG participants.
> > >
> > > # Conditional encoding
> > >
> > > Several conditional parameters are accompanied with narrative
> > text
> > > such the
> > > following:
> > >
> > > CURRENT:
> > >    The DONL field, when present, specifies the value of the
> 16-
> > bit
> > >    decoding order number of the contained NAL unit.  If sprop-
> > max-
> > > don-
> > >    diff is greater than 0 for any of the RTP streams, the DONL
> > field
> > >    MUST be present, and the variable DONL for the contained
> NAL
> > unit
> > > is
> > >    derived as equal to the value of the DONL field.
> > >
> > > The sprop-max-don-diff parameter is not defined (at this
> stage)
> > and it
> > > is really hard to follow. This is event exacerbated as there
> is
> > not
> > > adequate to describe how these parameters are intended to be
> > used and
> > > access for encoding/decoding, how this is linked to a session,
> > etc.
> > >
> > > Some more words to explain this is needed, IMO.
> > >
> > > # Padding
> > >
> > > Please add a note about the RTP padding in the narrative text.
> > >
> > > # F bit
> > >
> > > CURRENT:
> > >    The fields in the payload header are set as follows.  The F
> > bit
> > > MUST
> > >    be equal to 0 if the F bit of each aggregated NAL unit is
> > equal to
> > >    zero; otherwise, it MUST be equal to 1.
> > >
> > > In which case this can be set to "1"? 5.3 says that it is
> always
> > set
> > > to 0.
> > >
> > > # NUT values and interop
> > >
> > > CURRENT:
> > >    The NAL unit type
> > >    (NUT) for the NAL unit header contained in the RTP payload
> > header
> > >    MUST be equal to 56, which falls in the unspecified range
> of
> > the
> > > NAL
> > >    unit types defined in [ISO.IEC.23090-5].
> > >
> > > There are several NUT values used in the spec. The reasoning
> for
> > > picking these values is not clear to me.
> > >
> > > Also, the above excerpt suggests that this is selected in the
> > spec not
> > > in the ISO-IEC specs. Shouldn't this be also discussed there
> to
> > avoid
> > > conflicts? Or that's not a concern?
> > >
> > > # Congestion control measure
> > >
> > > CURRENT:
> > >    If a best-effort service is being used, users of this
> payload
> > > format
> > >    MUST monitor packet loss to ensure that the packet loss
> rate
> > is
> > >    within an acceptable range.
> > >
> > > ## Why is this specific to BE?
> > >
> > > ## BTW, if this is BE, how the acceptable rate is known?
> > >
> > > ## How this is supposed to be monitored for the multicast
> case?
> > >
> > >
> > > --------------------------------------------------------------
> --
> > --
> > > ----
> > > COMMENT:
> > > --------------------------------------------------------------
> --
> > --
> > > ----
> > >
> > > # Abstract: Internet Standards
> > >
> > > CURRENT:
> > >    The RTP payload format for V3C video sub-bitstreams is
> > defined by
> > >    relevant Internet Standards for the applicable video codec.
> > >
> > > Internet Standards has a special meaning (e.g.,
> rfc2026#section-
> > > 4.1.3). I think the intent here is "specification" rather that
> a
> > > maturity level.
> > >
> > > # Stale text
> > >
> > > CURRENT:
> > >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
> "SHALL
> > NOT",
> > >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
> "OPTIONAL"
> > in
> > > this
> > >    document are to be interpreted as described in [RFC2119].
> > >
> > >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
> "SHALL
> > NOT",
> > >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
> > "MAY",
> > > and
> > >    "OPTIONAL" in this document are to be interpreted as
> > described in
> > > BCP
> > >    14 [RFC2119] [RFC8174] when, and only when, they appear in
> > all
> > >    capitals, as shown here.
> > >
> > > The first para can be deleted.
> > >
> > > # Normative text in Section 4.3.2
> > >
> > > CURRENT:
> > >    nal_forbidden_zero_bit MUST be equal to 0.
> > >
> > > and
> > >
> > >    nal_temporal_id_plus1 minus 1 indicates a temporal
> identifier
> > for
> > > the
> > >    NAL unit.  The value of nal_temporal_id_plus1 MUST NOT be
> > equal to
> > > 0.
> > >
> > > I suggest to avoid use of normative language here, especially
> > that
> > > this is an informative excerpt, but more importantly, these
> > relevant
> > > MUST NOT for relevant fields defined in the spec are provided
> in
> > > Section 5.
> > >
> > > # Section 5.2: No need to copy/paste fields description from
> > > RFC3550 if the meaning is not adjusted here.
> > >
> > > I suggest to add the following, but only list the set of
> fields
> > that
> > > are customized here:
> > >
> > > NEW:
> > >    Unless contextualized below, the meaning of the fields
> > depicted in
> > >    Figure 2 is the same as in Section 5.1 of [RFC3550].
> > >
> > > # MTU (5.4.3)
> > >
> > > CURRENT:
> > >    However, the total amount of
> > >    data in an AP MUST fit into an IP packet, and the size
> SHOULD
> > be
> > >    chosen so that the resulting IP packet is smaller than the
> > MTU size
> > >    so to avoid IP layer fragmentation.
> > >
> > > Which MTU is referred to here? is it local one? Path MTU?
> Else?
> > >
> > > Shouldn't be a provision to configure that value be supported?
> > >
> > > # Redundant normative language (5.4.4)
> > >
> > > OLD:
> > >    FUs MUST NOT be nested; i.e., an FU MUST NOT contain a
> > >    subset of another FU.
> > >
> > > NEW:
> > >    FUs MUST NOT be nested; i.e., an FU must not contain a
> > >    subset of another FU.
> > >
> > > The second "must not" is not a NEW behavior per se but an
> > explanation
> > > of the first MUST NOT
> > >
> > > # nal_unit_type field
> > >
> > > CURRENT:
> > >    The field FUT MUST be equal to the nal_unit_type field of
> the
> > >    fragmented NAL unit.
> > >
> > > There is no such nal_unit_type field in the packet. I guess
> you
> > meant
> > > NUT. No?
> > >
> > > # Sections 7.1/9.1: IANA considerations
> > >
> > > Any reason why the template is not provided as part of IANA
> > > Considerations section?
> > >
> > > # Section 7.2
> > >
> > > ## Consider adding some text to explain these parameters and
> > their
> > > intended use, can these be controlled by configuration, are
> > these
> > > default values to assume when not present, etc.
> > >
> > > ## Mapping table
> > >
> > > A table that summarizes the parameters with the mapping to
> their
> > > ISO-IEC counterpart would be convenient.
> > >
> > > Hope this helps.
> > >
> > > Cheers,
> > > Med
> > >
> > >
> >
> >
> __________________________________________________________________
> > __________________________________________
> > Ce message et ses pieces jointes peuvent contenir des
> informations
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce
> message
> > par erreur, veuillez le signaler a l'expediteur et le detruire
> ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, Orange decline toute responsabilite si ce message
> a ete
> > altere, deforme ou falsifie.
> > Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should
> not
> > be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the
> sender and
> > delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that
> have
> > been modified, changed or falsified.
> > Thank you.
> 
> __________________________________________________________________
> __________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi que les pieces jointes. Les messages electroniques
> etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie.
> Merci.
> 
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should
> not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender
> and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that
> have been modified, changed or falsified.
> Thank you.

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.