Greetings, Tommy - Thanks for sending along your approvals for each of the RFCs to be in this cluster. We have updated the AUTH48 status pages accordingly.
Just a reminder to everyone that the AUTH48 status pages for this cluster can be viewed at https://www.rfc-editor.org/auth48/C508. In looking through the AUTH48 status pages, it appears as though we’ve received approvals at some point in the process from each author of RFC-to-be 9622. Michael - can you please confirm that all desired updates appear as intended in RFC-to-be 9622 and reconfirm your approval? Once we receive this, we can change the state to AUTH48-DONE while it awaits the other two docs in this cluster. For the other authors, we will assume your approvals stand unless we hear otherwise. Thank you. RFC Editor/mf > On Dec 13, 2024, at 10:30 AM, Tommy Pauly <tpa...@apple.com> wrote: > > 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
