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