Subject: [sipcore] Mirja Kühlewind's Yes on draft-ietf-sipcore-dns-dual-stack-07: (with COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Mon, 15 Aug 2016 06:16:32 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-sipcore-dns-dual-stack-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks! This seems very useful in the preparation for Happy-Eyeballs.

One question: Why does a client need to look up ALL addresses if it
already knows that it itself only support one specific address familiy?

And related to this question: Shouldn't it be named "multi-stack client"
instead of "dual-stack client"?

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 19 Aug 2016 14:37:44 -0400

Thanks!

> already knows that it itself only support one specific address familiy?

The draft refers to "all address" families in this part of section 3.1:

      The dual-stack client SHOULD look up all address records (i.e.,
      for all address family(ies) that it supports) for the domain name
      and add the resulting addresses to the list of IP addresses to be
      contacted.

In this context, we clarify that "all address records" means "[address
records] for all address family(ies) that [the device] supports".

There is also this usage in section 3.2:

   Such special-purpose hostnames SHOULD be used only as described in
   this section, as targets of SRV records for an aggregate host name,
   where the aggregate host name ultimately resolves to addresses in all
   families supported by the client.

Here the primary text qualifies "all families" with "supported by the
client".

> instead of "dual-stack client"?

Strictly speaking, "multi-stack client" is more robust against the
possibility that a third address family is introduced.  However, the
term "dual-stack" is what has been used in all of the discussions
regarding the transition to using IPv6, so we have continued its use in
this draft in the narrative portions.  OTOH, all of the normative text
is written to operate correctly even if further address families are
introduced.

Dale

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 19 Aug 2016 20:51:16 +0200

Hi,

thanks for your reply! See below.

> Am 19.08.2016 um 20:37 schrieb Dale R. Worley <[email-masked]>:
> 
> client“.

Okay. I think I was confused by the ‚i.e.‘ together with the second sentence here:

      The dual-stack client SHOULD look up all address records (i.e.,
      for all address family(ies) that it supports) for the domain name
      and add the resulting addresses to the list of IP addresses to be
      contacted.  A client MUST be prepared for the existence of DNS
      resource records containing addresses in families that it does not
      support; if such records may be returned by the client's DNS
      queries, such records MUST be ignored as unusable and the
      supported addresses used as specified herein.

Reading it again with your clarification I not sure why I misunderstood in the first place. So probably no clarification needed; or maybe just remove the ‚i.e.‘ and the brackets..?

One more question: getting an record returned for an address family that was not requested is an error case, right? Or can this actual happen in ‚normal‘ operation?

> is written to operate correctly even if further address families are

I noticed that the whole doc is written in a way that would correctly operate with new address families. That's we I suggested this change. I think that this term would be as easily understandable as the current dual-stack term. But I don’t have a strong opinion, so please just use what you think is better.

Mirja

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 22 Aug 2016 15:32:31 -0400

"Mirja Kuehlewind (IETF)" <[email-masked]> writes:
> Reading it again with your clarification I not sure why I
> misunderstood in the first place. So probably no clarification needed;
> or maybe just remove the ‚i.e.‘ and the brackets..?

Reading it again, the text can be simplified by replacing "all address
records (i.e., for all address family(ies) that it supports)" with
"address records for all address families that it supports".  So I've
made that change.

> One more question: getting an record returned for an address family
> that was not requested is an error case, right? Or can this actual
> happen in ‚normal‘ operation?

It depends on what DNS requests are used.  E.g., if the client does an
ANY request, then it will get both A and AAAA records for the domain
name.  But if there is a new address family, it might receive other
records, and the client must be prepared to ignore them.

> I noticed that the whole doc is written in a way that would correctly
> operate with new address families. That's we I suggested this
> change. I think that this term would be as easily understandable as
> the current dual-stack term. But I don’t have a strong opinion, so
> please just use what you think is better.

I'll ask my coauthors what they think.  They've been working on this
text longer than I have and know its background better.

I've updated the draft -08.  You can see the differences in
https://www.ietf.org/rfcdiff?url1=draft-ietf-sipcore-dns-dual-stack-07&url2=http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-08.txt
and the entire current draft in
http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-08.{txt,html}

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 24 Aug 2016 14:33:36 -0400

> please just use what you think is better.

We've kept the term "dual-stack" because that's what's been used in all
the Happy Eyeballs-related discussions, but we've revised the
Terminology section to make it clear that "dual-stack" includes any
situation "where the client has access to multiple communication methods
that have distinct addressing characteristics".

I've updated the draft -08.  You can see the differences in
https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-sipcore-dns-dual-stack-07&ur=
l2=3Dhttp://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-d=
ns-dual-stack-08.txt
and the entire current draft in
http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-du=
al-stack-08.{txt,html}

Dale