Hello, Thanks for all of these updates! I approve this latest version of RFC 9622.
Best, Tommy > On Dec 12, 2024, at 1:13 PM, Megan Ferguson <mfergu...@amsl.com> wrote: > > Hi Michael, > > Thank you for sending these along. We have updated on our end to post these > versions and ensure that changes that may have been submitted simultaneously > are represented. > > We have sent replies to each RFC-to-be thread (9622 and 9623) and copied them > below for everyone’s convenience. > > Please have a look and let us know if any further updates are necessary. > > Thank you. > > RFC Editor/mf > > RFC-to-be 9622: > Michael, > > Thank you for sending along the files. We have synced our files with those > you submitted. > > Please review the files carefully as we do not make changes after > publication. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9622.txt > https://www.rfc-editor.org/authors/rfc9622.pdf > https://www.rfc-editor.org/authors/rfc9622.html > https://www.rfc-editor.org/authors/rfc9622.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9622-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9622-auth48diff.html (AUTH48 changes > only) > https://www.rfc-editor.org/authors/rfc9622-lastdiff.html (last to current > version only) > > Please contact us with any further updates/questions/comments you may have. > > We will await approvals from each of the parties listed on the AUTH48 status > page prior to moving forward to publication. > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9622 > > Thank you. > > RFC Editor/mf > > RFC-to-be 9623: > Michael, > > Thank you for sending along the files. We have synced our files with those > you submitted (including making sure the updates that may have come in while > you were working appear as expected). > > Please review the files carefully as we do not make changes after > publication. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9623.txt > https://www.rfc-editor.org/authors/rfc9623.pdf > https://www.rfc-editor.org/authors/rfc9623.html > https://www.rfc-editor.org/authors/rfc9623.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9623-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9623-auth48diff.html (AUTH48 changes > only) > https://www.rfc-editor.org/authors/rfc9623-lastdiff.html (last to current > version only) > > Please contact us with any further updates/questions/comments you may have. > > We will await approvals from each of the parties listed on the AUTH48 status > page prior to moving forward to publication. > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9623 > > Thank you. > > RFC Editor/mf > > > >> On Dec 12, 2024, at 12:32 AM, Michael Welzl <mich...@ifi.uio.no> wrote: >> >> Dear all, >> >> This is about question 5. >> >> I am attaching updated xml files for the RFC-to-be-9622 and 9623 that >> address this question. >> I am also attaching the originals so you can make sure which version I >> worked with - a diff between these files and the very last version could >> indicate some very minor changes that you have applied after I made the >> change. >> >> I downloaded the original XML files and made these updates on December 10, >> and gave the other authors until now to comment (two have, and said they >> were fine with these changes). >> >> Cheers, >> Michael >> >> = = = = = >> >> Please feel free to ignore the following text - but in case of doubt, when >> looking at my version, perhaps these notes that I took when doing the >> changes are useful: >> >> >> The name of the "final" property is "final", and using it marks a message as >> Final. I changed one "Final" to lowercase to account fo this. Also, both >> "final" and "Final" are <tt> marked in such sentences. >> >> One occurrence of "Final" seemed odd, and rather than discussing whether it >> should be "final", "<tt>Final</t>" or "<tt>final</tt>", I renamed it to >> "last". >> >> In one place, removed "()" after "Initiate", "Listen" and "Rendezvous". >> Removed one "()" after "Set". >> >> Another thing: strange - I think we corrected this before, but perhaps this >> was something similar in the -impl draft? Anyway, I replaced "Interface >> Instance or Type" and "interface instances and types" with "interface" (two >> occurrences). Both of these cases seem to be left-over references to a >> heading of a property rather than the actual property name. >> >> It's the same for "Timeout for aborting the Connection" in one place where >> it should instead be "connTimeout" (so I replaced it). >> >> Also, we had this kind of thing in the TCP user timeout text; fixed. >> >> We have one occurrence of "multipath aware" and one occurrence of >> "multipath-aware". I made this uniform, using the version with the dash. >> >> Fixed capitalization of "unidirectional send" and "unidirectional receive" >> to make it uniform (capital "U"). >> >> "MessageContext" and "Message Context" appear only in RFC 9622, not the >> others; messageContext appears also in RFC 9623. It made sense to use the >> capital words in RFC 9622 though, but these should at least be uniform. I >> chose MessageContext (before: 27 occurrences, whereas "Message Context" has >> 11). >> >> For RFC-to-be-9623, I tried to use <tt> style wherever we refer to API >> elements from RFC 9622. >> >> >> >> >> <rfc9622_updateMW.xml><rfc9623_updateMW.xml><rfc9622.xml><rfc9623.xml> >>> On Dec 4, 2024, at 3:13 AM, Megan Ferguson <mfergu...@amsl.com> wrote: >>> >>> Greetings, >>> >>> While reviewing this cluster of documents*, please review the questions >>> below regarding consistency across the cluster. These questions are in >>> addition >>> to the document-specific questions sent for each RFC-to-be. >>> >>> Your reply will likely impact two or more of the documents in the cluster, >>> so >>> please discuss off-list as necessary and then let us know how to proceed. >>> >>> * Cluster 508 (C508) currently in AUTH48 state: >>> https://www.rfc-editor.org/authors/rfc9621.html >>> https://www.rfc-editor.org/authors/rfc9622.html >>> https://www.rfc-editor.org/authors/rfc9623.html >>> (In addition, the .pdf, .txt, .xml, and diff files are available.) >>> >>> You may track the progress of all documents in this cluster through AUTH48 >>> at: >>> https://www.rfc-editor.org/auth48/C508 >>> >>> 1) The following terms were used inconsistently in this group of documents. >>> We chose to use the latter forms and have already incorporated these >>> changes >>> (we raise them here simply for awareness). Please let us know any >>> objections. >>> >>> Connection properties (1 instance) / Connection Properties (>70 instances) >>> >>> Pre-Establishment Phase (1 instance in text) / pre-establishment phase (6 >>> instances in text) >>> Note - we also closed this compound per the dictionary use. >>> >>> protocol stack(s) (7 instances) / Protocol Stack(s) (~130 instances) >>> >>> remote Endpoint Identifier (1 instance) / Remote Endpoint Identifier (~21 >>> instances) >>> >>> selection properties (1 instance) / Selection Properties (~47 instances, >>> along with ~26 instances of "Selection Property") >>> >>> sockets API (1 instance) / socket API (1 instance) / Socket API (14 >>> instances) >>> >>> transport services (4 instances) / Transport Services (>300 instances) >>> >>> Transport Services Architecture (1 instance in text) / Transport Services >>> architecture (8 instances in text) >>> >>> Transport Services implementation (5 instances) / >>> Transport Services Implementation (~70 instances) >>> >>> >>> 2) The following term appears to be hyphenated inconsistently in this group >>> of documents. >>> Please let us know if/how these uses may be made consistent. >>> Notes: >>> a.) the hyphenated compound is more prevalent in published RFCs and >>> b.) the closed compound is used in a proper noun in RFC-to-be 9622. >>> >>> multi-stream / multistream >>> >>> 3) We see that draft-ietf-taps-interface uses the unquoted form Interface >>> Instance >>> or Type (enclosed in <tt> in the XML file), but draft-ietf-taps-impl >>> uses the quoted form "Interface Instance or Type". Which style is >>> preferred? >>> >>> >>> 4) Please verify that the capitalization of terms appears as desired for >>> the cluster. >>> >>> NOTE: Due to the large number of terms as well as the nature of their use, >>> we suggest that >>> authors make any edits directly to the XML files (instead of via email) for >>> ease of use and >>> to avoid any possible confusion. Further, we suggest getting any other >>> substantive changes >>> made to the documents prior to implementing these updates for ease of >>> review in diff files >>> (this is likely directed mostly toward RFC 9623 at this point). >>> >>> A list of these terms has been posted here: >>> >>> https://www.rfc-editor.org/authors/clusterC508caps.txt >>> >>> Notes about the list: >>> >>> -we have grouped the list according to topic instead of alphanumerically to >>> aid in showing >>> possible discrepancies. >>> >>> -we have marked the terms with “c” that we have already identified as >>> likely impacting more >>> than one document in the cluster (this may not be exhaustive). Note also >>> that the list may >>> include terms we made consistent in our question 1 above (for >>> completeness). >>> >>> -we have included some comments and questions in the list itself. Please >>> review. >>> >>> At a minimum, we suggest making identifiable patterns consistent throughout >>> the document set with regard to capitalization (of both the name itself and >>> the label). >>> >>> For example: >>> >>> properties: >>> examples: >>> preferred properties vs. Preferred properties >>> Protocol Selection Property vs. interface Selection Property >>> Message Properties vs. Message Contexts vs. Message Context Property >>> >>> actions: >>> example: termination action vs. Abort action >>> >>> objects: >>> example: Listener object vs. ErrorCode Object >>> >>> events: >>> example: receive event vs. Receive event (vs. Received event) >>> Note - events have been made consistent with regard to the use of <> in >>> RFC-to-be 9622. >>> >>> 5) We have already sent some document-specific queries related to the use >>> of <tt>. For your convenience, we have also created a cluster-wide list >>> that is sorted alphanumerically and marked by RFC number: >>> >>> https://www.rfc-editor.org/authors/clusterC508tt.txt >>> >>> Please verify that the use of <tt> appears as desired both within the >>> documents and across the cluster. Again, any desired updates are best >>> communicated through updates to the XML file itself. >>> >>> Thank you. >>> >>> RFC Editor/mf >>> >>> >>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
