Hi Ted, Thanks for your reply. We will wait to hear from you before continuing with the publication process.
Sincerely, RFC Editor/st > On Apr 28, 2025, at 3:10 PM, Ted Lemon <[email protected]> wrote: > > 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> wrote: >>>> >>>> On 17 Apr 2025, at 14:26, Sarah Tarrant <[email protected]> >>>> 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 -- [email protected] To unsubscribe send an email to [email protected]
