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 >>> >>> >>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
