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> > > > . > > > [FFmpegAPVenc] > > > "FFmpeg implementation of APV encoder" , 4 May 2025, > > > <https:// > > > 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> > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
