You asked for a last review, which seems reasonable, but I am on vacation this week, so that won't happen until next week.
> On 28 Apr 2025, at 16:08, Sarah Tarrant <starr...@staff.rfc-editor.org> wrote: > > Hi Ted and Stuart, > > This is a friendly reminder that we have yet to hear back from you regarding > this document’s readiness for publication. > > Please review the AUTH48 status page > (http://www.rfc-editor.org/auth48/rfc9665) for further information and the > previous messages in this thread for pertinent communication. > > Thank you, > RFC Editor/st > >> On Apr 22, 2025, at 9:24 AM, Sarah Tarrant <starr...@staff.rfc-editor.org> >> wrote: >> >> Hi Ted, >> >> Thank you for your reply. We have updated the document accordingly. >> >> Please review the document carefully to ensure satisfaction as we do not >> make changes once it has been published as an RFC. Contact us with any >> further updates or with your approval of the document in its current form. >> We will await approvals from each author prior to moving forward in the >> publication process. >> >> The updated files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9665.txt >> https://www.rfc-editor.org/authors/rfc9665.pdf >> https://www.rfc-editor.org/authors/rfc9665.html >> https://www.rfc-editor.org/authors/rfc9665.xml >> >> The relevant diff files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9665-diff.html (comprehensive diff) >> https://www.rfc-editor.org/authors/rfc9665-auth48diff.html (AUTH48 changes >> only) >> >> Note that it may be necessary for you to refresh your browser to view the >> most recent version. >> >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfc9665 >> >> Thank you, >> RFC Editor/st >> >>> On Apr 18, 2025, at 4:31 PM, Ted Lemon <mel...@fugue.com> wrote: >>> >>> On 17 Apr 2025, at 14:26, Sarah Tarrant <starr...@staff.rfc-editor.org> >>> wrote: >>>> Stuart and Ted - We have a few followup questions/comments: >>>> >>>> A) Regarding: >>>>> XML comment from Ted: >>>>> Adding a dependent clause here obscures the meaning of the second half of >>>>> the compound sentence. >>>> >>>> Current: >>>> DNS-SD [RFC6763] also allows clients to discover services using the >>>> DNS protocol over traditional unicast [RFC1035]. >>>> >>>> Would the following make the dependent clause relationship more clear? If >>>> not, feel free to provide your preferred text. >>>> >>>> Perhaps: >>>> DNS-SD [RFC6763] also allows clients to discover services by using the >>>> DNS protocol over traditional unicast [RFC1035]. >>> >>> Yes, this is a good clarification. >>> >>>> B) Regarding: >>>>> XML comment from Ted: >>>>> I don't think e.g. should have a comma after it. I changed it to "for >>>>> example" to illustrate why I think this, but my Latin is rusty, so maybe >>>>> it does make sense when the abbreviation is used? Ah, I see why I'm >>>>> confused. In most of the cases where e.g. or for example is being used, >>>>> it's being used like this: If we use foo, for example, then BAR. But here >>>>> debugging isn't the example, so the extra comma changes the meaning. >>>> >>>> Ted's text: >>>> This is optional because >>>> the reverse mapping PTR record serves no essential protocol function, >>>> but it may be useful for debugging, for example in annotating network >>>> packet traces or logs. >>>> >>>> We understand that commas may seem to break up thoughts, but thankfully >>>> this is not the case for "e.g.", "i.e.", or "for example". It is >>>> house-style for there to be a comma before and after these elements, so it >>>> does not break the sentence. We have examples of this in the style guide >>>> (https://www.rfc-editor.org/info/rfc7322) as well as the Web Portion of >>>> the Style Guide (https://www.rfc-editor.org/styleguide/part2/). Please let >>>> us know if you would like to revert back to "e.g.". >>>> >>>> Current: >>>> This is optional because >>>> the reverse mapping PTR record serves no essential protocol function, >>>> but it may be useful for debugging, for example, in annotating network >>>> packet traces or logs. >>> >>> I really don't love this sentence either way. We're trying to say too much. >>> How about: >>> >>> This is optional: the reverse mapping PTR record serves no essential >>> protocol function. One reason to provide reverse mappings is that they can >>> be used to annotate logs and network packet traces. >>> >>>> >>>> >>>> C) Regarding: >>>>>> 15) <!-- [rfced] We had some questions regarding capitalization of >>>>>> certain terms: >>>>>> >>>>>> b) We see the following similar terms. Please review and let us know >>>>>> if/how to make these terms consistent. >>>>>> >>>>>> service instance name >>>>>> Service Instance Name >>>>>> "Service Instance Name" >>>>> [Ted] The above are all the same thing >>>> >>>> May we update to "service instance" for all, then? >>> >>> No. Where you see "service instance" and not "service instance name" we are >>> talking about the thing the name refers to: these are two separate things. >>> It's fine to use all lowercase though, if that's what you were asking. >>> >>>> D) Regarding: >>>>> f) Regarding the terms "Service Description", Service Discovery, and >>>>> "Host Description". >>>>> >>>>> - We see both Instruction and instruction when following these terms. >>>>> If/How may we make this uniform? >>>>> >>>>> - Should “instruction” or the like should be inserted after instances >>>>> of these terms? Sometimes they are followed by "record" or "update", >>>>> if they appear without a label, might this be confusing to the reader? >>>>> >>>>> Example: >>>>> The KEY record in Service Description updates MAY be omitted for >>>>> brevity; if it is omitted, the SRP registrar MUST behave as if the >>>>> same KEY record that is given for the Host Description is also given >>>>> for each Service Description for which no KEY record is provided. >>>> >>>> Please let us know if we need to make any changes regarding this question. >>>> It appears that this may no have been addressed. >>> >>> The service description is the data structure. The service description >>> instruction is the collection of updates that, when applied together, >>> creates the intended service description. A service description update is >>> an individual update in a service description instruction. Please do not >>> make any changes to the way we have written this. >>> >>>> E) Regarding the IANA section: >>>> >>>> The text refers to IESG Approval but also points to RFC 8126 to define >>>> "specification exists". Do we need to reference 8126 again here because >>>> it's quoted text? >>>> >>>> The following appears in Section 10.3: >>>> The IETF has change control for this >>>> registry. New entries may be added either as a result of Standards >>>> Action or with IESG Approval, provided that a specification exists >>>> [RFC8126]. >>>> >>>> It is unclear whether "specification exists [RFC8126]" means: >>>> >>>> a) a combination of IESG Approval and Specification Required >>>> >>>> b) IESG Approval, provided that a document exists >>>> >>>> Does the text refer to the definition of "Specification Required" to >>>> indicate what satisfies "specification", as opposed to defining the >>>> Specification Required policy overall (which also requires expert review)? >>> >>> The intention is that an entry in the registry can be created either >>> through standards action (that is, a standards-track RFC being published). >>> Or, a document exists and the IESG approves adding the entry (e.g. an ISE >>> document , an informational IETF document, or an external SDO's document). >>> I realize that Standards Action subsumes "document exists + IESG approval" >>> and so this is a bit confusing. What we specifically mean here is >>> "Specification Required AND IESG approval" as described in sections 4.6 and >>> 4.10 of RFC8126. >>> >>>> >>>> If this is the case, may we use the relevant text from RFC 8126. For >>>> example: >>>> >>>> New entries may be added either as a result of >>>> Standards Action (Section 4.9 of [RFC8126]) or with IESG Approval >>>> (Section 4.10 of [RFC8126]), provided that the values and >>>> their meanings are documented in a permanent and readily >>>> available public specification, in sufficient detail so that >>>> interoperability between independent implementations is possible. >>> >>> This text accurately conveys our intention, so it's fine to use it. >>> >>> Thanks for your continued patience and effort on this. Hopefully we are >>> nearly there. :) >>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
