Subject: [dnssd] draft-aggarwal-dnssd-optimize-query-00

From: Tom Pusateri <[email-masked]>
Date: Thu, 24 Jul 2014 14:09:35 -0400

Ashutosh,
	Interesting draft. I have a few comments.

1. In section 3, you describe the TXT record filters in the additional section. But you don't exactly specify what is in the query section. Does this apply only for queries to instances of TXT records or does this also apply to PTR queries for instances of services or for PTR queries for just the service itself or all three?

2. There would seem to be a tradeoff in requesting too much or too little. If you apply TXT filters and then don't get any responses, you will have to query again with a broader filter. The optimal case will depend on the service you're looking for. In some cases you would have been better off without the filter. In other cases, knowing there is no match is useful too. Each application will have to make that tradeoff when it queries.

3. With your implied logical operations of TXT attribute filters, things could get confusing when there are multiple records queried at once. You should expand on section 3 to explain this after clarifying from question #1 which record types are in the query section. It's perfectly legal to query the PTR record for _printer._tcp.local and the TXT and SRV records for HP OfficeJet._printer._tcp.local in the same query. Will the TXT record in the additional records section have to be for an instance like HP OfficeJet._printer._tcp.local or does it apply to the PTR query for _printer._tcp.local? If the TXT record can be for a service and not a specific instance, this changes who responds.
When there are multiple TXT records in the additional section, it gets more confusing on how to apply the logical operations.

Thanks,
Tom

---

From: "Aggarwal, Ashutosh" <[email-masked]>
Date: Thu, 24 Jul 2014 18:58:56 +0000

Thanks for your comments. Please see below:

-----Original Message-----
From: dnssd [mailto:[email-masked]] On Behalf Of Tom Pusateri
Sent: Thursday, July 24, 2014 11:10 AM
To: [email-masked]
Subject: [dnssd] draft-aggarwal-dnssd-optimize-query-00

Ashutosh,

[Aggarwal, Ashutosh] 
This contribution was written to optimize the DNS-SD query scenario when the client application issues the PTR query with the service name. The contribution proposes to add DNS TXT records for such queries. 

2. There would seem to be a tradeoff in requesting too much or too little. If you apply TXT filters and then don't get any responses, you will have to query again with a broader filter. The optimal case will depend on the service you're looking for. In some cases you would have been better off without the filter. In other cases, knowing there is no match is useful too. Each application will have to make that tradeoff when it queries.
[Aggarwal, Ashutosh] 
You are absolutely correct regarding trade-offs. The pre-condition is that the client application knows what constraints or filters it is looking to apply and it should specify them in the initial query. It would be better than querying for the service name and then establishing a connection with each service instance for subsequent negotiation. If the client application doesn't need to apply any filter, it can send the query with the service name only. The decision regarding which keys/filters to apply is application specific as you mention. Just like DNS-SD has the provision for the responder to add key/value pairs in the DNS response message, the contribution proposes to enable the use of DNS TXT records in the PTR queries for the service name.

[Aggarwal, Ashutosh] 
[Aggarwal, Ashutosh] 
I added multiple TXT records details if we want to allow for complex filter criteria. I can add some examples to clarify for sure. We can discuss if we can summarize the desired filter criteria using a single TXT record. The filtering scheme was proposed for PTR query with the service name.

Hope this answers your comments,
Ashutosh

Thanks,
Tom
_______________________________________________
dnssd mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnssd

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 24 Jul 2014 16:21:14 -0400

> On Jul 24, 2014, at 2:58 PM, Aggarwal, Ashutosh <[email-masked]> wrote:
> 

Ok, but a TXT record is for an instance of a service. So your proposal is now changing what is expected in a TXT record.

Let's clarify to be sure. You are suggesting this:

----------------------------------------
Query Section:

_printer._tcp.local. IN PTR

Additional Records Section:

_printer._tcp.local. IN TXT "color=True"
----------------------------------------

An mDNS participant that isn't aware of your draft, would expect the TXT record in the AR Section to be an actual instance of a service. Something like this would be more expected:

HP OfficeJet._printer._tcp.local. IN TXT "color=True"

and the recipient wouldn't know what to do with

_printer._tcp.local. IN TXT "color=True"

since it is not an instance of a service.

Thanks,
Tom

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 24 Jul 2014 16:27:11 -0400

Additionally,  since TXT records are incredibly overloaded at this point 
in time that the creation of a TXT Registry draft was both useful and 
sad at the same time.

tim

---

From: "Aggarwal, Ashutosh" <[email-masked]>
Date: Fri, 25 Jul 2014 02:05:00 +0000

Yes, your example below (between the dotted lines) captures what the draft is proposing. 

Btw, when you say the TXT record is for an instance of service that is certainly true in the current DNS-SD scope when the service instance is populating the TXT records in the response. At the time of query, querier only knows about the service name and hence the TXT record in the additional section can only represent the service and not the service instance. With this change, there is implied behavior for the responders who choose to filter the response based on the keys and they can process the TXT records as proposed (that was my thinking). 

Thanks,
Ashutosh 

-----Original Message-----
From: Tom Pusateri [mailto:[email-masked]] 
Sent: Thursday, July 24, 2014 1:21 PM
To: Aggarwal, Ashutosh
Cc: [email-masked]; Dave Thaler ([email-masked])
Subject: Re: [dnssd] draft-aggarwal-dnssd-optimize-query-00

Thanks,
Tom

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 25 Jul 2014 09:01:23 -0400

Ok, you should probably say in the draft that the TTL of the TXT record in the AR section should be set to 0 so it won't be cached.

Thanks,
Tom

> On Jul 24, 2014, at 10:05 PM, Aggarwal, Ashutosh <[email-masked]> wrote:
>

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 25 Jul 2014 09:15:34 -0400

> _printer._tcp.local. IN TXT "color=True"

Just to be perfectly clear, an mDNS participant that isn't aware of
the draft isn't anyway allowed to have a theory of what might appear
in a TXT record.  This is the problem with overloading TXT records.
You're just not allowed to make assumptions about what might appear
there, underscore labels or not, because the DNS permits approximately
anything at all in the RDATA of a TXT record and mDNS follows the
semantics of DNS RRTYPEs.  So any implementation _has to_ be able to
cope with these records it isn't expecting, or it is already broken.

But I agree that it's not ideal to overload the underscore-labelled
TXT record if one can avoid it.  Given the goal in the draft, however,
I don't think it can be avoided.

Just to be clear, I think it is clear that this is an mDNS-only trick:
given DNSSEC, you can't do anything with the DNS.  (I worry also about
caches in the DNS and these additional records, if you did filtering.
That's another reason not to do this in DNS.)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Aggarwal, Ashutosh" <[email-masked]>
Date: Fri, 25 Jul 2014 23:37:12 +0000

Sure, I will reflect that in the next set of updates.

Thanks,
Ashutosh

-----Original Message-----
From: Tom Pusateri [mailto:[email-masked]] 
Sent: Friday, July 25, 2014 6:01 AM
To: Aggarwal, Ashutosh
Cc: [email-masked]; Dave Thaler ([email-masked])
Subject: Re: [dnssd] draft-aggarwal-dnssd-optimize-query-00

Thanks,
Tom