From pkyzivat@alum.mit.edu Mon Dec 2 08:04:09 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FDC1ABD2A for ; Mon, 2 Dec 2013 08:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzmWAt8PCHZ0 for ; Mon, 2 Dec 2013 08:04:08 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 467641A1F65 for ; Mon, 2 Dec 2013 08:04:08 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta07.westchester.pa.mail.comcast.net with comcast id wdEB1m00617dt5G57g4524; Mon, 02 Dec 2013 16:04:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id wg451m00g3ZTu2S3Zg450F; Mon, 02 Dec 2013 16:04:05 +0000 Message-ID: <529CAF75.3050100@alum.mit.edu> Date: Mon, 02 Dec 2013 08:04:05 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <20131129023247.19386.89965.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386000245; bh=kfRrTUzbNHmQphYoMPY3jLrmCTeDZUp4BxWnII/N+GA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Q5hCaV/wGSBqp+zt3qnYThaebEBB6r3NAXOw+oJCBbXMStLagjvCWleMg2+V35ie2 tx+cYOf05I+Zj+ugvhQyCLMKXdCwneXZy1CdO7CwajNhFJ0LoJcBwdMIwHUyGWxfXy QspqLKh4Dc6H5830LJbQfOvuvtm7KqQaicbaDbehlM2PktlPPsmv2NAl/cBOmzvfAN YYOUOEC2ndlHK93Q/F3NKlXF/JhUBxGXxuNcaBuRncpY7JG3CsQTzoBTHMv1otR30U t2FHH4o5ReLS2llaQP+j4UM5Sn8jVE+xMv0vrhX8vyu3d1UMaHaTCDXOxB57xggsfR dy1Y2Ka0M/KuQ== Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-10.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 16:04:09 -0000 Iñaki, Generally this looks good. I remain concerned about the "updates" issue, though it appears that I may be the only person who is. So I'm satisfied with this draft, and will pursue my general concerns about the meaning of "updates" separately. Thanks, Paul On 11/28/13 6:40 PM, Iñaki Baz Castillo wrote: > 2013/11/29 : >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. >> >> Title : The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) >> Author(s) : Inaki Baz Castillo >> Jose Luis Millan Villegas >> Victor Pascual >> Filename : draft-ietf-sipcore-sip-websocket-10.txt >> Pages : 24 >> Date : 2013-11-28 >> >> Abstract: >> The WebSocket protocol enables two-way realtime communication between >> clients and servers in web-based applications. This document >> specifies a WebSocket sub-protocol as a reliable transport mechanism >> between SIP (Session Initiation Protocol) entities to enable usage of >> SIP in web-oriented deployments. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-10 > > > > Hi, > > The changelog for the version 10 of the draft is the following: > > > - Removed "_This section is non-normative_" at the top of > non-normative sections (those don't include normative keywords so they > are already non-normative). > > - Use "RECOMMENDED" instead of "recommended" in section "Secure > WebSocket Connection" under "Security Considerations" (thanks to > Stephen Farrell). > > - RFC 5246 (TLS Protocol Version 1.2) moved to normative references > (thanks to Stephen Farrell). > > - Remove indentation of second paragraph in "WebSocket SIP > Sub-Protocol -> Handshake" section (thanks to Benoit Claise). > > - Improvements and fixes in normative text (thanks to Pete Resnick). > > - Replace "optional" with "not necessary" when talking about > Content-Length header (thanks to Pete Resnick). > > - Remove "updates RFC 3261" given that an implementor of a SIP > UDP/TCP/TLS device does not need to know about SIP WebSocket transport > (requested by Stephen Farrell and others). > > - Clarify that UTF-8 encoding is RECOMMENDED (given JavaScript and > WebSocket nature). > > - Many changes in "Authentication" section, by making some MTI > authentication mechanisms (thanks to Pete Resnick). > > - RFC 2617 (HTTP authentication) and RFC 6265 (HTTP Cookies) moved to > Normative References. > > - Removed the text about "matching Web/WebSocket identity and SIP > identity" as it just makes sense in specific usecases (thanks to > Binod). > > > I'm really sorry for the delay in posting this new revision of the > draft. As always, your comments and feedback are welcome. > > Thanks to all the members in the group. > Best regards. > > > > > > > -- > Iñaki Baz Castillo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From ibc@aliax.net Mon Dec 2 08:09:20 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844A31AE4BB for ; Mon, 2 Dec 2013 08:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIcHzcd1EQkD for ; Mon, 2 Dec 2013 08:09:19 -0800 (PST) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id EA1801AE4B1 for ; Mon, 2 Dec 2013 08:09:18 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id k4so4502149qaq.8 for ; Mon, 02 Dec 2013 08:09:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=PnWoW2t/dagozV9pzJGpZUMbXFNzyT97kTvFZO1+83E=; b=MzvPSg0Za2/RZcC06hLMpRBQjfXdOmOA/G9lJNL2gXsviirPGI1BMaX+yZDsn7Vjcf RSdevQlBtWteKcu16MFJR+jt0Vt3HvacA80ArEaVJb+t0NgGcMuoee1bkHZXQyheyIg8 FU4NRrodHKuAVba5yil7ywcUvTm7nYqNvQDJCqFSdRMncMP+n/2eEtC8lZPZWkIQn/Im ov8EDB4QHqd2J976hm6mseh+Xj2CFwCRImuI62eo5TZ1uEjzg5u+HJ6OffzSTKx629Lk CxYG09QfjRnHtbWGKoI32g0g948AZzq7Ig9d3cblpWitxCM23Vy2vpK/3/rh4Lx4SdF6 m9dg== X-Gm-Message-State: ALoCoQmTWqf7Gby+Vf9fdPwtomV0EjwHcUgm4QHSyZZLwcZKcT2SjbN8F9qtwmvESLFjLkWqhcLj X-Received: by 10.49.131.164 with SMTP id on4mr47071231qeb.16.1386000556415; Mon, 02 Dec 2013 08:09:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.71.8 with HTTP; Mon, 2 Dec 2013 08:08:55 -0800 (PST) In-Reply-To: <529CAF75.3050100@alum.mit.edu> References: <20131129023247.19386.89965.idtracker@ietfa.amsl.com> <529CAF75.3050100@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 2 Dec 2013 17:08:55 +0100 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-10.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 16:09:20 -0000 2013/12/2 Paul Kyzivat : > I=C3=B1aki, > > Generally this looks good. I remain concerned about the "updates" issue, > though it appears that I may be the only person who is. So I'm satisfied > with this draft, and will pursue my general concerns about the meaning of > "updates" separately. Thanks a lot Paul, Indeed the "updates 3261" seems a hard topic given that it adds some stuff to RFC 3261, changes some minor stuff in it, but still does not require developers of non-WS SIP devices to be aware of the SIP WebSocket transport. Best regards. --=20 I=C3=B1aki Baz Castillo From shinji.okumura@softfront.jp Thu Dec 5 02:38:04 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382F61ADEA3 for ; Thu, 5 Dec 2013 02:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.17 X-Spam-Level: X-Spam-Status: No, score=-97.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, SPF_HELO_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlzryYHyIgCP for ; Thu, 5 Dec 2013 02:38:02 -0800 (PST) Received: from softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by ietfa.amsl.com (Postfix) with ESMTP id 45E391ADE72 for ; Thu, 5 Dec 2013 02:38:00 -0800 (PST) Received: from localhost (sf-mail [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 17C2B4280B9 for ; Thu, 5 Dec 2013 19:37:56 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmoYFme4BsRG for ; Thu, 5 Dec 2013 19:37:55 +0900 (JST) Received: from softfront.jp (sf-pc-111.softfront.local [172.16.33.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sf-mail.softfront.co.jp (Postfix) with ESMTP id B284D4280B8 for ; Thu, 5 Dec 2013 19:37:54 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Thu, 05 Dec 2013 19:37:53 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary-TYzhXHhK5unLiPxPYvbGj" X-Mailer: HidemaruMail 6.01 (WinNT,601) In-Reply-To: <20131107182721.8391.35063.idtracker@ietfa.amsl.com> References: <20131107182721.8391.35063.idtracker@ietfa.amsl.com> Message-Id: <9CCEF1A60DA830shinji.okumura@softfront.jp> Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-callflows-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 10:38:04 -0000 --Boundary-TYzhXHhK5unLiPxPYvbGj Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I attach diff files. Please reflect a new version, if correct. And one question. Is it correct certainly that the index-val of rc/np parameter is a just parent of hi-index at all times? i.e. History-Info: ;index=x.y.z;rc=x.y Or case by case? Regards Shinji internet-drafts@ietf.org Thu, 07 Nov 2013 10:27:21 -0800 > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. > > Title : Session Initiation Protocol (SIP) History-Info Header Call Flow Examples > Author(s) : Mary Barnes > Francois Audet > Shida Schubert > Hans Erik van Elburg > Christer Holmberg > Filename : draft-ietf-sipcore-rfc4244bis-callflows-08.txt > Pages : 48 > Date : 2013-11-07 > >Abstract: > This document describes use cases and documents call flows which > require the History-Info header field to capture the Request-URIs as > a Session Initiation Protocol (SIP) Request is retargeted. The use > cases are described along with the corresponding call flow diagrams > and messaging details. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-callflows-08 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4244bis-callflows-08 > > >Please note that it may take a couple of minutes from the time of submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ --Boundary-TYzhXHhK5unLiPxPYvbGj Content-Type: application/octet-stream; name="rfc4244bis-12.patch" Content-Disposition: attachment; filename="rfc4244bis-12.patch" Content-Transfer-Encoding: base64 KioqIGRyYWZ0LWlldGYtc2lwY29yZS1yZmM0MjQ0YmlzLTEyLnR4dAotLS0gZHJhZnQtaWV0 Zi1zaXBjb3JlLXJmYzQyNDRiaXMtMTJuZXcudHh0CioqKioqKioqKioqKioqKgoqKiogNTMw LDUzNiAqKioqCiAgICAgSGlzdG9yeS1JbmZvOiA8c2lwOlVzZXJBQGltcy5leGFtcGxlLmNv bT47aW5kZXg9MTtmb289YmFyCiAgCiAgICAgSGlzdG9yeS1JbmZvOiA8c2lwOlVzZXJBQGlt cy5leGFtcGxlLmNvbT9SZWFzb249U0lQJTNCXAohICAgICAgICAgICAgICAgICAgY2F1c2Ul M0QzMDI+O2luZGV4PTEuMSxcCiAgICAgICAgICAgICAgICAgICA8c2lwOlVzZXJCQGV4YW1w bGUuY29tP1ByaXZhY3k9aGlzdG9yeSZSZWFzb249U0lQJTNCXAogICAgICAgICAgICAgICAg ICAgY2F1c2UlM0Q0ODY+O2luZGV4PTEuMjttcD0xLjEsXAogICAgICAgICAgICAgICAgICAg PHNpcDo0NTQzMkAxOTIuMTY4LjAuMz47aW5kZXg9MS4zO3JjPTEuMgotLS0gNTMwLDUzNiAt LS0tCiAgICAgSGlzdG9yeS1JbmZvOiA8c2lwOlVzZXJBQGltcy5leGFtcGxlLmNvbT47aW5k ZXg9MTtmb289YmFyCiAgCiAgICAgSGlzdG9yeS1JbmZvOiA8c2lwOlVzZXJBQGltcy5leGFt cGxlLmNvbT9SZWFzb249U0lQJTNCXAohICAgICAgICAgICAgICAgICAgY2F1c2UlM0QzMDI+ O2luZGV4PTEuMTtucD0xLFwKICAgICAgICAgICAgICAgICAgIDxzaXA6VXNlckJAZXhhbXBs ZS5jb20/UHJpdmFjeT1oaXN0b3J5JlJlYXNvbj1TSVAlM0JcCiAgICAgICAgICAgICAgICAg ICBjYXVzZSUzRDQ4Nj47aW5kZXg9MS4yO21wPTEuMSxcCiAgICAgICAgICAgICAgICAgICA8 c2lwOjQ1NDMyQDE5Mi4xNjguMC4zPjtpbmRleD0xLjM7cmM9MS4yCg== --Boundary-TYzhXHhK5unLiPxPYvbGj Content-Type: application/octet-stream; name="rfc4244bis-callflow-08.patch" Content-Disposition: attachment; filename="rfc4244bis-callflow-08.patch" Content-Transfer-Encoding: base64 KioqIGRyYWZ0LWlldGYtc2lwY29yZS1yZmM0MjQ0YmlzLWNhbGxmbG93cy0wOC50eHQKLS0t IGRyYWZ0LWlldGYtc2lwY29yZS1yZmM0MjQ0YmlzLWNhbGxmbG93cy0wOG5ldy50eHQKKioq KioqKioqKioqKioqCioqKiA2ODgsNjk0ICoqKioKICAgICBDYWxsLUlkOiAxMjM0NTYwMEBh dGxhbnRhLmV4YW1wbGUuY29tCiAgICAgQ1NlcTogMSBJTlZJVEUKICAgICBIaXN0b3J5LUlu Zm86IDxzaXA6Ym9iQGJpbG94aS5leGFtcGxlLmNvbTtwPXg+O2luZGV4PTEKISAgICBIaXN0 b3J5LUluZm86IDxzaXA6Ym9iQGJpbG94aS5leGFtcGxlLmNvbTtwPXg+O2luZGV4PTEuMQog ICAgIEhpc3RvcnktSW5mbzogPHNpcDpib2JAMTkyLjAuMS4xMT47aW5kZXg9MS4xLjE7cmM9 MS4xCiAgICAgQ29udGFjdDogQWxpY2UgPHNpcDphbGljZUAxOTIuMC4yLjM+CiAgICAgQ29u dGVudC1UeXBlOiBhcHBsaWNhdGlvbi9zZHAKLS0tIDY4OCw2OTQgLS0tLQogICAgIENhbGwt SWQ6IDEyMzQ1NjAwQGF0bGFudGEuZXhhbXBsZS5jb20KICAgICBDU2VxOiAxIElOVklURQog ICAgIEhpc3RvcnktSW5mbzogPHNpcDpib2JAYmlsb3hpLmV4YW1wbGUuY29tO3A9eD47aW5k ZXg9MQohICAgIEhpc3RvcnktSW5mbzogPHNpcDpib2JAYmlsb3hpLmV4YW1wbGUuY29tO3A9 eD47aW5kZXg9MS4xO25wPTEKICAgICBIaXN0b3J5LUluZm86IDxzaXA6Ym9iQDE5Mi4wLjEu MTE+O2luZGV4PTEuMS4xO3JjPTEuMQogICAgIENvbnRhY3Q6IEFsaWNlIDxzaXA6YWxpY2VA MTkyLjAuMi4zPgogICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vc2RwCioqKioqKioq KioqKioqKgoqKiogNzEzLDcxOSAqKioqCiAgICAgQ2FsbC1JZDogMTIzNDU2MDBAYXRsYW50 YS5leGFtcGxlLmNvbQogICAgIENTZXE6IDEgSU5WSVRFCiAgICAgSGlzdG9yeS1JbmZvOiA8 c2lwOmJvYkBiaWxveGkuZXhhbXBsZS5jb207cD14PjtpbmRleD0xCiEgICAgSGlzdG9yeS1J bmZvOiA8c2lwOmJvYkBiaWxveGkuZXhhbXBsZS5jb207cD14PjtpbmRleD0xLjEKICAgICBI aXN0b3J5LUluZm86IDxzaXA6Ym9iQDE5Mi4wLjEuMTE+O2luZGV4PTEuMS4xO3JjPTEuMQog ICAgIENvbnRhY3Q6IEJvYiBIb21lIDxzaXA6Ym9iQDE5Mi4wLjEuMTU+CiAgICAgQ29udGVu dC1UeXBlOiBhcHBsaWNhdGlvbi9zZHAKLS0tIDcxMyw3MTkgLS0tLQogICAgIENhbGwtSWQ6 IDEyMzQ1NjAwQGF0bGFudGEuZXhhbXBsZS5jb20KICAgICBDU2VxOiAxIElOVklURQogICAg IEhpc3RvcnktSW5mbzogPHNpcDpib2JAYmlsb3hpLmV4YW1wbGUuY29tO3A9eD47aW5kZXg9 MQohICAgIEhpc3RvcnktSW5mbzogPHNpcDpib2JAYmlsb3hpLmV4YW1wbGUuY29tO3A9eD47 aW5kZXg9MS4xO25wPTEKICAgICBIaXN0b3J5LUluZm86IDxzaXA6Ym9iQDE5Mi4wLjEuMTE+ O2luZGV4PTEuMS4xO3JjPTEuMQogICAgIENvbnRhY3Q6IEJvYiBIb21lIDxzaXA6Ym9iQDE5 Mi4wLjEuMTU+CiAgICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9zZHAKKioqKioqKioq KioqKioqCioqKiA3NjIsNzcxICoqKioKICAgICBDYWxsLUlkOiAxMjM0NTYwMEBhdGxhbnRh LmV4YW1wbGUuY29tCiAgICAgQ1NlcTogMSBJTlZJVEUKICAgICBIaXN0b3J5LUluZm86IDxz aXA6Ym9iQGJpbG94aS5leGFtcGxlLmNvbTtwPXg+O2luZGV4PTEKISAgICBIaXN0b3J5LUlu Zm86IDxzaXA6Ym9iQGJpbG94aS5leGFtcGxlLmNvbTtwPXg+O2luZGV4PTEuMQogICAgIEhp c3RvcnktSW5mbzogPHNpcDpib2JAMTkyLjAuMS4xMT9SZWFzb249U0lQJTNCY2F1c2UlM0Qz MDI+O1wKISAgICAgICAgICAgICAgICAgICAgaW5kZXg9MS4xLjE7cmM9MQohICAgIEhpc3Rv cnktSW5mbzogPHNpcDpib2JAMTkyLjAuMS4xNT47aW5kZXg9MS4xLjIKICAgICBDb250YWN0 OiBBbGljZSA8c2lwOmFsaWNlQDE5Mi4wLjIuMz4KICAgICBDb250ZW50LVR5cGU6IGFwcGxp Y2F0aW9uL3NkcAogICAgIENvbnRlbnQtTGVuZ3RoOiA8YXBwcm9wcmlhdGUgdmFsdWU+Ci0t LSA3NjIsNzcxIC0tLS0KICAgICBDYWxsLUlkOiAxMjM0NTYwMEBhdGxhbnRhLmV4YW1wbGUu Y29tCiAgICAgQ1NlcTogMSBJTlZJVEUKICAgICBIaXN0b3J5LUluZm86IDxzaXA6Ym9iQGJp bG94aS5leGFtcGxlLmNvbTtwPXg+O2luZGV4PTEKISAgICBIaXN0b3J5LUluZm86IDxzaXA6 Ym9iQGJpbG94aS5leGFtcGxlLmNvbTtwPXg+O2luZGV4PTEuMTtucD0xCiAgICAgSGlzdG9y eS1JbmZvOiA8c2lwOmJvYkAxOTIuMC4xLjExP1JlYXNvbj1TSVAlM0JjYXVzZSUzRDMwMj47 XAohICAgICAgICAgICAgICAgICAgICBpbmRleD0xLjEuMTtyYz0xLjEKISAgICBIaXN0b3J5 LUluZm86IEJvYiBIb21lIDxzaXA6Ym9iQDE5Mi4wLjEuMTU+O2luZGV4PTEuMS4yCiAgICAg Q29udGFjdDogQWxpY2UgPHNpcDphbGljZUAxOTIuMC4yLjM+CiAgICAgQ29udGVudC1UeXBl OiBhcHBsaWNhdGlvbi9zZHAKICAgICBDb250ZW50LUxlbmd0aDogPGFwcHJvcHJpYXRlIHZh bHVlPgoqKioqKioqKioqKioqKioKKioqIDgwMCw4MDkgKioqKgogICAgIENhbGwtSWQ6IDEy MzQ1NjAwQGF0bGFudGEuZXhhbXBsZS5jb20KICAgICBDU2VxOiAxIElOVklURQogICAgIEhp c3RvcnktSW5mbzogPHNpcDpib2JAYmlsb3hpLmV4YW1wbGUuY29tO3A9eD47aW5kZXg9MQoh ICAgIEhpc3RvcnktSW5mbzogPHNpcDpib2JAYmlsb3hpLmV4YW1wbGUuY29tO3A9eD47aW5k ZXg9MS4xCiAgICAgSGlzdG9yeS1JbmZvOiA8c2lwOmJvYkAxOTIuMC4xLjExP1JlYXNvbj1T SVAlM0JjYXVzZSUzRDMwMj47XAohICAgICAgICAgICAgICAgICAgICBpbmRleD0xLjEuMTty Yz0xCiEgICAgSGlzdG9yeS1JbmZvOiA8c2lwOmJvYkAxOTIuMC4xLjE1PjtpbmRleD0xLjEu MjtyYz0xLjEKICAgICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3NkcAogICAgIENvbnRl bnQtTGVuZ3RoOiA8YXBwcm9wcmlhdGUgdmFsdWU+CiAgICAgPCEtLSBTRFAgTm90IFNob3du IC0tPgotLS0gODAwLDgxMCAtLS0tCiAgICAgQ2FsbC1JZDogMTIzNDU2MDBAYXRsYW50YS5l eGFtcGxlLmNvbQogICAgIENTZXE6IDEgSU5WSVRFCiAgICAgSGlzdG9yeS1JbmZvOiA8c2lw OmJvYkBiaWxveGkuZXhhbXBsZS5jb207cD14PjtpbmRleD0xCiEgICAgSGlzdG9yeS1JbmZv OiA8c2lwOmJvYkBiaWxveGkuZXhhbXBsZS5jb207cD14PjtpbmRleD0xLjE7bnA9MQogICAg IEhpc3RvcnktSW5mbzogPHNpcDpib2JAMTkyLjAuMS4xMT9SZWFzb249U0lQJTNCY2F1c2Ul M0QzMDI+O1wKISAgICAgICAgICAgICAgICAgICAgaW5kZXg9MS4xLjE7cmM9MS4xCiEgICAg SGlzdG9yeS1JbmZvOiBCb2IgSG9tZSA8c2lwOmJvYkAxOTIuMC4xLjE1PjtpbmRleD0xLjEu MgohICAgIENvbnRhY3Q6IEJvYiA8c2lwOmJvYkAxOTIuMC4xLjE1PgogICAgIENvbnRlbnQt VHlwZTogYXBwbGljYXRpb24vc2RwCiAgICAgQ29udGVudC1MZW5ndGg6IDxhcHByb3ByaWF0 ZSB2YWx1ZT4KICAgICA8IS0tIFNEUCBOb3QgU2hvd24gLS0+CioqKioqKioqKioqKioqKgoq KiogODI0LDgzMyAqKioqCiAgICAgQ2FsbC1JZDogMTIzNDU2MDBAYXRsYW50YS5leGFtcGxl LmNvbQogICAgIENTZXE6IDEgSU5WSVRFCiAgICAgSGlzdG9yeS1JbmZvOiA8c2lwOmFub255 bW91c0Bhbm9ueW1vdXMuaW52YWxpZD47aW5kZXg9MQohICAgIEhpc3RvcnktSW5mbzogPHNp cDphbm9ueW1vdXNAYW5vbnltb3VzLmludmFsaWQ+O2luZGV4PTEuMQohICAgIEhpc3Rvcnkt SW5mbzogPHNpcDphbm9ueW1vdXNAYW5vbnltb3VzLmludmFsaWQ+O2luZGV4PTEuMS4xO3Jj PTEKISAgICBIaXN0b3J5LUluZm86IDxzaXA6YW5vbnltb3VzQGFub255bW91cy5pbnZhbGlk PjtpbmRleD0xLjEuMjtyYz0xLjEKISAgICBDb250YWN0OiBCb2IgPHNpcDpib2JAMTkyLjAu MS4xMT4KICAgICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3NkcAogICAgIENvbnRlbnQt TGVuZ3RoOiA8YXBwcm9wcmlhdGUgdmFsdWU+CiAgICAgPCEtLSBTRFAgTm90IFNob3duIC0t PgotLS0gODI1LDgzNCAtLS0tCiAgICAgQ2FsbC1JZDogMTIzNDU2MDBAYXRsYW50YS5leGFt cGxlLmNvbQogICAgIENTZXE6IDEgSU5WSVRFCiAgICAgSGlzdG9yeS1JbmZvOiA8c2lwOmFu b255bW91c0Bhbm9ueW1vdXMuaW52YWxpZD47aW5kZXg9MQohICAgIEhpc3RvcnktSW5mbzog PHNpcDphbm9ueW1vdXNAYW5vbnltb3VzLmludmFsaWQ+O2luZGV4PTEuMTtucD0xCiEgICAg SGlzdG9yeS1JbmZvOiA8c2lwOmFub255bW91c0Bhbm9ueW1vdXMuaW52YWxpZD47aW5kZXg9 MS4xLjE7cmM9MS4xCiEgICAgSGlzdG9yeS1JbmZvOiA8c2lwOmFub255bW91c0Bhbm9ueW1v dXMuaW52YWxpZD47aW5kZXg9MS4xLjIKISAgICBDb250YWN0OiBCb2IgPHNpcDpib2JAMTky LjAuMS4xNT4KICAgICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3NkcAogICAgIENvbnRl bnQtTGVuZ3RoOiA8YXBwcm9wcmlhdGUgdmFsdWU+CiAgICAgPCEtLSBTRFAgTm90IFNob3du IC0tPgoqKioqKioqKioqKioqKioKKioqIDg1Miw4NjEgKioqKgogICAgIENhbGwtSWQ6IDEy MzQ1NjAwQGF0bGFudGEuZXhhbXBsZS5jb20KICAgICBDU2VxOiAxIElOVklURQogICAgIEhp c3RvcnktSW5mbzogPHNpcDphbm9ueW1vdXNAYW5vbnltb3VzLmludmFsaWQ+O2luZGV4PTEK ISAgICBIaXN0b3J5LUluZm86IDxzaXA6YW5vbnltb3VzQGFub255bW91cy5pbnZhbGlkPjtp bmRleD0xLjEKICAgICBIaXN0b3J5LUluZm86IDxzaXA6YW5vbnltb3VzQGFub255bW91cy5p bnZhbGlkPjtpbmRleD0xLjEuMTtyYz0xCiAgICAgSGlzdG9yeS1JbmZvOiA8c2lwOmFub255 bW91c0Bhbm9ueW1vdXMuaW52YWxpZD47aW5kZXg9MS4xLjI7cmM9MS4xCiEgICAgQ29udGFj dDogQm9iIDxzaXA6Ym9iQDE5Mi4wLjEuMTE+CiAgICAgQ29udGVudC1UeXBlOiBhcHBsaWNh dGlvbi9zZHAKICAgICBDb250ZW50LUxlbmd0aDogPGFwcHJvcHJpYXRlIHZhbHVlPgogICAg IDwhLS0gU0RQIE5vdCBTaG93biAtLT4KLS0tIDg1Myw4NjIgLS0tLQogICAgIENhbGwtSWQ6 IDEyMzQ1NjAwQGF0bGFudGEuZXhhbXBsZS5jb20KICAgICBDU2VxOiAxIElOVklURQogICAg IEhpc3RvcnktSW5mbzogPHNpcDphbm9ueW1vdXNAYW5vbnltb3VzLmludmFsaWQ+O2luZGV4 PTEKISAgICBIaXN0b3J5LUluZm86IDxzaXA6YW5vbnltb3VzQGFub255bW91cy5pbnZhbGlk PjtpbmRleD0xLjE7bnA9MQogICAgIEhpc3RvcnktSW5mbzogPHNpcDphbm9ueW1vdXNAYW5v bnltb3VzLmludmFsaWQ+O2luZGV4PTEuMS4xO3JjPTEKICAgICBIaXN0b3J5LUluZm86IDxz aXA6YW5vbnltb3VzQGFub255bW91cy5pbnZhbGlkPjtpbmRleD0xLjEuMjtyYz0xLjEKISAg ICBDb250YWN0OiBCb2IgPHNpcDpib2JAMTkyLjAuMS4xNT4KICAgICBDb250ZW50LVR5cGU6 IGFwcGxpY2F0aW9uL3NkcAogICAgIENvbnRlbnQtTGVuZ3RoOiA8YXBwcm9wcmlhdGUgdmFs dWU+CiAgICAgPCEtLSBTRFAgTm90IFNob3duIC0tPgo= --Boundary-TYzhXHhK5unLiPxPYvbGj-- From pkyzivat@alum.mit.edu Thu Dec 5 08:36:07 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B8C1AE0A3 for ; Thu, 5 Dec 2013 08:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKJgMLUTCU8D for ; Thu, 5 Dec 2013 08:36:06 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id CD8411AE0DA for ; Thu, 5 Dec 2013 08:36:05 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta07.westchester.pa.mail.comcast.net with comcast id xoeS1m0010vyq2s57sc28C; Thu, 05 Dec 2013 16:36:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id xsc11m0023ZTu2S3Rsc1BW; Thu, 05 Dec 2013 16:36:02 +0000 Message-ID: <52A0AB71.3030204@alum.mit.edu> Date: Thu, 05 Dec 2013 11:36:01 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org References: <20131107182721.8391.35063.idtracker@ietfa.amsl.com> <9CCEF1A60DA830shinji.okumura@softfront.jp> In-Reply-To: <9CCEF1A60DA830shinji.okumura@softfront.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386261362; bh=+hJsDgYrkiLUVtQ6HTeovNeKv0FBoIBaBKo0d7iqB58=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lox5Zwif/n9uN0b8lLjunUOaaGtu0MepxLSpTfecMOjwL1vntl+hTuxkVSAVoEJpk gIWPh1NL1lcoDJzNuqz7xBjoNw/5afFiAcUEjccqanekziKm/gIwIhTItaA9HuktX6 Rb3dVI5qMCeHF3+lK+ZebsmH3g73Gc8C1u+ybHuUHTZBojHZFsrfN2Aya07J3EYeTI m1BEHQX5gIaBNj5FL5ZB9w8vvji1/sD0lOUqSW/Q/xrCFwqkYoAxwjG9QC8+QkTNnH lB4jaXRbxeOPPI70Dza0cxDxJ6enOEYYxkVSRLPeyOE94W+zg1D2BbhtomwkXq1BK/ eVzdl24MagzoQ== Cc: sipcore@ietf.org, "sipcore-chairs@tools.ietf.org" Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-callflows-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 16:36:07 -0000 Authors - please look at these and comment if you believe they are valid. Comments from others are also welcome on this. I'll note that it is very late in the process to get changes. Potentially there is an opportunity during AUTH48. Thanks, Paul On 12/5/13 5:37 AM, OKUMURA Shinji wrote: > Hi, > > I attach diff files. > Please reflect a new version, if correct. > > And one question. > Is it correct certainly that the index-val of rc/np parameter is a just parent of hi-index at all times? > i.e. > History-Info: ;index=x.y.z;rc=x.y > > Or case by case? > > Regards > Shinji > > internet-drafts@ietf.org > Thu, 07 Nov 2013 10:27:21 -0800 >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. >> >> Title : Session Initiation Protocol (SIP) History-Info Header Call Flow Examples >> Author(s) : Mary Barnes >> Francois Audet >> Shida Schubert >> Hans Erik van Elburg >> Christer Holmberg >> Filename : draft-ietf-sipcore-rfc4244bis-callflows-08.txt >> Pages : 48 >> Date : 2013-11-07 >> >> Abstract: >> This document describes use cases and documents call flows which >> require the History-Info header field to capture the Request-URIs as >> a Session Initiation Protocol (SIP) Request is retargeted. The use >> cases are described along with the corresponding call flow diagrams >> and messaging details. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-callflows-08 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4244bis-callflows-08 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore From mary.ietf.barnes@gmail.com Thu Dec 5 08:45:13 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA701AE0F5 for ; Thu, 5 Dec 2013 08:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpesC1QlPJM8 for ; Thu, 5 Dec 2013 08:45:11 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id A74D01AE0E2 for ; Thu, 5 Dec 2013 08:45:03 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id en1so10116786wid.3 for ; Thu, 05 Dec 2013 08:44:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fH2h16M4tISyIcGa0+K+nNtRMv4S0dJFG2ggauCiXZA=; b=sKsCife0KhAfo/1+9WPBtPRctvFxeRlwWrHtXWzjKUdJmDfDRd/39/7WPOLGWoYxNv vGGJOcmzGKc/PvptMXi/qaUzeORfflJsczF8jhxOwkU8NwwF7Y4DlwdVObOCmMr/hkgJ MRDd84Q8xi9fn6aEJDA+0ByijWn4Cd5GBDPIht74E/xv71KHOvVIntR2Qgx5WmTmiDP+ Zt4kCk2UEEpIHf/PbGRSxsvupFpBeVoQGtvhAlnI41WwukEtxwmm5eukKk63zlKcdIvc ZkYk9V/2VKw2043UKZFA1VVTXpv+m9Te06rkSNMJ7nYcx9sAxK/EORWb5zA9bW3x0fYg P+9Q== MIME-Version: 1.0 X-Received: by 10.180.188.229 with SMTP id gd5mr12988773wic.38.1386261899759; Thu, 05 Dec 2013 08:44:59 -0800 (PST) Received: by 10.216.172.9 with HTTP; Thu, 5 Dec 2013 08:44:59 -0800 (PST) In-Reply-To: <52A0AB71.3030204@alum.mit.edu> References: <20131107182721.8391.35063.idtracker@ietfa.amsl.com> <9CCEF1A60DA830shinji.okumura@softfront.jp> <52A0AB71.3030204@alum.mit.edu> Date: Thu, 5 Dec 2013 10:44:59 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11c37e8e19d8f804eccc40c7 Cc: "sipcore-chairs@tools.ietf.org" , "draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org" , SIPCORE Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-callflows-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 16:45:13 -0000 --001a11c37e8e19d8f804eccc40c7 Content-Type: text/plain; charset=ISO-8859-1 My preference is for individuals to send the comments in line in the email (as we do for all official reviews). It's very tedious to expect authors to sift through a diff and more importantly it makes any of the details impossible to find if you're googling. As you note, the changes are very late in the process. Mary. On Thu, Dec 5, 2013 at 10:36 AM, Paul Kyzivat wrote: > Authors - please look at these and comment if you believe they are valid. > > Comments from others are also welcome on this. > > I'll note that it is very late in the process to get changes. Potentially > there is an opportunity during AUTH48. > > Thanks, > Paul > > > On 12/5/13 5:37 AM, OKUMURA Shinji wrote: > >> Hi, >> >> I attach diff files. >> Please reflect a new version, if correct. >> >> And one question. >> Is it correct certainly that the index-val of rc/np parameter is a just >> parent of hi-index at all times? >> i.e. >> History-Info: ;index=x.y.z;rc=x.y >> >> Or case by case? >> >> Regards >> Shinji >> >> internet-drafts@ietf.org >> Thu, 07 Nov 2013 10:27:21 -0800 >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Session Initiation Protocol Core >>> Working Group of the IETF. >>> >>> Title : Session Initiation Protocol (SIP) History-Info >>> Header Call Flow Examples >>> Author(s) : Mary Barnes >>> Francois Audet >>> Shida Schubert >>> Hans Erik van Elburg >>> Christer Holmberg >>> Filename : draft-ietf-sipcore-rfc4244bis-callflows-08.txt >>> Pages : 48 >>> Date : 2013-11-07 >>> >>> Abstract: >>> This document describes use cases and documents call flows which >>> require the History-Info header field to capture the Request-URIs as >>> a Session Initiation Protocol (SIP) Request is retargeted. The use >>> cases are described along with the corresponding call flow diagrams >>> and messaging details. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-callflows-08 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore- >>> rfc4244bis-callflows-08 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a11c37e8e19d8f804eccc40c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My preference is for individuals to send the comments in l= ine in the email (as we do for all official reviews). =A0It's very tedi= ous to expect authors to sift through a diff and more importantly it makes = any of the details impossible to find if you're googling.=A0

As you note, the changes are very late in the process.

Mary.
<= br>
On Thu, Dec 5, 2013 at 10:36 AM, Paul Kyz= ivat <pkyzivat@alum.mit.edu> wrote:
Authors - please look at these and comment i= f you believe they are valid.

Comments from others are also welcome on this.

I'll note that it is very late in the process to get changes. Potential= ly there is an opportunity during AUTH48.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


On 12/5/13 5:37 AM, OKUMURA Shinji wrote:
Hi,

I attach diff files.
Please reflect a new version, if correct.

And one question.
Is it correct certainly that the index-val of rc/np parameter is a just par= ent of hi-index at all times?
i.e.
=A0 History-Info: <sip:xxx>;index=3Dx.y.z;rc=3Dx.y

Or case by case?

Regards
Shinji

internet-draf= ts@ietf.org
Thu, 07 Nov 2013 10:27:21 -0800

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Session Initiation Protocol Core Working G= roup of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Session Initiation Protocol (SI= P) History-Info Header Call Flow Examples
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Mary Barnes
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Francois Audet
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Shida Schubert
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hans Erik van Elburg =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Christer Holmberg
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-sipcore-rfc4244bis-= callflows-08.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 48
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-11-07

Abstract:
=A0 =A0This document describes use cases and documents call flows which
=A0 =A0require the History-Info header field to capture the Request-URIs as=
=A0 =A0a Session Initiation Protocol (SIP) Request is retargeted. =A0The us= e
=A0 =A0cases are described along with the corresponding call flow diagrams<= br> =A0 =A0and messaging details.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-i= etf-sipcore-rfc4244bis-callflows

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sipco= re-rfc4244bis-callflows-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3D= draft-ietf-sipcore-rfc4244bis-callflows-08


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/


_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--001a11c37e8e19d8f804eccc40c7-- From shinji.okumura@softfront.jp Fri Dec 6 02:54:47 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB08F1AE323 for ; Fri, 6 Dec 2013 02:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.17 X-Spam-Level: X-Spam-Status: No, score=-97.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, SPF_HELO_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJBEEcdJNZ36 for ; Fri, 6 Dec 2013 02:54:44 -0800 (PST) Received: from softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by ietfa.amsl.com (Postfix) with ESMTP id 6708E1AD9AD for ; Fri, 6 Dec 2013 02:54:42 -0800 (PST) Received: from localhost (sf-mail [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id DB3B24280C7; Fri, 6 Dec 2013 19:54:37 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVAxjfwqZNJU; Fri, 6 Dec 2013 19:54:37 +0900 (JST) Received: from softfront.jp (sf-pc-111.softfront.local [172.16.33.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 2FB7B42800B; Fri, 6 Dec 2013 19:54:36 +0900 (JST) From: OKUMURA Shinji To: Mary Barnes , Paul Kyzivat Date: Fri, 06 Dec 2013 19:54:35 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.01 (WinNT,601) In-Reply-To: References: <20131107182721.8391.35063.idtracker@ietfa.amsl.com> <9CCEF1A60DA830shinji.okumura@softfront.jp> <52A0AB71.3030204@alum.mit.edu> Message-Id: Cc: "draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org" , SIPCORE Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-callflows-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 10:54:48 -0000 Paul and Mary, As you say, my comment is too late, sorry. But I just want to know which are my comment and question valid or not? Regards Shinji Mary Barnes Thu, 5 Dec 2013 10:44:59 -0600 >My preference is for individuals to send the comments in line in the email >(as we do for all official reviews). It's very tedious to expect authors >to sift through a diff and more importantly it makes any of the details >impossible to find if you're googling. > >As you note, the changes are very late in the process. > >Mary. > > >On Thu, Dec 5, 2013 at 10:36 AM, Paul Kyzivat wrote: > >> Authors - please look at these and comment if you believe they are valid. >> >> Comments from others are also welcome on this. >> >> I'll note that it is very late in the process to get changes. Potentially >> there is an opportunity during AUTH48. >> >> Thanks, >> Paul >> >> >> On 12/5/13 5:37 AM, OKUMURA Shinji wrote: >> >>> Hi, >>> >>> I attach diff files. >>> Please reflect a new version, if correct. >>> >>> And one question. >>> Is it correct certainly that the index-val of rc/np parameter is a just >>> parent of hi-index at all times? >>> i.e. >>> History-Info: ;index=x.y.z;rc=x.y >>> >>> Or case by case? >>> >>> Regards >>> Shinji >>> >>> internet-drafts@ietf.org >>> Thu, 07 Nov 2013 10:27:21 -0800 >>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Session Initiation Protocol Core >>>> Working Group of the IETF. >>>> >>>> Title : Session Initiation Protocol (SIP) History-Info >>>> Header Call Flow Examples >>>> Author(s) : Mary Barnes >>>> Francois Audet >>>> Shida Schubert >>>> Hans Erik van Elburg >>>> Christer Holmberg >>>> Filename : draft-ietf-sipcore-rfc4244bis-callflows-08.txt >>>> Pages : 48 >>>> Date : 2013-11-07 >>>> >>>> Abstract: >>>> This document describes use cases and documents call flows which >>>> require the History-Info header field to capture the Request-URIs as >>>> a Session Initiation Protocol (SIP) Request is retargeted. The use >>>> cases are described along with the corresponding call flow diagrams >>>> and messaging details. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-callflows-08 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore- >>>> rfc4244bis-callflows-08 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ From oej@edvina.net Fri Dec 6 05:20:27 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4441ADFAD for ; Fri, 6 Dec 2013 05:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i01z0-p_YTw2 for ; Fri, 6 Dec 2013 05:20:23 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id B00F61AE387 for ; Fri, 6 Dec 2013 05:20:22 -0800 (PST) Received: from [192.168.40.22] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id DCD9093C2A1; Fri, 6 Dec 2013 13:20:17 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Dec 2013 14:20:17 +0100 Message-Id: To: SIPCORE WG Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Cc: Olle E Johansson Subject: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 13:20:27 -0000 Hi! Coming back to an earlier discussion, it seemed to me that we had a few = people that supported adding IPv6 dual stack issues to the charter of = this wg - if it's not in there already.=20 I would like to propose that we add this to the charter and that we plan = a meeting at the IETF in London to discuss this and happy eyeballs = issues. We have two drafts in the pipeline and one that should have been written = about the actual happy eyeballs connection setup, but currently only = exists as promiseware... /O= From mary.ietf.barnes@gmail.com Fri Dec 6 06:11:32 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982D51ADFB5 for ; Fri, 6 Dec 2013 06:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iManXRYAhTy3 for ; Fri, 6 Dec 2013 06:11:30 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C2FF41ADF43 for ; Fri, 6 Dec 2013 06:11:29 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id u57so714303wes.32 for ; Fri, 06 Dec 2013 06:11:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PBQ6LyXvb13rFSNLJ5c+x/jCNQnPreOGneDnNiOcl2E=; b=0gdnruhClpPFiFt0Ax4nPnhPaVQa4TVo3scvdAc9jPpX4O897stkuwRfn+ynlqP3Bg n1tVodzhGviwqz9CO0VVi2efb1eirhsVCywUWGsMrX7ulglxnVMTNOlKtDrpHiE+KfOv xOYOc2dsfBHuK5oIxQR7U+dliY7XOfJ44mi4IVVnwQWczqjFpkSUXAQEoOvzFWroHhkm PRrfLu9ve1XAEGfLPHGH3hnFAFB4O+qvMOxR1BBV20Jho0MSu8onQTc2BIysRmg/YcoE i+HYUPfDSTwEWUwSg2fWW0om+P9CIOp8rio3SrWw+lI5a4yB2l03545VFIseE2WPaSvA 2eCA== MIME-Version: 1.0 X-Received: by 10.180.206.41 with SMTP id ll9mr2608610wic.7.1386339085496; Fri, 06 Dec 2013 06:11:25 -0800 (PST) Received: by 10.216.172.9 with HTTP; Fri, 6 Dec 2013 06:11:25 -0800 (PST) In-Reply-To: References: <20131107182721.8391.35063.idtracker@ietfa.amsl.com> <9CCEF1A60DA830shinji.okumura@softfront.jp> <52A0AB71.3030204@alum.mit.edu> Date: Fri, 6 Dec 2013 08:11:25 -0600 Message-ID: From: Mary Barnes To: OKUMURA Shinji Content-Type: multipart/alternative; boundary=001a11c38882bab56704ecde3857 Cc: "draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org" , SIPCORE Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-callflows-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 14:11:32 -0000 --001a11c38882bab56704ecde3857 Content-Type: text/plain; charset=ISO-8859-1 We will review your comments and get back to you shortly (we won't ignore your input that may be valid). Thanks, Mary. On Fri, Dec 6, 2013 at 4:54 AM, OKUMURA Shinji wrote: > Paul and Mary, > > As you say, my comment is too late, sorry. > > But I just want to know which are my comment and question valid or not? > > Regards > Shinji > > Mary Barnes > Thu, 5 Dec 2013 10:44:59 -0600 > >My preference is for individuals to send the comments in line in the email > >(as we do for all official reviews). It's very tedious to expect authors > >to sift through a diff and more importantly it makes any of the details > >impossible to find if you're googling. > > > >As you note, the changes are very late in the process. > > > >Mary. > > > > > >On Thu, Dec 5, 2013 at 10:36 AM, Paul Kyzivat > wrote: > > > >> Authors - please look at these and comment if you believe they are > valid. > >> > >> Comments from others are also welcome on this. > >> > >> I'll note that it is very late in the process to get changes. > Potentially > >> there is an opportunity during AUTH48. > >> > >> Thanks, > >> Paul > >> > >> > >> On 12/5/13 5:37 AM, OKUMURA Shinji wrote: > >> > >>> Hi, > >>> > >>> I attach diff files. > >>> Please reflect a new version, if correct. > >>> > >>> And one question. > >>> Is it correct certainly that the index-val of rc/np parameter is a just > >>> parent of hi-index at all times? > >>> i.e. > >>> History-Info: ;index=x.y.z;rc=x.y > >>> > >>> Or case by case? > >>> > >>> Regards > >>> Shinji > >>> > >>> internet-drafts@ietf.org > >>> Thu, 07 Nov 2013 10:27:21 -0800 > >>> > >>>> > >>>> A New Internet-Draft is available from the on-line Internet-Drafts > >>>> directories. > >>>> This draft is a work item of the Session Initiation Protocol Core > >>>> Working Group of the IETF. > >>>> > >>>> Title : Session Initiation Protocol (SIP) > History-Info > >>>> Header Call Flow Examples > >>>> Author(s) : Mary Barnes > >>>> Francois Audet > >>>> Shida Schubert > >>>> Hans Erik van Elburg > >>>> Christer Holmberg > >>>> Filename : > draft-ietf-sipcore-rfc4244bis-callflows-08.txt > >>>> Pages : 48 > >>>> Date : 2013-11-07 > >>>> > >>>> Abstract: > >>>> This document describes use cases and documents call flows which > >>>> require the History-Info header field to capture the Request-URIs > as > >>>> a Session Initiation Protocol (SIP) Request is retargeted. The use > >>>> cases are described along with the corresponding call flow diagrams > >>>> and messaging details. > >>>> > >>>> > >>>> The IETF datatracker status page for this draft is: > >>>> > https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows > >>>> > >>>> There's also a htmlized version available at: > >>>> http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-callflows-08 > >>>> > >>>> A diff from the previous version is available at: > >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore- > >>>> rfc4244bis-callflows-08 > >>>> > >>>> > >>>> Please note that it may take a couple of minutes from the time of > >>>> submission > >>>> until the htmlized version and diff are available at tools.ietf.org. > >>>> > >>>> Internet-Drafts are also available by anonymous FTP at: > >>>> ftp://ftp.ietf.org/internet-drafts/ > --001a11c38882bab56704ecde3857 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We will review your comments and get back to you shortly (= we won't ignore your input that may be valid).

Thanks,
Mary.

On Fri, Dec 6, 2013 at 4:54 AM, OKUMURA Shinji <= span dir=3D"ltr"><shinji.okumura@softfront.jp> wrote:
Paul and Mary,

As you say, my comment is too late, sorry.

But I just want to know which are my comment and question valid or not?

Regards
Shinji

Mary Barnes <mary.ietf.bar= nes@gmail.com>
Thu, 5 Dec 2013 10:44:59 -0600
>My preference is for individual= s to send the comments in line in the email
>(as we do for all official reviews). =A0It's very tedious to expect= authors
>to sift through a diff and more importantly it makes any of the details=
>impossible to find if you're googling.
>
>As you note, the changes are very late in the process.
>
>Mary.
>
>
>On Thu, Dec 5, 2013 at 10:36 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>
>> Authors - please look at these and comment if you believe they are= valid.
>>
>> Comments from others are also welcome on this.
>>
>> I'll note that it is very late in the process to get changes. = Potentially
>> there is an opportunity during AUTH48.
>>
>> =A0 =A0 =A0 =A0 Thanks,
>> =A0 =A0 =A0 =A0 Paul
>>
>>
>> On 12/5/13 5:37 AM, OKUMURA Shinji wrote:
>>
>>> Hi,
>>>
>>> I attach diff files.
>>> Please reflect a new version, if correct.
>>>
>>> And one question.
>>> Is it correct certainly that the index-val of rc/np parameter = is a just
>>> parent of hi-index at all times?
>>> i.e.
>>> =A0 History-Info: <sip:xxx>;index=3Dx.y.z;rc=3Dx.y
>>>
>>> Or case by case?
>>>
>>> Regards
>>> Shinji
>>>
>>> internet-drafts@ie= tf.org
>>> Thu, 07 Nov 2013 10:27:21 -0800
>>>
>>>>
>>>> A New Internet-Draft is available from the on-line Interne= t-Drafts
>>>> directories.
>>>> This draft is a work item of the Session Initiation Protoc= ol Core
>>>> Working Group of the IETF.
>>>>
>>>> =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Session Initia= tion Protocol (SIP) History-Info
>>>> Header Call Flow Examples
>>>> =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Mary Barnes
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Franco= is Audet
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Shida = Schubert
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hans E= rik van Elburg
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Christ= er Holmberg
>>>> =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-sipco= re-rfc4244bis-callflows-08.txt
>>>> =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 48
>>>> =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-11-07 >>>>
>>>> Abstract:
>>>> =A0 =A0This document describes use cases and documents cal= l flows which
>>>> =A0 =A0require the History-Info header field to capture th= e Request-URIs as
>>>> =A0 =A0a Session Initiation Protocol (SIP) Request is reta= rgeted. =A0The use
>>>> =A0 =A0cases are described along with the corresponding ca= ll flow diagrams
>>>> =A0 =A0and messaging details.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/d= oc/draft-ietf-sipcore-rfc4244bis-callflows
>>>>
>>>> There's also a htmlized version available at:
>>>> http://tools.ietf.org/html/draft-= ietf-sipcore-rfc4244bis-callflows-08
>>>>
>>>> A diff from the previous version is available at:
>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-si= pcore-
>>>> rfc4244bis-callflows-08
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the = time of
>>>> submission
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/

--001a11c38882bab56704ecde3857-- From pkyzivat@alum.mit.edu Fri Dec 6 09:28:51 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9521ADF6E for ; Fri, 6 Dec 2013 09:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-m5Uzm66_us for ; Fri, 6 Dec 2013 09:28:50 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 8499E1AE03F for ; Fri, 6 Dec 2013 09:28:50 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta13.westchester.pa.mail.comcast.net with comcast id yGr71m0060xGWP85DHUmBo; Fri, 06 Dec 2013 17:28:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id yHUm1m00b3ZTu2S3YHUmpm; Fri, 06 Dec 2013 17:28:46 +0000 Message-ID: <52A2094E.8020009@alum.mit.edu> Date: Fri, 06 Dec 2013 12:28:46 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386350926; bh=W2W56zZeWFobnwZFzHqTDNLbWQ+lN98MPO1LOYJvQ2A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FlynpKVl8S7PKvUQVnU0DQSghQ56qTWrccPwY1gofSKcnmNtmC8t4GZwNIDd/Mlw2 Yd2pAzMoaCkKBIzUAIaJEqe566JWV45RsBhxjWof5bQx4PHj/qAym8FH+piLRb8AlS oR4SJPuUWiA2MD3b8XZCXxA/4BCASe3KZJmEdGmdVT/b6JeHUfdJ8ypJWrVCDEjXcw 3u3qpKVsT9+Y2UCHt982Ibb9LxcXSoKZ0VBaYA8jeZ1xKlWFllPRuf5UwtZa7ZE+RT SIPSF6e+hOL/oOtn07coOwaXFdY4lUPIAUs5PxL9nbnyacBPRjdcbVxf7gLoYDAOY8 0z60hS0XUb8nw== Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 17:28:51 -0000 Olle, Yes, this is something it seems evident we should take on. I don't believe we need to change the "charter", but we should add a milestone for this. If you would like to propose milestone text (in the same style as the existing milestones) and take a first guess at a date for it, that would be great. Now that we have this, and some other things, that are on the table we are planning on having a sipcore session in London. This will be one (or more) of the agenda items for that meeting. Thanks, Paul On 12/6/13 8:20 AM, Olle E. Johansson wrote: > Hi! > > Coming back to an earlier discussion, it seemed to me that we had a few people that supported adding IPv6 dual stack issues to the charter of this wg - if it's not in there already. > > I would like to propose that we add this to the charter and that we plan a meeting at the IETF in London to discuss this and happy eyeballs issues. > > We have two drafts in the pipeline and one that should have been written about the actual happy eyeballs connection setup, but currently only exists as promiseware... > > /O > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From brett@broadsoft.com Sat Dec 7 10:24:28 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453571AE3CF for ; Sat, 7 Dec 2013 10:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vL_Vs4m7jRxA for ; Sat, 7 Dec 2013 10:24:26 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id 30ABE1AE3B5 for ; Sat, 7 Dec 2013 10:24:26 -0800 (PST) Received: from CASUMHUB03.citservers.local (172.16.98.219) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sat, 7 Dec 2013 10:26:15 -0800 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Sat, 7 Dec 2013 10:26:15 -0800 From: Brett Tate To: "sipcore@ietf.org" Thread-Topic: RFC 3261: 305 Use Proxy Thread-Index: Ac7zeYtfzrfjjjZ2SuC5iKD08D8RQQ== Date: Sat, 7 Dec 2013 18:26:13 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A06D0EA@MBX08.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] RFC 3261: 305 Use Proxy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 18:24:28 -0000 Hi, As indicated within the following snippet from draft-rosenberg-sip-route-co= nstruct-01, the 305 response is underspecified within RFC 3261. What is the expected behavior concerning how to handle a 305's Contact: rep= lace Request-URI or utilized as a Route header? The snippet indicates that= the unstated assumption is that it populates the Request-URI. Thanks, Brett ----- 2.4 305 Use Proxy RFC 3261 defines the 305 "Use Proxy" response code, but says extremely little about exactly how it is used. It has this to say: The requested resource MUST be accessed through the proxy given by the Contact field. The Contact field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 (Use Proxy) responses MUST only be generated by UASs. It is unclear how the Contact in the redirect is used. Does it populate the request URI of the resulting request? Or, does it get used to populate the Route header field? The restriction to UASs is also not explained. Historically, the reason for the restriction to UAs was to avoid routing loops. Consider an outbound proxy that generates a 305, instead of proxying the request. The concern was that the client would then recurse on the response, populate the Contact into a new request URI, and send the request to its default outbound proxy, which redirects once more. To avoid this, the RFC says that only a UAS can redirect with a 305, not a proxy. However, this design decision on 305 handling was made prior to the conception of loose routing, although both ended up in RFC 3261. The design of the 305 mechanism, unfortunately, was not revisited after loose routing was specified. As such, the draft is not clear about whether or not the contact gets utilized as a Route header field value or whether it replaces the Request URI. The assumption, unstated, is that it populates the Request-URI, since redirection works that way in general. This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, and destroy = all copies of this message, along with any attachment, prior to reading, di= stributing or copying it. From pkyzivat@alum.mit.edu Sat Dec 7 10:54:50 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAD51AE12F for ; Sat, 7 Dec 2013 10:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hys5u2yjXTbY for ; Sat, 7 Dec 2013 10:54:48 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECEC1AE0FC for ; Sat, 7 Dec 2013 10:54:47 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta10.westchester.pa.mail.comcast.net with comcast id yiXe1m0051swQuc5Aiuj7T; Sat, 07 Dec 2013 18:54:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id yiuj1m00B3ZTu2S3biujCu; Sat, 07 Dec 2013 18:54:43 +0000 Message-ID: <52A36EF3.3040702@alum.mit.edu> Date: Sat, 07 Dec 2013 13:54:43 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <576A8B541C219D4E9CEB1DF8C19C7B881A06D0EA@MBX08.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B881A06D0EA@MBX08.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386442483; bh=mfmdZlieULZpTHcn47IqVgnSWU5QSonjHd8sUrC5bTw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Nu9dqA77J6jx7G3qpVT4k5gz+EweSNzedzkg0G2PA7tzzeUzIfQbbEvjyLw37EMhx +luLmqMlEGdevUBqPGaNPRu4dHEDnser7C6d9Ylf3u+1jN4Wwlrn4I4NAUIuLX4R0M XKv3GHhFRyflStFLuBW4qyQNfj4yRP/dAZNGYsIrqxTWMczilx44g4C6gj4Dgs+Ys4 wjLeMZ6bYa5PYzBtzl5AyTWLpPf/4BcIbWm2QuuXRTJwwlj1bdSkiKRGy690GuaCyc q3sk2pjHFiN/yuOO/AILOBMLfTwhebbUA0RTdZo8NtcQIP3MdPbjKzXF77koCN9wZk 3wuYf3hp1Zw9A== Subject: Re: [sipcore] RFC 3261: 305 Use Proxy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 18:54:50 -0000 On 12/7/13 1:26 PM, Brett Tate wrote: > Hi, > > As indicated within the following snippet from draft-rosenberg-sip-route-construct-01, the 305 response is underspecified within RFC 3261. > > What is the expected behavior concerning how to handle a 305's Contact: replace Request-URI or utilized as a Route header? The snippet indicates that the unstated assumption is that it populates the Request-URI. I don't know. AFAIK this was never satisfactorily clarified. If we wanted to clarify this, I think the first thing we would want to do is take a survey of any known current uses of 305. (Hopefully there are none, because nobody knows how to use it.) Thanks, Paul > Thanks, > Brett > > ----- > > 2.4 305 Use Proxy > > RFC 3261 defines the 305 "Use Proxy" response code, but says > extremely little about exactly how it is used. It has this to say: > > The requested resource MUST be accessed through the proxy given by > the Contact field. The Contact field gives the URI of the proxy. > The recipient is expected to repeat this single request via the > proxy. 305 (Use Proxy) responses MUST only be generated by UASs. > > It is unclear how the Contact in the redirect is used. Does it > populate the request URI of the resulting request? Or, does it get > used to populate the Route header field? The restriction to UASs is > also not explained. > > Historically, the reason for the restriction to UAs was to avoid > routing loops. Consider an outbound proxy that generates a 305, > instead of proxying the request. The concern was that the client > would then recurse on the response, populate the Contact into a new > request URI, and send the request to its default outbound proxy, > which redirects once more. To avoid this, the RFC says that only a > UAS can redirect with a 305, not a proxy. > > However, this design decision on 305 handling was made prior to the > conception of loose routing, although both ended up in RFC 3261. The > design of the 305 mechanism, unfortunately, was not revisited after > loose routing was specified. As such, the draft is not clear about > whether or not the contact gets utilized as a Route header field > value or whether it replaces the Request URI. The assumption, > unstated, is that it populates the Request-URI, since redirection > works that way in general. > > This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From aallen@blackberry.com Sat Dec 7 20:56:48 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7601AD7BF for ; Sat, 7 Dec 2013 20:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEYHcma75saO for ; Sat, 7 Dec 2013 20:56:46 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3ED1AD6D1 for ; Sat, 7 Dec 2013 20:56:45 -0800 (PST) Received: from xct101ads.rim.net ([10.67.111.42]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 07 Dec 2013 23:56:34 -0500 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.03.0158.001; Sat, 7 Dec 2013 22:56:33 -0600 From: Andrew Allen To: "pkyzivat@alum.mit.edu" , "sipcore@ietf.org" Thread-Topic: [sipcore] RFC 3261: 305 Use Proxy Thread-Index: Ac7zeYtfzrfjjjZ2SuC5iKD08D8RQQANol6AAAhyCrM= Date: Sun, 8 Dec 2013 04:56:32 +0000 Message-ID: In-Reply-To: <52A36EF3.3040702@alum.mit.edu> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.253] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] RFC 3261: 305 Use Proxy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 04:56:48 -0000 Paul 3GPP specifications make use of the 305 Use Proxy response but don't go int= o details of how the Contact header is utilised. My assumption is that the Route header is used as this is used to redirect = an INVITE request via a different proxy and so you need to preserve the Req= uest-URI which contains the address of the destination UA. This behavior also seems to align with the loose routing concepts of RFC 32= 61 - i.e. you leave the Request-URI alone when routing. Andrew ----- Original Message ----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Saturday, December 07, 2013 01:54 PM Eastern Standard Time To: sipcore@ietf.org Subject: Re: [sipcore] RFC 3261: 305 Use Proxy On 12/7/13 1:26 PM, Brett Tate wrote: > Hi, > > As indicated within the following snippet from draft-rosenberg-sip-route-= construct-01, the 305 response is underspecified within RFC 3261. > > What is the expected behavior concerning how to handle a 305's Contact: r= eplace Request-URI or utilized as a Route header? The snippet indicates th= at the unstated assumption is that it populates the Request-URI. I don't know. AFAIK this was never satisfactorily clarified. If we wanted to clarify this, I think the first thing we would want to = do is take a survey of any known current uses of 305. (Hopefully there = are none, because nobody knows how to use it.) Thanks, Paul > Thanks, > Brett > > ----- > > 2.4 305 Use Proxy > > RFC 3261 defines the 305 "Use Proxy" response code, but says > extremely little about exactly how it is used. It has this to say: > > The requested resource MUST be accessed through the proxy given by > the Contact field. The Contact field gives the URI of the proxy. > The recipient is expected to repeat this single request via the > proxy. 305 (Use Proxy) responses MUST only be generated by UASs. > > It is unclear how the Contact in the redirect is used. Does it > populate the request URI of the resulting request? Or, does it get > used to populate the Route header field? The restriction to UASs is > also not explained. > > Historically, the reason for the restriction to UAs was to avoid > routing loops. Consider an outbound proxy that generates a 305, > instead of proxying the request. The concern was that the client > would then recurse on the response, populate the Contact into a new > request URI, and send the request to its default outbound proxy, > which redirects once more. To avoid this, the RFC says that only a > UAS can redirect with a 305, not a proxy. > > However, this design decision on 305 handling was made prior to the > conception of loose routing, although both ended up in RFC 3261. The > design of the 305 mechanism, unfortunately, was not revisited after > loose routing was specified. As such, the draft is not clear about > whether or not the contact gets utilized as a Route header field > value or whether it replaces the Request URI. The assumption, > unstated, is that it populates the Request-URI, since redirection > works that way in general. > > This email is intended solely for the person or entity to which it is add= ressed and may contain confidential and/or privileged information. If you a= re not the intended recipient and have received this email in error, please= notify BroadSoft, Inc. immediately by replying to this message, and destro= y all copies of this message, along with any attachment, prior to reading, = distributing or copying it. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From brett@broadsoft.com Mon Dec 9 04:54:10 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861F11AE2AF for ; Mon, 9 Dec 2013 04:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PB7Gsd7BEZjy for ; Mon, 9 Dec 2013 04:54:07 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id 84E0B1ADF32 for ; Mon, 9 Dec 2013 04:54:07 -0800 (PST) Received: from CASUMHUB04.citservers.local (172.16.98.225) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 9 Dec 2013 04:55:57 -0800 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Mon, 9 Dec 2013 04:55:57 -0800 From: Brett Tate To: Andrew Allen , "pkyzivat@alum.mit.edu" , "sipcore@ietf.org" Thread-Topic: [sipcore] RFC 3261: 305 Use Proxy Thread-Index: Ac7zeYtfzrfjjjZ2SuC5iKD08D8RQQANol6AAAhyCrMAQGnC4A== Date: Mon, 9 Dec 2013 12:55:56 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A06D259@MBX08.citservers.local> References: <52A36EF3.3040702@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] RFC 3261: 305 Use Proxy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:54:10 -0000 > 3GPP specifications make use of the 305 Use Proxy response=20 > but don't go into details of how the Contact header is utilised. Sounds like RFC 3261. :) How does 3GPP interpret "305 (Use Proxy) responses MUST only be generated b= y UASs"? For instance, can proxies and B2BUAs generate 305 responses? If yes, can i= t be sent even though the middle box was not the last loose route entry? Because of all the middle boxes and loose routing within 3GPP (including du= ring call setup), which device does 3GPP expect to act upon the 305? And i= f the immediate hop prior does not act upon the 305 should it proxy the 305= (thus potentially being subsequently bypassed and causing another 305)? > My assumption is that the Route header is used as this is=20 > used to redirect an INVITE request via a different proxy=20 > and so you need to preserve the Request-URI which contains=20 > the address of the destination UA. How does the device acting upon the 305 alter an existing loose route to ac= commodate the Contact? For instance, let's assume that the original INVITE contained a Route to tr= averse 3 proxies (first, second, and third) and no additional Route entries= were added by middle boxes (to simplify the example). How should each pro= xy and UAC adjust the Route if they were to act upon the 305? I assume that a 305 with multiple Contact headers does not indicate to trav= erse multiple proxies. > This behavior also seems to align with the loose=20 > routing concepts of RFC 3261 - i.e. you leave the=20 > Request-URI alone when routing. Loose routing was introduce by RFC 3261. 305 existed within RFC 2543. Bas= ed upon your interpretation, it sounds like RFC 2543 devices acting upon a = 305 would have sent the INVITE to the Contact location without adding a Rou= te and without altering the Request-URI. This interpretation also appears to complicate the default handling discuss= ed within RFC 3261 section 5.1.1. More specifically, the 300 handling of 3= 05 would result in the other interpretation of the 305 (i.e. replace Reques= t-URI). RFC 3261 section 5.1.1: "SIP response codes are extensible. SIP applications are not required to understand the meaning of all registered response codes, though such understanding is obviously desirable. However, applications MUST understand the class of any response code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 response code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if a client receives an unrecognized response code of 431, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 (Bad Request) response code." From carl_klatsky@cable.comcast.com Mon Dec 9 06:32:05 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819461AE263 for ; Mon, 9 Dec 2013 06:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOmTpczKtqep for ; Mon, 9 Dec 2013 06:32:04 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 7721D1ADF34 for ; Mon, 9 Dec 2013 06:32:04 -0800 (PST) Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.75521866; Mon, 09 Dec 2013 09:31:56 -0500 Received: from PACDCEXMB12.cable.comcast.com ([169.254.6.249]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Mon, 9 Dec 2013 09:31:56 -0500 From: "Klatsky, Carl" To: "'sipcore@ietf.org'" Thread-Topic: UAC or UAS Thread-Index: Ac706x/ThtcF14MnRhWvlCKibdf7BA== Date: Mon, 9 Dec 2013 14:31:06 +0000 Message-ID: <6C15A6B88541034E912E94C2D8BC3E87F770AA11@PACDCEXMB12.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.174] x-wiganss: 0100000001001Epacdcexhub03.cable.comcast.com ID0048<6C15A6B88541034E912E94C2D8BC3E87F770AA11@PACDCEXMB12.cable.comcast.com> Content-Type: multipart/alternative; boundary="_000_6C15A6B88541034E912E94C2D8BC3E87F770AA11PACDCEXMB12cabl_" MIME-Version: 1.0 Subject: [sipcore] UAC or UAS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 14:32:05 -0000 --_000_6C15A6B88541034E912E94C2D8BC3E87F770AA11PACDCEXMB12cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi SIPcore, In this exchange between A and B: B sends A an INVITE with no SDP A replies with a 200 OK with SDP B replies with an ACK with SDP Is A the UAS or UAC in this scenario? I thought A would be UAS but wanted = to check with the SIP community. Thanks. Regards, Carl Klatsky Comcast --_000_6C15A6B88541034E912E94C2D8BC3E87F770AA11PACDCEXMB12cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi SIPcore,

 

In this exchange between A and B:

 

B sends A an INVITE with no SDP

A replies with a 200 OK with SDP

B replies with an ACK with SDP

 

Is A the UAS or UAC in this scenario?  I though= t A would be UAS but wanted to check with the SIP community.  Thanks.<= o:p>

 

Regards,

 

Carl Klatsky

Comcast

--_000_6C15A6B88541034E912E94C2D8BC3E87F770AA11PACDCEXMB12cabl_-- From brett@broadsoft.com Mon Dec 9 08:01:39 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FF91AE358 for ; Mon, 9 Dec 2013 08:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8Lxz0IAl7sX for ; Mon, 9 Dec 2013 08:01:36 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id B46271AE373 for ; Mon, 9 Dec 2013 08:01:35 -0800 (PST) Received: from CASUMHUB05.citservers.local (172.16.98.229) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 9 Dec 2013 08:03:25 -0800 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by casumhub05.citservers.local ([::1]) with mapi id 14.02.0247.003; Mon, 9 Dec 2013 08:03:25 -0800 From: Brett Tate To: "sipcore@ietf.org" Thread-Topic: [sipcore] RFC 3261: 305 Use Proxy Thread-Index: Ac7zeYtfzrfjjjZ2SuC5iKD08D8RQQANol6AAAhyCrMAQGnC4AAIovHA Date: Mon, 9 Dec 2013 16:03:23 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A06D2DE@MBX08.citservers.local> References: <52A36EF3.3040702@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B881A06D259@MBX08.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B881A06D259@MBX08.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] RFC 3261: 305 Use Proxy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:01:39 -0000 Hi, I have another 305 question. RFC 3261 section 19.1.2 indicates that the lr parameter is not applicable t= o a redirected Contact. If sipcore decides to allow the 305's Contact to impact the Route, what sho= uld occur concerning the lr parameter? 1) Assume RFC 3261 section 19.1.2 has a bug; lr parameter is optional withi= n a 305's Contact. 2) Cannot loose route to the 305 Contact location. 3) The device building the Route based upon the 305's Contact can assume th= at loose routing is supported and add an lr parameter. 4) Something else. Thanks, Brett > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett Tate > Sent: Monday, December 09, 2013 7:56 AM > To: Andrew Allen; pkyzivat@alum.mit.edu; sipcore@ietf.org > Subject: Re: [sipcore] RFC 3261: 305 Use Proxy >=20 > > 3GPP specifications make use of the 305 Use Proxy response > > but don't go into details of how the Contact header is utilised. >=20 > Sounds like RFC 3261. :) >=20 > How does 3GPP interpret "305 (Use Proxy) responses MUST only be > generated by UASs"? >=20 > For instance, can proxies and B2BUAs generate 305 responses? If yes, > can it be sent even though the middle box was not the last loose route > entry? >=20 > Because of all the middle boxes and loose routing within 3GPP > (including during call setup), which device does 3GPP expect to act > upon the 305? And if the immediate hop prior does not act upon the 305 > should it proxy the 305 (thus potentially being subsequently bypassed > and causing another 305)? >=20 > > My assumption is that the Route header is used as this is > > used to redirect an INVITE request via a different proxy > > and so you need to preserve the Request-URI which contains > > the address of the destination UA. >=20 > How does the device acting upon the 305 alter an existing loose route > to accommodate the Contact? >=20 > For instance, let's assume that the original INVITE contained a Route > to traverse 3 proxies (first, second, and third) and no additional > Route entries were added by middle boxes (to simplify the example). > How should each proxy and UAC adjust the Route if they were to act upon > the 305? >=20 > I assume that a 305 with multiple Contact headers does not indicate to > traverse multiple proxies. >=20 > > This behavior also seems to align with the loose > > routing concepts of RFC 3261 - i.e. you leave the > > Request-URI alone when routing. >=20 > Loose routing was introduce by RFC 3261. 305 existed within RFC 2543. > Based upon your interpretation, it sounds like RFC 2543 devices acting > upon a 305 would have sent the INVITE to the Contact location without > adding a Route and without altering the Request-URI. >=20 > This interpretation also appears to complicate the default handling > discussed within RFC 3261 section 5.1.1. More specifically, the 300 > handling of 305 would result in the other interpretation of the 305 > (i.e. replace Request-URI). >=20 > RFC 3261 section 5.1.1: >=20 > "SIP response codes are extensible. SIP applications are not required > to understand the meaning of all registered response codes, though > such understanding is obviously desirable. However, applications MUST > understand the class of any response code, as indicated by the first > digit, and treat any unrecognized response as being equivalent to the > x00 response code of that class, with the exception that an > unrecognized response MUST NOT be cached. For example, if a client > receives an unrecognized response code of 431, it can safely assume > that there was something wrong with its request and treat the > response as if it had received a 400 (Bad Request) response code." > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From brett@broadsoft.com Mon Dec 9 08:23:22 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FFC1ADFCC for ; Mon, 9 Dec 2013 08:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95YcMzKPuSKT for ; Mon, 9 Dec 2013 08:23:20 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id C9E7B1ADFC8 for ; Mon, 9 Dec 2013 08:23:20 -0800 (PST) Received: from CASUMHUB03.citservers.local (172.16.98.219) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 9 Dec 2013 08:25:11 -0800 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Mon, 9 Dec 2013 08:25:11 -0800 From: Brett Tate To: "Klatsky, Carl" , "'sipcore@ietf.org'" Thread-Topic: UAC or UAS Thread-Index: Ac706x/ThtcF14MnRhWvlCKibdf7BAAA9unQ Date: Mon, 9 Dec 2013 16:25:10 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A06D2ED@MBX08.citservers.local> References: <6C15A6B88541034E912E94C2D8BC3E87F770AA11@PACDCEXMB12.cable.comcast.com> In-Reply-To: <6C15A6B88541034E912E94C2D8BC3E87F770AA11@PACDCEXMB12.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] UAC or UAS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:23:23 -0000 > In this exchange between A and B: >=20 > B sends A an INVITE with no SDP > A replies with a 200 OK with SDP > B replies with an ACK with SDP >=20 > Is A the UAS or UAC in this scenario? A is the UAS. RFC 3261 section 6 contains the definitions. "User Agent Client (UAC): A user agent client is a logical entity that creates a new request, and then uses the client transaction state machinery to send it. The role of UAC lasts only for the duration of that transaction. In other words, if a piece of software initiates a request, it acts as a UAC for the duration of that transaction. If it receives a request later, it assumes the role of a user agent server for the processing of that transaction." "User Agent Server (UAS): A user agent server is a logical entity that generates a response to a SIP request. The response accepts, rejects, or redirects the request. This role lasts only for the duration of that transaction. In other words, if a piece of software responds to a request, it acts as a UAS for the duration of that transaction. If it generates a request later, it assumes the role of a user agent client for the processing of that transaction." If you have other general SIP questions, you might want to post them to sip= -implementors. https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors=20 From keith.drage@alcatel-lucent.com Mon Dec 9 10:49:21 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FEB1AE3DE for ; Mon, 9 Dec 2013 10:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehL6V-XSGUKU for ; Mon, 9 Dec 2013 10:49:19 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 094881ADFB8 for ; Mon, 9 Dec 2013 10:49:18 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rB9In7JF018070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Dec 2013 12:49:09 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rB9In7xn029770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 19:49:07 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 9 Dec 2013 19:49:07 +0100 From: "DRAGE, Keith (Keith)" To: Brett Tate , Andrew Allen , "pkyzivat@alum.mit.edu" , "sipcore@ietf.org" Thread-Topic: [sipcore] RFC 3261: 305 Use Proxy Thread-Index: Ac7zeYtfzrfjjjZ2SuC5iKD08D8RQf//97qAgACoJQCAAhhGAP//jVDQ Date: Mon, 9 Dec 2013 18:49:06 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0F43C9@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <52A36EF3.3040702@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B881A06D259@MBX08.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B881A06D259@MBX08.citservers.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [sipcore] RFC 3261: 305 Use Proxy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 18:49:21 -0000 In answe to your first question, if you generate a 305 response to a reques= t, you are by definition a UAS for that transaction. Our interpretation has always been that you assume a role (UAS or proxy), f= or the transaction (otherwise how can you be a USA for a REGISTER request a= nd an outbound proxy for an INVITE request?). Keith > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > Brett Tate > Sent: 09 December 2013 12:56 > To: Andrew Allen; pkyzivat@alum.mit.edu; sipcore@ietf.org > Subject: Re: [sipcore] RFC 3261: 305 Use Proxy >=20 > > 3GPP specifications make use of the 305 Use Proxy response=20 > but don't=20 > > go into details of how the Contact header is utilised. >=20 > Sounds like RFC 3261. :) >=20 > How does 3GPP interpret "305 (Use Proxy) responses MUST only=20 > be generated by UASs"? >=20 > For instance, can proxies and B2BUAs generate 305 responses? =20 > If yes, can it be sent even though the middle box was not the=20 > last loose route entry? >=20 > Because of all the middle boxes and loose routing within 3GPP=20 > (including during call setup), which device does 3GPP expect=20 > to act upon the 305? And if the immediate hop prior does not=20 > act upon the 305 should it proxy the 305 (thus potentially=20 > being subsequently bypassed and causing another 305)? >=20 > > My assumption is that the Route header is used as this is used to=20 > > redirect an INVITE request via a different proxy and so you need to=20 > > preserve the Request-URI which contains the address of the=20 > destination=20 > > UA. >=20 > How does the device acting upon the 305 alter an existing=20 > loose route to accommodate the Contact? >=20 > For instance, let's assume that the original INVITE contained=20 > a Route to traverse 3 proxies (first, second, and third) and=20 > no additional Route entries were added by middle boxes (to=20 > simplify the example). How should each proxy and UAC adjust=20 > the Route if they were to act upon the 305? >=20 > I assume that a 305 with multiple Contact headers does not=20 > indicate to traverse multiple proxies. >=20 > > This behavior also seems to align with the loose routing=20 > concepts of=20 > > RFC 3261 - i.e. you leave the Request-URI alone when routing. >=20 > Loose routing was introduce by RFC 3261. 305 existed within=20 > RFC 2543. Based upon your interpretation, it sounds like RFC=20 > 2543 devices acting upon a 305 would have sent the INVITE to=20 > the Contact location without adding a Route and without=20 > altering the Request-URI. >=20 > This interpretation also appears to complicate the default=20 > handling discussed within RFC 3261 section 5.1.1. More=20 > specifically, the 300 handling of 305 would result in the=20 > other interpretation of the 305 (i.e. replace Request-URI). >=20 > RFC 3261 section 5.1.1: >=20 > "SIP response codes are extensible. SIP applications are not=20 > required to understand the meaning of all registered=20 > response codes, though such understanding is obviously=20 > desirable. However, applications MUST understand the class=20 > of any response code, as indicated by the first digit, and=20 > treat any unrecognized response as being equivalent to the =20 > x00 response code of that class, with the exception that an =20 > unrecognized response MUST NOT be cached. For example, if a=20 > client receives an unrecognized response code of 431, it can=20 > safely assume that there was something wrong with its=20 > request and treat the response as if it had received a 400=20 > (Bad Request) response code." > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From iesg-secretary@ietf.org Mon Dec 9 11:10:19 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851211AE4C8; Mon, 9 Dec 2013 11:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BsqxNc7hsh9; Mon, 9 Dec 2013 11:10:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9D11AE4CE; Mon, 9 Dec 2013 11:10:16 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131209191016.4782.64732.idtracker@ietfa.amsl.com> Date: Mon, 09 Dec 2013 11:10:16 -0800 Cc: sipcore mailing list , sipcore chair , RFC Editor Subject: [sipcore] Protocol Action: 'The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)' to Proposed Standard (draft-ietf-sipcore-sip-websocket-10.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 19:10:19 -0000 The IESG has approved the following document: - 'The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)' (draft-ietf-sipcore-sip-websocket-10.txt) as Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Richard Barnes and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket/ Technical Summary The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies a new WebSocket sub- protocol as a reliable transport mechanism between SIP (Session Initiation Protocol) entities to enable usage of SIP in new scenarios. Working Group Summary The introduction, adoption, and last call of this document went unusually smoothly and quickly. It has been amazingly uncontroversial. Document Quality Are there existing implementations of the protocol? Yes. At least two. Have a significant number of vendors indicated their plan to implement the specification? At least two. There is a difference of opinion in the community regarding the desirability of implementing SIP in a browser. That portion of the community that is interested seems to be planning to go ahead. It is entirely fine that some want to do this and some do not. It simply reflects different philosophies for construction of web-based services. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? No. If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? There is nothing in this document that calls for an expert review. Personnel Who is the Document Shepherd? Paul Kyzivat Who is the Responsible Area Director? Richard Barnes From pkyzivat@alum.mit.edu Mon Dec 9 11:45:22 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354401AE508 for ; Mon, 9 Dec 2013 11:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlL3WPy7eXkA for ; Mon, 9 Dec 2013 11:45:20 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id C6FEC1AE4F9 for ; Mon, 9 Dec 2013 11:45:17 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta09.westchester.pa.mail.comcast.net with comcast id zRyG1m0021c6gX859XlCed; Mon, 09 Dec 2013 19:45:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id zXlC1m00E3ZTu2S3jXlCTv; Mon, 09 Dec 2013 19:45:12 +0000 Message-ID: <52A61DC8.7000000@alum.mit.edu> Date: Mon, 09 Dec 2013 14:45:12 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Andrew Allen , "sipcore@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386618312; bh=kGs1SOmRi8x4y33OHH+HzD4m3NQA6aSJIqCvAuLLoKw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Psu41LOHcqq0dl/DsVH+DNhrxPPqi19x+y9DkbMwHbQUY8jksz5MlyyuOGivKlHqD QHH4KHEXVK8Ki3iGYwklerMSICpPanOur38NZP/rIGV8/P+qvrazvr+vuqvgTmpqWI szuznkHuJJPr1PJPdysKTktE15hwKuEIfHgbrADE8zGtC4OFzNhrxFfa+zWk9rpmVL msVta/Olir4n/fUA9ei5xkRonxLmdr/LLIOfac21/wPA1ogJiQm/V6ki3dlDtBmpva LewMwJGLZRi/zS2cs1YEap3l8p18zq2XvfcgWSbD9Ykr0KV/KVjysIUuoIP32sNTTc CAs3gq7BWlVXA== Subject: Re: [sipcore] RFC 3261: 305 Use Proxy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 19:45:22 -0000 On 12/7/13 11:56 PM, Andrew Allen wrote: > > Paul > > 3GPP specifications make use of the 305 Use Proxy response but don't go into details of how the Contact header is utilised. My point about taking a survey is that we would want to take account of what is actually done in the wild. From what you say, 3GPP isn't any clearer that 3261 is, so we can't use it as data about what is done in the wild. Rather, we need to know what actual 3GPP deployments do with it. Thanks, Paul > My assumption is that the Route header is used as this is used to redirect an INVITE request via a different proxy and so you need to preserve the Request-URI which contains the address of the destination UA. > > This behavior also seems to align with the loose routing concepts of RFC 3261 - i.e. you leave the Request-URI alone when routing. > > Andrew > > ----- Original Message ----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Saturday, December 07, 2013 01:54 PM Eastern Standard Time > To: sipcore@ietf.org > Subject: Re: [sipcore] RFC 3261: 305 Use Proxy > > On 12/7/13 1:26 PM, Brett Tate wrote: >> Hi, >> >> As indicated within the following snippet from draft-rosenberg-sip-route-construct-01, the 305 response is underspecified within RFC 3261. >> >> What is the expected behavior concerning how to handle a 305's Contact: replace Request-URI or utilized as a Route header? The snippet indicates that the unstated assumption is that it populates the Request-URI. > > I don't know. AFAIK this was never satisfactorily clarified. > > If we wanted to clarify this, I think the first thing we would want to > do is take a survey of any known current uses of 305. (Hopefully there > are none, because nobody knows how to use it.) > > Thanks, > Paul > >> Thanks, >> Brett >> >> ----- >> >> 2.4 305 Use Proxy >> >> RFC 3261 defines the 305 "Use Proxy" response code, but says >> extremely little about exactly how it is used. It has this to say: >> >> The requested resource MUST be accessed through the proxy given by >> the Contact field. The Contact field gives the URI of the proxy. >> The recipient is expected to repeat this single request via the >> proxy. 305 (Use Proxy) responses MUST only be generated by UASs. >> >> It is unclear how the Contact in the redirect is used. Does it >> populate the request URI of the resulting request? Or, does it get >> used to populate the Route header field? The restriction to UASs is >> also not explained. >> >> Historically, the reason for the restriction to UAs was to avoid >> routing loops. Consider an outbound proxy that generates a 305, >> instead of proxying the request. The concern was that the client >> would then recurse on the response, populate the Contact into a new >> request URI, and send the request to its default outbound proxy, >> which redirects once more. To avoid this, the RFC says that only a >> UAS can redirect with a 305, not a proxy. >> >> However, this design decision on 305 handling was made prior to the >> conception of loose routing, although both ended up in RFC 3261. The >> design of the 305 mechanism, unfortunately, was not revisited after >> loose routing was specified. As such, the draft is not clear about >> whether or not the contact gets utilized as a Route header field >> value or whether it replaces the Request URI. The assumption, >> unstated, is that it populates the Request-URI, since redirection >> works that way in general. >> >> This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it. >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > > From brett@broadsoft.com Mon Dec 9 11:55:50 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344251AE52D for ; Mon, 9 Dec 2013 11:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmbzVcuawIJJ for ; Mon, 9 Dec 2013 11:55:48 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id 745731AE52C for ; Mon, 9 Dec 2013 11:55:48 -0800 (PST) Received: from CASUMHUB05.citservers.local (172.16.98.229) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 9 Dec 2013 11:57:38 -0800 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by casumhub05.citservers.local ([::1]) with mapi id 14.02.0247.003; Mon, 9 Dec 2013 11:57:38 -0800 From: Brett Tate To: "DRAGE, Keith (Keith)" , "sipcore@ietf.org" Thread-Topic: [sipcore] RFC 3261: 305 Use Proxy Thread-Index: Ac7zeYtfzrfjjjZ2SuC5iKD08D8RQf//97qAgACoJQCAAhhGAP//jVDQ//8ZcPA= Date: Mon, 9 Dec 2013 19:57:37 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A06D37E@MBX08.citservers.local> References: <52A36EF3.3040702@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B881A06D259@MBX08.citservers.local> <949EF20990823C4C85C18D59AA11AD8B0F43C9@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0F43C9@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] RFC 3261: 305 Use Proxy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 19:55:50 -0000 > In answe to your first question, if you generate a=20 > 305 response to a request, you are by definition a=20 > UAS for that transaction. >=20 > Our interpretation has always been that you assume=20 > a role (UAS or proxy), for the transaction (otherwise=20 > how can you be a USA for a REGISTER request and an=20 > outbound proxy for an INVITE request?). In general, I agree; however based upon what was stated within draft-rosenb= erg-sip-route-construct-01 about the restriction, it doesn't sound like the= RFC 2543/3261 authors and working group were just restating the obvious. Draft-rosenberg-sip-route-construct-01 section 2.4: "Historically, the reason for the restriction to UAs was to avoid routing loops. Consider an outbound proxy that generates a 305, instead of proxying the request. The concern was that the client would then recurse on the response, populate the Contact into a new request URI, and send the request to its default outbound proxy, which redirects once more. To avoid this, the RFC says that only a UAS can redirect with a 305, not a proxy." If 3GPP is explicitly indicating to send 305 (such as within 3GPP TS 24.229= ), it sounds like sipcore might need to make some decisions about how to ha= ndle receiving a 305. If 3GPP is explicitly allowing middle boxes to generate 305 responses, it a= ppears to complicate things a little more. Thanks, Brett > > -----Original Message----- > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of > > Brett Tate > > Sent: 09 December 2013 12:56 > > To: Andrew Allen; pkyzivat@alum.mit.edu; sipcore@ietf.org > > Subject: Re: [sipcore] RFC 3261: 305 Use Proxy > > > > > 3GPP specifications make use of the 305 Use Proxy response > > but don't > > > go into details of how the Contact header is utilised. > > > > Sounds like RFC 3261. :) > > > > How does 3GPP interpret "305 (Use Proxy) responses MUST only > > be generated by UASs"? From adam@nostrum.com Mon Dec 9 12:06:28 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B251AE2E1 for ; Mon, 9 Dec 2013 12:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kp6BezTzVp5o for ; Mon, 9 Dec 2013 12:06:27 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9121AE07F for ; Mon, 9 Dec 2013 12:06:27 -0800 (PST) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB9K6GR8026065 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 9 Dec 2013 14:06:16 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <52A622B3.3050801@nostrum.com> Date: Mon, 09 Dec 2013 14:06:11 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Paul Kyzivat , Andrew Allen , "sipcore@ietf.org" References: <52A61DC8.7000000@alum.mit.edu> In-Reply-To: <52A61DC8.7000000@alum.mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: Re: [sipcore] RFC 3261: 305 Use Proxy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 20:06:28 -0000 On 12/9/13 13:45, Paul Kyzivat wrote: > On 12/7/13 11:56 PM, Andrew Allen wrote: >> >> Paul >> >> 3GPP specifications make use of the 305 Use Proxy response but don't >> go into details of how the Contact header is utilised. > > My point about taking a survey is that we would want to take account > of what is actually done in the wild. From what you say, 3GPP isn't > any clearer that 3261 is, so we can't use it as data about what is > done in the wild. Rather, we need to know what actual 3GPP deployments > do with it. I'll point out that the SIPit events would be an excellent place to gather this kind of information. If we can wait until late next year, we could get really good, hard stats on what a bunch of UAs do. /a From pkyzivat@alum.mit.edu Mon Dec 9 12:46:36 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D5E1AE528 for ; Mon, 9 Dec 2013 12:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmVcKKHAqF2T for ; Mon, 9 Dec 2013 12:46:34 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 14D341AE4F4 for ; Mon, 9 Dec 2013 12:46:33 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta03.westchester.pa.mail.comcast.net with comcast id zVpb1m0041wpRvQ53YmVut; Mon, 09 Dec 2013 20:46:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id zYmU1m00d3ZTu2S3eYmUVZ; Mon, 09 Dec 2013 20:46:29 +0000 Message-ID: <52A62C24.8010104@alum.mit.edu> Date: Mon, 09 Dec 2013 15:46:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <52A36EF3.3040702@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B881A06D259@MBX08.citservers.local> <576A8B541C219D4E9CEB1DF8C19C7B881A06D2DE@MBX08.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B881A06D2DE@MBX08.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386621989; bh=ZyEoSlhHBiU7vigaykDQohiPzrYJR00X/9NjvAeyVlg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sIcrTdsWfSBu215bjqyzoKZcPdGPbGbJfU4ZK+JL6w5uvBqbfZtvCrarX9UVI9By6 AgWPgkcqzTdF9wkcg1vPF/lT+hn3avYGZwuMHQ3hnixbDphLnF7a4bKP/YaeOmCszy eUiltvrab9JMqGGbU6v/eXcgMjJU+oQSY61hVlG3pD5zfHJ0xiTRctkAexg24ibpvp Mjb4SR1yAhSYxYXHR08xC2chQ9CX4lkqgGLUUbLvumWIRe9FaaYvAx5r9jj9qGnMW2 KHxYc8aKR1WTnc098YsjnM0hi5D3QtVDW6Uvy7jeaaFBJtk5RxgOFgG0rky4IE1iWq +1U2W4l/Yjvlg== Subject: Re: [sipcore] RFC 3261: 305 Use Proxy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 20:46:36 -0000 On 12/9/13 11:03 AM, Brett Tate wrote: > Hi, > > I have another 305 question. > > RFC 3261 section 19.1.2 indicates that the lr parameter is not applicable to a redirected Contact. > > If sipcore decides to allow the 305's Contact to impact the Route, what should occur concerning the lr parameter? > > 1) Assume RFC 3261 section 19.1.2 has a bug; lr parameter is optional within a 305's Contact. > > 2) Cannot loose route to the 305 Contact location. > > 3) The device building the Route based upon the 305's Contact can assume that loose routing is supported and add an lr parameter. > > 4) Something else. I think that table in 3261 is incorrect. The lr param describes the capabilities of the resource described by the URI, so some could be loose routing and some not. Thanks, Paul > Thanks, > Brett > >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett Tate >> Sent: Monday, December 09, 2013 7:56 AM >> To: Andrew Allen; pkyzivat@alum.mit.edu; sipcore@ietf.org >> Subject: Re: [sipcore] RFC 3261: 305 Use Proxy >> >>> 3GPP specifications make use of the 305 Use Proxy response >>> but don't go into details of how the Contact header is utilised. >> >> Sounds like RFC 3261. :) >> >> How does 3GPP interpret "305 (Use Proxy) responses MUST only be >> generated by UASs"? >> >> For instance, can proxies and B2BUAs generate 305 responses? If yes, >> can it be sent even though the middle box was not the last loose route >> entry? >> >> Because of all the middle boxes and loose routing within 3GPP >> (including during call setup), which device does 3GPP expect to act >> upon the 305? And if the immediate hop prior does not act upon the 305 >> should it proxy the 305 (thus potentially being subsequently bypassed >> and causing another 305)? >> >>> My assumption is that the Route header is used as this is >>> used to redirect an INVITE request via a different proxy >>> and so you need to preserve the Request-URI which contains >>> the address of the destination UA. >> >> How does the device acting upon the 305 alter an existing loose route >> to accommodate the Contact? >> >> For instance, let's assume that the original INVITE contained a Route >> to traverse 3 proxies (first, second, and third) and no additional >> Route entries were added by middle boxes (to simplify the example). >> How should each proxy and UAC adjust the Route if they were to act upon >> the 305? >> >> I assume that a 305 with multiple Contact headers does not indicate to >> traverse multiple proxies. >> >>> This behavior also seems to align with the loose >>> routing concepts of RFC 3261 - i.e. you leave the >>> Request-URI alone when routing. >> >> Loose routing was introduce by RFC 3261. 305 existed within RFC 2543. >> Based upon your interpretation, it sounds like RFC 2543 devices acting >> upon a 305 would have sent the INVITE to the Contact location without >> adding a Route and without altering the Request-URI. >> >> This interpretation also appears to complicate the default handling >> discussed within RFC 3261 section 5.1.1. More specifically, the 300 >> handling of 305 would result in the other interpretation of the 305 >> (i.e. replace Request-URI). >> >> RFC 3261 section 5.1.1: >> >> "SIP response codes are extensible. SIP applications are not required >> to understand the meaning of all registered response codes, though >> such understanding is obviously desirable. However, applications MUST >> understand the class of any response code, as indicated by the first >> digit, and treat any unrecognized response as being equivalent to the >> x00 response code of that class, with the exception that an >> unrecognized response MUST NOT be cached. For example, if a client >> receives an unrecognized response code of 431, it can safely assume >> that there was something wrong with its request and treat the >> response as if it had received a 400 (Bad Request) response code." >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From gsalguei@cisco.com Mon Dec 9 20:49:45 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865211AE1AD for ; Mon, 9 Dec 2013 20:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_b5Gx4-eLN7 for ; Mon, 9 Dec 2013 20:49:44 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 02FC41AE1A8 for ; Mon, 9 Dec 2013 20:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1732; q=dns/txt; s=iport; t=1386650979; x=1387860579; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8UAEXGcEtuF/4e3C7HdPDS4fQU0TIXwORMAs3inskeM=; b=J8CST60FVihqyJACww9OtWQNfBgV3mf7o84JLns7+Fj5NYq78kwdJCeM voYmsmnejNFUyY0Nw7lAPQWaSfjX/R+w6bCawGodRITUgXX/Z+CMiMM/f lm/SsnoYj0YSD3+KEelUZit1MIrcIOVmhJZqam4gA7jkSEMngp4DvJwHI o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAImcplKtJV2d/2dsb2JhbABZDoJ5OFO4RU6BIxZ0giUBAQEDAQEBATc0CwULAgEIDgoeECcLJQIEDgWHfAYNwEUTBI48ITMHgyCBEwOYFJITgmo/gio X-IronPort-AV: E=Sophos;i="4.93,863,1378857600"; d="scan'208";a="5579864" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 10 Dec 2013 04:49:38 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rBA4ncao022447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 04:49:38 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 22:49:38 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat Thread-Topic: [sipcore] IPv6 in the sip core wg Thread-Index: AQHO8oXtPaG9LxtinkCT+HMY0fMEHZpH0MUAgAV1OYA= Date: Tue, 10 Dec 2013 04:49:37 +0000 Message-ID: <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> References: <52A2094E.8020009@alum.mit.edu> In-Reply-To: <52A2094E.8020009@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.246.129] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 04:49:45 -0000 Paul -=20 On Dec 6, 2013, at 12:28 PM, Paul Kyzivat wrote: > Olle, >=20 > Yes, this is something it seems evident we should take on. > I don't believe we need to change the "charter", but we should add a mile= stone for this. >=20 > If you would like to propose milestone text (in the same style as the exi= sting milestones) and take a first guess at a date for it, that would be gr= eat. How about: Apr 2014 Amended procedures for dual-stack server handling of SIP URIs con= taining domain names >=20 > Now that we have this, and some other things, that are on the table we ar= e planning on having a sipcore session in London. This will be one (or more= ) of the agenda items for that meeting. Sounds good. Gonzalo >=20 > Thanks, > Paul >=20 > On 12/6/13 8:20 AM, Olle E. Johansson wrote: >> Hi! >>=20 >> Coming back to an earlier discussion, it seemed to me that we had a few = people that supported adding IPv6 dual stack issues to the charter of this = wg - if it's not in there already. >>=20 >> I would like to propose that we add this to the charter and that we plan= a meeting at the IETF in London to discuss this and happy eyeballs issues. >>=20 >> We have two drafts in the pipeline and one that should have been written= about the actual happy eyeballs connection setup, but currently only exist= s as promiseware... >>=20 >> /O >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From mary.ietf.barnes@gmail.com Tue Dec 10 07:19:10 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28701ADF8B for ; Tue, 10 Dec 2013 07:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HWbCVfl3gs5 for ; Tue, 10 Dec 2013 07:19:08 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 637731AE0CF for ; Tue, 10 Dec 2013 07:19:08 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id q58so5148067wes.33 for ; Tue, 10 Dec 2013 07:19:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xlVGgjVX26YhTNAxJnydG1i5iOzeQXqK8zx+F00iiuQ=; b=Gd+sDJhO/PyB32Mzjny2k1Q2aNmHVs52YOhrclg6OcQ0KU8DL0WGCaSCrZ8tPU+i5Z 44B1KpAUdkkuX7dOW2Zmv0NBjAiSg6dvbjXVbrUk8ic5Bx/1/VhrkCuScqfScWgC4IwS WLLvnlbVZ6hX71CBxRvy5AVO/2QOHd58g00RXA60JZfAXRb29SFq5mwqncW5bn9JvbSa xHwjaFucopF/yOYVvg8lTDPU5oEGFj9eFfLhFhCqpWEz280f+nmjdv94PbPE7VhFt04T zcar3aZIQ9f9aPAxHx2T8MPbRNjQRvGsqIIqRXRSDGwA4eA7hmvsxw7qQYBh8Xu15vky MsAw== MIME-Version: 1.0 X-Received: by 10.180.188.229 with SMTP id gd5mr20005862wic.38.1386688742757; Tue, 10 Dec 2013 07:19:02 -0800 (PST) Received: by 10.216.172.9 with HTTP; Tue, 10 Dec 2013 07:19:02 -0800 (PST) In-Reply-To: <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> Date: Tue, 10 Dec 2013 09:19:02 -0600 Message-ID: From: Mary Barnes To: "Gonzalo Salgueiro (gsalguei)" Content-Type: multipart/alternative; boundary=001a11c37e8eed1aa704ed2fa15d Cc: "sipcore@ietf.org" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 15:19:11 -0000 --001a11c37e8eed1aa704ed2fa15d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 9, 2013 at 10:49 PM, Gonzalo Salgueiro (gsalguei) < gsalguei@cisco.com> wrote: > Paul - > > On Dec 6, 2013, at 12:28 PM, Paul Kyzivat wrote: > > > Olle, > > > > Yes, this is something it seems evident we should take on. > > I don't believe we need to change the "charter", but we should add a > milestone for this. > > > > If you would like to propose milestone text (in the same style as the > existing milestones) and take a first guess at a date for it, that would be > great. > > How about: > > Apr 2014 Amended procedures for dual-stack server handling of SIP URIs > containing domain names > [MB] I would suggest to just use the term "Updated" as opposed to "Amended". While all of our dates are always optimistic, I think June 2014 is probably beyond the usually level of optimism, since that's the date for the doc to go to the IESG. It often takes at least 2 months to get a doc from WGLC to ready for IESG review. That would mean the document completes WGLC in February 2014. If you think that's possible, then April is fine, but I would anticipate that it could take a tad longer. [/MB] > > > > > Now that we have this, and some other things, that are on the table we > are planning on having a sipcore session in London. This will be one (or > more) of the agenda items for that meeting. > > Sounds good. > > Gonzalo > > > > > Thanks, > > Paul > > > > On 12/6/13 8:20 AM, Olle E. Johansson wrote: > >> Hi! > >> > >> Coming back to an earlier discussion, it seemed to me that we had a few > people that supported adding IPv6 dual stack issues to the charter of this > wg - if it's not in there already. > >> > >> I would like to propose that we add this to the charter and that we > plan a meeting at the IETF in London to discuss this and happy eyeballs > issues. > >> > >> We have two drafts in the pipeline and one that should have been > written about the actual happy eyeballs connection setup, but currently > only exists as promiseware... > >> > >> /O > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a11c37e8eed1aa704ed2fa15d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 9, 2013 at 10:49 PM= , Gonzalo Salgueiro (gsalguei) <gsalguei@cisco.com> wrote:<= br>
Paul -

On Dec 6, 2013, at 12:28 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> Olle,
>
> Yes, this is something it seems evident we should take on.
> I don't believe we need to change the "charter", but we = should add a milestone for this.
>
> If you would like to propose milestone text (in the same style as the = existing milestones) and take a first guess at a date for it, that would be= great.

How about:

Apr 2014 =A0Amended procedures for dual-stack server handling of SIP URIs c= ontaining domain names
[MB] I would suggest to just us= e the term "Updated" as opposed to "Amended".
While all of our dates are always optimistic, I think June 2014 is pro= bably beyond the usually level of optimism, since that's the date for t= he doc to go to the IESG. =A0 It often takes at least 2 months to get a doc= from WGLC to ready for IESG review. =A0That would mean the document comple= tes WGLC in February 2014. =A0If you think that's possible, then April = is fine, but I would anticipate that it could take a tad longer.=A0
[/MB]=A0

>
> Now that we have this, and some other things, that are on the table we= are planning on having a sipcore session in London. This will be one (or m= ore) of the agenda items for that meeting.

Sounds good.

Gonzalo

>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
> On 12/6/13 8:20 AM, Olle E. Johansson wrote:
>> Hi!
>>
>> Coming back to an earlier discussion, it seemed to me that we had = a few people that supported adding IPv6 dual stack issues to the charter of= this wg - if it's not in there already.
>>
>> I would like to propose that we add this to the charter and that w= e plan a meeting at the IETF in London to discuss this and happy eyeballs i= ssues.
>>
>> We have two drafts in the pipeline and one that should have been w= ritten about the actual happy eyeballs connection setup, but currently only= exists as promiseware...
>>
>> /O
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf= .org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org=
> https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--001a11c37e8eed1aa704ed2fa15d-- From brett@broadsoft.com Tue Dec 10 07:33:09 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D13A1ADC03 for ; Tue, 10 Dec 2013 07:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NU6MhwvaLoQn for ; Tue, 10 Dec 2013 07:33:07 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id DD0B91AD7C5 for ; Tue, 10 Dec 2013 07:33:07 -0800 (PST) Received: from CASUMHUB03.citservers.local (172.16.98.219) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 10 Dec 2013 07:34:57 -0800 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Tue, 10 Dec 2013 07:34:57 -0800 From: Brett Tate To: "sipcore@ietf.org" Thread-Topic: [sipcore] RFC 3261: 305 Use Proxy Thread-Index: AQHO834U0dGj3ONYiUe9qHgjXk7YEppNgmTg Date: Tue, 10 Dec 2013 15:34:56 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A06D507@MBX08.citservers.local> References: <576A8B541C219D4E9CEB1DF8C19C7B881A06D0EA@MBX08.citservers.local> <52A36EF3.3040702@alum.mit.edu> In-Reply-To: <52A36EF3.3040702@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] RFC 3261: 305 Use Proxy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 15:33:09 -0000 > > As indicated within the following snippet from=20 > > draft-rosenberg-sip-route-construct-01, the 305=20 > > response is underspecified within RFC 3261. > > > > What is the expected behavior concerning how to=20 > > handle a 305's Contact: replace Request-URI or=20 > > utilized as a Route header? The snippet indicates=20 > > that the unstated assumption is that it populates=20 > > the Request-URI. >=20 > I don't know. AFAIK this was never satisfactorily=20 > clarified. >=20 > If we wanted to clarify this, I think the first thing=20 > we would want to do is take a survey of any known=20 > current uses of 305. (Hopefully there are none,=20 > because nobody knows how to use it.) Someone has started sending 305 within IMS deployments. I'm not sure if it= was because of 3GPP TS 24.229, similar 3GPP specifications, or another rea= son. The following is one of the snippets from 3GPP TS 24.229 V10.5.0. "If the HSS indicates to the S-CSCF that there is already another S-CSCF as= signed for the user, the S-CSCF shall return a 305 (Use Proxy) response con= taining the SIP URI of the assigned S-CSCF received from the HSS in the Con= tact header field." Surveying the senders of 305 is potentially as important as how everyone is= handling it. For instance, what are they supplying within the Contact and= how are they expecting the 305 to be handled? Thanks, Brett From pkyzivat@alum.mit.edu Tue Dec 10 08:59:33 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A37E1AE1D6 for ; Tue, 10 Dec 2013 08:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gw3GxzISCAVc for ; Tue, 10 Dec 2013 08:59:32 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 059591ADF74 for ; Tue, 10 Dec 2013 08:59:31 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta08.westchester.pa.mail.comcast.net with comcast id zqJh1m0020vyq2s58szSPM; Tue, 10 Dec 2013 16:59:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id zszS1m00c3ZTu2S3RszShi; Tue, 10 Dec 2013 16:59:26 +0000 Message-ID: <52A7486E.2090005@alum.mit.edu> Date: Tue, 10 Dec 2013 11:59:26 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Mary Barnes , "Gonzalo Salgueiro (gsalguei)" References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386694766; bh=KMc5Ykj43nMMG1aaaGuFJeD2ZX/JbSP1T7FVhWEsdY0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GhrPHdwg6lxmY71zbvFySnDmwOgjfaHE9znHZsG9oCba0Z/4ngcZ3g4VeoA6T/WdX 7QMTRQsQhxnnQqMEg3Zgk/UYsHHzG9SWsJwDo2h+9OPtx0vTP8MKEXlX9KCk2iyeVv MnnEBp/plbat9vMNo3GAXv7qLRSD8yS+oeRMAJtCLrJes/qnp7AfOvuWi8GHVFRAdO t4ZNS4lWed7MTmP6ECFLhzfE2TT++sMld/OLMIYRR9PAlvynQVy+kMN7H7/tLi7TOJ moHpGABT1LjHydk3toA4Iyk/xjmFOyfRaqd5sS7bjMcGIxGoJQip3WZxuRsDs1P+Yk GrRBSmt6lnaCg== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 16:59:33 -0000 Gonzalo, Mary made the comment on schedule before I got the chance. :-) June is between the London meeting and the Toronto meeting. Its a reasonable time if we we have substantial agreement coming out of the London meeting. If we need another meeting cycle, then of course it will take longer. I don't yet have a sense how much controversy and debate there might be on this subject. For now I'm ok with a June date. (They don't hang us for missing dates.) So does the following work for you? June 2014 Updated procedures for dual-stack server handling of SIP URIs containing domain names Thanks, Paul On 12/10/13 10:19 AM, Mary Barnes wrote: > On Mon, Dec 9, 2013 at 10:49 PM, Gonzalo Salgueiro (gsalguei) > > wrote: > > Paul - > > On Dec 6, 2013, at 12:28 PM, Paul Kyzivat > wrote: > > > Olle, > > > > Yes, this is something it seems evident we should take on. > > I don't believe we need to change the "charter", but we should > add a milestone for this. > > > > If you would like to propose milestone text (in the same style as > the existing milestones) and take a first guess at a date for it, > that would be great. > > How about: > > Apr 2014 Amended procedures for dual-stack server handling of SIP > URIs containing domain names > > [MB] I would suggest to just use the term "Updated" as opposed to "Amended". > While all of our dates are always optimistic, I think June 2014 is > probably beyond the usually level of optimism, since that's the date for > the doc to go to the IESG. It often takes at least 2 months to get a > doc from WGLC to ready for IESG review. That would mean the document > completes WGLC in February 2014. If you think that's possible, then > April is fine, but I would anticipate that it could take a tad longer. > [/MB] > > > > > > Now that we have this, and some other things, that are on the > table we are planning on having a sipcore session in London. This > will be one (or more) of the agenda items for that meeting. > > Sounds good. > > Gonzalo > > > > > Thanks, > > Paul > > > > On 12/6/13 8:20 AM, Olle E. Johansson wrote: > >> Hi! > >> > >> Coming back to an earlier discussion, it seemed to me that we > had a few people that supported adding IPv6 dual stack issues to the > charter of this wg - if it's not in there already. > >> > >> I would like to propose that we add this to the charter and that > we plan a meeting at the IETF in London to discuss this and happy > eyeballs issues. > >> > >> We have two drafts in the pipeline and one that should have been > written about the actual happy eyeballs connection setup, but > currently only exists as promiseware... > >> > >> /O > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > From gsalguei@cisco.com Tue Dec 10 09:08:57 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D08A1AE222 for ; Tue, 10 Dec 2013 09:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ra0wfz4EniKS for ; Tue, 10 Dec 2013 09:08:55 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 984081AE1F9 for ; Tue, 10 Dec 2013 09:08:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2903; q=dns/txt; s=iport; t=1386695330; x=1387904930; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+/Ttqb3qATXB7Y+GGNCundWzoftINqmHgcTQSZO3mAk=; b=C1FrR63VMJ64/EfiCzBicYZA5KwEIp3+4hcgeGuCr242Rxk40MqdvlLQ w5zfMR3ZsTNM1G4k/INYt+oMj+Iu3OF4kUsQixGoM3EHpMeprxHAQrbXB W3vgUje2rRBznnubbBQODLp89++reEbQ6syEo/BuLWi+7R32wYipnW9k/ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAEVKp1KtJV2c/2dsb2JhbABZgwc4U7hQToEeFnSCJQEBAQMBAQEBJkULBQsCAQIGGC4hBgslAgQOBYdwAwkGDboVDYZnEwSMc4E+ITMHgyGBEwSJCo0fgWuMWoU5gymCKg X-IronPort-AV: E=Sophos;i="4.93,865,1378857600"; d="scan'208";a="5722218" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP; 10 Dec 2013 17:08:50 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rBAH8oSF012398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 17:08:50 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 10 Dec 2013 11:08:49 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Mary Barnes Thread-Topic: [sipcore] IPv6 in the sip core wg Thread-Index: AQHO8oXtPaG9LxtinkCT+HMY0fMEHZpH0MUAgAV1OYCAAK/bAIAAHqsA Importance: high X-Priority: 1 Date: Tue, 10 Dec 2013 17:08:49 +0000 Message-ID: <64750EC7-8E66-447B-8710-8FAD841DC457@cisco.com> References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.239.182] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <702948BA8A94894EBCD3E235F19C3ECB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 17:08:57 -0000 Hi Mary -=20 Agree with both points raised. Thanks. Gonzalo On Dec 10, 2013, at 10:19 AM, Mary Barnes wrot= e: > On Mon, Dec 9, 2013 at 10:49 PM, Gonzalo Salgueiro (gsalguei) wrote: > Paul - >=20 > On Dec 6, 2013, at 12:28 PM, Paul Kyzivat wrote: >=20 > > Olle, > > > > Yes, this is something it seems evident we should take on. > > I don't believe we need to change the "charter", but we should add a mi= lestone for this. > > > > If you would like to propose milestone text (in the same style as the e= xisting milestones) and take a first guess at a date for it, that would be = great. >=20 > How about: >=20 > Apr 2014 Amended procedures for dual-stack server handling of SIP URIs c= ontaining domain names > [MB] I would suggest to just use the term "Updated" as opposed to "Amende= d". > While all of our dates are always optimistic, I think June 2014 is probab= ly beyond the usually level of optimism, since that's the date for the doc = to go to the IESG. It often takes at least 2 months to get a doc from WGL= C to ready for IESG review. That would mean the document completes WGLC in= February 2014. If you think that's possible, then April is fine, but I wo= uld anticipate that it could take a tad longer.=20 > [/MB]=20 >=20 > > > > Now that we have this, and some other things, that are on the table we = are planning on having a sipcore session in London. This will be one (or mo= re) of the agenda items for that meeting. >=20 > Sounds good. >=20 > Gonzalo >=20 > > > > Thanks, > > Paul > > > > On 12/6/13 8:20 AM, Olle E. Johansson wrote: > >> Hi! > >> > >> Coming back to an earlier discussion, it seemed to me that we had a fe= w people that supported adding IPv6 dual stack issues to the charter of thi= s wg - if it's not in there already. > >> > >> I would like to propose that we add this to the charter and that we pl= an a meeting at the IETF in London to discuss this and happy eyeballs issue= s. > >> > >> We have two drafts in the pipeline and one that should have been writt= en about the actual happy eyeballs connection setup, but currently only exi= sts as promiseware... > >> > >> /O > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From gsalguei@cisco.com Tue Dec 10 09:09:06 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D4B1AE235 for ; Tue, 10 Dec 2013 09:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ESOFuOqcF9b for ; Tue, 10 Dec 2013 09:09:04 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BF5111AE1DC for ; Tue, 10 Dec 2013 09:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4182; q=dns/txt; s=iport; t=1386695340; x=1387904940; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jLuFAoYrYHjd3JaYgTzAmIhyfL9LxtxcQoBle0FEeJk=; b=OCHqWv+KyLgS4s8J7dPNbLvhgBMeNjzqPgKgfmlPoRIFkCGLhVbJffts /1C7pIF33s5Bovg92nQUm/cKCtMo4nEtWL9+sPUQD5J95QnSXL6NeglAT 863eubPY2tYvfGdrjABNdASsH+UUoBnVZQgBuna3PNPvT42vmqOHjsbvb o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAHFJp1KtJXG//2dsb2JhbABZDoJ5OFO4UE6BHhZ0giUBAQEEAQEBJkULEAIBAgYOCicHJwsUEQIEAQ0FiAINwQsTBI4xVAeENASJCo8KkhOCaj+CKg X-IronPort-AV: E=Sophos;i="4.93,865,1378857600"; d="scan'208";a="290638040" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 10 Dec 2013 17:08:59 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBAH8xNJ012951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 17:08:59 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Tue, 10 Dec 2013 11:08:58 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat , Mary Barnes Thread-Topic: [sipcore] IPv6 in the sip core wg Thread-Index: AQHO8oXtPaG9LxtinkCT+HMY0fMEHZpH0MUAgAV1OYCAAK/bAIAAHA0A//+u1gA= Importance: high X-Priority: 1 Date: Tue, 10 Dec 2013 17:08:58 +0000 Message-ID: References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> In-Reply-To: <52A7486E.2090005@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.239.182] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4230DED2350C424F92073A41BFB837EE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 17:09:07 -0000 Works for me.=20 BTW - I=B9m perfectly fine if we want to be conservative and push the milestone deadline out further, if that is desirable. If we get it done prior, then all the better. Gonzalo On 12/10/13, 11:59 AM, "Paul Kyzivat" wrote: >Gonzalo, > >Mary made the comment on schedule before I got the chance. :-) > >June is between the London meeting and the Toronto meeting. Its a >reasonable time if we we have substantial agreement coming out of the >London meeting. If we need another meeting cycle, then of course it will >take longer. > >I don't yet have a sense how much controversy and debate there might be >on this subject. For now I'm ok with a June date. (They don't hang us >for missing dates.) > >So does the following work for you? > > June 2014 Updated procedures for dual-stack server handling of SIP > URIs containing domain names > > Thanks, > Paul > >On 12/10/13 10:19 AM, Mary Barnes wrote: >> On Mon, Dec 9, 2013 at 10:49 PM, Gonzalo Salgueiro (gsalguei) >> > wrote: >> >> Paul - >> >> On Dec 6, 2013, at 12:28 PM, Paul Kyzivat > > wrote: >> >> > Olle, >> > >> > Yes, this is something it seems evident we should take on. >> > I don't believe we need to change the "charter", but we should >> add a milestone for this. >> > >> > If you would like to propose milestone text (in the same style as >> the existing milestones) and take a first guess at a date for it, >> that would be great. >> >> How about: >> >> Apr 2014 Amended procedures for dual-stack server handling of SIP >> URIs containing domain names >> >> [MB] I would suggest to just use the term "Updated" as opposed to >>"Amended". >> While all of our dates are always optimistic, I think June 2014 is >> probably beyond the usually level of optimism, since that's the date for >> the doc to go to the IESG. It often takes at least 2 months to get a >> doc from WGLC to ready for IESG review. That would mean the document >> completes WGLC in February 2014. If you think that's possible, then >> April is fine, but I would anticipate that it could take a tad longer. >> [/MB] >> >> >> > >> > Now that we have this, and some other things, that are on the >> table we are planning on having a sipcore session in London. This >> will be one (or more) of the agenda items for that meeting. >> >> Sounds good. >> >> Gonzalo >> >> > >> > Thanks, >> > Paul >> > >> > On 12/6/13 8:20 AM, Olle E. Johansson wrote: >> >> Hi! >> >> >> >> Coming back to an earlier discussion, it seemed to me that we >> had a few people that supported adding IPv6 dual stack issues to the >> charter of this wg - if it's not in there already. >> >> >> >> I would like to propose that we add this to the charter and that >> we plan a meeting at the IETF in London to discuss this and happy >> eyeballs issues. >> >> >> >> We have two drafts in the pipeline and one that should have been >> written about the actual happy eyeballs connection setup, but >> currently only exists as promiseware... >> >> >> >> /O >> >> _______________________________________________ >> >> sipcore mailing list >> >> sipcore@ietf.org >> >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> > >> > _______________________________________________ >> > sipcore mailing list >> > sipcore@ietf.org >> > https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From fluffy@iii.ca Tue Dec 10 09:14:10 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B174A1AE00E for ; Tue, 10 Dec 2013 09:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrTR9uEJsHVP for ; Tue, 10 Dec 2013 09:14:09 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id BB2B61ADF73 for ; Tue, 10 Dec 2013 09:14:09 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6AD8450A85; Tue, 10 Dec 2013 12:14:03 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Cullen Jennings In-Reply-To: <52A7486E.2090005@alum.mit.edu> Date: Tue, 10 Dec 2013 10:14:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> To: Paul Kyzivat , Mary Barnes X-Mailer: Apple Mail (2.1510) Cc: sipcore@ietf.org, "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 17:14:10 -0000 On Dec 10, 2013, at 9:59 AM, Paul Kyzivat wrote: > June 2014 Updated procedures for dual-stack server handling of SIP > URIs containing domain names Before we use update, can someone tell me what normative text of the = current RFCs need to be changed? From pkyzivat@alum.mit.edu Tue Dec 10 09:14:54 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08351AE037 for ; Tue, 10 Dec 2013 09:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7yA4E1feg4J for ; Tue, 10 Dec 2013 09:14:53 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 124EE1ADF73 for ; Tue, 10 Dec 2013 09:14:52 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta03.westchester.pa.mail.comcast.net with comcast id zrxR1m0061uE5Es53tEnqk; Tue, 10 Dec 2013 17:14:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id ztEn1m00l3ZTu2S3ctEnpX; Tue, 10 Dec 2013 17:14:47 +0000 Message-ID: <52A74C07.8050903@alum.mit.edu> Date: Tue, 10 Dec 2013 12:14:47 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <576A8B541C219D4E9CEB1DF8C19C7B881A06D0EA@MBX08.citservers.local> <52A36EF3.3040702@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B881A06D507@MBX08.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B881A06D507@MBX08.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386695687; bh=3gQCsrFezGMSBv57ZaSlQO2RC0f7XMAxlgkDGMI4Mnw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mULhZp8pzxKaEAWHMV5HJePiUVC8TFY2CVSo7YTZJT1xSZj0/FUjBZtEOeULmVuSE vUWL5yr4o3IY3ul9FbVXlOQyzz1i/3e6y0cqpdMzp/QNcnXAKZHqTmp8L8Z1BsD3vP XKg744DR6CHWvUeK4khAs5o3sTJ/LY47f7cjPMnimvidEzfYY+qO0GQQWJXxGLeoCH K3vkB/4RMiv/htLZr/FqneMTwD+ZBWcmaCOSC8A/85c1V9WnnwgKgPhfW+avYtCHm6 DxyfRljnxibpYYHLC9U2qsHCPC3ZZrygB0qYcbFLS3Zm6D84W4DbaGNmEFNP+0Q6ue GIJGA80QFRnqA== Subject: [sipcore] IMS use of 305 Use Proxy response??? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 17:14:54 -0000 IMS people: Can you please provide information on how 305 is being used in IMS implementations? Does a recipient of the 305 insert the URI into the Route header and retry using the original R-URI? If so, is the new URI *added*, or does it replace some existing URI in the Route header? Where in the Route header does it go? For context, if you haven't been following this discussion, the 305 response semantics are underspecified in 3261. If this is starting to be used, then it is becoming more urgent to get some clarification so that all use it in consistent ways. Thanks, Paul On 12/10/13 10:34 AM, Brett Tate wrote: >>> As indicated within the following snippet from >>> draft-rosenberg-sip-route-construct-01, the 305 >>> response is underspecified within RFC 3261. >>> >>> What is the expected behavior concerning how to >>> handle a 305's Contact: replace Request-URI or >>> utilized as a Route header? The snippet indicates >>> that the unstated assumption is that it populates >>> the Request-URI. >> >> I don't know. AFAIK this was never satisfactorily >> clarified. >> >> If we wanted to clarify this, I think the first thing >> we would want to do is take a survey of any known >> current uses of 305. (Hopefully there are none, >> because nobody knows how to use it.) > > Someone has started sending 305 within IMS deployments. I'm not sure if it was because of 3GPP TS 24.229, similar 3GPP specifications, or another reason. The following is one of the snippets from 3GPP TS 24.229 V10.5.0. > > "If the HSS indicates to the S-CSCF that there is already another S-CSCF assigned for the user, the S-CSCF shall return a 305 (Use Proxy) response containing the SIP URI of the assigned S-CSCF received from the HSS in the Contact header field." > > Surveying the senders of 305 is potentially as important as how everyone is handling it. For instance, what are they supplying within the Contact and how are they expecting the 305 to be handled? > > Thanks, > Brett > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From worley@shell01.TheWorld.com Tue Dec 10 11:15:12 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776071AE15D for ; Tue, 10 Dec 2013 11:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyP5ap3y2MQz for ; Tue, 10 Dec 2013 11:15:10 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 58AEB1AE056 for ; Tue, 10 Dec 2013 11:15:10 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id rBAJF0Oe025371 for ; Tue, 10 Dec 2013 14:15:02 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id rBAJCCxA571810 for ; Tue, 10 Dec 2013 14:12:12 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id rBAJCCek571905; Tue, 10 Dec 2013 14:12:12 -0500 (EST) Date: Tue, 10 Dec 2013 14:12:12 -0500 (EST) Message-Id: <201312101912.rBAJCCek571905@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: <576A8B541C219D4E9CEB1DF8C19C7B881A06D37E@MBX08.citservers.local> (brett@broadsoft.com) References: <52A36EF3.3040702@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B881A06D259@MBX08.citservers.local> <949EF20990823C4C85C18D59AA11AD8B0F43C9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <576A8B541C219D4E9CEB1DF8C19C7B881A06D37E@MBX08.citservers.local> Subject: Re: [sipcore] RFC 3261: 305 Use Proxy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 19:15:12 -0000 > From: Brett Tate > In general, I agree; however based upon what was stated within > draft-rosenberg-sip-route-construct-01 about the restriction, it > doesn't sound like the RFC 2543/3261 authors and working group were > just restating the obvious. > > Draft-rosenberg-sip-route-construct-01 section 2.4: > > "Historically, the reason for the restriction to UAs was to avoid > routing loops. Consider an outbound proxy that generates a 305, > instead of proxying the request. The concern was that the client > would then recurse on the response, populate the Contact into a new > request URI, and send the request to its default outbound proxy, > which redirects once more. To avoid this, the RFC says that only a > UAS can redirect with a 305, not a proxy." RFC 3261, 21.3.4 305 Use Proxy The requested resource MUST be accessed through the proxy given by the Contact field. The Contact field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 (Use Proxy) responses MUST only be generated by UASs. Personally, it seems to me that this rule must be a poor rule in practice. As far as I can figure out, what it means by "UAS" is "a UA capable of terminating calls", i.e., an entity that can provide a 200 response under suitable conditions. As Keith notes, *any* entity that produces a final response is a UAS for the transaction to which it provides a final response, even if the entity's normal function isn't seen as being a UAS. But in practice, that sort of UAS is probably never going to be the entity that can detect the policy situation of "the UAC should be sending this INVITE via a different proxy". The entity that will detect that is a policy-enforcing intake proxy. Dale From worley@shell01.TheWorld.com Tue Dec 10 11:16:21 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740181AE1BC for ; Tue, 10 Dec 2013 11:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1BqpQ0DnJGT for ; Tue, 10 Dec 2013 11:16:20 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id BC99D1AE1BA for ; Tue, 10 Dec 2013 11:16:09 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id rBAJFBQD025807 for ; Tue, 10 Dec 2013 14:15:13 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id rBAJCR3p571693 for ; Tue, 10 Dec 2013 14:12:27 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id rBAJCRAQ571973; Tue, 10 Dec 2013 14:12:27 -0500 (EST) Date: Tue, 10 Dec 2013 14:12:27 -0500 (EST) Message-Id: <201312101912.rBAJCRAQ571973@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: <576A8B541C219D4E9CEB1DF8C19C7B881A06D0EA@MBX08.citservers.local> (brett@broadsoft.com) References: <576A8B541C219D4E9CEB1DF8C19C7B881A06D0EA@MBX08.citservers.local> Subject: Re: [sipcore] RFC 3261: 305 Use Proxy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 19:16:21 -0000 > From: Brett Tate > What is the expected behavior concerning how to handle a 305's > Contact: replace Request-URI or utilized as a Route header? The > snippet indicates that the unstated assumption is that it populates > the Request-URI. That's tricky. 305 is part of the 3xx family, so ideally you want to handle its Contact header like you'd handle the Contact header for 301 and 302. In those cases, you put the Contact URI in the request-URI. But that doesn't seem to match the semantics of 305, which is specifically to direct the upstream entity to send the request to a particular proxy. I suppose you could satisfy both requirements by a trick: The URI in the Contact of a 305 would be ?Route= That's not satisfying either. Dale From oej@edvina.net Tue Dec 10 11:21:34 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18001AE01B for ; Tue, 10 Dec 2013 11:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1gpKadEM1GP for ; Tue, 10 Dec 2013 11:21:32 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id C6CD41ADFF5 for ; Tue, 10 Dec 2013 11:21:31 -0800 (PST) Received: from [192.168.101.63] (unknown [72.46.244.148]) by smtp7.webway.se (Postfix) with ESMTPA id EBDE393C2A1; Tue, 10 Dec 2013 19:21:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 10 Dec 2013 14:21:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> To: Cullen Jennings X-Mailer: Apple Mail (2.1822) Cc: Olle E Johansson , SIPCORE WG , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 19:21:34 -0000 On 10 Dec 2013, at 12:14, Cullen Jennings wrote: >=20 > On Dec 10, 2013, at 9:59 AM, Paul Kyzivat = wrote: >=20 >> June 2014 Updated procedures for dual-stack server handling of SIP >> URIs containing domain names >=20 > Before we use update, can someone tell me what normative text of the = current RFCs need to be changed? >=20 That's part of the problem, RFC 3263 is not very clear to me in = indicating what exactly is normative. If you read our draft, you will = see that we point to a few sections that clearly says that a UA needs to = look up "A or AAAA" records, which has been proven wrong and doesn't = follow the intention of the DNS SRV RFC. If this was unintentional or = normative, I don't know, but it's written enough times to cause issues = in implementations and have been copied to other documents, like the = MSRP RFC. We need to clarify that a SIP implementation needs to follow the DNS SRV = RFC and look up all addresses for a host name (ipv4, IPv6 or future = address families) and test them all before moving to the next priority = and host. I've checked this with members of the IETF DNS directorate two times = now, and they agree with this. When we clarified/updated/extended/informed the audience - developers - = about this, we need to get down to how to connect - serially, in = parallell, in reverse random order controlled by the phases of the moon = or other planets - or simply Happy Eyeballs. But even with TCP, doing = happy eyeballs like in HTTP would not work unless we have both A and = AAAA records. RFC 3263 doesn't really indicate that. Someone else needs to help out to clarify to me what is really normative = in 3263 and what the relationship between 3263 and RFC 2782 really is - = if RFC 2782 is the normative one and RFC 3263 just can be seen as a = happy story that points to 2782 without making any normative changes, we = might have to clarify that in an informational document and move on to = connection setup in a dual stack world. If RFC 3263 changes the = behaviour intended by 2782 and really forces a developer to select A or = AAAA records, then we need to change that behaviour. Either way, we have work to do in ths wg. /O= From fluffy@iii.ca Tue Dec 10 15:13:18 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D125B1AE147 for ; Tue, 10 Dec 2013 15:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOf_tiJtdABZ for ; Tue, 10 Dec 2013 15:13:17 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id D883D1ACCDE for ; Tue, 10 Dec 2013 15:13:16 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 64A5E22E253; Tue, 10 Dec 2013 18:13:09 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Cullen Jennings In-Reply-To: <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> Date: Tue, 10 Dec 2013 16:13:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> To: Olle E. Johansson X-Mailer: Apple Mail (2.1510) Cc: SIPCORE WG , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 23:13:19 -0000 Well from a milestone point of view there is a big difference between we = need the change an existing RFC (i.e. update) or we need to define a new = RFC that tells developers who want to implement the new RFC what they = need to do.=20 I think what is needed here is the later item and not the update. I have = asked about this a bunch of times and and I always get answers that = suggest that a new document is needed but it does not need to replace or = update 3263. It needs to be a new document that provides more detailed = advice. If we are going to say this updates something, I want to be = convinced first that there is something that is wrong and needs to be = changed. I'm fine with the idea that ore detailed specifications are = needed to do something like happy eyeballs for SIP but I don't think = that requires an update of 3263.=20 On Dec 10, 2013, at 12:21 PM, Olle E. Johansson wrote: >=20 > On 10 Dec 2013, at 12:14, Cullen Jennings wrote: >=20 >>=20 >> On Dec 10, 2013, at 9:59 AM, Paul Kyzivat = wrote: >>=20 >>> June 2014 Updated procedures for dual-stack server handling of SIP >>> URIs containing domain names >>=20 >> Before we use update, can someone tell me what normative text of the = current RFCs need to be changed? >>=20 >=20 > That's part of the problem, RFC 3263 is not very clear to me in = indicating what exactly is normative. If you read our draft, you will = see that we point to a few sections that clearly says that a UA needs to = look up "A or AAAA" records, which has been proven wrong and doesn't = follow the intention of the DNS SRV RFC. If this was unintentional or = normative, I don't know, but it's written enough times to cause issues = in implementations and have been copied to other documents, like the = MSRP RFC. >=20 > We need to clarify that a SIP implementation needs to follow the DNS = SRV RFC and look up all addresses for a host name (ipv4, IPv6 or future = address families) and test them all before moving to the next priority = and host. >=20 > I've checked this with members of the IETF DNS directorate two times = now, and they agree with this. >=20 > When we clarified/updated/extended/informed the audience - developers = - about this, we need to get down to how to connect - serially, in = parallell, in reverse random order controlled by the phases of the moon = or other planets - or simply Happy Eyeballs. But even with TCP, doing = happy eyeballs like in HTTP would not work unless we have both A and = AAAA records. RFC 3263 doesn't really indicate that. >=20 > Someone else needs to help out to clarify to me what is really = normative in 3263 and what the relationship between 3263 and RFC 2782 = really is - if RFC 2782 is the normative one and RFC 3263 just can be = seen as a happy story that points to 2782 without making any normative = changes, we might have to clarify that in an informational document and = move on to connection setup in a dual stack world. If RFC 3263 changes = the behaviour intended by 2782 and really forces a developer to select A = or AAAA records, then we need to change that behaviour. >=20 > Either way, we have work to do in ths wg. > /O From oej@edvina.net Wed Dec 11 06:50:56 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A201ADF46 for ; Wed, 11 Dec 2013 06:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dknc2VEy_WOS for ; Wed, 11 Dec 2013 06:50:54 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id A99551ADF2F for ; Wed, 11 Dec 2013 06:50:52 -0800 (PST) Received: from [192.168.101.75] (unknown [72.46.244.148]) by smtp7.webway.se (Postfix) with ESMTPA id 837EC93C2A2; Wed, 11 Dec 2013 14:50:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: "Olle E. Johansson" In-Reply-To: Date: Wed, 11 Dec 2013 09:50:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> To: Cullen Jennings X-Mailer: Apple Mail (2.1822) Cc: SIPCORE WG , Olle E Johansson , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 14:50:56 -0000 On 10 Dec 2013, at 18:13, Cullen Jennings wrote: >=20 > Well from a milestone point of view there is a big difference between = we need the change an existing RFC (i.e. update) or we need to define a = new RFC that tells developers who want to implement the new RFC what = they need to do.=20 >=20 > I think what is needed here is the later item and not the update. I = have asked about this a bunch of times and and I always get answers that = suggest that a new document is needed but it does not need to replace or = update 3263. It needs to be a new document that provides more detailed = advice. If we are going to say this updates something, I want to be = convinced first that there is something that is wrong and needs to be = changed. I'm fine with the idea that ore detailed specifications are = needed to do something like happy eyeballs for SIP but I don't think = that requires an update of 3263.=20 I am fine with a milestone that doesn't say update. If we discover later = that an update really is required, we can still add a milestone for = that. I just want to get the work started at this point. /O >=20 >=20 > On Dec 10, 2013, at 12:21 PM, Olle E. Johansson = wrote: >=20 >>=20 >> On 10 Dec 2013, at 12:14, Cullen Jennings wrote: >>=20 >>>=20 >>> On Dec 10, 2013, at 9:59 AM, Paul Kyzivat = wrote: >>>=20 >>>> June 2014 Updated procedures for dual-stack server handling of SIP >>>> URIs containing domain names >>>=20 >>> Before we use update, can someone tell me what normative text of the = current RFCs need to be changed? >>>=20 >>=20 >> That's part of the problem, RFC 3263 is not very clear to me in = indicating what exactly is normative. If you read our draft, you will = see that we point to a few sections that clearly says that a UA needs to = look up "A or AAAA" records, which has been proven wrong and doesn't = follow the intention of the DNS SRV RFC. If this was unintentional or = normative, I don't know, but it's written enough times to cause issues = in implementations and have been copied to other documents, like the = MSRP RFC. >>=20 >> We need to clarify that a SIP implementation needs to follow the DNS = SRV RFC and look up all addresses for a host name (ipv4, IPv6 or future = address families) and test them all before moving to the next priority = and host. >>=20 >> I've checked this with members of the IETF DNS directorate two times = now, and they agree with this. >>=20 >> When we clarified/updated/extended/informed the audience - developers = - about this, we need to get down to how to connect - serially, in = parallell, in reverse random order controlled by the phases of the moon = or other planets - or simply Happy Eyeballs. But even with TCP, doing = happy eyeballs like in HTTP would not work unless we have both A and = AAAA records. RFC 3263 doesn't really indicate that. >>=20 >> Someone else needs to help out to clarify to me what is really = normative in 3263 and what the relationship between 3263 and RFC 2782 = really is - if RFC 2782 is the normative one and RFC 3263 just can be = seen as a happy story that points to 2782 without making any normative = changes, we might have to clarify that in an informational document and = move on to connection setup in a dual stack world. If RFC 3263 changes = the behaviour intended by 2782 and really forces a developer to select A = or AAAA records, then we need to change that behaviour. >>=20 >> Either way, we have work to do in ths wg. >> /O >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From brett@broadsoft.com Wed Dec 11 08:40:39 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469BE1ADF80 for ; Wed, 11 Dec 2013 08:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1BhHIN7O3fe for ; Wed, 11 Dec 2013 08:40:38 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id E8E0C1ADEA7 for ; Wed, 11 Dec 2013 08:40:37 -0800 (PST) Received: from CASUMHUB03.citservers.local (172.16.98.219) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 11 Dec 2013 08:42:28 -0800 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Wed, 11 Dec 2013 08:42:28 -0800 From: Brett Tate To: "draft-ietf-straw-sip-traceroute@tools.ietf.org" , "sipcore@ietf.org" Thread-Topic: draft-ietf-straw-sip-traceroute-01: WGLC comments Thread-Index: Ac72j7SabFUxvCuYTzG4rWshBxRIKA== Date: Wed, 11 Dec 2013 16:42:28 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A06D77E@MBX08.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-straw-sip-traceroute-01: WGLC comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 16:40:39 -0000 Hi, The following are some comments concerning draft-ietf-straw-sip-traceroute-= 01. Thanks, Brett ------- Section 3: - B2bua-Hops should be Max-Forwards. Section 3.2 paragraph 1: - Potentially could clarify that the middle box is answering because of Max= -Forwards 0 (instead of answering for another reason). Section 3.2 paragraph 2: - As discussed within the following email, I agree that requiring a specifi= c reason-text value might not desirable. This is because I view the text p= arameter to be similar to the status-line's reason-phrase. If something is= needed instead of just 483 for automation reasons, the reason-params poten= tially could be expanded to include a new parameter such as "traceroute". http://www.ietf.org/mail-archive/web/straw/current/msg00194.html Section 7: - [RFC3261] should be added; it is referenced within section 3.1. This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, and destroy = all copies of this message, along with any attachment, prior to reading, di= stributing or copying it. From pkyzivat@alum.mit.edu Wed Dec 11 12:49:15 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA7E1AE090 for ; Wed, 11 Dec 2013 12:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOCVNcZHDuxj for ; Wed, 11 Dec 2013 12:49:14 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id E53631ADF55 for ; Wed, 11 Dec 2013 12:49:13 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta14.westchester.pa.mail.comcast.net with comcast id 0JsF1n0041YDfWL5ELp87w; Wed, 11 Dec 2013 20:49:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id 0Lp71n00A3ZTu2S3gLp7wA; Wed, 11 Dec 2013 20:49:08 +0000 Message-ID: <52A8CFC3.3080309@alum.mit.edu> Date: Wed, 11 Dec 2013 15:49:07 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Cullen Jennings , "Olle E. Johansson" References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386794948; bh=5xSUCrEqonOQP07EB/WNnyaCeXoQg3wP8IZKlmdYvEk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DI6ysDqg5ysn0e1LTBQlMdqcVhQf5s/o2lVJpsMSU1f46LOpvtTWtCPO4/D7oXYzV wmMABP4mK85Pt5yD3FXIPpmn/QKMm4mK0DjEIwrtUiQtLceRRxqojyOLGx/tRlcI1p JXi1xOj3Suew90M5XWlePQLo7v79wLg+r3XMbu1Vr68ONF/iYasgmxeFUH/ovwBAO/ onb0jwyXq+o9wR+L03MiRT8guvPXhnlN86oDVk4tijDo+MEAxUFKIeyhFp3AhnDAn1 dAj01yRfZIwD/ppBeAsGYbdtCQ5qyYrTe5w4UBe++yd3vkBhk9Kp9tvE4WBEdvziVV DABzA/HET9f/A== Cc: SIPCORE WG , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 20:49:15 -0000 Cullen, Would you be satisfied if the milestone is sufficiently vague that we can leave it to the deliverable to decide whether an update is needed or not? Thanks, Paul On 12/10/13 6:13 PM, Cullen Jennings wrote: > > Well from a milestone point of view there is a big difference between we need the change an existing RFC (i.e. update) or we need to define a new RFC that tells developers who want to implement the new RFC what they need to do. > > I think what is needed here is the later item and not the update. I have asked about this a bunch of times and and I always get answers that suggest that a new document is needed but it does not need to replace or update 3263. It needs to be a new document that provides more detailed advice. If we are going to say this updates something, I want to be convinced first that there is something that is wrong and needs to be changed. I'm fine with the idea that ore detailed specifications are needed to do something like happy eyeballs for SIP but I don't think that requires an update of 3263. > > > On Dec 10, 2013, at 12:21 PM, Olle E. Johansson wrote: > >> >> On 10 Dec 2013, at 12:14, Cullen Jennings wrote: >> >>> >>> On Dec 10, 2013, at 9:59 AM, Paul Kyzivat wrote: >>> >>>> June 2014 Updated procedures for dual-stack server handling of SIP >>>> URIs containing domain names >>> >>> Before we use update, can someone tell me what normative text of the current RFCs need to be changed? >>> >> >> That's part of the problem, RFC 3263 is not very clear to me in indicating what exactly is normative. If you read our draft, you will see that we point to a few sections that clearly says that a UA needs to look up "A or AAAA" records, which has been proven wrong and doesn't follow the intention of the DNS SRV RFC. If this was unintentional or normative, I don't know, but it's written enough times to cause issues in implementations and have been copied to other documents, like the MSRP RFC. >> >> We need to clarify that a SIP implementation needs to follow the DNS SRV RFC and look up all addresses for a host name (ipv4, IPv6 or future address families) and test them all before moving to the next priority and host. >> >> I've checked this with members of the IETF DNS directorate two times now, and they agree with this. >> >> When we clarified/updated/extended/informed the audience - developers - about this, we need to get down to how to connect - serially, in parallell, in reverse random order controlled by the phases of the moon or other planets - or simply Happy Eyeballs. But even with TCP, doing happy eyeballs like in HTTP would not work unless we have both A and AAAA records. RFC 3263 doesn't really indicate that. >> >> Someone else needs to help out to clarify to me what is really normative in 3263 and what the relationship between 3263 and RFC 2782 really is - if RFC 2782 is the normative one and RFC 3263 just can be seen as a happy story that points to 2782 without making any normative changes, we might have to clarify that in an informational document and move on to connection setup in a dual stack world. If RFC 3263 changes the behaviour intended by 2782 and really forces a developer to select A or AAAA records, then we need to change that behaviour. >> >> Either way, we have work to do in ths wg. >> /O > > From mary.ietf.barnes@gmail.com Thu Dec 12 08:59:54 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11091ADF6E for ; Thu, 12 Dec 2013 08:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OZg82rrWa5u for ; Thu, 12 Dec 2013 08:59:51 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1D46E1ADF67 for ; Thu, 12 Dec 2013 08:59:50 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id t60so731722wes.34 for ; Thu, 12 Dec 2013 08:59:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v6tpkUQaPq3/4RhuaqhA9UYQc1ufuTsQPgjbeuh3HOc=; b=IGr+os+pwp3pkXFesw1xdnr9wcK4LcUaIgRxU1TEYFWbHvPmEsiNQOtpH8SKvM2Lxz TzQgvYBRsOUHH0j7VFpxSiLkQAD350McrEqCZHEWF22eq/m2dg5hlaelj64KRXaE8zVV +raCb8oXMYlm/QSz9l049gOkcGtNB8K8RCI6egsisDjRI2xJdqct2qqBvM3cNRyvWu5t Jekvls6TXkI0i54DV1S+KqrIg9cFkCPO7ct/h6k+o/YLyTAAsPLb8XMPPQ0IeRFQVFbs spoaB0Y4PCeoDC6nauHQZaOh2NThmqOVDPo5MSE+sjLDX7Pxkg4Sqz8SasQ0P6XKow57 IDZw== MIME-Version: 1.0 X-Received: by 10.180.206.41 with SMTP id ll9mr8461421wic.7.1386867584373; Thu, 12 Dec 2013 08:59:44 -0800 (PST) Received: by 10.216.172.9 with HTTP; Thu, 12 Dec 2013 08:59:44 -0800 (PST) In-Reply-To: <52A8CFC3.3080309@alum.mit.edu> References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> Date: Thu, 12 Dec 2013 10:59:44 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11c38882b797d204ed5945a2 Cc: SIPCORE WG , "Olle E. Johansson" , "Gonzalo Salgueiro \(gsalguei\)" , Cullen Jennings Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 16:59:54 -0000 --001a11c38882b797d204ed5945a2 Content-Type: text/plain; charset=ISO-8859-1 The question in my mind becomes how you can word it properly. There are already procedures for dual stack, so you can't just say: Procedures for dual-stack server handling of SIP URIs containing domain names Any of the adjectives proposed so far "Amended" or "Updated" or others that might seem appropriate, e.g., "Enhanced" imply that the existing procedures are being changed or corrected. Although maybe "Enhanced" is general enough to not necessarily imply an "Update" to RFC 3263? But, then would you be talking about an Informational versus standards track document? I think it's usual for milestones to indicate whether the work is informational, standards track or BCP. But, if the AD will approve the new milestone without that level of specificity, that's fine. But, I also don't think it's useful for the group to rathole on that later in the process and it will definitely cause confusion if the WG doesn't have a clear reason why the specific type of specification was selected. Regards, Mary. On Wed, Dec 11, 2013 at 2:49 PM, Paul Kyzivat wrote: > Cullen, > > Would you be satisfied if the milestone is sufficiently vague that we can > leave it to the deliverable to decide whether an update is needed or not? > > Thanks, > Paul > > > On 12/10/13 6:13 PM, Cullen Jennings wrote: > >> >> Well from a milestone point of view there is a big difference between we >> need the change an existing RFC (i.e. update) or we need to define a new >> RFC that tells developers who want to implement the new RFC what they need >> to do. >> >> I think what is needed here is the later item and not the update. I have >> asked about this a bunch of times and and I always get answers that suggest >> that a new document is needed but it does not need to replace or update >> 3263. It needs to be a new document that provides more detailed advice. If >> we are going to say this updates something, I want to be convinced first >> that there is something that is wrong and needs to be changed. I'm fine >> with the idea that ore detailed specifications are needed to do something >> like happy eyeballs for SIP but I don't think that requires an update of >> 3263. >> >> >> On Dec 10, 2013, at 12:21 PM, Olle E. Johansson wrote: >> >> >>> On 10 Dec 2013, at 12:14, Cullen Jennings wrote: >>> >>> >>>> On Dec 10, 2013, at 9:59 AM, Paul Kyzivat >>>> wrote: >>>> >>>> June 2014 Updated procedures for dual-stack server handling of SIP >>>>> URIs containing domain names >>>>> >>>> >>>> Before we use update, can someone tell me what normative text of the >>>> current RFCs need to be changed? >>>> >>>> >>> That's part of the problem, RFC 3263 is not very clear to me in >>> indicating what exactly is normative. If you read our draft, you will see >>> that we point to a few sections that clearly says that a UA needs to look >>> up "A or AAAA" records, which has been proven wrong and doesn't follow the >>> intention of the DNS SRV RFC. If this was unintentional or normative, I >>> don't know, but it's written enough times to cause issues in >>> implementations and have been copied to other documents, like the MSRP RFC. >>> >>> We need to clarify that a SIP implementation needs to follow the DNS SRV >>> RFC and look up all addresses for a host name (ipv4, IPv6 or future address >>> families) and test them all before moving to the next priority and host. >>> >>> I've checked this with members of the IETF DNS directorate two times >>> now, and they agree with this. >>> >>> When we clarified/updated/extended/informed the audience - developers - >>> about this, we need to get down to how to connect - serially, in parallell, >>> in reverse random order controlled by the phases of the moon or other >>> planets - or simply Happy Eyeballs. But even with TCP, doing happy eyeballs >>> like in HTTP would not work unless we have both A and AAAA records. RFC >>> 3263 doesn't really indicate that. >>> >>> Someone else needs to help out to clarify to me what is really normative >>> in 3263 and what the relationship between 3263 and RFC 2782 really is - if >>> RFC 2782 is the normative one and RFC 3263 just can be seen as a happy >>> story that points to 2782 without making any normative changes, we might >>> have to clarify that in an informational document and move on to connection >>> setup in a dual stack world. If RFC 3263 changes the behaviour intended by >>> 2782 and really forces a developer to select A or AAAA records, then we >>> need to change that behaviour. >>> >>> Either way, we have work to do in ths wg. >>> /O >>> >> >> >> > --001a11c38882b797d204ed5945a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The question in my mind becomes how you can word it proper= ly. =A0There are already procedures for dual stack, so you can't just s= ay:

Procedures for dual-stack server handling of SIP UR= Is containing domain names

Any of the adjectives proposed so far &q= uot;Amended" or "Updated" or others that might seem appropri= ate, e.g., "Enhanced" imply that the existing procedures are bein= g changed or corrected. =A0Although maybe "Enhanced" is general e= nough to not necessarily imply an "Update" to RFC 3263? =A0 But, = then would you be talking about an Informational versus standards track doc= ument? =A0 I think it's usual for milestones to indicate whether the wo= rk is informational, standards track or BCP. =A0But, if the AD will approve= the new milestone without that level of specificity, that's fine. But,= I also don't think it's useful for the group to rathole on that la= ter in the process and it will definitely cause confusion if the WG doesn&#= 39;t have a clear reason why the specific type of specification was selecte= d.

Regards,
Mary.= =A0



On Wed, Dec 11, 2013 at 2:49 PM, Paul Kyzivat <pkyziv= at@alum.mit.edu> wrote:
Cullen,

Would you be satisfied if the milestone is sufficiently vague that we can l= eave it to the deliverable to decide whether an update is needed or not?
=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


On 12/10/13 6:13 PM, Cullen Jennings wrote:

Well from a milestone point of view there is a big difference between we ne= ed the change an existing RFC (i.e. update) or we need to define a new RFC = that tells developers who want to implement the new RFC what they need to d= o.

I think what is needed here is the later item and not the update. I have as= ked about this a bunch of times and and I always get answers that suggest t= hat a new document is needed but it does not need to replace or update 3263= . It needs to be a new document that provides more detailed advice. If we a= re going to say this updates something, I want to be convinced first that t= here is something that is wrong and needs to be changed. I'm fine with = the idea that ore detailed specifications are needed to do something like h= appy eyeballs for SIP but I don't think that requires an update of 3263= .


On Dec 10, 2013, at 12:21 PM, Olle E. Johansson <oej@edvina.net> wrote:


On 10 Dec 2013, at 12:14, Cullen Jennings <fluffy@iii.ca> wrote:


On Dec 10, 2013, at 9:59 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

June 2014 =A0Updated procedures for dual-stack server handling of SIP
=A0 URIs containing domain names

Before we use update, can someone tell me what normative text of the curren= t RFCs need to be changed?


That's part of the problem, RFC 3263 is not very clear to me in indicat= ing what exactly is normative. If you read our draft, you will see that we = point to a few sections that clearly says that a UA needs to look up "= A or AAAA" records, which has been proven wrong and doesn't follow= the intention of the DNS SRV RFC. If this was unintentional or normative, = I don't know, but it's written enough times to cause issues in impl= ementations and have been copied to other documents, like the MSRP RFC.

We need to clarify that a SIP implementation needs to follow the DNS SRV RF= C and look up all addresses for a host name (ipv4, IPv6 or future address f= amilies) and test them all before moving to the next priority and host.

I've checked this with members of the IETF DNS directorate two times no= w, and they agree with this.

When we clarified/updated/extended/informed the audience - developer= s - about this, we need to get down to how to connect - serially, in parall= ell, in reverse random order controlled by the phases of the moon or other = planets - or simply Happy Eyeballs. But even with TCP, doing happy eyeballs= like in HTTP would not work unless we have both A and AAAA records. RFC 32= 63 doesn't really indicate that.

Someone else needs to help out to clarify to me what is really normative in= 3263 and what the relationship between 3263 and RFC 2782 really is - if RF= C 2782 is the normative one and RFC 3263 just can be seen as a happy story = that points to 2782 without making any normative changes, we might have to = clarify that in an informational document and move on to connection setup i= n a dual stack world. If RFC 3263 changes the behaviour intended by 2782 an= d really forces a developer to select A or AAAA records, then we need to ch= ange that behaviour.

Either way, we have work to do in ths wg.
/O




--001a11c38882b797d204ed5945a2-- From gsalguei@cisco.com Thu Dec 12 09:21:50 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102EC1AE34E for ; Thu, 12 Dec 2013 09:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q4F_AXaBC_6 for ; Thu, 12 Dec 2013 09:21:47 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 14B201AE02C for ; Thu, 12 Dec 2013 09:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5348; q=dns/txt; s=iport; t=1386868901; x=1388078501; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RLtTABKRfIny7AHtcor6iH/fg3hvA0wtTF18HD5dRrs=; b=EELC93xBLfx57Ng2UYc4UjNfXNCH/0hH9ukuc85Ho4PfQ2nibk108EWx tqFh9l5hmq+HedH+qheDw2yxkAaEFWec15Kfo+j3joESP7OHWL+eE+tTp fVbc4AD2BmPcS7RsJC18UlptwvkMJVl9kNvUyHg34dFAjRx8PFBpQib+P w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAEbwqVKtJXG//2dsb2JhbABZgwo4VbgNToEcFnSCJQEBAQMBAQEBJkUEBwULAgECBhguIQYLJQIEDgWHcAMJCA27TA2HEhMEjQCBYTMHgyGBEwSJC4sngXiBa4xahTqDKYIq X-IronPort-AV: E=Sophos;i="4.93,879,1378857600"; d="scan'208";a="290965902" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 12 Dec 2013 17:21:40 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBCHLcfI018238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 17:21:38 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 11:21:38 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Mary Barnes Thread-Topic: [sipcore] IPv6 in the sip core wg Thread-Index: AQHO8oXtPaG9LxtinkCT+HMY0fMEHZpH0MUAgAV1OYCAA4wfHIAAaqQA Importance: high X-Priority: 1 Date: Thu, 12 Dec 2013 17:21:37 +0000 Message-ID: <330BB06A-EC15-437A-9B57-C56037D93F8E@cisco.com> References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.222.152] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Cullen Jennings , SIPCORE WG , "Olle E. Johansson" , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 17:21:50 -0000 Normative procedure are being prescribed, so it is undoubtedly Standards Tr= ack IMO. Enhanced/Improved/Refined all seem fine to me and don't imply that= this work formally updates 3263. That is a discussion detail we can have = once we actually have some concrete text adopted and the WG can weigh in wi= th their preference.=20 Gonzalo On Dec 12, 2013, at 11:59 AM, Mary Barnes wrot= e: > The question in my mind becomes how you can word it properly. There are = already procedures for dual stack, so you can't just say: >=20 > Procedures for dual-stack server handling of SIP URIs containing domain n= ames >=20 > Any of the adjectives proposed so far "Amended" or "Updated" or others th= at might seem appropriate, e.g., "Enhanced" imply that the existing procedu= res are being changed or corrected. Although maybe "Enhanced" is general e= nough to not necessarily imply an "Update" to RFC 3263? But, then would y= ou be talking about an Informational versus standards track document? I t= hink it's usual for milestones to indicate whether the work is informationa= l, standards track or BCP. But, if the AD will approve the new milestone w= ithout that level of specificity, that's fine. But, I also don't think it's= useful for the group to rathole on that later in the process and it will d= efinitely cause confusion if the WG doesn't have a clear reason why the spe= cific type of specification was selected. >=20 > Regards, > Mary.=20 >=20 >=20 >=20 > On Wed, Dec 11, 2013 at 2:49 PM, Paul Kyzivat wro= te: > Cullen, >=20 > Would you be satisfied if the milestone is sufficiently vague that we can= leave it to the deliverable to decide whether an update is needed or not? >=20 > Thanks, > Paul >=20 >=20 > On 12/10/13 6:13 PM, Cullen Jennings wrote: >=20 > Well from a milestone point of view there is a big difference between we = need the change an existing RFC (i.e. update) or we need to define a new RF= C that tells developers who want to implement the new RFC what they need to= do. >=20 > I think what is needed here is the later item and not the update. I have = asked about this a bunch of times and and I always get answers that suggest= that a new document is needed but it does not need to replace or update 32= 63. It needs to be a new document that provides more detailed advice. If we= are going to say this updates something, I want to be convinced first that= there is something that is wrong and needs to be changed. I'm fine with th= e idea that ore detailed specifications are needed to do something like hap= py eyeballs for SIP but I don't think that requires an update of 3263. >=20 >=20 > On Dec 10, 2013, at 12:21 PM, Olle E. Johansson wrote: >=20 >=20 > On 10 Dec 2013, at 12:14, Cullen Jennings wrote: >=20 >=20 > On Dec 10, 2013, at 9:59 AM, Paul Kyzivat wrote: >=20 > June 2014 Updated procedures for dual-stack server handling of SIP > URIs containing domain names >=20 > Before we use update, can someone tell me what normative text of the curr= ent RFCs need to be changed? >=20 >=20 > That's part of the problem, RFC 3263 is not very clear to me in indicatin= g what exactly is normative. If you read our draft, you will see that we po= int to a few sections that clearly says that a UA needs to look up "A or AA= AA" records, which has been proven wrong and doesn't follow the intention o= f the DNS SRV RFC. If this was unintentional or normative, I don't know, bu= t it's written enough times to cause issues in implementations and have bee= n copied to other documents, like the MSRP RFC. >=20 > We need to clarify that a SIP implementation needs to follow the DNS SRV = RFC and look up all addresses for a host name (ipv4, IPv6 or future address= families) and test them all before moving to the next priority and host. >=20 > I've checked this with members of the IETF DNS directorate two times now,= and they agree with this. >=20 > When we clarified/updated/extended/informed the audience - developers - a= bout this, we need to get down to how to connect - serially, in parallell, = in reverse random order controlled by the phases of the moon or other plane= ts - or simply Happy Eyeballs. But even with TCP, doing happy eyeballs like= in HTTP would not work unless we have both A and AAAA records. RFC 3263 do= esn't really indicate that. >=20 > Someone else needs to help out to clarify to me what is really normative = in 3263 and what the relationship between 3263 and RFC 2782 really is - if = RFC 2782 is the normative one and RFC 3263 just can be seen as a happy stor= y that points to 2782 without making any normative changes, we might have t= o clarify that in an informational document and move on to connection setup= in a dual stack world. If RFC 3263 changes the behaviour intended by 2782 = and really forces a developer to select A or AAAA records, then we need to = change that behaviour. >=20 > Either way, we have work to do in ths wg. > /O >=20 >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Thu Dec 12 09:59:52 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914911AE3A2 for ; Thu, 12 Dec 2013 09:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF__kkKwhn14 for ; Thu, 12 Dec 2013 09:59:51 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 04EEB1AE3A1 for ; Thu, 12 Dec 2013 09:59:50 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta14.westchester.pa.mail.comcast.net with comcast id 0cQF1n0020cZkys5EhzkNF; Thu, 12 Dec 2013 17:59:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id 0hzk1n00A3ZTu2S3WhzkNz; Thu, 12 Dec 2013 17:59:44 +0000 Message-ID: <52A9F990.1030201@alum.mit.edu> Date: Thu, 12 Dec 2013 12:59:44 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Mary Barnes References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386871184; bh=Shye+IByqoqrrqz3cQ1OQxjt4iKoANWyBtrp/ViU5cA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YV0fzdjkO26YNG6z58ZqunM9ubPTnrOV0vmIdg+Xga8PP3C1R6XMJOQWwQ4Tk3Ke+ MElkkdP4nXq0Hy056UDY+cUa9IHK4Tshl5ITDMzywK84PtenGeMfoAn5jmqIyIzW7Q xzyrFMhGCSezz4XbGg5vcA3tsKxjDnaKReQRSQYckmMBVLBt4OD1+dwF+5kZ51dTic HZ79OKh2mMDj5QYIR3cz0F5XI6Ox5xOVHDT9VkuxANUpDacY9UY0Sd+H1fd20aXAH4 OiNgNdBgtS+RHIruIBs837z2+JUV7n8u8V6QLx+bCommTJ49a8SvGizNrlvx+4xZAA Lt5EfLt2HB83w== Cc: SIPCORE WG , "Olle E. Johansson" , "Gonzalo Salgueiro \(gsalguei\)" , Cullen Jennings Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 17:59:52 -0000 On 12/12/13 11:59 AM, Mary Barnes wrote: > The question in my mind becomes how you can word it properly. There are > already procedures for dual stack, so you can't just say: > > Procedures for dual-stack server handling of SIP URIs containing domain > names > > Any of the adjectives proposed so far "Amended" or "Updated" or others > that might seem appropriate, e.g., "Enhanced" imply that the existing > procedures are being changed or corrected. Although maybe "Enhanced" is > general enough to not necessarily imply an "Update" to RFC 3263? But, > then would you be talking about an Informational versus standards track > document? I think it's usual for milestones to indicate whether the > work is informational, standards track or BCP. But, if the AD will > approve the new milestone without that level of specificity, that's > fine. ISTM that we are in a situation where we need to consider the details of the proposed mechanism(s) before deciding if the desired mechanism will be an update or not. So I think it makes sense to word the milestone to be non-specific about this. Maybe its not the term itself that is the problem, but rather what the term references. IOW, is it that we intend to ammend/update/enhance/improve the *procedures*, or the *description* of the procedures? IIUC the intent is to clarify the description, and if that is insufficient to get a satisfactory result, then to update the procedures themselves. Thanks, Paul > But, I also don't think it's useful for the group to rathole on > that later in the process and it will definitely cause confusion if the > WG doesn't have a clear reason why the specific type of specification > was selected. > > Regards, > Mary. > > > > On Wed, Dec 11, 2013 at 2:49 PM, Paul Kyzivat > wrote: > > Cullen, > > Would you be satisfied if the milestone is sufficiently vague that > we can leave it to the deliverable to decide whether an update is > needed or not? > > Thanks, > Paul > > > On 12/10/13 6:13 PM, Cullen Jennings wrote: > > > Well from a milestone point of view there is a big difference > between we need the change an existing RFC (i.e. update) or we > need to define a new RFC that tells developers who want to > implement the new RFC what they need to do. > > I think what is needed here is the later item and not the > update. I have asked about this a bunch of times and and I > always get answers that suggest that a new document is needed > but it does not need to replace or update 3263. It needs to be a > new document that provides more detailed advice. If we are going > to say this updates something, I want to be convinced first that > there is something that is wrong and needs to be changed. I'm > fine with the idea that ore detailed specifications are needed > to do something like happy eyeballs for SIP but I don't think > that requires an update of 3263. > > > On Dec 10, 2013, at 12:21 PM, Olle E. Johansson > wrote: > > > On 10 Dec 2013, at 12:14, Cullen Jennings > wrote: > > > On Dec 10, 2013, at 9:59 AM, Paul Kyzivat > > > wrote: > > June 2014 Updated procedures for dual-stack server > handling of SIP > URIs containing domain names > > > Before we use update, can someone tell me what normative > text of the current RFCs need to be changed? > > > That's part of the problem, RFC 3263 is not very clear to me > in indicating what exactly is normative. If you read our > draft, you will see that we point to a few sections that > clearly says that a UA needs to look up "A or AAAA" records, > which has been proven wrong and doesn't follow the intention > of the DNS SRV RFC. If this was unintentional or normative, > I don't know, but it's written enough times to cause issues > in implementations and have been copied to other documents, > like the MSRP RFC. > > We need to clarify that a SIP implementation needs to follow > the DNS SRV RFC and look up all addresses for a host name > (ipv4, IPv6 or future address families) and test them all > before moving to the next priority and host. > > I've checked this with members of the IETF DNS directorate > two times now, and they agree with this. > > When we clarified/updated/extended/__informed the audience - > developers - about this, we need to get down to how to > connect - serially, in parallell, in reverse random order > controlled by the phases of the moon or other planets - or > simply Happy Eyeballs. But even with TCP, doing happy > eyeballs like in HTTP would not work unless we have both A > and AAAA records. RFC 3263 doesn't really indicate that. > > Someone else needs to help out to clarify to me what is > really normative in 3263 and what the relationship between > 3263 and RFC 2782 really is - if RFC 2782 is the normative > one and RFC 3263 just can be seen as a happy story that > points to 2782 without making any normative changes, we > might have to clarify that in an informational document and > move on to connection setup in a dual stack world. If RFC > 3263 changes the behaviour intended by 2782 and really > forces a developer to select A or AAAA records, then we need > to change that behaviour. > > Either way, we have work to do in ths wg. > /O > > > > > From gsalguei@cisco.com Thu Dec 12 11:19:04 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3AD1ADF74 for ; Thu, 12 Dec 2013 11:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLnBZUbekPhi for ; Thu, 12 Dec 2013 11:19:01 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9C67A1AE138 for ; Thu, 12 Dec 2013 11:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6603; q=dns/txt; s=iport; t=1386875936; x=1388085536; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lm3iw7mtzQuQ1KhjbcGtO2EUnbJDUK1NqFy1bg37y1g=; b=m6sJoclYyVZl1ED9J2O3yxj3aaYie2z0O0IL8/zJ6I6pJTAQvjTsBN33 qYwUmvhdzezdvOO6wWu9V18uQ/7QZ+OrjJvOqTYJ4yWrE2FqiJ5F1gBW1 U5qEI1xgXAoMG/8P94wpzfC117eg5gHTIwpbrE0CnutKG4aDVpjLa5Zl8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAFwLqlKtJV2Z/2dsb2JhbABZDoJ8OFW4W4EdFnSCJQEBAQMBKUkHBQsCAQIGDgonBzIUEQIEDgWHfAjDDheOYTMHgyGBEwSJC4sng2OSFIJqP4Iq X-IronPort-AV: E=Sophos;i="4.95,473,1384300800"; d="scan'208";a="6369628" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 12 Dec 2013 19:18:55 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBCJItwU025362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 19:18:55 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 13:18:54 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat Thread-Topic: [sipcore] IPv6 in the sip core wg Thread-Index: AQHO92PvPaG9LxtinkCT+HMY0fMEHZpRU8qA Importance: high X-Priority: 1 Date: Thu, 12 Dec 2013 19:18:54 +0000 Message-ID: <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> In-Reply-To: <52A9F990.1030201@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.222.152] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5CF1CE85ED99FD46AC53BA80219D2ACD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIPCORE WG , "Olle E. Johansson" , "Gonzalo Salgueiro \(gsalguei\)" , Cullen Jennings Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 19:19:04 -0000 On Dec 12, 2013, at 12:59 PM, Paul Kyzivat wrote: > On 12/12/13 11:59 AM, Mary Barnes wrote: >> The question in my mind becomes how you can word it properly. There are >> already procedures for dual stack, so you can't just say: >>=20 >> Procedures for dual-stack server handling of SIP URIs containing domain >> names >>=20 >> Any of the adjectives proposed so far "Amended" or "Updated" or others >> that might seem appropriate, e.g., "Enhanced" imply that the existing >> procedures are being changed or corrected. Although maybe "Enhanced" is >> general enough to not necessarily imply an "Update" to RFC 3263? But, >> then would you be talking about an Informational versus standards track >> document? I think it's usual for milestones to indicate whether the >> work is informational, standards track or BCP. But, if the AD will >> approve the new milestone without that level of specificity, that's >> fine. >=20 > ISTM that we are in a situation where we need to consider the details of = the proposed mechanism(s) before deciding if the desired mechanism will be = an update or not. So I think it makes sense to word the milestone to be non= -specific about this. >=20 > Maybe its not the term itself that is the problem, but rather what the te= rm references. IOW, is it that we intend to ammend/update/enhance/improve t= he *procedures*, or the *description* of the procedures? >=20 > IIUC the intent is to clarify the description, and if that is insufficien= t to get a satisfactory result, then to update the procedures themselves. So what is the proposed text for the milestone? Gonzalo >=20 > Thanks, > Paul >=20 >> But, I also don't think it's useful for the group to rathole on >> that later in the process and it will definitely cause confusion if the >> WG doesn't have a clear reason why the specific type of specification >> was selected. >>=20 >> Regards, >> Mary. >>=20 >>=20 >>=20 >> On Wed, Dec 11, 2013 at 2:49 PM, Paul Kyzivat > > wrote: >>=20 >> Cullen, >>=20 >> Would you be satisfied if the milestone is sufficiently vague that >> we can leave it to the deliverable to decide whether an update is >> needed or not? >>=20 >> Thanks, >> Paul >>=20 >>=20 >> On 12/10/13 6:13 PM, Cullen Jennings wrote: >>=20 >>=20 >> Well from a milestone point of view there is a big difference >> between we need the change an existing RFC (i.e. update) or we >> need to define a new RFC that tells developers who want to >> implement the new RFC what they need to do. >>=20 >> I think what is needed here is the later item and not the >> update. I have asked about this a bunch of times and and I >> always get answers that suggest that a new document is needed >> but it does not need to replace or update 3263. It needs to be a >> new document that provides more detailed advice. If we are going >> to say this updates something, I want to be convinced first that >> there is something that is wrong and needs to be changed. I'm >> fine with the idea that ore detailed specifications are needed >> to do something like happy eyeballs for SIP but I don't think >> that requires an update of 3263. >>=20 >>=20 >> On Dec 10, 2013, at 12:21 PM, Olle E. Johansson > > wrote: >>=20 >>=20 >> On 10 Dec 2013, at 12:14, Cullen Jennings > > wrote: >>=20 >>=20 >> On Dec 10, 2013, at 9:59 AM, Paul Kyzivat >> > >> wrote: >>=20 >> June 2014 Updated procedures for dual-stack server >> handling of SIP >> URIs containing domain names >>=20 >>=20 >> Before we use update, can someone tell me what normative >> text of the current RFCs need to be changed? >>=20 >>=20 >> That's part of the problem, RFC 3263 is not very clear to me >> in indicating what exactly is normative. If you read our >> draft, you will see that we point to a few sections that >> clearly says that a UA needs to look up "A or AAAA" records, >> which has been proven wrong and doesn't follow the intention >> of the DNS SRV RFC. If this was unintentional or normative, >> I don't know, but it's written enough times to cause issues >> in implementations and have been copied to other documents, >> like the MSRP RFC. >>=20 >> We need to clarify that a SIP implementation needs to follow >> the DNS SRV RFC and look up all addresses for a host name >> (ipv4, IPv6 or future address families) and test them all >> before moving to the next priority and host. >>=20 >> I've checked this with members of the IETF DNS directorate >> two times now, and they agree with this. >>=20 >> When we clarified/updated/extended/__informed the audience - >> developers - about this, we need to get down to how to >> connect - serially, in parallell, in reverse random order >> controlled by the phases of the moon or other planets - or >> simply Happy Eyeballs. But even with TCP, doing happy >> eyeballs like in HTTP would not work unless we have both A >> and AAAA records. RFC 3263 doesn't really indicate that. >>=20 >> Someone else needs to help out to clarify to me what is >> really normative in 3263 and what the relationship between >> 3263 and RFC 2782 really is - if RFC 2782 is the normative >> one and RFC 3263 just can be seen as a happy story that >> points to 2782 without making any normative changes, we >> might have to clarify that in an informational document and >> move on to connection setup in a dual stack world. If RFC >> 3263 changes the behaviour intended by 2782 and really >> forces a developer to select A or AAAA records, then we need >> to change that behaviour. >>=20 >> Either way, we have work to do in ths wg. >> /O >>=20 >>=20 >>=20 >>=20 >>=20 >=20 From keith.drage@alcatel-lucent.com Thu Dec 12 13:46:46 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1A81AE0C5 for ; Thu, 12 Dec 2013 13:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8axV2mTz3Ka for ; Thu, 12 Dec 2013 13:46:43 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 6D08A1ADFCF for ; Thu, 12 Dec 2013 13:46:42 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rBCLjtkY001567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Dec 2013 15:45:57 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rBCLjrIN016439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 22:45:53 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 12 Dec 2013 22:45:53 +0100 From: "DRAGE, Keith (Keith)" To: "Gonzalo Salgueiro (gsalguei)" , Paul Kyzivat Thread-Topic: [sipcore] IPv6 in the sip core wg Thread-Index: AQHO9f1rFmxMwFa6OUik7RkhLMXct5pQy0fD////2gCAABYeAIAAHQCA Date: Thu, 12 Dec 2013 21:45:51 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> In-Reply-To: <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: SIPCORE WG , "Olle E. Johansson" , Cullen Jennings Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 21:46:46 -0000 I was losing track of this discussion so I had to go back. The only document we seem to have on the table at the moment is: http://www.ietf.org/id/draft-johansson-sip-dual-stack-01.txt This currently contains no normative provisions (no MUST, SHOULD, MAY) so i= t is a bit difficult to judge what the scope of a normative document should= be. Could I suggest that before we scope the work and as a consequence write th= e milestone, we see another version of the author draft containing at least= the minimum set of normative requirements the authors think we need. That may be because it is written in the style of RFC 3263 which also conta= ins no normative provisions. It might be that in order to scope this work w= e actually need a bis version of RFC 3263, rather than something that adds = some more requirements in this area. In response to Cullen, I would say there is another reason why something sh= ould be an update rather than just being regarded as an extension. If it co= ntains provisions that all RFC 3263 implementations (or most of) should als= o implement, and it is within the scope of the original RFC, then I believe= that may also justify and update. But I agree that we need to write the re= quirements first and then do this analysis. I'd also remind you that Vijay has some comments that the issue was wider t= han RFC 3263, so there may be a need to scope round that. None of these comments should be taken as a suggestion that we should not d= o the work (I think the issue has been justified), only that I do not under= stand the scope and there is not enough on the table to judge that. Keith =20 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > Gonzalo Salgueiro (gsalguei) > Sent: 12 December 2013 19:19 > To: Paul Kyzivat > Cc: SIPCORE WG; Olle E. Johansson; Gonzalo Salgueiro=20 > (gsalguei); Cullen Jennings > Subject: Re: [sipcore] IPv6 in the sip core wg > Importance: High >=20 >=20 > On Dec 12, 2013, at 12:59 PM, Paul Kyzivat=20 > wrote: >=20 > > On 12/12/13 11:59 AM, Mary Barnes wrote: > >> The question in my mind becomes how you can word it=20 > properly. There=20 > >> are already procedures for dual stack, so you can't just say: > >>=20 > >> Procedures for dual-stack server handling of SIP URIs containing=20 > >> domain names > >>=20 > >> Any of the adjectives proposed so far "Amended" or "Updated" or=20 > >> others that might seem appropriate, e.g., "Enhanced" imply=20 > that the=20 > >> existing procedures are being changed or corrected. =20 > Although maybe "Enhanced" is > >> general enough to not necessarily imply an "Update" to RFC=20 > 3263? But, > >> then would you be talking about an Informational versus=20 > standards track > >> document? I think it's usual for milestones to indicate=20 > whether the > >> work is informational, standards track or BCP. But, if=20 > the AD will=20 > >> approve the new milestone without that level of=20 > specificity, that's=20 > >> fine. > >=20 > > ISTM that we are in a situation where we need to consider=20 > the details of the proposed mechanism(s) before deciding if=20 > the desired mechanism will be an update or not. So I think it=20 > makes sense to word the milestone to be non-specific about this. > >=20 > > Maybe its not the term itself that is the problem, but=20 > rather what the term references. IOW, is it that we intend to=20 > ammend/update/enhance/improve the *procedures*, or the=20 > *description* of the procedures? > >=20 > > IIUC the intent is to clarify the description, and if that=20 > is insufficient to get a satisfactory result, then to update=20 > the procedures themselves. >=20 > So what is the proposed text for the milestone? >=20 > Gonzalo >=20 > >=20 > > Thanks, > > Paul > >=20 > >> But, I also don't think it's useful for the group to=20 > rathole on that=20 > >> later in the process and it will definitely cause=20 > confusion if the WG=20 > >> doesn't have a clear reason why the specific type of specification=20 > >> was selected. > >>=20 > >> Regards, > >> Mary. > >>=20 > >>=20 > >>=20 > >> On Wed, Dec 11, 2013 at 2:49 PM, Paul Kyzivat=20 > >> > wrote: > >>=20 > >> Cullen, > >>=20 > >> Would you be satisfied if the milestone is sufficiently=20 > vague that > >> we can leave it to the deliverable to decide whether an=20 > update is > >> needed or not? > >>=20 > >> Thanks, > >> Paul > >>=20 > >>=20 > >> On 12/10/13 6:13 PM, Cullen Jennings wrote: > >>=20 > >>=20 > >> Well from a milestone point of view there is a big=20 > difference > >> between we need the change an existing RFC (i.e.=20 > update) or we > >> need to define a new RFC that tells developers who want to > >> implement the new RFC what they need to do. > >>=20 > >> I think what is needed here is the later item and not the > >> update. I have asked about this a bunch of times and and I > >> always get answers that suggest that a new document=20 > is needed > >> but it does not need to replace or update 3263. It=20 > needs to be a > >> new document that provides more detailed advice. If=20 > we are going > >> to say this updates something, I want to be=20 > convinced first that > >> there is something that is wrong and needs to be=20 > changed. I'm > >> fine with the idea that ore detailed specifications=20 > are needed > >> to do something like happy eyeballs for SIP but I=20 > don't think > >> that requires an update of 3263. > >>=20 > >>=20 > >> On Dec 10, 2013, at 12:21 PM, Olle E. Johansson=20 > >> > wrote: > >>=20 > >>=20 > >> On 10 Dec 2013, at 12:14, Cullen Jennings >> > wrote: > >>=20 > >>=20 > >> On Dec 10, 2013, at 9:59 AM, Paul Kyzivat > >> > > >> wrote: > >>=20 > >> June 2014 Updated procedures for=20 > dual-stack server > >> handling of SIP > >> URIs containing domain names > >>=20 > >>=20 > >> Before we use update, can someone tell me=20 > what normative > >> text of the current RFCs need to be changed? > >>=20 > >>=20 > >> That's part of the problem, RFC 3263 is not=20 > very clear to me > >> in indicating what exactly is normative. If you read our > >> draft, you will see that we point to a few sections that > >> clearly says that a UA needs to look up "A or=20 > AAAA" records, > >> which has been proven wrong and doesn't follow=20 > the intention > >> of the DNS SRV RFC. If this was unintentional=20 > or normative, > >> I don't know, but it's written enough times to=20 > cause issues > >> in implementations and have been copied to=20 > other documents, > >> like the MSRP RFC. > >>=20 > >> We need to clarify that a SIP implementation=20 > needs to follow > >> the DNS SRV RFC and look up all addresses for a=20 > host name > >> (ipv4, IPv6 or future address families) and=20 > test them all > >> before moving to the next priority and host. > >>=20 > >> I've checked this with members of the IETF DNS=20 > directorate > >> two times now, and they agree with this. > >>=20 > >> When we clarified/updated/extended/__informed=20 > the audience - > >> developers - about this, we need to get down to how to > >> connect - serially, in parallell, in reverse=20 > random order > >> controlled by the phases of the moon or other=20 > planets - or > >> simply Happy Eyeballs. But even with TCP, doing happy > >> eyeballs like in HTTP would not work unless we=20 > have both A > >> and AAAA records. RFC 3263 doesn't really indicate that. > >>=20 > >> Someone else needs to help out to clarify to me what is > >> really normative in 3263 and what the=20 > relationship between > >> 3263 and RFC 2782 really is - if RFC 2782 is=20 > the normative > >> one and RFC 3263 just can be seen as a happy story that > >> points to 2782 without making any normative changes, we > >> might have to clarify that in an informational=20 > document and > >> move on to connection setup in a dual stack=20 > world. If RFC > >> 3263 changes the behaviour intended by 2782 and really > >> forces a developer to select A or AAAA records,=20 > then we need > >> to change that behaviour. > >>=20 > >> Either way, we have work to do in ths wg. > >> /O > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From adam@nostrum.com Thu Dec 12 14:24:22 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852A31ADF52 for ; Thu, 12 Dec 2013 14:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzT4IdoENyh7 for ; Thu, 12 Dec 2013 14:24:21 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4881AE1EE for ; Thu, 12 Dec 2013 14:24:21 -0800 (PST) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBCMO33F046652 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 12 Dec 2013 16:24:15 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <52AA377E.4060703@nostrum.com> Date: Thu, 12 Dec 2013 16:23:58 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "'SIPCORE'" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: [sipcore] Call for agenda items X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 22:24:22 -0000 [as chair] I know March seems a pretty long time in the future, but agenda planning for IETF 89 has begun in earnest. If you think you will have reason to lead discussion around a SIPCORE-relevant topic in London, please let the chairs know as soon as practical; but, in any case, no later than Friday, January 10th. Thanks. /a From fluffy@iii.ca Thu Dec 12 16:21:37 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D61D1AE585 for ; Thu, 12 Dec 2013 16:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ha3Dkscfh9Nz for ; Thu, 12 Dec 2013 16:21:35 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 394A41AE56A for ; Thu, 12 Dec 2013 16:21:35 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 80634509B5; Thu, 12 Dec 2013 19:21:27 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Cullen Jennings In-Reply-To: Date: Thu, 12 Dec 2013 17:21:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7886ADB0-BDB3-4D15-800B-AAEB34713547@iii.ca> References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> To: Olle E. Johansson X-Mailer: Apple Mail (2.1510) Cc: SIPCORE WG , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 00:21:38 -0000 On Dec 11, 2013, at 7:50 AM, Olle E. Johansson wrote: >=20 > I am fine with a milestone that doesn't say update. If we discover = later that an update really is required, we can still add a milestone = for that. I just want to get the work started at this point. >=20 >=20 > /O That sounds reasonable way forward but when I read = draft-johansson-sip-dual-stack, I don't think the things it claims are a = change to 3263 actually are a change.=20 I'm fine this a new RFC that tells you how to do the things in the happy = eye balls way, but that does not need to update 3261. Nothing in 3263 = says lookups can't be tried in parallel and the this can just be a new = RFC.=20 From gsalguei@cisco.com Thu Dec 12 16:54:21 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297021AE58C for ; Thu, 12 Dec 2013 16:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVlE-vl2F2Vs for ; Thu, 12 Dec 2013 16:54:18 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5A11AE591 for ; Thu, 12 Dec 2013 16:54:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10484; q=dns/txt; s=iport; t=1386896051; x=1388105651; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=daDgghWLJdjA8dkK3Zjo4/q+3IlU7sszw+XAWzKaJow=; b=FPUA4DFmtJhqHUXpmCqobPLrhm4lhUFelqQY1OV6ubWmw6ywYCeJTHpt GRJFbwuneJ1JDxG7lJqo8E/Hpwt3oFcFEsTQ/s+WBXDRLjhlCyHBjRsb9 BZBth8ZNFs6fkeQgTBBXhdFbl7n2vDxiEZfbZGRGY5sdWtFsd9DxyvUPN 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFADRaqlKtJXHB/2dsb2JhbABZgwo4VbgKToEeFnSCJQEBAQMBAQEBJhE0BAcFBwQCAQIGEQQBAQEeCQcnCxQJCAIEDgUJh3MIDcJ7F45hMwcGgxyBEwSUMoNjkhSDKYIq X-IronPort-AV: E=Sophos;i="4.95,475,1384300800"; d="scan'208";a="6432796" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-2.cisco.com with ESMTP; 13 Dec 2013 00:54:11 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rBD0sAt3001618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 00:54:10 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 18:54:10 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Keith Drage Thread-Topic: [sipcore] IPv6 in the sip core wg Thread-Index: AQHO92PvPaG9LxtinkCT+HMY0fMEHZpRU8qAgAApEICAADScgA== Importance: high X-Priority: 1 Date: Fri, 13 Dec 2013 00:54:10 +0000 Message-ID: References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.210.185] Content-Type: text/plain; charset="us-ascii" Content-ID: <1600B474C2133045BE15A60F5EDED87D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Cullen Jennings , SIPCORE WG , "Olle E. Johansson" , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 00:54:21 -0000 (as co-author) I'm happy to publish a new version of the document that makes use of 2119 l= anguage. =20 I think we might be trying to over-complicate matters. As stated earlier, t= his work is merely an extension to the procedures in 3263 and should not ma= ke the myriad existing deployments non-compliant to a core SIP specificatio= n. The intent here is only to provide supplemental best practices that we h= ave learned along the way through extensive interop testing. To emblazon th= is point into everyone's psyche, the next version will not have the "Update= s: 3263 (if approved)" label. With this in mind, I propose the following as the milestone text: Supplemental procedures for dual-stack server handling of SIP URIs containi= ng domain names To your point regarding Vijay, the authors will stay in sync with him throu= ghout. Cheers, Gonzalo =20 On Dec 12, 2013, at 4:45 PM, DRAGE, Keith (Keith) wrote: > I was losing track of this discussion so I had to go back. >=20 > The only document we seem to have on the table at the moment is: >=20 > http://www.ietf.org/id/draft-johansson-sip-dual-stack-01.txt >=20 > This currently contains no normative provisions (no MUST, SHOULD, MAY) so= it is a bit difficult to judge what the scope of a normative document shou= ld be. >=20 > Could I suggest that before we scope the work and as a consequence write = the milestone, we see another version of the author draft containing at lea= st the minimum set of normative requirements the authors think we need. >=20 > That may be because it is written in the style of RFC 3263 which also con= tains no normative provisions. It might be that in order to scope this work= we actually need a bis version of RFC 3263, rather than something that add= s some more requirements in this area. >=20 > In response to Cullen, I would say there is another reason why something = should be an update rather than just being regarded as an extension. If it = contains provisions that all RFC 3263 implementations (or most of) should a= lso implement, and it is within the scope of the original RFC, then I belie= ve that may also justify and update. But I agree that we need to write the = requirements first and then do this analysis. >=20 > I'd also remind you that Vijay has some comments that the issue was wider= than RFC 3263, so there may be a need to scope round that. >=20 > None of these comments should be taken as a suggestion that we should not= do the work (I think the issue has been justified), only that I do not und= erstand the scope and there is not enough on the table to judge that. >=20 > Keith >=20 >=20 >=20 >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 >> Gonzalo Salgueiro (gsalguei) >> Sent: 12 December 2013 19:19 >> To: Paul Kyzivat >> Cc: SIPCORE WG; Olle E. Johansson; Gonzalo Salgueiro=20 >> (gsalguei); Cullen Jennings >> Subject: Re: [sipcore] IPv6 in the sip core wg >> Importance: High >>=20 >>=20 >> On Dec 12, 2013, at 12:59 PM, Paul Kyzivat=20 >> wrote: >>=20 >>> On 12/12/13 11:59 AM, Mary Barnes wrote: >>>> The question in my mind becomes how you can word it=20 >> properly. There=20 >>>> are already procedures for dual stack, so you can't just say: >>>>=20 >>>> Procedures for dual-stack server handling of SIP URIs containing=20 >>>> domain names >>>>=20 >>>> Any of the adjectives proposed so far "Amended" or "Updated" or=20 >>>> others that might seem appropriate, e.g., "Enhanced" imply=20 >> that the=20 >>>> existing procedures are being changed or corrected. =20 >> Although maybe "Enhanced" is >>>> general enough to not necessarily imply an "Update" to RFC=20 >> 3263? But, >>>> then would you be talking about an Informational versus=20 >> standards track >>>> document? I think it's usual for milestones to indicate=20 >> whether the >>>> work is informational, standards track or BCP. But, if=20 >> the AD will=20 >>>> approve the new milestone without that level of=20 >> specificity, that's=20 >>>> fine. >>>=20 >>> ISTM that we are in a situation where we need to consider=20 >> the details of the proposed mechanism(s) before deciding if=20 >> the desired mechanism will be an update or not. So I think it=20 >> makes sense to word the milestone to be non-specific about this. >>>=20 >>> Maybe its not the term itself that is the problem, but=20 >> rather what the term references. IOW, is it that we intend to=20 >> ammend/update/enhance/improve the *procedures*, or the=20 >> *description* of the procedures? >>>=20 >>> IIUC the intent is to clarify the description, and if that=20 >> is insufficient to get a satisfactory result, then to update=20 >> the procedures themselves. >>=20 >> So what is the proposed text for the milestone? >>=20 >> Gonzalo >>=20 >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> But, I also don't think it's useful for the group to=20 >> rathole on that=20 >>>> later in the process and it will definitely cause=20 >> confusion if the WG=20 >>>> doesn't have a clear reason why the specific type of specification=20 >>>> was selected. >>>>=20 >>>> Regards, >>>> Mary. >>>>=20 >>>>=20 >>>>=20 >>>> On Wed, Dec 11, 2013 at 2:49 PM, Paul Kyzivat=20 >> >>> > wrote: >>>>=20 >>>> Cullen, >>>>=20 >>>> Would you be satisfied if the milestone is sufficiently=20 >> vague that >>>> we can leave it to the deliverable to decide whether an=20 >> update is >>>> needed or not? >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>>=20 >>>> On 12/10/13 6:13 PM, Cullen Jennings wrote: >>>>=20 >>>>=20 >>>> Well from a milestone point of view there is a big=20 >> difference >>>> between we need the change an existing RFC (i.e.=20 >> update) or we >>>> need to define a new RFC that tells developers who want to >>>> implement the new RFC what they need to do. >>>>=20 >>>> I think what is needed here is the later item and not the >>>> update. I have asked about this a bunch of times and and I >>>> always get answers that suggest that a new document=20 >> is needed >>>> but it does not need to replace or update 3263. It=20 >> needs to be a >>>> new document that provides more detailed advice. If=20 >> we are going >>>> to say this updates something, I want to be=20 >> convinced first that >>>> there is something that is wrong and needs to be=20 >> changed. I'm >>>> fine with the idea that ore detailed specifications=20 >> are needed >>>> to do something like happy eyeballs for SIP but I=20 >> don't think >>>> that requires an update of 3263. >>>>=20 >>>>=20 >>>> On Dec 10, 2013, at 12:21 PM, Olle E. Johansson=20 >> >>> > wrote: >>>>=20 >>>>=20 >>>> On 10 Dec 2013, at 12:14, Cullen Jennings >>> > wrote: >>>>=20 >>>>=20 >>>> On Dec 10, 2013, at 9:59 AM, Paul Kyzivat >>>> > > >>>> wrote: >>>>=20 >>>> June 2014 Updated procedures for=20 >> dual-stack server >>>> handling of SIP >>>> URIs containing domain names >>>>=20 >>>>=20 >>>> Before we use update, can someone tell me=20 >> what normative >>>> text of the current RFCs need to be changed? >>>>=20 >>>>=20 >>>> That's part of the problem, RFC 3263 is not=20 >> very clear to me >>>> in indicating what exactly is normative. If you read our >>>> draft, you will see that we point to a few sections that >>>> clearly says that a UA needs to look up "A or=20 >> AAAA" records, >>>> which has been proven wrong and doesn't follow=20 >> the intention >>>> of the DNS SRV RFC. If this was unintentional=20 >> or normative, >>>> I don't know, but it's written enough times to=20 >> cause issues >>>> in implementations and have been copied to=20 >> other documents, >>>> like the MSRP RFC. >>>>=20 >>>> We need to clarify that a SIP implementation=20 >> needs to follow >>>> the DNS SRV RFC and look up all addresses for a=20 >> host name >>>> (ipv4, IPv6 or future address families) and=20 >> test them all >>>> before moving to the next priority and host. >>>>=20 >>>> I've checked this with members of the IETF DNS=20 >> directorate >>>> two times now, and they agree with this. >>>>=20 >>>> When we clarified/updated/extended/__informed=20 >> the audience - >>>> developers - about this, we need to get down to how to >>>> connect - serially, in parallell, in reverse=20 >> random order >>>> controlled by the phases of the moon or other=20 >> planets - or >>>> simply Happy Eyeballs. But even with TCP, doing happy >>>> eyeballs like in HTTP would not work unless we=20 >> have both A >>>> and AAAA records. RFC 3263 doesn't really indicate that. >>>>=20 >>>> Someone else needs to help out to clarify to me what is >>>> really normative in 3263 and what the=20 >> relationship between >>>> 3263 and RFC 2782 really is - if RFC 2782 is=20 >> the normative >>>> one and RFC 3263 just can be seen as a happy story that >>>> points to 2782 without making any normative changes, we >>>> might have to clarify that in an informational=20 >> document and >>>> move on to connection setup in a dual stack=20 >> world. If RFC >>>> 3263 changes the behaviour intended by 2782 and really >>>> forces a developer to select A or AAAA records,=20 >> then we need >>>> to change that behaviour. >>>>=20 >>>> Either way, we have work to do in ths wg. >>>> /O >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore From keith.drage@alcatel-lucent.com Thu Dec 12 17:04:46 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5AE1AE5A6 for ; Thu, 12 Dec 2013 17:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Mx6HrOmdZbA for ; Thu, 12 Dec 2013 17:04:40 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3191AE105 for ; Thu, 12 Dec 2013 17:04:40 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rBD14Q6o002911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Dec 2013 19:04:28 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rBD14PWY013775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 02:04:25 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 13 Dec 2013 02:04:25 +0100 From: "DRAGE, Keith (Keith)" To: "Gonzalo Salgueiro (gsalguei)" Thread-Topic: [sipcore] IPv6 in the sip core wg Thread-Index: AQHO9f1rFmxMwFa6OUik7RkhLMXct5pQy0fD////2gCAABYeAIAAHQCAgABArQCAABNvwA== Date: Fri, 13 Dec 2013 01:04:24 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: SIPCORE WG , "Olle E. Johansson" , Cullen Jennings Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 01:04:46 -0000 Lets look at the specification. Your mail seems to being its best to justify it as a BCP, which I assume is= not what you intend. Keith=20 > -----Original Message----- > From: Gonzalo Salgueiro (gsalguei) [mailto:gsalguei@cisco.com]=20 > Sent: 13 December 2013 00:54 > To: DRAGE, Keith (Keith) > Cc: Paul Kyzivat; Gonzalo Salgueiro (gsalguei); SIPCORE WG;=20 > Olle E. Johansson; Cullen Jennings > Subject: Re: [sipcore] IPv6 in the sip core wg > Importance: High >=20 > (as co-author) >=20 > I'm happy to publish a new version of the document that makes=20 > use of 2119 language. =20 >=20 > I think we might be trying to over-complicate matters. As=20 > stated earlier, this work is merely an extension to the=20 > procedures in 3263 and should not make the myriad existing=20 > deployments non-compliant to a core SIP specification. The=20 > intent here is only to provide supplemental best practices=20 > that we have learned along the way through extensive interop=20 > testing. To emblazon this point into everyone's psyche, the=20 > next version will not have the "Updates: 3263 (if approved)" label. >=20 > With this in mind, I propose the following as the milestone text: >=20 > Supplemental procedures for dual-stack server handling of SIP=20 > URIs containing domain names >=20 >=20 > To your point regarding Vijay, the authors will stay in sync=20 > with him throughout. >=20 >=20 > Cheers, >=20 > Gonzalo >=20 > =20 >=20 > On Dec 12, 2013, at 4:45 PM, DRAGE, Keith (Keith)=20 > wrote: >=20 > > I was losing track of this discussion so I had to go back. > >=20 > > The only document we seem to have on the table at the moment is: > >=20 > > http://www.ietf.org/id/draft-johansson-sip-dual-stack-01.txt > >=20 > > This currently contains no normative provisions (no MUST,=20 > SHOULD, MAY) so it is a bit difficult to judge what the scope=20 > of a normative document should be. > >=20 > > Could I suggest that before we scope the work and as a=20 > consequence write the milestone, we see another version of=20 > the author draft containing at least the minimum set of=20 > normative requirements the authors think we need. > >=20 > > That may be because it is written in the style of RFC 3263=20 > which also contains no normative provisions. It might be that=20 > in order to scope this work we actually need a bis version of=20 > RFC 3263, rather than something that adds some more=20 > requirements in this area. > >=20 > > In response to Cullen, I would say there is another reason=20 > why something should be an update rather than just being=20 > regarded as an extension. If it contains provisions that all=20 > RFC 3263 implementations (or most of) should also implement,=20 > and it is within the scope of the original RFC, then I=20 > believe that may also justify and update. But I agree that we=20 > need to write the requirements first and then do this analysis. > >=20 > > I'd also remind you that Vijay has some comments that the=20 > issue was wider than RFC 3263, so there may be a need to=20 > scope round that. > >=20 > > None of these comments should be taken as a suggestion that=20 > we should not do the work (I think the issue has been=20 > justified), only that I do not understand the scope and there=20 > is not enough on the table to judge that. > >=20 > > Keith > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf=20 > Of Gonzalo=20 > >> Salgueiro (gsalguei) > >> Sent: 12 December 2013 19:19 > >> To: Paul Kyzivat > >> Cc: SIPCORE WG; Olle E. Johansson; Gonzalo Salgueiro (gsalguei);=20 > >> Cullen Jennings > >> Subject: Re: [sipcore] IPv6 in the sip core wg > >> Importance: High > >>=20 > >>=20 > >> On Dec 12, 2013, at 12:59 PM, Paul Kyzivat =20 > >> wrote: > >>=20 > >>> On 12/12/13 11:59 AM, Mary Barnes wrote: > >>>> The question in my mind becomes how you can word it > >> properly. There > >>>> are already procedures for dual stack, so you can't just say: > >>>>=20 > >>>> Procedures for dual-stack server handling of SIP URIs containing=20 > >>>> domain names > >>>>=20 > >>>> Any of the adjectives proposed so far "Amended" or "Updated" or=20 > >>>> others that might seem appropriate, e.g., "Enhanced" imply > >> that the > >>>> existing procedures are being changed or corrected. =20 > >> Although maybe "Enhanced" is > >>>> general enough to not necessarily imply an "Update" to RFC > >> 3263? But, > >>>> then would you be talking about an Informational versus > >> standards track > >>>> document? I think it's usual for milestones to indicate=20 > >> whether the > >>>> work is informational, standards track or BCP. But, if > >> the AD will > >>>> approve the new milestone without that level of > >> specificity, that's > >>>> fine. > >>>=20 > >>> ISTM that we are in a situation where we need to consider > >> the details of the proposed mechanism(s) before deciding if the=20 > >> desired mechanism will be an update or not. So I think it=20 > makes sense=20 > >> to word the milestone to be non-specific about this. > >>>=20 > >>> Maybe its not the term itself that is the problem, but > >> rather what the term references. IOW, is it that we intend to=20 > >> ammend/update/enhance/improve the *procedures*, or the > >> *description* of the procedures? > >>>=20 > >>> IIUC the intent is to clarify the description, and if that > >> is insufficient to get a satisfactory result, then to update the=20 > >> procedures themselves. > >>=20 > >> So what is the proposed text for the milestone? > >>=20 > >> Gonzalo > >>=20 > >>>=20 > >>> Thanks, > >>> Paul > >>>=20 > >>>> But, I also don't think it's useful for the group to > >> rathole on that > >>>> later in the process and it will definitely cause > >> confusion if the WG > >>>> doesn't have a clear reason why the specific type of=20 > specification=20 > >>>> was selected. > >>>>=20 > >>>> Regards, > >>>> Mary. > >>>>=20 > >>>>=20 > >>>>=20 > >>>> On Wed, Dec 11, 2013 at 2:49 PM, Paul Kyzivat > >> >>>> > wrote: > >>>>=20 > >>>> Cullen, > >>>>=20 > >>>> Would you be satisfied if the milestone is sufficiently > >> vague that > >>>> we can leave it to the deliverable to decide whether an > >> update is > >>>> needed or not? > >>>>=20 > >>>> Thanks, > >>>> Paul > >>>>=20 > >>>>=20 > >>>> On 12/10/13 6:13 PM, Cullen Jennings wrote: > >>>>=20 > >>>>=20 > >>>> Well from a milestone point of view there is a big > >> difference > >>>> between we need the change an existing RFC (i.e.=20 > >> update) or we > >>>> need to define a new RFC that tells developers who want to > >>>> implement the new RFC what they need to do. > >>>>=20 > >>>> I think what is needed here is the later item and not the > >>>> update. I have asked about this a bunch of times and and I > >>>> always get answers that suggest that a new document > >> is needed > >>>> but it does not need to replace or update 3263. It > >> needs to be a > >>>> new document that provides more detailed advice. If > >> we are going > >>>> to say this updates something, I want to be > >> convinced first that > >>>> there is something that is wrong and needs to be > >> changed. I'm > >>>> fine with the idea that ore detailed specifications > >> are needed > >>>> to do something like happy eyeballs for SIP but I > >> don't think > >>>> that requires an update of 3263. > >>>>=20 > >>>>=20 > >>>> On Dec 10, 2013, at 12:21 PM, Olle E. Johansson > >> >>>> > wrote: > >>>>=20 > >>>>=20 > >>>> On 10 Dec 2013, at 12:14, Cullen Jennings=20 > >>>> > wrote: > >>>>=20 > >>>>=20 > >>>> On Dec 10, 2013, at 9:59 AM, Paul Kyzivat > >>>> >> > > >>>> wrote: > >>>>=20 > >>>> June 2014 Updated procedures for > >> dual-stack server > >>>> handling of SIP > >>>> URIs containing domain names > >>>>=20 > >>>>=20 > >>>> Before we use update, can someone tell me > >> what normative > >>>> text of the current RFCs need to be changed? > >>>>=20 > >>>>=20 > >>>> That's part of the problem, RFC 3263 is not > >> very clear to me > >>>> in indicating what exactly is normative. If=20 > you read our > >>>> draft, you will see that we point to a few=20 > sections that > >>>> clearly says that a UA needs to look up "A or > >> AAAA" records, > >>>> which has been proven wrong and doesn't follow > >> the intention > >>>> of the DNS SRV RFC. If this was unintentional > >> or normative, > >>>> I don't know, but it's written enough times to > >> cause issues > >>>> in implementations and have been copied to > >> other documents, > >>>> like the MSRP RFC. > >>>>=20 > >>>> We need to clarify that a SIP implementation > >> needs to follow > >>>> the DNS SRV RFC and look up all addresses for a > >> host name > >>>> (ipv4, IPv6 or future address families) and > >> test them all > >>>> before moving to the next priority and host. > >>>>=20 > >>>> I've checked this with members of the IETF DNS > >> directorate > >>>> two times now, and they agree with this. > >>>>=20 > >>>> When we clarified/updated/extended/__informed > >> the audience - > >>>> developers - about this, we need to get down to how to > >>>> connect - serially, in parallell, in reverse > >> random order > >>>> controlled by the phases of the moon or other > >> planets - or > >>>> simply Happy Eyeballs. But even with TCP, doing happy > >>>> eyeballs like in HTTP would not work unless we > >> have both A > >>>> and AAAA records. RFC 3263 doesn't really=20 > indicate that. > >>>>=20 > >>>> Someone else needs to help out to clarify to me what is > >>>> really normative in 3263 and what the > >> relationship between > >>>> 3263 and RFC 2782 really is - if RFC 2782 is > >> the normative > >>>> one and RFC 3263 just can be seen as a happy story that > >>>> points to 2782 without making any normative changes, we > >>>> might have to clarify that in an informational > >> document and > >>>> move on to connection setup in a dual stack > >> world. If RFC > >>>> 3263 changes the behaviour intended by 2782 and really > >>>> forces a developer to select A or AAAA records, > >> then we need > >>>> to change that behaviour. > >>>>=20 > >>>> Either way, we have work to do in ths wg. > >>>> /O > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>=20 > >>=20 > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > = From gsalguei@cisco.com Thu Dec 12 17:08:09 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5401AE5A7 for ; Thu, 12 Dec 2013 17:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFewhI21JeVE for ; Thu, 12 Dec 2013 17:08:06 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id CA11D1AE193 for ; Thu, 12 Dec 2013 17:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11845; q=dns/txt; s=iport; t=1386896880; x=1388106480; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=b+M6oOWh++QemvfpbBUgHMH1y8i2g0n1m+WS7pxsGDo=; b=YESFq+Xj4UYot4GO7RCFoGd7hx9ASfN52uQzyB/oIKQg32xMXETCd6jz jGMOzzyxYOGfIN+fiViB8HLlGg39qgdYvYlWUA1HmBX3ywZOCQ3wVXfom 57aE+1OAP4P8rYHgn3AZOtNfNtNixCa4FwszYg/qxy0/QgX8Ei9vlGcIu o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAKRdqlKtJV2d/2dsb2JhbABZgwo4VbgKToEeFnSCJQEBAQMBAQEBJhE0BAcFBwQCAQIGEQQBAQEeCQcnCxQJCAIEDgUJh3MIDcJsF45DAQEcMwcGgxyBEwSUMoNjkhSDKYFxOQ X-IronPort-AV: E=Sophos;i="4.95,475,1384300800"; d="scan'208";a="6432141" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 13 Dec 2013 01:07:46 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rBD17kus028197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 01:07:46 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 19:07:45 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Keith Drage Thread-Topic: [sipcore] IPv6 in the sip core wg Thread-Index: AQHO92PvPaG9LxtinkCT+HMY0fMEHZpRU8qAgAApEICAADScgIAAAt0AgAAA7wA= Importance: high X-Priority: 1 Date: Fri, 13 Dec 2013 01:07:45 +0000 Message-ID: References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.210.185] Content-Type: text/plain; charset="us-ascii" Content-ID: <61DBC75A7A526D4C8F4C039D23208A23@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Cullen Jennings , SIPCORE WG , "Olle E. Johansson" , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 01:08:09 -0000 On Dec 12, 2013, at 8:04 PM, DRAGE, Keith (Keith) wrote: > Lets look at the specification. >=20 > Your mail seems to being its best to justify it as a BCP, which I assume = is not what you intend. You're right, t is not at all my intent. What I intend is to provide a sta= nd-alone RFC that provides some useful supplemental procedures for improved= performance in SIP dual-stack environments. Gonzalo >=20 > Keith=20 >=20 >> -----Original Message----- >> From: Gonzalo Salgueiro (gsalguei) [mailto:gsalguei@cisco.com]=20 >> Sent: 13 December 2013 00:54 >> To: DRAGE, Keith (Keith) >> Cc: Paul Kyzivat; Gonzalo Salgueiro (gsalguei); SIPCORE WG;=20 >> Olle E. Johansson; Cullen Jennings >> Subject: Re: [sipcore] IPv6 in the sip core wg >> Importance: High >>=20 >> (as co-author) >>=20 >> I'm happy to publish a new version of the document that makes=20 >> use of 2119 language. =20 >>=20 >> I think we might be trying to over-complicate matters. As=20 >> stated earlier, this work is merely an extension to the=20 >> procedures in 3263 and should not make the myriad existing=20 >> deployments non-compliant to a core SIP specification. The=20 >> intent here is only to provide supplemental best practices=20 >> that we have learned along the way through extensive interop=20 >> testing. To emblazon this point into everyone's psyche, the=20 >> next version will not have the "Updates: 3263 (if approved)" label. >>=20 >> With this in mind, I propose the following as the milestone text: >>=20 >> Supplemental procedures for dual-stack server handling of SIP=20 >> URIs containing domain names >>=20 >>=20 >> To your point regarding Vijay, the authors will stay in sync=20 >> with him throughout. >>=20 >>=20 >> Cheers, >>=20 >> Gonzalo >>=20 >>=20 >>=20 >> On Dec 12, 2013, at 4:45 PM, DRAGE, Keith (Keith)=20 >> wrote: >>=20 >>> I was losing track of this discussion so I had to go back. >>>=20 >>> The only document we seem to have on the table at the moment is: >>>=20 >>> http://www.ietf.org/id/draft-johansson-sip-dual-stack-01.txt >>>=20 >>> This currently contains no normative provisions (no MUST,=20 >> SHOULD, MAY) so it is a bit difficult to judge what the scope=20 >> of a normative document should be. >>>=20 >>> Could I suggest that before we scope the work and as a=20 >> consequence write the milestone, we see another version of=20 >> the author draft containing at least the minimum set of=20 >> normative requirements the authors think we need. >>>=20 >>> That may be because it is written in the style of RFC 3263=20 >> which also contains no normative provisions. It might be that=20 >> in order to scope this work we actually need a bis version of=20 >> RFC 3263, rather than something that adds some more=20 >> requirements in this area. >>>=20 >>> In response to Cullen, I would say there is another reason=20 >> why something should be an update rather than just being=20 >> regarded as an extension. If it contains provisions that all=20 >> RFC 3263 implementations (or most of) should also implement,=20 >> and it is within the scope of the original RFC, then I=20 >> believe that may also justify and update. But I agree that we=20 >> need to write the requirements first and then do this analysis. >>>=20 >>> I'd also remind you that Vijay has some comments that the=20 >> issue was wider than RFC 3263, so there may be a need to=20 >> scope round that. >>>=20 >>> None of these comments should be taken as a suggestion that=20 >> we should not do the work (I think the issue has been=20 >> justified), only that I do not understand the scope and there=20 >> is not enough on the table to judge that. >>>=20 >>> Keith >>>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf=20 >> Of Gonzalo=20 >>>> Salgueiro (gsalguei) >>>> Sent: 12 December 2013 19:19 >>>> To: Paul Kyzivat >>>> Cc: SIPCORE WG; Olle E. Johansson; Gonzalo Salgueiro (gsalguei);=20 >>>> Cullen Jennings >>>> Subject: Re: [sipcore] IPv6 in the sip core wg >>>> Importance: High >>>>=20 >>>>=20 >>>> On Dec 12, 2013, at 12:59 PM, Paul Kyzivat =20 >>>> wrote: >>>>=20 >>>>> On 12/12/13 11:59 AM, Mary Barnes wrote: >>>>>> The question in my mind becomes how you can word it >>>> properly. There >>>>>> are already procedures for dual stack, so you can't just say: >>>>>>=20 >>>>>> Procedures for dual-stack server handling of SIP URIs containing=20 >>>>>> domain names >>>>>>=20 >>>>>> Any of the adjectives proposed so far "Amended" or "Updated" or=20 >>>>>> others that might seem appropriate, e.g., "Enhanced" imply >>>> that the >>>>>> existing procedures are being changed or corrected. =20 >>>> Although maybe "Enhanced" is >>>>>> general enough to not necessarily imply an "Update" to RFC >>>> 3263? But, >>>>>> then would you be talking about an Informational versus >>>> standards track >>>>>> document? I think it's usual for milestones to indicate=20 >>>> whether the >>>>>> work is informational, standards track or BCP. But, if >>>> the AD will >>>>>> approve the new milestone without that level of >>>> specificity, that's >>>>>> fine. >>>>>=20 >>>>> ISTM that we are in a situation where we need to consider >>>> the details of the proposed mechanism(s) before deciding if the=20 >>>> desired mechanism will be an update or not. So I think it=20 >> makes sense=20 >>>> to word the milestone to be non-specific about this. >>>>>=20 >>>>> Maybe its not the term itself that is the problem, but >>>> rather what the term references. IOW, is it that we intend to=20 >>>> ammend/update/enhance/improve the *procedures*, or the >>>> *description* of the procedures? >>>>>=20 >>>>> IIUC the intent is to clarify the description, and if that >>>> is insufficient to get a satisfactory result, then to update the=20 >>>> procedures themselves. >>>>=20 >>>> So what is the proposed text for the milestone? >>>>=20 >>>> Gonzalo >>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Paul >>>>>=20 >>>>>> But, I also don't think it's useful for the group to >>>> rathole on that >>>>>> later in the process and it will definitely cause >>>> confusion if the WG >>>>>> doesn't have a clear reason why the specific type of=20 >> specification=20 >>>>>> was selected. >>>>>>=20 >>>>>> Regards, >>>>>> Mary. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Wed, Dec 11, 2013 at 2:49 PM, Paul Kyzivat >>>> >>>>> > wrote: >>>>>>=20 >>>>>> Cullen, >>>>>>=20 >>>>>> Would you be satisfied if the milestone is sufficiently >>>> vague that >>>>>> we can leave it to the deliverable to decide whether an >>>> update is >>>>>> needed or not? >>>>>>=20 >>>>>> Thanks, >>>>>> Paul >>>>>>=20 >>>>>>=20 >>>>>> On 12/10/13 6:13 PM, Cullen Jennings wrote: >>>>>>=20 >>>>>>=20 >>>>>> Well from a milestone point of view there is a big >>>> difference >>>>>> between we need the change an existing RFC (i.e.=20 >>>> update) or we >>>>>> need to define a new RFC that tells developers who want to >>>>>> implement the new RFC what they need to do. >>>>>>=20 >>>>>> I think what is needed here is the later item and not the >>>>>> update. I have asked about this a bunch of times and and I >>>>>> always get answers that suggest that a new document >>>> is needed >>>>>> but it does not need to replace or update 3263. It >>>> needs to be a >>>>>> new document that provides more detailed advice. If >>>> we are going >>>>>> to say this updates something, I want to be >>>> convinced first that >>>>>> there is something that is wrong and needs to be >>>> changed. I'm >>>>>> fine with the idea that ore detailed specifications >>>> are needed >>>>>> to do something like happy eyeballs for SIP but I >>>> don't think >>>>>> that requires an update of 3263. >>>>>>=20 >>>>>>=20 >>>>>> On Dec 10, 2013, at 12:21 PM, Olle E. Johansson >>>> >>>>> > wrote: >>>>>>=20 >>>>>>=20 >>>>>> On 10 Dec 2013, at 12:14, Cullen Jennings=20 >> >>>>> > wrote: >>>>>>=20 >>>>>>=20 >>>>>> On Dec 10, 2013, at 9:59 AM, Paul Kyzivat >>>>>> >>> > >>>>>> wrote: >>>>>>=20 >>>>>> June 2014 Updated procedures for >>>> dual-stack server >>>>>> handling of SIP >>>>>> URIs containing domain names >>>>>>=20 >>>>>>=20 >>>>>> Before we use update, can someone tell me >>>> what normative >>>>>> text of the current RFCs need to be changed? >>>>>>=20 >>>>>>=20 >>>>>> That's part of the problem, RFC 3263 is not >>>> very clear to me >>>>>> in indicating what exactly is normative. If=20 >> you read our >>>>>> draft, you will see that we point to a few=20 >> sections that >>>>>> clearly says that a UA needs to look up "A or >>>> AAAA" records, >>>>>> which has been proven wrong and doesn't follow >>>> the intention >>>>>> of the DNS SRV RFC. If this was unintentional >>>> or normative, >>>>>> I don't know, but it's written enough times to >>>> cause issues >>>>>> in implementations and have been copied to >>>> other documents, >>>>>> like the MSRP RFC. >>>>>>=20 >>>>>> We need to clarify that a SIP implementation >>>> needs to follow >>>>>> the DNS SRV RFC and look up all addresses for a >>>> host name >>>>>> (ipv4, IPv6 or future address families) and >>>> test them all >>>>>> before moving to the next priority and host. >>>>>>=20 >>>>>> I've checked this with members of the IETF DNS >>>> directorate >>>>>> two times now, and they agree with this. >>>>>>=20 >>>>>> When we clarified/updated/extended/__informed >>>> the audience - >>>>>> developers - about this, we need to get down to how to >>>>>> connect - serially, in parallell, in reverse >>>> random order >>>>>> controlled by the phases of the moon or other >>>> planets - or >>>>>> simply Happy Eyeballs. But even with TCP, doing happy >>>>>> eyeballs like in HTTP would not work unless we >>>> have both A >>>>>> and AAAA records. RFC 3263 doesn't really=20 >> indicate that. >>>>>>=20 >>>>>> Someone else needs to help out to clarify to me what is >>>>>> really normative in 3263 and what the >>>> relationship between >>>>>> 3263 and RFC 2782 really is - if RFC 2782 is >>>> the normative >>>>>> one and RFC 3263 just can be seen as a happy story that >>>>>> points to 2782 without making any normative changes, we >>>>>> might have to clarify that in an informational >>>> document and >>>>>> move on to connection setup in a dual stack >>>> world. If RFC >>>>>> 3263 changes the behaviour intended by 2782 and really >>>>>> forces a developer to select A or AAAA records, >>>> then we need >>>>>> to change that behaviour. >>>>>>=20 >>>>>> Either way, we have work to do in ths wg. >>>>>> /O >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 From oej@edvina.net Fri Dec 13 08:17:13 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF561AE31F for ; Fri, 13 Dec 2013 08:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhcwnS7Eq67G for ; Fri, 13 Dec 2013 08:17:11 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 529A21ADFCB for ; Fri, 13 Dec 2013 08:17:10 -0800 (PST) Received: from [192.168.101.75] (unknown [72.46.244.148]) by smtp7.webway.se (Postfix) with ESMTPA id 65C7C93C2A2; Fri, 13 Dec 2013 16:17:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: "Olle E. Johansson" In-Reply-To: <7886ADB0-BDB3-4D15-800B-AAEB34713547@iii.ca> Date: Fri, 13 Dec 2013 11:17:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <7886ADB0-BDB3-4D15-800B-AAEB34713547@iii.ca> To: Cullen Jennings X-Mailer: Apple Mail (2.1822) Cc: SIPCORE WG , Olle E Johansson , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 16:17:13 -0000 On 12 Dec 2013, at 19:21, Cullen Jennings wrote: >=20 > On Dec 11, 2013, at 7:50 AM, Olle E. Johansson wrote: >=20 >>=20 >> I am fine with a milestone that doesn't say update. If we discover = later that an update really is required, we can still add a milestone = for that. I just want to get the work started at this point. >>=20 >>=20 >> /O >=20 > That sounds reasonable way forward but when I read = draft-johansson-sip-dual-stack, I don't think the things it claims are a = change to 3263 actually are a change.=20 >=20 > I'm fine this a new RFC that tells you how to do the things in the = happy eye balls way, but that does not need to update 3261. Nothing in = 3263 says lookups can't be tried in parallel and the this can just be a = new RFC.=20 >=20 The problem is really that RFC 3263 repeats "A or AAAA" - which means = that if we follow RFC 3263 verbatim we won't have both IPv4 and IPv6 = addresses to connect to. I have not claimed that it talks about how we = connect. It seems like no one can say whether this text is normative or not, = which really means we have to clarify this, since developers will be (or = already am) confused on how to implement properly. /O= From vkg@bell-labs.com Fri Dec 13 08:26:27 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46831AE31D for ; Fri, 13 Dec 2013 08:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLnNRFu34WvG for ; Fri, 13 Dec 2013 08:26:25 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBD31AE22D for ; Fri, 13 Dec 2013 08:26:25 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rBDGQI2t019373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 13 Dec 2013 10:26:18 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id rBDGQHRq012613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 13 Dec 2013 10:26:18 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id rBDGQHiI014821 for ; Fri, 13 Dec 2013 10:26:17 -0600 (CST) Message-ID: <52AB353A.9030600@bell-labs.com> Date: Fri, 13 Dec 2013 10:26:34 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <7886ADB0-BDB3-4D15-800B-AAEB34713547@iii.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 16:26:27 -0000 On 12/13/2013 10:17 AM, Olle E. Johansson wrote: > The problem is really that RFC 3263 repeats "A or AAAA" - which means > that if we follow RFC 3263 verbatim we won't have both IPv4 and IPv6 > addresses to connect to. I have not claimed that it talks about how > we connect. I am sorry to keep interjecting rfc6157 here, but it does say to perform name lookup using getaddrinfo(), which, if rfc3484 is adhered to will produce an ordered list of IPv6/IPv4 destination addresses. > It seems like no one can say whether this text is normative or not, > which really means we have to clarify this, since developers will be > (or already am) confused on how to implement properly. Sure, rfc6157 does not update rfc3263 so this point may be lost in the noise. To be sure, I am not against adding a milestone to better specify this behaviour; all I am pointing out is that more than rfc3263 may be impacted. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From pkyzivat@alum.mit.edu Fri Dec 13 08:28:32 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89EA41AE323 for ; Fri, 13 Dec 2013 08:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS2yJ1qx1YvK for ; Fri, 13 Dec 2013 08:28:30 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id C0F241AE325 for ; Fri, 13 Dec 2013 08:28:29 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 11Xp1n0010mv7h05B4UPJH; Fri, 13 Dec 2013 16:28:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id 14UN1n00L3ZTu2S3X4UN74; Fri, 13 Dec 2013 16:28:23 +0000 Message-ID: <52AB35A6.8030701@alum.mit.edu> Date: Fri, 13 Dec 2013 11:28:22 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Gonzalo Salgueiro (gsalguei)" , Keith Drage References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386952103; bh=BhtyUEJc0zFB63sIuPft7OKbkd8i69kdfTwZBrIe/QQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jRpJxlZZcevfFSbaX3BN4QgJNKBahy8NTvtniEe4f9oxRKF4AfWD1Z/e1mz6dilx6 yg1hwdHt/9eOhDfitqZCYQ6ybAQuS8ZAsvjemQO5zbN5nEdCee9xdmGLmE+H0uYUHO QXwNwl1S3aCsFxKLBN9BO0qobYahFMT6FhiRg47sYrlLCZNjE5rjvByng+hz6iEiMB 4k+dYxcLylMb7Ve0oNbHzEnyj3Be5Rc43xtkSrbtvSPjlmMlxB1eb7oTPEgJH75ZE1 vhUlw1rpX+rPkT3/XTMJFUPO8kSB7aYl9N0Jql1By0j4u1ZIkTGEgHci1yA+X4RdZL SZhMfNTz3RbmA== Cc: SIPCORE WG , "Olle E. Johansson" , Cullen Jennings Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 16:28:32 -0000 On 12/12/13 8:07 PM, Gonzalo Salgueiro (gsalguei) wrote: > > On Dec 12, 2013, at 8:04 PM, DRAGE, Keith (Keith) wrote: > >> Lets look at the specification. >> >> Your mail seems to being its best to justify it as a BCP, which I assume is not what you intend. > > You're right, t is not at all my intent. What I intend is to provide a stand-alone RFC that provides some useful supplemental procedures for improved performance in SIP dual-stack environments. If these procedures are supplemental, will there be anything that should be normative? Contrary to what Keith said, I do find normative language in the draft now. (A SHOULD in the last paragraph of 3.1.) And this is a change to language in 3263 - changing "A or AAAA" to "A and AAAA". It is arguable whether this has normative impact on existing implementations of 3263. 3263 has no normative language regarding "A or AAAA", but it does have normative language ("SHOULD") about how to use the results of the lookup. I think it can be viewed as a normative change to 3263 for dual stack devices. And 3263 suffers from the common problem of using "SHOULD" widely without any explanation of when it makes sense to violate the "SHOULD". This gives people the opportunity to say that implementations that do otherwise are still compliant. I would be uncomfortable publishing a new normative RFC that doesn't say it updates 3263 while mandating behavior that is different from the SHOULDs of 3263. Having said that, I suggest the following as the milestone: May 2014 WGLC of procedures to supplement RFC3263 for dual-stack client and server handling of SIP URIs containing domain names (PS) This assumes that the work will be standards track, but doesn't say whether or not it will update 3263. I've made the milestone to be for WGLC, so we take the time for IESG processing out of the schedule. The date is after the London meeting but before the Toronto meeting. It is assuming that we will get much of the work done on the mailing list before London, thrash out any controversial issues in London, then do cleanup and WGLC. It is optimistic, but possible if there isn't a lot if dissent. Richard - does this work for you? Olle & Gonzalo - does it work for you? Thanks, Paul > Gonzalo > > >> >> Keith >> >>> -----Original Message----- >>> From: Gonzalo Salgueiro (gsalguei) [mailto:gsalguei@cisco.com] >>> Sent: 13 December 2013 00:54 >>> To: DRAGE, Keith (Keith) >>> Cc: Paul Kyzivat; Gonzalo Salgueiro (gsalguei); SIPCORE WG; >>> Olle E. Johansson; Cullen Jennings >>> Subject: Re: [sipcore] IPv6 in the sip core wg >>> Importance: High >>> >>> (as co-author) >>> >>> I'm happy to publish a new version of the document that makes >>> use of 2119 language. >>> >>> I think we might be trying to over-complicate matters. As >>> stated earlier, this work is merely an extension to the >>> procedures in 3263 and should not make the myriad existing >>> deployments non-compliant to a core SIP specification. The >>> intent here is only to provide supplemental best practices >>> that we have learned along the way through extensive interop >>> testing. To emblazon this point into everyone's psyche, the >>> next version will not have the "Updates: 3263 (if approved)" label. >>> >>> With this in mind, I propose the following as the milestone text: >>> >>> Supplemental procedures for dual-stack server handling of SIP >>> URIs containing domain names >>> >>> >>> To your point regarding Vijay, the authors will stay in sync >>> with him throughout. >>> >>> >>> Cheers, >>> >>> Gonzalo >>> >>> >>> >>> On Dec 12, 2013, at 4:45 PM, DRAGE, Keith (Keith) >>> wrote: >>> >>>> I was losing track of this discussion so I had to go back. >>>> >>>> The only document we seem to have on the table at the moment is: >>>> >>>> http://www.ietf.org/id/draft-johansson-sip-dual-stack-01.txt >>>> >>>> This currently contains no normative provisions (no MUST, >>> SHOULD, MAY) so it is a bit difficult to judge what the scope >>> of a normative document should be. >>>> >>>> Could I suggest that before we scope the work and as a >>> consequence write the milestone, we see another version of >>> the author draft containing at least the minimum set of >>> normative requirements the authors think we need. >>>> >>>> That may be because it is written in the style of RFC 3263 >>> which also contains no normative provisions. It might be that >>> in order to scope this work we actually need a bis version of >>> RFC 3263, rather than something that adds some more >>> requirements in this area. >>>> >>>> In response to Cullen, I would say there is another reason >>> why something should be an update rather than just being >>> regarded as an extension. If it contains provisions that all >>> RFC 3263 implementations (or most of) should also implement, >>> and it is within the scope of the original RFC, then I >>> believe that may also justify and update. But I agree that we >>> need to write the requirements first and then do this analysis. >>>> >>>> I'd also remind you that Vijay has some comments that the >>> issue was wider than RFC 3263, so there may be a need to >>> scope round that. >>>> >>>> None of these comments should be taken as a suggestion that >>> we should not do the work (I think the issue has been >>> justified), only that I do not understand the scope and there >>> is not enough on the table to judge that. >>>> >>>> Keith >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf >>> Of Gonzalo >>>>> Salgueiro (gsalguei) >>>>> Sent: 12 December 2013 19:19 >>>>> To: Paul Kyzivat >>>>> Cc: SIPCORE WG; Olle E. Johansson; Gonzalo Salgueiro (gsalguei); >>>>> Cullen Jennings >>>>> Subject: Re: [sipcore] IPv6 in the sip core wg >>>>> Importance: High >>>>> >>>>> >>>>> On Dec 12, 2013, at 12:59 PM, Paul Kyzivat >>>>> wrote: >>>>> >>>>>> On 12/12/13 11:59 AM, Mary Barnes wrote: >>>>>>> The question in my mind becomes how you can word it >>>>> properly. There >>>>>>> are already procedures for dual stack, so you can't just say: >>>>>>> >>>>>>> Procedures for dual-stack server handling of SIP URIs containing >>>>>>> domain names >>>>>>> >>>>>>> Any of the adjectives proposed so far "Amended" or "Updated" or >>>>>>> others that might seem appropriate, e.g., "Enhanced" imply >>>>> that the >>>>>>> existing procedures are being changed or corrected. >>>>> Although maybe "Enhanced" is >>>>>>> general enough to not necessarily imply an "Update" to RFC >>>>> 3263? But, >>>>>>> then would you be talking about an Informational versus >>>>> standards track >>>>>>> document? I think it's usual for milestones to indicate >>>>> whether the >>>>>>> work is informational, standards track or BCP. But, if >>>>> the AD will >>>>>>> approve the new milestone without that level of >>>>> specificity, that's >>>>>>> fine. >>>>>> >>>>>> ISTM that we are in a situation where we need to consider >>>>> the details of the proposed mechanism(s) before deciding if the >>>>> desired mechanism will be an update or not. So I think it >>> makes sense >>>>> to word the milestone to be non-specific about this. >>>>>> >>>>>> Maybe its not the term itself that is the problem, but >>>>> rather what the term references. IOW, is it that we intend to >>>>> ammend/update/enhance/improve the *procedures*, or the >>>>> *description* of the procedures? >>>>>> >>>>>> IIUC the intent is to clarify the description, and if that >>>>> is insufficient to get a satisfactory result, then to update the >>>>> procedures themselves. >>>>> >>>>> So what is the proposed text for the milestone? >>>>> >>>>> Gonzalo >>>>> >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> But, I also don't think it's useful for the group to >>>>> rathole on that >>>>>>> later in the process and it will definitely cause >>>>> confusion if the WG >>>>>>> doesn't have a clear reason why the specific type of >>> specification >>>>>>> was selected. >>>>>>> >>>>>>> Regards, >>>>>>> Mary. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Dec 11, 2013 at 2:49 PM, Paul Kyzivat >>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Cullen, >>>>>>> >>>>>>> Would you be satisfied if the milestone is sufficiently >>>>> vague that >>>>>>> we can leave it to the deliverable to decide whether an >>>>> update is >>>>>>> needed or not? >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> >>>>>>> On 12/10/13 6:13 PM, Cullen Jennings wrote: >>>>>>> >>>>>>> >>>>>>> Well from a milestone point of view there is a big >>>>> difference >>>>>>> between we need the change an existing RFC (i.e. >>>>> update) or we >>>>>>> need to define a new RFC that tells developers who want to >>>>>>> implement the new RFC what they need to do. >>>>>>> >>>>>>> I think what is needed here is the later item and not the >>>>>>> update. I have asked about this a bunch of times and and I >>>>>>> always get answers that suggest that a new document >>>>> is needed >>>>>>> but it does not need to replace or update 3263. It >>>>> needs to be a >>>>>>> new document that provides more detailed advice. If >>>>> we are going >>>>>>> to say this updates something, I want to be >>>>> convinced first that >>>>>>> there is something that is wrong and needs to be >>>>> changed. I'm >>>>>>> fine with the idea that ore detailed specifications >>>>> are needed >>>>>>> to do something like happy eyeballs for SIP but I >>>>> don't think >>>>>>> that requires an update of 3263. >>>>>>> >>>>>>> >>>>>>> On Dec 10, 2013, at 12:21 PM, Olle E. Johansson >>>>> >>>>>> > wrote: >>>>>>> >>>>>>> >>>>>>> On 10 Dec 2013, at 12:14, Cullen Jennings >>> >>>>>> > wrote: >>>>>>> >>>>>>> >>>>>>> On Dec 10, 2013, at 9:59 AM, Paul Kyzivat >>>>>>> >>>> > >>>>>>> wrote: >>>>>>> >>>>>>> June 2014 Updated procedures for >>>>> dual-stack server >>>>>>> handling of SIP >>>>>>> URIs containing domain names >>>>>>> >>>>>>> >>>>>>> Before we use update, can someone tell me >>>>> what normative >>>>>>> text of the current RFCs need to be changed? >>>>>>> >>>>>>> >>>>>>> That's part of the problem, RFC 3263 is not >>>>> very clear to me >>>>>>> in indicating what exactly is normative. If >>> you read our >>>>>>> draft, you will see that we point to a few >>> sections that >>>>>>> clearly says that a UA needs to look up "A or >>>>> AAAA" records, >>>>>>> which has been proven wrong and doesn't follow >>>>> the intention >>>>>>> of the DNS SRV RFC. If this was unintentional >>>>> or normative, >>>>>>> I don't know, but it's written enough times to >>>>> cause issues >>>>>>> in implementations and have been copied to >>>>> other documents, >>>>>>> like the MSRP RFC. >>>>>>> >>>>>>> We need to clarify that a SIP implementation >>>>> needs to follow >>>>>>> the DNS SRV RFC and look up all addresses for a >>>>> host name >>>>>>> (ipv4, IPv6 or future address families) and >>>>> test them all >>>>>>> before moving to the next priority and host. >>>>>>> >>>>>>> I've checked this with members of the IETF DNS >>>>> directorate >>>>>>> two times now, and they agree with this. >>>>>>> >>>>>>> When we clarified/updated/extended/__informed >>>>> the audience - >>>>>>> developers - about this, we need to get down to how to >>>>>>> connect - serially, in parallell, in reverse >>>>> random order >>>>>>> controlled by the phases of the moon or other >>>>> planets - or >>>>>>> simply Happy Eyeballs. But even with TCP, doing happy >>>>>>> eyeballs like in HTTP would not work unless we >>>>> have both A >>>>>>> and AAAA records. RFC 3263 doesn't really >>> indicate that. >>>>>>> >>>>>>> Someone else needs to help out to clarify to me what is >>>>>>> really normative in 3263 and what the >>>>> relationship between >>>>>>> 3263 and RFC 2782 really is - if RFC 2782 is >>>>> the normative >>>>>>> one and RFC 3263 just can be seen as a happy story that >>>>>>> points to 2782 without making any normative changes, we >>>>>>> might have to clarify that in an informational >>>>> document and >>>>>>> move on to connection setup in a dual stack >>>>> world. If RFC >>>>>>> 3263 changes the behaviour intended by 2782 and really >>>>>>> forces a developer to select A or AAAA records, >>>>> then we need >>>>>>> to change that behaviour. >>>>>>> >>>>>>> Either way, we have work to do in ths wg. >>>>>>> /O >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>> > > From oej@edvina.net Fri Dec 13 08:34:55 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8C71AE323 for ; Fri, 13 Dec 2013 08:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhB-d_l4KZv5 for ; Fri, 13 Dec 2013 08:34:53 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id D8E611AE337 for ; Fri, 13 Dec 2013 08:34:51 -0800 (PST) Received: from [192.168.101.75] (unknown [72.46.244.148]) by smtp7.webway.se (Postfix) with ESMTPA id E7DA893C2A2; Fri, 13 Dec 2013 16:34:42 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" X-Priority: 1 In-Reply-To: Date: Fri, 13 Dec 2013 11:34:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <960CC805-6BB1-4607-96BC-20BE6F1FE428@edvina.net> References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "Gonzalo Salgueiro (gsalguei)" X-Mailer: Apple Mail (2.1822) Cc: Cullen Jennings , Olle E Johansson , SIPCORE WG Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 16:34:55 -0000 On 12 Dec 2013, at 20:07, Gonzalo Salgueiro (gsalguei) = wrote: >=20 > On Dec 12, 2013, at 8:04 PM, DRAGE, Keith (Keith) = wrote: >=20 >> Lets look at the specification. >>=20 >> Your mail seems to being its best to justify it as a BCP, which I = assume is not what you intend. >=20 > You're right, t is not at all my intent. What I intend is to provide = a stand-alone RFC that provides some useful supplemental procedures for = improved performance in SIP dual-stack environments. Yes, we need to help developers with a specification that makes SIP work = properly in dual stack environments. Whether or not it's an update to another RFC is nothing I can judge, I = was told to add the update statement earlier on and just did so. At this = point, I have no opinion about that part, but really want us to write = specs so that we can build working implementations. RFC 3263 alone doesn't help in = doing that, so we clearly need to add a new document to the series, update our code and test at = SIPit. :-) /O >=20 > Gonzalo >=20 >=20 >>=20 >> Keith=20 >>=20 >>> -----Original Message----- >>> From: Gonzalo Salgueiro (gsalguei) [mailto:gsalguei@cisco.com]=20 >>> Sent: 13 December 2013 00:54 >>> To: DRAGE, Keith (Keith) >>> Cc: Paul Kyzivat; Gonzalo Salgueiro (gsalguei); SIPCORE WG;=20 >>> Olle E. Johansson; Cullen Jennings >>> Subject: Re: [sipcore] IPv6 in the sip core wg >>> Importance: High >>>=20 >>> (as co-author) >>>=20 >>> I'm happy to publish a new version of the document that makes=20 >>> use of 2119 language. =20 >>>=20 >>> I think we might be trying to over-complicate matters. As=20 >>> stated earlier, this work is merely an extension to the=20 >>> procedures in 3263 and should not make the myriad existing=20 >>> deployments non-compliant to a core SIP specification. The=20 >>> intent here is only to provide supplemental best practices=20 >>> that we have learned along the way through extensive interop=20 >>> testing. To emblazon this point into everyone's psyche, the=20 >>> next version will not have the "Updates: 3263 (if approved)" label. >>>=20 >>> With this in mind, I propose the following as the milestone text: >>>=20 >>> Supplemental procedures for dual-stack server handling of SIP=20 >>> URIs containing domain names >>>=20 >>>=20 >>> To your point regarding Vijay, the authors will stay in sync=20 >>> with him throughout. >>>=20 >>>=20 >>> Cheers, >>>=20 >>> Gonzalo >>>=20 >>>=20 >>>=20 >>> On Dec 12, 2013, at 4:45 PM, DRAGE, Keith (Keith)=20 >>> wrote: >>>=20 >>>> I was losing track of this discussion so I had to go back. >>>>=20 >>>> The only document we seem to have on the table at the moment is: >>>>=20 >>>> http://www.ietf.org/id/draft-johansson-sip-dual-stack-01.txt >>>>=20 >>>> This currently contains no normative provisions (no MUST,=20 >>> SHOULD, MAY) so it is a bit difficult to judge what the scope=20 >>> of a normative document should be. >>>>=20 >>>> Could I suggest that before we scope the work and as a=20 >>> consequence write the milestone, we see another version of=20 >>> the author draft containing at least the minimum set of=20 >>> normative requirements the authors think we need. >>>>=20 >>>> That may be because it is written in the style of RFC 3263=20 >>> which also contains no normative provisions. It might be that=20 >>> in order to scope this work we actually need a bis version of=20 >>> RFC 3263, rather than something that adds some more=20 >>> requirements in this area. >>>>=20 >>>> In response to Cullen, I would say there is another reason=20 >>> why something should be an update rather than just being=20 >>> regarded as an extension. If it contains provisions that all=20 >>> RFC 3263 implementations (or most of) should also implement,=20 >>> and it is within the scope of the original RFC, then I=20 >>> believe that may also justify and update. But I agree that we=20 >>> need to write the requirements first and then do this analysis. >>>>=20 >>>> I'd also remind you that Vijay has some comments that the=20 >>> issue was wider than RFC 3263, so there may be a need to=20 >>> scope round that. >>>>=20 >>>> None of these comments should be taken as a suggestion that=20 >>> we should not do the work (I think the issue has been=20 >>> justified), only that I do not understand the scope and there=20 >>> is not enough on the table to judge that. >>>>=20 >>>> Keith >>>>=20 >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf=20 >>> Of Gonzalo=20 >>>>> Salgueiro (gsalguei) >>>>> Sent: 12 December 2013 19:19 >>>>> To: Paul Kyzivat >>>>> Cc: SIPCORE WG; Olle E. Johansson; Gonzalo Salgueiro (gsalguei);=20= >>>>> Cullen Jennings >>>>> Subject: Re: [sipcore] IPv6 in the sip core wg >>>>> Importance: High >>>>>=20 >>>>>=20 >>>>> On Dec 12, 2013, at 12:59 PM, Paul Kyzivat =20= >>>>> wrote: >>>>>=20 >>>>>> On 12/12/13 11:59 AM, Mary Barnes wrote: >>>>>>> The question in my mind becomes how you can word it >>>>> properly. There >>>>>>> are already procedures for dual stack, so you can't just say: >>>>>>>=20 >>>>>>> Procedures for dual-stack server handling of SIP URIs containing=20= >>>>>>> domain names >>>>>>>=20 >>>>>>> Any of the adjectives proposed so far "Amended" or "Updated" or=20= >>>>>>> others that might seem appropriate, e.g., "Enhanced" imply >>>>> that the >>>>>>> existing procedures are being changed or corrected. =20 >>>>> Although maybe "Enhanced" is >>>>>>> general enough to not necessarily imply an "Update" to RFC >>>>> 3263? But, >>>>>>> then would you be talking about an Informational versus >>>>> standards track >>>>>>> document? I think it's usual for milestones to indicate=20 >>>>> whether the >>>>>>> work is informational, standards track or BCP. But, if >>>>> the AD will >>>>>>> approve the new milestone without that level of >>>>> specificity, that's >>>>>>> fine. >>>>>>=20 >>>>>> ISTM that we are in a situation where we need to consider >>>>> the details of the proposed mechanism(s) before deciding if the=20 >>>>> desired mechanism will be an update or not. So I think it=20 >>> makes sense=20 >>>>> to word the milestone to be non-specific about this. >>>>>>=20 >>>>>> Maybe its not the term itself that is the problem, but >>>>> rather what the term references. IOW, is it that we intend to=20 >>>>> ammend/update/enhance/improve the *procedures*, or the >>>>> *description* of the procedures? >>>>>>=20 >>>>>> IIUC the intent is to clarify the description, and if that >>>>> is insufficient to get a satisfactory result, then to update the=20= >>>>> procedures themselves. >>>>>=20 >>>>> So what is the proposed text for the milestone? >>>>>=20 >>>>> Gonzalo >>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>> Paul >>>>>>=20 >>>>>>> But, I also don't think it's useful for the group to >>>>> rathole on that >>>>>>> later in the process and it will definitely cause >>>>> confusion if the WG >>>>>>> doesn't have a clear reason why the specific type of=20 >>> specification=20 >>>>>>> was selected. >>>>>>>=20 >>>>>>> Regards, >>>>>>> Mary. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Wed, Dec 11, 2013 at 2:49 PM, Paul Kyzivat >>>>> >>>>>> > wrote: >>>>>>>=20 >>>>>>> Cullen, >>>>>>>=20 >>>>>>> Would you be satisfied if the milestone is sufficiently >>>>> vague that >>>>>>> we can leave it to the deliverable to decide whether an >>>>> update is >>>>>>> needed or not? >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Paul >>>>>>>=20 >>>>>>>=20 >>>>>>> On 12/10/13 6:13 PM, Cullen Jennings wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> Well from a milestone point of view there is a big >>>>> difference >>>>>>> between we need the change an existing RFC (i.e.=20 >>>>> update) or we >>>>>>> need to define a new RFC that tells developers who want to >>>>>>> implement the new RFC what they need to do. >>>>>>>=20 >>>>>>> I think what is needed here is the later item and not the >>>>>>> update. I have asked about this a bunch of times and and I >>>>>>> always get answers that suggest that a new document >>>>> is needed >>>>>>> but it does not need to replace or update 3263. It >>>>> needs to be a >>>>>>> new document that provides more detailed advice. If >>>>> we are going >>>>>>> to say this updates something, I want to be >>>>> convinced first that >>>>>>> there is something that is wrong and needs to be >>>>> changed. I'm >>>>>>> fine with the idea that ore detailed specifications >>>>> are needed >>>>>>> to do something like happy eyeballs for SIP but I >>>>> don't think >>>>>>> that requires an update of 3263. >>>>>>>=20 >>>>>>>=20 >>>>>>> On Dec 10, 2013, at 12:21 PM, Olle E. Johansson >>>>> >>>>>> > wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> On 10 Dec 2013, at 12:14, Cullen Jennings=20 >>> >>>>>> > wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> On Dec 10, 2013, at 9:59 AM, Paul Kyzivat >>>>>>> >>>> > >>>>>>> wrote: >>>>>>>=20 >>>>>>> June 2014 Updated procedures for >>>>> dual-stack server >>>>>>> handling of SIP >>>>>>> URIs containing domain names >>>>>>>=20 >>>>>>>=20 >>>>>>> Before we use update, can someone tell me >>>>> what normative >>>>>>> text of the current RFCs need to be changed? >>>>>>>=20 >>>>>>>=20 >>>>>>> That's part of the problem, RFC 3263 is not >>>>> very clear to me >>>>>>> in indicating what exactly is normative. If=20 >>> you read our >>>>>>> draft, you will see that we point to a few=20 >>> sections that >>>>>>> clearly says that a UA needs to look up "A or >>>>> AAAA" records, >>>>>>> which has been proven wrong and doesn't follow >>>>> the intention >>>>>>> of the DNS SRV RFC. If this was unintentional >>>>> or normative, >>>>>>> I don't know, but it's written enough times to >>>>> cause issues >>>>>>> in implementations and have been copied to >>>>> other documents, >>>>>>> like the MSRP RFC. >>>>>>>=20 >>>>>>> We need to clarify that a SIP implementation >>>>> needs to follow >>>>>>> the DNS SRV RFC and look up all addresses for a >>>>> host name >>>>>>> (ipv4, IPv6 or future address families) and >>>>> test them all >>>>>>> before moving to the next priority and host. >>>>>>>=20 >>>>>>> I've checked this with members of the IETF DNS >>>>> directorate >>>>>>> two times now, and they agree with this. >>>>>>>=20 >>>>>>> When we clarified/updated/extended/__informed >>>>> the audience - >>>>>>> developers - about this, we need to get down to how to >>>>>>> connect - serially, in parallell, in reverse >>>>> random order >>>>>>> controlled by the phases of the moon or other >>>>> planets - or >>>>>>> simply Happy Eyeballs. But even with TCP, doing happy >>>>>>> eyeballs like in HTTP would not work unless we >>>>> have both A >>>>>>> and AAAA records. RFC 3263 doesn't really=20 >>> indicate that. >>>>>>>=20 >>>>>>> Someone else needs to help out to clarify to me what is >>>>>>> really normative in 3263 and what the >>>>> relationship between >>>>>>> 3263 and RFC 2782 really is - if RFC 2782 is >>>>> the normative >>>>>>> one and RFC 3263 just can be seen as a happy story that >>>>>>> points to 2782 without making any normative changes, we >>>>>>> might have to clarify that in an informational >>>>> document and >>>>>>> move on to connection setup in a dual stack >>>>> world. If RFC >>>>>>> 3263 changes the behaviour intended by 2782 and really >>>>>>> forces a developer to select A or AAAA records, >>>>> then we need >>>>>>> to change that behaviour. >>>>>>>=20 >>>>>>> Either way, we have work to do in ths wg. >>>>>>> /O >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >=20 From pkyzivat@alum.mit.edu Fri Dec 13 09:19:38 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80861AE349 for ; Fri, 13 Dec 2013 09:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTfKHGv1-gPT for ; Fri, 13 Dec 2013 09:19:37 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id A715D1AD8CD for ; Fri, 13 Dec 2013 09:19:37 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta03.westchester.pa.mail.comcast.net with comcast id 110B1n00417dt5G535KWJw; Fri, 13 Dec 2013 17:19:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id 15KW1n00n3ZTu2S3Z5KWf1; Fri, 13 Dec 2013 17:19:30 +0000 Message-ID: <52AB41A2.6070700@alum.mit.edu> Date: Fri, 13 Dec 2013 12:19:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <7886ADB0-BDB3-4D15-800B-AAEB34713547@iii.ca> <52AB353A.9030600@bell-labs.com> In-Reply-To: <52AB353A.9030600@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386955170; bh=+ksSKH8GglwaY+io90ZwakP38dv7NL3w4Ia/X7gA6Po=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=aNv2J7GzUHH8F2XYTOayw/NMEbip7r1RQJV7qFLDw8gOe3ixHB+lYXqVN2tpXRJsY XGt8nCvpSpehxSCcCsy99eT1d+E7ptkY3ZR98ojnaefNAL2G1w6JYoE6l4vaDMCz/2 9ovGsDYoxB5zlxxrB5ejrSIG6IRJsAMCH00N2zh1RdYt/IxUoOC3YQfNSIeT2iCtdc P/gRbgyENs9R+TdJFKxptW1VunJ6gP3wnaRPE9E7MhDjHLs6UNOlWbOQhPyTkJRiPg JfVUa61bHwEAkxJMffrf3uPOI08/3hfQX4vq8FonKt2MDToGBQIaM8LD7FjXPDAY76 kXWY0UCPgpLyA== Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 17:19:39 -0000 Vijay, On 12/13/13 11:26 AM, Vijay K. Gurbani wrote: > On 12/13/2013 10:17 AM, Olle E. Johansson wrote: >> The problem is really that RFC 3263 repeats "A or AAAA" - which means >> that if we follow RFC 3263 verbatim we won't have both IPv4 and IPv6 >> addresses to connect to. I have not claimed that it talks about how >> we connect. > > I am sorry to keep interjecting rfc6157 here, but it does say to perform > name lookup using getaddrinfo(), which, if rfc3484 is adhered to will > produce an ordered list of IPv6/IPv4 destination addresses. It's ok to keep bringing it up, because it seems to be relevant. I just glanced through it to refresh my memory. It seems to cover, at least implicitly, some of the same scope. But that part of the draft appears to have been somewhat of an afterthought. I find the following problematic: "IPv6-only or dual-stack clients MUST use the newer getaddrinfo() name lookup function, instead of gethostbyname()." It is a normative statement to use a particular API function as an alternative to a different API function. But there was never a requirement to use "gethostbyname", so the "instead" isn't meaningful, and we shouldn't be requiring use of any particular API functions. It would make a lot more sense if it had a MUST on the algorithms in 3484. (I no doubt participated in the WGLC on this document, so I have only myself to blame for not complaining about this earlier.) Since that is now an RFC, I guess we should assume that people will "do the right thing" if those APIs don't work for them, and follow the intent of the RFC. >> It seems like no one can say whether this text is normative or not, >> which really means we have to clarify this, since developers will be >> (or already am) confused on how to implement properly. > > Sure, rfc6157 does not update rfc3263 so this point may be lost in the > noise. To be sure, I am not against adding a milestone to better > specify this behaviour; all I am pointing out is that more than rfc3263 > may be impacted. At the very least, we should include that in the scope of the work. Here is a revised milestone: May 2014 WGLC of procedures to supplement RFC3263 and RFC6157 for dual-stack client and server handling of SIP URIs containing domain names (PS) Thanks, Paul > Cheers, > > - vijay From gsalguei@cisco.com Fri Dec 13 09:22:23 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62CA1ADF9A for ; Fri, 13 Dec 2013 09:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VhMGsOVl2Zf for ; Fri, 13 Dec 2013 09:22:21 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A21DB1ADD9D for ; Fri, 13 Dec 2013 09:22:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14823; q=dns/txt; s=iport; t=1386955334; x=1388164934; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gbYQkE6ZO2RUqhjyLY5uxn1+XUkChfmskf2RlbRJXlE=; b=OXRKdgCdCtKnKcbhnGWRgZup3CP9jcQdTPPhGdJmQxGdDYrpGC7vjoW5 1CmfG98PLbuvGwDOHrCPYxNvwdM8DsrnN1+fndczl6tD/54/L1q9ioipO 0je4OrgAKYBmSHKbxnXBTDXymOYZGsLEhDJR5NO3+DWcEkrqmopGY9Yrh o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFABVBq1KtJV2a/2dsb2JhbABZDoJ8OFW4D06BJRZ0giUBAQEDAQEBASZFBAcFBwQCAQIGDgMEAQEBJwcnCxQJCAIEDgUJh3MIDcsiF45BAwEBHDMHBoMdgRMEiQuLKINjkhSCaz+BcTk X-IronPort-AV: E=Sophos;i="4.95,480,1384300800"; d="scan'208";a="291418134" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 13 Dec 2013 17:22:12 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBDHMBws031858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 17:22:11 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Fri, 13 Dec 2013 11:22:12 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat Thread-Topic: [sipcore] IPv6 in the sip core wg Thread-Index: AQHO92PvPaG9LxtinkCT+HMY0fMEHZpRU8qAgAApEICAADScgIAAAt0AgAAA7wCAAQE5AIAADwgA Importance: high X-Priority: 1 Date: Fri, 13 Dec 2013 17:22:10 +0000 Message-ID: <8CADAD8F-0D99-44E0-9BF2-44C087EF3509@cisco.com> References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> In-Reply-To: <52AB35A6.8030701@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.215.251] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Olle E. Johansson" , SIPCORE WG , "Gonzalo Salgueiro \(gsalguei\)" , Cullen Jennings Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 17:22:23 -0000 On Dec 13, 2013, at 11:28 AM, Paul Kyzivat wrote: > On 12/12/13 8:07 PM, Gonzalo Salgueiro (gsalguei) wrote: >>=20 >> On Dec 12, 2013, at 8:04 PM, DRAGE, Keith (Keith) wrote: >>=20 >>> Lets look at the specification. >>>=20 >>> Your mail seems to being its best to justify it as a BCP, which I assum= e is not what you intend. >>=20 >> You're right, t is not at all my intent. What I intend is to provide a = stand-alone RFC that provides some useful supplemental procedures for impro= ved performance in SIP dual-stack environments. >=20 > If these procedures are supplemental, will there be anything that should = be normative? >=20 > Contrary to what Keith said, I do find normative language in the draft no= w. (A SHOULD in the last paragraph of 3.1.) And this is a change to languag= e in 3263 - changing "A or AAAA" to "A and AAAA". >=20 > It is arguable whether this has normative impact on existing implementati= ons of 3263. 3263 has no normative language regarding "A or AAAA", but it d= oes have normative language ("SHOULD") about how to use the results of the = lookup. I think it can be viewed as a normative change to 3263 for dual sta= ck devices. >=20 > And 3263 suffers from the common problem of using "SHOULD" widely without= any explanation of when it makes sense to violate the "SHOULD". This gives= people the opportunity to say that implementations that do otherwise are s= till compliant. I would be uncomfortable publishing a new normative RFC tha= t doesn't say it updates 3263 while mandating behavior that is different fr= om the SHOULDs of 3263. >=20 > Having said that, I suggest the following as the milestone: >=20 > May 2014 WGLC of procedures to supplement RFC3263 for dual-stack > client and server handling of SIP URIs containing domain names (PS) >=20 > This assumes that the work will be standards track, but doesn't say wheth= er or not it will update 3263. I've made the milestone to be for WGLC, so w= e take the time for IESG processing out of the schedule. The date is after = the London meeting but before the Toronto meeting. It is assuming that we w= ill get much of the work done on the mailing list before London, thrash out= any controversial issues in London, then do cleanup and WGLC. It is optimi= stic, but possible if there isn't a lot if dissent. >=20 > Richard - does this work for you? >=20 > Olle & Gonzalo - does it work for you? I'm ok with it. =20 The authors will make some changes to the current version of the document a= nd submit a new version that hopefully makes clearer the original intent: a= stand-alone RFC offering improved procedures for dual-stack environments (= i.e., does not invalidate or render non-compliant the myriad of 3263 implem= entations out there that work fine with v6). Gonzalo >=20 > Thanks, > Paul >=20 >=20 >> Gonzalo >>=20 >>=20 >>>=20 >>> Keith >>>=20 >>>> -----Original Message----- >>>> From: Gonzalo Salgueiro (gsalguei) [mailto:gsalguei@cisco.com] >>>> Sent: 13 December 2013 00:54 >>>> To: DRAGE, Keith (Keith) >>>> Cc: Paul Kyzivat; Gonzalo Salgueiro (gsalguei); SIPCORE WG; >>>> Olle E. Johansson; Cullen Jennings >>>> Subject: Re: [sipcore] IPv6 in the sip core wg >>>> Importance: High >>>>=20 >>>> (as co-author) >>>>=20 >>>> I'm happy to publish a new version of the document that makes >>>> use of 2119 language. >>>>=20 >>>> I think we might be trying to over-complicate matters. As >>>> stated earlier, this work is merely an extension to the >>>> procedures in 3263 and should not make the myriad existing >>>> deployments non-compliant to a core SIP specification. The >>>> intent here is only to provide supplemental best practices >>>> that we have learned along the way through extensive interop >>>> testing. To emblazon this point into everyone's psyche, the >>>> next version will not have the "Updates: 3263 (if approved)" label. >>>>=20 >>>> With this in mind, I propose the following as the milestone text: >>>>=20 >>>> Supplemental procedures for dual-stack server handling of SIP >>>> URIs containing domain names >>>>=20 >>>>=20 >>>> To your point regarding Vijay, the authors will stay in sync >>>> with him throughout. >>>>=20 >>>>=20 >>>> Cheers, >>>>=20 >>>> Gonzalo >>>>=20 >>>>=20 >>>>=20 >>>> On Dec 12, 2013, at 4:45 PM, DRAGE, Keith (Keith) >>>> wrote: >>>>=20 >>>>> I was losing track of this discussion so I had to go back. >>>>>=20 >>>>> The only document we seem to have on the table at the moment is: >>>>>=20 >>>>> http://www.ietf.org/id/draft-johansson-sip-dual-stack-01.txt >>>>>=20 >>>>> This currently contains no normative provisions (no MUST, >>>> SHOULD, MAY) so it is a bit difficult to judge what the scope >>>> of a normative document should be. >>>>>=20 >>>>> Could I suggest that before we scope the work and as a >>>> consequence write the milestone, we see another version of >>>> the author draft containing at least the minimum set of >>>> normative requirements the authors think we need. >>>>>=20 >>>>> That may be because it is written in the style of RFC 3263 >>>> which also contains no normative provisions. It might be that >>>> in order to scope this work we actually need a bis version of >>>> RFC 3263, rather than something that adds some more >>>> requirements in this area. >>>>>=20 >>>>> In response to Cullen, I would say there is another reason >>>> why something should be an update rather than just being >>>> regarded as an extension. If it contains provisions that all >>>> RFC 3263 implementations (or most of) should also implement, >>>> and it is within the scope of the original RFC, then I >>>> believe that may also justify and update. But I agree that we >>>> need to write the requirements first and then do this analysis. >>>>>=20 >>>>> I'd also remind you that Vijay has some comments that the >>>> issue was wider than RFC 3263, so there may be a need to >>>> scope round that. >>>>>=20 >>>>> None of these comments should be taken as a suggestion that >>>> we should not do the work (I think the issue has been >>>> justified), only that I do not understand the scope and there >>>> is not enough on the table to judge that. >>>>>=20 >>>>> Keith >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf >>>> Of Gonzalo >>>>>> Salgueiro (gsalguei) >>>>>> Sent: 12 December 2013 19:19 >>>>>> To: Paul Kyzivat >>>>>> Cc: SIPCORE WG; Olle E. Johansson; Gonzalo Salgueiro (gsalguei); >>>>>> Cullen Jennings >>>>>> Subject: Re: [sipcore] IPv6 in the sip core wg >>>>>> Importance: High >>>>>>=20 >>>>>>=20 >>>>>> On Dec 12, 2013, at 12:59 PM, Paul Kyzivat >>>>>> wrote: >>>>>>=20 >>>>>>> On 12/12/13 11:59 AM, Mary Barnes wrote: >>>>>>>> The question in my mind becomes how you can word it >>>>>> properly. There >>>>>>>> are already procedures for dual stack, so you can't just say: >>>>>>>>=20 >>>>>>>> Procedures for dual-stack server handling of SIP URIs containing >>>>>>>> domain names >>>>>>>>=20 >>>>>>>> Any of the adjectives proposed so far "Amended" or "Updated" or >>>>>>>> others that might seem appropriate, e.g., "Enhanced" imply >>>>>> that the >>>>>>>> existing procedures are being changed or corrected. >>>>>> Although maybe "Enhanced" is >>>>>>>> general enough to not necessarily imply an "Update" to RFC >>>>>> 3263? But, >>>>>>>> then would you be talking about an Informational versus >>>>>> standards track >>>>>>>> document? I think it's usual for milestones to indicate >>>>>> whether the >>>>>>>> work is informational, standards track or BCP. But, if >>>>>> the AD will >>>>>>>> approve the new milestone without that level of >>>>>> specificity, that's >>>>>>>> fine. >>>>>>>=20 >>>>>>> ISTM that we are in a situation where we need to consider >>>>>> the details of the proposed mechanism(s) before deciding if the >>>>>> desired mechanism will be an update or not. So I think it >>>> makes sense >>>>>> to word the milestone to be non-specific about this. >>>>>>>=20 >>>>>>> Maybe its not the term itself that is the problem, but >>>>>> rather what the term references. IOW, is it that we intend to >>>>>> ammend/update/enhance/improve the *procedures*, or the >>>>>> *description* of the procedures? >>>>>>>=20 >>>>>>> IIUC the intent is to clarify the description, and if that >>>>>> is insufficient to get a satisfactory result, then to update the >>>>>> procedures themselves. >>>>>>=20 >>>>>> So what is the proposed text for the milestone? >>>>>>=20 >>>>>> Gonzalo >>>>>>=20 >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Paul >>>>>>>=20 >>>>>>>> But, I also don't think it's useful for the group to >>>>>> rathole on that >>>>>>>> later in the process and it will definitely cause >>>>>> confusion if the WG >>>>>>>> doesn't have a clear reason why the specific type of >>>> specification >>>>>>>> was selected. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Mary. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Wed, Dec 11, 2013 at 2:49 PM, Paul Kyzivat >>>>>> >>>>>>> > wrote: >>>>>>>>=20 >>>>>>>> Cullen, >>>>>>>>=20 >>>>>>>> Would you be satisfied if the milestone is sufficiently >>>>>> vague that >>>>>>>> we can leave it to the deliverable to decide whether an >>>>>> update is >>>>>>>> needed or not? >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 12/10/13 6:13 PM, Cullen Jennings wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Well from a milestone point of view there is a big >>>>>> difference >>>>>>>> between we need the change an existing RFC (i.e. >>>>>> update) or we >>>>>>>> need to define a new RFC that tells developers who want to >>>>>>>> implement the new RFC what they need to do. >>>>>>>>=20 >>>>>>>> I think what is needed here is the later item and not the >>>>>>>> update. I have asked about this a bunch of times and and I >>>>>>>> always get answers that suggest that a new document >>>>>> is needed >>>>>>>> but it does not need to replace or update 3263. It >>>>>> needs to be a >>>>>>>> new document that provides more detailed advice. If >>>>>> we are going >>>>>>>> to say this updates something, I want to be >>>>>> convinced first that >>>>>>>> there is something that is wrong and needs to be >>>>>> changed. I'm >>>>>>>> fine with the idea that ore detailed specifications >>>>>> are needed >>>>>>>> to do something like happy eyeballs for SIP but I >>>>>> don't think >>>>>>>> that requires an update of 3263. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Dec 10, 2013, at 12:21 PM, Olle E. Johansson >>>>>> >>>>>>> > wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 10 Dec 2013, at 12:14, Cullen Jennings >>>> >>>>>>> > wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Dec 10, 2013, at 9:59 AM, Paul Kyzivat >>>>>>>> >>>>> > >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>> June 2014 Updated procedures for >>>>>> dual-stack server >>>>>>>> handling of SIP >>>>>>>> URIs containing domain names >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Before we use update, can someone tell me >>>>>> what normative >>>>>>>> text of the current RFCs need to be changed? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> That's part of the problem, RFC 3263 is not >>>>>> very clear to me >>>>>>>> in indicating what exactly is normative. If >>>> you read our >>>>>>>> draft, you will see that we point to a few >>>> sections that >>>>>>>> clearly says that a UA needs to look up "A or >>>>>> AAAA" records, >>>>>>>> which has been proven wrong and doesn't follow >>>>>> the intention >>>>>>>> of the DNS SRV RFC. If this was unintentional >>>>>> or normative, >>>>>>>> I don't know, but it's written enough times to >>>>>> cause issues >>>>>>>> in implementations and have been copied to >>>>>> other documents, >>>>>>>> like the MSRP RFC. >>>>>>>>=20 >>>>>>>> We need to clarify that a SIP implementation >>>>>> needs to follow >>>>>>>> the DNS SRV RFC and look up all addresses for a >>>>>> host name >>>>>>>> (ipv4, IPv6 or future address families) and >>>>>> test them all >>>>>>>> before moving to the next priority and host. >>>>>>>>=20 >>>>>>>> I've checked this with members of the IETF DNS >>>>>> directorate >>>>>>>> two times now, and they agree with this. >>>>>>>>=20 >>>>>>>> When we clarified/updated/extended/__informed >>>>>> the audience - >>>>>>>> developers - about this, we need to get down to how to >>>>>>>> connect - serially, in parallell, in reverse >>>>>> random order >>>>>>>> controlled by the phases of the moon or other >>>>>> planets - or >>>>>>>> simply Happy Eyeballs. But even with TCP, doing happy >>>>>>>> eyeballs like in HTTP would not work unless we >>>>>> have both A >>>>>>>> and AAAA records. RFC 3263 doesn't really >>>> indicate that. >>>>>>>>=20 >>>>>>>> Someone else needs to help out to clarify to me what is >>>>>>>> really normative in 3263 and what the >>>>>> relationship between >>>>>>>> 3263 and RFC 2782 really is - if RFC 2782 is >>>>>> the normative >>>>>>>> one and RFC 3263 just can be seen as a happy story that >>>>>>>> points to 2782 without making any normative changes, we >>>>>>>> might have to clarify that in an informational >>>>>> document and >>>>>>>> move on to connection setup in a dual stack >>>>>> world. If RFC >>>>>>>> 3263 changes the behaviour intended by 2782 and really >>>>>>>> forces a developer to select A or AAAA records, >>>>>> then we need >>>>>>>> to change that behaviour. >>>>>>>>=20 >>>>>>>> Either way, we have work to do in ths wg. >>>>>>>> /O >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>=20 >>=20 >>=20 >=20 From keith.drage@alcatel-lucent.com Fri Dec 13 09:27:39 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC6B1AE371 for ; Fri, 13 Dec 2013 09:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY3aMZu8AF6M for ; Fri, 13 Dec 2013 09:27:35 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4681AE349 for ; Fri, 13 Dec 2013 09:27:34 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id rBDHQpXC013037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Dec 2013 11:26:53 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rBDHQmrb026970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 18:26:51 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 13 Dec 2013 18:26:49 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "Gonzalo Salgueiro (gsalguei)" Thread-Topic: [sipcore] IPv6 in the sip core wg Thread-Index: AQHO9f1rFmxMwFa6OUik7RkhLMXct5pSVLkwgAAIRxA= Date: Fri, 13 Dec 2013 17:26:48 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0F9012@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> In-Reply-To: <52AB35A6.8030701@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: SIPCORE WG , "Olle E. Johansson" , Cullen Jennings Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 17:27:39 -0000 Yes, I've found the SHOULD now in the draft. Mozilla did one of its tricks = on me and as a result I was searching for the wrong things. I agree with your comment on 3263 in regard to the use of SHOULD. It does c= ontain normative provisions, but they are substantially SHOULD requirements= with no additional guidance. I could not find anything in RFC 3263 than mandated in any form the use of = A versus AAAA, eithewr together or separately. On that basis it adds rather than updates. But there may be other requireme= nts that come out of the discussion. But Vijay keeps mentioning RFC 6157 so I had a look and there it states: "IPv4/IPv6 user agents SHOULD gather both IPv4 and IPv6 addresses using the ICE procedures to generate all their offers. This way, both IPv4-only and IPv6-only answerers will be able to generate a mutually acceptable answer that establishes a session (having used ICE to gather both IPv4 and IPv6 addresses in the offer reduces the session establishment time because all answerers will find the offer valid.) Implementations are encouraged to use ICE; however, the normative strength of the text above is left at a SHOULD since in some managed networks (such as a closed enterprise network) it is possible for the administrator to have control over the IP version utilized in all nodes and thus deploy an IPv6-only network, for example. The use of ICE can be avoided for signaling messages that stay within such managed networks." So is that not pretty much saying the same thing as: "A dual-stack client SHOULD perform an A and AAAA record lookup of the domain name and add the respective IPv4/IPv6 addresses to the list of IP addresses to be contacted." Certainly, if something is missing, we may well be talking about something = that updates RFC 6157 rather than RFC 3263. In regards to your milestone proposal, I do not understand: "so we take the time for IESG processing out of the schedule" "to WGLC" is to the start of WGLC "to IESG" is the publication request Neither milestone would include IESG processing. A possible different milestone wording would be "Use of RFC 3263 in dual-st= ack devices". I would like to get rid of the word "supplement". We'd need t= o see if that requires changing based on Vijay's input. Keith =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 > Sent: 13 December 2013 16:28 > To: Gonzalo Salgueiro (gsalguei); DRAGE, Keith (Keith) > Cc: SIPCORE WG; Olle E. Johansson; Cullen Jennings > Subject: Re: [sipcore] IPv6 in the sip core wg >=20 > On 12/12/13 8:07 PM, Gonzalo Salgueiro (gsalguei) wrote: > > > > On Dec 12, 2013, at 8:04 PM, DRAGE, Keith (Keith)=20 > wrote: > > > >> Lets look at the specification. > >> > >> Your mail seems to being its best to justify it as a BCP,=20 > which I assume is not what you intend. > > > > You're right, t is not at all my intent. What I intend is=20 > to provide a stand-alone RFC that provides some useful=20 > supplemental procedures for improved performance in SIP=20 > dual-stack environments. >=20 > If these procedures are supplemental, will there be anything=20 > that should be normative? >=20 > Contrary to what Keith said, I do find normative language in=20 > the draft now. (A SHOULD in the last paragraph of 3.1.) And=20 > this is a change to language in 3263 - changing "A or AAAA"=20 > to "A and AAAA". >=20 > It is arguable whether this has normative impact on existing=20 > implementations of 3263. 3263 has no normative language=20 > regarding "A or AAAA", but it does have normative language=20 > ("SHOULD") about how to use the results of the lookup. I=20 > think it can be viewed as a normative change to 3263 for dual=20 > stack devices. >=20 > And 3263 suffers from the common problem of using "SHOULD"=20 > widely without any explanation of when it makes sense to=20 > violate the "SHOULD".=20 > This gives people the opportunity to say that implementations=20 > that do otherwise are still compliant. I would be=20 > uncomfortable publishing a new normative RFC that doesn't say=20 > it updates 3263 while mandating behavior that is different=20 > from the SHOULDs of 3263. >=20 > Having said that, I suggest the following as the milestone: >=20 > May 2014 WGLC of procedures to supplement RFC3263 for dual-stack > client and server handling of SIP URIs containing domain=20 > names (PS) >=20 > This assumes that the work will be standards track, but=20 > doesn't say whether or not it will update 3263. I've made the=20 > milestone to be for WGLC, so we take the time for IESG=20 > processing out of the schedule. The date is after the London=20 > meeting but before the Toronto meeting. It is assuming that=20 > we will get much of the work done on the mailing list before=20 > London, thrash out any controversial issues in London, then=20 > do cleanup and WGLC. It is optimistic, but possible if there=20 > isn't a lot if dissent. >=20 > Richard - does this work for you? >=20 > Olle & Gonzalo - does it work for you? >=20 > Thanks, > Paul >=20 >=20 > > Gonzalo > > > > > >> > >> Keith > >> > >>> -----Original Message----- > >>> From: Gonzalo Salgueiro (gsalguei) [mailto:gsalguei@cisco.com] > >>> Sent: 13 December 2013 00:54 > >>> To: DRAGE, Keith (Keith) > >>> Cc: Paul Kyzivat; Gonzalo Salgueiro (gsalguei); SIPCORE=20 > WG; Olle E.=20 > >>> Johansson; Cullen Jennings > >>> Subject: Re: [sipcore] IPv6 in the sip core wg > >>> Importance: High > >>> > >>> (as co-author) > >>> > >>> I'm happy to publish a new version of the document that=20 > makes use of=20 > >>> 2119 language. > >>> > >>> I think we might be trying to over-complicate matters. As stated=20 > >>> earlier, this work is merely an extension to the=20 > procedures in 3263=20 > >>> and should not make the myriad existing deployments=20 > non-compliant to=20 > >>> a core SIP specification. The intent here is only to provide=20 > >>> supplemental best practices that we have learned along the way=20 > >>> through extensive interop testing. To emblazon this point into=20 > >>> everyone's psyche, the next version will not have the=20 > "Updates: 3263=20 > >>> (if approved)" label. > >>> > >>> With this in mind, I propose the following as the milestone text: > >>> > >>> Supplemental procedures for dual-stack server handling of=20 > SIP URIs=20 > >>> containing domain names > >>> > >>> > >>> To your point regarding Vijay, the authors will stay in sync with=20 > >>> him throughout. > >>> > >>> > >>> Cheers, > >>> > >>> Gonzalo > >>> > >>> > >>> > >>> On Dec 12, 2013, at 4:45 PM, DRAGE, Keith (Keith)=20 > >>> wrote: > >>> > >>>> I was losing track of this discussion so I had to go back. > >>>> > >>>> The only document we seem to have on the table at the moment is: > >>>> > >>>> http://www.ietf.org/id/draft-johansson-sip-dual-stack-01.txt > >>>> > >>>> This currently contains no normative provisions (no MUST, > >>> SHOULD, MAY) so it is a bit difficult to judge what the=20 > scope of a=20 > >>> normative document should be. > >>>> > >>>> Could I suggest that before we scope the work and as a > >>> consequence write the milestone, we see another version of the=20 > >>> author draft containing at least the minimum set of normative=20 > >>> requirements the authors think we need. > >>>> > >>>> That may be because it is written in the style of RFC 3263 > >>> which also contains no normative provisions. It might be that in=20 > >>> order to scope this work we actually need a bis version=20 > of RFC 3263,=20 > >>> rather than something that adds some more requirements in=20 > this area. > >>>> > >>>> In response to Cullen, I would say there is another reason > >>> why something should be an update rather than just being=20 > regarded as=20 > >>> an extension. If it contains provisions that all RFC 3263=20 > >>> implementations (or most of) should also implement, and=20 > it is within=20 > >>> the scope of the original RFC, then I believe that may=20 > also justify=20 > >>> and update. But I agree that we need to write the=20 > requirements first=20 > >>> and then do this analysis. > >>>> > >>>> I'd also remind you that Vijay has some comments that the > >>> issue was wider than RFC 3263, so there may be a need to=20 > scope round=20 > >>> that. > >>>> > >>>> None of these comments should be taken as a suggestion that > >>> we should not do the work (I think the issue has been justified),=20 > >>> only that I do not understand the scope and there is not=20 > enough on=20 > >>> the table to judge that. > >>>> > >>>> Keith > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf > >>> Of Gonzalo > >>>>> Salgueiro (gsalguei) > >>>>> Sent: 12 December 2013 19:19 > >>>>> To: Paul Kyzivat > >>>>> Cc: SIPCORE WG; Olle E. Johansson; Gonzalo Salgueiro=20 > (gsalguei);=20 > >>>>> Cullen Jennings > >>>>> Subject: Re: [sipcore] IPv6 in the sip core wg > >>>>> Importance: High > >>>>> > >>>>> > >>>>> On Dec 12, 2013, at 12:59 PM, Paul Kyzivat=20 > > >>>>> wrote: > >>>>> > >>>>>> On 12/12/13 11:59 AM, Mary Barnes wrote: > >>>>>>> The question in my mind becomes how you can word it > >>>>> properly. There > >>>>>>> are already procedures for dual stack, so you can't just say: > >>>>>>> > >>>>>>> Procedures for dual-stack server handling of SIP URIs=20 > containing=20 > >>>>>>> domain names > >>>>>>> > >>>>>>> Any of the adjectives proposed so far "Amended" or=20 > "Updated" or=20 > >>>>>>> others that might seem appropriate, e.g., "Enhanced" imply > >>>>> that the > >>>>>>> existing procedures are being changed or corrected. > >>>>> Although maybe "Enhanced" is > >>>>>>> general enough to not necessarily imply an "Update" to RFC > >>>>> 3263? But, > >>>>>>> then would you be talking about an Informational versus > >>>>> standards track > >>>>>>> document? I think it's usual for milestones to indicate > >>>>> whether the > >>>>>>> work is informational, standards track or BCP. But, if > >>>>> the AD will > >>>>>>> approve the new milestone without that level of > >>>>> specificity, that's > >>>>>>> fine. > >>>>>> > >>>>>> ISTM that we are in a situation where we need to consider > >>>>> the details of the proposed mechanism(s) before deciding if the=20 > >>>>> desired mechanism will be an update or not. So I think it > >>> makes sense > >>>>> to word the milestone to be non-specific about this. > >>>>>> > >>>>>> Maybe its not the term itself that is the problem, but > >>>>> rather what the term references. IOW, is it that we intend to=20 > >>>>> ammend/update/enhance/improve the *procedures*, or the > >>>>> *description* of the procedures? > >>>>>> > >>>>>> IIUC the intent is to clarify the description, and if that > >>>>> is insufficient to get a satisfactory result, then to=20 > update the=20 > >>>>> procedures themselves. > >>>>> > >>>>> So what is the proposed text for the milestone? > >>>>> > >>>>> Gonzalo > >>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> Paul > >>>>>> > >>>>>>> But, I also don't think it's useful for the group to > >>>>> rathole on that > >>>>>>> later in the process and it will definitely cause > >>>>> confusion if the WG > >>>>>>> doesn't have a clear reason why the specific type of > >>> specification > >>>>>>> was selected. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Mary. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Wed, Dec 11, 2013 at 2:49 PM, Paul Kyzivat > >>>>> >>>>>>> > wrote: > >>>>>>> > >>>>>>> Cullen, > >>>>>>> > >>>>>>> Would you be satisfied if the milestone is sufficiently > >>>>> vague that > >>>>>>> we can leave it to the deliverable to decide whether an > >>>>> update is > >>>>>>> needed or not? > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Paul > >>>>>>> > >>>>>>> > >>>>>>> On 12/10/13 6:13 PM, Cullen Jennings wrote: > >>>>>>> > >>>>>>> > >>>>>>> Well from a milestone point of view there is a big > >>>>> difference > >>>>>>> between we need the change an existing RFC (i.e. > >>>>> update) or we > >>>>>>> need to define a new RFC that tells developers=20 > who want to > >>>>>>> implement the new RFC what they need to do. > >>>>>>> > >>>>>>> I think what is needed here is the later item=20 > and not the > >>>>>>> update. I have asked about this a bunch of=20 > times and and I > >>>>>>> always get answers that suggest that a new document > >>>>> is needed > >>>>>>> but it does not need to replace or update 3263. It > >>>>> needs to be a > >>>>>>> new document that provides more detailed advice. If > >>>>> we are going > >>>>>>> to say this updates something, I want to be > >>>>> convinced first that > >>>>>>> there is something that is wrong and needs to be > >>>>> changed. I'm > >>>>>>> fine with the idea that ore detailed specifications > >>>>> are needed > >>>>>>> to do something like happy eyeballs for SIP but I > >>>>> don't think > >>>>>>> that requires an update of 3263. > >>>>>>> > >>>>>>> > >>>>>>> On Dec 10, 2013, at 12:21 PM, Olle E. Johansson > >>>>> >>>>>>> > wrote: > >>>>>>> > >>>>>>> > >>>>>>> On 10 Dec 2013, at 12:14, Cullen Jennings > >>> >>>>>>> > wrote: > >>>>>>> > >>>>>>> > >>>>>>> On Dec 10, 2013, at 9:59 AM, Paul Kyzivat > >>>>>>> >>>>> > > >>>>>>> wrote: > >>>>>>> > >>>>>>> June 2014 Updated procedures for > >>>>> dual-stack server > >>>>>>> handling of SIP > >>>>>>> URIs containing domain names > >>>>>>> > >>>>>>> > >>>>>>> Before we use update, can someone tell me > >>>>> what normative > >>>>>>> text of the current RFCs need to be changed? > >>>>>>> > >>>>>>> > >>>>>>> That's part of the problem, RFC 3263 is not > >>>>> very clear to me > >>>>>>> in indicating what exactly is normative. If > >>> you read our > >>>>>>> draft, you will see that we point to a few > >>> sections that > >>>>>>> clearly says that a UA needs to look up "A or > >>>>> AAAA" records, > >>>>>>> which has been proven wrong and doesn't follow > >>>>> the intention > >>>>>>> of the DNS SRV RFC. If this was unintentional > >>>>> or normative, > >>>>>>> I don't know, but it's written enough times to > >>>>> cause issues > >>>>>>> in implementations and have been copied to > >>>>> other documents, > >>>>>>> like the MSRP RFC. > >>>>>>> > >>>>>>> We need to clarify that a SIP implementation > >>>>> needs to follow > >>>>>>> the DNS SRV RFC and look up all addresses for a > >>>>> host name > >>>>>>> (ipv4, IPv6 or future address families) and > >>>>> test them all > >>>>>>> before moving to the next priority and host. > >>>>>>> > >>>>>>> I've checked this with members of the IETF DNS > >>>>> directorate > >>>>>>> two times now, and they agree with this. > >>>>>>> > >>>>>>> When we clarified/updated/extended/__informed > >>>>> the audience - > >>>>>>> developers - about this, we need to get=20 > down to how to > >>>>>>> connect - serially, in parallell, in reverse > >>>>> random order > >>>>>>> controlled by the phases of the moon or other > >>>>> planets - or > >>>>>>> simply Happy Eyeballs. But even with TCP,=20 > doing happy > >>>>>>> eyeballs like in HTTP would not work unless we > >>>>> have both A > >>>>>>> and AAAA records. RFC 3263 doesn't really > >>> indicate that. > >>>>>>> > >>>>>>> Someone else needs to help out to clarify=20 > to me what is > >>>>>>> really normative in 3263 and what the > >>>>> relationship between > >>>>>>> 3263 and RFC 2782 really is - if RFC 2782 is > >>>>> the normative > >>>>>>> one and RFC 3263 just can be seen as a=20 > happy story that > >>>>>>> points to 2782 without making any normative=20 > changes, we > >>>>>>> might have to clarify that in an informational > >>>>> document and > >>>>>>> move on to connection setup in a dual stack > >>>>> world. If RFC > >>>>>>> 3263 changes the behaviour intended by 2782=20 > and really > >>>>>>> forces a developer to select A or AAAA records, > >>>>> then we need > >>>>>>> to change that behaviour. > >>>>>>> > >>>>>>> Either way, we have work to do in ths wg. > >>>>>>> /O > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> sipcore mailing list > >>>>> sipcore@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > > > > >=20 > = From oej@edvina.net Fri Dec 13 09:32:14 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078A91ADF7E for ; Fri, 13 Dec 2013 09:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdDiNe213Ti3 for ; Fri, 13 Dec 2013 09:32:10 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 82A8F1AD8F4 for ; Fri, 13 Dec 2013 09:32:08 -0800 (PST) Received: from [192.168.101.75] (unknown [72.46.244.148]) by smtp7.webway.se (Postfix) with ESMTPA id 4533093C2A2; Fri, 13 Dec 2013 17:32:00 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" X-Priority: 1 In-Reply-To: <8CADAD8F-0D99-44E0-9BF2-44C087EF3509@cisco.com> Date: Fri, 13 Dec 2013 12:31:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <8CADAD8F-0D99-44E0-9BF2-44C087EF3509@cisco.com> To: "Gonzalo Salgueiro (gsalguei)" X-Mailer: Apple Mail (2.1822) Cc: SIPCORE WG , Olle E Johansson , Cullen Jennings Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 17:32:14 -0000 On 13 Dec 2013, at 12:22, Gonzalo Salgueiro (gsalguei) = wrote: > On Dec 13, 2013, at 11:28 AM, Paul Kyzivat = wrote: >=20 >> On 12/12/13 8:07 PM, Gonzalo Salgueiro (gsalguei) wrote: >>>=20 >>> On Dec 12, 2013, at 8:04 PM, DRAGE, Keith (Keith) = wrote: >>>=20 >>>> Lets look at the specification. >>>>=20 >>>> Your mail seems to being its best to justify it as a BCP, which I = assume is not what you intend. >>>=20 >>> You're right, t is not at all my intent. What I intend is to = provide a stand-alone RFC that provides some useful supplemental = procedures for improved performance in SIP dual-stack environments. >>=20 >> If these procedures are supplemental, will there be anything that = should be normative? >>=20 >> Contrary to what Keith said, I do find normative language in the = draft now. (A SHOULD in the last paragraph of 3.1.) And this is a change = to language in 3263 - changing "A or AAAA" to "A and AAAA". >>=20 >> It is arguable whether this has normative impact on existing = implementations of 3263. 3263 has no normative language regarding "A or = AAAA", but it does have normative language ("SHOULD") about how to use = the results of the lookup. I think it can be viewed as a normative = change to 3263 for dual stack devices. >>=20 >> And 3263 suffers from the common problem of using "SHOULD" widely = without any explanation of when it makes sense to violate the "SHOULD". = This gives people the opportunity to say that implementations that do = otherwise are still compliant. I would be uncomfortable publishing a new = normative RFC that doesn't say it updates 3263 while mandating behavior = that is different from the SHOULDs of 3263. >>=20 >> Having said that, I suggest the following as the milestone: >>=20 >> May 2014 WGLC of procedures to supplement RFC3263 for dual-stack >> client and server handling of SIP URIs containing domain names (PS) >>=20 >> This assumes that the work will be standards track, but doesn't say = whether or not it will update 3263. I've made the milestone to be for = WGLC, so we take the time for IESG processing out of the schedule. The = date is after the London meeting but before the Toronto meeting. It is = assuming that we will get much of the work done on the mailing list = before London, thrash out any controversial issues in London, then do = cleanup and WGLC. It is optimistic, but possible if there isn't a lot if = dissent. >>=20 >> Richard - does this work for you? >>=20 >> Olle & Gonzalo - does it work for you? >=20 > I'm ok with it. =20 +1 /O >=20 > The authors will make some changes to the current version of the = document and submit a new version that hopefully makes clearer the = original intent: a stand-alone RFC offering improved procedures for = dual-stack environments (i.e., does not invalidate or render = non-compliant the myriad of 3263 implementations out there that work = fine with v6). >=20 > Gonzalo >>=20 >> Thanks, >> Paul >>=20 >>=20 >>> Gonzalo >>>=20 >>>=20 >>>>=20 >>>> Keith >>>>=20 >>>>> -----Original Message----- >>>>> From: Gonzalo Salgueiro (gsalguei) [mailto:gsalguei@cisco.com] >>>>> Sent: 13 December 2013 00:54 >>>>> To: DRAGE, Keith (Keith) >>>>> Cc: Paul Kyzivat; Gonzalo Salgueiro (gsalguei); SIPCORE WG; >>>>> Olle E. Johansson; Cullen Jennings >>>>> Subject: Re: [sipcore] IPv6 in the sip core wg >>>>> Importance: High >>>>>=20 >>>>> (as co-author) >>>>>=20 >>>>> I'm happy to publish a new version of the document that makes >>>>> use of 2119 language. >>>>>=20 >>>>> I think we might be trying to over-complicate matters. As >>>>> stated earlier, this work is merely an extension to the >>>>> procedures in 3263 and should not make the myriad existing >>>>> deployments non-compliant to a core SIP specification. The >>>>> intent here is only to provide supplemental best practices >>>>> that we have learned along the way through extensive interop >>>>> testing. To emblazon this point into everyone's psyche, the >>>>> next version will not have the "Updates: 3263 (if approved)" = label. >>>>>=20 >>>>> With this in mind, I propose the following as the milestone text: >>>>>=20 >>>>> Supplemental procedures for dual-stack server handling of SIP >>>>> URIs containing domain names >>>>>=20 >>>>>=20 >>>>> To your point regarding Vijay, the authors will stay in sync >>>>> with him throughout. >>>>>=20 >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Gonzalo >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Dec 12, 2013, at 4:45 PM, DRAGE, Keith (Keith) >>>>> wrote: >>>>>=20 >>>>>> I was losing track of this discussion so I had to go back. >>>>>>=20 >>>>>> The only document we seem to have on the table at the moment is: >>>>>>=20 >>>>>> http://www.ietf.org/id/draft-johansson-sip-dual-stack-01.txt >>>>>>=20 >>>>>> This currently contains no normative provisions (no MUST, >>>>> SHOULD, MAY) so it is a bit difficult to judge what the scope >>>>> of a normative document should be. >>>>>>=20 >>>>>> Could I suggest that before we scope the work and as a >>>>> consequence write the milestone, we see another version of >>>>> the author draft containing at least the minimum set of >>>>> normative requirements the authors think we need. >>>>>>=20 >>>>>> That may be because it is written in the style of RFC 3263 >>>>> which also contains no normative provisions. It might be that >>>>> in order to scope this work we actually need a bis version of >>>>> RFC 3263, rather than something that adds some more >>>>> requirements in this area. >>>>>>=20 >>>>>> In response to Cullen, I would say there is another reason >>>>> why something should be an update rather than just being >>>>> regarded as an extension. If it contains provisions that all >>>>> RFC 3263 implementations (or most of) should also implement, >>>>> and it is within the scope of the original RFC, then I >>>>> believe that may also justify and update. But I agree that we >>>>> need to write the requirements first and then do this analysis. >>>>>>=20 >>>>>> I'd also remind you that Vijay has some comments that the >>>>> issue was wider than RFC 3263, so there may be a need to >>>>> scope round that. >>>>>>=20 >>>>>> None of these comments should be taken as a suggestion that >>>>> we should not do the work (I think the issue has been >>>>> justified), only that I do not understand the scope and there >>>>> is not enough on the table to judge that. >>>>>>=20 >>>>>> Keith >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf >>>>> Of Gonzalo >>>>>>> Salgueiro (gsalguei) >>>>>>> Sent: 12 December 2013 19:19 >>>>>>> To: Paul Kyzivat >>>>>>> Cc: SIPCORE WG; Olle E. Johansson; Gonzalo Salgueiro (gsalguei); >>>>>>> Cullen Jennings >>>>>>> Subject: Re: [sipcore] IPv6 in the sip core wg >>>>>>> Importance: High >>>>>>>=20 >>>>>>>=20 >>>>>>> On Dec 12, 2013, at 12:59 PM, Paul Kyzivat = >>>>>>> wrote: >>>>>>>=20 >>>>>>>> On 12/12/13 11:59 AM, Mary Barnes wrote: >>>>>>>>> The question in my mind becomes how you can word it >>>>>>> properly. There >>>>>>>>> are already procedures for dual stack, so you can't just say: >>>>>>>>>=20 >>>>>>>>> Procedures for dual-stack server handling of SIP URIs = containing >>>>>>>>> domain names >>>>>>>>>=20 >>>>>>>>> Any of the adjectives proposed so far "Amended" or "Updated" = or >>>>>>>>> others that might seem appropriate, e.g., "Enhanced" imply >>>>>>> that the >>>>>>>>> existing procedures are being changed or corrected. >>>>>>> Although maybe "Enhanced" is >>>>>>>>> general enough to not necessarily imply an "Update" to RFC >>>>>>> 3263? But, >>>>>>>>> then would you be talking about an Informational versus >>>>>>> standards track >>>>>>>>> document? I think it's usual for milestones to indicate >>>>>>> whether the >>>>>>>>> work is informational, standards track or BCP. But, if >>>>>>> the AD will >>>>>>>>> approve the new milestone without that level of >>>>>>> specificity, that's >>>>>>>>> fine. >>>>>>>>=20 >>>>>>>> ISTM that we are in a situation where we need to consider >>>>>>> the details of the proposed mechanism(s) before deciding if the >>>>>>> desired mechanism will be an update or not. So I think it >>>>> makes sense >>>>>>> to word the milestone to be non-specific about this. >>>>>>>>=20 >>>>>>>> Maybe its not the term itself that is the problem, but >>>>>>> rather what the term references. IOW, is it that we intend to >>>>>>> ammend/update/enhance/improve the *procedures*, or the >>>>>>> *description* of the procedures? >>>>>>>>=20 >>>>>>>> IIUC the intent is to clarify the description, and if that >>>>>>> is insufficient to get a satisfactory result, then to update the >>>>>>> procedures themselves. >>>>>>>=20 >>>>>>> So what is the proposed text for the milestone? >>>>>>>=20 >>>>>>> Gonzalo >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>>=20 >>>>>>>>> But, I also don't think it's useful for the group to >>>>>>> rathole on that >>>>>>>>> later in the process and it will definitely cause >>>>>>> confusion if the WG >>>>>>>>> doesn't have a clear reason why the specific type of >>>>> specification >>>>>>>>> was selected. >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>> Mary. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Wed, Dec 11, 2013 at 2:49 PM, Paul Kyzivat >>>>>>> >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>> Cullen, >>>>>>>>>=20 >>>>>>>>> Would you be satisfied if the milestone is sufficiently >>>>>>> vague that >>>>>>>>> we can leave it to the deliverable to decide whether an >>>>>>> update is >>>>>>>>> needed or not? >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 12/10/13 6:13 PM, Cullen Jennings wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Well from a milestone point of view there is a big >>>>>>> difference >>>>>>>>> between we need the change an existing RFC (i.e. >>>>>>> update) or we >>>>>>>>> need to define a new RFC that tells developers who want to >>>>>>>>> implement the new RFC what they need to do. >>>>>>>>>=20 >>>>>>>>> I think what is needed here is the later item and not the >>>>>>>>> update. I have asked about this a bunch of times and and I >>>>>>>>> always get answers that suggest that a new document >>>>>>> is needed >>>>>>>>> but it does not need to replace or update 3263. It >>>>>>> needs to be a >>>>>>>>> new document that provides more detailed advice. If >>>>>>> we are going >>>>>>>>> to say this updates something, I want to be >>>>>>> convinced first that >>>>>>>>> there is something that is wrong and needs to be >>>>>>> changed. I'm >>>>>>>>> fine with the idea that ore detailed specifications >>>>>>> are needed >>>>>>>>> to do something like happy eyeballs for SIP but I >>>>>>> don't think >>>>>>>>> that requires an update of 3263. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Dec 10, 2013, at 12:21 PM, Olle E. Johansson >>>>>>> >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 10 Dec 2013, at 12:14, Cullen Jennings >>>>> >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Dec 10, 2013, at 9:59 AM, Paul Kyzivat >>>>>>>>> >>>>>> > >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> June 2014 Updated procedures for >>>>>>> dual-stack server >>>>>>>>> handling of SIP >>>>>>>>> URIs containing domain names >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Before we use update, can someone tell me >>>>>>> what normative >>>>>>>>> text of the current RFCs need to be changed? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> That's part of the problem, RFC 3263 is not >>>>>>> very clear to me >>>>>>>>> in indicating what exactly is normative. If >>>>> you read our >>>>>>>>> draft, you will see that we point to a few >>>>> sections that >>>>>>>>> clearly says that a UA needs to look up "A or >>>>>>> AAAA" records, >>>>>>>>> which has been proven wrong and doesn't follow >>>>>>> the intention >>>>>>>>> of the DNS SRV RFC. If this was unintentional >>>>>>> or normative, >>>>>>>>> I don't know, but it's written enough times to >>>>>>> cause issues >>>>>>>>> in implementations and have been copied to >>>>>>> other documents, >>>>>>>>> like the MSRP RFC. >>>>>>>>>=20 >>>>>>>>> We need to clarify that a SIP implementation >>>>>>> needs to follow >>>>>>>>> the DNS SRV RFC and look up all addresses for a >>>>>>> host name >>>>>>>>> (ipv4, IPv6 or future address families) and >>>>>>> test them all >>>>>>>>> before moving to the next priority and host. >>>>>>>>>=20 >>>>>>>>> I've checked this with members of the IETF DNS >>>>>>> directorate >>>>>>>>> two times now, and they agree with this. >>>>>>>>>=20 >>>>>>>>> When we clarified/updated/extended/__informed >>>>>>> the audience - >>>>>>>>> developers - about this, we need to get down to how to >>>>>>>>> connect - serially, in parallell, in reverse >>>>>>> random order >>>>>>>>> controlled by the phases of the moon or other >>>>>>> planets - or >>>>>>>>> simply Happy Eyeballs. But even with TCP, doing happy >>>>>>>>> eyeballs like in HTTP would not work unless we >>>>>>> have both A >>>>>>>>> and AAAA records. RFC 3263 doesn't really >>>>> indicate that. >>>>>>>>>=20 >>>>>>>>> Someone else needs to help out to clarify to me what = is >>>>>>>>> really normative in 3263 and what the >>>>>>> relationship between >>>>>>>>> 3263 and RFC 2782 really is - if RFC 2782 is >>>>>>> the normative >>>>>>>>> one and RFC 3263 just can be seen as a happy story = that >>>>>>>>> points to 2782 without making any normative changes, = we >>>>>>>>> might have to clarify that in an informational >>>>>>> document and >>>>>>>>> move on to connection setup in a dual stack >>>>>>> world. If RFC >>>>>>>>> 3263 changes the behaviour intended by 2782 and really >>>>>>>>> forces a developer to select A or AAAA records, >>>>>>> then we need >>>>>>>>> to change that behaviour. >>>>>>>>>=20 >>>>>>>>> Either way, we have work to do in ths wg. >>>>>>>>> /O >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> sipcore mailing list >>>>>>> sipcore@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>=20 >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From vkg@bell-labs.com Fri Dec 13 09:35:06 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27AA1AE36F for ; Fri, 13 Dec 2013 09:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNiR2_7ZI9qZ for ; Fri, 13 Dec 2013 09:35:04 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 29BE91ADF7E for ; Fri, 13 Dec 2013 09:35:03 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rBDHYt26009330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 13 Dec 2013 11:34:55 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id rBDHYt4n022256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 13 Dec 2013 11:34:55 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id rBDHYt2t028523 for ; Fri, 13 Dec 2013 11:34:55 -0600 (CST) Message-ID: <52AB454F.6020105@bell-labs.com> Date: Fri, 13 Dec 2013 11:35:11 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <7886ADB0-BDB3-4D15-800B-AAEB34713547@iii.ca> <52AB353A.9030600@bell-labs.com> <52AB41A2.6070700@alum.mit.edu> In-Reply-To: <52AB41A2.6070700@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 17:35:06 -0000 On 12/13/2013 11:19 AM, Paul Kyzivat wrote: [...] > It is a normative statement to use a particular API function as an > alternative to a different API function. But there was never a > requirement to use "gethostbyname", so the "instead" isn't meaningful, > and we shouldn't be requiring use of any particular API functions. It > would make a lot more sense if it had a MUST on the algorithms in 3484. Paul: No doubt true from specifying text in a standards-track RFC, but I suspect that most implementors are much more familiar with the differences between gethostbyname() and getaddrinfo() than they are with the arcana that getaddrinfo() implements rfc3484. [...] > At the very least, we should include that in the scope of the work. > Here is a revised milestone: > > May 2014 WGLC of procedures to supplement RFC3263 and RFC6157 for > dual-stack client and server handling of SIP URIs containing domain > names (PS) Works for me. Thanks for your time, Paul. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From mary.ietf.barnes@gmail.com Fri Dec 13 09:43:21 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD9A1AE6D4 for ; Fri, 13 Dec 2013 09:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxa9KrnEWyVJ for ; Fri, 13 Dec 2013 09:43:19 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 652201AE37B for ; Fri, 13 Dec 2013 09:43:19 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x12so2238530wgg.16 for ; Fri, 13 Dec 2013 09:43:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RKIN+oE9X46/s13oW0jbvlzE7q73F6LDCpudXZ3sBlQ=; b=kiQhy6KeAVuky++z8F3bnAsCmc5mvtrp9Jgax9TCVL8F4n9rwUJrJ3hJuAlq3eLxYf /OmAL2SMLda4mFKObfxevnOmvmWKs45cESz/T/YKCDvrQ+Ce12rqxgtoPztvA4QiKw+5 5lIJTNnIbeVGGvfKFMHVak8MOeJ+ZsAXYYjXDUwOQKj74u8Mg9IQcolLjv0XYpVlAbqn jvmEBVv2d7axeHg1++HowRnctbvYtCIhzQn8/9fC1kVz0LXON14FGI1KwKFtVOsN4fG7 9U6jWNT16vz+0y8omEesWDNLhqWkNkevmO3zbB5GUaNFFQCJu23ScpeEDEuvPmkIQ/vm dg3A== MIME-Version: 1.0 X-Received: by 10.180.92.230 with SMTP id cp6mr9921536wib.0.1386956592576; Fri, 13 Dec 2013 09:43:12 -0800 (PST) Received: by 10.216.172.9 with HTTP; Fri, 13 Dec 2013 09:43:12 -0800 (PST) In-Reply-To: <52AB35A6.8030701@alum.mit.edu> References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> Date: Fri, 13 Dec 2013 11:43:12 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=f46d043892cf04ff0c04ed6dff8d Cc: "Olle E. Johansson" , SIPCORE WG , "Gonzalo Salgueiro \(gsalguei\)" , Cullen Jennings Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 17:43:22 -0000 --f46d043892cf04ff0c04ed6dff8d Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 13, 2013 at 10:28 AM, Paul Kyzivat wrote: > On 12/12/13 8:07 PM, Gonzalo Salgueiro (gsalguei) wrote: > >> >> On Dec 12, 2013, at 8:04 PM, DRAGE, Keith (Keith) < >> keith.drage@alcatel-lucent.com> wrote: >> >> Lets look at the specification. >>> >>> Your mail seems to being its best to justify it as a BCP, which I assume >>> is not what you intend. >>> >> >> You're right, t is not at all my intent. What I intend is to provide a >> stand-alone RFC that provides some useful supplemental procedures for >> improved performance in SIP dual-stack environments. >> > > If these procedures are supplemental, will there be anything that should > be normative? > > Contrary to what Keith said, I do find normative language in the draft > now. (A SHOULD in the last paragraph of 3.1.) And this is a change to > language in 3263 - changing "A or AAAA" to "A and AAAA". > > It is arguable whether this has normative impact on existing > implementations of 3263. 3263 has no normative language regarding "A or > AAAA", but it does have normative language ("SHOULD") about how to use the > results of the lookup. I think it can be viewed as a normative change to > 3263 for dual stack devices. > > And 3263 suffers from the common problem of using "SHOULD" widely without > any explanation of when it makes sense to violate the "SHOULD". This gives > people the opportunity to say that implementations that do otherwise are > still compliant. I would be uncomfortable publishing a new normative RFC > that doesn't say it updates 3263 while mandating behavior that is different > from the SHOULDs of 3263. > > Having said that, I suggest the following as the milestone: > > May 2014 WGLC of procedures to supplement RFC3263 for dual-stack > client and server handling of SIP URIs containing domain names (PS) > > This assumes that the work will be standards track, but doesn't say > whether or not it will update 3263. I've made the milestone to be for WGLC, > so we take the time for IESG processing out of the schedule. [MB] What is the point of taking the time for IESG processing out of the schedule? I don't see a problem with stating two milestones, but milestones in a charter always reflect the target completion of work within the WG (and that's NOT WGLC). There was a period of time where the ADs wanted to see the two milestones, so that's certainly not an unacceptable thing to do, but not listing the IESG milestone isn't normal procedure. RFC 2418 explains some of this. As I said in a previous note, in my experience, two months is an optimistic average for the time between completing a 1st WGLC and a doc going to the IESG. [/MB] > The date is after the London meeting but before the Toronto meeting. It is > assuming that we will get much of the work done on the mailing list before > London, thrash out any controversial issues in London, then do cleanup and > WGLC. It is optimistic, but possible if there isn't a lot if dissent. > > Richard - does this work for you? > > Olle & Gonzalo - does it work for you? > > Thanks, > Paul Note, I've delated the remainder of this thread as it's gotten insanely long. [MB] > > > >> --f46d043892cf04ff0c04ed6dff8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Dec 13, 2013 at 10:28 AM, Paul Kyzivat &l= t;pkyzivat@alum.= mit.edu> wrote:
On 12/12/13 8:07 PM, Gonza= lo Salgueiro (gsalguei) wrote:

On Dec 12, 2013, at 8:04 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.<= u>com> wrote:

Lets look at the specification.

Your mail seems to being its best to justify it as a BCP, which I assume is= not what you intend.

You're right, t is not at all my intent. =A0What I intend is to provide= a stand-alone RFC that provides some useful supplemental procedures for im= proved performance in SIP dual-stack environments.

If these procedures are supplemental, will there be anything that should be= normative?

Contrary to what Keith said, I do find normative language in the draft now.= (A SHOULD in the last paragraph of 3.1.) And this is a change to language = in 3263 - changing "A or AAAA" to "A and AAAA".

It is arguable whether this has normative impact on existing implementation= s of 3263. 3263 has no normative language regarding "A or AAAA", = but it does have normative language ("SHOULD") about how to use t= he results of the lookup. I think it can be viewed as a normative change to= 3263 for dual stack devices.

And 3263 suffers from the common problem of using "SHOULD" widely= without any explanation of when it makes sense to violate the "SHOULD= ". This gives people the opportunity to say that implementations that = do otherwise are still compliant. I would be uncomfortable publishing a new= normative RFC that doesn't say it updates 3263 while mandating behavio= r that is different from the SHOULDs of 3263.

Having said that, I suggest the following as the milestone:

=A0 =A0 May 2014 =A0WGLC of procedures to supplement RFC3263 for dual-stack=
=A0 =A0 client and server handling of SIP URIs containing domain names (PS)=

This assumes that the work will be standards track, but doesn't say whe= ther or not it will update 3263. I've made the milestone to be for WGLC= , so we take the time for IESG processing out of the schedule.
[MB] What is the point of taking the time for IESG processing out of t= he schedule? =A0 I don't see a problem with stating two milestones, but= milestones in a charter always reflect the target completion of work withi= n the WG (and that's NOT WGLC). =A0There was a period of time where the= ADs wanted to see the two milestones, so that's certainly not an unacc= eptable thing to do, but not listing the IESG milestone isn't normal pr= ocedure. =A0RFC 2418 explains some of this. =A0 As I said in a previous not= e, in my experience, two months is an optimistic average for the time betwe= en completing a 1st WGLC and a doc going to the IESG. =A0 [/MB]
=A0
The date is after the London m= eeting but before the Toronto meeting. It is assuming that we will get much= of the work done on the mailing list before London, thrash out any controv= ersial issues in London, then do cleanup and WGLC. It is optimistic, but po= ssible if there isn't a lot if dissent.

Richard - does this work for you?

Olle & Gonzalo - does it work for you?

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

Note, I've delated= the remainder of this thread as it's gotten insanely long.=A0
[MB]=A0



--f46d043892cf04ff0c04ed6dff8d-- From fluffy@iii.ca Mon Dec 16 11:31:03 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6E71A1F4C for ; Mon, 16 Dec 2013 11:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rOvsuSzl1Tw for ; Mon, 16 Dec 2013 11:31:01 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA0E1A1F3D for ; Mon, 16 Dec 2013 11:31:01 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F10E050A86; Mon, 16 Dec 2013 14:30:59 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Cullen Jennings In-Reply-To: Date: Mon, 16 Dec 2013 12:30:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <7886ADB0-BDB3-4D15-800B-AAEB34713547@iii.ca> To: Olle E. Johansson X-Mailer: Apple Mail (2.1510) Cc: SIPCORE WG , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 19:31:03 -0000 On Dec 13, 2013, at 9:17 AM, Olle E. Johansson wrote: > The problem is really that RFC 3263 repeats "A or AAAA" - which means = that if we follow RFC 3263 verbatim we won't have both IPv4 and IPv6 = addresses to connect to. I have not claimed that it talks about how we = connect. A or B does not mean you are not allowed to do both From fluffy@cisco.com Mon Dec 16 11:33:09 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4736C1A82E2 for ; Mon, 16 Dec 2013 11:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.039 X-Spam-Level: X-Spam-Status: No, score=-110.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NykbL1yOjnwZ for ; Mon, 16 Dec 2013 11:33:08 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id D2D081A1F4C for ; Mon, 16 Dec 2013 11:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=429; q=dns/txt; s=iport; t=1387222387; x=1388431987; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hj1aj9Pt3HkGHdh+74h3c6zHiMDMsmBkmZc4Q+B3nhY=; b=Z/BysHw6MTm5mdzQncRY9H6NqNwcL3nsauVP1X1SQGy8K9nGuRyaP5Bb lWxCg+5vDNsu4NXzQ1sfujZ/8z6jfIUWrGyjt8Zk8T4kNefPZojsOHN+n +hXAXEVl3pIhAk58HVvG2zjW/KEcPrREK9luSquFLUidymqSbQPLm0+eT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAC9Ur1KtJV2c/2dsb2JhbABZDoJ8gQ24cYEnFnSCJQEBAQMBeQULAgEIDjgyJQIEDgWHfAjIHReOZjMHgyOBEwEDiQuPC5IUgms/gio X-IronPort-AV: E=Sophos;i="4.95,496,1384300800"; d="scan'208";a="7158244" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 16 Dec 2013 19:33:06 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rBGJX6ng026606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Dec 2013 19:33:07 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.231]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Mon, 16 Dec 2013 13:33:06 -0600 From: "Cullen Jennings (fluffy)" To: Paul Kyzivat Thread-Topic: [sipcore] IPv6 in the sip core wg Thread-Index: AQHO+pWkQom0+Bv1tEynMa4RoCRZsQ== Date: Mon, 16 Dec 2013 19:33:05 +0000 Message-ID: <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> In-Reply-To: <52AB35A6.8030701@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <07D7965DCFB0474FAF99189FB2632422@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Olle E. Johansson" , SIPCORE WG , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 19:33:09 -0000 On Dec 13, 2013, at 9:28 AM, Paul Kyzivat wrote: > Having said that, I suggest the following as the milestone: >=20 > May 2014 WGLC of procedures to supplement RFC3263 for dual-stack > client and server handling of SIP URIs containing domain names (PS) Good with me. And if you want to change "WGLC of" to "Request publication o= f" that seems like it would fix the point Mary raised. From pkyzivat@alum.mit.edu Mon Dec 16 11:49:03 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00ED11AC4A3 for ; Mon, 16 Dec 2013 11:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ek0NFTdL009b for ; Mon, 16 Dec 2013 11:49:02 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id DAB631A1F3F for ; Mon, 16 Dec 2013 11:49:01 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta12.westchester.pa.mail.comcast.net with comcast id 2D6F1n0021vXlb85CKp1pT; Mon, 16 Dec 2013 19:49:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id 2Kp01n00n3ZTu2S3dKp0LA; Mon, 16 Dec 2013 19:49:01 +0000 Message-ID: <52AF592C.3050000@alum.mit.edu> Date: Mon, 16 Dec 2013 14:49:00 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <7886ADB0-BDB3-4D15-800B-AAEB34713547@iii.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1387223341; bh=SYaQjH+4MAUvHf/BNqa9zX8ePr5Go9Yq+5nrUVIKTag=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dlhQxo60ZJhOg9Dzn1eLMWbMleK3poK4WIp09Zv0JzU0zjCrye94xYMY99D4Aozax jN4qFTpbbcwCPnxPToIHR3HWcMMlMirexCAK5rvPJ7NwTzdo5i8J2RfRlSsaMN1Lxq ugGFA0MmKp6yshVnX+drRURG6cs25jOirKTboKySXf9prACQKVeFeTlJazsuyHxdw4 Zi5Xrbhv3f41F9OoS/Svo5CEYldLv5tEN11HKnvGl5IBqTrpgowNHvFeTY1MSsF72d t4kF3eRoj/6tDtZIWT2/sdpNEE6oEIOvYAArwyy6Fl9RdcH2I8pD5RC8WZu4zCqnR8 5igYByZFisdkw== Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 19:49:03 -0000 On 12/16/13 2:30 PM, Cullen Jennings wrote: > > On Dec 13, 2013, at 9:17 AM, Olle E. Johansson wrote: > >> The problem is really that RFC 3263 repeats "A or AAAA" - which means that if we follow RFC 3263 verbatim we won't have both IPv4 and IPv6 addresses to connect to. I have not claimed that it talks about how we connect. > > A or B does not mean you are not allowed to do both English is vague about this. It can be read as either OR or XOR. And that is just when considering use by native English speakers. When you factor in people for whom English is not native, it is probably more dubious which it means. If there is any concern then we should ensure that this is clarified. Whether that requires an update may still be controversial. But ISTM if we are going to produce a standards track RFC anyway, that it would be better to be sure by declaring it to be an update. If your implementation is already consistent with the clarification, then you can immediately claim conformance to it. But advertising it as an update may provoke some to discover that they aren't consistent with the clarified intent. That will cause them some work to conform, but will also fix problems. Thanks, Paul From pkyzivat@alum.mit.edu Mon Dec 16 11:51:02 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E7E1AC82B for ; Mon, 16 Dec 2013 11:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1bKRBIZKwRR for ; Mon, 16 Dec 2013 11:51:01 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id BC40A1AC85E for ; Mon, 16 Dec 2013 11:51:00 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta15.westchester.pa.mail.comcast.net with comcast id 2Fbu1n0061c6gX85FKqzjS; Mon, 16 Dec 2013 19:50:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id 2Kqy1n00t3ZTu2S3jKqzw4; Mon, 16 Dec 2013 19:50:59 +0000 Message-ID: <52AF59A2.6000604@alum.mit.edu> Date: Mon, 16 Dec 2013 14:50:58 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Mary Barnes References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1387223459; bh=rKwuhtqUpxpYAAoWjeXlNMrE+RyZ1zkFMxBUOB0ZQhU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RoHtdIOMSX+ZSsNgno3uPd6W7gofzFNm1dyOg+mkhlUBdu/ZPAFORFUKNJVeQ6joz fPEBQMuG9/yWuFbth4z+Yeh8AZfa5QJ4efthOvdg6Vw6FHaEee5EsXyA9SNY+at2yq ZbhLBE5PvdeuGC6DjV8Zp4iHsgNJvde/gRdX2fB0jcQ/K/abS/yqCimZOx0Z/RIGWR Ly0dUVq3nOuYs6An8NWiOdhJfcqWbuojn9oh2H6kWSgbcCoxN5zFhj75ApnWDx2MB1 qjR8Wn5BE0jxWLP+Mi6OKsL6z6bAyyZSgOqKNyBHz5GkOCys0D06pwa24GNe3DSotc DwiWsFFmT06AA== Cc: "Olle E. Johansson" , SIPCORE WG , "Gonzalo Salgueiro \(gsalguei\)" , Cullen Jennings Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 19:51:02 -0000 On 12/13/13 12:43 PM, Mary Barnes wrote: > > > > On Fri, Dec 13, 2013 at 10:28 AM, Paul Kyzivat > wrote: > > On 12/12/13 8:07 PM, Gonzalo Salgueiro (gsalguei) wrote: > > > On Dec 12, 2013, at 8:04 PM, DRAGE, Keith (Keith) > > wrote: > > Lets look at the specification. > > Your mail seems to being its best to justify it as a BCP, > which I assume is not what you intend. > > > You're right, t is not at all my intent. What I intend is to > provide a stand-alone RFC that provides some useful supplemental > procedures for improved performance in SIP dual-stack environments. > > > If these procedures are supplemental, will there be anything that > should be normative? > > Contrary to what Keith said, I do find normative language in the > draft now. (A SHOULD in the last paragraph of 3.1.) And this is a > change to language in 3263 - changing "A or AAAA" to "A and AAAA". > > It is arguable whether this has normative impact on existing > implementations of 3263. 3263 has no normative language regarding "A > or AAAA", but it does have normative language ("SHOULD") about how > to use the results of the lookup. I think it can be viewed as a > normative change to 3263 for dual stack devices. > > And 3263 suffers from the common problem of using "SHOULD" widely > without any explanation of when it makes sense to violate the > "SHOULD". This gives people the opportunity to say that > implementations that do otherwise are still compliant. I would be > uncomfortable publishing a new normative RFC that doesn't say it > updates 3263 while mandating behavior that is different from the > SHOULDs of 3263. > > Having said that, I suggest the following as the milestone: > > May 2014 WGLC of procedures to supplement RFC3263 for dual-stack > client and server handling of SIP URIs containing domain names (PS) > > This assumes that the work will be standards track, but doesn't say > whether or not it will update 3263. I've made the milestone to be > for WGLC, so we take the time for IESG processing out of the schedule. > > [MB] What is the point of taking the time for IESG processing out of the > schedule? I don't see a problem with stating two milestones, but > milestones in a charter always reflect the target completion of work > within the WG (and that's NOT WGLC). There was a period of time where > the ADs wanted to see the two milestones, so that's certainly not an > unacceptable thing to do, but not listing the IESG milestone isn't > normal procedure. RFC 2418 explains some of this. As I said in a > previous note, in my experience, two months is an optimistic average for > the time between completing a 1st WGLC and a doc going to the IESG. [/MB] I will defer to your deeper knowledge of this. > The date is after the London meeting but before the Toronto meeting. > It is assuming that we will get much of the work done on the mailing > list before London, thrash out any controversial issues in London, > then do cleanup and WGLC. It is optimistic, but possible if there > isn't a lot if dissent. > > Richard - does this work for you? > > Olle & Gonzalo - does it work for you? > > Thanks, > Paul > > > Note, I've delated the remainder of this thread as it's gotten insanely > long. > [MB] > > > > From pkyzivat@alum.mit.edu Mon Dec 16 11:54:58 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E16D1AC82B for ; Mon, 16 Dec 2013 11:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNkPjGFRz7cC for ; Mon, 16 Dec 2013 11:54:57 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id AEE7E1A1F3F for ; Mon, 16 Dec 2013 11:54:57 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta02.westchester.pa.mail.comcast.net with comcast id 2D2N1n0020vyq2s51Kuw9S; Mon, 16 Dec 2013 19:54:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id 2Kuw1n00b3ZTu2S3RKuwY6; Mon, 16 Dec 2013 19:54:56 +0000 Message-ID: <52AF5A90.9020700@alum.mit.edu> Date: Mon, 16 Dec 2013 14:54:56 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <7886ADB0-BDB3-4D15-800B-AAEB34713547@iii.ca> <52AB353A.9030600@bell-labs.com> <52AB41A2.6070700@alum.mit.edu> <52AB454F.6020105@bell-labs.com> In-Reply-To: <52AB454F.6020105@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1387223696; bh=1K4c5ut6Xx5aRJ/g/RC/4h3AQKTw/YvVSQ0p+QDRyWk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=IOIgZxOQfvtXSnmLadqllmIpqOqzZyJEP9ujHyb7Xqd0VWoyBg9mtLatwmcemdZpj 0uXBZ2pGB7L24S2JRhsFTMNAHZR/rT24cUtY6wMIgDEd+qaS1M4Kh2rhH3pcEcXGri A6OYgrEXbTUMHcz/wn8H80SxzRAiBvtsCnf4QgEm/QlgRqZRcT+gr5qUC/4KlRdOnh /03+N6qaikR933SCeI7yQfQDes7uXHLCX5lIbXdtbMa+kgP73nIn/KwDWRMpj7plIf 66hGn2AQTp8NoailIAp6GwqD9Wdq2K8ENwqx2Ex4Bb30XLwCjarHviK5w4dNm1xgqD pkcZc922CU3Qw== Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 19:54:58 -0000 On 12/13/13 12:35 PM, Vijay K. Gurbani wrote: > On 12/13/2013 11:19 AM, Paul Kyzivat wrote: > [...] >> It is a normative statement to use a particular API function as an >> alternative to a different API function. But there was never a >> requirement to use "gethostbyname", so the "instead" isn't meaningful, >> and we shouldn't be requiring use of any particular API functions. It >> would make a lot more sense if it had a MUST on the algorithms in 3484. > > Paul: No doubt true from specifying text in a standards-track RFC, but > I suspect that most implementors are much more familiar with the > differences between gethostbyname() and getaddrinfo() than they > are with the arcana that getaddrinfo() implements rfc3484. I would not object to this as an implementation note. But it doesn't seem like a good way to state the normative requirement. Thanks, Paul > [...] >> At the very least, we should include that in the scope of the work. >> Here is a revised milestone: >> >> May 2014 WGLC of procedures to supplement RFC3263 and RFC6157 for >> dual-stack client and server handling of SIP URIs containing domain >> names (PS) > > Works for me. Thanks for your time, Paul. > > Cheers, > > - vijay From pkyzivat@alum.mit.edu Mon Dec 16 12:01:19 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72D71ADBD0 for ; Mon, 16 Dec 2013 12:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgCKWZFMlmQm for ; Mon, 16 Dec 2013 12:01:18 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id C57CC1ADEB4 for ; Mon, 16 Dec 2013 12:01:17 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta10.westchester.pa.mail.comcast.net with comcast id 2Kbd1n0041uE5Es5AL1HCZ; Mon, 16 Dec 2013 20:01:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id 2L1G1n00N3ZTu2S3cL1Gtq; Mon, 16 Dec 2013 20:01:17 +0000 Message-ID: <52AF5C0C.9000206@alum.mit.edu> Date: Mon, 16 Dec 2013 15:01:16 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> In-Reply-To: <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1387224077; bh=PmZZJRuiJ9SqjgEujxakJrKnF0QYJ9JPdFgMHt+oXUU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SbEvhORCNLCLFz48pkGj/q0yy2hzvsbUZ9OuTsTJP1GOEptLF/ako8nd+PhJH7aBI 9OCQ33lt2SjRSx6STrbW9gQPlIYEL+CX1SWdVFcB45bOaQbt3ZJd7T6pdQ6o/j31ZN XfFuxPvQ6DGWmDAkPv4J1yDamMis4HgLjJSgc7Oy2p+R6hvvmcKEBMC8L8Zr8pCqoL vdF+njDRYHfTX+38EKDLtxU0oPydV8s/OHF8q23YJcZ5ycudL1qmx2NPA8xVGE2fQF u5xSwtVHads5D8ME099hPHab0jKoFZbP+pO6IfOsjQRCSpgrFfpSbWeJEMJClsfwo1 2pjRDF6ZGd7qg== Cc: "Olle E. Johansson" , SIPCORE WG , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 20:01:19 -0000 On 12/16/13 2:33 PM, Cullen Jennings (fluffy) wrote: > > On Dec 13, 2013, at 9:28 AM, Paul Kyzivat wrote: > >> Having said that, I suggest the following as the milestone: >> >> May 2014 WGLC of procedures to supplement RFC3263 for dual-stack >> client and server handling of SIP URIs containing domain names (PS) > > Good with me. And if you want to change "WGLC of" to "Request publication of" that seems like it would fix the point Mary raised. OK. Latest candidate is: June 2014 Request publication of procedures to supplement RFC3263 for dual-stack client and server handling of SIP URIs containing domain names (PS) (I put back the extra month for Mary.) Richard - does this work for you? Thanks, Paul From rlb@ipv.sx Mon Dec 16 12:03:41 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF95F1A1F4C for ; Mon, 16 Dec 2013 12:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zl60DQPljoDI for ; Mon, 16 Dec 2013 12:03:40 -0800 (PST) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id EE99D1A1F33 for ; Mon, 16 Dec 2013 12:03:39 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id i4so5522693oah.22 for ; Mon, 16 Dec 2013 12:03:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uW0KnPBPFs5eLfM4P9eafBMK082O5FZo+L7di3HcRYg=; b=SJpIwo/5yju7Gtb45Is9GFA+SOj0cqIPhfIpnZLydx4usYYQTNHhdDBQPvXhjK2IlK I1R2CXponz956Ey7qv2v27IBZnlDRgYnv11lR28JmpNSadmQ2szRIB5BfdaIxuQOE6cY hzL9IBUnPONOshneObvxKcqm/IZBgUWJseJGYA0JKkJLGYBedQrZ6dvwW+0EUJin59l3 GPLWQhBJNs5jNE7n0KVaJzlX9ahacB1ztzxXF4ZFxDWe2d/I8Iklbb74SbwGkusenQ17 uFyoa1cdz4KvRe+cbReXl7MA+Bs6JYUa4nINM5zw7wAWL5zZKnKDGQvb4tC4LPz2i8C1 cYyA== X-Gm-Message-State: ALoCoQnM69KKbYhD7LxuTtbBhWnWCbOTkBhFj5MLE01md2jHer14bHHZpy68gjUbhVU2tSqXYdFa MIME-Version: 1.0 X-Received: by 10.182.92.231 with SMTP id cp7mr6426obb.82.1387224219170; Mon, 16 Dec 2013 12:03:39 -0800 (PST) Received: by 10.60.54.65 with HTTP; Mon, 16 Dec 2013 12:03:39 -0800 (PST) In-Reply-To: <52AF5C0C.9000206@alum.mit.edu> References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> Date: Mon, 16 Dec 2013 15:03:39 -0500 Message-ID: From: Richard Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11c302ccced1df04edac4e39 Cc: "Cullen Jennings \(fluffy\)" , SIPCORE WG , "Olle E. Johansson" , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 20:03:42 -0000 --001a11c302ccced1df04edac4e39 Content-Type: text/plain; charset=ISO-8859-1 Sounds good to me, though a couple of extra months might not hurt, just in case. --Richard On Mon, Dec 16, 2013 at 3:01 PM, Paul Kyzivat wrote: > On 12/16/13 2:33 PM, Cullen Jennings (fluffy) wrote: > >> >> On Dec 13, 2013, at 9:28 AM, Paul Kyzivat wrote: >> >> Having said that, I suggest the following as the milestone: >>> >>> May 2014 WGLC of procedures to supplement RFC3263 for dual-stack >>> client and server handling of SIP URIs containing domain names (PS) >>> >> >> Good with me. And if you want to change "WGLC of" to "Request publication >> of" that seems like it would fix the point Mary raised. >> > > OK. Latest candidate is: > > June 2014 Request publication of procedures to supplement RFC3263 > > for dual-stack client and server handling of SIP URIs containing > domain names (PS) > > (I put back the extra month for Mary.) > > > Richard - does this work for you? > > Thanks, > Paul > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a11c302ccced1df04edac4e39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sounds good to me, though a couple of extra months might n= ot hurt, just in case.
--Richard
=

On Mon, Dec 16, 2013 at 3:01 PM, Paul Ky= zivat <pkyzivat@alum.mit.edu> wrote:
On 12/16/13 2:33 PM, Culle= n Jennings (fluffy) wrote:

On Dec 13, 2013, at 9:28 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

Having said that, I suggest the following as the milestone:

=A0 =A0 May 2014 =A0WGLC of procedures to supplement RFC3263 for dual-stack=
=A0 =A0 client and server handling of SIP URIs containing domain names (PS)=

Good with me. And if you want to change "WGLC of" to "Reques= t publication of" that seems like it would fix the point Mary raised.<= br>

OK. Latest candidate is:

=A0 =A0 June 2014 =A0Request publication of procedures to supplement RFC326= 3

=A0 =A0 for dual-stack client and server handling of SIP URIs containing =A0 =A0 domain names (PS)

(I put back the extra month for Mary.)


Richard - does this work for you?

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul




_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--001a11c302ccced1df04edac4e39-- From vkg@bell-labs.com Mon Dec 16 12:13:17 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25AB1AD6C1 for ; Mon, 16 Dec 2013 12:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4H0rCHlostge for ; Mon, 16 Dec 2013 12:13:15 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id B48261AD791 for ; Mon, 16 Dec 2013 12:13:13 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id rBGKD6c9011517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Dec 2013 14:13:07 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id rBGKD6E6005255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Dec 2013 14:13:06 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id rBGKD6KZ021342; Mon, 16 Dec 2013 14:13:06 -0600 (CST) Message-ID: <52AF5EE5.1030609@bell-labs.com> Date: Mon, 16 Dec 2013 14:13:25 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Paul Kyzivat , "Cullen Jennings (fluffy)" References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> In-Reply-To: <52AF5C0C.9000206@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: SIPCORE WG , "Olle E. Johansson" , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 20:13:18 -0000 On 12/16/2013 02:01 PM, Paul Kyzivat wrote: > OK. Latest candidate is: > > June 2014 Request publication of procedures to supplement RFC3263 > for dual-stack client and server handling of SIP URIs containing > domain names (PS) Wait ... Sorry, I thought we had agreed to [1] May 2014 WGLC of procedures to supplement RFC3263 and RFC6157 for dual-stack client and server handling of SIP URIs containing domain names (PS) with s/May/June No? [1] http://www.ietf.org/mail-archive/web/sipcore/current/msg05890.html Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From pkyzivat@alum.mit.edu Mon Dec 16 15:03:20 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A851ADF73 for ; Mon, 16 Dec 2013 15:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmnuz7IW1kmC for ; Mon, 16 Dec 2013 15:03:19 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8831ADF7F for ; Mon, 16 Dec 2013 15:03:19 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta10.westchester.pa.mail.comcast.net with comcast id 2MBh1n0081ei1Bg5AP3JzZ; Mon, 16 Dec 2013 23:03:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id 2P3H1n00Q3ZTu2S3kP3HQB; Mon, 16 Dec 2013 23:03:18 +0000 Message-ID: <52AF86B5.7030706@alum.mit.edu> Date: Mon, 16 Dec 2013 18:03:17 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Vijay K. Gurbani" , "Cullen Jennings (fluffy)" References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> <52AF5EE5.1030609@bell-labs.com> In-Reply-To: <52AF5EE5.1030609@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1387234998; bh=85yVvoaOFp1ItZ9V94nkh7T0zBEYfkrkyZgJS5+10tg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=IFbPvAgTGkGO7CZXrtQBdA1xx9ekq9tR0p2opbKBpqmqmWUqkk6dV7ibZOlFA7dD4 5Z+PyJD2LoPytjpr9NAJR17cGPTsHBelztZztDrIP71BLAJ3NjPJcQKylFP1+Cun9s +LnFd52U0ahWZc5etGv7Vj0YoDUNSqnpbuPujsvZlB4fbHGAePUebl0wjamNuCU3pb Wl5ZuhYkvstl3JDJ5Na4K4JoZfFP89WO1C0aJmAo8FoRZqexqsKCeFlxOP22eeqZCL MfHpV6hSeVnKs0fwOJE6IQ3rDd0/hBbs4PF4CZUrftHIVXZ6Ot1d7768hvsLCGCr3v VDtePpUeJNTTQ== Cc: SIPCORE WG , "Olle E. Johansson" , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 23:03:20 -0000 On 12/16/13 3:13 PM, Vijay K. Gurbani wrote: > On 12/16/2013 02:01 PM, Paul Kyzivat wrote: >> OK. Latest candidate is: >> >> June 2014 Request publication of procedures to supplement RFC3263 >> for dual-stack client and server handling of SIP URIs containing >> domain names (PS) > > Wait ... Sorry, I thought we had agreed to [1] > > May 2014 WGLC of procedures to supplement RFC3263 and RFC6157 for > dual-stack client and server handling of SIP URIs containing domain > names (PS) Oh, sorry. Trying again - merge of those two: June 2014 Request publication of procedures to supplement RFC3263 and RFC6157 for dual-stack client and server handling of SIP URIs containing domain names (PS) Is that ok Vijay? Any other complaints? Thanks, Paul From mary.ietf.barnes@gmail.com Mon Dec 16 15:07:54 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57D41ADF84 for ; Mon, 16 Dec 2013 15:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YiSNyvOBmex for ; Mon, 16 Dec 2013 15:07:52 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9A63F1ADF73 for ; Mon, 16 Dec 2013 15:07:52 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id n12so5244551wgh.33 for ; Mon, 16 Dec 2013 15:07:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DIaWsxgxWlvC60y8nPD1v2yFDKaPUUpfNgIdVwAJ32k=; b=G8gHGVyIIGafUSKNtNGTyDkCE+BrMawNHn5eSrc5uwzyGBgTQDv6pt04sXxmSJQCCX gALufg9WfNbHLMhew/xdTB6JIeQPGxP7KlDoTuPNKcsjWoccNFJiXCCulpJTLLoUSmhw IlEDvvDrqcR9adETXNobkB0P51ePzca+rXNveEkYlQnF66kY7Dc2iw0+rlfBSU1k1j0O Ca+YbDpOfjj6qaUZsBBRK2xOds1tMZ2NaXd71FBJZM91nO1oo+37sPgCdh/ZXvZhHizr VNEkjAQJn//+z30p7D3bvMrdLNp2U7Y2f70vA/ZCPskYJFldgJZanJgy8uz3ut4foGRB UlTQ== MIME-Version: 1.0 X-Received: by 10.194.185.113 with SMTP id fb17mr15028387wjc.29.1387235271210; Mon, 16 Dec 2013 15:07:51 -0800 (PST) Received: by 10.216.172.9 with HTTP; Mon, 16 Dec 2013 15:07:51 -0800 (PST) In-Reply-To: <52AF86B5.7030706@alum.mit.edu> References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> <52AF5EE5.1030609@bell-labs.com> <52AF86B5.7030706@alum.mit.edu> Date: Mon, 16 Dec 2013 17:07:51 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7bd6bb0e8f7d3804edaee1aa Cc: "Cullen Jennings \(fluffy\)" , "Olle E. Johansson" , SIPCORE WG , "Vijay K. Gurbani" , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 23:07:54 -0000 --047d7bd6bb0e8f7d3804edaee1aa Content-Type: text/plain; charset=ISO-8859-1 I think that's good - it covers all bases. Mary. On Mon, Dec 16, 2013 at 5:03 PM, Paul Kyzivat wrote: > On 12/16/13 3:13 PM, Vijay K. Gurbani wrote: > >> On 12/16/2013 02:01 PM, Paul Kyzivat wrote: >> >>> OK. Latest candidate is: >>> >>> June 2014 Request publication of procedures to supplement RFC3263 >>> for dual-stack client and server handling of SIP URIs containing >>> domain names (PS) >>> >> >> Wait ... Sorry, I thought we had agreed to [1] >> >> May 2014 WGLC of procedures to supplement RFC3263 and RFC6157 for >> dual-stack client and server handling of SIP URIs containing domain >> names (PS) >> > > Oh, sorry. Trying again - merge of those two: > > > June 2014 Request publication of procedures to supplement RFC3263 > and RFC6157 for dual-stack client and server handling of SIP URIs > containing domain names (PS) > > Is that ok Vijay? > Any other complaints? > > Thanks, > Paul > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --047d7bd6bb0e8f7d3804edaee1aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think that's good - it covers all bases.=A0

=
Mary.=A0


On Mon, Dec 16, 2013 at 5:03 PM, Paul Kyzivat <pky= zivat@alum.mit.edu> wrote:
On 12/16/13 3:13 PM, Vijay= K. Gurbani wrote:
On 12/16/2013 02:01 PM, Paul Kyzivat wrote:
OK. Latest candidate is:

=A0 =A0 =A0June 2014 =A0Request publication of procedures to supplement RFC= 3263
=A0 =A0 =A0for dual-stack client and server handling of SIP URIs containing=
=A0 =A0 =A0domain names (PS)

Wait ... Sorry, I thought we had agreed to [1]

=A0 =A0 =A0May 2014 =A0WGLC of procedures to supplement RFC3263 and RFC6157= for
=A0 =A0 =A0dual-stack client and server handling of SIP URIs containing dom= ain
=A0 =A0 =A0names (PS)

Oh, sorry. Trying again - merge of those two:


=A0 =A0 =A0June 2014 =A0Request publication of procedures to supplement RFC= 3263
=A0 =A0 =A0and RFC6157 for dual-stack client and server handling of SIP URI= s
=A0 =A0 =A0containing domain names (PS)

Is that ok Vijay?
Any other complaints?

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul



_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--047d7bd6bb0e8f7d3804edaee1aa-- From vkg@bell-labs.com Tue Dec 17 06:00:30 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306DA1AE214 for ; Tue, 17 Dec 2013 06:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9FtQB4DjKKp for ; Tue, 17 Dec 2013 06:00:28 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id B35F21ADFAB for ; Tue, 17 Dec 2013 06:00:28 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id rBHE0PWh016595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Dec 2013 08:00:26 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id rBHE0PKE005259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Dec 2013 08:00:25 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id rBHE0MoD006139; Tue, 17 Dec 2013 08:00:25 -0600 (CST) Message-ID: <52B0590B.3020203@bell-labs.com> Date: Tue, 17 Dec 2013 08:00:43 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Paul Kyzivat References: <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> <52AF5EE5.1030609@bell-labs.com> <52AF86B5.7030706@alum.mit.edu> In-Reply-To: <52AF86B5.7030706@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: SIPCORE WG Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 14:00:30 -0000 On 12/16/2013 05:03 PM, Paul Kyzivat wrote: > Oh, sorry. Trying again - merge of those two: > > June 2014 Request publication of procedures to supplement RFC3263 > and RFC6157 for dual-stack client and server handling of SIP URIs > containing domain names (PS) > > Is that ok Vijay? Paul: Works for me. Thanks for attending to this. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From oej@edvina.net Tue Dec 17 06:19:08 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471031AE15F for ; Tue, 17 Dec 2013 06:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEz18T0FmGqW for ; Tue, 17 Dec 2013 06:19:06 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 602F71AE14F for ; Tue, 17 Dec 2013 06:19:05 -0800 (PST) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 9306B93C2A2; Tue, 17 Dec 2013 14:19:03 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: "Olle E. Johansson" In-Reply-To: <52B0590B.3020203@bell-labs.com> Date: Tue, 17 Dec 2013 15:19:02 +0100 Content-Transfer-Encoding: 7bit Message-Id: <7DFAB26A-CCF9-4E4F-BBEE-2FC199047A02@edvina.net> References: <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> <52AF5EE5.1030609@bell-labs.com> <52AF86B5.7030706@alum.mit.edu> <52B0590B.3020203@be ll-labs.com> To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.1822) Cc: SIPCORE WG , Olle E Johansson Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 14:19:08 -0000 On 17 Dec 2013, at 15:00, Vijay K. Gurbani wrote: > On 12/16/2013 05:03 PM, Paul Kyzivat wrote: >> Oh, sorry. Trying again - merge of those two: >> >> June 2014 Request publication of procedures to supplement RFC3263 >> and RFC6157 for dual-stack client and server handling of SIP URIs >> containing domain names (PS) >> >> Is that ok Vijay? > > Paul: Works for me. Thanks for attending to this. > I am fine with this too. /O From keith.drage@alcatel-lucent.com Tue Dec 17 15:55:27 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22911ADE8B for ; Tue, 17 Dec 2013 15:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8rGJgWoHD0P for ; Tue, 17 Dec 2013 15:55:26 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE561AD9AC for ; Tue, 17 Dec 2013 15:55:26 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rBHNswxf004176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Dec 2013 17:55:00 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rBHNsvL8015984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Dec 2013 00:54:57 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 18 Dec 2013 00:54:56 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "Cullen Jennings (fluffy)" Thread-Topic: [sipcore] IPv6 in the sip core wg Thread-Index: AQHO9f1rFmxMwFa6OUik7RkhLMXct5pXNmkAgAHP3sA= Date: Tue, 17 Dec 2013 23:54:55 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0FA8CF@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> In-Reply-To: <52AF5C0C.9000206@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: SIPCORE WG , "Olle E. Johansson" , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 23:55:28 -0000 I said in a previous mail that I would like to avoid the use of the word "s= upplement" and did suggest alternative wording. My reason is that some SDOs= treat the word "supplement" as identifying informative material, and given= that you want reuse in other SDOs it is best not to confuse the issue. In any case I don't think we need to bring out in either the title or the m= ilestone the exact relationship with RFC 3263, only that one exists. Defini= ng that relationship more accurately belongs to the abstract. Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 > Sent: 16 December 2013 20:01 > To: Cullen Jennings (fluffy) > Cc: Gonzalo Salgueiro (gsalguei); DRAGE, Keith (Keith);=20 > SIPCORE WG; Olle E. Johansson > Subject: Re: [sipcore] IPv6 in the sip core wg >=20 > On 12/16/13 2:33 PM, Cullen Jennings (fluffy) wrote: > > > > On Dec 13, 2013, at 9:28 AM, Paul Kyzivat=20 > wrote: > > > >> Having said that, I suggest the following as the milestone: > >> > >> May 2014 WGLC of procedures to supplement RFC3263 for=20 > dual-stack > >> client and server handling of SIP URIs containing domain names=20 > >> (PS) > > > > Good with me. And if you want to change "WGLC of" to=20 > "Request publication of" that seems like it would fix the=20 > point Mary raised. >=20 > OK. Latest candidate is: >=20 > June 2014 Request publication of procedures to=20 > supplement RFC3263 > for dual-stack client and server handling of SIP URIs containing > domain names (PS) >=20 > (I put back the extra month for Mary.) >=20 > Richard - does this work for you? >=20 > Thanks, > Paul >=20 >=20 >=20 > = From pkyzivat@alum.mit.edu Wed Dec 18 09:12:55 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C979B1ADED7 for ; Wed, 18 Dec 2013 09:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O_DyltTR3zCJ for ; Wed, 18 Dec 2013 09:12:54 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6351ADEBA for ; Wed, 18 Dec 2013 09:12:54 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta01.westchester.pa.mail.comcast.net with comcast id 30a71n0041GhbT8515CsEh; Wed, 18 Dec 2013 17:12:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id 35Cs1n00A3ZTu2S3T5CssD; Wed, 18 Dec 2013 17:12:52 +0000 Message-ID: <52B1D794.1080602@alum.mit.edu> Date: Wed, 18 Dec 2013 12:12:52 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , "Cullen Jennings (fluffy)" References: <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0FA8CF@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0FA8CF@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1387386772; bh=dQyXW+ENODLBh2bYVXlhshx1xNqUyFxDE9H+6MVMbq8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EA7P1m73fXe7oPJHqPfOIU78kz3DTzEazBAQj1DCcPOsqbUTpff/5BwNnwIr8JIlf NTd7+5N1ib64Xdm1YSgUTJ9fikPFIIeH1MVjnOYlUv4YNDu+PjVXZ4jr5LsXlYpaP7 5GCgwmvbJer+4WE4m5CDoz4865a6w6ZeR38ispTY0h7iZvRhy4AYCMveRbQ0iMD38M P7RlwLGztEVD4zZ6Y+poiPhmuBdfYSe3rvv/yuiqPvFAUoBhaT/GtRA3/pYVpADYhD 8y32hFEgn1LfsxGoPaPQq0ZwezPXj1P8kVwHZpajMPSGMcb9tM4BKPYio7QMUWRhgf HpXfDcDIW9VNg== Cc: SIPCORE WG , "Olle E. Johansson" , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 17:12:56 -0000 On 12/17/13 6:54 PM, DRAGE, Keith (Keith) wrote: > I said in a previous mail that I would like to avoid the use of the word "supplement" and did suggest alternative wording. My reason is that some SDOs treat the word "supplement" as identifying informative material, and given that you want reuse in other SDOs it is best not to confuse the issue. I don't see why that should prevent us from using "supplement" in this context. We can have that discussion again if the word is used in a draft, but I don't see why it's a concern there either. (The definitive indication is whether the RFC is standards track, and the normative language in the draft.) > In any case I don't think we need to bring out in either the title or the milestone the exact relationship with RFC 3263, only that one exists. Defining that relationship more accurately belongs to the abstract. My latest proposal was: June 2014 Request publication of procedures to supplement RFC3263 and RFC6157 for dual-stack client and server handling of SIP URIs containing domain names (PS) Your earlier proposal was: "Use of RFC 3263 in dual-stack devices". RFC6157 already addresses dual-stack devices. What we are trying to deal with is that 3263 and 6157 are insufficient and/or wrong for dual-stack clients. I see no way to avoid using *some* verb - supplement, update, clarify, expand, ... Feel free to offer something that addresses both your concerns and the others that have been raised. Thanks, Paul > Keith > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 16 December 2013 20:01 >> To: Cullen Jennings (fluffy) >> Cc: Gonzalo Salgueiro (gsalguei); DRAGE, Keith (Keith); >> SIPCORE WG; Olle E. Johansson >> Subject: Re: [sipcore] IPv6 in the sip core wg >> >> On 12/16/13 2:33 PM, Cullen Jennings (fluffy) wrote: >>> >>> On Dec 13, 2013, at 9:28 AM, Paul Kyzivat >> wrote: >>> >>>> Having said that, I suggest the following as the milestone: >>>> >>>> May 2014 WGLC of procedures to supplement RFC3263 for >> dual-stack >>>> client and server handling of SIP URIs containing domain names >>>> (PS) >>> >>> Good with me. And if you want to change "WGLC of" to >> "Request publication of" that seems like it would fix the >> point Mary raised. >> >> OK. Latest candidate is: >> >> June 2014 Request publication of procedures to >> supplement RFC3263 >> for dual-stack client and server handling of SIP URIs containing >> domain names (PS) >> >> (I put back the extra month for Mary.) >> >> Richard - does this work for you? >> >> Thanks, >> Paul >> >> >> >>