Hi Ted and Eric,
We read through your edits and have a few notes for you to consider. We limited
our comments to textual changes, as we expect to have an opportunity to update
punctuation, typos, and other small things later. There are no notes for
RFC-to-be 9664. Our notes regarding RFC-to-be 9665 are below.
A) To make this sentence more parallel, we would suggest the following update:
Current:
The SRP Update
MUST contain exactly one Host Description Instruction, containing
exactly one "Delete All RRsets From A Name" instruction for the
hostname, and no "Add to an RRSet" instructions for that hostname.
Suggested:
The SRP Update
MUST contain exactly one Host Description Instruction that contains
exactly one "Delete All RRsets From A Name" instruction for the
hostname and no "Add to an RRSet" instructions for that hostname.
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.
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.
> -->
D) In Section 5.1, "'n'" was updated to "M". Please confirm that this is
correct.
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.”
Please consider updating your draft or letting us know how to resolve the above
once the draft is re-approved.
Sincerely,
RFC Editor/st
> On Mar 5, 2025, at 2:22 AM, Ted Lemon <mel...@fugue.com> wrote:
>
> Sounds good. See you there!
>
> On Wed, Mar 5, 2025, at 7:33 AM, Eric Vyncke (evyncke) wrote:
>> Ted,
>>
>> The next steps sound logical to me. Let’s check at IETF-122 for the WG
>> consensus about the last changes, but until now: no reactions on the DNSSD
>> mailing list.
>>
>> Regards
>>
>> -éric
>>
>> From: Ted Lemon <mel...@fugue.com>
>> Date: Tuesday, 4 March 2025 at 23:13
>> To: Sandy Ginoza <sgin...@staff.rfc-editor.org>
>> Cc: Sarah Tarrant <starr...@staff.rfc-editor.org>, Stuart Cheshire
>> <chesh...@apple.com>, Eric Vyncke (evyncke) <evyn...@cisco.com>, RFC Editor
>> <rfc-edi...@rfc-editor.org>, dnssd-...@ietf.org <dnssd-...@ietf.org>,
>> dnssd-cha...@ietf.org <dnssd-cha...@ietf.org>, auth48archive@rfc-editor.org
>> <auth48archive@rfc-editor.org>, David Schinazi <dschinazi.i...@gmail.com>
>> Subject: Re: [AD] [C507] AUTH48 Questions: RFC-to-be 9665
>> <draft-ietf-dnssd-srp-25> and RFC-to-be 9664
>> <draft-ietf-dnssd-update-lease-08>
>> The versions currently published contain all our edits. We still need to
>> confirm with the working group. I suspect at this point the conversation
>> will happen at IETF in Bangkok. It would be helpful if someone on the RFC
>> editor team could look at our edits—if the WG wants any changes they will be
>> a very small tweak to what is there now.
>>
>> On Tue, Mar 4, 2025, at 9:44 PM, Sandy Ginoza wrote:
>> Greetings,
>>
>> Just checking to see if there has been any progress with RFCs-to-be 9664 and
>> 9665?
>>
>> Thanks,
>> RFC Editor/sg
>>
>>
>>
>> > On Feb 11, 2025, at 6:55 AM, Edward Lemon <mel...@fugue.com> wrote:
>> >
>> > The situation at present is that all edits are based on the RFCs-to-be,
>> > and are in github. I don't think it's technically possible to submit an
>> > RFC-to-be as an internet draft, but we expect the working group to want to
>> > review the changes. That being the case, we may back out just the RFC
>> > keyword changes in order to produce something that can be published as a
>> > -26 draft, but leave those in on github. I would suggest that top-of-tree
>> > on github would be the document for the RFC editor to work on, rather than
>> > the intermediate draft, if we follow that plan.
>> >
>> > I think we need to have a conversation with Eric and possibly the WG
>> > chairs about next steps once the edits are done.
>> >
>> >> On Feb 11, 2025, at 15:20, Sarah Tarrant <starr...@staff.rfc-editor.org>
>> >> wrote:
>> >>
>> >> Hi Stuart,
>> >>
>> >> Thank you much for the update. For our understanding, is it correct that
>> >> your edits will be in the edited copy of RFCs-to-be 9664 and 9665 (i.e.,
>> >> are the RPC edits being incorporated into GitHub as well), as opposed to
>> >> the approved draft? We ask because you mentioned possibly submitting a
>> >> new draft next week, and we are hopeful that any new draft would be based
>> >> on the the most current file possible.
>> >>
>> >> Sincerely,
>> >> RFC Editor/st
>> >>
>> >>> On Feb 7, 2025, at 4:14 PM, Stuart Cheshire <chesh...@apple.com> wrote:
>> >>>
>> >>> On Feb 5, 2025, at 15:45, Sarah Tarrant <starr...@staff.rfc-editor.org>
>> >>> wrote:
>> >>>
>> >>>> Hello Ted, Stuart, and Éric,
>> >>>>
>> >>>> We do not believe we have received the XML file from you yet. It
>> >>>> appears that the last update was on 1/20/25.
>> >>>
>> >>> Sorry Sarah. I made my final edits for draft-ietf-dnssd-update-lease
>> >>> (9664) and sent the email about it on 20th January saying that the
>> >>> document was complete and ready for Ted’s final review, but it appears
>> >>> we had an email delivery failure of some kind because Ted never received
>> >>> the email. I have just talked about this with Ted via text message, and
>> >>> I have re-sent the lost email to Ted’s apple.com email address for Ted
>> >>> to address on Monday.
>> >>>
>> >>> This week I am in Philadelphia for the Thread Group Board of Directors
>> >>> meeting. On my flight back to California this weekend I will go through
>> >>> my handwritten notes for draft-ietf-dnssd-srp (9665) and make the
>> >>> necessary GitHub edits, so that they are also ready for Ted to review on
>> >>> Monday morning. Ted mentioned that we may want to get a final working
>> >>> group review for 9665 to make sure everyone agrees with the changes. We
>> >>> will talk with Éric Vyncke and get his advice. IETF 122 in Bangkok is
>> >>> just five weeks away now, so one possible plan could be: We make the
>> >>> edits, submit draft-ietf-dnssd-update-lease-09 next week, give the
>> >>> working group four weeks for a final review, and then wrap it up in
>> >>> person at the Bangkok meeting.
>> >>>
>> >>> Stuart Cheshire
>> >>>
>> >>
>> >
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
