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
