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
