Hi Gorry and Michael, Thanks for sending along the file for RFC 9621 updated for <tt> consistency. We used that version and added in the other cluster-wide update to use multistream (closed compound) as well as the changes Gorry requested.
We believe the only outstanding issue for this document is the response to the capitalization consistency cluster-wide query (#4). Please review the other updates and let us know if further changes are necessary. The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9621.txt https://www.rfc-editor.org/authors/rfc9621.pdf https://www.rfc-editor.org/authors/rfc9621.html https://www.rfc-editor.org/authors/rfc9621.xml Diff files are available here (please refresh): https://www.rfc-editor.org/authors/rfc9621-diff.html (comprehensive) https://www.rfc-editor.org/authors/rfc9621-rfcdiff.html (comprehensive rfcdiff) https://www.rfc-editor.org/authors/rfc9621-auth48diff.html (all AUTH48 changes) https://www.rfc-editor.org/authors/rfc9621-lastdiff.html (last version to this) https://www.rfc-editor.org/authors/rfc9621-lastrfcdiff.html (ditto but rfcdiff) Thank you. RFC Editor/mf > On Dec 9, 2024, at 7:52 AM, Gorry Fairhurst <go...@erg.abdn.ac.uk> wrote: > > Dear RFC-Ed, > > Please note that the following issues relating to Arch were not dealt with in > the cluster answer sent to the RFC Editor, but specifically relate to > improving consistency with draft-ietf-taps-arch: > 1. Could you please add this definition to the ARCH draft to be consistent > with other I-Ds in this cluster: > > Transport Services API: The abstract interface [REF-RFC9662] to a Transport > Services Implementation [REF-RFC9663]. > > --- > > 2. Please could you also please also change: > > OLD: > > Transport Services architecture > > NEW: > > Transport Services Architecture > > Throughout, although leaving the first usage as lower case, if you wish, > since it is not defined until the terminology section? > > --- > > Best wishes, > > Gorry > > On 03/12/2024 21:43, Megan Ferguson 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
