Kaelin

I couldn’t quite parse your message. Don’t require additional approvals or not?

Eliot

> On 12 Dec 2025, at 23:11, Kaelin Foody <[email protected]> wrote:
> 
> Hi all,
> 
> Nevil: Thank you for your approval of this document’s content. We have marked 
> it on the AUTH48 status page for this document.
> 
> Alexis, all: Thanks for your reply. As part of the RPC’s kramdown-rfc pilot, 
> there is a two-part AUTH48 approval process (one round of approvals for 
> content and a final round of approvals for formatting).
> 
> We have received all necessary content approvals and have converted the 
> document to RFCXML, with no major formatting changes to note.
> 
> Please review the XML file/diff and the output files, and let us know if any 
> additional formatting changes are required or if you approve the RFC for 
> publication. We consider this your final assent that the document is ready 
> for publication. To request changes or approve this RFC for publication, 
> please reply all to this email.
> 
> The AUTH48 status page for this document is available here:
> https://www.rfc-editor.org/auth48/rfc9896
> 
> For more information about the RPC’s kramdown-rfc pilot, please see:
> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_instructions_completing_auth48_using_kramdown.
> 
> — FILES: —
> 
> XML file:
> https://www.rfc-editor.org/authors/rfc9896.xml
> 
> XML diff:
> https://www.rfc-editor.org/authors/rfc9896-xmldiff1.html
> 
> Output files:
> https://www.rfc-editor.org/authors/rfc9896.html
> https://www.rfc-editor.org/authors/rfc9896.pdf
> https://www.rfc-editor.org/authors/rfc9896.txt
> 
> Diff of changes made in AUTH48:
> https://www.rfc-editor.org/authors/rfc9896-auth48diff.html
> https://www.rfc-editor.org/authors/rfc9896-auth48rfcdiff.html (side by side)
> 
> Diff of all changes:
> https://www.rfc-editor.org/authors/rfc9896-diff.html
> https://www.rfc-editor.org/authors/rfc9896-rfcdiff.html (side by side)
> 
> 
> Thank you all for your time.
> 
> All best,
> 
> Kaelin Foody
> RFC Production Center
> 
>> On Dec 12, 2025, at 4:21 PM, Alexis Rossi <[email protected]> wrote:
>> 
>> Hi Kaelin,
>> 
>> I think we have all of the approvals now, is that correct?
>> 
>> Thanks,
>> Alexis
>> 
>> 
>> On Wed, Dec 10, 2025 at 7:51 PM Nevil Brownlee <[email protected]> 
>> wrote:
>> Hi RFC Editor(s):
>> I approve the changes made, as reflected in this AUTH48 email.
>> 
>> Cheers, Nevil Brownlee
>> 
>>> On Tue, Nov 18, 2025 at 7:50 PM <[email protected]> wrote:
>>> 
>>> Authors,
>>> 
>>> While reviewing this document during AUTH48, please resolve (as necessary) 
>>> the following questions, which are also in the source file.
>>> 
>>> 
>>> 1) <!-- [rfced] Abstract
>>> 
>>> a) The Abstract does not explicitly mention that this document obsoletes RFC
>>> 7996. See the checklist in the "Abstract" section of
>>> https://authors.ietf.org/required-content. Please review and let us know how
>>> you would like to update.
>>> 
>>> 
>>> b) This sentence mentions the RPC being responsible for implementation
>>> decisions. Other instances in the document mention the RPC being responsible
>>> for decisions about both tooling and implementation. Are any updates needed,
>>> or is the current okay?
>>> 
>>> Original:
>>>   It also makes the RFC Publication Center (RPC) responsible for
>>>   implementation decisions regarding SVGs.
>>> 
>>> Perhaps:
>>>   It also makes the RFC Publication Center (RPC) responsible for
>>>   decisions about SVG tooling and implementation.
>>> -->
>>> 
>>> 
>>> 2) <!-- [rfced] Abstract/Introduction: Is "sets" the best word choice here? 
>>> Would
>>> "defines" or something else be better? Also, will all readers know what the
>>> "definitive versions of RFCs and relevant publication formats" are? Would
>>> adding a citation or clarification in the Introduction be helpful? If so,
>>> please provide the appropriate citation or text.
>>> 
>>> Original:
>>>   This document sets policy for the inclusion of SVGs in the definitive
>>>   versions of RFCs and relevant publication formats.
>>>   ...
>>>   This document sets policy for the inclusion of SVGs (Scalable Vector
>>>   Graphics) in the definitive versions of RFCs and relevant publication
>>>   formats.
>>> -->
>>> 
>>> 
>>> 3) <!-- [rfced] Section 2: In the text below, how may we update "This 
>>> includes"?
>>> It is not clear what "This" refers to.
>>> 
>>> Original:
>>>   *  Images and diagrams in RFCs should be successfully rendered and
>>>      understood by the widest audience possible.  To that end, the RPC
>>>      may prohibit the use of SVG features that are known to lack
>>>      support on common devices, that do not render on small or low-
>>>      resolution screens, or that could make diagrams less
>>>      comprehensible for any significant readership.  This includes:
>>> 
>>>      -  SVGs must not contain pointers to external resources.
>>> 
>>>      -  SVGs must not contain executable script.
>>> 
>>>      -  SVGs should be as accessible as possible to people with visual
>>>         disabilities, ...
>>> 
>>> Perhaps:
>>>   *  Images and diagrams in RFCs should be successfully rendered and
>>>      understood by the widest audience possible.  To that end, the RPC
>>>      may prohibit the use of SVG features that are known to lack
>>>      support on common devices, that do not render on small or low-
>>>      resolution screens, or that could make diagrams less
>>>      comprehensible for any significant readership.  In particular:
>>> 
>>>      -  SVGs must not contain pointers to external resources.
>>> 
>>>      -  SVGs must not contain executable script.
>>> 
>>>      -  SVGs should be as accessible as possible to people with visual
>>>         disabilities, ...
>>> 
>>> Or:
>>>   *  Images and diagrams in RFCs should be successfully rendered and
>>>      understood by the widest audience possible.  To that end, the RPC
>>>      may prohibit the use of SVG features that are known to lack
>>>      support on common devices, that do not render on small or low-
>>>      resolution screens, or that could make diagrams less
>>>      comprehensible for any significant readership.  For instance:
>>> 
>>>      -  SVGs must not contain pointers to external resources.
>>> 
>>>      -  SVGs must not contain executable script.
>>> 
>>>      -  SVGs should be as accessible as possible to people with visual
>>>         disabilities, ...
>>> -->
>>> 
>>> 
>>> 4) <!-- [rfced] Section 2: FYI, we have updated the sentence below to 
>>> clarify that
>>> SVGs should be consistent with the content of the RFC (rather than the text
>>> output file of the RFC).
>>> 
>>> Original:
>>>  At minimum, SVGs should be consistent with the text.
>>> 
>>> Current:
>>>  At minimum, SVGs should be consistent with the descriptions
>>>  in the text of the RFC.
>>> -->
>>> 
>>> 
>>> 5) <!-- [rfced] Section 2: This sentence mentions that decisions about SVG
>>> tooling and implementation are "made or overseen" by the RPC. The document
>>> mentions several times that the RPC is responsible for making decisions, but
>>> this is the only mention of "overseen" in the document. Please review and 
>>> let
>>> us know if any updates are needed.
>>> 
>>> Original:
>>>   SVG tooling and implementation decisions are made or overseen by the
>>>   RPC, and must adhere to the policy requirements in this document.
>>> -->
>>> 
>>> 
>>> 6) <!-- [rfced] Section 2: We updated "rfcxml" to "RFCXML" in the first 
>>> sentence
>>> below per RFC 9720. Would it be helpful to also include a citation to RFC 
>>> 9720
>>> or other applicable reference here?
>>> 
>>> Original:
>>>   *  Authors may include multiple versions of images or diagrams in
>>>      rfcxml.  Publication formats should present the versions best
>>>      suited to each format.  In many cases, that will be an SVG.
>>> 
>>> Perhaps:
>>>   *  Authors may include multiple versions of images or diagrams in
>>>      RFCXML [RFC9720].  Publication formats should present the versions best
>>>      suited to each format.  In many cases, that will be an SVG.
>>> -->
>>> 
>>> 
>>> 7) <!-- [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.
>>> 
>>> -->
>>> 
>>> 
>>> Thank you.
>>> 
>>> Kaelin Foody and Rebecca VanRheenen
>>> RFC Production Center
>>> 
>>> 
>>> 
>>>> On Nov 17, 2025, at 10:45 PM, [email protected] wrote:
>>> 
>>> *****IMPORTANT*****
>>> 
>>> Updated 2025/11/17
>>> 
>>> RFC Author(s):
>>> 
>>> Your document has now entered AUTH48.
>>> 
>>> The document was edited in kramdown-rfc as part of the RPC pilot test (see
>>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc).
>>> 
>>> Please review the procedures for AUTH48 using kramdown-rfc:
>>> 
>>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_instructions_completing_auth48_using_kramdown
>>> 
>>> Once your document has completed AUTH48, it will be published as
>>> an RFC.
>>> 
>>> 
>>> Files
>>> -----
>>> 
>>> The files are available here:
>>>  https://www.rfc-editor.org/authors/rfc9896.md
>>>  https://www.rfc-editor.org/authors/rfc9896.html
>>>  https://www.rfc-editor.org/authors/rfc9896.pdf
>>>  https://www.rfc-editor.org/authors/rfc9896.txt
>>> 
>>> Diff file of the text:
>>>  https://www.rfc-editor.org/authors/rfc9896-diff.html
>>>  https://www.rfc-editor.org/authors/rfc9896-rfcdiff.html (side by side)
>>> 
>>> Diff of the kramdown:
>>>  https://www.rfc-editor.org/authors/rfc9896-md-diff.html
>>>  https://www.rfc-editor.org/authors/rfc9896-md-rfcdiff.html (side by side)
>>> 
>>> 
>>> Tracking progress
>>> -----------------
>>> 
>>> The details of the AUTH48 status of your document are here:
>>> https://www.rfc-editor.org/auth48/rfc9896
>>> 
>>> 
>>> Please let us know if you have any questions.
>>> 
>>> Thank you for your cooperation,
>>> 
>>> RFC Editor
>>> 
>> 
>> 
>> --
>> -----------------------------------
>> Nevil Brownlee, Taupo, NZ
>> 
>> --
>> RSAB mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
> 
> --
> RSAB mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> 

-- 
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to