Re: [dnssd] WGLC on draft-ietf-dnssd-push-10 (extended to 14th April)

> On Apr 13, 2017, at 9:05 PM, Tom Pusateri <pusateri@bangj.com> wrote:
> 
>> 
>> On Apr 13, 2017, at 12:26 PM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
>> 
>> I think draft-ietf-dnssd-push-10  is ready to be forwarded to the IESG, after the following comment is addressed:
>> 
>> I found the second item in the list in section 6.1 confusing:
>> 
>> 6.1.  Discovery
>> 
>>  The first step in DNS Push Notification subscription is to discover
>>  an appropriate DNS server that supports DNS Push Notifications for
>>  the desired zone.  The client MUST also determine which TCP port on
>>  the server is listening for connections, which need not be (and often
>>  is not) the typical TCP port 53 used for conventional DNS, or TCP
>>  port 853 used for DNS over TLS [RFC7858].
>> 
>>  1.  The client begins the discovery by sending a DNS query to its
>>      local resolver, with record type SOA [RFC1035], for the domain
>>      name to which it wishes to subscribe.
>> 
>>  2.  If the SOA record exists, it MUST be returned in the Answer
>>      Section of the response.  If not, the local resolver SHOULD
>>      include the SOA record for the zone of the requested name in the
>>      Authority Section.
>> 
>> The second sentence seems self-contradictory: "If the SOA record doesn't exist, include the SOA record in the Authority Section.”
>> 
> 
> It’s not contradictory but could be worded better.
> 
> From the LLQ draft:
> 
>   The client begins by sending a standard DNS query for the name of the
>   LLQ, with type SOA. The server MUST answer with that SOA record in
>   the Answer section, if the record exists. The server SHOULD include
>   an SOA record for that name's zone in the Authority section, if the
>   LLQ name (type SOA) does not exist. For example, a query for
>   _ftp._tcp.apple.com <http://tcp.apple.com/>. may return an SOA record named apple.com <http://apple.com/>. in the
>   Authority section if there is no SOA record named
>   _ftp._tcp.apple.com <http://tcp.apple.com/>. If, in this case, the server does not include
>   the SOA record in the Authority section, the client strips the
>   leading label from the name and tries again, repeating until an
>   answer is received.
> 
> We can make this more clear.

Got it.  One change that would clarify the example from the LLQ draft (at least clarify for me) would be to use an initial request for which the zone is not simply the original FQDN with the service specifiers stripped off.  E.g.: for the query _ftp._tcp.bldg1.apple.com, the SOA record in the Authority section would be apple.com.  This SOA record would result in a different query in the next step, rather than simply re-issuing the same request.

- Ralph

> 
>> Minor editorial nit:
>> 
>> In the "NOTE:" at the end of section 6.2.1, s/were/where/
> 
> Fixed.
> 
> Thanks,
> Tom
> 
> 
>> 
>> - Ralph
>> 
>>> On Apr 6, 2017, at 4:59 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
>>> 
>>> Hi,
>>> 
>>> We have had no comments on this WGLC.
>>> 
>>> In order to progress the draft to our AD/IESG we need some positive expressions of support; please do try to find some time to read and comment on the document.
>>> 
>>> We’ll extend the WGLC until next Friday, 14th April, given we are also waiting on a WGLC for the DNS session signalling draft used by DNS Push.
>>> 
>>> Many thanks,
>>> Tim & Ralph
>>> 
>>>> On 21 Mar 2017, at 11:24, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
>>>> 
>>>> Dear dnssd WG participants,
>>>> 
>>>> We are initiating a WG Last Call today on draft-ietf-dnssd-push-10, which you can find at https://tools.ietf.org/html/draft-ietf-dnssd-push-10
>>>> 
>>>> The call runs for two weeks, and will thus close on Tuesday 4th April.
>>>> 
>>>> Please send any comments, which includes indications of support for progression of the document as is, to the dnssd@ietf.org list.  Such statements of support are important; this draft will not be advanced for publication unless there is sufficient response and support from the WG.  
>>>> 
>>>> There will be a brief opportunity to also make comments in the dnssd WG meeting in Chicago next week, but the chairs would appreciate a record of comments to the list.
>>>> 
>>>> We are expecting the associated DNS session signalling draft to also go through WGLC in the dnsop WG in the next couple of weeks, with the aim of both documents being published together.
>>>> 
>>>> The DNS-SD Discovery Proxy (formerly the DNS-SD Hybrid Proxy), which Stuart has updated to reflect the new nomenclature, will be sent to the IESG once the shepherd write-up is completed.
>>>> 
>>>> Best wishes,
>>>> 
>>>> Ralph and Tim
>>>> dnssd WG co-chairs
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> dnssd mailing list
>>> dnssd@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnssd
>> 
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org <mailto:dnssd@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>