Dear Sandy,
We have reviewed the updated document and everything looks good to us.
On behalf of ther authors, I can approve the RFC for publication.
Thank you!
Sincerely,
Youngkwon
On Fri, Feb 6, 2026, 08:55 Sandy Ginoza <[email protected]>
wrote:
Hi Youngkwon,
The document has been updated and the files are available here:
https://www.rfc-editor.org/authors/rfc9924.xml
https://www.rfc-editor.org/authors/rfc9924.txt
https://www.rfc-editor.org/authors/rfc9924.pdf
https://www.rfc-editor.org/authors/rfc9924.html
Diffs of most recent updates only:
https://www.rfc-editor.org/authors/rfc9924-lastdiff.html
https://www.rfc-editor.org/authors/rfc9924-lastrfcdiff.html (side
by side)
AUTH48 diffs:
https://www.rfc-editor.org/authors/rfc9924-auth48diff.html
https://www.rfc-editor.org/authors/rfc9924-auth48rfcdiff.html
(side by side)
Comprehensive diffs:
https://www.rfc-editor.org/authors/rfc9924-diff.html
https://www.rfc-editor.org/authors/rfc9924-rfcdiff.html (side by side)
Please review and let us know if any additional updates are needed
or if you approve the RFC for publication.
Thank you,
Sandy Ginoza
RFC Production Center
> On Feb 5, 2026, at 8:04 PM, Youngkwon Lim <[email protected]>
wrote:
>
> Dear Sandy,
>
> Thank you for the quick response. We have reviewed the new
changes and they are all looking good. During the final review, we
have identified several additional typos. Please see attached file
with corrections.
>
> Sincerely,
> Youngkwon
>
> On Thu, Feb 5, 2026, 16:04 Sandy Ginoza
<[email protected]> wrote:
> Hi Youngkwon, Eliot*,
>
> * Eliot - please review the updates and let us know if you have
any concerns.
>
> Youngkwon, thank you for your thorough reply and for updating
the XML! We made a few additional changes (e.g., removed “version
of this document” in additional places), so please be sure to
review the updates carefully and let us know if any further
changes are needed.
>
> The files here available here:
> https://www.rfc-editor.org/authors/rfc9924.xml
> https://www.rfc-editor.org/authors/rfc9924.txt
> https://www.rfc-editor.org/authors/rfc9924.pdf
> https://www.rfc-editor.org/authors/rfc9924.html
>
> AUTH48 diffs (highlights updates since entering AUTH48):
> https://www.rfc-editor.org/authors/rfc9924-auth48diff.html
> https://www.rfc-editor.org/authors/rfc9924-auth48rfcdiff.html
(side by side)
>
> Comprehensive diffs:
> https://www.rfc-editor.org/authors/rfc9924-diff.html
> https://www.rfc-editor.org/authors/rfc9924-rfcdiff.html (side by
side)
>
> Thank you,
> Sandy Ginoza
> RFC Production Center
>
>
>
> > On Feb 5, 2026, at 11:18 AM, Youngkwon Lim
<[email protected]> wrote:
> >
> > Dear Sandy,
> >
> > I have reviewed your comments. They are really helpful. I have
disposed all of them. Please see the comments in red below. I have
made changes to XML file and created PDF and DIFF ast attached so
that I can review the version after update.
> >
> >
> >
> > 1) <!-- [rfced] Does "but between transformed values" mean
"but with
> > prediction between transformed values"? Please clarify.
> > Agree with the suggested text
> >
> > Original:
> > * Intra frame coding without prediction between pixel
values but
> > between transformed values for low delay encoding;
> > -->
> >
> > * Intra frame coding without prediction between pixel
values but with prediction
> > between transformed values for low delay encoding;
> >
> >
> >
> > 2) <!-- [rfced] For clarity, may this text be updated as follows?
> >
> > Agree with the suggested text
> >
> > Original:
> > * Multiple decoding and re-encoding without severe visual
quality
> > degradation; and
> >
> > -->
> >
> > * the ability to decode and re-encode multiple times
without severe
> > visual quality degradation; and
> >
> >
> >
> > 3) <!-- [rfced] We do not believe we see "I" used in this
manner, though we
> > do see instances of "i". Please review and let us know if "I"
should be
> > removed or if other changes are needed.
> >
> > “I” can be removed. “i” in section 3.2.1 and 5.3.7 are array
index. They can stay unchanged.
> >
> >
> > Original Section 2.2:
> > * I: intra
> >
> > Original Section 3.2.1:
> > * sum (i=x, y, f(i)) : a summation of f(i) with i taking
all integer
> > values from x up to and including y
> >
> > Original Section 5.3.7:
> > The array index i specifies an indicator for the color
> > component; ...
> > -->
> >
> >
> > 4) <!-- [rfced] For clarity, may we update the text as
follows? If this is
> > incorrect, please clarify what is following widely used
industry practices.
> > Or is the exception per widely used industry practices?
> > The operators in Sections 3.2.1 and 3.2.2 are the exceptions
from C programming language. Updated text proposed.
> >
> > Original:
> > The operators and the order of precedence are the same as
used in the
> > C programming language [ISO9899], with the exception of the
operators
> > described in the Section 3.2.1 and Section 3.2.2 following
widely
> > used industry practices for video codecs.
> >
> > Perhaps:
> > Following widely used industry practices for video codecs,
the operators
> > and the order of precedence are the same as used in the C
programming
> > language [ISO9899], with the exception of the operators
described in the
> > Sections 3.2.1 and 3.2.2.
> > -->
> > The operators and the order of precedence are the same as
used in the
> > C programming language [ISO9899]. However, there are some
exceptions described in the
> > Sections 3.2.1 and 3.2.2, which follows widely
> >
> > used industry practices for video codecs.
> >
> >
> > 5) <!-- [rfced] Should "square parentheses" be "square brackets"?
> > In our understanding both square parentheses and square
brackets refers “[“ and “]”. We can change square parentheses to
square brackets.
> >
> >
> >
> > Original:
> > Square parentheses are used for the indexing
> > of arrays.
> > -->
> > Square brackets are used for the indexing
> > of arrays.
> >
> > 6) <!-- [rfced] We are having trouble parsing "depending on
the Chroma
> > format sampling structure" - what is depending on that structure?
> > The values of the variables depends on the chroma format and
the chroma format is signaled by the syntax element chroma_format_idc.
> >
> >
> >
> > Original:
> > The variables SubWidthC, SubHeightC and NumComps are
specified in
> > Table 2, depending on the chroma format sampling structure,
which is
> > specified through chroma_format_idc.
> >
> > Perhaps:
> > The variables SubWidthC, SubHeightC, and NumComps are
specified in
> > Table 2, according to the chroma format sampling structure,
which is
> > specified through chroma_format_idc.
> > -->
> > The values of the variables SubWidthC, SubHeightC and
NumComps depends on the chroma format sampling structure as
specified in
> > Table 2. The chroma format sampling structure is signaled
through chroma_format_idc.
> >
> >
> >
> > 7) <!-- [rfced] Is "1D" needed here, as section 4.4.1
indicates that the
> > zig-zag process converts a 2D array into a 1D array?
Simplifying the
> > sentence improves readability.
> >
> > Agree with the suggestion.
> >
> > Original:
> > * The variable forwardScan is derived by invoking zig-zag
scan order
> > 1D array initialization process as specified in Section
4.4.1 with
> > input parameters blkWidth and blkHeight.
> >
> > Perhaps:
> > * The variable forwardScan is derived by invoking the
zig-zag scan
> > order process as specified in Section 4.4.1 with
> > input parameters blkWidth and blkHeight.
> > -->
> >
> > * The variable forwardScan is derived by invoking the
zig-zag scan
> > order initialization process as specified in Section
4.4.1 with
> >
> > input parameters blkWidth and blkHeight.
> >
> >
> >
> > 8) <!-- [rfced] For readability, may we update this sentence
as follows?
> > Agree with the suggestion.
> >
> >
> > Original:
> > The APV bitstream is described in this document using
syntax code
> > based on the C programming language [ISO9899] and uses its
if/else,
> > while, and for keywords as well as functions defined within
this
> > document.
> >
> > Perhaps:
> > The APV bitstream is described using syntax code
> > based on the C programming language [ISO9899] - including
use of the
> > keywords if/else, while, and for - as well as functions
defined within
> > this document.
> > -->
> > The APV bitstream is described using syntax code
> > based on the C programming language [ISO9899] - including
use of the
> > keywords if/else, while, and for - as well as functions
defined within
> > this document.
> >
> > 9) <!-- [rfced] Can "of this version of the document" be
dropped in
> > multiple places, since section references are assumed to be in
this
> > document (unless specified otherwise) and because the HTML and
PDF link to
> > the relevant sections of the given document? For example:
> > Agree with the suggestion. It was a kind of habit to
mention ‘this version’ to make the document future proof. As there
will be no versioning of RFC, it will be fine to remove such phrase.
> >
> >
> > Original Section 5.3.3:
> > * reserved_zero_8bits
> >
> > MUST be equal to 0 in bitstreams conforming to the profiles
> > specified in Section 9 of this version of document.
Values of
> > reserved_zero_8bits greater than 0 are reserved for
future use.
> > Decoders conforming to the profiles specified in Section
9 of this
> > version of document MUST ignore PBU with values of
> > reserved_zero_8bits greater than 0.
> > --> MUST be equal to 0 in bitstreams conforming to the
profiles
> > specified in Section 9. Values of
> >
> > reserved_zero_8bits greater than 0 are reserved for
future use.
> > Decoders conforming to the profiles specified in Section
9 MUST ignore PBU with values of
> > reserved_zero_8bits greater than 0.
> >
> >
> >
> > Original Section 5.3.5:
> > * reserved_zero_8bits
> >
> > MUST be equal to 0 in bitstreams conforming to the profiles
> > specified in Section 9 of this version of document.
Values of
> > reserved_zero_8bits greater than 0 are reserved for
future use.
> > Decoders conforming to the profiles specified in Section
9 of this
> > version of document MUST ignore PBU with values of
> > reserved_zero_8bits greater than 0.
> > -->
> > MUST be equal to 0 in bitstreams conforming to the profiles
> > specified in Section 9. Values of
> >
> > reserved_zero_8bits greater than 0 are reserved for
future use.
> > Decoders conforming to the profiles specified in Section
9 MUST ignore PBU with values of
> > reserved_zero_8bits greater than 0.
> >
> > 10) <!-- [rfced] We are trying to draw a more clear
connection between the
> > text before and after the semicolon. Please consider whether
the suggested
> > text conveys the intended meaning. Otherwise, please clarify.
> >
> > Note that this text appears multiple times; we will update all
similar instances based on the outcome of this discussion.
> >
> > The sentence tries to say that if i==0 it is Y, if i==1 it is
Cb, and if i==2 it is Cr. I have proposed revision to make it clearer.
> >
> > Original:
> > The array index i specifies an indicator for the color
> > component; when chroma_format_idc is equal to 2 or 3, 0
for Y, 1
> > for Cb and 2 for Cr.
> >
> > Perhaps:
> > The array index i specifies an indicator for the color
> > component when chroma_format_idc is equal to 2 or 3, Y is 0,
> > Cb is 1, and CR is 2.
> > -->
> > The array index i specifies an indicator for the color
> > component; when chroma_format_idc is equal to 2 or 3,
the value of the index i is equal to 0 for Y component, 1
> >
> > for Cb and 2 for Cr.
> >
> >
> > 11) <!-- [rfced] Please confirm that no additional explanatory
text is
> > needed after Figure 21.
> >
> > A sentence describing the basic function of the code can be added.
> >
> > --> The tile_data() syntax calculates the location of the
macroblocks belong to each tile and collect them.
> >
> >
> >
> > 12) <!-- [rfced] How may we expand "DC"? Differential
coding? Will it be
> > understood by readers without expansion?
> >
> > In signal processing, DC refers mean value of the waveform.
The term originally came from direct current. Normally it is not
expanded. (DC bias - Wikipedia)
> >
> >
> > Original:
> > * abs_dc_coeff_diff
> >
> > specifies the absolute value of the difference between
the current
> > DC transform coefficient level and PrevDC.
> > -->
> >
> >
> > 13) <!-- [rfced] "It is the requirement of bitstream
conformance" is a bit
> > awkward to read. Please consider whether the suggested update
is correct.
> > Otherwise, please clarify.
> >
> > The phrase describes the requirements to the bitstream
conforming to this document. Please see the revised text below.
> >
> > Original:
> > It is the requirement of bitstream conformance that
> > the coded tiles of the frame MUST contain tile data for
every MB
> > of the frame, such that the division of the frame into
tiles and
> > the division of the tiles into MBs each forms a
partitioning of
> > the frame.
> >
> > Perhaps:
> > For conforming bitstreams, the coded tiles of the frame
MUST contain
> > tile data for every MB
> > of the frame, such that the division of the frame into
tiles and
> > the division of the tiles into MBs each forms a
partitioning of
> > the frame.
> > -->
> > For the bitstreams conforming to this document, the
coded tiles of the frame MUST contain
> > tile data for every MB
> > of the frame, such that the division of the frame into
tiles and
> > the division of the tiles into MBs form a partitioning of
> > the frame.
> >
> > 14) <!-- [rfced] Please clarify "(when chroma_format_idc is
equal to 2 or
> > 3, Y, Cb, and Cr)." Perhaps "(when chroma_format_idc is equal
to 2 or 3,
> > and Y, Cb, and Cr are specified)"?
> >
> > The phrase tries to say that the three components, Y
component, Cb component and Cr component are reconstructed. Please
see the revised text below.
> >
> > Original:
> > Outputs of this process are the
> > reconstructed samples of all the NumComps color components
(when
> > chroma_format_idc is equal to 2 or 3, Y, Cb, and Cr) for
the current
> > MB.
> >
> > -->
> > Outputs of this process are the reconstructed samples of all
color components. The total number of color components is
indicated by the value of the NumComps for the current MB. For
example, when chroma_format_idc is equal to 2 or 3, the value of
NumComps is equal to 3 and three components, Y component, Cb
component, and Cr component, are reconstructed
> >
> >
> > Similarly, please let us know how/if mention of Cb and Cr may
be clarified
> > here as well?
> >
> > Color components are ordered as Y, Cb and Cr. So, the first
component is Y, the 2nd component is Cb and the 3rd component is
Cr. Please see the revised text below.
> >
> >
> > Original:
> > * When chroma_format_idc is not equal to 0, let
recSamples[1] be a
> > (MbWidthC)x(MbHeightC) array of the reconstructed
samples of the
> > second color component (when chroma_format_idc is equal
to 2 or 3,
> > Cb).
> >
> > --> * When chroma_format_idc is not equal to 0, let
recSamples[1] be a
> >
> > (MbWidthC)x(MbHeightC) array of the reconstructed
samples of the
> > second color component. For example, when
chroma_format_idc is equal to 2 or 3,
> > recSamples[1] is Cb component.
> >
> >
> > ...
> >
> > * When chroma_format_idc is not equal to 0, let
recSamples[2] be a
> > (MbWidthC)x(MbHeightC) array of the reconstructed
samples of the
> > third color component(when chroma_format_idc is equal to
2 or 3,
> > Cr).
> >
> >
> > -->
> > * When chroma_format_idc is not equal to 0, let recSamples[2]
be a
> > (MbWidthC)x(MbHeightC) array of the reconstructed
samples of the
> > third color component. For example, when
chroma_format_idc is equal to 2 or 3,
> > recSamples[2] is Cr component.
> >
> >
> >
> > 15) <!-- [rfced] Section 6.2: Is there text missing after
these bullets?
> > Nothing appears after "the following applies." Also, the
formatting here
> > looks odd. Please review and let us know how the text may be
updated.
> > I have corrected nesting order and indentations of the section
6.2.
> >
> > * For yIdx = 0..numBlkY - 1, the following applies:
> >
> > o For xIdx = 0..numBlkX - 1, the following applies:
> > -->
> >
> >
> > 16) <!-- [rfced] Should the last 3 bulleted items be regular
text (i.e.,
> > not part of the bulleted list)?
> > I have corrected nesting order and indentations of the section
6.3.2.2.
> >
> >
> >
> > 6.3.2.2. Transformation process
> >
> > Inputs to this process are:
> >
> > * a variable nTbS specifying the sample size of scaled
transform
> > coefficients, and
> >
> > * a list of scaled transform coefficients x with elements
x[j], with
> > j = 0..(nTbS - 1).
> >
> > * Output of this process is the list of transformed
samples y with
> > elements y[i], with i = 0..(nTbS - 1).
> >
> > * The transformation matrix derivation process as specified in
> > Section 6.3.2.3. invoked with the transform size nTbS as
input,
> > and the transformation matrix transMatrix as output.
> >
> > * The list of transformed samples y[i] with i = 0..(nTbS -
1) is
> > derived as follows:
> >
> > y[i] = sum(j = 0, nTbS - 1, transMatrix[i][j] * x[j])
> > -->
> >
> >
> > 17) <!-- [rfced] Please confirm that no additional explanatory
text is
> > needed after Figure 28. -->
> >
> > added one sentence.
> >
> > 18) <!-- [rfced] Will readers be familiar with CIE 1931?
Please consider
> > whether a reference should be added. Note that "CIE 1931" is
mentioned 4
> > times. If you would like to add a reference, please provide
the reference
> > entry.
> >
> > Added the reference to ISO specification specifying CIE 1931.
> >
> >
> > Original:
> > * primary_chromaticity_x[i]
> >
> > specifies a 0.16 fixed-point format of X chromaticity
coordinate
> > of mastering display as defined by CIE 1931, where i =
0, 1, 2
> > specifies Red, Green, Blue respectively.
> > -->
> >
> >
> > 19) <!-- [rfced] Please note that we expanded UUID as
"Universally Unique
> > Identifier." Please let us know if any corrections are needed.
> > OK
> >
> > Original:
> > * uuid
> >
> > MUST be a 128-bit value specified as a generated UUID
according to
> > the procedures specified in [RFC9562].
> > -->
> >
> >
> > 20) <!-- [rfced] We are having trouble parsing this sentence.
Perhaps "to
> > specifically create different sets of constraints" is intended?
> >
> > sentence corrected.
> >
> >
> >
> > Original:
> > For example, a certain level L and a certain band
> > B can be combined with either profile X or profile Y to
specifically
> > different set of constraints.
> > -->
> > For example, a certain level L and a certain band B can be
combined with either profile X or profile Y to specifically define
two different set of constraints.
> >
> > 21) <!-- [rfced] This sentence appears many times in this
document. May we
> > update it as follows?
> >
> > Updated with new sentence.
> >
> >
> > Original:
> > Any levels and bands constraints specified in Section 9.4
MUST be
> > fulfilled.
> >
> > Perhaps:
> > Any levels and bands MUST adhere to the constraints
specified in
> > Section 9.4.
> > -->
> > Coded frames conforming to the 422-10 profile
<bcp14>MUST</bcp14> also conform to any levels and bands
constraints specified in Section 9.4.
> >
> >
> > 22) <!-- [rfced] Is "level B" correct, as opposed to "band
B"? Note that
> > "level B" appears multiple times.
> >
> > Yes, it must be “band B” I have changed all.
> >
> >
> > * The coded frame is indicated to conform to a band (by a
specific
> > value of band_idc) that is lower than or equal to level B.
> > -->
> >
> >
> > 23) <!-- [rfced] We have updated the format of the header row
of table 4 so
> > it fits within the line-length limitiation. Please review
carefully and
> > let us know if and adjustments are needed or if you have other
suggestions
> > for how it can be rendered.
> > -->
> > OK
> >
> >
> > 24) <!-- [rfced] "no read" can be difficult to parse. Perhaps
this can be
> > reworded?
> >
> > Original:
> > The implementation MUST ensure that no read outside
> > allocated and initialized memory occurs.
> >
> > A is OK.
> >
> >
> > Perhaps A:
> > The implementation MUST ensure that any data outside
> > of the allocated and initialized memory cannot be read.
> >
> > Perhaps B:
> > The implementation MUST ensure that there is no
> > data outside of the allocated and initialized memory.
> > -->
> >
> >
> > 25) <!-- [rfced] [ISO9899] Please review.
> > This reference currently points to a withdrawn version of
ISO/IEC 9899:
> > https://www.iso.org/standard/74528.html.
> > The most current version of this reference is ISO/IEC 9899:2024.
> >
> > Should this reference be updated to point to the most current
version?
> >
> > YES!
> >
> >
> > Current:
> > [ISO9899] ISO/IEC, "Information technology - Programming
languages -
> > C", ISO/IEC 9899:2018, 2018,
> > <https://www.iso.org/standard/74528.html>.
> > -->
> >
> >
> > 26) <!-- [rfced] [CEA-861.3] Please review.
> > CEA-861.3 appears to have been placed in "Historical" status (see:
> > https://webstore.ansi.org/standards/cea/cea8612015-1528168).
The most
> > current version of this standard appears to be CTA-861.3-A (see:
> > https://www.cta.tech/standards/cta-8613-a/). Note that the
Consumer
> > Electronics Association (CEA) changed its name to the "Consumer
> > Technology Association" (CTA) in 2015.
> >
> > Should this reference be updated to point to CTA-861.3-A?
> >
> > agree with the update.
> >
> >
> > Current:
> > [CEA-861.3]
> > CEA, "CEA-861.3, HDR Static Metadata Extension",
January
> > 2015.
> > -->
> >
> >
> > 27) <!-- [rfced] Please review whether any of the notes in
this document
> > should be in the <aside> element. It is defined as "a
container for
> > content that is semantically less important or tangential to the
> > content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
> > -->
> > NOTES are used to provide additional information for the
readers. We don’t think the definition of <aside> matches with the
intention. Please keep them as the notes.
> >
> > 28) <!-- [rfced] Please review the "Inclusive Language"
portion of the
> > online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> > and let us know if any changes are needed. Updates of this nature
> > typically result in more precise language, which is helpful
for readers.
> >
> > Note that our script did not flag any words in particular, but
this should
> > still be reviewed as a best practice.
> > -->
> > We have found none.
> >
> > In addition to the changes according to your comments, I have
also updated two references.
> >
> > OLD
> >
> > [FFmpegAPVdec]
> > "FFmpeg implementation of APV decoder", 19 April
2025,
> > <https://git.ffmpeg.org/gitweb/ffmpeg.git/
> > commit/483cadf8d77d3260eec8781f5f18c50f27e468f8>.
> >
> > [FFmpegAPVenc]
> > "FFmpeg implementation of APV encoder", 23 April
2025,
> > <https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/
> > fab691edaf53bbf10429ef3448f1f274e5078395>.
> >
> >
> >
> > NEW
> >
> > [FFmpegAPVdec]
> > "FFmpeg implementation of APV decoder" , 20 November 2025,
> > <https://
> > ffmpeg.org/download.html#release_8.0
<http://ffmpeg.org/download.html#release_8.0>>
> > .
> > [FFmpegAPVenc]
> > "FFmpeg implementation of APV encoder" , 4 May 2025,
> > <https://
> > git.ffmpeg.org/gitweb/ffmpeg.git/commit/
<http://git.ffmpeg.org/gitweb/ffmpeg.git/commit/>
fab691edaf53bbf10429ef3448f1f274e5078395>
> >
> > Please let us know if you have any further questions or comments.
> >
> >
> > Sincerely,
> > Youngkwon
> >
> >
> > On Wed, Feb 4, 2026, 13:47 Sandy Ginoza
<[email protected]> wrote:
> > Hi Youngkwon,
> >
> > Thank you for your reply. We will wait to hear from you.
> >
> > Thank you,
> > Sandy Ginoza
> > RFC Production Center
> >
> >
> >
> > > On Feb 4, 2026, at 10:12 AM, Youngkwon Lim
<[email protected]> wrote:
> > >
> > > Dear Sandy,
> > >
> > > Thank you for the notes. I have received your email
yesterday. I'm reviewing the comments. I'll be able to send you
the answers probably by tomorrow.
> > >
> > > Sincerely,
> > > Youngkwon.
> > >
> > > On Wed, Feb 4, 2026, 12:10 Sandy Ginoza
<[email protected]> wrote:
> > > Hi Youngkwon,
> > >
> > > We understand that you would like to publish this document
as quickly as possible. This document was moved to AUTH48 (see
https://mailarchive.ietf.org/arch/msg/auth48archive/gLcjKw1Lm4JZQefWIc2249CjaA0/).
Please follow the instructions to ensure timely publication.
> > >
> > > In addition, please reply to the questions in our followup
mail (see
> > >
https://mailarchive.ietf.org/arch/msg/auth48archive/2RYT4cM76OIcNmJl9PU5KFcBOqA/).
Note that the RFC will not be published until the questions have
been resolved and each of the authors has indicated that they have
reviewed the document and approve it for publication.
> > >
> > > Please let us know if you have any questions.
> > >
> > > Thank you,
> > > Sandy Ginoza
> > > RFC Production Center
> > >
> > >
> > >
> > > > On Feb 1, 2026, at 10:59 AM, Youngkwon Lim
<[email protected]> wrote:
> > > >
> > > > Dear Eliot,
> > > >
> > > > We fully understand and appreciate the efforts by the RPC
and the reviewers including you. I absolutely agree with you that
the quality of the work shouldn't be compromised for any reason.
We, the authors, just don't want miss the opportunity to be part
of the big events by a small delay which will also be an
opportunity to express our thanks to the RPC as well.
> > > >
> > > > Sincerely,
> > > > Youngkwon
> > > >
> > > >
> > > > On Sun, Feb 1, 2026, 12:49 Independent Submissions Editor
(Eliot Lear) <[email protected]> wrote:
> > > > Hi!
> > > > I want to make clear that publication of RFCs is not for
marketing events. The RPC will have worked quite hard to ensure
the best quality version of your work. For that to happen they
MUST NOT be rushed.
> > > > Eliot
> > > > On 30.01.2026 20:42, Sarah Tarrant wrote:
> > > >> Hi Youngkwon,
> > > >>
> > > >> We can do our best to get this to AUTH48 earlier next
week. And from there, the best support you can give us to expedite
the AUTH48 process is to send updates and approvals once you get
that AUTH48 email.
> > > >>
> > > >> Sincerely,
> > > >> Sarah Tarrant
> > > >> RFC Production Center
> > > >>
> > > >>
> > > >>> On Jan 30, 2026, at 1:06 PM, Youngkwon Lim
<[email protected]> wrote:
> > > >>>
> > > >>> Dear Sarah,
> > > >>>
> > > >>> Thank you for checking. Would it be possible to make it
happen by the next week? We are working on a big event regarding
APV in general. I don't want to miss the opportunity to be part of
it due to just a week delay. It will be really appreciated if you
can consider the situation. Please let me know if you need any
support from us to expedite the process.
> > > >>>
> > > >>> Sincerely,
> > > >>> Youngkwon
> > > >>>
> > > >>> On Fri, Jan 30, 2026, 13:01 Sarah Tarrant
<[email protected]> wrote:
> > > >>> Hi Youngkwon,
> > > >>>
> > > >>> Thank you for checking in! Now, it looks like this draft
should move to AUTH48 in the next 1 or 2 weeks.
> > > >>>
> > > >>> Sincerely,
> > > >>> Sarah Tarrant
> > > >>> RFC Production Center
> > > >>>
> > > >>>
> > > >>>> On Jan 30, 2026, at 11:22 AM, Youngkwon Lim
<[email protected]> wrote:
> > > >>>>
> > > >>>> Dear Sarah,
> > > >>>>
> > > >>>> As today is the last working day of the January, I'm
just touching base with you again if there has been any update on
the progress of the production. Thank you!
> > > >>>>
> > > >>>> Sincerely,
> > > >>>> Youngkwon.
> > > >>>>
> > > >>>>
> > > >>>> On Fri, Jan 9, 2026, 14:00 Sarah Tarrant
<[email protected]> wrote:
> > > >>>> Hi Youngkwon,
> > > >>>>
> > > >>>> Happy New Year to you as well!
> > > >>>>
> > > >>>> It's still looking like your draft should enter AUTH48
closer to the end of January 2026.
> > > >>>>
> > > >>>> Sincerely,
> > > >>>> Sarah Tarrant
> > > >>>> RFC Production Center
> > > >>>>
> > > >>>>
> > > >>>>> On Jan 8, 2026, at 1:37 PM, Youngkwon Lim
<[email protected]> wrote:
> > > >>>>>
> > > >>>>> Dear Sarah,
> > > >>>>>
> > > >>>>> Happy New Year!
> > > >>>>>
> > > >>>>> I hope you have a enjoyable holiday season and started
a great new year.
> > > >>>>>
> > > >>>>> I just wanted to touch base with you about the
progress of the edit and see if you have more visibility about the
dates for the next step.
> > > >>>>>
> > > >>>>> Sincerely,
> > > >>>>> Youngkwon Lim
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> On Thu, Oct 23, 2025, 11:52 Sarah Tarrant
<[email protected]> wrote:
> > > >>>>> Hi Young,
> > > >>>>>
> > > >>>>> Based on the current processing time, it looks like
draft-lim-apv-09 would enter AUTH48 in January, after the holiday
season.
> > > >>>>>
> > > >>>>> Sincerely,
> > > >>>>> Sarah Tarrant
> > > >>>>> RFC Production Center
> > > >>>>>
> > > >>>>>
> > > >>>>>> On Oct 22, 2025, at 8:32 AM, Youngkwon Lim
<[email protected]> wrote:
> > > >>>>>>
> > > >>>>>> Thank you for the confirmation. BTW, do you have any
time frame expected about AUTH48 in this case you can guess? Just
in case, as we are approaching holiday season.
> > > >>>>>>
> > > >>>>>> Sincerely,
> > > >>>>>> Young.
> > > >>>>>>
> > > >>>>>> On Wed, Oct 22, 2025, 07:49 Sarah Tarrant
<[email protected]> wrote:
> > > >>>>>> Hi Young,
> > > >>>>>>
> > > >>>>>> Thank you for your reply. We will reach out if we
need further clarification on anything during the editing process.
> > > >>>>>>
> > > >>>>>> Sincerely,
> > > >>>>>> Sarah Tarrant
> > > >>>>>> RFC Production Center
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>> On Oct 21, 2025, at 7:43 PM, Youngkwon Lim
<[email protected]> wrote:
> > > >>>>>>>
> > > >>>>>>> Dear the RPC Team,
> > > >>>>>>>
> > > >>>>>>> We are really excited that the draft has reached
this step and ready for production.
> > > >>>>>>>
> > > >>>>>>> We have reviewed the questions in your email and can
confirm that no updates are required and there are no special
request to make. You can process the 09 version of the draft as it
is.
> > > >>>>>>>
> > > >>>>>>> We are really grateful to the shepherd who has
reviewed the draft many times thoroughly and provide us many good
comments. We will be happy to work with you to move forward this
draft to the final publication. Please feel free to reach out to
us if there are any questions or request to us. Thank you!
> > > >>>>>>>
> > > >>>>>>> Sincerely,
> > > >>>>>>> Young
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> ------ Original Message ------
> > > >>>>>>> >From "Sarah Tarrant" <[email protected]>
> > > >>>>>>> To [email protected]; [email protected];
[email protected]; [email protected]; [email protected]
> > > >>>>>>> Cc [email protected];
[email protected]; [email protected]
> > > >>>>>>> Date 10/21/2025 4:42:46 PM
> > > >>>>>>> Subject Document intake questions about
<draft-lim-apv-09>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>> Author(s),
> > > >>>>>>>> Congratulations, your document has been
successfully added to the RFC Editor queue!
> > > >>>>>>>> The team at the RFC Production Center (RPC) is
looking forward to working with you
> > > >>>>>>>> as your document moves forward toward publication.
To help reduce processing time
> > > >>>>>>>> and improve editing accuracy, please respond to the
questions below. Please confer
> > > >>>>>>>> with your coauthors (or authors of other documents
if your document is in a
> > > >>>>>>>> cluster) as necessary prior to taking action in
order to streamline communication.
> > > >>>>>>>> If your document has multiple authors, only one
author needs to reply to this
> > > >>>>>>>> message.
> > > >>>>>>>> As you read through the rest of this email:
> > > >>>>>>>> * If you need/want to make updates to your
document, we encourage you to make those
> > > >>>>>>>> changes and resubmit to the Datatracker. This
allows for the easy creation of diffs,
> > > >>>>>>>> which facilitates review by interested parties
(e.g., authors, ADs, doc shepherds).
> > > >>>>>>>> * If you feel no updates to the document are
necessary, please reply with any
> > > >>>>>>>> applicable rationale/comments.
> > > >>>>>>>> Please note that the RPC team will not work on your
document until we hear from you
> > > >>>>>>>> (that is, your document will remain in AUTH state
until we receive a reply). Even
> > > >>>>>>>> if you don't have guidance or don't feel that you
need to make any updates to the
> > > >>>>>>>> document, you need to let us know. After we hear
from you, your document will start
> > > >>>>>>>> moving through the queue. You will be able to
review and approve our updates
> > > >>>>>>>> during AUTH48.
> > > >>>>>>>> Please feel free to contact us with any questions
you may have at
> > > >>>>>>>> [email protected].
> > > >>>>>>>> Thank you!
> > > >>>>>>>> The RPC Team
> > > >>>>>>>> --
> > > >>>>>>>> 1) As there may have been multiple updates made to
the document during Last Call,
> > > >>>>>>>> please review the current version of the document:
> > > >>>>>>>> * Is the text in the Abstract still accurate?
> > > >>>>>>>> * Are the Authors' Addresses, Contributors, and
Acknowledgments
> > > >>>>>>>> sections current?
> > > >>>>>>>> 2) Please share any style information that could
help us with editing your
> > > >>>>>>>> document. For example:
> > > >>>>>>>> * Is your document's format or its terminology
based on another document?
> > > >>>>>>>> If so, please provide a pointer to that document
(e.g., this document's
> > > >>>>>>>> terminology should match DNS terminology in RFC 9499).
> > > >>>>>>>> * Is there a pattern of capitalization or
formatting of terms? (e.g., field names
> > > >>>>>>>> should have initial capitalization; parameter names
should be in double quotes;
> > > >>>>>>>> <tt/> should be used for token names; etc.)
> > > >>>>>>>> 3) Please review the entries in the References
section carefully with
> > > >>>>>>>> the following in mind. Note that we will update as
follows unless we
> > > >>>>>>>> hear otherwise at this time:
> > > >>>>>>>> * References to obsoleted RFCs will be updated to
point to the current
> > > >>>>>>>> RFC on the topic in accordance with Section 4.8.6
of RFC 7322
> > > >>>>>>>> (RFC Style Guide).
> > > >>>>>>>> * References to I-Ds that have been replaced by
another I-D will be
> > > >>>>>>>> updated to point to the replacement I-D.
> > > >>>>>>>> * References to documents from other organizations
that have been
> > > >>>>>>>> superseded will be updated to their superseding
version.
> > > >>>>>>>> Note: To check for outdated RFC and I-D references,
you can use
> > > >>>>>>>> idnits <https://author-tools.ietf.org/idnits>. You
can also help the
> > > >>>>>>>> IETF Tools Team by testing idnits3
<https://author-tools.ietf.org/idnits3/>
> > > >>>>>>>> with your document and reporting any issues to them.
> > > >>>>>>>> 4) Is there any text that should be handled extra
cautiously? For example, are
> > > >>>>>>>> there any sections that were contentious when the
document was drafted?
> > > >>>>>>>> 5) Is there anything else that the RPC should be
aware of while editing this
> > > >>>>>>>> document?
> > > >>>>>>>> 6) Would you like to participate in the RPC Pilot
Test for editing in kramdown-rfc?
> > > >>>>>>>> If so, please let us know and provide a
self-contained kramdown-rfc file. For more
> > > >>>>>>>> information about this experiment, see:
> > > >>>>>>>>
https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>> On Oct 21, 2025, at 4:39 PM,
[email protected] wrote:
> > > >>>>>>>>> Author(s),
> > > >>>>>>>>> Your document draft-lim-apv-09, which has been
approved for publication as
> > > >>>>>>>>> an RFC, has been added to the RFC Editor queue
> > > >>>>>>>>> <https://www.rfc-editor.org/current_queue.php>.
> > > >>>>>>>>> If your XML file was submitted using the I-D
submission tool
> > > >>>>>>>>> <https://datatracker.ietf.org/submit/>, we have
already retrieved it
> > > >>>>>>>>> and have started working on it.
> > > >>>>>>>>> If you did not submit the file via the I-D
submission tool, or
> > > >>>>>>>>> if you have an updated version (e.g., updated
contact information),
> > > >>>>>>>>> please send us the file at this time by attaching it
> > > >>>>>>>>> in your reply to this message and specifying any
differences
> > > >>>>>>>>> between the approved I-D and the file that you are
providing.
> > > >>>>>>>>> You will receive a separate message from us asking
for style input.
> > > >>>>>>>>> Please respond to that message. When we have
received your response,
> > > >>>>>>>>> your document will then move through the queue.
The first step that
> > > >>>>>>>>> we take as your document moves through the queue
is converting it to
> > > >>>>>>>>> RFCXML (if it is not already in RFCXML) and
applying the formatting
> > > >>>>>>>>> steps listed at
<https://www.rfc-editor.org/pubprocess/how-we-update/>.
> > > >>>>>>>>> Next, we will edit for clarity and apply the style
guide
> > > >>>>>>>>> (<https://www.rfc-editor.org/styleguide/>).
> > > >>>>>>>>> You can check the status of your document at
> > > >>>>>>>>> <https://www.rfc-editor.org/current_queue.php>.
> > > >>>>>>>>> You will receive automatic notifications as your
document changes
> > > >>>>>>>>> queue state (for more information about these
states, please see
> > > >>>>>>>>> <https://www.rfc-editor.org/about/queue/>). When
we have completed
> > > >>>>>>>>> our edits, we will move your document to AUTH48
state and ask you
> > > >>>>>>>>> to perform a final review of the document.
> > > >>>>>>>>> Please let us know if you have any questions.
> > > >>>>>>>>> Thank you.
> > > >>>>>>>>> The RFC Editor Team
> > > >>>>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> >
>
>
<rfc9924_0205.diff.html><rfc9924_0205_authors.xml><rfc9924_0205_authors.pdf>
