Hi Stuart and *Éric,
Thank you for the updated files! We are still working through the updates and
will post the files for review either later today or early tomorrow.
*Éric - In the meantime, we would appreciate confirmation that you approve the
updates.
Thank you,
RFC Editor/st
> On Apr 15, 2025, at 3:56 AM, Eric Vyncke (evyncke) <evyn...@cisco.com> wrote:
>
> 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> 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
> (seehttps://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
