Totally not saying this to be insensitive but I swear I'm that dumb, slow or lazy. But I cannot find question 29 to 37 to save my life on any of these links in. I completely blindly missing it.?
Sorry for the ignorance Corinne On Wed, Feb 18, 2026, 17:06 <[email protected]> wrote: > Send auth48archive mailing list submissions to > [email protected] > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of auth48archive digest..."Today's Topics: > > 1. Re: [AD] Document intake questions about > <draft-ietf-modpod-group-processes-16> > (Sarah Tarrant) > 2. Re: AUTH48: RFC-to-be 9913 <draft-ietf-raw-technologies-17> for your > review > (Janos Farkas) > > > > ---------- Forwarded message ---------- > From: Sarah Tarrant <[email protected]> > To: Roman Danyliw <[email protected]>, Lars Eggert <[email protected]>, Eliot > Lear <[email protected]> > Cc: Sandy Ginoza <[email protected]>, "[email protected]" < > [email protected]>, "[email protected]" <[email protected]>, " > [email protected]" <[email protected]>, RFC Editor < > [email protected]>, "[email protected]" < > [email protected]> > Bcc: > Date: Wed, 18 Feb 2026 15:35:22 -0600 > Subject: [auth48] Re: [AD] Document intake questions about > <draft-ietf-modpod-group-processes-16> > Hi all, > > Based on albeit weak preferences, we will mark this draft as obsoleting > BCP83 and will assign a new BCP number. > > Thank you for your time, > Sarah Tarrant > RFC Production Center > > > On Feb 17, 2026, at 3:40 PM, Sarah Tarrant < > [email protected]> wrote: > > > > Hi Roman, > > > > Thank you for your reply. > > > > I'll be on the lookout for any responses. > > > > Sincerely, > > Sarah Tarrant > > RFC Production Center > > > >> On Feb 17, 2026, at 11:53 AM, Roman Danyliw <[email protected]> wrote: > >> > >> Good afternoon Sarah! > >> > >> If all things are equal and nothing needed to be changed with the > current text, of these two options: > >> > >>> There are two possible approaches: > >>> • Replace RFC 3683 in BCP83 with this document; or > >>> • Obsolete BCP83 entirely and assign a new number. > >> > >> I have a weak preference for obsoleting bcp83 and assigning a new > number to create a clear break. > >> > >> Please give Lars (as the other author) and MODPOD chairs 24 hours to > weigh in. If nothing is heard, let's proceed with the new bcp number. > >> > >> Thanks, > >> Roman > >> > >> -----Original Message----- > >> From: Sarah Tarrant <[email protected]> > >> Sent: Tuesday, February 17, 2026 12:45 PM > >> To: Roman Danyliw <[email protected]> > >> Cc: Sandy Ginoza <[email protected]>; Lars Eggert < > [email protected]>; [email protected]; [email protected]; > [email protected]; RFC Editor <[email protected]>; > [email protected]; Eliot Lear <[email protected]> > >> Subject: Re: [AD] Document intake questions about > <draft-ietf-modpod-group-processes-16> > >> > >> Warning: External Sender - do not click links or open attachments > unless you recognize the sender and know the content is safe. > >> > >> > >> Hi Roman, > >> > >> Just a friendly reminder that we await your feedback on this draft's > BCP status. Please see email thread for full conversation. > >> > >> Sincerely, > >> Sarah Tarrant > >> RFC Production Center > >> > >>> On Feb 12, 2026, at 7:00 AM, Eliot Lear <[email protected]> wrote: > >>> > >>> Hi Sandy, > >>> On 11.02.2026 22:38, Sandy Ginoza wrote: > >>>> Hi again, > >>>> > >>>> Just a bit of additional information, as this document updates the > following RFCs which are part of 3 different BCPs: > >>>> > >>>> Obsoletes RFC 3683, BCP 83: A Practice for Revoking Posting Rights to > >>>> IETF Mailing Lists Obsoletes RFC 3934, BCP 25: Updates to RFC 2418 > >>>> Regarding the Management of IETF Mailing Lists Updates RFC 2418, BCP > >>>> 25: IETF Working Group Guidelines and Procedures Updates RFC 9245, > >>>> BCP 45: IETF Discussion List Charter > >>>> > >>>> Please review and let us know if adding > draft-ietf-modpod-group-processes to BCP 83 makes the most sense. > >>> There are two possible approaches: > >>> • Replace RFC 3683 in BCP83 with this document; or > >>> • Obsolete BCP83 entirely and assign a new number. > >>> I have no strong preference either way. > >>> Eliot > >>> <OpenPGP_0x87B66B46D9D27A33.asc> > >> > > > > > > > ---------- Forwarded message ---------- > From: Janos Farkas <[email protected]> > To: Kaelin Foody <[email protected]> > Cc: "[email protected]" <[email protected]>, Pascal > Thubert <[email protected]>, "[email protected]" < > [email protected]>, "[email protected]" <[email protected]>, " > [email protected]" <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" <[email protected]>, > "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, " > [email protected]" <[email protected]> > Bcc: > Date: Wed, 18 Feb 2026 22:06:27 +0000 > Subject: [auth48] Re: AUTH48: RFC-to-be 9913 > <draft-ietf-raw-technologies-17> for your review > Hi, > > Just trying to help with 802.11ax: > https://standards.ieee.org/ieee/802.11ax/7180/ > The reason for the ax amendment being superseded is that it has been > incorporated into the 2020 revision of the base standard, i.e., IEEE Std > 802.11-2020: https://standards.ieee.org/ieee/802.11/7028/, where 802.11ax > is listed among the incorporated amendments. > Actually, IEEE Std 802.11-2020 has been superseded by the most recent > revision: IEEE Std 802.11-2024: > https://standards.ieee.org/ieee/802.11/10548/ > > So, the actual reference to the technical content is IEEE Std 802.11-2024. > > One way could be: > "as originally specified by IEEE Std 802.11ax, which has been incorporated > to IEEE Std 802.11-2024" > or something alike. > > My 2 cetns, > Janos > > -----Original Message----- > From: Kaelin Foody <[email protected]> > Sent: Wednesday, February 18, 2026 9:19 PM > To: Janos Farkas <[email protected]> > Cc: [email protected]; Pascal Thubert <[email protected]>; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; [email protected]; > [email protected] > Subject: Re: AUTH48: RFC-to-be 9913 <draft-ietf-raw-technologies-17> for > your review > > [You don't often get email from [email protected]. Learn why > this is important at https://aka.ms/LearnAboutSenderIdentification ] > > All, > > Thank you all for your thorough responses and reviews. > > We have updated the document to reflect responses from Pascal, Dave, Xavi, > Corinna, and Janos thus far. You may find the updated files at the end of > this email. > > We only await responses to questions 29-37. > > Pending questions are noted on the AUTH48 status page for this document > below: > https://www.rfc-editor.org/auth48/rfc9913 > > > In addition, we have a few follow-up notes and questions: > > a) For question #43 below, how should we proceed with updating the > superseded reference [IEEE Std 802.11ax]? > > We ask because we are not certain if [IEEE Std 802.3-2022] is the same > IEEE standard as [IEEE Std 802.11ax]. > > A list of the active versions that replaced IEEE Std 802.11ax is available > here: https://ieeexplore.ieee.org/document/9442429/versions. > > > 43) <!-- [rfced] This reference has been superseded, but we cannot > > locate a more recent version. Please review and let us know if any > > updates are needed or if the current is correct. > > > > See: > > https://ieee/ > > xplore.ieee.org%2Fdocument%2F9442429&data=05%7C02%7Cjanos.farkas% > 40ericsson.com%7C50d72988563841aad6fc08de6f2b0f77%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639070428183408320%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=v99iJJtai9I6O0J%2FweHsclVayD%2FtRvPqz%2F6mOuNyMMk%3D&reserved=0 > (superseded) <JF> The most recent revision of 802.3 has been completed in > 2022. > > Please update the reference to IEEE Std 802.3-2022 I think these URLs > > work: > > https://stan/ > > dards.ieee.org%2Fieee%2F802.3%2F10422%2F&data=05%7C02%7Cjanos.farkas%4 > > 0ericsson.com%7C50d72988563841aad6fc08de6f2b0f77%7C92e84cebfbfd47abbe5 > > 2080c6b87953f%7C0%7C0%7C639070428183427577%7CUnknown%7CTWFpbGZsb3d8eyJ > > FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb > > CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=I7YnMd64AAxC3s6E8yi211eXb67AhQc > > VXRzUhM4KHEA%3D&reserved=0 > > https://stan/ > > dards.ieee.org%2Fieee%2F802.3%2F10422%2F&data=05%7C02%7Cjanos.farkas%4 > > 0ericsson.com%7C50d72988563841aad6fc08de6f2b0f77%7C92e84cebfbfd47abbe5 > > 2080c6b87953f%7C0%7C0%7C639070428183444474%7CUnknown%7CTWFpbGZsb3d8eyJ > > FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb > > CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xGreb32h3lkdHYVOLt0cu%2F0OCowD1 > > JDWsVGhlgCbM1Y%3D&reserved=0 > > </JF> > > > > > > Original: > > [IEEE Std 802.11ax] > > IEEE standard for Information Technology, "802.11ax: > > Enhancements for High Efficiency WLAN", 2021, > > <https://ieeexplore.ieee.org/document/9442429>. > > —> > > > b) All of the items below have already been updated accordingly, but > please review for accuracy: > > - For question #2 below, we have made Pascal’s requested update, but have > made slight adjustments to the punctuation for readability. Please review > these changes in the Abstract and let us know any objections. > > > 2) <!-- [rfced] Should "/" here be updated to "or" or "and"? > > > > Original: > > This document surveys the short and middle range radio technologies > > that are suitable to provide a Deterministic Networking / Reliable > > and Available Wireless (RAW) service over, presents the > > characteristics that RAW may leverage, and explores the applicability > > of the technologies to carry deterministic flows, as of its time of > > publication. > > > > Perhaps: > > This document surveys the short- and middle-range radio technologies > > over which providing Deterministic Networking (DetNet) or Reliable > > and Available Wireless (RAW) service is suitable, presents the > > characteristics that RAW may leverage, and explores the applicability > > of the technologies to carry deterministic flows, as of the time of > > publication. > > --> > > Pascal> Many replace "/" by "and more specifically" since RAW is a > > subset of detnet > > > - For question #5 below, we have left these titles as is, but we have > added "Wireless Local Area Networks (WLAN)" to the title of Section 4 per > Janos’s note. > > > 5) <!-- [rfced] Please review the titles of Sections 4-7 (the > > sections for the technologies reviewed by this document). Would it be > > helpful to readers to update the titles of Sections 4 and 5 as shown > > below? Note that the suggested aligns with the last sentence in the > > abstract and a similar sentence in the Introduction. > > > > Original: > > 4. IEEE 802.11 > > 5. IEEE 802.15.4 Timeslotted Channel Hopping > > 6. 5G > > 7. L-band Digital Aeronautical Communications System > > > > Perhaps: > > 4. Wi-Fi > > 5. Time-Slotted Channel Hopping (TSCH) > > 6. 5G > > 7. L-band Digital Aeronautical Communications System (LDACS) > > --> > > > > Pascal> I'd rather retain the original titles. Wi-Fiis a subset of > > Pascal> 802.11 and the text really deals with .11 > > <JF> > > I agree with Pascal, better to keep 802.11. > > If text is wanted, then the title of the 802.11 standard could be added > to have: > > 4. IEEE 802.11 Wireless Local Area Networks (WLAN) </JF> > > > - For question #51 below, note that we have updated these terms per Xavi’s > rationale. > > > 51) <!-- [rfced] Terminology: > > > > a) We note inconsistencies in the terms below throughout the text. > > Should these be uniform? If so, please let us know which form is > preferred. > > > > ChannelOffset vs. channeloffset vs. channelOffset > > Note: "channelOffset" is used in RFCs 8480, 9030, and 9033. > > > > slotoffset vs. slotOffset > > Note: "slotoffset" is used in RFCs 8480, 9030, and 9033. > > > > slotFrame vs. slotframe > > Note: "slotframe" is used in RFC 9030. > > > > timeSlot vs. timeslot > > Note: "timeSlot" is used in RFC 9030. > > > > XV: Please align terminology with RFC 9030 and others usage: > > channelOffset > > slotOffset > > slotframe > > timeSlot > > > - For item #39 below, note that we will sort the references alphabetically > once AUTH48 is complete and all other items have been closed (as to not > make the diffs difficult to read). > > > 39) <!-- [rfced] Would you like the references to be alphabetized or > > left in their current order? > > --> > > > > Answer: This does not matter for us. It is your choice > > > — FILES (please refresh): — > > The updated files have been posted here: > https://www.rfc-editor.org/authors/rfc9913.txt > https://www.rfc-editor.org/authors/rfc9913.pdf > https://www.rfc-editor.org/authors/rfc9913.html > https://www.rfc-editor.org/authors/rfc9913.xml > > Diff files showing changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9913-auth48diff.html > https://www.rfc-editor.org/authors/rfc9913-auth48rfcdiff.html (side by > side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9913-diff.html > https://www.rfc-editor.org/authors/rfc9913-rfcdiff.html (side by side) > > > Thank you, > > Kaelin Foody > RFC Production Center > > > > On Feb 16, 2026, at 4:21 PM, Janos Farkas <Janos.Farkas= > [email protected]> wrote: > > > > Hi, > > Indeed, many thanks for your efforts on this document! > > Please find some notes from me marked with <JF> in-line. > > Best regards, > > Janos > > From: Pascal Thubert <[email protected]> > > Sent: Tuesday, February 10, 2026 4:32 PM > > To: [email protected] > > Cc: [email protected]; [email protected]; > > [email protected]; Janos Farkas <[email protected]>; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected] > > Subject: Re: AUTH48: RFC-to-be 9913 <draft-ietf-raw-technologies-17> > > for your review Dear RFC Editor, Many thanks for your hard and deep > > work on this document. Please find below the answers of the questions I > tagged for myself and for all author: > > 2) <!-- [rfced] Should "/" here be updated to "or" or "and"? > > > > Original: > > This document surveys the short and middle range radio technologies > > that are suitable to provide a Deterministic Networking / Reliable > > and Available Wireless (RAW) service over, presents the > > characteristics that RAW may leverage, and explores the applicability > > of the technologies to carry deterministic flows, as of its time of > > publication. > > > > Perhaps: > > This document surveys the short- and middle-range radio technologies > > over which providing Deterministic Networking (DetNet) or Reliable > > and Available Wireless (RAW) service is suitable, presents the > > characteristics that RAW may leverage, and explores the applicability > > of the technologies to carry deterministic flows, as of the time of > > publication. > > --> > > Pascal> Many replace "/" by "and more specifically" since RAW is a > > subset of detnet > > > > 3) <!-- [rfced] The series in this sentence is difficult to read > > because of the many commas. We have updated to use semicolons to > > separate the items in the series as shown below; please review for > accuracy. > > > > Original: > > > > The control loop involves communication monitoring through > > Operations, Administration and Maintenance (OAM), path control > > through a Path computation Element (PCE) and a runtime distributed > > Path Selection Engine (PSE) and extended packet replication, > > elimination, and ordering functions (PREOF). > > > > Current: > > > > The control loop involves communication monitoring through > > Operations, Administration, and Maintenance (OAM); path control > > through a Path Computation Element (PCE) and a runtime distributed > > Path Selection Engine (PSE); and extended Packet Replication, > > Elimination, and Ordering Functions (PREOF). > > --> > > Pascal> OK > > > > 4) <!-- [rfced] We updated this text to point to Section 3 instead of > > Section 2 of draft-ietf-raw-architecture (RFC-to-be 9912). Please > confirm. > > > > Original: > > > > This document uses the terminology and acronyms defined in Section 2 > > of [RFC8655] and Section 2 of [I-D.ietf-raw-architecture]. > > > > Updated: > > > > This document uses the terminology and acronyms defined in Section 2 > > of [RFC8655] and Section 3 of [RFC9912]. > > --> > > Pascal> OK > > 5) <!-- [rfced] Please review the titles of Sections 4-7 (the > > sections for the technologies reviewed by this document). Would it be > > helpful to readers to update the titles of Sections 4 and 5 as shown > > below? Note that the suggested aligns with the last sentence in the > > abstract and a similar sentence in the Introduction. > > > > Original: > > 4. IEEE 802.11 > > 5. IEEE 802.15.4 Timeslotted Channel Hopping > > 6. 5G > > 7. L-band Digital Aeronautical Communications System > > > > Perhaps: > > 4. Wi-Fi > > 5. Time-Slotted Channel Hopping (TSCH) > > 6. 5G > > 7. L-band Digital Aeronautical Communications System (LDACS) > > --> > > > > Pascal> I'd rather retain the original titles. Wi-Fiis a subset of > > Pascal> 802.11 and the text really deals with .11 > > <JF> > > I agree with Pascal, better to keep 802.11. > > If text is wanted, then the title of the 802.11 standard could be added > to have: > > 4. IEEE 802.11 Wireless Local Area Networks (WLAN) </JF> > > 40) <!-- [rfced] Note that we removed spaces from some citation > > tags per Section 3.5 of RFC 7322 ("RFC Style Guide"). For example: > > > > Original: > > [IEEE Std 802.15.4] > > > > Updated: > > [IEEE802.15.4] > > --> > > Pascal> OK > > > > 41) <!-- [rfced] This reference points to a superseded version of IEEE > > Std 802.11; the most recent version was approved in 2024. May we > > update this reference to point to the most current version? > > > > See: > > https://ieee/ > > xplore.ieee.org%2Fdocument%2F9363693&data=05%7C02%7Cjanos.farkas%40eri > > csson.com%7C50d72988563841aad6fc08de6f2b0f77%7C92e84cebfbfd47abbe52080 > > c6b87953f%7C0%7C0%7C639070428183639903%7CUnknown%7CTWFpbGZsb3d8eyJFbXB > > 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI > > ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=w4QbMZIo8GQD%2BQ36jUP1MGuei6neI0uKA > > HSfkgVW4zs%3D&reserved=0 (superseded) > > https://ieee/ > > xplore.ieee.org%2Fdocument%2F10979691&data=05%7C02%7Cjanos.farkas%40er > > icsson.com%7C50d72988563841aad6fc08de6f2b0f77%7C92e84cebfbfd47abbe5208 > > 0c6b87953f%7C0%7C0%7C639070428183657733%7CUnknown%7CTWFpbGZsb3d8eyJFbX > > B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=c9L6HcT4qmurPtSnSDrm6WUQNxmSvdvdjZ > > 7MS2IRrAo%3D&reserved=0 (most current) > > > > Original: > > [IEEE Std 802.11] > > IEEE standard for Information Technology, "IEEE Standard > > 802.11 - IEEE Standard for Information Technology - > > Telecommunications and information exchange between > > systems Local and metropolitan area networks - Specific > > requirements - Part 11: Wireless LAN Medium Access Control > > (MAC) and Physical Layer (PHY) Specifications.", > > <https://ieeexplore.ieee.org/document/9363693>. > > --> > > > > > > 42) <!-- [rfced] This reference points to a superseded IEEE Std from > > 2018. The newest version of this IEEE Std was published in 2022. May > > we update this reference to point to the most recent version of the > standard? > > > > See: > > https://ieee/ > > xplore.ieee.org%2Fdocument%2F8457469&data=05%7C02%7Cjanos.farkas%40eri > > csson.com%7C50d72988563841aad6fc08de6f2b0f77%7C92e84cebfbfd47abbe52080 > > c6b87953f%7C0%7C0%7C639070428183729610%7CUnknown%7CTWFpbGZsb3d8eyJFbXB > > 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI > > ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9jlTYrFClPOpcdC7qNNOUz4H0jOOyKXu92Z > > mJv7Z48c%3D&reserved=0 (superseded) > > https://ieee/ > > xplore.ieee.org%2Fdocument%2F9844436&data=05%7C02%7Cjanos.farkas%40eri > > csson.com%7C50d72988563841aad6fc08de6f2b0f77%7C92e84cebfbfd47abbe52080 > > c6b87953f%7C0%7C0%7C639070428183769899%7CUnknown%7CTWFpbGZsb3d8eyJFbXB > > 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI > > ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TrBDoYkG3k38GaartAvKx%2FdyR1jx2aEaC > > pB70NQDA90%3D&reserved=0 (most current) > > > > Original: > > [IEEE802.3] > > IEEE, "IEEE Standard for Ethernet", IEEE 802.3-2018, > > <https://ieeexplore.ieee.org/document/8457469>. > > --> > > > > > > 43) <!-- [rfced] This reference has been superseded, but we cannot > > locate a more recent version. Please review and let us know if any > > updates are needed or if the current is correct. > > > > See: > > https://ieee/ > > xplore.ieee.org%2Fdocument%2F9442429&data=05%7C02%7Cjanos.farkas% > 40ericsson.com%7C50d72988563841aad6fc08de6f2b0f77%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639070428183809318%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qUhwXo3TyjCTmEMB9shVnAQD90xrEzwQQNGlKyIZfXQ%3D&reserved=0 > (superseded) <JF> The most recent revision of 802.3 has been completed in > 2022. > > Please update the reference to IEEE Std 802.3-2022 I think these URLs > > work: > > https://stan/ > > dards.ieee.org%2Fieee%2F802.3%2F10422%2F&data=05%7C02%7Cjanos.farkas%4 > > 0ericsson.com%7C50d72988563841aad6fc08de6f2b0f77%7C92e84cebfbfd47abbe5 > > 2080c6b87953f%7C0%7C0%7C639070428183828136%7CUnknown%7CTWFpbGZsb3d8eyJ > > FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb > > CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=PYOq4w%2BuLxwa2p9QwtBQVm0a9iEjb > > tqbvsTyZBKS1Cc%3D&reserved=0 > > https://stan/ > > dards.ieee.org%2Fieee%2F802.3%2F10422%2F&data=05%7C02%7Cjanos.farkas%4 > > 0ericsson.com%7C50d72988563841aad6fc08de6f2b0f77%7C92e84cebfbfd47abbe5 > > 2080c6b87953f%7C0%7C0%7C639070428183843873%7CUnknown%7CTWFpbGZsb3d8eyJ > > FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb > > CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WNQEFo5o%2B1LFtx4jR06ASbsaD01bR > > Cr1BWTomt5nvNM%3D&reserved=0 > > </JF> > > > > > > Original: > > [IEEE Std 802.11ax] > > IEEE standard for Information Technology, "802.11ax: > > Enhancements for High Efficiency WLAN", 2021, > > <https://ieeexplore.ieee.org/document/9442429>. > > --> > > > > For the 4 items above, OK to use the updated reference and happy that > you are now using dates in recurring IEEE specs like IEEE802.11 > > 44) <!-- [rfced] Note that we have made substantial updates to the > > References section of this document for consistency and access. We > > have added URLs and/or DOIs, and we have corrected some incorrect > > reference information such as missing authors, incorrect dates, etc. > > > > We have already updated the references below as follows. Please review > > for accuracy and let us know if you have any objections. > > Pascal> many thanks, no objection > > > > a) Based on the context of the citations to this reference, we updated > > this reference entry to point to the 2015 revision. > > > > Original: > > [IEEE Std 802.15.4] > > IEEE standard for Information Technology, "IEEE Std > > 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) > > and Physical Layer (PHY) Specifications for Low-Rate > > Wireless Personal Area Networks". > > > > Updated: > > [IEEE802.15.4] > > IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE > > Std 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875, > > <https://doi.org/10.1109/IEEESTD.2016.7460875>. > > > > > > b) We updated this reference entry as shown below as it is now > > published as an IEEE standard. > > > > Original: > > [IEEE 802.11be] > > IEEE standard for Information Technology, "802.11be: > > Extreme High Throughput PAR", > > <https://mentor.ieee.org/802.11/dcn/18/11-18-1231-04-0eht- > > eht-draft-proposed-par.docx>. > > > > Updated: > > [IEEE802.11be] > > IEEE, "IEEE Standard for Information technology - > > Telecommunications and information exchange between > > systems Local and metropolitan area networks - Specific > > requirements - Part 11: Wireless LAN Medium Access Control > > (MAC) and Physical Layer (PHY) Specifications Amendment 2: > > Enhancements for Extremely High Throughput (EHT)", IEEE > > Std 802.11be-2024, DOI 10.1109/IEEESTD.2024.11090080, > > <https://ieeexplore.ieee.org/document/11090080>. > > > > > > c) The original URL for this reference pointed to a page that results > > in a 404 error. We have updated the URL and reference to point to the > > home page for > > ISA100 Wireless. > > > > Original: > > [ISA100.11a] > > ISA/IEC, "ISA100.11a, Wireless Systems for Automation, > > also IEC 62734", 2011, <http://www.isa100wci.org/en- > > US/Documents/PDF/3405-ISA100-WirelessSystems-Future-broch- > > WEB-ETSI.aspx>. > > > > Updated: > > [ISA100.11a] > > ISA, "ISA100 Wireless", ANSI/ISA-100.11a-2011 (IEC 26743), > > <https://isa100wci.org/about-isa100-wireless?_gl=1*19xrxgo > > *_up*MQ..*_ga*NDczNjkxOTQ1LjE3NjI0NjQ2NDk.*_ga_L2KSW4EHCS* > > czE3NjI0NjQ2NDkkbzEkZzEkdDE3NjI0NjQ3MzQkajYwJGwwJGgw>. > > Pascal> all OK on my side > > > > d) The original URL for this reference redirects to a page for the > > FieldComm Group (https://www.fieldcommgroup.org/). > > > > Original URL: > > http://www.h/ > > artcomm.org%2F&data=05%7C02%7Cjanos.farkas%40ericsson.com%7C50d7298856 > > 3841aad6fc08de6f2b0f77%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C63 > > 9070428184132336%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO > > iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C > > %7C%7C&sdata=6tZX4WSDgmIunAocnoySmqZfu6HNHzyyrgNR2tGTUTU%3D&reserved=0 > > > > There is a specific page for WirelessHART here: > > https://www.fieldcommgroup.org/technologies/wirelesshart. > > > > However, this does not match the original title of this reference. The > > original title of this reference seems to be pointing to IEC 62951, > > which can be found at this URL: > > https://webs/ > > tore.iec.ch%2Fen%2Fpublication%2F24433&data=05%7C02%7Cjanos.farkas%40e > > ricsson.com%7C50d72988563841aad6fc08de6f2b0f77%7C92e84cebfbfd47abbe520 > > 80c6b87953f%7C0%7C0%7C639070428184204494%7CUnknown%7CTWFpbGZsb3d8eyJFb > > XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > > sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UDM58duwJK9ZhKsMQv7bNWlcXBypOIIrH > > gytZfdIb2U%3D&reserved=0 > > > > We have updated this reference based of the information available at > > the redirected URL to point to FieldComm Group's page for > > WirelessHART. Please let us know if you would prefer to point to the > > IEC page. > > > > Original: > > [WirelessHART] > > http://www.hartcomm.org/, "Industrial Communication > Networks - > > Wireless Communication Network and Communication Profiles > > - WirelessHART - IEC 62591", 2010. > > > > Updated: > > [WirelessHART] > > FieldComm Group, "WirelessHART", > > <https://www.fieldcommgroup.org/technologies/ > > wirelesshart>. > > Pascal> many thanks, sorry the pages change. > > > > e) The original title for this reference doesn't match the title at > > the URL. We have updated this reference to match the URL. > > > > Original: > > [IMT2020] "ITU towards IMT for 2020 and beyond", > > < > https://www.itu.int/en/ITU-R/study-groups/rsg5/rwp5d/imt-2020/Pages/default.aspx > >. > > > > Updated: > > [IMT2020] ITU, "IMT-2020 (a.k.a. "5G")", > > < > https://www.itu.int/en/ITU-R/study-groups/rsg5/rwp5d/imt-2020/Pages/default.aspx > >. > > Pascal> OK > > > > f) The original URL for this reference results in a 404 error. We > > found the following URL, which matches the information for this > > reference, but M. Schnell is not the author of this article. We have > > updated the reference accordingly. > > > > Original: > > [SCH19] Schnell, M., "DLR tests digital communications > > technologies combined with additional navigation functions > > for the first time", 3 March 2019, > > <https://www.dlr.de/dlr/en/desktopdefault.aspx/tabid- > > 10081/151_read-32951/#/gallery/33877>. > > > > Current: > > [SCH19] German Aerospace Center (DLR), "DLR tests digital > > communications technologies combined with additional > > navigation functions for the first time", 27 March 2019, > > <https://www.dlr.de/en/latest/ > > news/2019/01/20190327_modern-technology-for-the-flight- > > deck>. > > --> > > > > Pascal> OK > > > > > > 45) <!-- [rfced] In the Contributors section, would you like to point > > to specific section numbers? This would create links in the HTML and > > PDF outputs. Also, is Section 4 the "Wi-Fi section"? Will this be > > clear to readers? > > > > Current: > > * Georgios Z. Papadopoulos: Contributed to the TSCH section > > > > * Nils Maeurer: Contributed to the LDACS section > > > > * Thomas Graeupl: Contributed to the LDACS section > > > > * Torsten Dudda, Alexey Shapin, and Sara Sandberg: Contributed to > > the 5G section > > > > * Rocco Di Taranto: Contributed to the Wi-Fi section > > > > * Rute Sofia: Contributed to the Introduction and Terminology > > sections > > > > Perhaps: > > * Georgios Z. Papadopoulos contributed to Section 5 ("IEEE 802.15.4 > > Time-Slotted Channel Hopping (TSCH)"). > > > > * Nils Maeurer and Thomas Graeupl contributed to Section 7 ("L-Band > > Digital Aeronautical Communications System (LDACS)"). > > > > * Torsten Dudda, Alexey Shapin, and Sara Sandberg contributed to > Section 6 ("5G"). > > > > * Rocco Di Taranto contributed to Section 4 ("IEEE 802.11"). > > > > * Rute Sofia contributed to Section 1 ("Introduction") and Section 2 > ("Terminology"). > > --> > > > > Pascal> yes, please use 'Perhaps' > > > > 46) <!-- [rfced] Some author comments are present in the XML. Please > > confirm that no updates related to these comments are needed. Note > > that these comments will be deleted prior to publication. --> Pascal> > > I'll do that offline > > > > 47) <!-- [rfced] Would you like to make use of <sup> for superscript > > for the two instances of "10^-5" in this document? We updated the > > first instance so you can see what this looks like; please review in > > the HTML. Note that in the HTML and PDF, it appears as superscript; in > > the text output, <sup> generates a^b, which is used in the original > document. > > --> > > > > Pascal> yes, please use <sup>. Looks good > > > > 48) <!-- [rfced] Please review "It results that" in these sentences. > > Would either removing this phrase or updating to "As a result", > > "Thus," (or something > > else) improve these sentences? Note that how to update may depend on > > context, so please review each instance in context. > > > > Original: > > It results that a frame that is received in a RX-cell of a Track with > a > > destination MAC address set to this node as opposed to broadcast must > > be extracted from the Track and delivered to the upper layer (a frame > > with an unrecognized MAC address is dropped at the lower MAC layer > > and thus is not received at the 6top sublayer). > > ... > > It results that a frame > > that is received over a layer-3 bundle may be in fact associated with > > a Track. > > ... > > It results that the tagging that is used for a DetNet flow outside > > the 6TiSCH Low Power Lossy Network (LLN) must be swapped into 6TiSCH > > formats and back as the packet enters and then leaves the 6TiSCH > > network. > > ... > > It results that a node > > will maintain only a small number of peering information, and will > > not be able to store many packets waiting to be forwarded. > > --> > > > > > > Pascal> I'll trust you on this. "As a result" seems good to me. > > 49) <!-- [rfced] Would you like to update "wide-area" and > > "local-area" in these sentences to "WAN" and "LAN", respectively? Or do > you prefer the current? > > > > Current: > > With these three cornerstones, NR is a > > complete solution supporting the connectivity needs of consumers, > > enterprises, and the public sector for both wide-area and local-area > > (e.g., indoor) deployments. > > ... > > The 5G system allows deployment in a vast spectrum range, addressing > > use cases in both wide-area and local-area networks. > > > > Perhaps: > > With these three cornerstones, NR is a > > complete solution supporting the connectivity needs of consumers, > > enterprises, and the public sector for both WAN and LAN > > (e.g., indoor) deployments. > > ... > > The 5G system allows deployment in a vast spectrum range, addressing > > use cases in both WANs and LANs. > > --> > > Pascal> Please keep the original text. The meaning is different. > > <JF> > > I also prefer the original text. > > </JF> > > > > 50) <!-- [rfced] Units of measure: > > > > a) We see both "ms" and "msec" used in the document. Would you like to > > use one form consistently or update to "millisecond" (or the plural > "milliseconds" > > depending on context)? > > Pascal> Please use "ms" which is the SI standard. I believe the right > format is like "10ms" as opposed to "10 ms". > > > > b) Will readers know what "1us" is here? Does this refer to > > microsecond (i.e., )? If so, may we update to use "microsecond" for > > clarity? Also, would updating to "in 1us accuracy level" to "with an > > accuracy level of 1 microsecond" improve readability? > > > > Original: > > NR supports accurate reference time synchronization in 1us accuracy > > level. > > > > Perhaps: > > NR supports accurate reference time synchronization with an accuracy > level > > of 1 microsecond. > > --> > > Pascal> 1μs is SI standard so people will understand it. I believe us > was used because of a restriction. If µs is usable please use it. > > <JF> > > I agree with Pascal. > > </JF> > > > > > > 51) <!-- [rfced] Terminology: > > > > a) We note inconsistencies in the terms below throughout the text. > > Should these be uniform? If so, please let us know which form is > preferred. > > > > ChannelOffset vs. channeloffset vs. channelOffset > > Note: "channelOffset" is used in RFCs 8480, 9030, and 9033. > > Pascal> Please use ChannelOffset > > > > slotoffset vs. slotOffset > > Note: "slotoffset" is used in RFCs 8480, 9030, and 9033. > > Pascal> Please use "slotoffset" > > > > slotFrame vs. slotframe > > Note: "slotframe" is used in RFC 9030. > > Pascal> Please use "slotframe" > > timeSlot vs. timeslot > > Note: "timeSlot" is used in RFC 9030. > > Pascal> Please use "timeSlot" > > > > b) We see one instance each of the terms below document. Should these > > be updated to either "DetNet or RAW" or "DetNet and RAW"? > > Pascal> we may use RAW only since RAW is part of and implies DetNet. > > DetNet/RAW > > RAW/DetNet > > > > > > c) FYI - This document uses a mix of British and American spellings. > > We updated to American spelling for consistency per Section 3.1 of RFC > > 7322 ("RFC Style Guide"). Note that we updated the spellings of the > > following words: utiliz*, neighbor, signaling, and analog. > > > > Pascal> OK > > d) Some text includes "802.X" that is not prefaced by "IEEE" or "IEEE > > Std". Are any updated needed for these? Or is the current okay? The > > document includes many instances; some examples below. > > > > Original: > > While previous 802.11 > > generations, such as 802.11n and 802.11ac, have focused mainly on > > improving peak throughput, more recent generations are also > > considering other performance vectors ... > > ... > > 802.11 WLANs can > > also be part of a 802.1Q bridged networks with enhancements enabled > > by the 802.11ak amendment retrofitted in IEEE Std 802.11-2020. > > ... > > Traffic classification based on 802.1Q VLAN tags is also supported in > > 802.11. Other 802.1 TSN capabilities such as 802.1Qbv and 802.1CB, > > which are media agnostic, can already operate over 802.11. > > > > Perhaps: > > While previous IEEE 802.11 > > generations, such as IEEE 802.11n and IEEE 802.11ac, have focused > mainly on > > improving peak throughput, more recent generations are also > > considering other performance vectors ... > > ... > > IEEE 802.11 WLANs can > > also be part of IEEE 802.1Q bridged networks with enhancements enabled > > by the IEEE 802.11ak amendment retrofitted in IEEE Std 802.11-2020. > > ... > > Traffic classification based on IEEE 802.1Q VLAN tags is also > supported in > > IEEE 802.11. Other IEEE 802.1 TSN capabilities such as IEEE 802.1Qbv > and IEEE 802.1CB, > > which are media agnostic, can already operate over IEEE 802.11. > > --> > > Pascal> OK > > > > 52) <!-- [rfced] Abbreviations: > > > > a) How may we expand the following abbreviations? > > > > BPSK (perhaps "Binary Phase-Shift Keying"?) QPSK (perhaps "Quadrature > > Phase-Shift Keying"?) SAP (perhaps "Service Access Point"?) VDL > > (perhaps "VHF Digital Link"?) Pascal> yes to all > > > > b) FYI - We have added expansions for the following abbreviations per > > Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > > expansion in the document carefully to ensure correctness. > > > > Federal Communications Commission (FCC) Carrier Sense Multiple Access > > (CSMA) Highway Addressable Remote Transducer Protocol (HART) Routing > > Protocol for Low-Power and Lossy Networks (RPL) Signal-to-Noise Ratio > > (SNR) station (STA) Personal Area Network (PAN) gNodeB (gNB) Pascal> > > yes to all > > > > c) FYI - "L1" and"L3" were used only once in the document, and "L2" > > was only used twice. We updated to use the expanded forms "Layer 1", > > "Layer 2", and "Layer 3". > > Pascal> yes to all > > > > d) This document contains these similar abbreviations. Will these > > cause any confusion for readers? If so, we can update the 8 instances > > of "GS" to the expansion "ground station" (and maybe also update > > instances of "AS" to "aircraft station" as they are often used in the > > same text). We will go with your preference here. > > > > 5GS - 5G System > > GS - Ground Station > > Pascal> please leave the text as is. These are different sections for > different technologies so the reader should not be confused. > > > > e) We note that this document switches between using the expanded and > > abbreviated forms of the terms below. Would you like to expand the > > first instance and then use the abbreviated form thereafter? Or do you > > prefer the current? > > > > physical vs. PHY (for the layer) > > uplink vs. UL > > downlink vs. DL > > forward link vs. FL > > reverse link vs. RL > > > > --> > > Pascal> please expand the first in each section. A reader might read > only one section. > > <JF> > > I agree with Pascal. > > Just FYI: > > Actually there has been a terminology change for Precision Time Protocol > (PTP) based time synchronization; however, the only term remains unchanged > is Grandmaster. > > A summary is given in page 7 in > > https://www/. > > ieee802.org%2F1%2Ffiles%2Fpublic%2Fdocs2022%2Fdr-Rodrigues-editors-upd > > ate-0922-v02.pdf&data=05%7C02%7Cjanos.farkas%40ericsson.com%7C50d72988 > > 563841aad6fc08de6f2b0f77%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C > > 639070428184487350%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlY > > iOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0% > > 7C%7C%7C&sdata=xx2Izg6ocigd9S%2BSPjLlX%2F%2Fk47TSfSlTjOB7gXHOwiA%3D&re > > served=0 > > IEEE 1588 is the standard for PTP. > > The P1588g project has made the terminology change for IEEE 1588 PTP. > > There are profiles of IEEE 1588, e.g., IEEE 802.1AS. The P802.1ASdr > project has made the terminology change for 802.1AS. 802.1ASdr has been > incorporated to the base standard by now. That is the most recent revision: > IEEE Std 802.1AS-2025 (https://standards.ieee.org/ieee/802.1AS/11968/) > now only has the revised inclusive terminology, which includes Grandmaster. > > The 5G System supports 802.1AS and some other IEEE 1588 based time sync > solutions. So the current text is fine. > > </JF> > > > > 53) <!-- [rfced] Please review the "Inclusive Language" portion of the > > online Style Guide > > <https://www/ > > .rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7 > > C02%7Cjanos.farkas%40ericsson.com%7C50d72988563841aad6fc08de6f2b0f77%7 > > C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639070428184566153%7CUnkno > > wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > > W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=aePkZ%2BnGD > > w3GkJ2agRkZDxL8jWFQb%2F4Aogii6fXF0tQ%3D&reserved=0> > > and let us know if any changes are needed. Updates of this nature > > typically result in more precise language, which is helpful for readers. > > > > For example, please consider whether the following should be updated: > > > > a) "master" > > > > Original: > > ...possibility for the TSN grandmaster clock to reside on the UE side. > > ... > > The European ATM Master Plan foresees... > > > > b) "native" > > > > Original: > > Moreover, providing IP service is native to 5G and 3GPP... > > ... > > NR is designed with native support of antenna arrays utilizing... > > --> > > > > Pascal> please leave the text as is. These are external terminologies > not text we control. > > All the best! > > -- Pascal > > > auth48archive mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
