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

[[e-mail] (Dale R. Worley)]

"Mirja Kuehlewind" <[e-mail]> writes:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks! This seems very useful in the preparation for Happy-Eyeballs.

Thanks!

> 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?

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

> And related to this question: Shouldn't it be named "multi-stack 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