Dear Sarah, dear RFC Editor, Just checking whether the authors, the AD (or the IANA) have still some pending actions before the publication of these two RFCs ?
Regards -éric On 09/04/2025, 06:28, "Stuart Cheshire" <chesh...@apple.com> wrote: On Apr 8, 2025, at 13:42, Sarah Tarrant <starr...@staff.rfc-editor.org<mailto:starr...@staff.rfc-editor.org>> wrote: > Hi Stuart, > > Wonderful to hear! We will await news that you all have completed all the > updates, and then we will continue our side of the publication project. > > Additionally, if you edited the xml files, it would greatly speed up the > project on our end if you could send us your edited xml files for both > documents. > > Please note that as I am attending the RPC Retreat in San Jose this week, my > responses may be more delayed than usual. > > Sincerely, > RFC Editor/st After conferring with Ted, I made my final edits today, adding the trailing dot on all fully qualified domain names. Both updated XML files are attached. I made most of the edits you suggested, and for the changes I did not make, answers to your questions are inline below. > B) We suggest adding "should" to the first sentence ("should try again") and > updating the last sentence as follows for clarity: > > Current: > Names rejected due to > this should return a Refused RCODE, indicating to the SRP > requester that it should not append or increment a number at the > end of the name and try again in an infinite loop. If a name is > considered unacceptable because it is obscene or offensive, adding > a number on the end is unlikely to make the name become > acceptable. > > Perhaps: > Names rejected due to > this should return a Refused RCODE, indicating to the SRP > requester that it should not append or increment a number at the > end of the name and should try again in an infinite loop. If a name is > considered unacceptable because it is obscene or offensive, adding > a number on the end is unlikely to make the name acceptable. Actually, this would be the opposite of what we mean. What we mean to say is that, “it SHOULD NOT append or increment a number at the end of the name and try again in an infinite loop.” I changed the text to this: it should not append or increment a number at the end of the name and then try again, since this would be likely to result in an infinite loop. > C) We noticed this update was not included in the new version. Do you > disagree with this update? If so, please consider how this list can be > clarified. > > 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. > --> Ted’s comment in the XML: The working group worked very hard on the text and the organization and structure of the bullets here, and this change completely goes against that consensus, so I am reverting it. I don't mean to suggest that there was no point to this change, but it was really hard to get agreement on this precise way of formatting the text, and I do not want to repeat that process. I actually tried to replicate some of your changes, and wasn't sure if I was changing the meaning of the text, so I've only retained your capitalization changes. Please think of this text as more like computer code than human language, if that helps. > D) In Section 5.1, "'n'" was updated to "M". Please confirm that this is > correct. Ted’s comment in the XML: These are actually two different quantities, but I agree with the correction generally, so have used M for the last paragraph. > E) "default.service.arpa” appears with and without a period after "arpa". > Please review and let us know if these should be consistent. We note that > IANA has registered this as follows (see > https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml#service-arpa-subdomain): > default.service.arpa. Default domain for SRP updates [RFC-ietf-dnssd-srp-25] > > "default.service.arpa" > "service.arpa." > "default.service.arpa.” I have corrected all to end with a final dot, as required by the formal DNS convention. I hope we are really finished with this. The documents have been carefully proofread and reviewed. Of course, we do value your input (others will confirm that I am sincere in saying this -- I often praise the role of the RFC Editor’s office in producing IETF documents that are consistently higher quality than other standards bodies). If you do see any changes necessary to correct punctuation, typos, and other small things we will happily review those, but I do hope we can see light at the end of the tunnel now. Stuart Cheshire +1 (408) 666-2262
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
