From oej@edvina.net Mon Oct 3 10:55:11 2011 Return-Path: X-Original-To: sipping@ietfa.amsl.com Delivered-To: sipping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5463621F8CDB for ; Mon, 3 Oct 2011 10:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4OTXB4Tdq6h for ; Mon, 3 Oct 2011 10:55:10 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 74F2C21F8CDA for ; Mon, 3 Oct 2011 10:55:10 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 682C1754BCD5 for ; Mon, 3 Oct 2011 17:58:10 +0000 (UTC) From: "Olle E. Johansson" Content-Type: multipart/alternative; boundary="Apple-Mail=_1CF51114-816D-4CD3-87E9-3CACD8AEF2C5" Date: Mon, 3 Oct 2011 19:58:15 +0200 Message-Id: To: sipping@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [Sipping] RFC 6157 actually updates RFC 3263 too - dual stack DNS lookups X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 17:55:11 -0000 --Apple-Mail=_1CF51114-816D-4CD3-87E9-3CACD8AEF2C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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=20 preference of address family - ipv4 or ipv6 - by using SRV entries. /O --Apple-Mail=_1CF51114-816D-4CD3-87E9-3CACD8AEF2C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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.

= --Apple-Mail=_1CF51114-816D-4CD3-87E9-3CACD8AEF2C5-- From ibc@aliax.net Mon Oct 3 13:31:40 2011 Return-Path: X-Original-To: sipping@ietfa.amsl.com Delivered-To: sipping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480B821F8E64 for ; Mon, 3 Oct 2011 13:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MY3V9bhKQit1 for ; Mon, 3 Oct 2011 13:31:39 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8BBA21F8E4E for ; Mon, 3 Oct 2011 13:31:39 -0700 (PDT) Received: by mail-vx0-f172.google.com with SMTP id fo11so4846911vcb.31 for ; Mon, 03 Oct 2011 13:34:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.177 with SMTP id bp17mr351730vdb.447.1317674082997; Mon, 03 Oct 2011 13:34:42 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Mon, 3 Oct 2011 13:34:42 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 Oct 2011 22:34:42 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sipping@ietf.org Subject: Re: [Sipping] RFC 6157 actually updates RFC 3263 too - dual stack DNS lookups X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 20:31:40 -0000 2011/10/3 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 R= FC > 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 i= n > 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"). --=20 I=C3=B1aki Baz Castillo From vkg@bell-labs.com Wed Oct 5 06:58:48 2011 Return-Path: X-Original-To: sipping@ietfa.amsl.com Delivered-To: sipping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AF221F8D64 for ; Wed, 5 Oct 2011 06:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.622 X-Spam-Level: X-Spam-Status: No, score=-106.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWRgXysGLyxT for ; Wed, 5 Oct 2011 06:58:44 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0130F21F8D71 for ; Wed, 5 Oct 2011 06:58:43 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p95E1pCD010124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 5 Oct 2011 09:01:51 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p95E1oaY006375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 5 Oct 2011 09:01:51 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p95E1o9Y029513 for ; Wed, 5 Oct 2011 09:01:50 -0500 (CDT) Message-ID: <4E8C63EC.3090908@bell-labs.com> Date: Wed, 05 Oct 2011 09:04:28 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: sipping@ietf.org References:

In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [Sipping] RFC 6157 actually updates RFC 3263 too - dual stack DNS lookups X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 13:58:48 -0000 On 2011/10/3 Olle E. Johansson 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@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From oej@edvina.net Sat Oct 8 04:41:06 2011 Return-Path: X-Original-To: sipping@ietfa.amsl.com Delivered-To: sipping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C0721F8ADE for ; Sat, 8 Oct 2011 04:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbGFux+VEKxh for ; Sat, 8 Oct 2011 04:41:06 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB2F21F8ACE for ; Sat, 8 Oct 2011 04:41:06 -0700 (PDT) Received: from [IPv6:2001:470:1f15:d79:c861:65e3:aea7:5665] (unknown [IPv6:2001:470:1f15:d79:c861:65e3:aea7:5665]) by smtp7.webway.se (Postfix) with ESMTPA id F1427754BCD5; Sat, 8 Oct 2011 11:44:18 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <4E8C63EC.3090908@bell-labs.com> Date: Sat, 8 Oct 2011 13:44:21 +0200 Content-Transfer-Encoding: 7bit Message-Id: <7DAC3337-179C-49B0-B1D9-947BB8DEA61A@edvina.net> References:

<4E8C63EC.3090908@bell-labs.com> To: Vijay K. Gurbani X-Mailer: Apple Mail (2.1244.3) Cc: sipping@ietf.org Subject: Re: [Sipping] RFC 6157 actually updates RFC 3263 too - dual stack DNS lookups X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 11:41:06 -0000 5 okt 2011 kl. 16:04 skrev Vijay K. Gurbani: > On 2011/10/3 Olle E. Johansson 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 From wwwrun@rfc-editor.org Mon Oct 10 11:47:52 2011 Return-Path: X-Original-To: sipping@ietfa.amsl.com Delivered-To: sipping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2B521F8C17 for ; Mon, 10 Oct 2011 11:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytsIZO0F4hIQ for ; Mon, 10 Oct 2011 11:47:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7F18421F8BE7 for ; Mon, 10 Oct 2011 11:47:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 53A3A98C272; Mon, 10 Oct 2011 11:47:52 -0700 (PDT) To: Gonzalo.Camarillo@ericsson.com, karim@athonet.com, vkg@bell-labs.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, gonzalo.camarillo@ericsson.com, mary.ietf.barnes@gmail.com From: RFC Errata System Message-Id: <20111010184752.53A3A98C272@rfc-editor.org> Date: Mon, 10 Oct 2011 11:47:52 -0700 (PDT) X-Mailman-Approved-At: Mon, 10 Oct 2011 11:48:40 -0700 Cc: sipping@ietf.org, rfc-editor@rfc-editor.org Subject: [Sipping] [Editorial Errata Reported] RFC6157 (2987) X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 18:47:53 -0000 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 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 From oej@edvina.net Mon Oct 10 13:05:40 2011 Return-Path: X-Original-To: sipping@ietfa.amsl.com Delivered-To: sipping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE0221F853E for ; Mon, 10 Oct 2011 13:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnkzhzbHVCAO for ; Mon, 10 Oct 2011 13:05:40 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id DE3FB21F8AFC for ; Mon, 10 Oct 2011 13:05:39 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 73798754BCD5 for ; Mon, 10 Oct 2011 20:05:31 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Oct 2011 22:05:37 +0200 Message-Id: <6CAE043E-9B12-48A9-B9D4-969284B7470C@edvina.net> To: sipping@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [Sipping] SIP certificate management (RFC 6072) and SIP outbound X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 20:05:40 -0000 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.=20 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?=20 /O= From fluffy@cisco.com Mon Oct 10 16:32:57 2011 Return-Path: X-Original-To: sipping@ietfa.amsl.com Delivered-To: sipping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7971D21F8513 for ; Mon, 10 Oct 2011 16:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSDquVT-GNzv for ; Mon, 10 Oct 2011 16:32:57 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 42F2321F8AE6 for ; Mon, 10 Oct 2011 16:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1159; q=dns/txt; s=iport; t=1318289575; x=1319499175; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8j+5wbgB+oSVPvuDbsturREAx5/AtbbqX/kUu2QRJDY=; b=jrkseZV4DLU/S7Mv38Cvq+DEnlU2fjNGuBjvksxEgBEeCMJ+LgBN9zQl 63z2D2qgfLVkIcSociRSNISfLb0Nkt7hIHaDurV3VxzxUUy/N86oQTr6f 4oOQUueH7Hi6BVo5DfU6GIipFckgrhw71jgujp9VudvJeD5AdfEyZZjL2 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGqAk06rRDoJ/2dsb2JhbABDqCSBBYFTAQEBAwESASc/BQsLRlcGNYdcmysBnjSGYmEEh32LeoUpjEg X-IronPort-AV: E=Sophos;i="4.68,519,1312156800"; d="scan'208";a="7076930" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 10 Oct 2011 23:32:55 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9ANWsJM020243; Mon, 10 Oct 2011 23:32:54 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <6CAE043E-9B12-48A9-B9D4-969284B7470C@edvina.net> Date: Mon, 10 Oct 2011 17:32:54 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6CAE043E-9B12-48A9-B9D4-969284B7470C@edvina.net> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1084) Cc: sipping@ietf.org Subject: Re: [Sipping] SIP certificate management (RFC 6072) and SIP outbound X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 23:32:57 -0000 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. >=20 > 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.=20 >=20 > 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?=20 Those outbound guys and 6072 guys should really talk to each other :-)=20= 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.=20 From wwwrun@rfc-editor.org Thu Oct 13 12:44:45 2011 Return-Path: X-Original-To: sipping@ietfa.amsl.com Delivered-To: sipping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BCF21F8B06 for ; Thu, 13 Oct 2011 12:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHPRqXPxnIaU for ; Thu, 13 Oct 2011 12:44:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BFC4B21F8AF8 for ; Thu, 13 Oct 2011 12:44:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2334998C262; Thu, 13 Oct 2011 12:44:44 -0700 (PDT) To: pkyzivat@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, gonzalo.camarillo@ericsson.com, mary.ietf.barnes@gmail.com From: RFC Errata System Message-Id: <20111013194444.2334998C262@rfc-editor.org> Date: Thu, 13 Oct 2011 12:44:44 -0700 (PDT) Cc: sipping@ietf.org, pkyzivat@alum.mit.edu, rfc-editor@rfc-editor.org Subject: [Sipping] [Technical Errata Reported] RFC5628 (2995) X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 19:44:45 -0000 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 Section: 5 Original Text ------------- If the notifier includes the 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 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 . 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