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. 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. 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. 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. "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. 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
