Hi Dan - thanks for your confirmation! The RFC will be announced shortly.
> Hope everyone has a Merry Christmas and a wonderful New Year. Thanks, and same to you - happy holidays! Sandy > On Dec 23, 2024, at 9:13 AM, Harkins, Dan <daniel.hark...@hpe.com> wrote: > > > Approved! > > Hope everyone has a Merry Christmas and a wonderful New Year. > > 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/23/24, 8:12 AM, "Sandy Ginoza" <sgin...@amsl.com> wrote: > > Hi Warren and Dan, > > Thanks for your confirmation Warren. Dan, we’ll continue with publication > once you confirm as well. > > Thanks, and happy holidays! > RFC Editor/sg > > >> On Dec 22, 2024, at 8:24 AM, Warren Kumari <war...@kumari.net> wrote: >> >> Approved! >> >> Thank you very much! >> W >> >> >> On Tue, Dec 17 2024 at 6:39 PM, Sandy Ginoza <sgin...@amsl.com> wrote: >> 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672.xml__;!!NpxR!kU47jQAzzJf4BUxDQyPNTvMYks_2d_lfmX7FC3pKlZiZ34DKcSkSFSDqECKcMZ7hdHY5ghntSg15zM0$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672.txt__;!!NpxR!kU47jQAzzJf4BUxDQyPNTvMYks_2d_lfmX7FC3pKlZiZ34DKcSkSFSDqECKcMZ7hdHY5ghnt7gVHR5c$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672.pdf__;!!NpxR!kU47jQAzzJf4BUxDQyPNTvMYks_2d_lfmX7FC3pKlZiZ34DKcSkSFSDqECKcMZ7hdHY5ghntR5PAPrE$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672.html__;!!NpxR!kU47jQAzzJf4BUxDQyPNTvMYks_2d_lfmX7FC3pKlZiZ34DKcSkSFSDqECKcMZ7hdHY5ghntT5hMkLY$ >> >> >> Diffs highlighting the most recent change only: >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672-lastdiff.html__;!!NpxR!kU47jQAzzJf4BUxDQyPNTvMYks_2d_lfmX7FC3pKlZiZ34DKcSkSFSDqECKcMZ7hdHY5ghnt8weaW5I$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672-lastrfcdiff.html__;!!NpxR!kU47jQAzzJf4BUxDQyPNTvMYks_2d_lfmX7FC3pKlZiZ34DKcSkSFSDqECKcMZ7hdHY5ghnt87Btykg$ >> >> >> AUTH48 diff: >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672-auth48diff.html__;!!NpxR!kU47jQAzzJf4BUxDQyPNTvMYks_2d_lfmX7FC3pKlZiZ34DKcSkSFSDqECKcMZ7hdHY5ghntYXZW2vA$ >> >> >> Comprehensive diffs: >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672-diff.html__;!!NpxR!kU47jQAzzJf4BUxDQyPNTvMYks_2d_lfmX7FC3pKlZiZ34DKcSkSFSDqECKcMZ7hdHY5ghntBwYhkt0$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672-rfcdiff.html__;!!NpxR!kU47jQAzzJf4BUxDQyPNTvMYks_2d_lfmX7FC3pKlZiZ34DKcSkSFSDqECKcMZ7hdHY5ghnt9lSNWQg$ >> >> >> 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672.xml__;!!NpxR!kU47jQAzzJf4BUxDQyPNTvMYks_2d_lfmX7FC3pKlZiZ34DKcSkSFSDqECKcMZ7hdHY5ghntSg15zM0$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672.txt__;!!NpxR!kU47jQAzzJf4BUxDQyPNTvMYks_2d_lfmX7FC3pKlZiZ34DKcSkSFSDqECKcMZ7hdHY5ghnt7gVHR5c$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672.pdf__;!!NpxR!kU47jQAzzJf4BUxDQyPNTvMYks_2d_lfmX7FC3pKlZiZ34DKcSkSFSDqECKcMZ7hdHY5ghntR5PAPrE$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672.html__;!!NpxR!kU47jQAzzJf4BUxDQyPNTvMYks_2d_lfmX7FC3pKlZiZ34DKcSkSFSDqECKcMZ7hdHY5ghntT5hMkLY$ >> >> >> Diffs highlighting the most recent updates only: >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672-lastdiff.html__;!!NpxR!kU47jQAzzJf4BUxDQyPNTvMYks_2d_lfmX7FC3pKlZiZ34DKcSkSFSDqECKcMZ7hdHY5ghnt8weaW5I$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672-lastrfcdiff.html__;!!NpxR!kU47jQAzzJf4BUxDQyPNTvMYks_2d_lfmX7FC3pKlZiZ34DKcSkSFSDqECKcMZ7hdHY5ghnt87Btykg$ >> >> >> AUTH48 diff: >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672-auth48diff.html__;!!NpxR!kU47jQAzzJf4BUxDQyPNTvMYks_2d_lfmX7FC3pKlZiZ34DKcSkSFSDqECKcMZ7hdHY5ghntYXZW2vA$ >> >> >> Comprehensive diffs: >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672-diff.html__;!!NpxR!kU47jQAzzJf4BUxDQyPNTvMYks_2d_lfmX7FC3pKlZiZ34DKcSkSFSDqECKcMZ7hdHY5ghntBwYhkt0$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9672-rfcdiff.html__;!!NpxR!kU47jQAzzJf4BUxDQyPNTvMYks_2d_lfmX7FC3pKlZiZ34DKcSkSFSDqECKcMZ7hdHY5ghnt9lSNWQg$ >> >> >> 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
