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
