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

Ralph Droms <> Fri, 14 April 2017 11:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 299E812EB7F for <>; Fri, 14 Apr 2017 04:56:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I7fBVq8KzzA6 for <>; Fri, 14 Apr 2017 04:56:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 989EF12EB9D for <>; Fri, 14 Apr 2017 04:56:28 -0700 (PDT)
Received: by with SMTP id f133so66768608qke.2 for <>; Fri, 14 Apr 2017 04:56:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Zhg4moD/Sz+tihniwTxQCeKAA/3dpnVWp8V4xJ2F94Q=; b=gI5EMFGOEpNlzDzyINqhjT0uqEZNGlL5FmDYHiJkGXBt4yNfKzsZqlMOeknRDeA/fl Fq6YHF+mYHlfl4+ddwQSDvi5xBTg3VVLsUqIJ0/WndG8rhhhTVvHx0gfnuVIsN5dv+yY FYt/tGbA2fIeSSJMOBY6hu+55MtVEUdaRpEYifYXx5sd2ci3X0lZWhIITpeJ9wK3pl6f YN3q2JNr6daIWO7fm4+LMZjFt6D2tTrKKraca58Sh6e+EEsxapzxZpxIqa+DG+lfi2a9 7PnI3S85Nm9ipOrY2rR3MOSxx9ZVGNVxjc6RnRM02TzUvAtUQMpazTyct7yWcrZFSNdB JB5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Zhg4moD/Sz+tihniwTxQCeKAA/3dpnVWp8V4xJ2F94Q=; b=r+B6ojxxisecOeaKFVCU2r+TXrug+D1VN+1wMqLhC3hJ1INHJQRGR8w3+bGeGw54tT UEEECcuLU4w3pTyRZslBXRNWQcjnUDRcgimVKoRfp8Q8/PTaEpe9k2SdnGkRuxXWf9Ip wuWYkf6UtiW037ap0+aZ3r+k0yt/2Q/EWI/rhkRnPfE0rW3kJHtkEB1vKYN18SiLYbw7 viXPTY4+3ofXmQcha4u4M5m6Mrcs+xIclWM0fr/4tRI+J0n9YHLMfF8VkZY7//P3TeJC Lxtz1xVtQG9T7JUXZpMATieDV2TH7bTD+O3EXXypVx7DUeeJVBcFQSBJ6U4294dIz+hu DJ4A==
X-Gm-Message-State: AN3rC/6YKcyu1AHsZLIX2mC8vwTPOW36A+UeufdlU5xtB+1fRrAXcscB w2ZC6MmK6ONIgKMh0CE=
X-Received: by with SMTP id h65mr7350692qkc.302.1492170987795; Fri, 14 Apr 2017 04:56:27 -0700 (PDT)
Received: from ?IPv6:2601:18f:801:600:c4a8:6e8:c7e7:abee? ([2601:18f:801:600:c4a8:6e8:c7e7:abee]) by with ESMTPSA id 94sm1101216qte.37.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 04:56:27 -0700 (PDT)
From: Ralph Droms <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_14B63A0A-44DF-4127-BBDA-0E9AD02713B7"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 14 Apr 2017 07:56:25 -0400
In-Reply-To: <>
Cc: "" <>
To: Tom Pusateri <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-push-10 (extended to 14th April)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Apr 2017 11:56:33 -0000

> On Apr 13, 2017, at 9:05 PM, Tom Pusateri <> wrote:
>> On Apr 13, 2017, at 12:26 PM, Ralph Droms <> 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
> <>. may return an SOA record named <>. in the
>   Authority section if there is no SOA record named
> <>. 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, the SOA record in the Authority section would be  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 <> 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 <> wrote:
>>>> Dear dnssd WG participants,
>>>> We are initiating a WG Last Call today on draft-ietf-dnssd-push-10, which you can find at
>>>> 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 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 mailing list
>> <>
>> <>