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-editor@ > 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://urldefense.com/v3/__https:/www.rfc-editor.org/authors/rfc9672.xml__;!!NpxR!kNibKrnywT5_R2bag2cDabMLkEcoa77ozt_fGEHgKy4MsF_Ji2-EY657HtCb3rP66dQ0XDWh9V1hjqyj$> > https://www.rfc-editor.org/authors/rfc9672.txt > <https://urldefense.com/v3/__https:/www.rfc-editor.org/authors/rfc9672.txt__;!!NpxR!kNibKrnywT5_R2bag2cDabMLkEcoa77ozt_fGEHgKy4MsF_Ji2-EY657HtCb3rP66dQ0XDWh9ardON_W$> > https://www.rfc-editor.org/authors/rfc9672.pdf > <https://urldefense.com/v3/__https:/www.rfc-editor.org/authors/rfc9672.pdf__;!!NpxR!kNibKrnywT5_R2bag2cDabMLkEcoa77ozt_fGEHgKy4MsF_Ji2-EY657HtCb3rP66dQ0XDWh9USBH7zE$> > https://www.rfc-editor.org/authors/rfc9672.html > <https://urldefense.com/v3/__https:/www.rfc-editor.org/authors/rfc9672.html__;!!NpxR!kNibKrnywT5_R2bag2cDabMLkEcoa77ozt_fGEHgKy4MsF_Ji2-EY657HtCb3rP66dQ0XDWh9SJ_Jm7A$> > > Diffs highlighting the most recent updates only: > https://www.rfc-editor.org/authors/rfc9672-lastdiff.html > <https://urldefense.com/v3/__https:/www.rfc-editor.org/authors/rfc9672-lastdiff.html__;!!NpxR!kNibKrnywT5_R2bag2cDabMLkEcoa77ozt_fGEHgKy4MsF_Ji2-EY657HtCb3rP66dQ0XDWh9eDGVC1R$> > https://www.rfc-editor.org/authors/rfc9672-lastrfcdiff.html > <https://urldefense.com/v3/__https:/www.rfc-editor.org/authors/rfc9672-lastrfcdiff.html__;!!NpxR!kNibKrnywT5_R2bag2cDabMLkEcoa77ozt_fGEHgKy4MsF_Ji2-EY657HtCb3rP66dQ0XDWh9ZV8LCjE$> > > AUTH48 diff: > https://www.rfc-editor.org/authors/rfc9672-auth48diff.html > <https://urldefense.com/v3/__https:/www.rfc-editor.org/authors/rfc9672-auth48diff.html__;!!NpxR!kNibKrnywT5_R2bag2cDabMLkEcoa77ozt_fGEHgKy4MsF_Ji2-EY657HtCb3rP66dQ0XDWh9UsuVE6R$> > > Comprehensive diffs: > https://www.rfc-editor.org/authors/rfc9672-diff.html > <https://urldefense.com/v3/__https:/www.rfc-editor.org/authors/rfc9672-diff.html__;!!NpxR!kNibKrnywT5_R2bag2cDabMLkEcoa77ozt_fGEHgKy4MsF_Ji2-EY657HtCb3rP66dQ0XDWh9Uo7glJ9$> > https://www.rfc-editor.org/authors/rfc9672-rfcdiff.html > <https://urldefense.com/v3/__https:/www.rfc-editor.org/authors/rfc9672-rfcdiff.html__;!!NpxR!kNibKrnywT5_R2bag2cDabMLkEcoa77ozt_fGEHgKy4MsF_Ji2-EY657HtCb3rP66dQ0XDWh9TuxwUNu$> > > 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.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.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.pdf__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhKedDuJ0$> > >> 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.html__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhRMGgtFI$> > >> > >> AUTH48 diff: > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/ > rfc9672-auth48diff. > html__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMh2Jpf3yg$ > <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-diff.html__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMh_0Is6LM$> > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/ > rfc9672-rfcdiff. > html__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhC03tSoM$ > <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$ > <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$ > <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$ > <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.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.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.pdf__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhKedDuJ0$> > > >>> 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.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-diff.html__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMh_0Is6LM$> > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/ > rfc9672-rfcdiff. > html__;!!NpxR!jnakUaRvodfLmxupOdc0phBycK1YTKkEKUbUhXX-1ccu6JLqdEIbNqY1NSkDJBDH1CxaoQMhC03tSoM$ > <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$ > <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$ > <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
