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
