Subject: [sipcore] draft-ietf-sipcore-dns-dual-stack-03

From: [email-masked] (Dale R. Worley)
Date: Mon, 01 Feb 2016 14:35:09 -0500

I've done an edit of draft-ietf-sipcore-dns-dual-stack and submitted it
as the -03.  The notification for the new version will be out as soon as
one of the old authors confirms it.  It doesn't seem to me that any of
the changes are controversial, but nonetheless, please take a careful
look at it, as I think we're close to WGLC for the draft.

In particular:

- The text emphasizes that this draft does not implement Happy Eyeballs
  for SIP, but rather does necessary preparation for that.

- The draft is not marked as updating 3263, but I believe that we will
  have to do that, as we really are updating 3263.

- I've copied the term "address records" from RFC 2782 (SRV records),
  because that term covers all records that provide addresses for any
  address families supported by the device.  Thus, the term "address
  records" automatically extends to any new address family that is
  defined.

- It's not obvious to the casual reader how the two revision points in
  section 4.1 fit into the overall 3263 resolution process.  In fact,
  after any NAPTR processing, resolution branches into 4 cases:
  . explicit address, 
  . domain name with port number,
  . domain name without port number and without SRV records,
  . domain name without port number and with SRV records.
  Case 4 is delegated to 2782, which *already* requires looking up both
  A and AAAA records.  Cases 2 and 3 are handled in 3263 directly, and
  are the two items which are being updated.

- I've revised the wording regarding how 3263 interacts with 6157.  I
  believe that the new wording expresses what was intended, but people
  should check me on this.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 12 Feb 2016 14:57:59 -0500

I propose modifying draft-ietf-sipcore-dns-dual-stack-03 to correct its
statement of the RFCs that it is updating.

>   have to do that, as we really are updating 3263.

I think this draft really does update 3263, and it should say so.  The
only alternative is to argue that the draft is stating what everybody
understood 3263 to mean already, and I don't think that is the case.

>   believe that the new wording expresses what was intended, but people

On the other hand, I think that this draft doesn't modify how 6157.  It
seems to me that the only sensible meaning of the text of 3263 in the
light of 6157 is how this draft explains it:

   This document clarifies the process: If SRV lookup is successful, the
   major ordering of the list of destination addresses is determined by
   the priority and weight fields of the SRV records as specified in
   [RFC2782].  The (minor) ordering among the destinations derived from
   the "target" field of a single SRV record is determined by [RFC6724].

However, I could be convinced otherwise.

Dale

---

From: Simon Perreault <[email-masked]>
Date: Fri, 12 Feb 2016 15:13:51 -0500

+1

Le 2016-02-12 14:57, Dale R. Worley a écrit :
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 12 Feb 2016 21:55:23 +0100

> On 12 Feb 2016, at 20:57, Dale R. Worley <[email-masked]> wrote:
> 

I agree.

/O

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 17 Feb 2016 14:37:45 -0500

> statement of the RFCs that it is updating.

I've done these updates.  The results are accessible at these URLs:

https://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-04.{xml,txt,html}

(Actually, those URLs are the current draft of -04, and the contents
will change with time.)

Dale