AFAIS the email was already on my tracker, just not as primary. tried to add again just in case
On Tue, Jun 2, 2026 at 2:11 PM Head, Jordan <[email protected]> wrote: > Hi Alanna, > > Sorry to flip back and forth, can you revert Tony’s e-mail back to what it > was previously? He can add that e-mail to his datatracker account as time > permits. > > [email protected] > > Other than that, a couple of edits: > > > 1. Section 1 - Typo > > the first sentence has RFIT instead of RIFT > > 2. Section 3 - Missing word > > CURRENT: > “While no explicit restrictions are placed on how Key-Value elements > are or how they are used…” > > SHOULD BE: > “While no explicit restrictions are placed on how Key-Value elements > are used...” > > 3. Section 3.1 - Missing article > > CURRENT: > “…will select the KV TIE with highest System ID...” > > SHOULD BE: > “…will select the KV TIE with the highest System ID...” > > > > > > *From: *Alanna Paloma <[email protected]> > *Date: *Monday, June 1, 2026 at 5:32 PM > *To: *Head, Jordan <[email protected]> > *Cc: *[email protected] <[email protected]>, > [email protected] <[email protected]>, Przygienda, Tony < > [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]> > *Subject: *Re: Final review: RFC-to-be 9992 > (draft-ietf-rift-kv-tie-structure-and-processing) > > Hi Jordan, > > Thank you for your replies. We have updated as requested. > > The files have been posted here (please refresh): > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9992.xml__;!!NpxR!nbE_lfaRRMS1LgijK1ecW-H6EdTXoEbekrsKu56KKh2KRYS0WHm0naRAJAn0k382_AC8TIWeyMPL9KRB4nj-Z3I3$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9992.txt__;!!NpxR!nbE_lfaRRMS1LgijK1ecW-H6EdTXoEbekrsKu56KKh2KRYS0WHm0naRAJAn0k382_AC8TIWeyMPL9KRB4r7LnyyV$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9992.html__;!!NpxR!nbE_lfaRRMS1LgijK1ecW-H6EdTXoEbekrsKu56KKh2KRYS0WHm0naRAJAn0k382_AC8TIWeyMPL9KRB4uha_hUb$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9992.pdf__;!!NpxR!nbE_lfaRRMS1LgijK1ecW-H6EdTXoEbekrsKu56KKh2KRYS0WHm0naRAJAn0k382_AC8TIWeyMPL9KRB4o5SJhJJ$ > > The relevant diff files have been posted here: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9992-diff.html__;!!NpxR!nbE_lfaRRMS1LgijK1ecW-H6EdTXoEbekrsKu56KKh2KRYS0WHm0naRAJAn0k382_AC8TIWeyMPL9KRB4jaQ12yp$ > (comprehensive diff) > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9992-auth48diff.html__;!!NpxR!nbE_lfaRRMS1LgijK1ecW-H6EdTXoEbekrsKu56KKh2KRYS0WHm0naRAJAn0k382_AC8TIWeyMPL9KRB4l3D8D_f$ > (Final Review changes) > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9992-auth48rfcdiff.html__;!!NpxR!nbE_lfaRRMS1LgijK1ecW-H6EdTXoEbekrsKu56KKh2KRYS0WHm0naRAJAn0k382_AC8TIWeyMPL9KRB4oU7IMgU$ > (Final Review changes side by side) > > Please review the document carefully and contact us with any further > updates you may have. Note that we do not make changes once a document is > published as an RFC. > > We will await approvals from each party listed on the Final Review status > page below prior to moving this document forward in the publication process. > > For the Final Review status of this document, please see: > > https://urldefense.com/v3/__https://queue.rfc-editor.org/final-review/rfc9992/__;!!NpxR!nbE_lfaRRMS1LgijK1ecW-H6EdTXoEbekrsKu56KKh2KRYS0WHm0naRAJAn0k382_AC8TIWeyMPL9KRB4rBnpD-7$ > > Thank you, > Alanna Paloma > RFC Production Center > > > On Jun 1, 2026, at 6:45 AM, Head, Jordan <jordan.head= > [email protected]> wrote: > > > > Sorry about that, ignore my first point. > > > > Let’s change it to [email protected] > > > > From: Head, Jordan <[email protected]> > > Date: Monday, June 1, 2026 at 9:44 AM > > To: [email protected] <[email protected]>, > [email protected] <[email protected]>, Przygienda, Tony < > [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]>, > [email protected] <[email protected]>, > [email protected] <[email protected]> > > Subject: Re: Final review: RFC-to-be 9992 > (draft-ietf-rift-kv-tie-structure-and-processing) > > > > Alanna, Alice, > > > > Thank you for reviewing and editing our document! > > > > Replies inline as jhead>> > > > > From: [email protected] <[email protected]> > > Date: Friday, May 29, 2026 at 6:33 PM > > To: Head, Jordan <[email protected]>, [email protected] < > [email protected]>, Przygienda, Tony <[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]>, > [email protected] <[email protected]>, > [email protected] <[email protected]> > > Subject: Re: Final review: RFC-to-be 9992 > (draft-ietf-rift-kv-tie-structure-and-processing) > > > > Authors, > > > > While reviewing this document during AUTH48, please resolve (as > necessary) the following > > questions, which are also in the source file. > > > > 1) <!--[rfced] Tony, we note that the email address used in this document > > does not match your email addresses as they appear here: > > > https://urldefense.com/v3/__https://datatracker.ietf.org/person/Tony*20Przygienda__;JQ!!NpxR!g2r540mi05sUS4XCIajxx4ubLhMmveiSk-R9wqI3OEW_RapTaFEFFgzZ83qOryc45ApVIxoMqnB8NtHP4-EVRew$ > > > > Which email address would you like to appear in the RFC? > > --> > > > > jhead>> Spoke with Tony, the HPE e-mail is correct. > > > > > > 2) <!--[rfced] May we clarify this citation as follows? > > > > Original: > > [RIFT-AUTO-EVPN] is an example of this type of implementation. > > > > Perhaps: > > For example, [RIFT-AUTO-EVPN] describes this type of implementation. > > --> > > > > jhead>> Good with this. > > > > 3) <!-- [rfced] Please review whether this note should be in the <aside> > element. > > It is defined as "a container for content that is semantically less > important > > or tangential to the content that surrounds it" > > ( > https://urldefense.com/v3/__https://authors.ietf.org/en/rfcxml-vocabulary*aside__;Iw!!NpxR!g2r540mi05sUS4XCIajxx4ubLhMmveiSk-R9wqI3OEW_RapTaFEFFgzZ83qOryc45ApVIxoMqnB8NtHP6jMKCS0$ > ). > > > > Original: > > *NOTE:*Like [RFC9692], this section uses terms to denote > > directionality, specifically, "northbound" meaning "toward the top of > > the fabric" and "southbound" meaning "toward the bottom of the > > fabric". > > --> > > > > jhead>> Yes, <aside> works here. > > > > 4) <!--[rfced] In Figure 6, is the second comma necessary? > > > > Original: > > | (System ID, > > | Level), > > > > Perhaps: > > | (System ID, > > | Level) > > —> > > > > jhead>> A matter of taste really, it can be removed. > > > > 5) <!-- [rfced] Three lines in Figure 9 exceeded the 69-character line > limit. > > We updated as follows; please let us if they should be modified > otherwise. > > > > Original: > > /// given a system ID delivers the bits set by the according Bloom > Filter in the > > southbound > > /// key value target. > > pub (crate) fn target2bits(target: UnsignedSystemID) -> > KeyValueTargetType { > > (0 as usize .. 3) > > .map(|s| { > > let rot = (target ^ RANDOMSEEDS[s]).rotate_left(s as _); > > rot.to_ne_bytes().iter().fold(0, |v: u8, nv| > v.rotate_right(4) ^ *nv) % 64 > > }) > > .fold(0, |v, nv| v | (1 << nv)) > > } > > > > Current: > > /// given a system ID delivers the bits set by the according > > /// Bloom Filter in the southbound key value target. > > pub (crate) fn target2bits(target: UnsignedSystemID) -> > > KeyValueTargetType { > > (0 as usize .. 3) > > .map(|s| { > > let rot = (target ^ RANDOMSEEDS[s]).rotate_left(s as _); > > rot.to_ne_bytes().iter().fold(0, > > |v: u8, nv| v.rotate_right(4) ^ *nv) % 64 > > }) > > .fold(0, |v, nv| v | (1 << nv)) > > } > > --> > > > > jhead>> This is fine. > > > > 6) <!-- [rfced] Please review the "type" attribute of the sourcecode > element in > > Section 3.2 in the XML file to ensure correctness. If the current list of > > preferred values for "type" > > ( > https://urldefense.com/v3/__https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types__;!!NpxR!g2r540mi05sUS4XCIajxx4ubLhMmveiSk-R9wqI3OEW_RapTaFEFFgzZ83qOryc45ApVIxoMqnB8NtHPsfFFxuk$ > ) > > does not contain an applicable type, then feel free to let us know. > > Also, it is acceptable to leave the "type" attribute not set. > > > > In addition, review each artwork element. Specifically, > > should any artwork element be tagged as sourcecode or another > > element? > > --> > > > > jhead>> Not setting it is fine. No other figures need to be set as > <sourcecode> > > > > 7) <!-- [rfced] 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. > > > > Link State Database (LSDB) > > Organizationally Unique Identifier (OUI) > > --> > > > > jhead>> I’m good with your expansions. > > > > 8) <!-- [rfced] Please review the "Inclusive Language" portion of the > online > > Style Guide < > https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!NpxR!g2r540mi05sUS4XCIajxx4ubLhMmveiSk-R9wqI3OEW_RapTaFEFFgzZ83qOryc45ApVIxoMqnB8NtHPTb-pMFc$ > > > > 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. > > --> > > > > jhead>> No further changes required here. Thanks for the reminder. > > > > Thank you. > > > > Alanna Paloma and Alice Russo > > RFC Production Center > > > > > > On May 29, 2026, [email protected] wrote: > > > > *****IMPORTANT***** > > > > RFC Author(s): > > -------------- > > > > Final Review for RFC-to-be 9992 > <draft-ietf-rift-kv-tie-structure-and-processing> > > > > Your document is now available for Final Review (previously 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, please see the Unavailable Authors > section > > ( > https://urldefense.com/v3/__https://authors.ietf.org/rfc-publication-process*unavailable-authors__;Iw!!NpxR!g2r540mi05sUS4XCIajxx4ubLhMmveiSk-R9wqI3OEW_RapTaFEFFgzZ83qOryc45ApVIxoMqnB8NtHPVYNBkQk$ > ). > > > > 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!g2r540mi05sUS4XCIajxx4ubLhMmveiSk-R9wqI3OEW_RapTaFEFFgzZ83qOryc45ApVIxoMqnB8NtHPdp1wxXw$ > ). > > > > * 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!g2r540mi05sUS4XCIajxx4ubLhMmveiSk-R9wqI3OEW_RapTaFEFFgzZ83qOryc45ApVIxoMqnB8NtHPOACCRDc$ > >. > > > > * 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 > > > > * [email protected] (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). > > > > * [email protected], which is an archival mailing list > > to preserve discussion about the document while in the RPC editorial > > queue; it is not an active discussion list: > > > > * More info: > > > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NpxR!g2r540mi05sUS4XCIajxx4ubLhMmveiSk-R9wqI3OEW_RapTaFEFFgzZ83qOryc45ApVIxoMqnB8NtHPRq5grgI$ > > > > * The archive itself: > > > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NpxR!g2r540mi05sUS4XCIajxx4ubLhMmveiSk-R9wqI3OEW_RapTaFEFFgzZ83qOryc45ApVIxoMqnB8NtHPjeFl08g$ > > > > * 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, > > [email protected] 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 > > > > 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/rfc9992.xml__;!!NpxR!g2r540mi05sUS4XCIajxx4ubLhMmveiSk-R9wqI3OEW_RapTaFEFFgzZ83qOryc45ApVIxoMqnB8NtHPpTauVSg$ > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9992.html__;!!NpxR!g2r540mi05sUS4XCIajxx4ubLhMmveiSk-R9wqI3OEW_RapTaFEFFgzZ83qOryc45ApVIxoMqnB8NtHP5RckF0M$ > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9992.pdf__;!!NpxR!g2r540mi05sUS4XCIajxx4ubLhMmveiSk-R9wqI3OEW_RapTaFEFFgzZ83qOryc45ApVIxoMqnB8NtHPtHkCfXc$ > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9992.txt__;!!NpxR!g2r540mi05sUS4XCIajxx4ubLhMmveiSk-R9wqI3OEW_RapTaFEFFgzZ83qOryc45ApVIxoMqnB8NtHPPL3b3bQ$ > > > > Diff file of the text: > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9992-diff.html__;!!NpxR!g2r540mi05sUS4XCIajxx4ubLhMmveiSk-R9wqI3OEW_RapTaFEFFgzZ83qOryc45ApVIxoMqnB8NtHPLWZSVv4$ > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9992-rfcdiff.html__;!!NpxR!g2r540mi05sUS4XCIajxx4ubLhMmveiSk-R9wqI3OEW_RapTaFEFFgzZ83qOryc45ApVIxoMqnB8NtHPJbWzwIs$ > (side by side) > > > > Diff of the XML: > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9992-xmldiff1.html__;!!NpxR!g2r540mi05sUS4XCIajxx4ubLhMmveiSk-R9wqI3OEW_RapTaFEFFgzZ83qOryc45ApVIxoMqnB8NtHPSGvzgzg$ > > > > > > Tracking progress > > ----------------- > > > > Details on the status of your Final Review are here: > > > https://urldefense.com/v3/__https://queue.rfc-editor.org/final-review/rfc9992/__;!!NpxR!g2r540mi05sUS4XCIajxx4ubLhMmveiSk-R9wqI3OEW_RapTaFEFFgzZ83qOryc45ApVIxoMqnB8NtHPa884eUQ$ > > > > Please let us know if you have any questions. > > > > Thank you for your cooperation, > > > > RFC Editor > > > > -------------------------------------- > > RFC 9992 (draft-ietf-rift-kv-tie-structure-and-processing) > > > > Title : Routing in Fat Trees (RIFT) Key/Value Topology > Information Elements Structure and Processing > > Author(s) : J. Head, Ed., T. Przygienda > > WG Chair(s) : Zhaohui Zhang, Jeff Tantsura > > Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
