I approve the document in its current form. Bob
> On Aug 12, 2025, at 5:44 PM, Rebecca VanRheenen > <rvanrhee...@staff.rfc-editor.org> wrote: > > Hi Brian and Bob, > > Thank you for addressing all of our questions. We have updated the document > accordingly. > > We have also noted Brian's approval on the AUTH48 status page for this > document (https://www.rfc-editor.org/auth48/rfc9844). > > Bob, please let us know if you approve the document in its current form or if > any further updates are needed. > > > — FILES (please refresh) — > > Updated XML file: > https://www.rfc-editor.org/authors/rfc9844.xml > > Updated output files: > https://www.rfc-editor.org/authors/rfc9844.txt > https://www.rfc-editor.org/authors/rfc9844.pdf > https://www.rfc-editor.org/authors/rfc9844.html > > Diff file showing all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9844-auth48diff.html > https://www.rfc-editor.org/authors/rfc9844-auth48rfcdiff.html (side by side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9844-diff.html > https://www.rfc-editor.org/authors/rfc9844-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9844-alt-diff.html (diff showing > changes where text is moved or deleted) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9844 > > Thank you, > RFC Editor/rv > > > >> On Aug 12, 2025, at 5:38 PM, Bob Hinden <bob.hin...@gmail.com> wrote: >> >> I am in agreement with Brian’s response. >> >> Bob >> >> >>> On Aug 12, 2025, at 1:52 PM, Brian E Carpenter >>> <brian.e.carpen...@gmail.com> wrote: >>> >>> Hi, >>> >>> I have carefully reviewed this version and am happy with it. My answers to >>> the queries are in line below. >>> >>> Regards/Ngā mihi >>> Brian Carpenter >>> >>> On 12-Aug-25 15:46, rfc-edi...@rfc-editor.org wrote: >>>> Authors, >>>> While reviewing this document during AUTH48, please resolve (as necessary) >>>> the following questions, which are also in the XML file. >>>> 1) <!-- [rfced] This document updates RFC 7622, which has some errata. >>>> Please review the errata reported for RFC 7622 and let us know if >>>> you confirm our opinion that none of them are relevant to the content >>>> of this document. >>>> Link to errata for RFC 7622: >>>> https://www.rfc-editor.org/errata/rfc7622 >>>> --> >>> >>> Agreed, these errata are irrelevant, >>> >>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in >>>> the title) for use on https://www.rfc-editor.org/search. --> >>>> 3) <!-- [rfced] The title for [ONE-NET] in the text and the reference >>>> entry are >>>> different. Which is correct? We see both forms used in the URL in the >>>> reference entry. Let us know which form to use consistently in this >>>> document. >>>> Original: >>>> 5. The National Marine Electronics Association (NMEA) has defined >>>> the "OneNet Marine IPv6 Ethernet Networking Standard" [ONE-NET], >>>> which uses IPv6 link-local addresses exclusively. >>>> ... >>>> [ONE-NET] NMEA, "The OneNet Standard for IP Networking of Marine >>>> Electronic Devices", 2023, >>>> <https://www.nmea.org/nmea-onenet.html>. >>>> --> >>> >>> The heading of that web page is "OneNet® Marine IPv6 Ethernet Networking >>> Standard" so I think we should go with that everywhere. I leave it to your >>> policy whether to include the "®". >>> >>>> 4) <!-- [rfced] How may we update "e.g., [LL-HACK]"? >>>> Original: >>>> Such requirements have already spawned hacks to work around current >>>> limitations (e.g., [LL-HACK], which is no longer maintained and has >>>> been archived). >>>> Perhaps: >>>> Such requirements have already spawned hacks to work around current >>>> limitations (e.g., the Snippets:IPv6 link local connect hack [LL-HACK], >>>> which is no longer maintained and has been archived). >>>> Or: >>>> Such requirements have already spawned hacks to work around current >>>> limitations (e.g., the hack described in [LL-HACK], which is no longer >>>> maintained and has been archived). >>>> --> >>> >>> The second variant seems fine to me. >>> >>>> 5) <!-- [rfced] Please review "NULL characters" in the sentence below. >>>> Should >>>> this instead be "NULs" (that is, referring to the specific ASCII control >>>> code) or "null characters"? >>>> Original: >>>> For example, a UI implementation should not allow ASCII >>>> NULL characters in a zone identifier string as this could cause >>>> inconsistencies in subsequent string processing. >>>> --> >>> >>> Good catch. How about simply s/NULL/NUL/ ? That would be quite clear to the >>> reader. I think "NULs" would look a bit strange. >>> >>>> 6) <!-- [rfced] We reordered one name in the Acknowledgments section as it >>>> seems that the intent was to list the names in alphabetical order by last >>>> name. Let us know any concerns. >>>> --> >>> >>> Good catch. >>> >>>> 7) <!-- [rfced] FYI - Per earlier discussion, the RPC will update metadata >>>> for >>>> RFC 3986 and create an erratum report on RFC 6874 as described below >>>> after publication of this document. >>>>> From email from Sandy Ginoza (RPC) on 20 May 2025 with subject line "Re: >>>> Datatracker State Update Notice: <draft-ietf-6man-zone-ui-10.txt>": >>>> This is the current metadata for RFC 3986 (STD 66): Obsoletes RFC 2732, RFC >>>> 2396, RFC 1808, Updates RFC 1738, Updated by RFC 6874, RFC 7320, RFC 8820 >>>> I believe the goal is for it to be updated as follows (remove mention of >>>> 6874): Obsoletes RFC 2732, RFC 2396, RFC 1808, Updates RFC 1738, Updated by >>>> RFC 7320, RFC 8820 >>>> For the reader that may land on RFC 6874, add an erratum on RFC 6874 with >>>> the >>>> content (or similar) below when draft-ietf-6man-zone-ui is published as an >>>> RFC. >>>> This was found unimplementable and no longer updates RFC 3986. Please see >>>> [RFC9844] for more info. >>>> --> >>> >>> Yes, good. >>> >>>> 8) <!-- [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. >>>> For example, please consider whether "native" should be updated: >>>> Original: >>>> It will become critical as IPv6-only or IPv6-mostly >>>> networks [RFC8925] [I-D.ietf-v6ops-6mops], with nodes lacking native >>>> IPv4 support, appear. >>>> --> >>> >>> No change. This is a term of art. >>> >>> Thanks. >>> >>>> Thank you. >>>> RFC Editor/rv >>>> On Aug 11, 2025, at 8:43 PM, rfc-edi...@rfc-editor.org wrote: >>>> *****IMPORTANT***** >>>> Updated 2025/08/11 >>>> RFC Author(s): >>>> -------------- >>>> Instructions for Completing AUTH48 >>>> Your document has now entered AUTH48. Once it has been reviewed and >>>> approved by you and all coauthors, it will be published as an RFC. >>>> If an author is no longer available, there are several remedies >>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>>> You and you coauthors are responsible for engaging other parties >>>> (e.g., Contributors or Working Group) as necessary before providing >>>> your approval. >>>> Planning your review >>>> --------------------- >>>> Please review the following aspects of your document: >>>> * RFC Editor questions >>>> Please review and resolve any questions raised by the RFC Editor >>>> that have been included in the XML file as comments marked as >>>> follows: >>>> <!-- [rfced] ... --> >>>> These questions will also be sent in a subsequent email. >>>> * Changes submitted by coauthors >>>> Please ensure that you review any changes submitted by your >>>> coauthors. We assume that if you do not speak up that you >>>> agree to changes submitted by your coauthors. >>>> * Content >>>> Please review the full content of the document, as this cannot >>>> change once the RFC is published. Please pay particular attention to: >>>> - IANA considerations updates (if applicable) >>>> - contact information >>>> - references >>>> * Copyright notices and legends >>>> Please review the copyright notice and legends as defined in >>>> RFC 5378 and the Trust Legal Provisions >>>> (TLP – https://trustee.ietf.org/license-info). >>>> * Semantic markup >>>> Please review the markup in the XML file to ensure that elements of >>>> content are correctly tagged. For example, ensure that <sourcecode> >>>> and <artwork> are set correctly. See details at >>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>> * Formatted output >>>> Please review the PDF, HTML, and TXT files to ensure that the >>>> formatted output, as generated from the markup in the XML file, is >>>> reasonable. Please note that the TXT will have formatting >>>> limitations compared to the PDF and HTML. >>>> Submitting changes >>>> ------------------ >>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>>> the parties CCed on this message need to see your changes. The parties >>>> include: >>>> * your coauthors >>>> * rfc-edi...@rfc-editor.org (the RPC team) >>>> * other document participants, depending on the stream (e.g., >>>> IETF Stream participants are your working group chairs, the >>>> responsible ADs, and the document shepherd). >>>> * auth48archive@rfc-editor.org, which is a new archival mailing list >>>> to preserve AUTH48 conversations; it is not an active discussion >>>> list: >>>> * More info: >>>> >>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>> * The archive itself: >>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>> * Note: If only absolutely necessary, you may temporarily opt out >>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>> If needed, please add a note at the top of the message that you >>>> have dropped the address. When the discussion is concluded, >>>> auth48archive@rfc-editor.org will be re-added to the CC list and >>>> its addition will be noted at the top of the message. >>>> You may submit your changes in one of two ways: >>>> An update to the provided XML file >>>> — OR — >>>> An explicit list of changes in this format >>>> Section # (or indicate Global) >>>> OLD: >>>> old text >>>> NEW: >>>> new text >>>> You do not need to reply with both an updated XML file and an explicit >>>> list of changes, as either form is sufficient. >>>> We will ask a stream manager to review and approve any changes that seem >>>> beyond editorial in nature, e.g., addition of new text, deletion of text, >>>> and technical changes. Information about stream managers can be found in >>>> the FAQ. Editorial changes do not require approval from a stream manager. >>>> Approving for publication >>>> -------------------------- >>>> To approve your RFC for publication, please reply to this email stating >>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>> as all the parties CCed on this message need to see your approval. >>>> Files >>>> ----- >>>> The files are available here: >>>> https://www.rfc-editor.org/authors/rfc9844.xml >>>> https://www.rfc-editor.org/authors/rfc9844.html >>>> https://www.rfc-editor.org/authors/rfc9844.pdf >>>> https://www.rfc-editor.org/authors/rfc9844.txt >>>> Diff file of the text: >>>> https://www.rfc-editor.org/authors/rfc9844-diff.html >>>> https://www.rfc-editor.org/authors/rfc9844-rfcdiff.html (side by side) >>>> Alt-diff of the text (allows you to more easily view changes >>>> where text has been deleted or moved): >>>> https://www.rfc-editor.org/authors/rfc9844-alt-diff.html >>>> Diff of the XML: >>>> https://www.rfc-editor.org/authors/rfc9844-xmldiff1.html >>>> Tracking progress >>>> ----------------- >>>> The details of the AUTH48 status of your document are here: >>>> https://www.rfc-editor.org/auth48/rfc9844 >>>> Please let us know if you have any questions. >>>> Thank you for your cooperation, >>>> RFC Editor >>>> -------------------------------------- >>>> RFC9844 (draft-ietf-6man-zone-ui-10) >>>> Title : Entering IPv6 Zone Identifiers in User Interfaces >>>> Author(s) : B. Carpenter, B. Hinden >>>> WG Chair(s) : Bob Hinden, Jen Linkova >>>> Area Director(s) : Erik Kline, Éric Vyncke >> >
signature.asc
Description: Message signed with OpenPGP
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
