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
