Hi Warren and Dan, Pulling this request to the top: > Please confirm you approve the RFC for publication.
We request your approval because it’s not a matter of publishing without a DOI; we have removed the reference altogether (which matches what was in the approved I-D). Please confirm you approve with RFC for publication after the most recent update. If approved, we will announce the RFC this week. Thanks, RFC Editor/sg > On Dec 11, 2024, at 3:55 PM, Sandy Ginoza <sgin...@amsl.com> wrote: > > Hi all, > > We have removed mention of [IEEE_802.11-2024]. Please note that this means > there will be no citation or informational reference to the document itself; > the reference to the IEEE_802.11 WG ([IEEE_802.11]) remains. > > You can view the updated files here: > https://www.rfc-editor.org/authors/rfc9672.xml > https://www.rfc-editor.org/authors/rfc9672.txt > https://www.rfc-editor.org/authors/rfc9672.pdf > https://www.rfc-editor.org/authors/rfc9672.html > > Diffs highlighting the most recent change only: > https://www.rfc-editor.org/authors/rfc9672-lastdiff.html > https://www.rfc-editor.org/authors/rfc9672-lastrfcdiff.html > > AUTH48 diff: > https://www.rfc-editor.org/authors/rfc9672-auth48diff.html > > Comprehensive diffs: > https://www.rfc-editor.org/authors/rfc9672-diff.html > https://www.rfc-editor.org/authors/rfc9672-rfcdiff.html > > Please confirm you approve the RFC for publication. > > Thank you, > RFC Editor/sg > > > >> On Dec 6, 2024, at 5:55 AM, Warren Kumari <war...@kumari.net> wrote: >> >> >> >> >> >> On Fri, Dec 06, 2024 at 8:46 AM, Dan Harkins <daniel.hark...@hpe.com> wrote: >> >> >> Hello, >> >> >> >> Yes, I confirm. I'm fine publishing without the DOI. >> >> >> >> Yah, me too! >> W >> >> >> >> >> regards, >> >> >> >> Dan. >> >> >> >> -- >> >> "the object of life is not to be on the side of the majority, but to >> >> escape finding oneself in the ranks of the insane." – Marcus Aurelius >> >> >> >> On 12/5/24, 10:12 PM, "Eric Vyncke (evyncke)" <evyn...@cisco.com> wrote: >> >> >> >> Sandy, >> >> >> >> I think that the IETF should not wait anymore for the IEEE actual >> publication, let’s publish RFC 9672 even without the DOI for the IEEE 802.11 >> Std 2024. >> >> >> >> Dan, Warren can you confirm our latest discussion on the above point ? >> >> >> >> Now, if the RFC editor policy is to wait until the DOI is available, then >> let’s wait. >> >> >> >> Regards, >> >> >> >> -éric >> >> >> >> From: Sandy Ginoza <sgin...@amsl.com> >> Date: Tuesday, 12 November 2024 at 18:20 >> To: Harkins, Dan <daniel.hark...@hpe.com> >> Cc: Warren Kumari <war...@kumari.net>, RFC Editor >> <rfc-edi...@rfc-editor.org>, Eric Vyncke (evyncke) <evyn...@cisco.com>, >> auth48archive@rfc-ed <auth48archive@rfc-editor.org> >> Subject: Re: AUTH48: RFC-to-be 9672 <draft-wkumari-rfc8110-to-ieee-02> for >> your review >> >> Hi Dan, >> >> Thanks for your reply. We updated the text in the Introduction. Note that >> we also added a placeholder for an informative reference to IEEE Std >> 802.11-2024. We will wait to hear further regarding publication of that >> document. >> >> The current files are available here: >> https://www.rfc-editor.org/authors/rfc9672.xml >> https://www.rfc-editor.org/authors/rfc9672.txt >> https://www.rfc-editor.org/authors/rfc9672.pdf >> https://www.rfc-editor.org/authors/rfc9672.html >> >> Diffs highlighting the most recent updates only: >> https://www.rfc-editor.org/authors/rfc9672-lastdiff.html >> https://www.rfc-editor.org/authors/rfc9672-lastrfcdiff.html >> >> AUTH48 diff: >> https://www.rfc-editor.org/authors/rfc9672-auth48diff.html >> >> Comprehensive diffs: >> https://www.rfc-editor.org/authors/rfc9672-diff.html >> https://www.rfc-editor.org/authors/rfc9672-rfcdiff.html >> >> Thank you, >> RFC Editor/sg >> >> >> >>> On Nov 7, 2024, at 8:21 AM, Harkins, Dan <daniel.hark...@hpe.com> wrote: >>> >>> >>> Hi Sandy, >>> >>> Yes, that update to section 1 looks great! Thanks. >>> >>> regards, >>> >>> Dan. >>> >>> -- >>> "the object of life is not to be on the side of the majority, but to >>> escape finding oneself in the ranks of the insane." – Marcus Aurelius >>> >>> On 11/7/24, 7:17 AM, "Sandy Ginoza" <sgin...@amsl.com> wrote: >>> >>> Hi Dan, >>> >>> Thanks for your input and for checking on the DOI. >>> >>> For the update to section 1, would this work? >>> >>> The IEEE 802.11 Working Group [IEEE_802.11] has requested the ability to >>> maintain and develop OWE (see [IEEE_LS]) to ensure that the protocol >>> remains in sync with the IEEE protocols. This document represents >>> concurrence that future work on OWE [RFC8110] will now occur in >>> the IEEE 802.11 Working Group. >>> >>> Thanks, >>> RFC Editor/sg >>> >>> >>>> On Nov 4, 2024, at 12:04 PM, Harkins, Dan <daniel.hark...@hpe.com> wrote: >>>> >>>> >>>> Hi Sandy (et al), >>>> >>>> I approve of publication. I do have a minor gripe regarding this change to >>>> section 1: >>>> >>>>> >>>>> Original: >>>>> [IEEE_802.11] has requested [IEEE_LS] that in order to allow for ongoing >>>>> maintenance and further development of the protocol, and to ensure that >>>>> the protocol remains in sync with the IEEE protocols, future work on the >>>>> protocol described in RFC8110 will now occur in >>>>> [IEEE_802.11]. This document is a concurrence. >>>>> >>>>> Perhaps: >>>>> The IEEE 802.11 Working Group [IEEE_802.11] has requested the ability to >>>>> maintain and develop OWE (see [IEEE_LS]). This document represents >>>>> concurrence that future work on OWE [RFC8110] will now occur in >>>>> the IEEE 802.11 Working Group to ensure that the protocol remains in sync >>>>> with the IEEE protocols. >>>>> >>>> >>>> I actually think the original here is better because it is the further >>>> development of the protocol in IEEE that would cause the loss of sync. So >>>> I think it's better to have those two things-- the cause of the result >>>> that we want to avoid-- connected. Maybe, "The IEEE 802.11 Working Group >>>> [IEEE_802.11] has requested that ongoing maintenance and development of >>>> the protocol be done in IEEE 802.11 in order to ensure the protocol >>>> remains in sync with other IEEE protocols. This document is a concurrence." >>>> >>>> But this is not a hill I care fight on much less die on, so I will defer >>>> to you. The similar change to section 2 looks fine though but I'd like to >>>> see this text in section 1 have these two things more connected. >>>> >>>> I'm going to the IEEE meeting next week and will inquire about a DOI for >>>> IEEE Std 802.11-2024. Hopefully it will be soon. >>>> >>>> regards, >>>> >>>> Dan. >>>> >>>> -- >>>> "the object of life is not to be on the side of the majority, but to >>>> escape finding oneself in the ranks of the insane." – Marcus Aurelius >>>> >>>> On 10/29/24, 1:34 PM, "Sandy Ginoza" <sgin...@amsl.com> wrote: >>>> >>>> Hi Warren, Dan, >>>> >>>> Regarding the following comment: >>>> >>>>> The only outstanding issue is that the IEEE stated that: "On September >>>>> 26, 2024, the IEEE SASB approved P802.11REVme/D7.0 to be published as >>>>> IEEE Std 802.11-2024. It is currently in publication editing and I expect >>>>> it will be available to the public in a month or two." and "Since IEEE >>>>> Std 802.11-2024 has been approved for publication, it can now be >>>>> referenced." >>>>> >>>>> But I don't think that it is actually published yet , and so does not >>>>> have a DOI number. I believe that the RFC Editor would prefer a more >>>>> formal reference (e.g with DOI) — as an example, RFC9542 references >>>>> 802.1AB as: >>>>> [IEEE802.1AB] >>>>> IEEE, "IEEE Standard for Local and metropolitan area >>>>> networks - Station and Media Access Control Connectivity >>>>> Discovery", IEEE Std 802.1AB-2016, >>>>> DOI 10.1109/IEEESTD.2016.7433915, March 2016, >>>>> >>>>> <https://urldefense.com/v3/__https://doi.org/10.1109/IEEESTD.2016.7433915__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhZmV4584$ >>>>> >. >>>>> >>>>> So, I'm not sure if we should wait till IEEE Std 802.11-2024 has a DOI, >>>>> or if it's fine without, or what you'd prefer. >>>>> >>>>> I have no opinion, so "I approve this RFC for publication" and do >>>>> whatever you want with the above reference issue[0]. >>>> >>>> This document does not contain a reference to the IEEE standard - >>>> references to [IEEE_802.11] are to the WG. Perhaps an in-text citation >>>> was intended in the following: >>>> >>>> Opportunistic Wireless Encryption (OWE) [RFC8110] is a mode of >>>> opportunistic security [RFC7435] for IEEE Std 802.11 that provides >>>> encryption of the wireless medium without authentication. >>>> >>>> >>>> If a reference is to be included, should it be listed as normative or >>>> informative? Assuming a reference is to be included, we would prefer to >>>> wait for publication. >>>> >>>> This is the status listed on >>>> <https://urldefense.com/v3/__https://www.ieee802.org/11/__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhNLJqMxs$ >>>> >: >>>> IEEE Std 802.11™-2024 was approved on September 26, 2024. Publication >>>> expected soon. >>>> >>>> >>>> Dan, we don’t believe we have heard from you regarding this document’s >>>> readiness for publication. Please review and let us know if updates are >>>> needed. >>>> >>>> We updated the document as indicated below and posted the revised files >>>> here: >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672.xml__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhemumOJ0$ >>>> >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672.txt__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhMPVWfnY$ >>>> >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672.pdf__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhKedDuJ0$ >>>> >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672.html__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhRMGgtFI$ >>>> >>>> >>>> AUTH48 diff: >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672-auth48diff.html__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMh2Jpf3yg$ >>>> >>>> >>>> Comprehensive diffs: >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672-diff.html__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMh_0Is6LM$ >>>> >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672-rfcdiff.html__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhC03tSoM$ >>>> >>>> >>>> >>>> Thanks, >>>> Sandy >>>> >>>>> On Oct 24, 2024, at 9:26 AM, Warren Kumari <war...@kumari.net> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Oct 21, 2024 at 7:52 PM, Sandy Ginoza <sgin...@amsl.com> wrote: >>>>> Hi Warren, >>>>> >>>>> Thanks for your note about the IEEE.11-2024 reference - we are reviewing. >>>>> >>>>> I don’t believe we have received a reply regarding the following items. >>>>> Please review and let us know if we may update the text. >>>>> >>>>> >>>>> >>>>> Doh, sorry. Approved, and thanks! >>>>> >>>>> >>>>> >>>>> 1) <!-- [rfced] Section 1: We are having trouble parsing this text. >>>>> Please consider whether the suggested text correctly conveys the intended >>>>> meaning. >>>>> >>>>> Original: >>>>> [IEEE_802.11] has requested [IEEE_LS] that in order to allow for ongoing >>>>> maintenance and further development of the protocol, and to ensure that >>>>> the protocol remains in sync with the IEEE protocols, future work on the >>>>> protocol described in RFC8110 will now occur in >>>>> [IEEE_802.11]. This document is a concurrence. >>>>> >>>>> Perhaps: >>>>> The IEEE 802.11 Working Group [IEEE_802.11] has requested the ability to >>>>> maintain and develop OWE (see [IEEE_LS]). This document represents >>>>> concurrence that future work on OWE [RFC8110] will now occur in >>>>> the IEEE 802.11 Working Group to ensure that the protocol remains in sync >>>>> with the IEEE protocols. >>>>> --> >>>>> >>>>> >>>>> >>>>> LGTM! >>>>> >>>>> >>>>> 2) <!-- [rfced] Section 2: If the update above is accepted, may we make a >>>>> similar change here? >>>>> >>>>> Original: >>>>> At the request of [IEEE_802.11], in order to allow for ongoing >>>>> maintenance and further development of the protocol, and to ensure that >>>>> the protocol remains in sync with the IEEE protocols, this document >>>>> specifies that future work on the protocol described in RFC8110 will now >>>>> occur in [IEEE_802.11]. >>>>> >>>>> The protocol defined in RFC8110 will be duplicated in [IEEE_802.11] such >>>>> that that document alone will be enough to implement it and any further >>>>> maintenance or modification of the protocol will be performed in IEEE >>>>> under its policies and procedures. >>>>> >>>>> Perhaps: >>>>> This document represents concurrence that future work on OWE [RFC8110] >>>>> will now occur in the IEEE 802.11 Working Group [IEEE_802.11] to ensure >>>>> that the protocol remains in sync with the IEEE protocols. >>>>> >>>>> The OWE protocol [RFC8110] will be duplicated by the IEEE 802.11 Working >>>>> Group [IEEE_802.11] such that the document alone will be enough to >>>>> implement, maintain, and modify the protocol within the IEEE under its >>>>> policies and procedures. >>>>> --> >>>>> >>>>> >>>>> >>>>> LGTM. >>>>> >>>>> Thank you! >>>>> W >>>>> >>>>> >>>>> >>>>> Thank you, >>>>> RFC Editor/sg >>>>> >>>>> On Oct 18, 2024, at 12:51 PM, Warren Kumari <war...@kumari.net> wrote: >>>>> >>>>> Inline…. >>>>> >>>>> On Fri, Oct 11, 2024 at 4:56 PM, <rfc-edi...@rfc-editor.org> wrote: >>>>> *****IMPORTANT***** >>>>> >>>>> Updated 2024/10/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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMh7mdbDnE$ >>>>> ). >>>>> >>>>> 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://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhA89-Luo$ >>>>> ). >>>>> >>>>> * 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhtz4Ncf0$ >>>>> >. >>>>> >>>>> * 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhk2LNzgM$ >>>>> >>>>> >>>>> * The archive itself: >>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMh-jmd0b4$ >>>>> >>>>> >>>>> * 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 >>>>> >>>>> No changes, thank you very much, RFC Ed. >>>>> >>>>> The only outstanding issue is that the IEEE stated that: "On September >>>>> 26, 2024, the IEEE SASB approved P802.11REVme/D7.0 to be published as >>>>> IEEE Std 802.11-2024. It is currently in publication editing and I expect >>>>> it will be available to the public in a month or two." and "Since IEEE >>>>> Std 802.11-2024 has been approved for publication, it can now be >>>>> referenced." >>>>> >>>>> But I don't think that it is actually published yet , and so does not >>>>> have a DOI number. I believe that the RFC Editor would prefer a more >>>>> formal reference (e.g with DOI) — as an example, RFC9542 references >>>>> 802.1AB as: >>>>> [IEEE802.1AB] >>>>> IEEE, "IEEE Standard for Local and metropolitan area networks - Station >>>>> and Media Access Control Connectivity Discovery", IEEE Std 802.1AB-2016, >>>>> DOI 10.1109/IEEESTD.2016.7433915, March 2016, >>>>> <https://urldefense.com/v3/__https://doi.org/10.1109/IEEESTD.2016.7433915__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhZmV4584$ >>>>> >. >>>>> >>>>> So, I'm not sure if we should wait till IEEE Std 802.11-2024 has a DOI, >>>>> or if it's fine without, or what you'd prefer. >>>>> >>>>> I have no opinion, so "I approve this RFC for publication" and do >>>>> whatever you want with the above reference issue[0]. >>>>> >>>>> W >>>>> [0]: That sounded snarky, but no snark intended… >>>>> 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672.xml__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhemumOJ0$ >>>>> >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672.html__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhRMGgtFI$ >>>>> >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672.pdf__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhKedDuJ0$ >>>>> >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672.txt__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhMPVWfnY$ >>>>> >>>>> >>>>> Diff file of the text: >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672-diff.html__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMh_0Is6LM$ >>>>> >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672-rfcdiff.html__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhC03tSoM$ >>>>> (side by side) >>>>> >>>>> Diff of the XML: >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672-xmldiff1.html__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhegGI5WU$ >>>>> >>>>> >>>>> Tracking progress >>>>> ----------------- >>>>> >>>>> The details of the AUTH48 status of your document are here: >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9672__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhPGaPN3Q$ >>>>> >>>>> >>>>> Please let us know if you have any questions. >>>>> >>>>> Thank you for your cooperation, >>>>> >>>>> RFC Editor >>>>> >>>>> -------------------------------------- >>>>> RFC 9672 (draft-wkumari-rfc8110-to-ieee-02) >>>>> >>>>> Title : Transferring Opportunistic Wireless Encryption to the IEEE 802.11 >>>>> Working Group Author(s) : W. Kumari, D. Harkins WG Chair(s) : >>>>> Area Director(s) : >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
