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://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
