Dear Anna, dear all, In short: I agree with all changes suggested by Anna in this email.
More below: > On Dec 27, 2024, at 7:37 PM, Anna Brunström <anna.brunst...@kau.se> wrote: > > Hi, > > Now finally, the comments for Section 10 in -impl. Here I think some of the > fixes created some problems. I take the first instance I encountered as an > example: > > "Calling Clone on a TCP connection creates a new Connection with equivalent > parameters. These Connections, and Connections generated via later calls to > Clone on an Established Connection, form a Connection Group." > > The change to "TCP connection" is of course correct, but the problem comes > when that connection is then referred to as "These Connections" and now all > of a sudden is a "Connection" rather than a "connection". It is also unclear > if the "new Connection" should be a "Connection" or "connection", both could > be possible. The root cause is that the text is a bit compressed and you do > not call Clone on a TCP connection, but on a Connection object mapped to a > TCP connection, so it gets a bit messy when now trying to distinguish and > keeping track of what refers to what. In the SCTP section the mapping is > explicitly mentioned, but in most other parts we use a more compressed text. Yes, I agree: there is some ambiguity in the text due to this compressed writing style. > I have tried to fix the text for TCP and UDP to get consistent references > without major edits in my suggested modifications below. Sorry about the > somewhat long list of suggested updates this late in the process. I tried to > keep track that the updates looked good overall and agreed with all the > principles used, but I had not looked closely enough on the details in > Section 10 until doing my final check today. > > I am also unsure why "UDP Multicast Receive Connection" is used and not "UDP > Multicast Receive connection" in Section 10.5? Is there something special > about UDP Multicast Receive that suggests it should not follow the general > principles and "UDP Multicast Receive connection" is not the correct term? > Perhaps it was just missed in the updates of the capitalization, but there is > one instance where it is modified in the opposite direction, from > "connection" to "Connection" suggesting it is a deliberate choice. There isn’t anything special about it; as you will have seen in my answers to Reese, my decisions were guided by the “layer above / layer below” logic but also: - how often do certain terms already appear in a certain form in all documents? (the goal being to minimize changes) - how is it written in the -arch document? (which should probably take precedence over the others) I thought it’s okay to go with such choices rather than “correctness” in some cases due to the aforementioned ambiguity. Trying to be 100% correct is really tricky here - on the one hand, I see the argument to use “connections” everywhere, but on the other, there are statements in section 10.5 such as: "UDP Multicast Receive Connections generate an EstablishmentError indicating that joining a multicast group failed if Initiate is called.” - which, surely, UDP per se doesn’t do in this exact form. So, that would be for the “Connection” instead. So It may be that I changed this on the basis of what’s more common instead, when this may have been a mistake. Looking at the previous version: https://ietf-tapswg.github.io/api-drafts/draft-ietf-taps-impl.html it seems to me that I just tried to make this uniform, and “Connection” was a more common use in the text. I hope this helps - and I’m sorry for any errors that I have introduced! Cheers, Michael > > Would be good if Michael can clarify the intentions with Section 10.5 before > I suggest edits for that section. Also check my suggested updates below and > see if you agree as you made the original edits. > > BR, > Anna > > OLD: > Clone: Calling Clone on a TCP connection creates a new Connection with > equivalent parameters. These Connections, and Connections generated via > later calls to Clone on an Established Connection, form a Connection Group. > NEW: > Clone: Calling Clone on a TCP connection creates a new TCP connection with > equivalent parameters. The two associated Connection objects, and > Connections generated via later calls to Clone on an Established Connection, > form a Connection Group. > > OLD: > Close: Calling Close on a TCP connection indicates that the Connection > should be gracefully closed (CLOSE.TCP) by sending a FIN to the peer. It > will then still be possible to receive data until the peer closes or aborts > the TCP connection. The Closed event will be issued upon reception of a FIN. > NEW: > Close: Calling Close on a TCP connection indicates that the TCP connection > should be gracefully closed (CLOSE.TCP) by sending a FIN to the peer. It > will then still be possible to receive data until the peer closes or aborts > the TCP connection. The Closed event will be issued upon reception of a FIN. > --- As written, I think "the Connection" must refer back to "a TCP > connection" and therefore also should be lower case. I added "TCP" just to > avoid any confusion. The similar argument applies to several of the suggested > modifications below. > > OLD: > Abort: Calling Abort on a TCP connection indicates that the Connection > should be immediately closed by sending a RST to the peer (ABORT.TCP). > NEW: > Abort: Calling Abort on a TCP connection indicates that the TCP connection > should be immediately closed by sending a RST to the peer (ABORT.TCP). > > OLD: > CloseGroup: Calling CloseGroup on a TCP connection (CLOSE.TCP) is identical > to calling Close on this Connection and on all Connections in the same > ConnectionGroup. > NEW: > CloseGroup: Calling CloseGroup on a TCP connection (CLOSE.TCP) is identical > to calling Close on its Connection object and on all Connections in the > same ConnectionGroup. > > OLD: > AbortGroup: Calling AbortGroup on a TCP connection (ABORT.TCP) is identical > to calling Abort on this Connection and on all Connections in the same > ConnectionGroup. > NEW: > AbortGroup: Calling AbortGroup on a TCP connection (ABORT.TCP) is identical > to calling Abort on its Connection object and on all Connections in the same > ConnectionGroup. > > OLD: > InitiateWithSend: Early data on a UDP connection does not have any special > meaning. The data is sent whenever the Connection is Ready. > NEW: > InitiateWithSend: Early data on a UDP connection does not have any special > meaning. The data is sent whenever the UDP connection is Ready. > > OLD: > ConnectionReceived: UDP Listeners will deliver new connections once they > have received traffic from a new Remote Endpoint. > NEW: > ConnectionReceived: UDP Listeners will deliver new Connections once they > have received traffic from a new Remote Endpoint. > --- Here I think we are talking about delivering new Connection objects so > should be upper case. > > OLD: > Clone: Calling Clone on a UDP connection creates a new Connection with > equivalent parameters. The two Connections are otherwise independent. > NEW: > Clone: Calling Clone on a UDP connection creates a new UDP connection with > equivalent parameters. The two associated Connection objects are otherwise > independent. > > OLD: > Close: Calling Close on a UDP connection (ABORT.UDP) releases the local port > reservation. The Connection then issues a Closed event. > NEW: > Close: Calling Close on a UDP connection (ABORT.UDP) releases the local port > reservation. A Closed event is then issued. > > OLD: > Abort: Calling Abort on a UDP connection (ABORT.UDP) is identical to calling > Close except that the Connection will send a ConnectionError event rather > than a Closed event. > NEW: > Abort: Calling Abort on a UDP connection (ABORT.UDP) is identical to calling > Close except that a ConnectionError event rather than a Closed event is > issued. > > OLD: > CloseGroup: Calling CloseGroup on a UDP connection (ABORT.UDP) is identical > to calling Close on this Connection and on all Connections in the same > ConnectionGroup. > NEW: > CloseGroup: Calling CloseGroup on a UDP connection (ABORT.UDP) is identical > to calling Close on its Connection object and on all Connections in the same > ConnectionGroup. > > OLD: > AbortGroup: Calling AbortGroup on a UDP connection (ABORT.UDP) is identical > to calling Close on this Connection and on all Connections in the same > ConnectionGroup. > NEW: > AbortGroup: Calling AbortGroup on a UDP connection (ABORT.UDP) is identical > to calling Close on its Connection object and on all Connections in the same > ConnectionGroup. > > > > > -----Original Message----- > From: Anna Brunström > Sent: den 27 december 2024 17:14 > To: Megan Ferguson <mfergu...@amsl.com>; Philipp S. Tiesel > <phil...@tiesel.net> > Cc: Michael Welzl <mich...@ifi.uio.no>; Mirja Kuehlewind > <mirja.kuehlew...@ericsson.com>; Brian Trammell <i...@trammell.ch>; Tommy > Pauly <tpa...@apple.com>; Colin Perkins <c...@csperkins.org>; Gorry Fairhurst > <go...@erg.abdn.ac.uk>; Reese Enghardt <i...@tenghardt.net>; Zaheduzzaman > Sarker <zahed.sarker.i...@gmail.com>; rfc-edi...@rfc-editor.org; > taps-...@ietf.org; taps-cha...@ietf.org; auth48archive@rfc-editor.org > Subject: RE: Cluster-Wide Questions for Cluster 508: ...: Comments for 9623 > > Hi, > > Now moving to -impl. I am splitting my comments in two parts, first all > comments excluding comments on Section 10 with the protocol mappings. I will > take Section 10 separately as there is where I think the capitalization > created some problems, as the original text was less precise, and my > co-authors may want to check those updates. > > OLD: > Candidate Racing involves attempting multiple options for Connection > establishment and choosing the first option to succeed as the Protocol Stack > to use for the connection. > NEW: > Candidate Racing involves attempting multiple options for Connection > establishment and choosing the first option to succeed as the Protocol Stack > to use for the Connection. > --- Connection here refers to the Connection object returned to the user and > should be capitalized. > > OLD: > 2. Protocol Options > NEW: > 2. Protocol options > --- Protocol options is not a term defined anywhere and is mostly used in > lower case in the document. We have Protocol Option Racing in -arch, but not > as a capitalized term used in the text, just defined as an action and > capitalized as all terms including Application and Protocol Instance. And it > is not the same term anyway. > > OLD: > Protocol Options are next checked in order. > NEW: > Protocol options are next checked in order. > --- See comment above. > > OLD: > The primary goal of the Candidate Racing process is to successfully negotiate > a Protocol Stack to an Endpoint over an interface to connect a single leaf > node of the tree with as little delay and as few unnecessary connections > attempts as possible. > NEW: > The primary goal of the Candidate Racing process is to successfully negotiate > a Protocol Stack to an Endpoint over an interface to connect a single leaf > node of the tree with as little delay and as few unnecessary connection > attempts as possible. > --- Typo in "connections attempts" > > OLD: > The function that implements custom framing logic will be referred to as the > "framer "Framer implementation", which may be provided by a Transport > Services implementation or the application itself. > NEW: > The function that implements custom framing logic will be referred to as the > "framer "Framer implementation", which may be provided by a Transport > Services Implementation or the application itself. > --- Implementation should be capitalized. > > OLD: > TCP can cache cookies for use in TFO > NEW: > TCP can cache cookies for use in TFO. > --- The period got lost in the update (I assume it was a mistake as the > bullet above has one). > > BR, > Anna > > > -----Original Message----- > From: Anna Brunström > Sent: den 27 december 2024 16:13 > To: Megan Ferguson <mfergu...@amsl.com>; Philipp S. Tiesel > <phil...@tiesel.net> > Cc: Michael Welzl <mich...@ifi.uio.no>; Mirja Kuehlewind > <mirja.kuehlew...@ericsson.com>; Brian Trammell <i...@trammell.ch>; Tommy > Pauly <tpa...@apple.com>; Colin Perkins <c...@csperkins.org>; Gorry Fairhurst > <go...@erg.abdn.ac.uk>; Reese Enghardt <i...@tenghardt.net>; Zaheduzzaman > Sarker <zahed.sarker.i...@gmail.com>; rfc-edi...@rfc-editor.org; > taps-...@ietf.org; taps-cha...@ietf.org; auth48archive@rfc-editor.org > Subject: RE: Cluster-Wide Questions for Cluster 508: ...: Comments for 9621 > > Hi again, > > Below are a few details for -arch. With the changes below, I approve the > document. > > BR, > Anna > > OLD: > Instead, it provides the Protocol Stack with additional information to allow > it to make better use of modern Transport Services, while simplifying the > application's role in parsing data. > NEW: > Instead, it provides the Protocol Stack with additional information to allow > it to make better use of modern transport protocols, while simplifying the > application's role in parsing data. > --- This change to upper case did not come out right, as it does not refer to > the Transport Services offered in the API, but the realization in the stack. > Changed to transport protocols to avoid any confusion. > > OLD: > The normative requirements described in this section allow Transport Services > APIs and the Transport Services Implementation to provide this functionality > without causing incompatibility or introducing security vulnerabilities. > NEW: > The normative requirements described in this section allow Transport Services > APIs and Transport Services Implementations to provide this functionality > without causing incompatibility or introducing security vulnerabilities. > --- If there are multiple Transport Services APIs there are multiple > Transport Services Implementations. > > OLD: > A single stack can be simple (e.g., one application stream carried TCP > running over IP) or complex (e.g,. multiple application streams carried over > a multipath transport protocol using multiple subflows over IP). > NEW: > A single stack can be simple (e.g., one application stream carried over TCP > running over IP) or complex (e.g,. multiple application streams carried over > a multipath transport protocol using multiple subflows over IP). > --- There must a be a word missing in "carried TCP", so added "over". > > > -----Original Message----- > From: Anna Brunström > Sent: den 27 december 2024 15:42 > To: Megan Ferguson <mfergu...@amsl.com>; Philipp S. Tiesel > <phil...@tiesel.net> > Cc: Michael Welzl <mich...@ifi.uio.no>; Mirja Kuehlewind > <mirja.kuehlew...@ericsson.com>; Brian Trammell <i...@trammell.ch>; Tommy > Pauly <tpa...@apple.com>; Colin Perkins <c...@csperkins.org>; Gorry Fairhurst > <go...@erg.abdn.ac.uk>; Reese Enghardt <i...@tenghardt.net>; Zaheduzzaman > Sarker <zahed.sarker.i...@gmail.com>; rfc-edi...@rfc-editor.org; > taps-...@ietf.org; taps-cha...@ietf.org; auth48archive@rfc-editor.org > Subject: RE: Cluster-Wide Questions for Cluster 508: RFCs 9621, 9622, and > 9623 (draft-ietf-taps-arch-19, draft-ietf-taps-interface-26, and > draft-ietf-taps-impl-18) > > Hi all, > > Thanks for all the efforts with the documents, and special thanks to Megan > and Michael for your huge efforts of course! > > Too many deadlines before Christmas, but I have now managed to go through all > the updates, and in particular all the capitalization changes. While I agree > with all the principles discussed, I detected a few places where it did not > work out right, as well as some other nits. To make it simpler and keep > things in order, let me split up my feedback in multiple mails. > > Let me start here with one cluster wide alignment that apply also to -api. We > use in the -arch document the term Candidate Protocol Stack, consistently > with capitalization in multiple places, but this has not been applied in > -impl or -api. Following the principles used, I think we should align the > other two documents. The following changes below are needed to align them. > > In 9622: > > OLD: > Once Initiate is called, the candidate Protocol Stack(s) can cause one or > more candidate transport-layer connections to be created to the specified > Remote Endpoint. > NEW: > Once Initiate is called, the Candidate Protocol Stack(s) can cause one or > more candidate transport-layer connections to be created to the specified > Remote Endpoint. > > OLD: > The Ready event occurs after Initiate has established a transport-layer > connection on at least one usable candidate Protocol Stack over at least > one Candidate Path. > NEW: > The Ready event occurs after Initiate has established a transport-layer > connection on at least one usable Candidate Protocol Stack over at least > one Candidate Path. > > In 9623: > > OLD: > During the process of establishment (Section 4), the Connection will not > necessarily be immediately bound to a transport protocol instance, since > multiple candidate Protocol Stacks might be raced. > NEW: > During the process of establishment (Section 4), the Connection will not > necessarily be immediately bound to a transport protocol instance, since > multiple Candidate Protocol Stacks might be raced. > > OLD: > Cached protocol state is primarily used during Connection establishment for a > single Protocol Stack, but it may be used to influence an implementation's > preference between several candidate Protocol Stacks. > NEW: > Cached protocol state is primarily used during Connection establishment for a > single Protocol Stack, but it may be used to influence an implementation's > preference between several Candidate Protocol Stacks. > > This was the only comment that applies to -api, which was already approved by > the authors. I will come back with my other comments in separate emails. > > Best, > Anna > > -----Original Message----- > From: Megan Ferguson <mfergu...@amsl.com> > Sent: den 23 december 2024 17:07 > To: Philipp S. Tiesel <phil...@tiesel.net>; Anna Brunström > <anna.brunst...@kau.se> > Cc: Michael Welzl <mich...@ifi.uio.no>; Mirja Kuehlewind > <mirja.kuehlew...@ericsson.com>; Brian Trammell <i...@trammell.ch>; Tommy > Pauly <tpa...@apple.com>; Colin Perkins <c...@csperkins.org>; Gorry Fairhurst > <go...@erg.abdn.ac.uk>; Reese Enghardt <i...@tenghardt.net>; Zaheduzzaman > Sarker <zahed.sarker.i...@gmail.com>; rfc-edi...@rfc-editor.org; > taps-...@ietf.org; taps-cha...@ietf.org; auth48archive@rfc-editor.org > Subject: Re: Cluster-Wide Questions for Cluster 508: RFCs 9621, 9622, and > 9623 (draft-ietf-taps-arch-19, draft-ietf-taps-interface-26, and > draft-ietf-taps-impl-18) > > Hi Philipp and *Anna, > > Philipp - thank you for your reply; we have updated your status to “Approved” > for RFC-to-be 9623. > > *Anna - once we hear your approvals for RFCs-to-be 9621 and 9623, this > document set will be ready to move forward in the publication process. We > look forward to hearing from you at your earliest convenience as our 2024 > publication window is soon to close. > > The AUTH48 status page for this document set is viewable at: > > https://www.rfc-editor.org/auth48/C508 > > Thank you. > > RFC Editor/mf > >> On Dec 22, 2024, at 6:42 AM, Philipp S. Tiesel <phil...@tiesel.net> wrote: >> >> Hi, >> >> first to all, but especially to Megan and Michael a very big thank you! >> >> I am fine with the edits and the current versions and authorise publication >> of RFC-to-be 9623. >> >> AVE! >> Philipp >> >>> On 21. Dec 2024, at 03:15, Megan Ferguson <mfergu...@amsl.com> wrote: >>> >>> Michael, >>> >>> Thanks for sending. We have updated and moved RFC-to-be 9622 to >>> AUTH48-DONE to await the other two documents. >>> >>> Thank you. >>> >>> RFC Editor/mf >>> >>> >>>> On Dec 20, 2024, at 6:20 PM, Michael Welzl <mich...@ifi.uio.no> wrote: >>>> >>>> I see that 9622 lacks my approval: I’m ok eith the latest changes and >>>> approve publication! >>>> >>>> Sent from my phone >>>> >>>>> Am 21.12.2024 um 02:55 schrieb Megan Ferguson <mfergu...@amsl.com>: >>>>> >>>>> Greetings, >>>>> >>>>> Just a final reminder for the year that this document set awaits author >>>>> actions. See the email thread below as well as the AUTH48 status page: >>>>> >>>>> https://www.rfc-editor.org/auth48/C508 >>>>> >>>>> Note that time is running out to move forward with a 2024 publication >>>>> date due to holidays etc. Please contact us at your earliest convenience >>>>> with approvals and/or updates. >>>>> >>>>> Thank you. >>>>> >>>>> RFC Editor/mf >>>>> >>>>>> On Dec 20, 2024, at 11:04 AM, Megan Ferguson <mfergu...@amsl.com> wrote: >>>>>> >>>>>> Michael and Mirja, >>>>>> >>>>>> Thanks for replies and explanations. We have updated the files and >>>>>> rolled these changes into the current versions of the diffs so as to >>>>>> keep access to the previous capping updates and all of the capping >>>>>> changes together where possible (to hopefully keep everyone in the loop). >>>>>> >>>>>> Notes: >>>>>> -Mirja’s first point that Michael suggests leaving as was: we have made >>>>>> no changes as this sounds acceptable to Mirja and Michael’s preference. >>>>>> >>>>>> -9622: we lowercased “Cellular data plan” in one instance. >>>>>> >>>>>> -9623: we updated to use only “policy” instead of “System Policy”. >>>>>> >>>>>> -9621: we have lowercased a single instance of “Message” and removed >>>>>> “Properties” as seemed agreeable to both Mirja and Michael. >>>>>> >>>>>> Please review and confirm that these updates appear as desired. >>>>>> >>>>>> The AUTH48 status page for the entire cluster is viewable here: >>>>>> https://www.rfc-editor.org/auth48/C508 >>>>>> >>>>>> Each document’s updated files and diffs are available as listed below: >>>>>> >>>>>> 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 >>>>>> >>>>>> The relevant diff files have been posted here (please refresh): >>>>>> https://www.rfc-editor.org/authors/rfc9621-diff.html >>>>>> (comprehensive diff) >>>>>> https://www.rfc-editor.org/authors/rfc9621-auth48diff.html (AUTH48 >>>>>> changes only) >>>>>> https://www.rfc-editor.org/authors/rfc9621-lastdiff.html (last to >>>>>> current version only) >>>>>> https://www.rfc-editor.org/authors/rfc9621-lastrfcdiff.html (ditto >>>>>> but rfcdiff) >>>>>> >>>>>> The following diff contains the capping changes from the last two rounds >>>>>> together: >>>>>> https://www.rfc-editor.org/authors/rfc9621caps-diff.html >>>>>> >>>>>> —— >>>>>> >>>>>> 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) >>>>>> https://www.rfc-editor.org/authors/rfc9622-lastrfcdiff.html (ditto >>>>>> but rfcdiff) >>>>>> >>>>>> >>>>>> —— >>>>>> >>>>>> 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) >>>>>> https://www.rfc-editor.org/authors/rfc9623-lastrfcdiff.html (ditto >>>>>> but rfcdiff) >>>>>> >>>>>> The following diff contains the capping changes from the last two rounds >>>>>> together: >>>>>> https://www.rfc-editor.org/authors/rfc9623caps-diff.html >>>>>> >>>>>> Please review carefully and let us know if any further changes are >>>>>> necessary. >>>>>> >>>>>> Thank you. >>>>>> >>>>>> RFC Editor/mf >>>>>> >>>>>>>> On Dec 20, 2024, at 10:08 AM, Michael Welzl <mich...@ifi.uio.no> wrote: >>>>>>> >>>>>>> Hi Mirja, >>>>>>> >>>>>>> Many thanks for taking a careful look! I’m sorry, I can’t do any more >>>>>>> updates for a while now - perhaps someone else could have a go at these? >>>>>>> >>>>>>> Answers below: >>>>>>> >>>>>>> >>>>>>>> On Dec 20, 2024, at 8:43 PM, Mirja Kuehlewind >>>>>>>> <mirja.kuehlew...@ericsson.com> wrote: >>>>>>>> >>>>>>>> Hi Michael, >>>>>>>> >>>>>>>> thanks for the huge amount of work! >>>>>>>> >>>>>>>> Sorry that I have to say this but I'm not fully convinced regarding >>>>>>>> the capitalization of Connection, Property and Messages. I think I >>>>>>>> would have preference to keep them lower case in most of the cases, >>>>>>>> and use upper case really only if a very specific "implementation >>>>>>>> instance" is meant. However, I can fully live with the current >>>>>>>> approach now as long as it is unified. >>>>>>> >>>>>>> First and foremost, I wanted to minimize changes, or at least stay true >>>>>>> to the original intention. I think what I did follows that - we have >>>>>>> long used capitalization of these terms to distinguish between the >>>>>>> “upper layer” and the “lower layer”. For Connection, the -arch draft >>>>>>> (9621) even explicitly says this, in two places (search for “capital”). >>>>>>> So I think we should keep these as they are. >>>>>>> >>>>>>> >>>>>>>> Still, I have a few comments though where I find something not >>>>>>>> completely right in my review: >>>>>>>> >>>>>>>> First, I agree with Reese on the use of " Cellular data plan" in >>>>>>>> RFC9622. This is just an example and normal word in a sentence and >>>>>>>> does not relate to any property in this occurrence and therefore >>>>>>>> should be lower case. >>>>>>> >>>>>>> As I explained, I did this to follow what already was the common style >>>>>>> in the documents; but this is totally fine with me, and I can’t imagine >>>>>>> anyone strongly disagreeing. Let’s lower-case it. >>>>>>> >>>>>>> >>>>>>>> For RFC9623, I did struggle with this occurrence of "System policy" >>>>>>>> (this sentence is twice in the doc): >>>>>>>> >>>>>>>> "Similar to a derived endpoint, the paths should be ranked based on >>>>>>>> preference, System Policy, and performance." >>>>>>>> >>>>>>>> Because it's listed here between preference and performance I think it >>>>>>>> should be lower case. Or you could even remove the word "System" and >>>>>>>> only use policy as an undefined term to avoid confusion. >>>>>>> >>>>>>> Ok for me to change. >>>>>>> >>>>>>> >>>>>>>> And for RFC9621, I have these two cases: >>>>>>>> >>>>>>>> "The Socket API provides a Message interface for datagram protocols" >>>>>>>> >>>>>>>> It's _a_ undefined message interface. Here message interface is just >>>>>>>> used as a specific kind of interface and not _the_ message interface >>>>>>>> we use in TAPS. >>>>>>> >>>>>>> Good catch, I agree. >>>>>>> >>>>>>> >>>>>>>> "This automated selection is constrained by the Properties and >>>>>>>> preferences expressed by the application and requires applications to >>>>>>>> explicitly set Properties that define any necessary constraints on >>>>>>>> protocol, path, and interface selection." >>>>>>>> >>>>>>>> I would either lower-case "Properties" when noted together with >>>>>>>> "preferences" or remove it, because preferences are expressed by >>>>>>>> Properties. >>>>>>> >>>>>>> I don’t really see the problem here; I’m against lower-casing >>>>>>> “Properties”, but removing it would be okay. >>>>>>> >>>>>>> Cheers, >>>>>>> Michael >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks again. Just my 2c... >>>>>>>> >>>>>>>> Mirja >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 20.12.24, 04:52, "Michael Welzl" <mich...@ifi.uio.no >>>>>>>> <mailto:mich...@ifi.uio.no>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi ! >>>>>>>> >>>>>>>> >>>>>>>> Here come the new versions! >>>>>>>> >>>>>>>> >>>>>>>> Once these changes are incorporated, I approve publication wherever >>>>>>>> it’s missing (as a co-author: RFCs 9622 and 9623). >>>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Michael >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Dec 20, 2024, at 12:00 AM, Megan Ferguson <mfergu...@amsl.com >>>>>>>>> <mailto:mfergu...@amsl.com>> wrote: >>>>>>>>> >>>>>>>>> Hi Michael, >>>>>>>>> >>>>>>>>>> I will apply all of these changes to the XML files (the latest >>>>>>>>>> version you sent) and send them back to you. >>>>>>>>> >>>>>>>>> Excellent. We will await the files updated with all of the changes >>>>>>>>> before taking any action on our end. >>>>>>>>> >>>>>>>>> As to the get-together: thanks for the invite! You will have to reach >>>>>>>>> out to whoever ends up at the RFC Editor desk at IETF if you would >>>>>>>>> like help celebrating this accomplishment :). We were happy to do our >>>>>>>>> part and very much appreciate your time and attention in getting this >>>>>>>>> cluster ready for publication (no easy feat on Michael’s part)! >>>>>>>>> >>>>>>>>> RFC Editor/mf >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >>> >> >> AVE! >> Philipp S. Tiesel / phils… >> -- >> {phils}--->---(ph...@in-panik.de)--->---(http://phils.in-panik.de)----, >> wenn w eine aube ist dn man au dran dre en | >> o Schr an muss hc h (Kurt Schwitters) | >> :wq! <----(phone: +49-179-6737439)---<---(jabber: ph...@in-panik.de)----' >> > > När du skickar e-post till Karlstads universitet behandlar vi dina > personuppgifter<https://www.kau.se/gdpr>. > When you send an e-mail to Karlstad University, we will process your personal > data<https://www.kau.se/en/gdpr>.
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
