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
