Last Call Review of draft-ietf-sipcore-dns-dual-stack-04
review-ietf-sipcore-dns-dual-stack-04-opsdir-lc-winter-2016-07-11-00

Hello,

 

I have reviewed draft-ietf-sipcore-dns-dual-stack-06 as part of the
Operational directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written with the
intent of improving the operational aspects of the IETF drafts. Comments
that are not addressed in last call may be included in AD reviews during
the IESG review.  Document editors and WG chairs should treat these
comments just like any other last call comments.

Section 3.1 is contradictory:
===========
"[...] The dual-stack client SHOULD look up all address records (i.e.,
for all address family(ies) that it supports) [...]"

vs.

"[...] A client MUST be prepared for DNS lookups to return addresses in
families that it does not support; [...]"

If it only looks up families it does support, then it will never get
responses for a family it does not support.

Section 3.2
===========
There is a  suggestion to use SRV records which point to hostnames which
resolve only on one address family. Note that RFC6555 discourages the
use of distinct per-family hostnames in its section 3.1.

Since this particular per-family distinction does not reach humans and
resolves automatically, it is probably okay do (ab)use the SRV mechanism
for that family preference signalling. Just wondering if that fact
should maybe be acknowledged in this section.

Also, RFC6555 always speaks of preference being indicated by the
*client* (either on the application layer or the OS). This draft's move
towards allowing the *server* to indicate its own preference is a whole
different story. This may be a good idea, but it has little, if not
nothing to do with RFC6555.

Section 4
=========
This is basically a recap of the current facts of life regarding SRV
lookup and multiple targets. That may be appropriate to do, but I wonder
if that section could do /more/: RFC6555 already has text which suggests
that the first preferred-family entry is tried first, but if that
connection fails to come up quick enough, the first not-preferred-family
entry is tried next.

So, if you are following RFC6555, this section 4 could mandate that in
lists like this one, the first IPv6 address is tried first, and then the
first IPv4 address. In the concrete example:

1) try 2001:0db8:58:c02::face
2) try 192.0.2.45
3) try remainder of addresses (order not important)

This would mirror the behaviour described in RFC6555's section 5.4.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me



http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66





Attachment:


0x8A39DC66.asc




Description:

 application/pgp-keys




Attachment:


signature.asc




Description:

 OpenPGP digital signature