Should we / can we still clarify what a client needs to do to remove all published services?

[EskoDijk]

Based on the email thread: https://mailarchive.ietf.org/arch/msg/dnssd/_JY8BWMpkALfJz-V4sjlgajKskQ/

And draft text:

To remove all the services registered to a particular host, the SRP requestor retransmits its most recent update with an Update Lease option that has a LEASE value of zero.

there was some unclarity because a client actually doesn't need to repeat its latest registration as a way to remove all published services, It could just not include any services at all, which is far more efficient than sending the services again included in the message just to remove them.

Can we still apply some clarification here, or would an erratum remark later on be better?

[Abhayakara]

It’s a bit late for a change like this. The only reason the document hasn’t been published is that right after the IESG review I had two deaths in the family and haven’t caught up from the backlog that produced yet. That would not be a legitimate erratum because it defines new behavior. In order to fix this we need to write a new document. Which we may indeed want to do. Op zo 5 nov 2023 om 18:56 schreef Esko Dijk ***@***.***>

…

Based on the email thread: https://mailarchive.ietf.org/arch/msg/dnssd/_JY8BWMpkALfJz-V4sjlgajKskQ/ And draft text: To remove all the services registered to a particular host, the SRP requestor retransmits its most recent update with an Update Lease option that has a LEASE value of zero. there was some unclarity because a client actually doesn't need to repeat its latest registration as a way to remove all published services, It could just not include any services at all, which is far more efficient than sending the services again included in the message just to remove them. Can we still apply some clarification here, or would an erratum remark later on be better? — Reply to this email directly, view it on GitHub <#23>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5USALTAYINIIEKSUFLB53YC7HOLAVCNFSM6AAAAAA66PVA7OVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE3TOOBZGQZTGMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Abhayakara]

The srp update is fairly heavy at this point, so I think it's okay to include a clarification for this after all. I've changed the text as follows: To remove all the services registered to a particular host, the SRP requestor transmits an SRP update for that host update with an Update Lease option that has a LEASE value of zero. This is actually corroborated by the third paragraph in the section, so we aren't changing the specified behavior, just removing some text that's arguably simply wrong.

…

On Sun, Nov 5, 2023 at 1:08 PM Ted Lemon ***@***.***> wrote: It’s a bit late for a change like this. The only reason the document hasn’t been published is that right after the IESG review I had two deaths in the family and haven’t caught up from the backlog that produced yet. That would not be a legitimate erratum because it defines new behavior. In order to fix this we need to write a new document. Which we may indeed want to do. Op zo 5 nov 2023 om 18:56 schreef Esko Dijk ***@***.***> > Based on the email thread: > https://mailarchive.ietf.org/arch/msg/dnssd/_JY8BWMpkALfJz-V4sjlgajKskQ/ > > And draft text: > > To remove all the services registered to a particular host, the SRP > requestor retransmits its most recent update with an Update Lease option > that has a LEASE value of zero. > > there was some unclarity because a client actually doesn't need to repeat > its latest registration as a way to remove all published services, It could > just not include any services at all, which is far more efficient than > sending the services again included in the message just to remove them. > > Can we still apply some clarification here, or would an erratum remark > later on be better? > > — > Reply to this email directly, view it on GitHub > <#23>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AA5USALTAYINIIEKSUFLB53YC7HOLAVCNFSM6AAAAAA66PVA7OVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE3TOOBZGQZTGMI> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >