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

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

Thanks,
Ashutosh

-----Original Message-----
From: Tom Pusateri [mailto:pusateri@bangj.com] 
Sent: Friday, July 25, 2014 6:01 AM
To: Aggarwal, Ashutosh
Cc: dnssd@ietf.org; Dave Thaler (dthaler@microsoft.com)
Subject: Re: [dnssd] draft-aggarwal-dnssd-optimize-query-00

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 <aaggarwa@qce.qualcomm.com> wrote:
> 
> 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:pusateri@bangj.com] 
> Sent: Thursday, July 24, 2014 1:21 PM
> To: Aggarwal, Ashutosh
> Cc: dnssd@ietf.org; Dave Thaler (dthaler@microsoft.com)
> Subject: Re: [dnssd] draft-aggarwal-dnssd-optimize-query-00
> 
> 
>> On Jul 24, 2014, at 2:58 PM, Aggarwal, Ashutosh <aaggarwa@qce.qualcomm.com> wrote:
>> 
>> Thanks for your comments. Please see below:
>> 
>> -----Original Message-----
>> From: dnssd [mailto:dnssd-bounces@ietf.org] On Behalf Of Tom Pusateri
>> Sent: Thursday, July 24, 2014 11:10 AM
>> To: dnssd@ietf.org
>> Subject: [dnssd] draft-aggarwal-dnssd-optimize-query-00
>> 
>> 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?
>> 
>> [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. 
>> 
> 
> 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
> 
>> 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.
>> 
>> 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.
>> 
>> [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
>> dnssd@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnssd
>> 
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnssd
> 