RFC 6157 actually updates RFC 3263 too - dual stack DNS lookups

[Olle E. Johansson]

Hi!

I notice that RFC 6157 updates RFC 3264, but does not mention changes to RFC 3263.

RFC 3263 - locating SIP servers - repeatedly says: "the client performs an A or AAAA record lookup of the domainvname". Note the "or"


RFC 6157, section 3.1 says:

Furthermore, there SHOULD
exist both IPv6 and IPv4 DNS entries for outbound proxy servers.
This allows the user agent to query DNS and obtain an IP address most
appropriate for its use (i.e., an IPv4-only user agent will query DNS
for A resource records (RRs), an IPv6-only user agent will query DNS
for AAAA RRs, and a dual-stack user agent will query DNS for all RRs
and choose a specific network.)



The clause about a dual-stack user agent clearly doesn't follow RFC 3263, since it implies "and" instead of "or". There's no MUST, SHOULD or MAY language applied here, so it seems like this is an oversight - not that RFC 6157 is wrong, but that there should have been a more clear update to RFC 3263.

Nitpicking, but I think it's important to clarify the DNS functionality in regards to dual stacks. In addition, I think there's a need for a BCP to explain how a domain can indicate
preference of address family - ipv4 or ipv6 - by using SRV entries.

/O

[Iñaki Baz Castillo]

Post by Olle E. Johansson
The clause about a dual-stack user agent clearly doesn't follow RFC 3263,
since it implies "and" instead of "or". There's no MUST, SHOULD or MAY
language applied here, so it seems like this is an oversight - not that RFC
6157 is wrong, but that there should have been a more clear update to RFC
3263.
Nitpicking, but I think it's important to clarify the DNS functionality in
regards to dual stacks. In addition, I think there's a need for a BCP to
explain how a domain can indicate
preference of address family - ipv4 or ipv6 - by using SRV entries.

I expect that any vendor implementing SIP over IPv4 and IPv6 should
also implement DNS A and AAAA. But I agree that there should be a
mention to it somewhere in a RFC (not a "or" but an "and").

[Vijay K. Gurbani]

Post by Olle E. Johansson
The clause about a dual-stack user agent clearly doesn't follow RFC
3263, since it implies "and" instead of "or". There's no MUST, SHOULD
or MAY language applied here, so it seems like this is an oversight -
not that RFC 6157 is wrong, but that there should have been a more
clear update to RFC 3263.

Interesting reading of the tea leaves.

One thing you may want to do is to file an errata (see "How to Report
Errata" at http://www.rfc-editor.org/how_to_report.html).

Then, the authors and any verifying parties will deliberate on whether
or not this is indeed an errata. This appears to work for errata in
text, but your claim is that rfc6157 should have updated rfc3263 as
well, so the change is in the masthead of rfc6157 and not in the text
itself.

I suspect that a decision will be made on what to do after an errata
is filed ...

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / ***@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Olle E. Johansson]

Post by Vijay K. Gurbani

Post by Olle E. Johansson
The clause about a dual-stack user agent clearly doesn't follow RFC
3263, since it implies "and" instead of "or". There's no MUST, SHOULD
or MAY language applied here, so it seems like this is an oversight -
not that RFC 6157 is wrong, but that there should have been a more
clear update to RFC 3263.

Interesting reading of the tea leaves.

Just noted that MSRP has the same issue. Growing to a tea bush :-)

Post by Vijay K. Gurbani
One thing you may want to do is to file an errata (see "How to Report
Errata" at http://www.rfc-editor.org/how_to_report.html).
Then, the authors and any verifying parties will deliberate on whether
or not this is indeed an errata. This appears to work for errata in
text, but your claim is that rfc6157 should have updated rfc3263 as
well, so the change is in the masthead of rfc6157 and not in the text
itself.
I suspect that a decision will be made on what to do after an errata
is filed ...

Ok, will do.

/O

_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP