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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi,

thanks for your reply! See below.


> Am 19.08.2016 um 20:37 schrieb Dale R. Worley <[e-mail]>:
> 
> "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“.

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?


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

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


> 
> Dale
>