Subject: Re: [sipcore] WGLC: draft-ietf-sip-dual-stack

From: [email-masked] (Dale R. Worley)
Date: Wed, 06 Apr 2016 16:42:36 -0400

I suspect the problem is that everyone agrees on both (1) what is the
desired behavior and (2) that the existing RFCs specify that behavior.
The goal of section 5 is to point out the complexities involved and make
sure that readers are aware of what the correct behavior is, but the
fact that the text makes no normative changes makes it more difficult to
describe what behaviors are excluded.

I've rewritten the section based on y'all's e-mails, and particularly
the example Adam provided:

   5.  Clarification of RFC 6157

   Section 5 of [RFC6157] specifies that the addresses from the address
   records for a single target DNS name for a server's DNS name must be
   contacted in the order specified by the Source and Destination
   Address Selection algorithms defined in [RFC6724] (the successor of
   [RFC3484]).  Typically, this is done by using the getaddrinfo()
   function to translate the target DNS name into a list of IPv4 and/or
   IPv6 addresses in the order in which they are to be contacted, as
   that function implements [RFC6724].

   Thus, if SRV lookup on the server's DNS name is successful, the major
   ordering of the complete list of destination addresses is determined
   by the priority and weight fields of the SRV records (as specified in
   [RFC2782]) and the (minor) ordering among the destinations derived
   from the "target" field of a single SRV record is determined by
   [RFC6724].

   For example, consider a server with DNS name example.com, with TCP
   transport specified.  The relevant SRV records are:

      _sip._tcp.example.com.  300 IN SRV 10 1 5060 sip-1.example.com.
      _sip._tcp.example.com.  300 IN SRV 20 1 5060 sip-2.example.com.

   The address records for sip-1.example.com, as ordered by [RFC6724],
   are

      sip-1.example.com.  300 IN AAAA 2001:0db8:58:c02::face
      sip-1.example.com.  300 IN AAAA 2001:0db8:c:a06::2:cafe
      sip-1.example.com.  300 IN AAAA 2001:0db8:44:204::d1ce
      sip-1.example.com.  300 IN A 192.0.2.45
      sip-1.example.com.  300 IN A 203.0.113.109
      sip-1.example.com.  300 IN A 198.51.100.24

   and the address records for sip-2.example.com, as ordered by
   [RFC6724], are:

      sip-2.example.com.  300 IN AAAA 2001:0db8:58:c02::dead
      sip-2.example.com.  300 IN AAAA 2001:0db8:c:a06::2:beef
      sip-2.example.com.  300 IN AAAA 2001:0db8:44:204::c0de
      sip-2.example.com.  300 IN A 192.0.2.75
      sip-2.example.com.  300 IN A 203.0.113.38
      sip-2.example.com.  300 IN A 198.51.100.140

   Thus, the complete list of destination addresses has this ordering:

      2001:0db8:58:c02::face
      2001:0db8:c:a06::2:cafe
      2001:0db8:44:204::d1ce
      192.0.2.45
      203.0.113.109
      198.51.100.24
      2001:0db8:58:c02::dead
      2001:0db8:c:a06::2:beef
      2001:0db8:44:204::c0de
      192.0.2.75
      203.0.113.38
      198.51.100.140

   In particular, the destination addresses derived from sip-
   1.example.com and those derived from sip-2.example.com are not
   interleaved; [RFC6724] does not operate on the complete list.  This
   would be true even if the two SRV records had the same priority and
   were (randomly) ordered based on their weights, as the address
   records of two target DNS names are never interleaved.

What do people think of that?

Dale

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Fri, 8 Apr 2016 20:33:34 +0000

This updated text works for me and the example really helps provide additional clarity and sheds light on practical usage/implementation of draft.  

At this point my concerns are addressed and am satisfied with the state of the draft.  Thanks, Dale.

Cheers,

Gonzalo

> On Apr 6, 2016, at 4:42 PM, Dale R. Worley <[email-masked]> wrote:
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore