headers
Olle E. Johansson | 3 Oct 2011 19:58
Gravatar

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

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

 



_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 3 comments |
headers
Iñaki Baz Castillo | 3 Oct 2011 22:34
Gravatar

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

2011/10/3 Olle E. Johansson <oej <at> edvina.net>:
> 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").

--

-- 
Iñaki Baz Castillo
<ibc <at> aliax.net>
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 2 comments |
headers
Vijay K. Gurbani | 5 Oct 2011 16:04
Favicon

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

On 2011/10/3 Olle E. Johansson<oej <at> edvina.net> wrote:
> 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 <at> {bell-labs.com,acm.org} / vijay.gurbani <at> 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-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 1 comment |
headers
Olle E. Johansson | 8 Oct 2011 13:44
Gravatar

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


5 okt 2011 kl. 16:04 skrev Vijay K. Gurbani:

> On 2011/10/3 Olle E. Johansson<oej <at> edvina.net> wrote:
>> 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 :-)

> 
> 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-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 0 comments |
headers
RFC Errata System | 10 Oct 2011 20:47
Favicon

[Editorial Errata Reported] RFC6157 (2987)


The following errata report has been submitted for RFC6157,
"IPv6 Transition in the Session Initiation Protocol (SIP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6157&eid=2987

--------------------------------------
Type: Editorial
Reported by: Olle E. Johansson <oej <at> edvina.net>

Section: 3.1

Original Text
-------------
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.)

Corrected Text
--------------
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.) This is an update to RFC 3263, in which
the client on a dual stack network queries for either A or AAAA.

Notes
-----
The RFC actually updates RFC 3263 - locating SIP servers - but doesn't make a clear note about it.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6157 (draft-ietf-sipping-v6-transition-07)
--------------------------------------
Title               : IPv6 Transition in the Session Initiation Protocol (SIP)
Publication Date    : April 2011
Author(s)           : G. Camarillo, K. El Malki, V. Gurbani
Category            : PROPOSED STANDARD
Source              : Session Initiation Proposal Investigation
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 0 comments |
headers
Olle E. Johansson | 10 Oct 2011 22:05
Gravatar

SIP certificate management (RFC 6072) and SIP outbound

After reading RFC 6072 I can't help to wonder how this works with an outbound proxy configured in the UA.

For instance, using SIP Outbound we have two proxys that we keep an active flow to. RFC 6072 says that
the UA is required to have a direct connection to the certificate service in order to publish a key and certificate.
This is in order to be able to examine the servers certificate. 

Does this mean that a UA that follows RFC 6072 should override the pre-defined route in the UA and thus
also ignore the SIP outbound mechanism for this transaction? 

/O
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 1 comment |
headers
Cullen Jennings | 11 Oct 2011 01:32
Picon
Favicon
Gravatar

Re: SIP certificate management (RFC 6072) and SIP outbound


On Oct 10, 2011, at 2:05 PM, Olle E. Johansson wrote:

> After reading RFC 6072 I can't help to wonder how this works with an outbound proxy configured in the UA.
> 
> For instance, using SIP Outbound we have two proxys that we keep an active flow to. RFC 6072 says that
> the UA is required to have a direct connection to the certificate service in order to publish a key and certificate.
> This is in order to be able to examine the servers certificate. 
> 
> Does this mean that a UA that follows RFC 6072 should override the pre-defined route in the UA and thus
> also ignore the SIP outbound mechanism for this transaction? 

Those outbound guys and 6072 guys should really talk to each other :-) 

Yes, the implementation I have seen are just skipping the outbound proxy for managing their own
credentials. The alternative is to use an outbound server that you trust at the same level as your
credential server. I don't like this as much because even thought they are likely managed by the same
domain, the credential server is probably a bit more carefully managed with less going on with it. 

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 0 comments |
headers
RFC Errata System | 13 Oct 2011 21:44
Favicon

[Technical Errata Reported] RFC5628 (2995)


The following errata report has been submitted for RFC5628,
"Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User
Agent URIs (GRUUs)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5628&eid=2995

--------------------------------------
Type: Technical
Reported by: Paul Kyzivat <pkyzivat <at> alum.mit.edu>

Section: 5

Original Text
-------------
   If the notifier includes the <temp-gruu> element, it MUST populate
   the element with the most recently assigned temporary GRUU that is
   associated with the instance ID and AOR of the registered contact.
   It MUST also populate the element with a "cseq" attribute
   corresponding to the first (oldest) currently active temporary GRUU
   that is associated with the instance ID and AOR of the registered
   contact.  The value of the "cseq" attribute is set to the value of
   the CSeq header field of the REGISTER request that caused that first
   temporary GRUU to be assigned.

Corrected Text
--------------
   If the notifier includes the <temp-gruu> element, it MUST populate
   the element with the most recently assigned temporary GRUU that is
   associated with the instance ID and AOR of the registered contact.
   It MUST also populate the element with a "first-cseq" attribute
   corresponding to the first (oldest) currently active temporary GRUU
   that is associated with the instance ID and AOR of the registered
   contact.  The value of the "first-cseq" attribute is set to the value of
   the CSeq header field of the REGISTER request that caused that first
   temporary GRUU to be assigned.

Notes
-----
This replaces '"cseq" attribute' with '"first-cseq" attribute.
This is almost a typo, since there is no "cseq" attribute of <temp-gruu>.
Following the text as written would yield an invalid xml document.

This was reported to me by Ivo Sedlacek:
http://www.ietf.org/mail-archive/web/sipcore/current/msg04282.html

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5628 (draft-ietf-sipping-gruu-reg-event-09)
--------------------------------------
Title               : Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable
User Agent URIs (GRUUs)
Publication Date    : October 2009
Author(s)           : P. Kyzivat
Category            : PROPOSED STANDARD
Source              : Session Initiation Proposal Investigation
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 0 comments |

Gmane