Authors, This is a friendly reminder that we await answers to the questions below and your review of the document before continuing with the publication process.
Thank you, RFC Editor/st > On Apr 29, 2025, at 4:02 PM, Sarah Tarrant <starr...@staff.rfc-editor.org> > wrote: > > 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 <mel...@fugue.com> 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 <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
