Subject: [dnssd] Fwd: New Version Notification for draft-sctl-service-registration-02.txt

From: Ted Lemon <[email-masked]>
Date: Sun, 15 Jul 2018 16:42:37 -0400

I just submitted an updated version of the service registration document.
 If you were planning to read this prior to the meeting and haven't read it
yet, you should definitely read the new version.   I think it's more
understandable than the old version, but more importantly, it's also more
correct.

This version contains significant updates from the version that Toke
reviewed last week.   Things move fast at the IETF...

---------- Forwarded message ----------
From: <[email-masked]>
Date: Sun, Jul 15, 2018 at 4:40 PM
Subject: New Version Notification for draft-sctl-service-registration-02.txt
To: Stuart Cheshire <[email-masked]>, Ted Lemon <[email-masked]>

A new version of I-D, draft-sctl-service-registration-02.txt
has been successfully submitted by Ted Lemon and posted to the
IETF repository.

Name:           draft-sctl-service-registration
Revision:       02
Title:          Service Registration Protocol for DNS-Based Service
Discovery
Document date:  2018-07-14
Group:          dnssd
Pages:          16
URL:            https://www.ietf.org/internet-drafts/draft-sctl-service-
registration-02.txt
Status:         https://datatracker.ietf.org/doc/draft-sctl-service-
registration/
Htmlized:       https://tools.ietf.org/html/draft-sctl-service-
registration-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-sctl-service-
registration
Diff:           https://www.ietf.org/rfcdiff?url2=draft-sctl-service-
registration-02

Abstract:
   The DNS-SD Service Registration Protocol uses the standard DNS Update
   mechanism to enable DNS-Based Service Discovery using only unicast
   packets.  This eliminates the dependency on Multicast DNS as the
   foundation layer, which greatly improves scalability and improves
   performance on networks where multicast service is not an optimal
   choice, particularly 802.11 (Wi-Fi) and 802.15.4 (IoT) networks.
   DNS-SD Service registration uses public keys and SIG(0) to allow
   services to defend their registrations against attack.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Tom Pusateri <[email-masked]>
Date: Sun, 15 Jul 2018 21:55:18 -0400

> On Jul 15, 2018, at 4:42 PM, Ted Lemon <[email-masked]> wrote:
> 
> I just submitted an updated version of the service registration document.   If you were planning to read this prior to the meeting and haven't read it yet, you should definitely read the new version.   I think it's more understandable than the old version, but more importantly, it's also more correct.
> 
> This version contains significant updates from the version that Toke reviewed last week.   Things move fast at the IETF...
> 

Some quick feedback on the latest version:

1. You reference mDNS but don’t define it as multicast DNS or reference RFC 6762.
2. Section 2, second paragraph, you mention registering with the default registration domain ("dr._dns-sd._udp”).

	a. You could add Section 11 to the RFC 6763 reference.
	b. You don’t specify if you should use the .local domain or another domain. If it’s another domain, how do you find that domain?
	c. Why do you recommend always using the default registration domain? Couldn’t you get the list of registration domains ("r._dns-sd._udp”) and pick one of those?

3. It’s not clear to me from the document about the TTL values. The life of the registration is handled by the Update Lease Time and the Instance Lease Time. Therefore, I think the document is saying (after talking to Stuart) that the TTL in the registration is the one the client wants the server to use in responses. But the server is keeping the registration for longer than the TTL based on the EDNS(0) Update Lease Option values.

So does the server start the TTL countdown on the first response and then subsequent responses use the decrementing TTL until it times out and then the server resets it to the TTL it received in the register on the next response? This is confusing to me even after talking to Stuart so I”m probably just missing something.

4. Section 3 (security considerations)

You limit the scope of this to within an administrative domain limiting it’s applicability but nowhere else in the document do you convey this. For most of the document, the reader may assume that registrations can be done from anywhere, may wonder why they aren’t encrypted, and then only see in the security section that this is really made for IoT devices and in the home.
I think the name of the protocol should reflect this limited scope instead of using a generic name like Service Registration Protocol since it isn’t designed to be used as a generic unicast service registration protocol. Maybe something like Local Service Registration Protocol or Site Service Registration Protocol or Constrained Service Registration Protocol or something better than I can’t think of right now,

Thanks,
Tom

---

From: Ted Lemon <[email-masked]>
Date: Sun, 15 Jul 2018 22:18:50 -0400

> Some quick feedback on the latest version:
Thanks! :)

> 1. You reference mDNS but don’t define it as multicast DNS or reference

We do reference RFC6762 in the introduction, but you're right that we don't
introduce the term properly.

>         a. You could add Section 11 to the RFC 6763 reference.

Good point, thanks.

>         b. You don’t specify if you should use the .local domain or
> another domain. If it’s another domain, how do you find that domain?
>

We specify that you should discover the default registration domain and use
that.   It sounds like this wasn't sufficiently clear, though.  :)

>         c. Why do you recommend always using the default registration
> domain? Couldn’t you get the list of registration domains
> ("r._dns-sd._udp”) and pick one of those?
>

This is an automatic protocol, so that would have to be configured.   Once
it has to be configured, then it doesn't matter whether it uses the list of
registration domains or not, although certainly one way to make this work
would be to have a UI that presents that list and allows the user to choose
one entry.

> 3. It’s not clear to me from the document about the TTL values. The life
> of the registration is handled by the Update Lease Time and the Instance
> Lease Time. Therefore, I think the document is saying (after talking to
> Stuart) that the TTL in the registration is the one the client wants the
> server to use in responses. But the server is keeping the registration for
> longer than the TTL based on the EDNS(0) Update Lease Option values.
>

Yes, TTL and leases are completely different things.

> So does the server start the TTL countdown on the first response and then
> subsequent responses use the decrementing TTL until it times out and then
> the server resets it to the TTL it received in the register on the next
> response? This is confusing to me even after talking to Stuart so I”m
> probably just missing something.
>

TTLs are used by caches.   The server always sends the same TTL.

> You limit the scope of this to within an administrative domain limiting
> it’s applicability but nowhere else in the document do you convey this. For
> most of the document, the reader may assume that registrations can be done
> from anywhere, may wonder why they aren’t encrypted, and then only see in
> the security section that this is really made for IoT devices and in the
> home.
> I think the name of the protocol should reflect this limited scope instead
> of using a generic name like Service Registration Protocol since it isn’t
> designed to be used as a generic unicast service registration protocol.
> Maybe something like Local Service Registration Protocol or Site Service
> Registration Protocol or Constrained Service Registration Protocol or
> something better than I can’t think of right now,
>

I don't see the point in this.   If we want to make it possible to register
services from outside of the administrative domain, we can add an extension
to do that, but it doesn't really make sense to have a service registration
protocol that takes the place of an administrator, but that spans
administrative domains.   If we had an authenticated service registration
protocol, it would just be this protocol plus some additional stuff to
allow enrolled devices to register when not local.   So I think making the
base spec have a name that is limiting in this way would send exactly the
wrong message.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 15 Jul 2018 22:31:09 -0400

Here are some proposed fixes to the issues you've raised:
https://github.com/StuartCheshire/draft-sctl-service-registration/commit/f532e4aee9aaae8f1fccc104df8ea12c450bc0ab

On Sun, Jul 15, 2018 at 10:18 PM, Ted Lemon <[email-masked]> wrote:

> We do reference RFC6762 in the introduction, but you're right that we
> don't introduce the term properly.
>
>
> We specify that you should discover the default registration domain and
> use that.   It sounds like this wasn't sufficiently clear, though.  :)
>
>
>> I think the name of the protocol should reflect this limited scope
>> instead of using a generic name like Service Registration Protocol since it
>> isn’t designed to be used as a generic unicast service registration
>> protocol. Maybe something like Local Service Registration Protocol or Site
>> Service Registration Protocol or Constrained Service Registration Protocol
>> or something better than I can’t think of right now,
>>
>
> I don't see the point in this.   If we want to make it possible to
> register services from outside of the administrative domain, we can add an
> extension to do that, but it doesn't really make sense to have a service
> registration protocol that takes the place of an administrator, but that
> spans administrative domains.   If we had an authenticated service
> registration protocol, it would just be this protocol plus some additional
> stuff to allow enrolled devices to register when not local.   So I think
> making the base spec have a name that is limiting in this way would send
> exactly the wrong message.
>

---

From: Tom Pusateri <[email-masked]>
Date: Sun, 15 Jul 2018 22:44:50 -0400

Thanks for the quick response.

> On Jul 15, 2018, at 10:18 PM, Ted Lemon <[email-masked]> wrote:
>  
> We specify that you should discover the default registration domain and use that.   It sounds like this wasn't sufficiently clear, though.  :)

To discover the default registration domain, you need a domain in the query: dr._dns-sd._udp.<domain>

domain could be .local or it could be something else. You don’t specify what to use here.
 
> TTLs are used by caches.   The server always sends the same TTL.

Ok. Should there be any checking on the server to make sure the TTL is valid from the client. The only advice is make sure the TTL is the same for every record in the RRset. Should the server make sure it is <= to the lease lifetime or any other checks instead of just blindly accepting the value from the client? If the TTL value is greater than the lease lifetime, what error should the server return for the registration?
 
> I don't see the point in this.   If we want to make it possible to register services from outside of the administrative domain, we can add an extension to do that, but it doesn't really make sense to have a service registration protocol that takes the place of an administrator, but that spans administrative domains.   If we had an authenticated service registration protocol, it would just be this protocol plus some additional stuff to allow enrolled devices to register when not local.   So I think making the base spec have a name that is limiting in this way would send exactly the wrong message.

I disagree. By admitting you need an extension, you are proving my point.

Thanks,
Tom

---

From: Ted Lemon <[email-masked]>
Date: Sun, 15 Jul 2018 23:07:37 -0400

OIC, you mean which domain should be used to discover the default
registration domain?

Is this better?
https://github.com/StuartCheshire/draft-sctl-service-registration/commit/327f3fef292731951c8cc8746b6880f3e13f2e43

On Sun, Jul 15, 2018 at 10:44 PM, Tom Pusateri <[email-masked]> wrote:

> Ok. Should there be any checking on the server to make sure the TTL is
> valid from the client. The only advice is make sure the TTL is the same for
> every record in the RRset. Should the server make sure it is <= to the
> lease lifetime or any other checks instead of just blindly accepting the
> value from the client? If the TTL value is greater than the lease lifetime,
> what error should the server return for the registration?
>
>
>
>

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 16 Jul 2018 12:00:30 +0200

Ted Lemon <[email-masked]> writes:

> I just submitted an updated version of the service registration
> document. If you were planning to read this prior to the meeting and
> haven't read it yet, you should definitely read the new version. I
> think it's more understandable than the old version, but more
> importantly, it's also more correct.

Yeah, I agree the changes are an improvement!

One minor nit:

Section 2.4.2 says "A Registration MUST include at least one Service
Name update" - but the listing just above that only mentions "Service
Discovery Update", "Service Description Update" and "Host Description
Update". Is that supposed to say "MUST include at least one Host
Description update"?

> Things move fast at the IETF...

Occasionally, at least ;)

-Toke

---

From: Tim Wattenberg <[email-masked]>
Date: Mon, 16 Jul 2018 14:24:46 +0200

Ted,

I just read through this conversation and the latest version on GitHub.
I think you made valuable improvements, especially adding some wording on
where the "base-domain" comes from (DHCP/RA).

Going through the draft in detail:
- 2.3.1 first mentions SIG(0), we might want to add a reference to RFC 2931?
- 2.3.2 these server most likely won't support SIG(0) first-come
first-served -- we might want to emphasize this at that point?
- 2.3.3 (similar to 2.3.2) it might be worthwhile to point out, that these
registrations most likely won't be secured
- 2.4 general question: Is SIG(0) first-come first-serve protection
mandatory to be used by a service which registers itself? Might there be
scenario where a service explicitly wants to give other instances the
opportunity to overwrite its service registration?
- 2.4.1.1/2.4.2 for completeness: should we mention the SIG RR?
- 2.4.2 as briefly discussed yesterday: should we mention that the order of
of the update-statements does matter? I mean it's clear if the reader is
familiar with DNS update, but I thinks it doesn't hurt to also point it out
in this draft.
- 2.4.2 (naming issue mentioned by Toke): If I understand correctly, it
should say "A Registration MUST include at least one Service Discovery
update, at least one Service Description update, and exactly one Host
Description update."
- 3. On the security discussion: I agree with you that the standard
behaviour should be limited to the administrative domain -- Tom's use-case
might be subject to an extension.

Thanks, Tim

Tim Wattenberg
[email-masked]
+49 1578 8248731

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 16 Jul 2018 08:59:03 -0400

> On Jul 15, 2018, at 11:07 PM, Ted Lemon <[email-masked]> wrote:
> 
> OIC, you mean which domain should be used to discover the default registration domain?
> 
> Is this better?  https://github.com/StuartCheshire/draft-sctl-service-registration/commit/327f3fef292731951c8cc8746b6880f3e13f2e43 <https://github.com/StuartCheshire/draft-sctl-service-registration/commit/327f3fef292731951c8cc8746b6880f3e13f2e43>
> 

Yes, the the dr._dns-sd._udp.<domain> part is more clear. Thanks.

The TTL addition still leaves ambiguity for the server implementation:

"Service Registration servers SHOULD ensure that TTLs are reasonable: neither too long nor too short.  The TTL should never be longer than the lease time.”

Can you give guidance for “too short”? “too long” seems to be > lease time. If this isn’t what you mean by “too long”, guidance on that would be appreciated too.

And finally, if the TTL is “too long” or “too short”, how does the server respond? Does the server accept the registration and modify the TTL? Does the server reject the registration and return an error? What error code?

One minor nit. If I understand the distinction correctly, you use “domain” if the following places where you should use “zone”:

Section 2:

However, they can be assumed to be able to provide registration domain discovery and routing.

Section 2.2:

As described above, full-featured devices are responsible for knowing in what domain they should register their services.

Thanks,
Tom

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 16 Jul 2018 14:47:08 -0400

> On Jul 16, 2018, at 8:59 AM, Tom Pusateri <[email-masked]> wrote:
> 

May I suggest that the server adjusts the TTL to a reasonable value (guidance) and returns the new value in the response.

Then the client can know for the future what is a more acceptable value and adjust future registrations with this server.

New Feedback
——————————

Section 2 says:

'In other network environments, updates for names ending in "services.arpa" may be rewritten internally to names with broader visibility.’

And Section 2.2 says:

‘...and let the DNS-SD Service Registration server handle rewriting that to a different domain if necessary.’

When the registration server rewrites the domain, does it send the new domain back in the response? I couldn’t find that anywhere in the document. Does it have to send back all of the records in the request? Can it send just a header if the Zone doesn’t change and the TTL doesn’t change? Can it only complete the Zone section if the zone name changes but the TTL stays the same with nothing changes in the Update section?

Section 2.3.3:

'To do so, it must discover default registration zone’   ——> insert ‘the’

Section 2.4.2 Page 9:

change “rejectration” to “registration”.

Throughout the document "DNS-SD Registration Protocol” is used synonymously with "DNS-SD Service Registration Protocol”. If the latter is too many words, you might substitute ‘this specification’. This becomes even more confusing with the discussion of service registration protocols in RFC 6763 such as:
	"Service discovery requires a service registration protocol. DNS already has one: DNS Dynamic Update.” and
	"This also requires some service discovery registration protocol to be implemented and deployed for clients to register with the central aggregation server.  Virtually every company with an IP network already runs a DNS server, and DNS already has a dynamic registration protocol.”
This provides additional motivation for a new name.

“Registrations” is capitalized lots of places where it probably shouldn’t be: "Ordinarily Registrations will fail…”

Thanks,
Tom

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Jul 2018 14:50:54 -0400

I don't know, I kind of like rejectration.   It has a certain classy ring
to it that you don't get with a more pedestrian word like "registration."
:)

My intention with "Registration" was for it to be referring to any message
from the service to the DNS-SD Registration server.  So the capitalization
was intentional.   But I agree that the term is a bit too generic; it might
be better if we could come up with a term that didn't need to be
capitalized to make it stand out.   Maybe "rejectration?"   (Just
Kidding... :)

On Mon, Jul 16, 2018 at 2:47 PM, Tom Pusateri <[email-masked]> wrote:

> > "Service Registration servers SHOULD ensure that TTLs are reasonable:
> neither too long nor too short.  The TTL should never be longer than the
> lease time.”
> >
> > Can you give guidance for “too short”? “too long” seems to be > lease
> time. If this isn’t what you mean by “too long”, guidance on that would be
> appreciated too.
> >
> > And finally, if the TTL is “too long” or “too short”, how does the
> server respond? Does the server accept the registration and modify the TTL?
> Does the server reject the registration and return an error? What error
> code?
>
> May I suggest that the server adjusts the TTL to a reasonable value
> (guidance) and returns the new value in the response.
>
> Then the client can know for the future what is a more acceptable value
> and adjust future registrations with this server.
>
> New Feedback
> ——————————
>
> Section 2 says:
>
> 'In other network environments, updates for names ending in
> "services.arpa" may be rewritten internally to names with broader
> visibility.’
>
> And Section 2.2 says:
>
> When the registration server rewrites the domain, does it send the new
> domain back in the response? I couldn’t find that anywhere in the document.
> Does it have to send back all of the records in the request? Can it send
> just a header if the Zone doesn’t change and the TTL doesn’t change? Can it
> only complete the Zone section if the zone name changes but the TTL stays
> the same with nothing changes in the Update section?
>
> Section 2.3.3:
>
> Throughout the document "DNS-SD Registration Protocol” is used
> synonymously with "DNS-SD Service Registration Protocol”. If the latter is
> too many words, you might substitute ‘this specification’. This becomes
> even more confusing with the discussion of service registration protocols
> in RFC 6763 such as:
>         "Service discovery requires a service registration protocol. DNS
> already has one: DNS Dynamic Update.” and
>         "This also requires some service discovery registration protocol
> to be implemented and deployed for clients to register with the central
> aggregation server.  Virtually every company with an IP network already
> runs a DNS server, and DNS already has a dynamic registration protocol.”
> “Registrations” is capitalized lots of places where it probably shouldn’t
> be: "Ordinarily Registrations will fail…”
>
> Thanks,
> Tom
>
>
>

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 16 Jul 2018 15:01:27 -0400

> On Jul 16, 2018, at 2:50 PM, Ted Lemon <[email-masked]> wrote:
> 
> I don't know, I kind of like rejectration.   It has a certain classy ring to it that you don't get with a more pedestrian word like "registration."  :)
> 
> My intention with "Registration" was for it to be referring to any message from the service to the DNS-SD Registration server.  So the capitalization was intentional.   But I agree that the term is a bit too generic; it might be better if we could come up with a term that didn't need to be capitalized to make it stand out.   Maybe "rejectration?"   (Just Kidding... :)

Uniqueness is important…

One more thing, you allocate a special use domain name ‘services.arpa’ but there is no IANA section to advise IANA on the allocation.

Thanks,
Tom

---

From: Tim Wattenberg <[email-masked]>
Date: Mon, 16 Jul 2018 21:17:21 +0200

> the same with nothing changes in the Update section?

This was in an earlier version of the draft (see https://github.com/
StuartCheshire/draft-sctl-service-registration/blob/
51b7cb54300fea7e44e8e7dee49c17e9f598b3ba/draft-sctl-service-
registration.txt#L204):

> The response to the DNS Update being used to register the service will
> contain the rewritten names, instead of ".local". Subsequent updates should
> still use the ".local" domain and not the registration domain, since the
> registration domain may change over time or when the service is physically
> moved to a new network.
>

However it got removed with the following iteration when moving to the
"services.arpa" domain.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Jul 2018 17:19:57 -0400

> - 2.3.1 first mentions SIG(0), we might want to add a reference to RFC
Done (not yet committed)

> first-served -- we might want to emphasize this at that point?
 I added text.

> registrations most likely won't be secured

I think this is unnecessary.   In order for such an update to be done, it
would have to be accompanied with whatever authentication the server being
updated requires.

> opportunity to overwrite its service registration?

I think defining a semantics for this that would not be hugely problematic
is difficult and definitely out of scope for this work.

> - 2.4.1.1/2.4.2 for completeness: should we mention the SIG RR?

What would we say?

> - 2.4.2 as briefly discussed yesterday: should we mention that the order
> of of the update-statements does matter? I mean it's clear if the reader is

I added this:
  Order matters in DNS updates.  Specifically, deletes must precede adds
for records that the deletes
  would affect; otherwise the add will have no effect.</t>

> update, at least one Service Description update, and exactly one Host

Yes, fixed.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Jul 2018 17:24:07 -0400

On Mon, Jul 16, 2018 at 8:59 AM, Tom Pusateri <[email-masked]> wrote:

> And finally, if the TTL is “too long” or “too short”, how does the server
> respond? Does the server accept the registration and modify the TTL? Does
> the server reject the registration and return an error? What error code?
>

I've added text.   The answer is that it's not an error for the SRP Update
to contain a TTL that the server doesn't like—if the server doesn't like
it, it just overrides it.

> One minor nit. If I understand the distinction correctly, you use “domain”
> if the following places where you should use “zone”:
>
> Section 2:
>
> As described above, full-featured devices are responsible for knowing in
> what domain they should register their services.
>
> In terms of DNS terminology, the correct term is domain, not zone.   The
registration domain doesn't have to be at a zone cut.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 16 Jul 2018 23:27:03 +0200

>> update, at least one Service Description update, and exactly one Host

Why can't it be just a Host Description? Might be useful for a device
that just wants to register its name but doesn't (currently, or ever)
advertise any services...

-Toke

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Jul 2018 17:28:07 -0400

> (guidance) and returns the new value in the response.

I don't think this is important.   What behavior on the client would change
on the basis of this guidance?   The client doesn't necessarily know which
server it's talking to, so the advisory TTL value, if retained, might be
considered wrong next time it sends an update. strations with this server.

> New Feedback

We concluded that it does not.   The only case where this happens now is
for constrained devices, and constrained devices shouldn't care.

> 'To do so, it must discover default registration zone’   ——> insert ‘the’
thanks.

> change “rejectration” to “registration”.
Done.

> be: "Ordinarily Registrations will fail…”

Yeah, I went through the document and noticed that there was a huge amount
of inconsistent use of terminology.   I updated the document to use SRP
instead of the various permutations of DNS-SD Service Registration
Protocol, SRP Server for the various permutations of Registration server,
and SRP update instead of Registration.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Jul 2018 17:29:32 -0400

On Mon, Jul 16, 2018 at 5:27 PM, Toke Høiland-Jørgensen <[email-masked]>
wrote:

> Good question.   What does the working group think?   :)

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Jul 2018 17:46:52 -0400

BTW, the current version of the document on github now includes fixes for
all the points that have been raised other than the ones I said I wasn't
going to fix:
https://github.com/StuartCheshire/draft-sctl-service-registration

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 16 Jul 2018 17:59:23 -0400

How is DNS-Based Service Discovery different from DNS Service Discovery?

Is this meant to distinguish from RFC 6763?
 
Thanks,
Tom

> On Jul 16, 2018, at 5:46 PM, Ted Lemon <[email-masked]> wrote:
> 
> BTW, the current version of the document on github now includes fixes for all the points that have been raised other than the ones I said I wasn't going to fix: https://github.com/StuartCheshire/draft-sctl-service-registration
> 
>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke Høiland-Jørgensen <[email-masked]> wrote:
>>> 
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Jul 2018 18:01:50 -0400

The title of RFC 6763 is DNS-Based Service Discovery.   So I tried to
harmonize the document toward that—did I miss something?

On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri <[email-masked]> wrote:

> going to fix: https://github.com/StuartCheshire/draft-sctl-
> service-registration
>

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 16 Jul 2018 18:41:25 -0400

Ok, just checking. So given that 6763 semi-defines service registration protocol as DNS Dynamic Update, should this document claim it updates 6763?

Thanks,
Tom

> On Jul 16, 2018, at 6:01 PM, Ted Lemon <[email-masked]> wrote:
> 
> The title of RFC 6763 is DNS-Based Service Discovery.   So I tried to harmonize the document toward that—did I miss something?
> 
> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
> On Jul 16, 2018, at 5:46 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> BTW, the current version of the document on github now includes fixes for all the points that have been raised other than the ones I said I wasn't going to fix: https://github.com/StuartCheshire/draft-sctl-service-registration <https://github.com/StuartCheshire/draft-sctl-service-registration>
>> 
>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>> On Mon, Jul 16, 2018 at 5:27 PM, Toke Høiland-Jørgensen <[email-masked] <mailto:[email-masked]>> wrote:
>> Ted Lemon <[email-masked] <mailto:[email-masked]>> writes:
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Jul 2018 18:42:36 -0400

The question of whether we update RFC6763 is basically "is there text that
is in RFC6763 that is no longer correct because of this document."  I think
the answer is no.

On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri <[email-masked]> wrote:

> Ok, just checking. So given that 6763 semi-defines service registration
> protocol as DNS Dynamic Update, should this document claim it updates 6763?
>
> Thanks,
> Tom
>
>> going to fix: https://github.com/StuartCheshire/draft-sctl-service-
>> registration
>>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Jul 2018 16:12:44 -0400

Tim pointed out that we need to protect the Service Instance Name as well
as the Host Description with a KEY record, because FCFS naming has to
protect both the service description and the host description.   Here are
the changes:

https://github.com/StuartCheshire/draft-sctl-service-registration/compare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8da85874597

On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon <[email-masked]> wrote:

>>> BTW, the current version of the document on github now includes fixes
>>> for all the points that have been raised other than the ones I said I
>>> wasn't going to fix: https://github.com/Stuart
>>> Cheshire/draft-sctl-service-registration
>>>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Jul 2018 16:14:39 -0400

Oh, this also adds text to the server behavior that simply requires that
the server check the validity of the SRP Update as a DNS uipdate as well as
an SRP update, since SRP update semantics are layered on top of DNS update
semantics.

On Tue, Jul 17, 2018 at 4:12 PM, Ted Lemon <[email-masked]> wrote:

> https://github.com/StuartCheshire/draft-sctl-service-registration/compare/
> ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8
> da85874597
>
>> The question of whether we update RFC6763 is basically "is there text
>> that is in RFC6763 that is no longer correct because of this document."  I
>> think the answer is no.
>>

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 18 Jul 2018 12:05:25 -0400

If you are adding more KEY records, you will certainly exceed the UDP update size of 512 bytes. The draft doesn’t mention transport but maybe this should be restricted to TCP.
The draft does mention searching for the update server using _dns-update._udp.<domain>. But then it won’t be able to use UDP for updates.

Thanks,
Tom

> On Jul 17, 2018, at 4:12 PM, Ted Lemon <[email-masked]> wrote:
> 
> Tim pointed out that we need to protect the Service Instance Name as well as the Host Description with a KEY record, because FCFS naming has to protect both the service description and the host description.   Here are the changes:
> 
> https://github.com/StuartCheshire/draft-sctl-service-registration/compare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8da85874597 <https://github.com/StuartCheshire/draft-sctl-service-registration/compare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8da85874597>
> 
> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
> The question of whether we update RFC6763 is basically "is there text that is in RFC6763 that is no longer correct because of this document."  I think the answer is no.
> 
> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 16, 2018, at 6:01 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Tim Wattenberg <[email-masked]>
Date: Wed, 18 Jul 2018 18:14:15 +0200

Well, the draft references to use regular DNS update messages as of RFC
2136 -- sec. 2.1 says to use UDP if it fits and switch to TCP otherwise.
However I agree that the "search domain" (dr._dns-sd._udp and
_dns-update._udp) mentioning UDP might me confusing.

Tim

Tim Wattenberg
[email-masked]
+49 1578 8248731

2018-07-18 18:05 GMT+02:00 Tom Pusateri <[email-masked]>:

> If you are adding more KEY records, you will certainly exceed the UDP
> update size of 512 bytes. The draft doesn’t mention transport but maybe
> this should be restricted to TCP.
> The draft does mention searching for the update server using
> _dns-update._udp.<domain>. But then it won’t be able to use UDP for
> updates.
>
> Thanks,
> Tom
>

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 18 Jul 2018 12:15:05 -0400

Looking in the IANA registry, dns-update isn’t assigned for TCP. So either you search for _dns-update._udp.<domain> and use TCP or you register _tcp.

And while you could use an EDNS(0) OPT RR to set the maximum UDP packet size larger than 512, you probably wouldn’t want to set it larger than the MTU and 1480 isn’t big enough for 3 KEYs plus other records.

Tom

> On Jul 18, 2018, at 12:05 PM, Tom Pusateri <[email-masked]> wrote:
> 
>> On Jul 17, 2018, at 4:12 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 18 Jul 2018 12:25:00 -0400

Just saw this in Section 2: "By requiring the use of TCP, the possibility of off-network spoofing is eliminated”. So requiring TCP is already handled.

Searching for _dns-update._udp.<domain> still seems odd but that’s been going on for a while a presume.

Tom

> On Jul 18, 2018, at 12:15 PM, Tom Pusateri <[email-masked]> wrote:
> 
>> On Jul 18, 2018, at 12:05 PM, Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Jul 2018 12:27:12 -0400

Of course, you still have a very good point in that the anycast update
method relies on UDP, so sending the key multiple times isn't desirable.
 But I also don't see a way around this.   We could have the server
replicate the key, I guess.

On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri <[email-masked]> wrote:

> Just saw this in Section 2: "By requiring the use of TCP, the possibility
> of off-network spoofing is eliminated”. So requiring TCP is already handled.
>
> Looking in the IANA registry, dns-update isn’t assigned for TCP. So either
> you search for _dns-update._udp.<domain> and use TCP or you register _tcp.
>
> And while you could use an EDNS(0) OPT RR to set the maximum UDP packet
> size larger than 512, you probably wouldn’t want to set it larger than the
> MTU and 1480 isn’t big enough for 3 KEYs plus other records.
>
> Tom
>

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 18 Jul 2018 12:48:26 -0400

I don’t see anywhere in the document where the anycast update method relies on UDP.

Tom

> On Jul 18, 2018, at 12:27 PM, Ted Lemon <[email-masked]> wrote:
> 
> Of course, you still have a very good point in that the anycast update method relies on UDP, so sending the key multiple times isn't desirable.   But I also don't see a way around this.   We could have the server replicate the key, I guess.
> 
> On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 18, 2018, at 12:15 PM, Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf..org/mailman/listinfo/dnssd>
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Jul 2018 13:08:49 -0400

Hm, you're right, that's never stated explicitly.

On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri <[email-masked]> wrote:

>> Looking in the IANA registry, dns-update isn’t assigned for TCP. So
>> either you search for _dns-update._udp.<domain> and use TCP or you
>> register _tcp.
>>
>> https://github.com/StuartCheshire/draft-sctl-service-
>> registration/compare/ae53618d8231733701ccdda4d336692a529c9f6
>> b...5c85181881b84ed1132d544e157df8da85874597
>>
>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke Høiland-Jørgensen <[email-masked]
>>>>>> > wrote:
>>>>>>
>> <https://www.ietf..org/mailman/listinfo/dnssd>
>>
>>
>>

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 18 Jul 2018 19:37:45 -0400

Tim and I were talking and we were wondering if one client could delete the PTR record for a service instance that another client created? Seems like it’s not protected and could be a denial of service attack? So you might need a KEY record the PTR record.

Tom

> On Jul 18, 2018, at 1:08 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 18, 2018, at 12:27 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 18 Jul 2018 19:40:39 -0400

You might not need a new KEY record for the PTR but you may need to follow the instance of the PTR to a KEY record to make sure you have permission to delete the PTR record.

Tom

> On Jul 18, 2018, at 7:37 PM, Tom Pusateri <[email-masked]> wrote:
> 
>> On Jul 18, 2018, at 1:08 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Jul 2018 20:27:37 -0400

You can't delete anything from a service name.   Maybe we need to say that
more explicitly.   Right now the protocol doesn't allow a service to delete
itself; only to add itself.   The assumption is that the service will not
know in advance that it is leaving the network, so service entries get
garbage collected, rather than being explicitly deleted.   Compare to
DHCPRELEASE in the DHCP protocol, which is pretty useless.

On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri <[email-masked]> wrote:

> You might not need a new KEY record for the PTR but you may need to follow
> the instance of the PTR to a KEY record to make sure you have permission to
> delete the PTR record.
>
> Tom
>
>
> Tim and I were talking and we were wondering if one client could delete
> the PTR record for a service instance that another client created? Seems
> like it’s not protected and could be a denial of service attack? So you
> might need a KEY record the PTR record.
>
> Tom
>
>>> Just saw this in Section 2: "By requiring the use of TCP, the
>>> possibility of off-network spoofing is eliminated”. So requiring TCP is
>>> already handled.
>>>
>>> Tim pointed out that we need to protect the Service Instance Name as
>>> well as the Host Description with a KEY record, because FCFS naming has to
>>> https://github.com/StuartCheshire/draft-sctl-service-registr
>>> ation/compare/ae53618d8231733701ccdda4d336692a529c9f6b...
>>> 5c85181881b84ed1132d544e157df8da85874597
>>>
>>>>> Ok, just checking. So given that 6763 semi-defines service
>>>>> registration protocol as DNS Dynamic Update, should this document claim it
>>>>> updates 6763?
>>>>>
>>>>> Thanks,
>>>>> Tom
>>>>>

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 18 Jul 2018 21:30:18 -0400

Yeah, that needs to be more explicit. 

If you try to do a delete, does the server send REFUSED?

Thanks,
Tom

> On Jul 18, 2018, at 8:27 PM, Ted Lemon <[email-masked]> wrote:
> 
> You can't delete anything from a service name.   Maybe we need to say that more explicitly.   Right now the protocol doesn't allow a service to delete itself; only to add itself.   The assumption is that the service will not know in advance that it is leaving the network, so service entries get garbage collected, rather than being explicitly deleted.   Compare to DHCPRELEASE in the DHCP protocol, which is pretty useless.
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Jul 2018 21:36:51 -0400

Yes, that’s the correct behavior.

On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri <[email-masked]> wrote:

>> You might not need a new KEY record for the PTR but you may need to
>> follow the instance of the PTR to a KEY record to make sure you have
>> permission to delete the PTR record.
>>
>> Tom
>>
>>
>>>> The draft does mention searching for the update server using _dns-update._udp.<domain>.
>>>> But then it won’t be able to use UDP for updates.
>>>>
>>>> Thanks,
>>>> Tom
>>>>
>>>>>>> BTW, the current version of the document on github now includes
>>>>>>> fixes for all the points that have been raised other than the ones I said I
>>>>>>> wasn't going to fix:

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Jul 2018 22:06:48 -0400

Okay, I've pushed fixes for the last couple of issues you guys brought up.
 I used _dnssd-srp._tcp instead of _dns-update._udp, but that's up for
debate.

https://github.com/StuartCheshire/draft-sctl-service-registration/commit/ce15160933b458a2da2346b6181ad89ed0ff1e11

On Wed, Jul 18, 2018 at 9:36 PM, Ted Lemon <[email-masked]> wrote:

>> You can't delete anything from a service name.   Maybe we need to say
>> that more explicitly.   Right now the protocol doesn't allow a service to
>> delete itself; only to add itself.   The assumption is that the service
>> will not know in advance that it is leaving the network, so service entries
>> get garbage collected, rather than being explicitly deleted.   Compare to
>>>>> And while you could use an EDNS(0) OPT RR to set the maximum UDP
>>>>> packet size larger than 512, you probably wouldn’t want to set it larger
>>>>> than the MTU and 1480 isn’t big enough for 3 KEYs plus other records.
>>>>>
>>>>> Tom
>>>>>
>>>>> https://github.com/StuartCheshire/draft-sctl-
>>>>> service-registration/compare/ae53618d8231733701ccdda4d33669
>>>>> 2a529c9f6b...5c85181881b84ed1132d544e157df8da85874597
>>>>>
>>>>>>> The title of RFC 6763 is DNS-Based Service Discovery.   So I tried
>>>>>>> to harmonize the document toward that—did I miss something?
>>>>>>>
>>>>>>>> wasn't going to fix: https://github.com/StuartCheshire/draft-sctl-
>>>>>>>> service-registration
>>>>>>>>

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 18 Jul 2018 22:17:42 -0400

So if a device changes it’s name, the old one could be around for a while along side the new name. 

That might be confusing. 

Tom

> On Jul 18, 2018, at 10:06 PM, Ted Lemon <[email-masked]> wrote:
> 
> Okay, I've pushed fixes for the last couple of issues you guys brought up.   I used _dnssd-srp._tcp instead of _dns-update._udp, but that's up for debate.
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Jul 2018 22:30:13 -0400

Depends on how the name change happens, but sure.   If a device has a
name-change UI, it could use a very short update lease time, but the server
might override it.   I guess we could define an SRP delete message that
deletes all or part of a registration.

On Wed, Jul 18, 2018 at 10:17 PM, Tom Pusateri <[email-masked]> wrote:

> Okay, I've pushed fixes for the last couple of issues you guys brought
> up.   I used _dnssd-srp._tcp instead of _dns-update._udp, but that's up for
> debate.
>
>>>>>>> The question of whether we update RFC6763 is basically "is there
>>>>>>> text that is in RFC6763 that is no longer correct because of this
>>>>>>> document."  I think the answer is no.
>>>>>>>

---

From: Tim Wattenberg <[email-masked]>
Date: Wed, 18 Jul 2018 22:47:38 -0400

Ted,
you said that deleting a service instance is not covered by the draft, I can see how a short lease time could mimic that functionality. 

However if we allow any DNS update operation on the PTRs besides adding a record, wouldn’t that actually still require checking the “ownership”? Otherwise a service could update another services’ lease time and by that “delete” the other service. 

> On 18. Jul 2018, at 22:30, Ted Lemon <[email-masked]> wrote:
> 
> Depends on how the name change happens, but sure.   If a device has a name-change UI, it could use a very short update lease time, but the server might override it.   I guess we could define an SRP delete message that deletes all or part of a registration.
>

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 18 Jul 2018 23:34:57 -0400

Speaking of name changes, you may need to handle name collision in a special way. Since devices can’t see other devices names, they can’t easily create unique names. So if there are 10 light bulbs from the same vendor all starting to register the instance name “light bulb”, the first will succeed and the others get YXDOMAIN. The second one will realize the name is taken but not know how to necessarily create a new name that is unique. The tenth light bulb might go through 9 iterations before generating a unique name. The traditional name collision avoidance mechanism with mDNS of incrementing a numerical suffix doesn’t work very well when you don’t know how many there are.

It might be better to suggest a random suffix instead of a numerical one or some other mechanism of generating unique names from the beginning. But then they won’t look human readable so I don’t know if that is a consideration.

Thanks,
Tom

> On Jul 18, 2018, at 10:30 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Wed, Jul 18, 2018 at 10:17 PM, Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
> On Jul 18, 2018, at 10:06 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> https://github.com/StuartCheshire/draft-sctl-service-registration/commit/ce15160933b458a2da2346b6181ad89ed0ff1e11 <https://github.com/StuartCheshire/draft-sctl-service-registration/commit/ce15160933b458a2da2346b6181ad89ed0ff1e11>
>> 
>> On Wed, Jul 18, 2018 at 9:36 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>> On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 18, 2018, at 8:27 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
>>>> On Jul 18, 2018, at 7:37 PM, Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf...org/mailman/listinfo/dnssd>
>>>>>> 
>>>>>>

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 19 Jul 2018 07:32:41 -0400

And I think this is a general problem to solve for unicast updates, not necessarily a SRP thing.

For instance, while the discovery proxy separates IP subnets which a unique subdomain to avoid collision, using regular unicast update to a discovery proxy doesn’t know about IP subnet subdomains and uses a shared namespace. The unicast name collision problem exists there too.

I haven’t read the mDNS relay spec in detail enough to know if it collapses the namespace or abides by the IP subnet subdomain separate namespaces.

But this may be something Stuart already solved. I’m just not aware of the solution.

Thanks,
Tom

> On Jul 18, 2018, at 11:34 PM, Tom Pusateri <[email-masked]> wrote:
> 
>> On Jul 18, 2018, at 10:30 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jul 2018 07:51:24 -0400

Yes, the way this would work is that you would have to delete your ptr
 record and at least the SRV and TXT records on the service instance name
it points to. You would sign this with the KEY that is on the service
instance name. This could be authenticated using that key.

On Wed, Jul 18, 2018 at 10:47 PM Tim Wattenberg <[email-masked]>
wrote:

> Ted,
> you said that deleting a service instance is not covered by the draft, I
> can see how a short lease time could mimic that functionality.
>
> However if we allow any DNS update operation on the PTRs besides adding a
> record, wouldn’t that actually still require checking the “ownership”?
> Otherwise a service could update another services’ lease time and by that
> “delete” the other service.
>
>>>>> Tim and I were talking and we were wondering if one client could
>>>>> delete the PTR record for a service instance that another client created?
>>>>> Seems like it’s not protected and could be a denial of service attack? So
>>>>> you might need a KEY record the PTR record.
>>>>>
>>>>> Tom
>>>>>
>>>>>> Of course, you still have a very good point in that the anycast
>>>>>> update method relies on UDP, so sending the key multiple times isn't
>>>>>> desirable.   But I also don't see a way around this.   We could have the
>>>>>> server replicate the key, I guess.
>>>>>>
>>>>>>> If you are adding more KEY records, you will certainly exceed the
>>>>>>> UDP update size of 512 bytes. The draft doesn’t mention transport but maybe
>>>>>>> <https://www.ietf...org/mailman/listinfo/dnssd>
>>>>>>>
>>>>>>>
>>>>>>>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jul 2018 07:55:12 -0400

The service registration domain is its own domain, not one of th link
domains. Disambiguation is done in the UI. If there are two services in two
different domains with the same name otherwise, these would appear in the
UI with the same name, annotated with the link name. SRP names would follow
the same convention.

I think this is talked about in the service discovery broker document.

On Thu, Jul 19, 2018 at 7:32 AM Tom Pusateri <[email-masked]> wrote:

> For instance, while the discovery proxy separates IP subnets which a
> unique subdomain to avoid collision, using regular unicast update to a
> discovery proxy doesn’t know about IP subnet subdomains and uses a shared
> namespace. The unicast name collision problem exists there too.
>
> I haven’t read the mDNS relay spec in detail enough to know if it
> collapses the namespace or abides by the IP subnet subdomain separate
> namespaces.
>
> Speaking of name changes, you may need to handle name collision in a
> special way. Since devices can’t see other devices names, they can’t easily
> create unique names. So if there are 10 light bulbs from the same vendor
> all starting to register the instance name “light bulb”, the first will
> succeed and the others get YXDOMAIN. The second one will realize the name
> is taken but not know how to necessarily create a new name that is unique.
> The tenth light bulb might go through 9 iterations before generating a
> unique name. The traditional name collision avoidance mechanism with mDNS
> of incrementing a numerical suffix doesn’t work very well when you don’t
> know how many there are.
>
> It might be better to suggest a random suffix instead of a numerical one
> or some other mechanism of generating unique names from the beginning. But
> then they won’t look human readable so I don’t know if that is a
> consideration.
>
> Thanks,
> Tom
>
>
>

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 19 Jul 2018 10:14:59 -0400

I've read this draft and I support its adoption.   One thing to add to the
document once it's adopted that any DNS naming involving _underscore names
addresses the new BCP from DNSOP draft-ietf-dnsop-attrleaf

Tim

On Thu, Jul 19, 2018 at 7:55 AM, Ted Lemon <[email-masked]> wrote:

>>> service-registration/commit/ce15160933b458a2da2346b6181ad89ed0ff1e11
>>>
>>>>>>>> _dns-update._udp.<domain>. But then it won’t be able to use UDP
>>>>>>>> for updates.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tom
>>>>>>>>
>>>>>>>> Tim pointed out that we need to protect the Service Instance Name
>>>>>>>> as well as the Host Description with a KEY record, because FCFS naming has
>>>>>>>> to protect both the service description and the host description.   Here
>>>>>>>> are the changes:
>>>>>>>>
>>>>>>>>>> The title of RFC 6763 is DNS-Based Service Discovery.   So I
>>>>>>>>>> tried to harmonize the document toward that—did I miss something?
>>>>>>>>>>
>>>>>>>>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri <[email-masked]
>>>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>>> wasn't going to fix: https://github.com/
>>>>>>>>>>> StuartCheshire/draft-sctl-service-registration
>>>>>>>>>>>