Dear all, I agree with all of Anna’s edits below.
Anna, see below: > On Dec 29, 2024, at 7:14 PM, Anna Brunström <anna.brunst...@kau.se> wrote: > > Hi Michael, > > Thanks for the further clarifications below. I then think we should update > Section 10.5 to be consistent with the rest of the document and the defined > principles. The text for UDP and UDP Multicast receive is very similar and I > found it confusing that we use “UDP connection” but “UDP Multicast Receive > Connection”. I think we should be consistent throughout the document and not > just within each subsection. My suggested edits for Section 10.5 as well as > two small nits for the SCTP part are indicated below. Many thanks, these are all good, and much appreciated. > This is the last of my comments for 9623. And to be clear, I think you did an > excellent job with all the capitalization work! Many thanks, this means a lot to me, it really does. > My suggested edits are just final polishing after reading with fresh eyes. So > still owe you lots of beer J Haha :-) Cheers, Michael > > Best Regards, > Anna > > OLD: > Initiate: Calling Initiate on a UDP Multicast Receive Connection causes an > immediate EstablishmentError. This is an unsupported operation. > NEW: > Initiate: Calling Initiate on a UDP Multicast Receive connection causes an > immediate EstablishmentError. This is an unsupported operation. > > OLD: > InitiateWithSend: Calling InitiateWithSend on a UDP Multicast Receive > Connection causes an immediate EstablishmentError. This is an unsupported > operation. > NEW: > InitiateWithSend: Calling InitiateWithSend on a UDP Multicast Receive > connection causes an immediate EstablishmentError. This is an unsupported > operation. > > OLD: > Ready: A UDP Multicast Receive Connection is ready once the system has > received traffic for the appropriate group and port. > NEW: > Ready: A UDP Multicast Receive connection is ready once the system has > received traffic for the appropriate group and port. > > OLD: > EstablishmentError: UDP Multicast Receive Connections generate an > EstablishmentError indicating that joining a multicast group failed if > Initiate is called. > NEW: > EstablishmentError: UDP Multicast Receive connections cause an > EstablishmentError indicating that joining a multicast group failed if > Initiate is called. > > OLD: > ConnectionError: The only ConnectionError generated by a UDP Multicast > Receive Connection is in response to an Abort action. > NEW: > ConnectionError: The only ConnectionError caused by a UDP Multicast Receive > connection is in response to an Abort action. > > OLD: > Clone: Calling Clone on a UDP Multicast Receive Connection creates a new > Connection with equivalent parameters. The two Connections are otherwise > independent. > NEW: > Clone: Calling Clone on a UDP Multicast Receive connection creates a new UDP > Multicast Receive connection with equivalent parameters. The two associated > Connection objects are otherwise independent. > > OLD: > Send: SEND.UDP. Calling Send on a UDP Multicast Receive Connection causes > an immediate SendError. This is an unsupported operation. > NEW: > Send: SEND.UDP. Calling Send on a UDP Multicast Receive connection causes > an immediate SendError. This is an unsupported operation. > > OLD: > Receive: RECEIVE.UDP. The Receive action in a UDP Multicast Receive > Connection only delivers complete Messages to Received, each of which > represents a single datagram received in a UDP packet. > NEW: > Receive: RECEIVE.UDP. UDP Multicast Receive only delivers complete Messages > to Received, each of which represents a single datagram received in a UDP > packet. > > OLD: > Close: Calling Close on a UDP Multicast Receive Connection (ABORT.UDP) > releases the local port reservation and leaves the group. The Connection > then issues a Closed event. > NEW: > Close: Calling Close on a UDP Multicast Receive connection (ABORT.UDP) > releases the local port reservation and leaves the group. A Closed event is > then issued. > > OLD: > Abort: Calling Abort on a UDP Multicast Receive 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 Multicast Receive 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 Multicast Receive 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 Multicast Receive 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 Multicast Receive 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 Multicast Receive connection > (ABORT.UDP) is identical to calling Close on its Connection object and on all > Connections in the same ConnectionGroup. > > OLD: > Else, the Connection object is one out of several Connection objects that are > assigned to the same SCTP association, and RESET_STREAM.SCTP must be called, > which informs the peer that the stream will no longer be used for mapping and > can be used by future Initiate, InitiateWithSend, or Listen action. > NEW: > Else, the Connection object is one out of several Connection objects that are > assigned to the same SCTP association, and RESET_STREAM.SCTP must be called, > which informs the peer that the stream will no longer be used for mapping and > can be used by a future Initiate, InitiateWithSend, or Listen action. > --- I am not a native speaker, but I think there is an “a” missing in front > of “future”. The text was changed to use “action” in singular instead of > “calls” so I am guessing it was missed in the update. > > OLD: > The resulting local RESET_STREAM-EVENT.SCTP informs the Transport Services > System that the stream id can now be reused by the next Initiate, > InitiateWithSend, or Listen actions, and invokes a Closed event toward the > application. > NEW: > The resulting local RESET_STREAM-EVENT.SCTP informs the Transport Services > System that the stream id can now be reused by the next Initiate, > InitiateWithSend, or Listen action, and invokes a Closed event toward the > application. > --- I think this sentence should have “action” in singular. > > > From: Michael Welzl <mich...@ifi.uio.no> > Sent: den 28 december 2024 14:04 > To: Anna Brunström <anna.brunst...@kau.se> > Cc: Megan Ferguson <mfergu...@amsl.com>; Philipp S. Tiesel > <phil...@tiesel.net>; 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 > > 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 > <mailto: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 <mailto:mfergu...@amsl.com>>; Philipp > S. Tiesel <phil...@tiesel.net <mailto:phil...@tiesel.net>> > Cc: Michael Welzl <mich...@ifi.uio.no <mailto:mich...@ifi.uio.no>>; Mirja > Kuehlewind <mirja.kuehlew...@ericsson.com > <mailto:mirja.kuehlew...@ericsson.com>>; Brian Trammell <i...@trammell.ch > <mailto:i...@trammell.ch>>; Tommy Pauly <tpa...@apple.com > <mailto:tpa...@apple.com>>; Colin Perkins <c...@csperkins.org > <mailto:c...@csperkins.org>>; Gorry Fairhurst <go...@erg.abdn.ac.uk > <mailto:go...@erg.abdn.ac.uk>>; Reese Enghardt <i...@tenghardt.net > <mailto:i...@tenghardt.net>>; Zaheduzzaman Sarker > <zahed.sarker.i...@gmail.com <mailto:zahed.sarker.i...@gmail.com>>; > rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>; > taps-...@ietf.org <mailto:taps-...@ietf.org>; taps-cha...@ietf.org > <mailto:taps-cha...@ietf.org>;auth48archive@rfc-editor.org > <mailto: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 <mailto:mfergu...@amsl.com>>; Philipp > S. Tiesel <phil...@tiesel.net <mailto:phil...@tiesel.net>> > Cc: Michael Welzl <mich...@ifi.uio.no <mailto:mich...@ifi.uio.no>>; Mirja > Kuehlewind <mirja.kuehlew...@ericsson.com > <mailto:mirja.kuehlew...@ericsson.com>>; Brian Trammell <i...@trammell.ch > <mailto:i...@trammell.ch>>; Tommy Pauly <tpa...@apple.com > <mailto:tpa...@apple.com>>; Colin Perkins <c...@csperkins.org > <mailto:c...@csperkins.org>>; Gorry Fairhurst <go...@erg.abdn.ac.uk > <mailto:go...@erg.abdn.ac.uk>>; Reese Enghardt <i...@tenghardt.net > <mailto:i...@tenghardt.net>>; Zaheduzzaman Sarker > <zahed.sarker.i...@gmail.com <mailto:zahed.sarker.i...@gmail.com>>; > rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>; > taps-...@ietf.org <mailto:taps-...@ietf.org>; taps-cha...@ietf.org > <mailto:taps-cha...@ietf.org>;auth48archive@rfc-editor.org > <mailto: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 <mailto:mfergu...@amsl.com>>; Philipp > S. Tiesel <phil...@tiesel.net <mailto:phil...@tiesel.net>> > Cc: Michael Welzl <mich...@ifi.uio.no <mailto:mich...@ifi.uio.no>>; Mirja > Kuehlewind <mirja.kuehlew...@ericsson.com > <mailto:mirja.kuehlew...@ericsson.com>>; Brian Trammell <i...@trammell.ch > <mailto:i...@trammell.ch>>; Tommy Pauly <tpa...@apple.com > <mailto:tpa...@apple.com>>; Colin Perkins <c...@csperkins.org > <mailto:c...@csperkins.org>>; Gorry Fairhurst <go...@erg.abdn.ac.uk > <mailto:go...@erg.abdn.ac.uk>>; Reese Enghardt <i...@tenghardt.net > <mailto:i...@tenghardt.net>>; Zaheduzzaman Sarker > <zahed.sarker.i...@gmail.com <mailto:zahed.sarker.i...@gmail.com>>; > rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>; > taps-...@ietf.org <mailto:taps-...@ietf.org>; taps-cha...@ietf.org > <mailto:taps-cha...@ietf.org>;auth48archive@rfc-editor.org > <mailto: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 <mailto:mfergu...@amsl.com>> > Sent: den 23 december 2024 17:07 > To: Philipp S. Tiesel <phil...@tiesel.net <mailto:phil...@tiesel.net>>; Anna > Brunström <anna.brunst...@kau.se <mailto:anna.brunst...@kau.se>> > Cc: Michael Welzl <mich...@ifi.uio.no <mailto:mich...@ifi.uio.no>>; Mirja > Kuehlewind <mirja.kuehlew...@ericsson.com > <mailto:mirja.kuehlew...@ericsson.com>>; Brian Trammell <i...@trammell.ch > <mailto:i...@trammell.ch>>; Tommy Pauly <tpa...@apple.com > <mailto:tpa...@apple.com>>; Colin Perkins <c...@csperkins.org > <mailto:c...@csperkins.org>>; Gorry Fairhurst <go...@erg.abdn.ac.uk > <mailto:go...@erg.abdn.ac.uk>>; Reese Enghardt <i...@tenghardt.net > <mailto:i...@tenghardt.net>>; Zaheduzzaman Sarker > <zahed.sarker.i...@gmail.com <mailto:zahed.sarker.i...@gmail.com>>; > rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>; > taps-...@ietf.org <mailto:taps-...@ietf.org>; taps-cha...@ietf.org > <mailto:taps-cha...@ietf.org>;auth48archive@rfc-editor.org > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 > <mailto:mich...@ifi.uio.no%20%3cmailto: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 > <mailto:mfergu...@amsl.com%20%3cmailto: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)---- > <mailto:ph...@in-panik.de)---%3e---(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)---- > <mailto: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>. > > 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
