Hi Megan / RFC Editor team, I can confirm that all desired updates appear as intended, but I don’t want to voice my approval to go ahead yet because there’s still one missing item: fixing the capitalization (which really applies to all three documents).
I am halfway (or perhaps a bit more) through your extremely long list of terms (and I’m very thankful for the work you’ve put into this: *creating* this list must have been a terrible task!). Some of them require careful manual inspection. I’m doing my very best to finish this as quickly as possible. I make direct edits to the XML; once these are done I’ll be happy to give my go-ahead. Cheers, Michael > On Dec 17, 2024, at 1:55 AM, Megan Ferguson <mfergu...@amsl.com> wrote: > > 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
