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]
