Sarah, I have reviewed the extensive updates, and they are all good making the text clearer. Therefore, I approve this version.
Regards and thanks to all for the work done -éric From: Sarah Tarrant <starr...@staff.rfc-editor.org> Date: Thursday, 17 April 2025 at 23:27 To: Ted Lemon <mel...@fugue.com>, Stuart Cheshire <chesh...@apple.com>, Eric Vyncke (evyncke) <evyn...@cisco.com> Cc: dnssd-...@ietf.org <dnssd-...@ietf.org>, dnssd-cha...@ietf.org <dnssd-cha...@ietf.org>, David Schinazi <dschinazi.i...@gmail.com>, auth48archive <auth48archive@rfc-editor.org>, RFC Editor <rfc-edi...@rfc-editor.org> Subject: Re: [AD] AUTH48: RFC-to-be 9665 <draft-ietf-dnssd-srp-25> for your review Hi Stuart, Ted, and *Éric, *Éric - Please review the diffs, particularly the added text, and let us know if all updates are approved. We recommend the -auth48diff.html as it highlights the updates that occurred since the first files posted for AUTH48. 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]. 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. 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? 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. 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)? 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. Please let us know how we may update. 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 Dec 4, 2024, at 10:11 AM, Sarah Tarrant <starr...@amsl.com> wrote: > > Authors and AD, > > Please see mail below regarding this document as well as our cluster-wide > email with questions relating to all three related documents. > > This document set has been in AUTH48 since mid-September. Please let us know > if there is anything we can do to facilitate moving the AUTH48 review forward. > > Sincerely, > RFC Editor/st > >> On Nov 22, 2024, at 2:11 PM, Sarah Tarrant <starr...@amsl.com> wrote: >> >> Hi all, >> >> This is a friendly weekly reminder that we await answers to the questions >> below and your review of the document before continuing with the publication >> process. >> >> Please let us know if we can be of further assistance as you complete your >> review. >> >> Thank you, >> RFC Editor/st >> >>> On Nov 14, 2024, at 2:26 PM, Sarah Tarrant <starr...@amsl.com> wrote: >>> >>> Hi all, >>> >>> This is a friendly weekly reminder that we await answers to the questions >>> below and your review of the document before continuing with the >>> publication process. >>> >>> Please let us know if we can be of further assistance as you complete your >>> review. >>> >>> Thank you, >>> RFC Editor/st >>> >>>> On Nov 4, 2024, at 11:37 AM, Sarah Tarrant <starr...@amsl.com> wrote: >>>> >>>> Hi all, >>>> >>>> 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 Oct 7, 2024, at 12:39 PM, Sarah Tarrant <starr...@amsl.com> wrote: >>>>> >>>>> 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 Sep 30, 2024, at 10:56 PM, rfc-edi...@rfc-editor.org wrote: >>>>>> >>>>>> Authors, >>>>>> >>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>> necessary) the following questions, which are also in the XML file. >>>>>> >>>>>> 1) <!--[rfced] Should "services" be "servers" here to match previous, >>>>>> similar text? And perhaps avoiding the two "provide" uses so >>>>>> close together would be helpful for the reader? >>>>>> >>>>>> >>>>>> Original: >>>>>> DNS-Based Service Discovery (DNS-SD) allows services to advertise >>>>>> the fact that they provide service, and to provide the >>>>>> information required to access that service. >>>>>> >>>>>> Perhaps: >>>>>> DNS-SD allows servers to advertise the fact that they provide >>>>>> service and to share the information required to access that >>>>>> service. >>>>>> >>>>>> --> >>>>>> >>>>>> >>>>>> 2) <!--[rfced] To what does "that" refer in this sentence? >>>>>> >>>>>> Original: >>>>>> As long as the registration service remembers the name and the key >>>>>> used to register that name, no other server can add or update the >>>>>> information associated with that. >>>>>> >>>>>> Perhaps: >>>>>> As long as the registration service remembers the name and the key >>>>>> used to register that name, no other server can add or update the >>>>>> information associated with them. >>>>>> >>>>>> Perhaps: >>>>>> As long as the registration service remembers the name and the key >>>>>> used to register that name, no other server can add or update the >>>>>> information associated with that pair. >>>>>> >>>>>> --> >>>>>> >>>>>> >>>>>> 3) <!--[rfced] How might we clarify "this" for the ease of the reader >>>>>> (especially as this sentence is the first of the paragraph)? >>>>>> >>>>>> Original: >>>>>> Note that this does not update [RFC2782]: DNS servers still MUST >>>>>> NOT compress SRV record targets. >>>>>> --> >>>>>> >>>>>> >>>>>> 4) <!-- [rfced] FYI - we updated the list as follows for clarity. Please >>>>>> let us know if there are any objections. >>>>>> >>>>>> Original: >>>>>> An instruction is a Service Discovery Instruction if it contains >>>>>> >>>>>> * exactly one "Add to an RRSet" ([RFC2136], Section 2.5.1) or >>>>>> exactly one "Delete an RR from an RRSet" ([RFC2136], >>>>>> Section 2.5.4) RR update, >>>>>> * which updates a PTR RR, >>>>>> * the target of which is a Service Instance Name >>>>>> * for which name a Service Description Instruction is present in the >>>>>> SRP Update, and: >>>>>> - if the RR Update is an "Add to an RRSet" instruction, that >>>>>> Service Description Instruction contains an "Add to an RRset" >>>>>> RR update for the SRV RR describing that service and no other >>>>>> "Delete from an RRset" instructions for that Service Instance >>>>>> Name; or >>>>>> - if the RR Update is a "Delete an RR from an RRSet" instruction, >>>>>> that Service Description Instruction contains a "Delete from an >>>>>> RRset" RR update and no other "Add to an RRset" instructions >>>>>> for that Service Instance Name. >>>>>> * and contains no other add or delete RR updates for the same name >>>>>> as the PTR RR Update. >>>>>> >>>>>> Current: >>>>>> An instruction is a Service Discovery Instruction if it: >>>>>> >>>>>> * Contains exactly one "Add to an RRSet" (Section 2.5.1 of >>>>>> [RFC2136]) or exactly one "Delete an RR from an RRSet" >>>>>> (Section 2.5.4 of [RFC2136]) RR update, which updates a PTR RR; >>>>>> the target of which is a Service Instance Name for which name a >>>>>> Service Description Instruction is present in the SRP Update. >>>>>> Additionally: >>>>>> >>>>>> - If the RR Update is an "Add to an RRSet" instruction, that >>>>>> Service Description Instruction contains an "Add to an RRset" >>>>>> RR update for the SRV RR describing that service and no other >>>>>> "Delete from an RRset" instructions for that Service Instance >>>>>> Name. >>>>>> - If the RR Update is a "Delete an RR from an RRSet" instruction, >>>>>> that Service Description Instruction contains a "Delete from an >>>>>> RRset" RR update and no other "Add to an RRset" instructions >>>>>> for that Service Instance Name. >>>>>> >>>>>> * Contains no other add or delete RR updates for the same name as >>>>>> the PTR RR Update. >>>>>> --> >>>>>> >>>>>> >>>>>> 5) <!--[rfced] For the ease of the reader, might we clarify what "these >>>>>> conditions" are? >>>>>> >>>>>> Original: >>>>>> Assuming that a DNS Update message has been validated with these >>>>>> conditions and is a valid SRP Update, the SRP registrar checks that >>>>>> the name in the Host Description Instruction exists. >>>>>> >>>>>> Perhaps: >>>>>> Assuming that a DNS Update message has been validated with an FCFS name >>>>>> and signature and is a valid SRP Update, the SRP registrar checks that >>>>>> the name in the Host Description Instruction exists. >>>>>> --> >>>>>> >>>>>> >>>>>> 6) <!--[rfced] Please review this transition sentence. Because it is >>>>>> placed at the beginning of a new paragraph, the "Otherwise" might >>>>>> be a bit jarring to the reader. (Our suggestion is likely weak, >>>>>> but for demonstrative purposes...) >>>>>> >>>>>> Original: >>>>>> Otherwise, the SRP registrar validates the SRP Update using SIG(0) >>>>>> against the public key in the KEY record of the Host Description >>>>>> Instruction. >>>>>> >>>>>> Perhaps: >>>>>> If the above steps are not taken, the SRP registrar validates the >>>>>> SRP Update using SIG(0) against the public key in the KEY record of >>>>>> the Host Description Instruction. >>>>>> --> >>>>>> >>>>>> >>>>>> 7) <!-- [rfced] In Section 5.1, we see both "N" and "'n'". Please review >>>>>> and let us know if/how we may update for uniformity. >>>>>> >>>>>> Original "N": >>>>>> SRP requestors SHOULD assume that each lease ends N seconds after the >>>>>> update was first transmitted, where N is the lease duration. >>>>>> >>>>>> Original "'n'": >>>>>> The lease time is never sent as a TTL; its >>>>>> sole purpose is to determine when the authoritative DNS server will >>>>>> delete stale records. It is not an error to send a DNS response with >>>>>> a TTL of 'n' when the remaining time on the lease is less than 'n'. >>>>>> --> >>>>>> >>>>>> >>>>>> 8) <!-- [rfced] In the following text, before the two numbered points, >>>>>> the text reads "There are three considerations". Should we update >>>>>> "three" to "two", or is there another point that the text is >>>>>> missing? >>>>>> >>>>>> Current: >>>>>> There are three considerations for caching DNS servers that follow >>>>>> this specification: >>>>>> >>>>>> 1. For correctness, recursive resolvers at sites using >>>>>> 'service.arpa.' must, in practice, transparently support DNSSEC >>>>>> queries: queries for DNSSEC records and queries with the DNSSEC >>>>>> OK (DO) bit set (Section 3.2.1 of [RFC4035]). DNSSEC validation >>>>>> is a Best Current Practice ([RFC9364]): although validation is not >>>>>> required, a caching recursive resolver that does not validate >>>>>> answers that can be validated may cache invalid data. In turn, >>>>>> this would prevent validating stub resolvers from successfully >>>>>> validating answers. Hence, as a practical matter, recursive >>>>>> resolvers at sites using 'service.arpa' should do DNSSEC >>>>>> validation. >>>>>> >>>>>> 2. Unless configured otherwise, recursive resolvers and DNS proxies >>>>>> MUST behave as described in Locally Served Zones (Section 3 of >>>>>> [RFC6303]). That is, queries for 'service.arpa.' and subdomains >>>>>> of 'service.arpa.' MUST NOT be forwarded, with one important >>>>>> exception: a query for a DS record with the DO bit set MUST >>>>>> return the correct answer for that question, including correct >>>>>> information in the authority section that proves that the record >>>>>> is nonexistent. >>>>>> >>>>>> So, for example, a query for the NS record for 'service.arpa.' >>>>>> MUST NOT result in that query being forwarded to an upstream >>>>>> cache nor to the authoritative DNS server for '.arpa.'. However, >>>>>> as necessary to provide accurate authority information, a query >>>>>> for the DS record MUST result in forwarding whatever queries are >>>>>> necessary. Typically, this will just be a query for the DS >>>>>> record since the necessary authority information will be included >>>>>> in the authority section of the response if the DO bit is set. >>>>>> --> >>>>>> >>>>>> >>>>>> 9) <!--[rfced] Is this text redundant (with two uses of necessary)? >>>>>> Does our suggestion change your intended meaning? >>>>>> >>>>>> Original: >>>>>> However, as necessary to provide accurate authority information, a >>>>>> query for the DS record MUST result in forwarding whatever queries are >>>>>> necessary; typically, ... >>>>>> >>>>>> >>>>>> Perhaps: >>>>>> However, to provide accurate authority information, a >>>>>> query for the DS record MUST result in forwarding whatever queries are >>>>>> necessary. >>>>>> --> >>>>>> >>>>>> >>>>>> 10) <!--[rfced] We are having trouble parsing this sentence. Is there >>>>>> text >>>>>> missing? >>>>>> >>>>>> Original: >>>>>> The operator for the DNS servers authoritative for 'service.arpa.' in >>>>>> the global DNS will configure any such servers as described in Section >>>>>> 9. >>>>>> >>>>>> Perhaps: >>>>>> The operator for the DNS servers that are authoritative for >>>>>> "service.arpa." in the global DNS will configure any such servers as >>>>>> described in Section >>>>>> 9. >>>>>> >>>>>> --> >>>>>> >>>>>> >>>>>> 11) <!--[rfced] We have some questions about Section 10.1 in the IANA >>>>>> Considerations: >>>>>> >>>>>> a) We see the title of the section is related to the first paragraph >>>>>> only. May we move the second paragraph to its own subsection? If so, >>>>>> please let us know how you would like the text to appear using >>>>>> Old/New. >>>>>> >>>>>> Original: >>>>>> >>>>>> 10.1. Registration and Delegation of 'service.arpa' as a Special-Use >>>>>> Domain Name >>>>>> >>>>>> IANA is requested to record the domain name 'service.arpa.' in the >>>>>> Special-Use Domain Names registry [SUDN]. IANA is requested, with >>>>>> the approval of IAB, to implement the delegation requested in >>>>>> Section 9. >>>>>> >>>>>> IANA is further requested to add a new entry to the "Transport- >>>>>> Independent Locally-Served Zones" subregistry of the "Locally-Served >>>>>> DNS Zones" registry [LSDZ]. The entry will be for the domain >>>>>> 'service.arpa.' with the description "DNS-SD Service Registration >>>>>> Protocol Special-Use Domain", and listing this document as the >>>>>> reference. >>>>>> >>>>>> b) The first paragraph of Section 10.1 mentions Section 9, which >>>>>> states: >>>>>> >>>>>> Original: >>>>>> 9. Delegation of 'service.arpa.' >>>>>> >>>>>> In order to be fully functional, the owner of the 'arpa.' zone must >>>>>> add a delegation of 'service.arpa.' in the '.arpa.' zone [RFC3172]. >>>>>> This delegation is to be set up as was done for 'home.arpa', as a >>>>>> result of the specification in Section 7 of [RFC8375]. This is >>>>>> currently the responsibility of the IAB [IAB-ARPA] >>>>>> >>>>>> Should Section 9 be updated as follows since this action has been >>>>>> taken? Also, please review whether this information actually belongs >>>>>> in the IANA section. If so, please let us know (using old/new) how to >>>>>> update. >>>>>> >>>>>> 9. Delegation of "service.arpa." >>>>>> >>>>>> The owner of the 'arpa.' zone, at the time of writing the IAB [IAB-ARPA], >>>>>> has added a delegation of 'service.arpa.' in the '.arpa.' zone >>>>>> [RFC3172], following the guidance provided in Section 7 of [RFC8375]. >>>>>> >>>>>> >>>>>> --> >>>>>> >>>>>> >>>>>> 12) <!-- [rfced] Normative reference RFC 3445 has been obsoleted by >>>>>> RFC 4033. We will update to the latter unless we hear objection. >>>>>> --> >>>>>> >>>>>> >>>>>> 13) <!--[rfced] Might this be an agreeable update to the title of >>>>>> Appendix A (to avoid double -ing words in the beginning?)? >>>>>> >>>>>> Original: >>>>>> >>>>>> Appendix A. Testing Using Standard DNS Servers Compliant with RFC >>>>>> 2136 >>>>>> >>>>>> Perhaps: >>>>>> >>>>>> Appendix A. Testing the Use of Standard DNS Servers Compliant with RFC >>>>>> 2136 >>>>>> >>>>>> Perhaps: >>>>>> >>>>>> Appendix A. Testing Standard DNS Servers Compliant with RFC 2136 >>>>>> --> >>>>>> >>>>>> >>>>>> 14) <!-- [rfced] We had some questions about abbreviations: >>>>>> >>>>>> a) Should "DNSSD" (in "non-DNSSD services" and "DNSSD discovery zone") >>>>>> be updated to "DNS-SD" (hyphen) or "dnssd" (lowercase) to match prior >>>>>> usage in the document? >>>>>> >>>>>> >>>>>> b) Is the "Service" (or "Service Description") redundant here and in >>>>>> similar cases throughout the document (as SD = Service Discovery)? >>>>>> That is, just examples below, more cases exist. >>>>>> >>>>>> Original: >>>>>> DNS-SD Service registration uses public keys and SIG(0) to allow >>>>>> services to defend their registrations. >>>>>> >>>>>> Original: >>>>>> Although in principle DNS-SD Service Description records can >>>>>> include other record types with the same Service Instance Name, in >>>>>> practice they rarely do. >>>>>> >>>>>> c) For "TSIG", would you like us to expand to "transaction signature" >>>>>> upon first usage to match RFC 8945? >>>>>> >>>>>> Original: >>>>>> The format of the KEY resource record in the SRP Update is defined in >>>>>> [RFC3445]. Because the KEY RR used in TSIG is not a zone-signing >>>>>> key, the flags field in the KEY RR MUST be all zeroes. >>>>>> >>>>>> d) Throughout the document, "SRP update" is used, and there is only >>>>>> one instance of "SRV update". We wanted to make sure that "SRV" was >>>>>> indeed intended and not "SRP". >>>>>> >>>>>> Original: >>>>>> * If there is one "Add to an RRset" SRV update, there MUST be at >>>>>> least one "Add to an RRset" TXT update. >>>>>> >>>>>> e) We have updated to use the abbreviation CNN for Constrained-Node >>>>>> Network (to match its use in RFC 7228). Please review and let us know >>>>>> any objections. Further, please review uses of "constrained network" >>>>>> and let us know if any of these should be updated to CNN as well. >>>>>> --> >>>>>> >>>>>> >>>>>> 15) <!-- [rfced] We had some questions regarding capitalization of >>>>>> certain terms: >>>>>> >>>>>> a) We see instances of "Anycast" (capitalized) and "anycast" >>>>>> (lowercase) throughout the document, but we are unsure if certain >>>>>> instances are part of proper names while other instances are more >>>>>> generic. Please let us know if these need to be made more consistent >>>>>> or if they are accurate as they currently are. We've listed a few >>>>>> instances below. >>>>>> >>>>>> Anycast vs. anycast: >>>>>> IPv6 Anycast address >>>>>> Port Control Protocol anycast address >>>>>> fixed anycast address >>>>>> anycast address >>>>>> >>>>>> >>>>>> 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" >>>>>> service instance >>>>>> Service Name >>>>>> >>>>>> c) We see the following similar terms. Please let us know how to >>>>>> update for consistency. >>>>>> >>>>>> >>>>>> BIND 9 vs. BIND9 >>>>>> >>>>>> d) We have updated the quoted terms that correspond to Sections 2.5.1 >>>>>> - 2.5.4 of RFC 2136 to appear consistently in double quotes and with >>>>>> capitalization that matches those section titles. Please let us know >>>>>> any objections. >>>>>> >>>>>> We further wondered if the following update should be made: >>>>>> >>>>>> Original: >>>>>> The target of the SRV RR Add... >>>>>> >>>>>> Perhaps: >>>>>> The "Add To An RRset" SRV update >>>>>> >>>>>> Please review other terms similar to these titles if they exist and >>>>>> let us know if any further changes should be made. >>>>>> >>>>>> e) The NoError status names are in all caps in Section 2.2 of RFC >>>>>> 2136. Should the following updates be made to match? >>>>>> >>>>>> ServFail to SERVFAIL >>>>>> Refused to REFUSED >>>>>> YXDomain to YXDOMAIN >>>>>> >>>>>> 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. >>>>>> >>>>>> g) Please review the following similar terms and let us know if/how >>>>>> they should be made uniform with regard to quotes and ending with a >>>>>> period (note that this term would have IANA implications): >>>>>> >>>>>> "default.service.arpa" >>>>>> "default.service.arpa." >>>>>> host.default.service.arpa >>>>>> host-1.default.service.arpa >>>>>> host-2.default.service.arpa >>>>>> host-31773.default.service.arpa. (at end of sentence) >>>>>> ".service.arpa." >>>>>> "service.arpa" >>>>>> "service.arpa." >>>>>> >>>>>> Further note that we have updated from single to double quotes around >>>>>> terms that were quoted in the original consistently. Please review >>>>>> and let us know if further updates are necessary. >>>>>> >>>>>> h) Please review the following for the use of quotes and consistent >>>>>> use of SRV record. Please let us know if/how to update. >>>>>> >>>>>> "_dnssd-srp._tcp.<zone>" SRV record vs. _dnssd-srp._tcp.<zone> SRV >>>>>> "_dnssd-srp-tls._tcp.<zone>" SRV record vs. _dnssd-srp-tls._tcp.<zone> >>>>>> record >>>>>> _dns-update._udp SRV >>>>>> >>>>>> --> >>>>>> >>>>>> >>>>>> 16) <!-- [rfced] Please review each artwork element in Appendix C in case >>>>>> they should be tagged as sourcecode or another element. >>>>>> --> >>>>>> >>>>>> >>>>>> 17) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>>>> online Style Guide >>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>>>>> and let us know if any changes are needed. >>>>>> >>>>>> Note that our script did not flag any words in particular, but this >>>>>> should still be reviewed as a best practice. >>>>>> --> >>>>>> >>>>>> >>>>>> Thank you. >>>>>> >>>>>> RFC Editor/st/mf >>>>>> >>>>>> *****IMPORTANT***** >>>>>> >>>>>> Updated 2024/09/30 >>>>>> >>>>>> RFC Author(s): >>>>>> -------------- >>>>>> >>>>>> Instructions for Completing AUTH48 >>>>>> >>>>>> Your document has now entered AUTH48. Once it has been reviewed and >>>>>> approved by you and all coauthors, it will be published as an RFC. >>>>>> If an author is no longer available, there are several remedies >>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>>>>> >>>>>> You and you coauthors are responsible for engaging other parties >>>>>> (e.g., Contributors or Working Group) as necessary before providing >>>>>> your approval. >>>>>> >>>>>> Planning your review >>>>>> --------------------- >>>>>> >>>>>> Please review the following aspects of your document: >>>>>> >>>>>> * RFC Editor questions >>>>>> >>>>>> Please review and resolve any questions raised by the RFC Editor >>>>>> that have been included in the XML file as comments marked as >>>>>> follows: >>>>>> >>>>>> <!-- [rfced] ... --> >>>>>> >>>>>> These questions will also be sent in a subsequent email. >>>>>> >>>>>> * Changes submitted by coauthors >>>>>> >>>>>> Please ensure that you review any changes submitted by your >>>>>> coauthors. We assume that if you do not speak up that you >>>>>> agree to changes submitted by your coauthors. >>>>>> >>>>>> * Content >>>>>> >>>>>> Please review the full content of the document, as this cannot >>>>>> change once the RFC is published. Please pay particular attention to: >>>>>> - IANA considerations updates (if applicable) >>>>>> - contact information >>>>>> - references >>>>>> >>>>>> * Copyright notices and legends >>>>>> >>>>>> Please review the copyright notice and legends as defined in >>>>>> RFC 5378 and the Trust Legal Provisions >>>>>> (TLP – https://trustee.ietf.org/license-info/). >>>>>> >>>>>> * Semantic markup >>>>>> >>>>>> Please review the markup in the XML file to ensure that elements of >>>>>> content are correctly tagged. For example, ensure that <sourcecode> >>>>>> and <artwork> are set correctly. See details at >>>>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>>>> >>>>>> * Formatted output >>>>>> >>>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>>> formatted output, as generated from the markup in the XML file, is >>>>>> reasonable. Please note that the TXT will have formatting >>>>>> limitations compared to the PDF and HTML. >>>>>> >>>>>> >>>>>> Submitting changes >>>>>> ------------------ >>>>>> >>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>>>>> the parties CCed on this message need to see your changes. The parties >>>>>> include: >>>>>> >>>>>> * your coauthors >>>>>> >>>>>> * rfc-edi...@rfc-editor.org (the RPC team) >>>>>> >>>>>> * other document participants, depending on the stream (e.g., >>>>>> IETF Stream participants are your working group chairs, the >>>>>> responsible ADs, and the document shepherd). >>>>>> >>>>>> * auth48archive@rfc-editor.org, which is a new archival mailing list >>>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>>> list: >>>>>> >>>>>> * More info: >>>>>> >>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>>>> >>>>>> * The archive itself: >>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>>> >>>>>> * Note: If only absolutely necessary, you may temporarily opt out >>>>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>>>> If needed, please add a note at the top of the message that you >>>>>> have dropped the address. When the discussion is concluded, >>>>>> auth48archive@rfc-editor.org will be re-added to the CC list and >>>>>> its addition will be noted at the top of the message. >>>>>> >>>>>> You may submit your changes in one of two ways: >>>>>> >>>>>> An update to the provided XML file >>>>>> — OR — >>>>>> An explicit list of changes in this format >>>>>> >>>>>> Section # (or indicate Global) >>>>>> >>>>>> OLD: >>>>>> old text >>>>>> >>>>>> NEW: >>>>>> new text >>>>>> >>>>>> You do not need to reply with both an updated XML file and an explicit >>>>>> list of changes, as either form is sufficient. >>>>>> >>>>>> We will ask a stream manager to review and approve any changes that seem >>>>>> beyond editorial in nature, e.g., addition of new text, deletion of text, >>>>>> and technical changes. Information about stream managers can be found in >>>>>> the FAQ. Editorial changes do not require approval from a stream >>>>>> manager. >>>>>> >>>>>> >>>>>> Approving for publication >>>>>> -------------------------- >>>>>> >>>>>> To approve your RFC for publication, please reply to this email stating >>>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>>>> as all the parties CCed on this message need to see your approval. >>>>>> >>>>>> >>>>>> Files >>>>>> ----- >>>>>> >>>>>> The files are available here: >>>>>> https://www.rfc-editor.org/authors/rfc9665.xml >>>>>> https://www.rfc-editor.org/authors/rfc9665.html >>>>>> https://www.rfc-editor.org/authors/rfc9665.pdf >>>>>> https://www.rfc-editor.org/authors/rfc9665.txt >>>>>> >>>>>> Diff file of the text: >>>>>> https://www.rfc-editor.org/authors/rfc9665-diff.html >>>>>> https://www.rfc-editor.org/authors/rfc9665-rfcdiff.html (side by side) >>>>>> >>>>>> Diff of the XML: >>>>>> https://www.rfc-editor.org/authors/rfc9665-xmldiff1.html >>>>>> >>>>>> >>>>>> Tracking progress >>>>>> ----------------- >>>>>> >>>>>> The details of the AUTH48 status of your document are here: >>>>>> https://www.rfc-editor.org/auth48/rfc9665 >>>>>> >>>>>> Please let us know if you have any questions. >>>>>> >>>>>> Thank you for your cooperation, >>>>>> >>>>>> RFC Editor >>>>>> >>>>>> -------------------------------------- >>>>>> RFC9665 (draft-ietf-dnssd-srp-25) >>>>>> >>>>>> Title : Service Registration Protocol for DNS-Based Service >>>>>> Discovery >>>>>> Author(s) : T. Lemon, S. Cheshire >>>>>> WG Chair(s) : Chris Box, David Schinazi >>>>>> Area Director(s) : Erik Kline, Éric Vyncke >>>>>> >>>>>> >>>>> >>>> >>> >> >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
