Thanks Megan! I approve this latest version of RFC 9623. Best, Tommy
> On Dec 12, 2024, at 1:13 PM, Megan Ferguson <mfergu...@amsl.com> wrote: > > 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 9, 2024, at 6:31 PM, Reese Enghardt <i...@tenghardt.net >> <mailto:i...@tenghardt.net>> wrote: >> >> Hi Megan, >> >> Thank you, looks good to me now. I agree with all the changes. >> >> Best, >> Reese >> >> >> On 12/9/24 09:40, Megan Ferguson wrote: >>> Hi Reese (and Michael), >>> >>> Thanks for pointing these out. We have updated as requested. >>> >>> Two notes: >>> >>> 1) FYI: We did a little digging for the strange break in “implementation”; >>> it seems to be related to this issue >>> (https://github.com/ietf-tools/xml2rfc/issues/532). We ended up updating >>> the list to start the description on a new line, which might actually be >>> preferable due to the length of the lead-in text. >>> >>> 2) We have updated to use the closed compound multistream in this document >>> per Michael’s response to the cluster-wide questions. >>> >>> 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 version to >>> this) >>> https://www.rfc-editor.org/authors/rfc9623-lastrfcdiff.html (last to this >>> rfcdiff) >>> >>> 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 9, 2024, at 6:08 AM, Michael Welzl <mich...@ifi.uio.no> wrote: >>>> >>>> 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
