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

From: Tim Chown <[email-masked]>
Date: Thu, 6 Apr 2017 08:59:29 +0000

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 <[email-masked]> 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 [email-masked] 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
> 
>

---

From: Ralph Droms <[email-masked]>
Date: Thu, 13 Apr 2017 18:26:38 -0400

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."

Minor editorial nit:

In the "NOTE:" at the end of section 6.2.1, s/were/where/

- Ralph

> On Apr 6, 2017, at 4:59 AM, Tim Chown <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 13 Apr 2017 15:05:15 -1000

> On Apr 13, 2017, at 12:26 PM, Ralph Droms <[email-masked]> wrote:
> 
> 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. may return an SOA record named apple.com. in the
   Authority section if there is no SOA record named
   _ftp._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.

> In the "NOTE:" at the end of section 6.2.1, s/were/where/

Fixed.

Thanks,
Tom

---

From: Ralph Droms <[email-masked]>
Date: Fri, 14 Apr 2017 07:56:25 -0400

> On Apr 13, 2017, at 9:05 PM, Tom Pusateri <[email-masked]> wrote:
> 
>> 
>   _ftp._tcp.apple.com <http://tcp.apple.com/>. may return an SOA record named apple.com <http://apple.com/>. in the
>   _ftp._tcp.apple.com <http://tcp.apple.com/>. If, in this case, the server does not include

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

>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>

---

From: Sara Dickinson <[email-masked]>
Date: Fri, 14 Apr 2017 18:05:14 +0100

HI All, 

This draft looks in very good shape to me. I have a couple of minor comments:

- I think there could be a reference to RFC7858 at the end of the second paragraph in Section 4.

- Section 6.4.1 discusses clients having 2 messages in flight with the same MESSAGE ID (SUBSCRIBE and UNSUBSCRIBE). This is a valid use case in this context but it does conflict with the statement in RFC7766 “When sending multiple queries over a TCP connection, clients MUST NOT reuse the DNS Message ID of an in-flight query on that connection in order to avoid Message ID collisions. “. I think it would be helpful to point out this exception and in fact I think that means this draft technically updates RFC7766?

- Section 7 - I think it would help if there was a reference to draft-ietf-dprive-dtls-and-tls-profiles - the discussion of server authentication here overlaps with that draft. Also a reference to  section 9 of draft-ietf-dprive-dtls-and-tls-profiles could be used instead of sections 7.3 and 7.4 as that document already makes recommendations about following RFC7525, TLS Session resumption and similar. 

Sara. 

> On 6 Apr 2017, at 09:59, Tim Chown <[email-masked]> wrote:
> 
> Hi,
>

---

From: Ralph Droms <[email-masked]>
Date: Fri, 14 Apr 2017 15:04:08 -0400

Thanks for your review, Sara.

Everyone - we have still received only minimal response to the WG last call, and we really need more support for consensus to progress the draft to the IESG.  Please review the document and respond to the mailing list - even a simple "I've read the draft and it's ready to go to the IESG" is helpful.

- Ralph

> On Apr 14, 2017, at 1:05 PM, Sara Dickinson <[email-masked]> wrote:
> 
> HI All, 
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Apr 2017 16:40:30 -0400

On Apr 14, 2017, at 3:04 PM, Ralph Droms <[email-masked]> wrote:
> Everyone - we have still received only minimal response to the WG last call, and we really need more support for consensus to progress the draft to the IESG.

I don't get that.   The working group agreed to adopt the work, the work was done, it's been reviewed, I've never understood why at this point in the process we need a show of hands to say "yes, publish it."   Nevertheless, FWIW, yes, publish it.

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 14 Apr 2017 17:14:23 -1000

Thanks for the review Sara.

The last paragraph of section 6.4.1 needs to be removed. It was left over from previous versions where the message id was 0. We now expect SUBSCRIBE and UNSUBSCRIBE requests (even overlapping ones) to have unique message IDs and will fully conform with RFC 7766.

I’ll add the appropriate references to the profiles draft.

Tom

> On Apr 14, 2017, at 7:05 AM, Sara Dickinson <[email-masked]> wrote:
> 
> HI All, 
>

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 16 Apr 2017 14:52:40 +0000

Hi,

This review is late.  It has been an interesting couple of weeks
learning how the new corporate masters do things.  Many apologies for
being late.  If this is too late to be useful, I apologise for that
too.

I hadn't looked carefully at this document in some time.  It's in good
shape.  There are a few nits below that could use addressing, but none
are AFACIT fatal.  In general, I like this document and I've been
looking forward to its publication; it should be published.

The review text below is a little telegraphic in style because I was
running out of battery.

In section 3 there's a reference to RFC 1996.  I wonder whether RFC
7719 might be better, since it appears to be about the terms.

What should a server do if it gets a query over the open TCP
connection with the RD bit set?  What about for a zone outside the
server's bailiwick?  REFUSED?  (In general, there are a bunch of
requirements that create error conditions, where it isn't clear what
the right answer is.  These are perhaps answered in the tables of
RCODEs later, but if so a forward reference would be better.)

SRV records are discussed here but mystifying until you get to 6.1.
Maybe a forward reference?

Classes are included but implementations are permitted not to support
them.  What do you do if you get a query for a class you don't
support?  This seems strange.  (It is possible to leave classes other
than IN undefined, though it seems sticky.  I tried to get DNSOP to
deprecate classes, but I got pushback.)

"DNS Push Notification clients MUST NOT recklessly create an
excessive" I don't know what MUST NOT means there; I think it's
guidance, not protocol spec.  (In general, throughout the draft there
are uses of 2119 language that don't really create protocol rules, so
that might be revisited).

In section 6,

   DNS Push Notification clients and servers MUST support DNS Session
   Signaling, but the server MUST NOT issue any DNS Session Signaling
   operations until after the client has first initiated a DNS Session
   Signaling operation of its own.

Why MUST NOT?  Session signalling only says SHOULD NOT.  I can imagine
a server in a network that is closely managed having the ability to be
certain of what all the clients can do (or, what's the same, not
caring because such clients shoukdn't be there).

I think what item 2 of 6.1 is saying is that you need a NOERROR/NODATA
response with an SOA in the authority section (it's intially a little
confusing, because it seems like you have to put the SOA of the
non-existent zone in the authority, but that doesn't make any sense so
that couldn't be it :).  Maybe a reference to RFC 2308 would be
helpful?

In step 3, does that mean "no SOA in the response message at all, in
any section"?  There sometimes appears to be an ambiguity in what
people mean by "returned" for a DNS query -- it often means the Answer
section, and in that interpretation step 3 would cause an extra
unneeded query, which I'm sure isn't the goal.

In step 5, I'm a little leery of the MUST NOT exist.  Since there's no
way to constrain what people might put in their zones if they don't
implement this specification, that's not really a rule one can make.
Maybe, "For implemneters of this specification, an authoritative
answer for that SRV record, and only such an answer, will determine
whether the zone supports DNS Push Notifications"?  The point is that
you can't control whether a non-implemnter will put such an SRV in a
zone, but you can say what an implementation of this spec will do.

   Each time a client makes a new DNS Push Notification subscription
   connection, it SHOULD repeat the discovery process in order to
   determine the preferred DNS server for subscriptions at that time.

and the following paragraph is a little surprising, because couldn't
you subscribe to the SRV record itself and thereby get notified when a
zone's rules change?  Anyway, if you're going to query for the same
SOA again within the TTL window, you're likely to tickle RRL.  Why
can't you use the cached SOA and SRV record for the length of the TTL?

In 6.2, what should happen if a server does issue a Subscribe request?
Ignore it?

In 6.2.1, do all errors result in TCP RST or just the duplicate
queries?  (Apparently not given 6.2.2.)  Why is this required?  Why
not just ignore the request?

The CNAME handling is a little strange.  CNAME is defined as canonical
name, so formally it means that the owner name just _is_ the target.
I think what is meant here, however, is that a CNAME in the query is
interpreted as matching the CNAME record itself, and on the server
side the CNAME expansion is not performed.  Right?  (This comes up
again later.)

The discussion of ALL vs ANY here is a little surprising to me.  It
seems to me that the semantics in this case are the same, because you
can only get these notifications from a server that is authoritative,
no?  ANY in that case does effectively mean ALL, but that's an
accident.  I'm leery of this document making the QTYPE=255 semantics
even more convoluted than they already are.

In 6.2.2 I'm a little worried about the use of SERVFAIL here.  It
appears to be somewhat at odds with the regular meaning of this
response code.

In 6.4, if a client gets an UNSUBSCRIBE request from a server, what
should it do?

Again, I don't think any of these are fatal, but if they could be
cleaned up it might make the document more useful.

Best regards,

A

---

From: "Jan Komissar (jkomissa)" <[email-masked]>
Date: Mon, 17 Apr 2017 13:04:39 +0000

Hi Tom,

Does this mean that a client may not unsubscribe a subscription until it has received the response to the subscription request? You may want to clarify that in section 6.4.1 paragraph 4, which explicitly allows an unsubscribe before the subscribe is acknowledged, effectively allowing two messages in flight with the same id at the same time. (Or has there been a protocol change that I missed?)

Regards,

Jan.

On 4/14/17, 11:14 PM, "dnssd on behalf of Tom Pusateri" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    Tom

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 17 Apr 2017 08:12:41 -1000

Sorry, Stuart changed this on me. The UNSUBSCRIBE used to contain the record name and type like the subscribe. I was still thinking that it did. I think this is the better approach and will discuss with Stuart. Then you can have unique IDs.

Thanks,
Tom

> On Apr 17, 2017, at 3:04 AM, Jan Komissar (jkomissa) <[email-masked]> wrote:
> 
> Hi Tom,
>

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 17 Apr 2017 08:24:05 -1000

Alternatively, the UNSUBSCRIBE TLV could contain the SUBSCRIBE ID as SSOP-DATA and still have it’s own unique message ID.

Tom

> On Apr 17, 2017, at 8:12 AM, Tom Pusateri <[email-masked]> wrote:
>

---

From: "Jan Komissar (jkomissa)" <[email-masked]>
Date: Mon, 17 Apr 2017 20:26:08 +0000

Hi Tom,

That sounds better.

And yes for WG adoption.

Regards,

Jan.

On 4/17/17, 2:24 PM, "Tom Pusateri" <[email-masked]> wrote:

    Tom