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]
