Hi all I appreciate all the help and all the work you've done, but to be honest I am not a coder. I do not understand these directions. Is there somebody that could help me with this ? Coding is so over my head... Serious struggles
I woukd truly appreciate more than you have Corinne On Wed, Feb 18, 2026, 14:01 <[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: AUTH48: RFC-to-be 9935 <draft-ietf-lamps-kyber-certificates-11> > for your review > (Massimo, Jake) > 2. AUTH48: RFC-to-be 9928 <draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-06> for > your review > ([email protected]) > 3. Re: AUTH48: RFC-to-be 9928 <draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-06> > for your review > ([email protected]) > > > > ---------- Forwarded message ---------- > From: "Massimo, Jake" <[email protected]> > To: "Kampanakis, Panos" <[email protected]>, Madison Church < > [email protected]>, Bas Westerbaan <[email protected]>, " > [email protected]" <[email protected]> > Cc: "[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 18:55:49 +0000 > Subject: [auth48] Re: AUTH48: RFC-to-be 9935 > <draft-ietf-lamps-kyber-certificates-11> for your review > Yes I approve! > > Cheers, > Jake > > *From: *Kampanakis, Panos <[email protected]> > *Date: *Wednesday, February 18, 2026 at 9:22 AM > *To: *Madison Church <[email protected]>, Bas Westerbaan < > [email protected]>, [email protected] <[email protected]>, Massimo, Jake < > [email protected]> > *Cc: *[email protected] <[email protected]>, > [email protected] <[email protected]>, [email protected] < > [email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]>, [email protected] > <[email protected]> > *Subject: *RE: [EXTERNAL] AUTH48: RFC-to-be 9935 > <draft-ietf-lamps-kyber-certificates-11> for your review > > Thank you, looks great, I approve. > > Sean, Jake? > > > -----Original Message----- > From: Madison Church <[email protected]> > Sent: Wednesday, February 18, 2026 12:20 PM > To: Kampanakis, Panos <[email protected]>; Bas Westerbaan < > [email protected]>; [email protected]; Massimo, Jake <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > Subject: RE: [EXTERNAL] AUTH48: RFC-to-be 9935 > <draft-ietf-lamps-kyber-certificates-11> for your review > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > > > Hi Panos, > > Thanks for pointing this out! We originally incorporated your feedback but > did not post the correct files. If you refresh, they should now include the > changes proposed on 10 February. > > The updated files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9935.txt > https://www.rfc-editor.org/authors/rfc9935.pdf > https://www.rfc-editor.org/authors/rfc9935.html > https://www.rfc-editor.org/authors/rfc9935.xml > > Updated diffs: > https://www.rfc-editor.org/authors/rfc9935-diff.html > https://www.rfc-editor.org/authors/rfc9935-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9935-auth48diff.html > https://www.rfc-editor.org/authors/rfc9935-auth48rfcdiff.html (side by > side) > > Thank you, and apologies for the inconvenience! > > Madison Church > RFC Production Center > > > On Feb 18, 2026, at 11:12 AM, > > > > > ---------- Forwarded message ---------- > From: [email protected] > To: [email protected], [email protected], > [email protected], [email protected] > Cc: [email protected], [email protected], [email protected], > [email protected], [email protected], [email protected] > Bcc: > Date: Wed, 18 Feb 2026 11:00:19 -0800 (PST) > Subject: [auth48] AUTH48: RFC-to-be 9928 > <draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-06> for your review > *****IMPORTANT***** > > Updated 2026/02/18 > > RFC Author(s): > -------------- > > Your document has now entered AUTH48. > > The document was edited in kramdown-rfc as part of the RPC pilot test (see > https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc). > > Please review the procedures for AUTH48 using kramdown-rfc: > > > https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_instructions_completing_auth48_using_kramdown > > Once your document has completed AUTH48, it will be published as > an RFC. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9928.md > https://www.rfc-editor.org/authors/rfc9928.html > https://www.rfc-editor.org/authors/rfc9928.pdf > https://www.rfc-editor.org/authors/rfc9928.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9928-diff.html > https://www.rfc-editor.org/authors/rfc9928-rfcdiff.html (side by side) > > Diff of the kramdown: > https://www.rfc-editor.org/authors/rfc9928-md-diff.html > https://www.rfc-editor.org/authors/rfc9928-md-rfcdiff.html (side by > side) > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9928 > > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9928 (draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-06) > > Title : DHCPv4-over-DHCPv6 with Relay Agent Support > Author(s) : C. Porfiri, S. Krishnan, J. Arkko, M. Kühlewind > WG Chair(s) : Timothy Winters, Bernie Volz > > Area Director(s) : Erik Kline, Éric Vyncke > > > > > > ---------- Forwarded message ---------- > From: [email protected] > To: [email protected], [email protected], > [email protected], [email protected] > Cc: [email protected], [email protected], [email protected], > [email protected], [email protected], [email protected] > Bcc: > Date: Wed, 18 Feb 2026 11:01:22 -0800 (PST) > Subject: [auth48] Re: AUTH48: RFC-to-be 9928 > <draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-06> for your review > Authors, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the source file. > > 1) <!-- [rfced] Please review the text below. We were unable to find > "L3RA" used in > [draft-ietf-dhc-rfc8415bis] (now published as RFC 9915). > > Original: > > Similarly, the specifications for DHCPv6 Relay Agents such as > Lightweight DHCPv6 Relay Agent (LDRA) [RFC6221] or DHCPv6 Relay Agent > (L3RA) [draft-ietf-dhc-rfc8415bis] do not foresee the possibility to > handle legacy DHCPv4, other than implementing DHCP 4o6 in the client. > > --> > > > 2) <!-- [rfced] Section 2: > > a) May we adjust the items in this list to appear in alphabetical order? > > b) May we make these list items consistent as follows? > > Original: > > * DHCP: If not otherwise specified, DHCP refers to DHCPv4 and/or > DHCPv6. > > * DHCPv4: DHCP as defined in [RFC2131]. > > * DHCPv4 over DHCPv6 (or 4o6): The architecture, the procedures, and > the protocols specified in the DHCPv4-over-DHCPv6 document > [RFC7341]. > > * DHCP Relay Agent: This is a concept in all of the following > protocols, although the details differ between them: BOOTP > [RFC951] [RFC1542], DHCPv4 [RFC2131] [RFC2132], and DHCPv6 > [draft-ietf-dhc-rfc8415bis]. > > * Lightweight DHCPv6 Relay Agent (or LDRA): This is an extension of > the original DHCPv6 Relay Agent specification, to allow layer- > 2-only devices to perform a Relay Agent function [RFC6221]. > > * DHCPv4 over DHCPv6 Relay Agent (or 4o6RA): Refers to a Relay Agent > that implements the 4o6 transport as specified in this document. > > Perhaps: > > DHCP: > Refers to DHCPv4 and/or DHCPv6 if not otherwise specified. > > DHCPv4: > Refers to DHCP as defined in [RFC2131]. > > DHCPv4 over DHCPv6 (DHCP 4o6): > Refers to the architecture, the procedures, and the protocols > specified in > the DHCPv4-over-DHCPv6 document [RFC7341]. > > (etc.) > > --> > > > 3) <!-- [rfced] Per Section 3.6 of RFC 7322 ("RFC Style Guide"), > abbreviations > should be expanded upon first use. How and where should "CPE" be expanded > as > it appears in Figure 4? > > Original: > > In a simple case, where the same node hosts the 4o6RA and the DHCP4o6 > server, it might be enough to only use 4o6RA, as shown in Figure 4. > > Perhaps: > > In a simple case, where the same node hosts the 4o6RA and the DHCP 4o6 > server, it might be enough to only use 4o6RA, as shown in Figure 4, > where > CPE stands for "Customer Premises Equipment". > > --> > > > 4) <!-- [rfced] Security Considerations: > > a) Would the following adjustment clarify what "the 4o6 DHCP specification" > refers to? > > b) Please note that we have changed "4o6 DHCP" to "DHCP 4o6" in this > section for consistency with the rest of the document. > > Original: > > This document does not change anything else in the 4o6 DHCP > specification > and therefore the security considerations of [RFC7341] still apply. > > Perhaps: > > This document does not change anything else in the DHCP 4o6 > specification [RFC7341]; > therefore, the security considerations of that document still apply. > > --> > > > 5) <!-- [rfced] Appendix A: Please review our questions and suggested > updates to > the text below, including the following items: > > a) Should the abbreviation for "Baseband Units (BB)" be updated to > "Baseband Units (BBUs)" > as seen in the text below? If so, please note that we would also update > instances of > "BB"/"BBs" to "BBU"/"BBUs" accordingly throughout the rest of this section > as well. > > b) Should the abbreviation for "Radio Fronthaul Network (FH)" be adjusted > for > clarity? > > Original: > > In 3GPP mobile network architecture, the User Equipments (UE) are > connected via Radio Access Network (RAN). RAN is built up with > Baseband Units (BB) and Radio Units (RU). Radio Fronthaul Network > (FH) connects RU and BB, each of RU and BB is an IP host, they may > support IPv4 only, IPv6 only or both depending on the vendor and the > model. > > Perhaps: > > In 3GPP mobile network architecture, the User Equipment (UE) is > connected via a Radio Access Network (RAN). RAN is built up with > Baseband Units (BBUs) and Radio Units (RUs). A radio Fronthaul (FH) > network > connects RUs and BBUs. Each RU and BBU is an IP host, and they may > support IPv4 only, IPv6 only, or both, depending on the vendor and the > model. > > --> > > > 6) <!-- [rfced] Terminology and Abbreviations: > > a) We note that the phrase "4o6" appears a few times by itself throughout > this > document. For consistency and context, should these instances be updated > to "DHCP 4o6"? > > We have provided a few examples below: > > the 4o6 transport > are expected to be compliant with 4o6 > the introduction of 4o6 at the edge > moving 4o6 to a intermediate node > a 4o6 client > > > b) We note the following phrases appear after their abbreviations are > introduced. For consistency, should these terms (on the left) be updated to > their abbreviated form (on the right) after first use? > > Expansion -> Abbreviation > > DHCPv4-over-DHCPv6 -> DHCP 4o6 > 4o6 Relay Agent -> 4o6RA > Layer 2 -> L2 > > > c) FYI - We have added expansions for abbreviations upon first use > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > expansion in the document carefully to ensure correctness. > > Bootstrap Protocol (BOOTP) > Layer 2 (L2) > > --> > > > 7) <!-- [rfced] Please review the "Inclusive Language" portion of the > online > Style Guide < > https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > and let us know if any changes are needed. Updates of this nature > typically > result in more precise language, which is helpful for readers. > > Note that our script did not flag any words in particular, but this should > still be reviewed as a best practice. --> > > > Thank you. > Alanna Paloma and Kaelin Foody > RFC Production Center > > > On Feb 18, 2026, at 11:00 AM, [email protected] wrote: > > *****IMPORTANT***** > > Updated 2026/02/18 > > RFC Author(s): > -------------- > > Your document has now entered AUTH48. > > The document was edited in kramdown-rfc as part of the RPC pilot test (see > https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc). > > Please review the procedures for AUTH48 using kramdown-rfc: > > > https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_instructions_completing_auth48_using_kramdown > > Once your document has completed AUTH48, it will be published as > an RFC. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9928.md > https://www.rfc-editor.org/authors/rfc9928.html > https://www.rfc-editor.org/authors/rfc9928.pdf > https://www.rfc-editor.org/authors/rfc9928.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9928-diff.html > https://www.rfc-editor.org/authors/rfc9928-rfcdiff.html (side by side) > > Diff of the kramdown: > https://www.rfc-editor.org/authors/rfc9928-md-diff.html > https://www.rfc-editor.org/authors/rfc9928-md-rfcdiff.html (side by > side) > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9928 > > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9928 (draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-06) > > Title : DHCPv4-over-DHCPv6 with Relay Agent Support > Author(s) : C. Porfiri, S. Krishnan, J. Arkko, M. Kühlewind > WG Chair(s) : Timothy Winters, Bernie Volz > > Area Director(s) : Erik Kline, Éric Vyncke > > 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]
