Hi all, I just wanted to state that I agree with all of these changes: the updates by the RFC Editor are all fine, and I also agree with what Reese says below.
Cheers, Michael > On Dec 6, 2024, at 10:56 PM, Reese Enghardt <i...@tenghardt.net> wrote: > > Hi all, > > Thank you Michael for the replies and the spotted issues, and thank you Megan > and the RFC Editor for the excellent editing work! > > > Reading through the diff just now, the following bits stood out to me: > > > Section 4.1.3: > > Just wanting to make sure it doesn't get lost, as it looked like the other > changes were incorporated: I still see the split of the word implementation > that Michael flagged, both in the diff and the most recent .txt file, even > after a "force refresh" in my browser. The word looks as expected in the html > though. > > OLD: > > "Capacity Profile" (property name connCapacityProfile): An implement > ation can use the capacity profile to prefer paths that match an > application's expected traffic profile. > > NEW: > > "Capacity Profile" (property name connCapacityProfile): An > implementation can use the capacity profile to prefer paths that > match an application's expected traffic profile. > > > Section 9.2: > > I think "battery level" doesn't need to be hyphenated here. > > OLD: > > This could for instance be signal strength information reported by radio > modems like Wi-Fi and mobile broadband or information about the battery-level > of the device. > > NEW: > > This could for instance be signal strength information reported by radio > modems like Wi-Fi and mobile broadband or information about the battery level > of the device. > > > Authors' Addresses: > > It appears that "California" was changed to "CA" once, but changed from "CA" > to "California" in another address. Perhaps these should all be made > consistent, I have no strong opinions on which one to use, but perhaps "CA" > as it's shorter. > > I saw a similar inconsistency in the Author's Addresses section of > draft-ietf-taps-interface, while draft-ietf-taps-arch only has "CA". > > > Best, > Reese > > > On 12/5/24 10:49, Megan Ferguson wrote: >> Hi Michael, >> >> Thank you for your reply and guidance to our questions as well as spotting >> the other issues. We have updated as requested in your last two mails. >> >> 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) >> >> 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 5, 2024, at 6:05 AM, Michael Welzl <mich...@ifi.uio.no> wrote: >>> >>> Dear all, >>> >>> Complementing yesterday’s email in which I sent answers to the questions, >>> here is a short list of changes - just a few small issues that I found when >>> reading the diff. >>> As always, many, many thanks to the RFC Editor staff for their great work >>> with this! >>> >>> Below, “MW:” indicates a explanation / comment line from me. >>> >>> ======= >>> >>> >>> MW: I think this “an” should become “a” due to acronym expansion. >>> >>> Section 2: >>> >>> OLD: >>> Once the Connection is established, the Transport Services >>> Implementation maps actions and events to the details of the chosen >>> Protocol Stack. For example, the same Connection object may >>> ultimately represent a single transport protocol instance (e.g., a >>> TCP connection, a TLS session over TCP, a UDP flow with fully >>> specified Local and Remote Endpoint Identifiers, a DTLS session, an >>> Stream Control Transmission Protocol (SCTP) stream, a QUIC stream, or >>> an HTTP/2 stream). The Connection Properties held by a Connection or >>> Listener are independent of other Connections that are not part of >>> the same Connection Group. >>> >>> NEW: >>> Once the Connection is established, the Transport Services >>> Implementation maps actions and events to the details of the chosen >>> Protocol Stack. For example, the same Connection object may >>> ultimately represent a single transport protocol instance (e.g., a >>> TCP connection, a TLS session over TCP, a UDP flow with fully >>> specified Local and Remote Endpoint Identifiers, a DTLS session, a >>> Stream Control Transmission Protocol (SCTP) stream, a QUIC stream, or >>> an HTTP/2 stream). The Connection Properties held by a Connection or >>> Listener are independent of other Connections that are not part of >>> the same Connection Group. >>> >>> >>> >>> MW: I *believe* “have” should be “has” after “each of which”, but I’m >>> unsure (I’m not a native speaker). As Spencer Dawkins would say: “please do >>> the right thing” :-) >>> >>> Section 3.1: >>> >>> OLD: >>> The Transport Services system should have a list of supported >>> protocols available, each of which have transport features reflecting >>> the capabilities of the protocol. Once an application specifies its >>> Transport Properties, the Transport Services system matches the >>> required and prohibited properties against the transport features of >>> the available protocols (see Section 6.2 of [RFC9622] for the >>> definition of property preferences). >>> >>> NEW: >>> The Transport Services system should have a list of supported >>> protocols available, each of which has transport features reflecting >>> the capabilities of the protocol. Once an application specifies its >>> Transport Properties, the Transport Services system matches the >>> required and prohibited properties against the transport features of >>> the available protocols (see Section 6.2 of [RFC9622] for the >>> definition of property preferences). >>> >>> >>> >>> MW: it seems a wrong line break happened here in the middle of the word >>> “implementation”. >>> >>> Section 4.1.3: >>> >>> OLD: >>> "Capacity Profile" (property name connCapacityProfile): An implement >>> ation can use the capacity profile to prefer paths that match an >>> application's expected traffic profile. This match will use >>> cached performance estimates; see Section 9.2. Some examples of >>> path preferences based on capacity profiles include: >>> >>> NEW: >>> "Capacity Profile" (property name connCapacityProfile): An >>> implementation can use the capacity profile to prefer paths that match >>> an application's expected traffic profile. This match will use >>> cached performance estimates; see Section 9.2. Some examples of >>> path preferences based on capacity profiles include: >>> >>> >>> >>> MW: Section 5.1.1: I see that you capitalized the first word after each >>> list item here (e.g., “when” became “When” after “msgOrdered:”). However, >>> this seems inconsistent: both after “msgLifetime:” and “msgPriority:”, >>> “this” should probably become “This” for consistency. >>> >>> OLD: >>> msgLifetime: this should be implemented by removing the Message from >>> the queue of pending Messages after the Lifetime has expired. A >>> >>> NEW: >>> msgLifetime: This should be implemented by removing the Message from >>> the queue of pending Messages after the Lifetime has expired. A >>> >>> and: >>> >>> OLD: >>> msgPriority: this represents the ability to prioritize a Message >>> over other Messages. This can be implemented by the Transport >>> >>> NEW: >>> msgPriority: This represents the ability to prioritize a Message >>> over other Messages. This can be implemented by the Transport >>> >>> >>> >>> Cheers, >>> Michael >>> >>> >>> >>>> On 25 Nov 2024, at 17:08, rfc-edi...@rfc-editor.org wrote: >>>> >>>> *****IMPORTANT***** >>>> >>>> Updated 2024/11/25 >>>> >>>> RFC Author(s): >>>> -------------- >>>> >>>> Instructions for Completing AUTH48 >>>> >>>> Your document has now entered AUTH48. Once it has been reviewed and >>>> approved by you and all coauthors, it will be published as an RFC. >>>> If an author is no longer available, there are several remedies >>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>>> >>>> You and you coauthors are responsible for engaging other parties >>>> (e.g., Contributors or Working Group) as necessary before providing >>>> your approval. >>>> >>>> Planning your review >>>> --------------------- >>>> >>>> Please review the following aspects of your document: >>>> >>>> * RFC Editor questions >>>> >>>> Please review and resolve any questions raised by the RFC Editor >>>> that have been included in the XML file as comments marked as >>>> follows: >>>> >>>> <!-- [rfced] ... --> >>>> >>>> These questions will also be sent in a subsequent email. >>>> >>>> * Changes submitted by coauthors >>>> >>>> Please ensure that you review any changes submitted by your >>>> coauthors. We assume that if you do not speak up that you >>>> agree to changes submitted by your coauthors. >>>> >>>> * Content >>>> >>>> Please review the full content of the document, as this cannot >>>> change once the RFC is published. Please pay particular attention to: >>>> - IANA considerations updates (if applicable) >>>> - contact information >>>> - references >>>> >>>> * Copyright notices and legends >>>> >>>> Please review the copyright notice and legends as defined in >>>> RFC 5378 and the Trust Legal Provisions >>>> (TLP – https://trustee.ietf.org/license-info). >>>> >>>> * Semantic markup >>>> >>>> Please review the markup in the XML file to ensure that elements of >>>> content are correctly tagged. For example, ensure that <sourcecode> >>>> and <artwork> are set correctly. See details at >>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>> >>>> * Formatted output >>>> >>>> Please review the PDF, HTML, and TXT files to ensure that the >>>> formatted output, as generated from the markup in the XML file, is >>>> reasonable. Please note that the TXT will have formatting >>>> limitations compared to the PDF and HTML. >>>> >>>> >>>> Submitting changes >>>> ------------------ >>>> >>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>>> the parties CCed on this message need to see your changes. The parties >>>> include: >>>> >>>> * your coauthors >>>> >>>> * rfc-edi...@rfc-editor.org (the RPC team) >>>> >>>> * other document participants, depending on the stream (e.g., >>>> IETF Stream participants are your working group chairs, the >>>> responsible ADs, and the document shepherd). >>>> >>>> * auth48archive@rfc-editor.org, which is a new archival mailing list >>>> to preserve AUTH48 conversations; it is not an active discussion >>>> list: >>>> >>>> * More info: >>>> >>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>> >>>> * The archive itself: >>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>> >>>> * Note: If only absolutely necessary, you may temporarily opt out >>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>> If needed, please add a note at the top of the message that you >>>> have dropped the address. When the discussion is concluded, >>>> auth48archive@rfc-editor.org will be re-added to the CC list and >>>> its addition will be noted at the top of the message. >>>> >>>> You may submit your changes in one of two ways: >>>> >>>> An update to the provided XML file >>>> — OR — >>>> An explicit list of changes in this format >>>> >>>> Section # (or indicate Global) >>>> >>>> OLD: >>>> old text >>>> >>>> NEW: >>>> new text >>>> >>>> You do not need to reply with both an updated XML file and an explicit >>>> list of changes, as either form is sufficient. >>>> >>>> We will ask a stream manager to review and approve any changes that seem >>>> beyond editorial in nature, e.g., addition of new text, deletion of text, >>>> and technical changes. Information about stream managers can be found in >>>> the FAQ. Editorial changes do not require approval from a stream manager. >>>> >>>> >>>> Approving for publication >>>> -------------------------- >>>> >>>> To approve your RFC for publication, please reply to this email stating >>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>> as all the parties CCed on this message need to see your approval. >>>> >>>> >>>> Files >>>> ----- >>>> >>>> The files are available here: >>>> https://www.rfc-editor.org/authors/rfc9623.xml >>>> https://www.rfc-editor.org/authors/rfc9623.html >>>> https://www.rfc-editor.org/authors/rfc9623.pdf >>>> https://www.rfc-editor.org/authors/rfc9623.txt >>>> >>>> Diff file of the text: >>>> https://www.rfc-editor.org/authors/rfc9623-diff.html >>>> https://www.rfc-editor.org/authors/rfc9623-rfcdiff.html (side by side) >>>> >>>> Diff of the XML: >>>> https://www.rfc-editor.org/authors/rfc9623-xmldiff1.html >>>> >>>> >>>> Tracking progress >>>> ----------------- >>>> >>>> The details of the AUTH48 status of your document are here: >>>> https://www.rfc-editor.org/auth48/rfc9623 >>>> >>>> Please let us know if you have any questions. >>>> >>>> Thank you for your cooperation, >>>> >>>> RFC Editor >>>> >>>> -------------------------------------- >>>> RFC9623 (draft-ietf-taps-impl-18) >>>> >>>> Title : Implementing Interfaces to Transport Services >>>> Author(s) : A. Brunstrom, Ed., T. Pauly, Ed., R. Enghardt, P. >>>> Tiesel, M. Welzl >>>> WG Chair(s) : Reese Enghardt, Aaron Falk >>>> >>>> Area Director(s) : Zaheduzzaman Sarker, Francesca Palombini >>>> >>>> >> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
