From paulej@packetizer.com Sat Jun 2 20:11:31 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A2211E8083 for ; Sat, 2 Jun 2012 20:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4l0-i-l+V9pr for ; Sat, 2 Jun 2012 20:11:29 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE7211E8080 for ; Sat, 2 Jun 2012 20:11:29 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q533BRdG010183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 2 Jun 2012 23:11:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1338693088; bh=yRrAMuxXoxL5UNph9UVCatMP0b7OvZMq5KwcQ7vuHiw=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=NRkmsK95N4hw1Kq9epSDZ7FT8c29WFqt37npbLD5Ran8H90dvkqIn5dpucY3tds+r ihtnGxw5N5Xu0+Pu0cDOE3g+lclYpJcke5f9Ebl5M89gZxXNXy0PhLEQm48riT1/QZ Ep1VMK4WUO5BWwFwGDViC4QjtcPWLZrmyKaFJJ3E= From: "Paul E. Jones" To: "'Ravindran, Parthasarathi'" , References: <02fd01cd3dd3$a04e9230$e0ebb690$@packetizer.com> <387F9047F55E8C42850AD6B3A7A03C6C16038963@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C16038963@inba-mail01.sonusnet.com> Date: Sat, 2 Jun 2012 23:11:36 -0400 Message-ID: <00b601cd4136$9672d580$c3588080$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B7_01CD4115.0F621FE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE4U5YzCDejwUHVpKZ/Wgs+HlZqTQKRmb4fl/0wAbA= Content-Language: en-us Subject: Re: [Insipid] Revised requirements document X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 03:11:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B7_01CD4115.0F621FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Partha, I agree that as the requirements now read, we should consider merging 5 and 6. That said, what REQ6 used to say was that the session ID must not reveal through the Session-ID that some entity was in the path that modified the signaling messages. I agree merging these two now is probably reasonable, but we are missing the spirit of the original REQ6. Do we want to retain that? Paul From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] Sent: Wednesday, May 30, 2012 5:58 AM To: Paul E. Jones; insipid@ietf.org Subject: RE: [Insipid] Revised requirements document Paul, IMO, REQ-5 and REQ-6 shall be merged together to indicate that "session-id mechanism MUST not reveal any form of identity in REQ-5 and any form of SIP messages in REQ-6". REQ-6 is important because it provides confidence to the operator/admin that session-id is safe to be passed across in SBC/PBX. In case it is possible to use any of the existing SIP headers/body, IMO there is no need to new session-id itself. AFAIK, there is no SIP headers/body exists which qualify for session-id as of now. Thanks Partha From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Wednesday, May 30, 2012 1:16 AM To: insipid@ietf.org Subject: [Insipid] Revised requirements document Folks, As requested, I posted a revised version of the INSIPID requirements document, taking into consideration the discussions from the call today. Here's the text: http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-01 Note that Requirement 1a needs to be completed. I'd be delighted if someone could propose some wording for that. As discussed on the call, the meaning of requirement 6 was changed quite substantially in meaning from the -00 draft. We need to decide exactly what meaning we want or introduce a new requirement if we want to both hide information and also not reveal that an SBC, for example, might have changed any of that information. Paul ------=_NextPart_000_00B7_01CD4115.0F621FE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Partha,

 

I agree that as the = requirements now read, we should consider merging 5 and = 6.

 

That said, what REQ6 = used to say was that the session ID must not reveal through the = Session-ID that some entity was in the path that modified the signaling = messages.

 

I agree merging these = two now is probably reasonable, but we are missing the spirit of the = original REQ6.  Do we want to retain that?

 

Paul

 

From:= = Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] =
Sent: Wednesday, May 30, 2012 5:58 AM
To: Paul E. = Jones; insipid@ietf.org
Subject: RE: [Insipid] Revised = requirements document

 

Paul,

 

IMO, REQ-5 and REQ-6 = shall be merged together to indicate that “session-id mechanism = MUST not reveal any form of identity in REQ-5 and any form of SIP = messages in REQ-6”.

 

REQ-6 is important = because it provides confidence to the operator/admin that session-id is = safe to be passed across in SBC/PBX. In case it is possible to use any = of the existing SIP headers/body, IMO there is no need to new session-id = itself. AFAIK, there is no SIP headers/body exists which qualify for = session-id as of now.

 

Thanks

Partha

 

From:= = insipid-bounces@ietf.org = [mailto:insipid-bounces= @ietf.org] On Behalf Of Paul E. Jones
Sent: = Wednesday, May 30, 2012 1:16 AM
To: insipid@ietf.org
Subject: = [Insipid] Revised requirements = document

 

Folks,

 

As = requested, I posted a revised version of the INSIPID requirements = document, taking into consideration the discussions from the call = today.  Here’s the text:

http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-01=

 

Note that Requirement 1a needs to be completed.  = I’d be delighted if someone could propose some wording for = that.

 

As discussed on the call, the meaning of requirement 6 = was changed quite substantially in meaning from the -00 draft.  We = need to decide exactly what meaning we want or introduce a new = requirement if we want to both hide information and also not reveal that = an SBC, for example, might have changed any of that = information.

 

Paul

 

------=_NextPart_000_00B7_01CD4115.0F621FE0-- From pravindran@sonusnet.com Mon Jun 4 01:22:52 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE56621F877B for ; Mon, 4 Jun 2012 01:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHcSAxyLc1od for ; Mon, 4 Jun 2012 01:22:50 -0700 (PDT) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9E81021F85A4 for ; Mon, 4 Jun 2012 01:22:49 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKT8xwVuEKVzHSli51CWg9SlIJVZNmBWTF@postini.com; Mon, 04 Jun 2012 01:22:49 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 4 Jun 2012 04:23:14 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Mon, 4 Jun 2012 13:52:41 +0530 From: "Ravindran, Parthasarathi" To: "Paul E. Jones" , "insipid@ietf.org" Thread-Topic: [Insipid] Revised requirements document Thread-Index: Ac090wzWy9p+WCsrQk27dM+DK4ieVQAdt+zgAK+j4AAASB2QkA== Date: Mon, 4 Jun 2012 08:22:39 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C1603A36E@inba-mail01.sonusnet.com> References: <02fd01cd3dd3$a04e9230$e0ebb690$@packetizer.com> <387F9047F55E8C42850AD6B3A7A03C6C16038963@inba-mail01.sonusnet.com> <00b601cd4136$9672d580$c3588080$@packetizer.com> In-Reply-To: <00b601cd4136$9672d580$c3588080$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.54] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C1603A36Einbamail01sonus_" MIME-Version: 1.0 Subject: Re: [Insipid] Revised requirements document X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 08:22:53 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C1603A36Einbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paul, First, I'll double confirm your concern. The scenario is as follows: 1) Some of the SIP headers/body is used by UAC to create the session i= d(something like hashing of SIP headers) and pass towards middle box (IP PB= X, SBC, or any other core server) 2) The middle box replaces SIP headers with new values and pass the sa= me session-id to the UAS 3) It is possible by UAS to identify that the middle box exists in the= path by the mechanism used to compute session-id In case I understand you concern correctly, I agree that it is missing in R= EQ-6 & REQ-5 as of now and also your concern looks valid to me based on cus= tomer requirement for removing History-info header from SIP message in SBC. Thanks Partha From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Sunday, June 03, 2012 8:42 AM To: Ravindran, Parthasarathi; insipid@ietf.org Subject: RE: [Insipid] Revised requirements document Partha, I agree that as the requirements now read, we should consider merging 5 and= 6. That said, what REQ6 used to say was that the session ID must not reveal th= rough the Session-ID that some entity was in the path that modified the sig= naling messages. I agree merging these two now is probably reasonable, but we are missing th= e spirit of the original REQ6. Do we want to retain that? Paul From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] Sent: Wednesday, May 30, 2012 5:58 AM To: Paul E. Jones; insipid@ietf.org Subject: RE: [Insipid] Revised requirements document Paul, IMO, REQ-5 and REQ-6 shall be merged together to indicate that "session-id = mechanism MUST not reveal any form of identity in REQ-5 and any form of SIP= messages in REQ-6". REQ-6 is important because it provides confidence to the operator/admin tha= t session-id is safe to be passed across in SBC/PBX. In case it is possible= to use any of the existing SIP headers/body, IMO there is no need to new s= ession-id itself. AFAIK, there is no SIP headers/body exists which qualify = for session-id as of now. Thanks Partha From: insipid-bounces@ietf.org [mailto:ins= ipid-bounces@ietf.org] On Behalf = Of Paul E. Jones Sent: Wednesday, May 30, 2012 1:16 AM To: insipid@ietf.org Subject: [Insipid] Revised requirements document Folks, As requested, I posted a revised version of the INSIPID requirements docume= nt, taking into consideration the discussions from the call today. Here's = the text: http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-01 Note that Requirement 1a needs to be completed. I'd be delighted if someon= e could propose some wording for that. As discussed on the call, the meaning of requirement 6 was changed quite su= bstantially in meaning from the -00 draft. We need to decide exactly what = meaning we want or introduce a new requirement if we want to both hide info= rmation and also not reveal that an SBC, for example, might have changed an= y of that information. Paul --_000_387F9047F55E8C42850AD6B3A7A03C6C1603A36Einbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Paul,

 

First, I’ll doub= le confirm your concern. The scenario is as follows:

 

1)&n= bsp;     Some of the SI= P headers/body is used by UAC to create the session id(something like hashi= ng of SIP headers) and pass towards middle box (IP PBX, SBC, or any other c= ore server)

2)&n= bsp;     The middle box= replaces SIP headers with new values and pass the same session-id to the U= AS

3)&n= bsp;     It is possible= by UAS to identify that the middle box exists in the path by the mechanism= used to compute session-id

 

In case I understand y= ou concern correctly, I agree that it is missing in REQ-6 & REQ-5 as of= now and also your concern looks valid to me based on customer requirement = for removing History-info header from SIP message in SBC.

 

Thanks

Partha

 

From: Paul E. = Jones [mailto:paulej@packetizer.com]
Sent: Sunday, June 03, 2012 8:42 AM
To: Ravindran, Parthasarathi; insipid@ietf.org
Subject: RE: [Insipid] Revised requirements document

 

Partha,

 

I agree that as the re= quirements now read, we should consider merging 5 and 6.<= /p>

 

That said, what REQ6 <= i>used to say was that the session ID must not reveal through the Sessi= on-ID that some entity was in the path that modified the signaling messages= .

 

I agree merging these = two now is probably reasonable, but we are missing the spirit of the origin= al REQ6.  Do we want to retain that?

 

Paul=

 

From: Ravindra= n, Parthasarathi [mailto:pravind= ran@sonusnet.com]
Sent: Wednesday, May 30, 2012 5:58 AM
To: Paul E. Jones; insipid@ietf.= org
Subject: RE: [Insipid] Revised requirements document

 

Paul,

 

IMO, REQ-5 and REQ-6 s= hall be merged together to indicate that “session-id mechanism MUST n= ot reveal any form of identity in REQ-5 and any form of SIP messages in REQ= -6”.

 

REQ-6 is important bec= ause it provides confidence to the operator/admin that session-id is safe t= o be passed across in SBC/PBX. In case it is possible to use any of the exi= sting SIP headers/body, IMO there is no need to new session-id itself. AFAIK, there is no SIP headers/body exis= ts which qualify for session-id as of now.

 

Thanks

Partha

 

From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Wednesday, May 30, 2012 1:16 AM
To: insipid@ietf.org
Subject: [Insipid] Revised requirements document

 

Folks,

 

As requested, I posted a revised version of the INSI= PID requirements document, taking into consideration the discussions from t= he call today.  Here’s the text:

http://tools.ietf.org/html/draft-jones-insipid-s= ession-id-reqts-01

 

Note that Requirement 1a needs to be completed. = ; I’d be delighted if someone could propose some wording for that.

 

As discussed on the call, the meaning of requirement= 6 was changed quite substantially in meaning from the -00 draft.  We = need to decide exactly what meaning we want or introduce a new requirement = if we want to both hide information and also not reveal that an SBC, for example, might have changed any of that i= nformation.

 

Paul

 

--_000_387F9047F55E8C42850AD6B3A7A03C6C1603A36Einbamail01sonus_-- From paulej@packetizer.com Mon Jun 4 09:59:42 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29F221F87EE for ; Mon, 4 Jun 2012 09:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-OGKAfJ7hKh for ; Mon, 4 Jun 2012 09:59:40 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id E38DE21F87DF for ; Mon, 4 Jun 2012 09:59:39 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q54GxcGr013613 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Jun 2012 12:59:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1338829179; bh=uDTuGTY6rUMeluqWWAZpyK7ScwnxJXUE8M0yxr7MVzc=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=f7G9+AFWEKMRSwvBIzyGamJE23GP11x6/3hO9BM/7KbyRY+Oumi4Gg13wPrSKzOWi QRhUntxOiRvtuX+M7Wh37/oRRc0pqIqjycXMuffNd3bDpfLY/04F9Y7zCF3Gju2r8B 1Kw8v16O1texiTj/Rp5J27XztsdsqN96Tp3Dhd7Y= From: "Paul E. Jones" To: "'Ravindran, Parthasarathi'" , References: <02fd01cd3dd3$a04e9230$e0ebb690$@packetizer.com> <387F9047F55E8C42850AD6B3A7A03C6C16038963@inba-mail01.sonusnet.com> <00b601cd4136$9672d580$c3588080$@packetizer.com> <387F9047F55E8C42850AD6B3A7A03C6C1603A36E@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C1603A36E@inba-mail01.sonusnet.com> Date: Mon, 4 Jun 2012 12:59:41 -0400 Message-ID: <008e01cd4273$6f834ac0$4e89e040$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008F_01CD4251.E8741BC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE4U5YzCDejwUHVpKZ/Wgs+HlZqTQKRmb4fAm7ugNYCVmyhDpfZgvWA Content-Language: en-us Subject: Re: [Insipid] Revised requirements document X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 16:59:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008F_01CD4251.E8741BC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Partha, If we used a hash (as you describe in (1)), that's probably OK since hash functions are one way. (I assume you were referring to SHA-1 or MD5 or other.) Your other examples are valid, I think. Unfortunately, I do not recall who proposed this requirement to hide the fact an SBC is present, but I think it was focused on topology hiding. If we use a non-MAC-based UUID or a hash, we could meet this requirement. The question, though, is whether we need to retain the spirit of the original requirement. Do we want to have an explicit requirement to not reveal any information like network topology through the session ID? I'm not sure the group feels strongly one way or the other, but it might be because there is already thinking that whatever we use will not reveal that information, anyway. Paul From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] Sent: Monday, June 04, 2012 4:23 AM To: Paul E. Jones; insipid@ietf.org Subject: RE: [Insipid] Revised requirements document Paul, First, I'll double confirm your concern. The scenario is as follows: 1) Some of the SIP headers/body is used by UAC to create the session id(something like hashing of SIP headers) and pass towards middle box (IP PBX, SBC, or any other core server) 2) The middle box replaces SIP headers with new values and pass the same session-id to the UAS 3) It is possible by UAS to identify that the middle box exists in the path by the mechanism used to compute session-id In case I understand you concern correctly, I agree that it is missing in REQ-6 & REQ-5 as of now and also your concern looks valid to me based on customer requirement for removing History-info header from SIP message in SBC. Thanks Partha From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Sunday, June 03, 2012 8:42 AM To: Ravindran, Parthasarathi; insipid@ietf.org Subject: RE: [Insipid] Revised requirements document Partha, I agree that as the requirements now read, we should consider merging 5 and 6. That said, what REQ6 used to say was that the session ID must not reveal through the Session-ID that some entity was in the path that modified the signaling messages. I agree merging these two now is probably reasonable, but we are missing the spirit of the original REQ6. Do we want to retain that? Paul From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] Sent: Wednesday, May 30, 2012 5:58 AM To: Paul E. Jones; insipid@ietf.org Subject: RE: [Insipid] Revised requirements document Paul, IMO, REQ-5 and REQ-6 shall be merged together to indicate that "session-id mechanism MUST not reveal any form of identity in REQ-5 and any form of SIP messages in REQ-6". REQ-6 is important because it provides confidence to the operator/admin that session-id is safe to be passed across in SBC/PBX. In case it is possible to use any of the existing SIP headers/body, IMO there is no need to new session-id itself. AFAIK, there is no SIP headers/body exists which qualify for session-id as of now. Thanks Partha From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Wednesday, May 30, 2012 1:16 AM To: insipid@ietf.org Subject: [Insipid] Revised requirements document Folks, As requested, I posted a revised version of the INSIPID requirements document, taking into consideration the discussions from the call today. Here's the text: http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-01 Note that Requirement 1a needs to be completed. I'd be delighted if someone could propose some wording for that. As discussed on the call, the meaning of requirement 6 was changed quite substantially in meaning from the -00 draft. We need to decide exactly what meaning we want or introduce a new requirement if we want to both hide information and also not reveal that an SBC, for example, might have changed any of that information. Paul ------=_NextPart_000_008F_01CD4251.E8741BC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Partha,

 

If we used a hash (as = you describe in (1)), that’s probably OK since hash functions are = one way. (I assume you were referring to SHA-1 or MD5 or = other.)

 

Your other examples are = valid, I think.

 

Unfortunately, I do not = recall who proposed this requirement to hide the fact an SBC is present, = but I think it was focused on topology hiding.  If we use a = non-MAC-based UUID or a hash, we could meet this requirement.  The = question, though, is whether we need to retain the spirit of the = original requirement.

 

Do we want to have an = explicit requirement to not reveal any information like network topology = through the session ID?  I’m not sure the group feels = strongly one way or the other, but it might be because there is already = thinking that whatever we use will not reveal that information, = anyway.

 

Paul

 

From:= = Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] =
Sent: Monday, June 04, 2012 4:23 AM
To: Paul E. = Jones; insipid@ietf.org
Subject: RE: [Insipid] Revised = requirements document

 

Paul,

 

First, I’ll double = confirm your concern. The scenario is as = follows:

 

1)      = Some of the = SIP headers/body is used by UAC to create the session id(something like = hashing of SIP headers) and pass towards middle box (IP PBX, SBC, or any = other core server)

2)      = The middle = box replaces SIP headers with new values and pass the same session-id to = the UAS

3)      = It is = possible by UAS to identify that the middle box exists in the path by = the mechanism used to compute session-id

 

In case I understand you = concern correctly, I agree that it is missing in REQ-6 & REQ-5 as of = now and also your concern looks valid to me based on customer = requirement for removing History-info header from SIP message in SBC. =

 

Thanks

Partha =

 

From:= = Paul E. Jones [mailto:paulej@packetizer.= com]
Sent: Sunday, June 03, 2012 8:42 AM
To: = Ravindran, Parthasarathi; insipid@ietf.org
Subject: = RE: [Insipid] Revised requirements = document

 

Partha,

 

I agree that as the = requirements now read, we should consider merging 5 and = 6.

 

That said, what REQ6 = used to say was that the session ID must not reveal through the = Session-ID that some entity was in the path that modified the signaling = messages.

 

I agree merging these = two now is probably reasonable, but we are missing the spirit of the = original REQ6.  Do we want to retain that?

 

Paul

 

From:= = Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com]
Sent: Wednesday, May 30, 2012 5:58 AM
To: Paul = E. Jones; insipid@ietf.org
Subject: = RE: [Insipid] Revised requirements = document

 

Paul,

 

IMO, REQ-5 and REQ-6 = shall be merged together to indicate that “session-id mechanism = MUST not reveal any form of identity in REQ-5 and any form of SIP = messages in REQ-6”.

 

REQ-6 is important = because it provides confidence to the operator/admin that session-id is = safe to be passed across in SBC/PBX. In case it is possible to use any = of the existing SIP headers/body, IMO there is no need to new session-id = itself. AFAIK, there is no SIP headers/body exists which qualify for = session-id as of now.

 

Thanks

Partha

 

From:= = insipid-bounces@ietf.org = [mailto:insipid-bounces= @ietf.org] On Behalf Of Paul E. Jones
Sent: = Wednesday, May 30, 2012 1:16 AM
To: insipid@ietf.org
Subject: = [Insipid] Revised requirements = document

 

Folks,

 

As = requested, I posted a revised version of the INSIPID requirements = document, taking into consideration the discussions from the call = today.  Here’s the text:

http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-01=

 

Note that Requirement 1a needs to be completed.  = I’d be delighted if someone could propose some wording for = that.

 

As discussed on the call, the meaning of requirement 6 = was changed quite substantially in meaning from the -00 draft.  We = need to decide exactly what meaning we want or introduce a new = requirement if we want to both hide information and also not reveal that = an SBC, for example, might have changed any of that = information.

 

Paul

 

------=_NextPart_000_008F_01CD4251.E8741BC0-- From iesg-secretary@ietf.org Thu Jun 7 13:00:52 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B1A11E813E; Thu, 7 Jun 2012 13:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k55c2mieKPxu; Thu, 7 Jun 2012 13:00:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278E111E80F2; Thu, 7 Jun 2012 13:00:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120607200052.15855.98893.idtracker@ietfa.amsl.com> Date: Thu, 07 Jun 2012 13:00:52 -0700 Cc: insipid@ietf.org Subject: [Insipid] INSIPID WG Virtual Interim Meetings: June 25 and July 10, 2012 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 20:00:52 -0000 The INSIPID WG plans to hold two further virtual interim meetings before = IETF #84 as follows: Virtual interim 2: Monday June 25th 2012 9:00 am - 11:00 am Pacific Time Virtual interim 3: Tuesday July 10th 2012 9:00 am - 11:00 am Pacific Time The agenda for the virtual interim 2 is: 5 min: Note well, agenda bash, etc Chairs 55 min: Requirements draft issues Paul Jones 55 min: Review of proposed solutions various 5 min: Next steps Chairs The agenda for virtual interim 3 is still open based on results before = then. From gsalguei@cisco.com Thu Jun 7 13:22:28 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEB821F858E for ; Thu, 7 Jun 2012 13:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6cwb2sVzKnZ for ; Thu, 7 Jun 2012 13:22:26 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id F12E921F86E1 for ; Thu, 7 Jun 2012 13:22:25 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q57KMP4Q007197 for ; Thu, 7 Jun 2012 16:22:25 -0400 (EDT) Received: from rtp-gsalguei-8717.cisco.com (rtp-gsalguei-8717.cisco.com [10.116.61.56]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q57KMOVM009117; Thu, 7 Jun 2012 16:22:24 -0400 (EDT) From: Gonzalo Salgueiro Content-Type: multipart/alternative; boundary="Apple-Mail=_B677F90F-A08D-4A98-8A1E-2A360FAE1C7F" Date: Thu, 7 Jun 2012 16:22:24 -0400 Message-Id: <92F65FB9-2DC6-4EFE-8ADC-947C58BDE250@cisco.com> To: insipid@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Cc: "Keith \(Keith\) DRAGE" Subject: [Insipid] INSIPID WG Virtual Interim #2 Meeting: Dial-in details via Webex X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 20:22:28 -0000 --Apple-Mail=_B677F90F-A08D-4A98-8A1E-2A360FAE1C7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks -=20 We will use Webex to host the INSIPID Virtual Interim #2 meeting (June = 25th at 9 AM Pacific Daylight Time). See below for the agenda and = "dial-in" details.=20 Cheers, Gonzalo -------------------------------------------------------- Agenda: 1) Note well, agenda bash, notetakers, etc. - Chairs (5 min) 2) Discussion of requirements draft issues (cont'd) - Paul Jones, James = Polk (55 min) draft-jones-ipmc-session-id-reqts-01 https://datatracker.ietf.org/doc/draft-jones-ipmc-session-id-reqts/ 3) Review of proposed solutions - various (55 min) [Note: We encourage folks to submit any candidate solutions for session = id that they wish to be considered by the WG] So far we have:=20 draft-jones-insipid-session-id-00 http://tools.ietf.org/id/draft-jones-insipid-session-id-00.txt 4) Next steps - Chairs (5 min) -------------------------------------------------------- INtermediary-safe SIP session ID (INSIPID) Group invites you to attend = this online meeting.=20 Topic: INSIPID WG Virtual Interm #2=20 Date: Monday, June 25, 2012=20 Time: 9:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)=20 Meeting Number: 964 706 122=20 Meeting Password: insipid=20 -------------------------------------------------------=20 To join the online meeting (Now from mobile devices!)=20 -------------------------------------------------------=20 1. Go to = https://workgreen.webex.com/workgreen/j.php?ED=3D194761642&UID=3D128899486= 7&PW=3DNMjA3MGVkMjBj&RT=3DMiM0=20 2. If requested, enter your name and email address.=20 3. If a password is required, enter the meeting password: insipid=20 4. Click "Join".=20 To view in other time zones or languages, please click the link:=20 = https://workgreen.webex.com/workgreen/j.php?ED=3D194761642&UID=3D128899486= 7&PW=3DNMjA3MGVkMjBj&ORT=3DMiM0=20 -------------------------------------------------------=20 To join the audio conference only=20 -------------------------------------------------------=20 To receive a call back, provide your phone number when you join the = meeting, or call the number below and enter the access code.=20 Call-in toll number (US/Canada): 1-408-792-6300=20 Global call-in numbers: = https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&ED= =3D194761642&tollFree=3D0=20 Access code:964 706 122=20 -------------------------------------------------------=20 For assistance=20 -------------------------------------------------------=20 1. Go to https://workgreen.webex.com/workgreen/mc=20 2. On the left navigation bar, click "Support".=20 You can contact me at:=20 cmorgan@amsl.com=20 1-510-492-4085=20 To add this meeting to your calendar program (for example Microsoft = Outlook), click this link:=20 = https://workgreen.webex.com/workgreen/j.php?ED=3D194761642&UID=3D128899486= 7&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3D6lQtSgS3IEYwbEC0eCuna/QfIqTRdi-0xh9= 3VsR-kDE=3D&RT=3DMiM0=20 The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going to = https://workgreen.webex.com/workgreen/systemdiagnosis.php.=20 Sign up for a free trial of WebEx=20 http://www.webex.com/go/mcemfreetrial=20 http://www.webex.com=20 CCP:+14087926300x964706122#=20 IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation.=20 --Apple-Mail=_B677F90F-A08D-4A98-8A1E-2A360FAE1C7F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Folks = - 

We will use Webex to host the INSIPID = Virtual Interim #2 meeting (June 25th at 9 AM Pacific Daylight Time). = See below for the agenda and "dial-in" = details. 

Cheers,

G= onzalo

------------------------------------------= --------------
Agenda:

1) Note well, = agenda bash, notetakers, etc. - Chairs (5 = min)

2) Discussion of requirements draft issues = (cont'd) - Paul Jones, James Polk (55 = min)


3) Review of proposed solutions - various = (55 min)

[Note: We encourage folks to submit = any candidate solutions for session id that they wish to be considered = by the WG]

So far we = have: 

4) Next steps - Chairs (5 = min)

----------------------------------------= ----------------

INtermediary-safe SIP session ID = (INSIPID) Group invites you to attend this online = meeting. 

Topic: INSIPID WG Virtual Interm = #2 
Date: Monday, June 25, 2012 
Time: 9:00 am, Pacific = Daylight Time (San Francisco, GMT-07:00) 
Meeting Number: 964 = 706 122 
Meeting Password: = insipid 


-------------------------------------------------= ------ 
To join the online meeting (Now from mobile = devices!) 
-------------------------------------------------------=  
1. Go to https://workgreen.webe= x.com/workgreen/j.php?ED=3D194761642&UID=3D1288994867&PW=3DNMjA3MG= VkMjBj&RT=3DMiM0 
2. If requested, enter your name and = email address. 
3. If a password is required, enter the meeting = password: insipid 
4. Click "Join". 

To view in = other time zones or languages, please click the = link: 
https://workgreen.webex.com/workgreen/j.php?ED=3D194761642&= amp;UID=3D1288994867&PW=3DNMjA3MGVkMjBj&ORT=3DMiM0 

--= ----------------------------------------------------- 
To join = the audio conference = only 
------------------------------------------------------- = ;
To receive a call back, provide your phone number when you join the = meeting, or call the number below and enter the access = code. 
Call-in toll number (US/Canada): = 1-408-792-6300 
Global call-in = numbers: https://workgreen.webex.com/workgreen/globalcallin.php?servi= ceType=3DMC&ED=3D194761642&tollFree=3D0 

Access = code:964 706 = 122 

-------------------------------------------------------&n= bsp;
For = assistance 
------------------------------------------------------= - 
1. Go = to https://workgreen.webex.com/workgreen/mc 
2. On the left = navigation bar, click "Support". 

You can contact me = at: 
cmorgan@amsl.com 
1-510-492-4085 

To = add this meeting to your calendar program (for example Microsoft = Outlook), click this = link: 
https://workgreen.webex.com/workgreen/j.php?ED=3D194761642&= amp;UID=3D1288994867&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA= 2=3D6lQtSgS3IEYwbEC0eCuna/QfIqTRdi-0xh93VsR-kDE=3D&RT=3DMiM0 
=
The playback of UCF (Universal Communications Format) rich media = files requires appropriate players. To view this type of rich media = files in the meeting, please check whether you have the players = installed on your computer by going = to https://workgreen.webex.com/workgreen/systemdiagnosis.php. 
Sign up for a free trial of = WebEx 
http://www.webex.com/go/mcemfreetrial 

http://w= ww.webex.com 

CCP:+14087926300x964706122# 

IMPORTA= NT NOTICE: This WebEx service includes a feature that allows audio and = any documents and other materials exchanged or viewed during the session = to be recorded. By joining this session, you automatically consent = to such recordings. If you do not consent to the recording, discuss your = concerns with the meeting host prior to the start of the recording or do = not join the session. Please note that any such recordings may be = subject to discovery in the event of = litigation. 

= --Apple-Mail=_B677F90F-A08D-4A98-8A1E-2A360FAE1C7F-- From paulej@packetizer.com Sun Jun 17 16:33:02 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F10421F852A for ; Sun, 17 Jun 2012 16:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATNqs32FMI0c for ; Sun, 17 Jun 2012 16:33:01 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 331A921F8528 for ; Sun, 17 Jun 2012 16:33:01 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q5HNWwuw002578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Jun 2012 19:32:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1339975979; bh=Luli5jlUdVLtWfzxLl3pIiOoDP/UYuyudV9CBMdFPU4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=bjmLfej9IxJ4UOw8m9W79z18Af+7h5CtNFzDIE4eJvuF4VAwcwQ+BFMkjnc7wxy6p 1OFFVkESWUZ+fCSMktJ197r+O9L02b9I8FEmgCeOwLp+LtYGkc7iyet2sFrVBmJz1v KU5AVCQj02jsMYf+/K+euKcSWDxqvplpTWJNN94I= From: "Paul E. Jones" To: References: <20120617232517.4355.36096.idtracker@ietfa.amsl.com> In-Reply-To: <20120617232517.4355.36096.idtracker@ietfa.amsl.com> Date: Sun, 17 Jun 2012 19:33:00 -0400 Message-ID: <010201cd4ce1$88a723a0$99f56ae0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKbPwDOuqTQ0fTS5+A0WOj09+LQA5VjQx/A Content-Language: en-us Cc: Hadriel Kaplan Subject: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-reqts-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2012 23:33:02 -0000 Folks, I posted a revised version of the requirements document. This version moves the use cases in front of the actual requirements. We discussed having more fleshed out use cases. I'm happy to insert those if somebody will provide the appropriate text. Also, there are two requirements that we reviewed on the last call that need further input. REQ1a: This is intended to be a requirement like REQ1, but focused on non-dialog creating transactions. If we wish to introduce this requirement, please provide appropriate text. REQ6: This was changed and we discussed merging it with REQ5. I'm OK with that approach, but the original requirement was to not provide any hint that a middlebox changed anything. I know Partha is favorable to a merge and dropping REQ6 entirely. Hadriel, what's your preference? Others? Paul > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: Sunday, June 17, 2012 7:25 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-jones-insipid-session-id-reqts-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Requirements for an End-to-End Session > Identification in IP-Based Multimedia Communication Networks > Author(s) : Paul E. Jones > Gonzalo Salgueiro > James Polk > Parthasarathi Ravindran > Laura Liess > Roland Jesske > Salvatore Loreto > Hadriel Kaplan > Filename : draft-jones-insipid-session-id-reqts-02.txt > Pages : 9 > Date : 2012-06-17 > > Abstract: > This document specifies the requirements for an end-to-end session > identifier in IP-based multimedia communication networks. This > identifier would enable endpoints, intermediate devices, and > management and monitoring systems to identify a session end-to-end, > associate multiple endpoints with a given multipoint conference, > track communication sessions when they are redirected, and associate > one or more media flows with a given communication session. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-jones-insipid-session-id-reqts > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-02 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-jones-insipid-session-id-reqts-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt From jmpolk@cisco.com Mon Jun 18 12:29:48 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B8111E80A3 for ; Mon, 18 Jun 2012 12:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.134 X-Spam-Level: X-Spam-Status: No, score=-110.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3bp98UYcGYb for ; Mon, 18 Jun 2012 12:29:47 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id BC12A21F86B5 for ; Mon, 18 Jun 2012 12:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=3952; q=dns/txt; s=iport; t=1340047786; x=1341257386; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=0sX1veLAfOBCeQlYcLm6WCtXNaSsehmN2Rplu0p9UoM=; b=hCcCPU4iZoe7JBxr2gEbfSK3xq0RbWFaKWbAHFj47jv9UtOEdbpyF6Ut prWrX+NyzuJHbPOFpkY5yQLjNNWMCICjFzCd0zTb0Mtu0tHNPMfJe4ouC XSTLC0r7c8DHW2E3gQnoz0BOUHIOG9eviX/zn2rpLPogLwjpvD6j81T4S k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGqA30+rRDoG/2dsb2JhbAA7CgG1bYEHghgBAQEEAQEBDwElAi4GCwwEBwQRBAEBAR4JBxkOHwgBCAYTCRIHh2gMmGqfbIs3EIYrA4hCjXSJcIMVgWaCfg X-IronPort-AV: E=Sophos;i="4.75,793,1330905600"; d="scan'208";a="49314091" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 18 Jun 2012 19:29:46 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5IJTjke032336; Mon, 18 Jun 2012 19:29:46 GMT Message-Id: <201206181929.q5IJTjke032336@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 18 Jun 2012 14:29:45 -0500 To: From: James Polk In-Reply-To: <010201cd4ce1$88a723a0$99f56ae0$@packetizer.com> References: <20120617232517.4355.36096.idtracker@ietfa.amsl.com> <010201cd4ce1$88a723a0$99f56ae0$@packetizer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Hadriel Kaplan Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-reqts-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 19:29:48 -0000 During the last interim, we discussed making the requirements draft a WG item. IMO, this version satisfies each of the comments well enough to propose this document move forward as a WG item, especially considering the timeframes this WG has to work under (i.e., get the solution doc done by December `12). I believe what's left to resolve in the requirements draft is minor and can be worked on while a WG item over the next few months to the point of consensus. Agreed? James At 06:33 PM 6/17/2012, Paul E. Jones wrote: >Folks, > >I posted a revised version of the requirements document. This version moves >the use cases in front of the actual requirements. > >We discussed having more fleshed out use cases. I'm happy to insert those >if somebody will provide the appropriate text. > >Also, there are two requirements that we reviewed on the last call that need >further input. > >REQ1a: This is intended to be a requirement like REQ1, but focused on >non-dialog creating transactions. If we wish to introduce this requirement, >please provide appropriate text. > >REQ6: This was changed and we discussed merging it with REQ5. I'm OK with >that approach, but the original requirement was to not provide any hint that >a middlebox changed anything. I know Partha is favorable to a merge and >dropping REQ6 entirely. Hadriel, what's your preference? Others? > >Paul > > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > > On Behalf Of internet-drafts@ietf.org > > Sent: Sunday, June 17, 2012 7:25 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-jones-insipid-session-id-reqts-02.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Requirements for an End-to-End Session > > Identification in IP-Based Multimedia Communication Networks > > Author(s) : Paul E. Jones > > Gonzalo Salgueiro > > James Polk > > Parthasarathi Ravindran > > Laura Liess > > Roland Jesske > > Salvatore Loreto > > Hadriel Kaplan > > Filename : draft-jones-insipid-session-id-reqts-02.txt > > Pages : 9 > > Date : 2012-06-17 > > > > Abstract: > > This document specifies the requirements for an end-to-end session > > identifier in IP-based multimedia communication networks. This > > identifier would enable endpoints, intermediate devices, and > > management and monitoring systems to identify a session end-to-end, > > associate multiple endpoints with a given multipoint conference, > > track communication sessions when they are redirected, and associate > > one or more media flows with a given communication session. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-jones-insipid-session-id-reqts > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-02 > > > > A diff from previous version is available at: > > http://tools.ietf.org/rfcdiff?url2=draft-jones-insipid-session-id-reqts-02 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From laura.liess.dt@googlemail.com Mon Jun 25 04:57:39 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3845E21F84F0 for ; Mon, 25 Jun 2012 04:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiW9z79qaM-c for ; Mon, 25 Jun 2012 04:57:34 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF6D621F8501 for ; Mon, 25 Jun 2012 04:57:34 -0700 (PDT) Received: by yenq13 with SMTP id q13so2999506yen.31 for ; Mon, 25 Jun 2012 04:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zUwsb+ayeGj0BD3iplCOox2YBaPWzCtUTRGYfdI+z/I=; b=BpILlnP415jUi7Xgklrgejq2OwOOLVbslBbokLuHCQpbT+h9qXZXmHbDGqLkO3oBDO /KMdHYNvwti80z0hoyTMpJx0m9lMohDX+4EF75/soVBTPBY+Nmlz8LUrU8ebdMnYzgLr 8r47jPQEfIHmSxbwHIoRQmen0M8QMwSouKZ06shDOsbfPWq9SaHThw20v1OMoWpF5Ugq s1egNXfL00HOUeDVvSp/9f1Ll+Lp76ZGtOrfH6PA+tCfWgjB6mBhfqHp+8jZPmwDWaOh Vf/bdcB36rZw+FajC2R6c2NA1K+6MDiINhDShHcifrKUU+3br0PSmoHQjXoSoH47E1d9 1Haw== MIME-Version: 1.0 Received: by 10.50.100.226 with SMTP id fb2mr7879358igb.31.1340625453968; Mon, 25 Jun 2012 04:57:33 -0700 (PDT) Received: by 10.231.10.130 with HTTP; Mon, 25 Jun 2012 04:57:33 -0700 (PDT) In-Reply-To: <010201cd4ce1$88a723a0$99f56ae0$@packetizer.com> References: <20120617232517.4355.36096.idtracker@ietfa.amsl.com> <010201cd4ce1$88a723a0$99f56ae0$@packetizer.com> Date: Mon, 25 Jun 2012 13:57:33 +0200 Message-ID: From: Laura Liess To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: insipid@ietf.org, Hadriel Kaplan Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-reqts-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 11:57:39 -0000 Paul, If more detailed text for the use cases is needed, I think the best way to provide the text is if people provide use case text for the requirements they are interested in. I could try to provide the use case text for REQ1, REQ4, REQ5 and REQ7. But it is not clear for me if this is needed or not. Thanks Laura 2012/6/18 Paul E. Jones : > Folks, > > I posted a revised version of the requirements document. =A0This version = moves > the use cases in front of the actual requirements.> > We discussed having more fleshed out use cases. =A0I'm happy to insert th= ose > if somebody will provide the appropriate text. > > Also, there are two requirements that we reviewed on the last call that n= eed > further input. > > REQ1a: This is intended to be a requirement like REQ1, but focused on > non-dialog creating transactions. =A0If we wish to introduce this require= ment, > please provide appropriate text. > > REQ6: This was changed and we discussed merging it with REQ5. =A0I'm OK w= ith > that approach, but the original requirement was to not provide any hint t= hat > a middlebox changed anything. =A0I know Partha is favorable to a merge an= d > dropping REQ6 entirely. =A0Hadriel, what's your preference? =A0Others? > > Paul > >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.or= g] >> On Behalf Of internet-drafts@ietf.org >> Sent: Sunday, June 17, 2012 7:25 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-jones-insipid-session-id-reqts-02.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Requirements for an End-to-End S= ession >> Identification in IP-Based Multimedia Communication Networks >> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Paul E. Jones >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gonzalo Salgueiro >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 James Polk >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Parthasarathi Ravind= ran >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Laura Liess >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Roland Jesske >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Salvatore Loreto >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hadriel Kaplan >> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-jones-insipid-session-id-req= ts-02.txt >> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 9 >> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-06-17 >> >> Abstract: >> =A0 =A0This document specifies the requirements for an end-to-end sessio= n >> =A0 =A0identifier in IP-based multimedia communication networks. =A0This >> =A0 =A0identifier would enable endpoints, intermediate devices, and >> =A0 =A0management and monitoring systems to identify a session end-to-en= d, >> =A0 =A0associate multiple endpoints with a given multipoint conference, >> =A0 =A0track communication sessions when they are redirected, and associ= ate >> =A0 =A0one or more media flows with a given communication session. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-jones-insipid-session-id-reqts >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-02 >> >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-jones-insipid-session-id-reqt= s-02 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From andrew.hutton@siemens-enterprise.com Mon Jun 25 07:04:03 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF92321F85CE for ; Mon, 25 Jun 2012 07:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbmX3RxybZWv for ; Mon, 25 Jun 2012 07:04:03 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id B2D7821F8649 for ; Mon, 25 Jun 2012 07:04:02 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 4EAD923F049B; Mon, 25 Jun 2012 16:04:00 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.34]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Mon, 25 Jun 2012 16:03:59 +0200 From: "Hutton, Andrew" To: Laura Liess , "Paul E. Jones" Thread-Topic: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-reqts-02.txt Thread-Index: AQHNTOGLzWQghsMglUCouOmlwiNmVZcK2B6AgAA8XpA= Date: Mon, 25 Jun 2012 14:03:59 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF02EF74@MCHP04MSX.global-ad.net> References: <20120617232517.4355.36096.idtracker@ietfa.amsl.com> <010201cd4ce1$88a723a0$99f56ae0$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.250.209] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "insipid@ietf.org" , Hadriel Kaplan Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-reqts-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 14:04:04 -0000 Hi, I already provided text for the recording use case see http://www.ietf.org/= mail-archive/web/insipid/current/msg00127.html. Regarding the comments I made in the 01 draft and the response from Paul I = don't think any related changes have found their way in to the 02 draft (Se= e http://www.ietf.org/mail-archive/web/insipid/current/msg00124.html).=20 For example the proposed change to the wording of the use case "Identificat= ion of devices taking part in the same multipoint conference" to something = like "Association of sessions taking part in the same multipoint conference= " has not been made. For me the main problem area is likely to be the forwarding/transfer use ca= se which could potentially open up a lot of issues so I would like to see s= ome use cases in this area to understand in more details what scenarios the= authors want to cover.=20 Regarding adoption then I don't see any reason to hold up adoption and will= try to contribute once it is adopted. Regards Andy > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Laura Liess > Sent: 25 June 2012 07:58 > To: Paul E. Jones > Cc: insipid@ietf.org; Hadriel Kaplan > Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id- > reqts-02.txt >=20 > Paul, >=20 > If more detailed text for the use cases is needed, I think the best > way to provide the text is if people provide use case text for the > requirements they are interested in. I could try to provide the use > case text for REQ1, REQ4, REQ5 and REQ7. But it is not clear for me > if this is needed or not. >=20 > Thanks > Laura >=20 > 2012/6/18 Paul E. Jones : > > Folks, > > > > I posted a revised version of the requirements document. =A0This > version moves > > the use cases in front of the actual requirements.> > > We discussed having more fleshed out use cases. =A0I'm happy to insert > those > > if somebody will provide the appropriate text. > > > > Also, there are two requirements that we reviewed on the last call > that need > > further input. > > > > REQ1a: This is intended to be a requirement like REQ1, but focused on > > non-dialog creating transactions. =A0If we wish to introduce this > requirement, > > please provide appropriate text. > > > > REQ6: This was changed and we discussed merging it with REQ5. =A0I'm OK > with > > that approach, but the original requirement was to not provide any > hint that > > a middlebox changed anything. =A0I know Partha is favorable to a merge > and > > dropping REQ6 entirely. =A0Hadriel, what's your preference? =A0Others? > > > > Paul > > > >> -----Original Message----- > >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] > >> On Behalf Of internet-drafts@ietf.org > >> Sent: Sunday, June 17, 2012 7:25 PM > >> To: i-d-announce@ietf.org > >> Subject: I-D Action: draft-jones-insipid-session-id-reqts-02.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> > >> > >> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Requirements for an End-to-End= Session > >> Identification in IP-Based Multimedia Communication Networks > >> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Paul E. Jones > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gonzalo Salgueiro > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 James Polk > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Parthasarathi Ravi= ndran > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Laura Liess > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Roland Jesske > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Salvatore Loreto > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hadriel Kaplan > >> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-jones-insipid-session-id-r= eqts-02.txt > >> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 9 > >> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-06-17 > >> > >> Abstract: > >> =A0 =A0This document specifies the requirements for an end-to-end > session > >> =A0 =A0identifier in IP-based multimedia communication networks. =A0Th= is > >> =A0 =A0identifier would enable endpoints, intermediate devices, and > >> =A0 =A0management and monitoring systems to identify a session end-to- > end, > >> =A0 =A0associate multiple endpoints with a given multipoint conference= , > >> =A0 =A0track communication sessions when they are redirected, and > associate > >> =A0 =A0one or more media flows with a given communication session. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-jones-insipid-session-id- > reqts > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-02 > >> > >> A diff from previous version is available at: > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-jones-insipid-session-id- > reqts-02 > >> > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft directories: http://www.ietf.org/shadow.html or > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Mon Jun 25 08:57:37 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B9C21F851C for ; Mon, 25 Jun 2012 08:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0skLPLi3oFt for ; Mon, 25 Jun 2012 08:57:36 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1257821F8504 for ; Mon, 25 Jun 2012 08:57:35 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q5PFvW5g022198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Jun 2012 11:57:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1340639853; bh=2zZsj944kZjpTSBgBxpke3iiDy+C73RTYLKAnTTwI2U=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=cbawev+fQnx8rUSKMgbfd7Qy7hUmsQbff9j5i/EOVP3OK9lMg1g1i4vJyhKHSd97V dXCSd2hDEOPs/lywbfnBYtxaY+jeCMVLLIMThTGWWCPVqxX3x+Yt9mm92rf4fKM52q vml4+UvWarFoAHkiiUwDEHvTbfgtpVVYKty3Em6s= From: "Paul E. Jones" To: "'Hutton, Andrew'" , "'Laura Liess'" References: <20120617232517.4355.36096.idtracker@ietfa.amsl.com> <010201cd4ce1$88a723a0$99f56ae0$@packetizer.com> <9F33F40F6F2CD847824537F3C4E37DDF02EF74@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF02EF74@MCHP04MSX.global-ad.net> Date: Mon, 25 Jun 2012 11:57:35 -0400 Message-ID: <013a01cd52eb$3d65b400$b8311c00$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKbPwDOuqTQ0fTS5+A0WOj09+LQAwGtWVMkAgavaNsBRSI9j5VHjp3w Content-Language: en-us Cc: insipid@ietf.org, 'Hadriel Kaplan' Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-reqts-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 15:57:37 -0000 Andrew, Thanks. I put that in my current draft. I'm not sure how to organize it right now, but perhaps section 3.x might be "Use Cases" and then 3.1 = would be "Session Recording" (containing your text) and 3.2 might be another detailed use case. I'm open to suggestions. Do we need to indicate "Derived Requirements" as was done for the RTCWeb requirements document? Paul > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > Sent: Monday, June 25, 2012 10:04 AM > To: Laura Liess; Paul E. Jones > Cc: insipid@ietf.org; Hadriel Kaplan > Subject: RE: [Insipid] FW: I-D Action: draft-jones-insipid-session-id- > reqts-02.txt >=20 > Hi, >=20 > I already provided text for the recording use case see > http://www.ietf.org/mail-archive/web/insipid/current/msg00127.html. >=20 > Regarding the comments I made in the 01 draft and the response from = Paul I > don't think any related changes have found their way in to the 02 = draft > (See = http://www.ietf.org/mail-archive/web/insipid/current/msg00124.html). >=20 > For example the proposed change to the wording of the use case > "Identification of devices taking part in the same multipoint = conference" > to something like "Association of sessions taking part in the same > multipoint conference" has not been made. >=20 > For me the main problem area is likely to be the forwarding/transfer = use > case which could potentially open up a lot of issues so I would like = to > see some use cases in this area to understand in more details what > scenarios the authors want to cover. >=20 > Regarding adoption then I don't see any reason to hold up adoption and > will try to contribute once it is adopted. >=20 > Regards > Andy >=20 > > -----Original Message----- > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > Behalf Of Laura Liess > > Sent: 25 June 2012 07:58 > > To: Paul E. Jones > > Cc: insipid@ietf.org; Hadriel Kaplan > > Subject: Re: [Insipid] FW: I-D Action: = draft-jones-insipid-session-id- > > reqts-02.txt > > > > Paul, > > > > If more detailed text for the use cases is needed, I think the best > > way to provide the text is if people provide use case text for the > > requirements they are interested in. I could try to provide the = use > > case text for REQ1, REQ4, REQ5 and REQ7. But it is not clear for = me > > if this is needed or not. > > > > Thanks > > Laura > > > > 2012/6/18 Paul E. Jones : > > > Folks, > > > > > > I posted a revised version of the requirements document. =A0This > > version moves > > > the use cases in front of the actual requirements.> We discussed > > > having more fleshed out use cases. =A0I'm happy to insert > > those > > > if somebody will provide the appropriate text. > > > > > > Also, there are two requirements that we reviewed on the last call > > that need > > > further input. > > > > > > REQ1a: This is intended to be a requirement like REQ1, but focused > > > on non-dialog creating transactions. =A0If we wish to introduce = this > > requirement, > > > please provide appropriate text. > > > > > > REQ6: This was changed and we discussed merging it with REQ5. = =A0I'm > > > OK > > with > > > that approach, but the original requirement was to not provide any > > hint that > > > a middlebox changed anything. =A0I know Partha is favorable to a = merge > > and > > > dropping REQ6 entirely. =A0Hadriel, what's your preference? = =A0Others? > > > > > > Paul > > > > > >> -----Original Message----- > > >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > > bounces@ietf.org] > > >> On Behalf Of internet-drafts@ietf.org > > >> Sent: Sunday, June 17, 2012 7:25 PM > > >> To: i-d-announce@ietf.org > > >> Subject: I-D Action: draft-jones-insipid-session-id-reqts-02.txt > > >> > > >> > > >> A New Internet-Draft is available from the on-line = Internet-Drafts > > >> directories. > > >> > > >> > > >> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Requirements for an = End-to-End Session > > >> Identification in IP-Based Multimedia Communication Networks > > >> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Paul E. Jones > > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gonzalo = Salgueiro > > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 James Polk > > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Parthasarathi = Ravindran > > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Laura Liess > > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Roland Jesske > > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Salvatore = Loreto > > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hadriel = Kaplan > > >> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: = draft-jones-insipid-session-id-reqts-02.txt > > >> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 9 > > >> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-06-17 > > >> > > >> Abstract: > > >> =A0 =A0This document specifies the requirements for an end-to-end > > session > > >> =A0 =A0identifier in IP-based multimedia communication networks. = =A0This > > >> =A0 =A0identifier would enable endpoints, intermediate devices, = and > > >> =A0 =A0management and monitoring systems to identify a session = end-to- > > end, > > >> =A0 =A0associate multiple endpoints with a given multipoint = conference, > > >> =A0 =A0track communication sessions when they are redirected, and > > associate > > >> =A0 =A0one or more media flows with a given communication = session. > > >> > > >> > > >> The IETF datatracker status page for this draft is: > > >> https://datatracker.ietf.org/doc/draft-jones-insipid-session-id- > > reqts > > >> > > >> There's also a htmlized version available at: > > >> = http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-02 > > >> > > >> A diff from previous version is available at: > > >> = http://tools.ietf.org/rfcdiff?url2=3Ddraft-jones-insipid-session-id- > > reqts-02 > > >> > > >> > > >> Internet-Drafts are also available by anonymous FTP at: > > >> ftp://ftp.ietf.org/internet-drafts/ > > >> > > >> _______________________________________________ > > >> I-D-Announce mailing list > > >> I-D-Announce@ietf.org > > >> https://www.ietf.org/mailman/listinfo/i-d-announce > > >> Internet-Draft directories: http://www.ietf.org/shadow.html or > > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > _______________________________________________ > > > insipid mailing list > > > insipid@ietf.org > > > https://www.ietf.org/mailman/listinfo/insipid > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid From laura.liess.dt@googlemail.com Mon Jun 25 09:03:02 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4266711E808F for ; Mon, 25 Jun 2012 09:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89O7uAt12Epm for ; Mon, 25 Jun 2012 09:02:55 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EBA8711E8073 for ; Mon, 25 Jun 2012 09:02:54 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3284924ggn.31 for ; Mon, 25 Jun 2012 09:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dsVzs2/Ds83lmrJqCAaVoqGaVp4DCyngXSKIN59DKdA=; b=LAmPnjahe89Zx+VBGxP15CdeV3nTyS8s7AmEdH/Lj0zwZrVQCIFzNE+27hT6HZHOaK H27G6WVzgBnLyVitc6FjMqPyUiumjO1LGQXcs+kiEAxRSQguA+AyklTNQqlvrEB1GggN +OulXPNdgmv86mx3jjEt/6+iA8NzjLsTQ2fKqYFRXus3BeAkAdnTcSGz42MNBPsw82Iw JIKNCfSF7DymwsVI2KvbuK3XugQCL8bYc2y5ea3qVpZWOlPo3SnVqOym4IX2E0aeEhAy gm3h2/PLz8h85d4NjpRY2YcwV19lf/b9FBngPnJyykxnoj4+FkEldM7i1r2drKFPNn8Y gFgw== MIME-Version: 1.0 Received: by 10.50.46.132 with SMTP id v4mr8495264igm.25.1340640174221; Mon, 25 Jun 2012 09:02:54 -0700 (PDT) Received: by 10.231.10.130 with HTTP; Mon, 25 Jun 2012 09:02:54 -0700 (PDT) In-Reply-To: <013a01cd52eb$3d65b400$b8311c00$@packetizer.com> References: <20120617232517.4355.36096.idtracker@ietfa.amsl.com> <010201cd4ce1$88a723a0$99f56ae0$@packetizer.com> <9F33F40F6F2CD847824537F3C4E37DDF02EF74@MCHP04MSX.global-ad.net> <013a01cd52eb$3d65b400$b8311c00$@packetizer.com> Date: Mon, 25 Jun 2012 18:02:54 +0200 Message-ID: From: Laura Liess To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: insipid@ietf.org, "Hutton, Andrew" , Hadriel Kaplan Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-reqts-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 16:03:02 -0000 > Do we need to indicate "Derived Requirements" as was done for the RTCWeb > requirements document? I think this could be usefull in later discussions an ist not difficult to do for the guy describing the use case. I think we should do it. Thanks Laura 2012/6/25 Paul E. Jones : > Andrew, > > Thanks. I put that in my current draft. =A0I'm not sure how to organize i= t > right now, but perhaps section 3.x might be "Use Cases" and then 3.1 woul= d > be "Session Recording" (containing your text) and 3.2 might be another > detailed use case. =A0I'm open to suggestions. > > Do we need to indicate "Derived Requirements" as was done for the RTCWeb > requirements document? > > Paul > >> -----Original Message----- >> From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >> Sent: Monday, June 25, 2012 10:04 AM >> To: Laura Liess; Paul E. Jones >> Cc: insipid@ietf.org; Hadriel Kaplan >> Subject: RE: [Insipid] FW: I-D Action: draft-jones-insipid-session-id- >> reqts-02.txt >> >> Hi, >> >> I already provided text for the recording use case see >> http://www.ietf.org/mail-archive/web/insipid/current/msg00127.html. >> >> Regarding the comments I made in the 01 draft and the response from Paul= I >> don't think any related changes have found their way in to the 02 draft >> (See http://www.ietf.org/mail-archive/web/insipid/current/msg00124.html)= . >> >> For example the proposed change to the wording of the use case >> "Identification of devices taking part in the same multipoint conference= " >> to something like "Association of sessions taking part in the same >> multipoint conference" has not been made. >> >> For me the main problem area is likely to be the forwarding/transfer use >> case which could potentially open up a lot of issues so I would like to >> see some use cases in this area to understand in more details what >> scenarios the authors want to cover. >> >> Regarding adoption then I don't see any reason to hold up adoption and >> will try to contribute once it is adopted. >> >> Regards >> Andy >> >> > -----Original Message----- >> > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> > Behalf Of Laura Liess >> > Sent: 25 June 2012 07:58 >> > To: Paul E. Jones >> > Cc: insipid@ietf.org; Hadriel Kaplan >> > Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id- >> > reqts-02.txt >> > >> > Paul, >> > >> > If more detailed text for the use cases is needed, I think the best >> > way to provide the text is if people provide use case =A0text for the >> > requirements =A0they are interested in. I could try to provide the =A0= use >> > case =A0text for REQ1, REQ4, REQ5 and REQ7. =A0But it is not clear for= me >> > if this is needed or not. >> > >> > Thanks >> > Laura >> > >> > 2012/6/18 Paul E. Jones : >> > > Folks, >> > > >> > > I posted a revised version of the requirements document. =A0This >> > version moves >> > > the use cases in front of the actual requirements.> We discussed >> > > having more fleshed out use cases. =A0I'm happy to insert >> > those >> > > if somebody will provide the appropriate text. >> > > >> > > Also, there are two requirements that we reviewed on the last call >> > that need >> > > further input. >> > > >> > > REQ1a: This is intended to be a requirement like REQ1, but focused >> > > on non-dialog creating transactions. =A0If we wish to introduce this >> > requirement, >> > > please provide appropriate text. >> > > >> > > REQ6: This was changed and we discussed merging it with REQ5. =A0I'm >> > > OK >> > with >> > > that approach, but the original requirement was to not provide any >> > hint that >> > > a middlebox changed anything. =A0I know Partha is favorable to a mer= ge >> > and >> > > dropping REQ6 entirely. =A0Hadriel, what's your preference? =A0Other= s? >> > > >> > > Paul >> > > >> > >> -----Original Message----- >> > >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- >> > bounces@ietf.org] >> > >> On Behalf Of internet-drafts@ietf.org >> > >> Sent: Sunday, June 17, 2012 7:25 PM >> > >> To: i-d-announce@ietf.org >> > >> Subject: I-D Action: draft-jones-insipid-session-id-reqts-02.txt >> > >> >> > >> >> > >> A New Internet-Draft is available from the on-line Internet-Drafts >> > >> directories. >> > >> >> > >> >> > >> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Requirements for an End-to-= End Session >> > >> Identification in IP-Based Multimedia Communication Networks >> > >> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Paul E. Jones >> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gonzalo Salguei= ro >> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 James Polk >> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Parthasarathi R= avindran >> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Laura Liess >> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Roland Jesske >> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Salvatore Loret= o >> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hadriel Kaplan >> > >> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-jones-insipid-session-i= d-reqts-02.txt >> > >> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 9 >> > >> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-06-17 >> > >> >> > >> Abstract: >> > >> =A0 =A0This document specifies the requirements for an end-to-end >> > session >> > >> =A0 =A0identifier in IP-based multimedia communication networks. = =A0This >> > >> =A0 =A0identifier would enable endpoints, intermediate devices, and >> > >> =A0 =A0management and monitoring systems to identify a session end-= to- >> > end, >> > >> =A0 =A0associate multiple endpoints with a given multipoint confere= nce, >> > >> =A0 =A0track communication sessions when they are redirected, and >> > associate >> > >> =A0 =A0one or more media flows with a given communication session. >> > >> >> > >> >> > >> The IETF datatracker status page for this draft is: >> > >> https://datatracker.ietf.org/doc/draft-jones-insipid-session-id- >> > reqts >> > >> >> > >> There's also a htmlized version available at: >> > >> http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-02 >> > >> >> > >> A diff from previous version is available at: >> > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-jones-insipid-session-id= - >> > reqts-02 >> > >> >> > >> >> > >> Internet-Drafts are also available by anonymous FTP at: >> > >> ftp://ftp.ietf.org/internet-drafts/ >> > >> >> > >> _______________________________________________ >> > >> I-D-Announce mailing list >> > >> I-D-Announce@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/i-d-announce >> > >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > >> > > _______________________________________________ >> > > insipid mailing list >> > > insipid@ietf.org >> > > https://www.ietf.org/mailman/listinfo/insipid >> > _______________________________________________ >> > insipid mailing list >> > insipid@ietf.org >> > https://www.ietf.org/mailman/listinfo/insipid > From andrew.hutton@siemens-enterprise.com Mon Jun 25 09:32:20 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D259821F849B for ; Mon, 25 Jun 2012 09:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CV4rgpM3uAI for ; Mon, 25 Jun 2012 09:32:20 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3A24121F8499 for ; Mon, 25 Jun 2012 09:32:18 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 5EA981EB8475; Mon, 25 Jun 2012 18:32:17 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.34]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Mon, 25 Jun 2012 18:32:17 +0200 From: "Hutton, Andrew" To: Laura Liess , "Paul E. Jones" Thread-Topic: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-reqts-02.txt Thread-Index: AQHNUuv828McQeSp8UKPwMJ+xRCsuJcLOjJg Date: Mon, 25 Jun 2012 16:32:16 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF02F1CE@MCHP04MSX.global-ad.net> References: <20120617232517.4355.36096.idtracker@ietfa.amsl.com> <010201cd4ce1$88a723a0$99f56ae0$@packetizer.com> <9F33F40F6F2CD847824537F3C4E37DDF02EF74@MCHP04MSX.global-ad.net> <013a01cd52eb$3d65b400$b8311c00$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.250.209] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "insipid@ietf.org" , Hadriel Kaplan Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-reqts-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 16:32:21 -0000 +1 it would be nice if we could do this. Andy > -----Original Message----- > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > Sent: 25 June 2012 12:03 > To: Paul E. Jones > Cc: Hutton, Andrew; insipid@ietf.org; Hadriel Kaplan > Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id- > reqts-02.txt >=20 > > Do we need to indicate "Derived Requirements" as was done for the > RTCWeb > > requirements document? >=20 > I think this could be usefull in later discussions an ist not > difficult to do for the guy describing the use case. I think we should > do it. >=20 > Thanks > Laura >=20 > 2012/6/25 Paul E. Jones : > > Andrew, > > > > Thanks. I put that in my current draft. =A0I'm not sure how to organize > it > > right now, but perhaps section 3.x might be "Use Cases" and then 3.1 > would > > be "Session Recording" (containing your text) and 3.2 might be > another > > detailed use case. =A0I'm open to suggestions. > > > > Do we need to indicate "Derived Requirements" as was done for the > RTCWeb > > requirements document? > > > > Paul > > > >> -----Original Message----- > >> From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > >> Sent: Monday, June 25, 2012 10:04 AM > >> To: Laura Liess; Paul E. Jones > >> Cc: insipid@ietf.org; Hadriel Kaplan > >> Subject: RE: [Insipid] FW: I-D Action: draft-jones-insipid-session- > id- > >> reqts-02.txt > >> > >> Hi, > >> > >> I already provided text for the recording use case see > >> http://www.ietf.org/mail-archive/web/insipid/current/msg00127.html. > >> > >> Regarding the comments I made in the 01 draft and the response from > Paul I > >> don't think any related changes have found their way in to the 02 > draft > >> (See http://www.ietf.org/mail- > archive/web/insipid/current/msg00124.html). > >> > >> For example the proposed change to the wording of the use case > >> "Identification of devices taking part in the same multipoint > conference" > >> to something like "Association of sessions taking part in the same > >> multipoint conference" has not been made. > >> > >> For me the main problem area is likely to be the forwarding/transfer > use > >> case which could potentially open up a lot of issues so I would like > to > >> see some use cases in this area to understand in more details what > >> scenarios the authors want to cover. > >> > >> Regarding adoption then I don't see any reason to hold up adoption > and > >> will try to contribute once it is adopted. > >> > >> Regards > >> Andy > >> > >> > -----Original Message----- > >> > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] > On > >> > Behalf Of Laura Liess > >> > Sent: 25 June 2012 07:58 > >> > To: Paul E. Jones > >> > Cc: insipid@ietf.org; Hadriel Kaplan > >> > Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid- > session-id- > >> > reqts-02.txt > >> > > >> > Paul, > >> > > >> > If more detailed text for the use cases is needed, I think the > best > >> > way to provide the text is if people provide use case =A0text for > the > >> > requirements =A0they are interested in. I could try to provide the > =A0use > >> > case =A0text for REQ1, REQ4, REQ5 and REQ7. =A0But it is not clear f= or > me > >> > if this is needed or not. > >> > > >> > Thanks > >> > Laura > >> > > >> > 2012/6/18 Paul E. Jones : > >> > > Folks, > >> > > > >> > > I posted a revised version of the requirements document. =A0This > >> > version moves > >> > > the use cases in front of the actual requirements.> We discussed > >> > > having more fleshed out use cases. =A0I'm happy to insert > >> > those > >> > > if somebody will provide the appropriate text. > >> > > > >> > > Also, there are two requirements that we reviewed on the last > call > >> > that need > >> > > further input. > >> > > > >> > > REQ1a: This is intended to be a requirement like REQ1, but > focused > >> > > on non-dialog creating transactions. =A0If we wish to introduce > this > >> > requirement, > >> > > please provide appropriate text. > >> > > > >> > > REQ6: This was changed and we discussed merging it with REQ5. > =A0I'm > >> > > OK > >> > with > >> > > that approach, but the original requirement was to not provide > any > >> > hint that > >> > > a middlebox changed anything. =A0I know Partha is favorable to a > merge > >> > and > >> > > dropping REQ6 entirely. =A0Hadriel, what's your preference? > =A0Others? > >> > > > >> > > Paul > >> > > > >> > >> -----Original Message----- > >> > >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > >> > bounces@ietf.org] > >> > >> On Behalf Of internet-drafts@ietf.org > >> > >> Sent: Sunday, June 17, 2012 7:25 PM > >> > >> To: i-d-announce@ietf.org > >> > >> Subject: I-D Action: draft-jones-insipid-session-id-reqts- > 02.txt > >> > >> > >> > >> > >> > >> A New Internet-Draft is available from the on-line Internet- > Drafts > >> > >> directories. > >> > >> > >> > >> > >> > >> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Requirements for an End-t= o-End Session > >> > >> Identification in IP-Based Multimedia Communication Networks > >> > >> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Paul E. Jones > >> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gonzalo Salgu= eiro > >> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 James Polk > >> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Parthasarathi= Ravindran > >> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Laura Liess > >> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Roland Jesske > >> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Salvatore Lor= eto > >> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hadriel Kapla= n > >> > >> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-jones-insipid-session= -id-reqts- > 02.txt > >> > >> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 9 > >> > >> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-06-17 > >> > >> > >> > >> Abstract: > >> > >> =A0 =A0This document specifies the requirements for an end-to-end > >> > session > >> > >> =A0 =A0identifier in IP-based multimedia communication networks. > =A0This > >> > >> =A0 =A0identifier would enable endpoints, intermediate devices, a= nd > >> > >> =A0 =A0management and monitoring systems to identify a session en= d- > to- > >> > end, > >> > >> =A0 =A0associate multiple endpoints with a given multipoint > conference, > >> > >> =A0 =A0track communication sessions when they are redirected, and > >> > associate > >> > >> =A0 =A0one or more media flows with a given communication session= . > >> > >> > >> > >> > >> > >> The IETF datatracker status page for this draft is: > >> > >> https://datatracker.ietf.org/doc/draft-jones-insipid-session- > id- > >> > reqts > >> > >> > >> > >> There's also a htmlized version available at: > >> > >> http://tools.ietf.org/html/draft-jones-insipid-session-id- > reqts-02 > >> > >> > >> > >> A diff from previous version is available at: > >> > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-jones-insipid-session- > id- > >> > reqts-02 > >> > >> > >> > >> > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> > >> > >> _______________________________________________ > >> > >> I-D-Announce mailing list > >> > >> I-D-Announce@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> > >> Internet-Draft directories: http://www.ietf.org/shadow.html or > >> > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > > > >> > > _______________________________________________ > >> > > insipid mailing list > >> > > insipid@ietf.org > >> > > https://www.ietf.org/mailman/listinfo/insipid > >> > _______________________________________________ > >> > insipid mailing list > >> > insipid@ietf.org > >> > https://www.ietf.org/mailman/listinfo/insipid > > From keith.drage@alcatel-lucent.com Tue Jun 26 03:10:56 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F0921F855F for ; Tue, 26 Jun 2012 03:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.762 X-Spam-Level: X-Spam-Status: No, score=-109.762 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MRKHJDWVOw9 for ; Tue, 26 Jun 2012 03:10:55 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6016921F8551 for ; Tue, 26 Jun 2012 03:10:54 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q5QAANtA019089 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 26 Jun 2012 12:10:51 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 26 Jun 2012 12:10:45 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Tue, 26 Jun 2012 12:10:43 +0200 Thread-Topic: Call for WG adoption of text to Thread-Index: Ac1Tg/KbWPYrQuCaRMCVkuYAj8xh5w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: [Insipid] Call for WG adoption of text to X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 10:10:56 -0000 (As WG cochair) In pursuance of the charter milestone: Aug 2012 Requirements and use cases for new identifier sent to IESG (as in= formational) I'd like to issue a call to adopt the text of: draft-jones-insipid-session-id-reqts-03 http://www.ietf.org/id/draft-jones-insipid-session-id-reqts-03.txt=20 for this work. The intent of the milestone is for a document that has: - use cases - requirements - how requirements are derived from the use cases There is still material to be added in this respect, but this can be done a= s a WG item. (And I would encourage all to contribute to the use cases in p= arallel to this call, i.e. separate mail threads).=20 It is also appropriate to respond indicating that only part of the text is = acceptable (in which case we can defer the remaining text for further consi= deration as input to the deliverable). Note that the text does not have to be perfect at this stage, merely that y= ou believe the text is appropriate for progressing by comment and review wi= thin the scope of WG discussions and WGLC. Please respond (Yes, Yes but only for sections ... / except for sections ..= ., or No) by close of business on the 5th July (so that assuming assent, we= can meet the -00 cutoff and issue this as a WG item before IETF#84). Regards Keith From keith.drage@alcatel-lucent.com Tue Jun 26 03:30:32 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A174521F85FB for ; Tue, 26 Jun 2012 03:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.816 X-Spam-Level: X-Spam-Status: No, score=-109.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2u4HVrkJbwZE for ; Tue, 26 Jun 2012 03:30:31 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 95CEA21F85F8 for ; Tue, 26 Jun 2012 03:30:24 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q5QAUJuP004207 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 26 Jun 2012 12:30:23 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 26 Jun 2012 12:30:12 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Tue, 26 Jun 2012 12:30:11 +0200 Thread-Topic: Query on solution draft Thread-Index: Ac1ThqpRNqQDLqPuRV2Mj6m+ovNjUA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [Insipid] Query on solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 10:30:32 -0000 (As individual) The scenario I was trying to explain on the call yesterday was as follows. (I agree it is a bit contrived as stated, but I am convinced all the elemen= ts of it exist in the multiple call multiple in progress transfers that exi= st on attendants consoles on enterprise networks). A calls B A makes a second call to B B calls C B makes a second call to B B transfers the first call from A to the first call to C B transfers the second call from A to the second call to C Does the solution provided in draft-jones-insipid-session-id-00 allow me to= : - identify from the session identifier the relationship between the first c= all before transfer and the first call after transfer, and=20 - the relationship between the second call before transfer and the second c= all after transfer=20 at both the UA of user A and at the UA of user C, and if so how? There may be readers who are also interested in doing this at an SBC near e= ach of these users, but that is not my question. Regards Keith From laura.liess.dt@googlemail.com Tue Jun 26 04:26:39 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B7321F8609 for ; Tue, 26 Jun 2012 04:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbATkNXxpf4H for ; Tue, 26 Jun 2012 04:26:38 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7BF21F860B for ; Tue, 26 Jun 2012 04:26:38 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4064719ghb.31 for ; Tue, 26 Jun 2012 04:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DViMrnGRDFT932nY6e5fkdSK3rWF1ijGnfmoBlK/fh4=; b=yQ7lR981gXFcu8u1KrLFaS385AmKTC+uusQW8FgJK7FgzE0hchTdNBMCMuxhD/1jeZ 2pm95NYemSYPdFPFaOZ5V5oH4+x/1ET8ZiWCP9MLAsAFkkyJYkk0sNFWoHmiOnLCVydj eebTIdcsefWvx5+AgknLcPga0lGSPhGMF3F6Dl9V4UDglTEdAwyKRqQw4wg0EWsMJtf4 VXiGmZXtCY75bOgP7HDMyrGX8iQXl3MUB48a6YTsuQ/NnmSZQH8l9WwuASzonYvyvqHp Ggtdl/4975kcIxqItgYxhVgB7JYvGZ1tbFBA4yj95FYSj5oYtCbvkrWwcpMxGP0zl3SR j1Ig== MIME-Version: 1.0 Received: by 10.50.100.226 with SMTP id fb2mr10805070igb.31.1340709997929; Tue, 26 Jun 2012 04:26:37 -0700 (PDT) Received: by 10.231.10.130 with HTTP; Tue, 26 Jun 2012 04:26:37 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jun 2012 13:26:37 +0200 Message-ID: From: Laura Liess To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "insipid@ietf.org" Subject: Re: [Insipid] Call for WG adoption of text to X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 11:26:39 -0000 Hi, I agree to adopt the draft as a WG item. Thanks Laura 2012/6/26 DRAGE, Keith (Keith) : > (As WG cochair) > > In pursuance of the charter milestone: > > Aug 2012 =A0 =A0 =A0 =A0Requirements and use cases for new identifier sen= t to IESG (as informational) > > I'd like to issue a call to adopt the text of: > > draft-jones-insipid-session-id-reqts-03 > > http://www.ietf.org/id/draft-jones-insipid-session-id-reqts-03.txt > > for this work. > > The intent of the milestone is for a document that has: > - =A0 =A0 =A0 use cases > - =A0 =A0 =A0 requirements > - =A0 =A0 =A0 how requirements are derived from the use cases > > There is still material to be added in this respect, but this can be done= as a WG item. (And I would encourage all to contribute to the use cases in= parallel to this call, i.e. separate mail threads). > > It is also appropriate to respond indicating that only part of the text i= s acceptable (in which case we can defer the remaining text for further con= sideration as input to the deliverable). > > Note that the text does not have to be perfect at this stage, merely that= you believe the text is appropriate for progressing by comment and review = within the scope of WG discussions and WGLC. > > Please respond (Yes, Yes but only for sections ... / except for sections = ..., or No) by close of business on the 5th July (so that assuming assent, = we can meet the -00 cutoff and issue this as a WG item before IETF#84). > > Regards > > Keith > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From jmpolk@cisco.com Tue Jun 26 11:59:57 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F0D11E809B for ; Tue, 26 Jun 2012 11:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.444 X-Spam-Level: X-Spam-Status: No, score=-110.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDxxdEzcxg6t for ; Tue, 26 Jun 2012 11:59:56 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 73B4211E808A for ; Tue, 26 Jun 2012 11:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1979; q=dns/txt; s=iport; t=1340737196; x=1341946796; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=DgNf9AijNwQSW8o/Zxdyrd/lKhEtG8H9XtCeChi+E8I=; b=KBYUExYxq+9AogxKlhkvlzdAHQqbXqy7Xuv/QhqD91ajnDIBnAueDRic wNIxi0tmHuYv3jGdTrjIqzPG9pYC+DC2hQtfSXFoDfD5/XhNiGXxXVHM/ KzYTyr32NyQNAzLEEM38pclZ2jfj71fJtoMsh4W5nuWPjQIX2kjGFf0AM E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAK4F6k+rRDoJ/2dsb2JhbABEAbY0gQeCGAEBAQQBAQEPAQobAjQGBRAHBBgeEBkOMAYTCRmHaAyZFaBIizcahWoDiEqbBYFmgn2BQQ X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="47680267" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 26 Jun 2012 18:59:56 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5QIxtn8032320; Tue, 26 Jun 2012 18:59:55 GMT Message-Id: <201206261859.q5QIxtn8032320@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Jun 2012 13:59:55 -0500 To: Laura Liess , "DRAGE, Keith (Keith)" From: James Polk In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "insipid@ietf.org" Subject: Re: [Insipid] Call for WG adoption of text to X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 18:59:57 -0000 agreed James At 06:26 AM 6/26/2012, Laura Liess wrote: >Hi, >I agree to adopt the draft as a WG item. > >Thanks >Laura > >2012/6/26 DRAGE, Keith (Keith) : > > (As WG cochair) > > > > In pursuance of the charter milestone: > > > > Aug 2012 Requirements and use cases for new identifier > sent to IESG (as informational) > > > > I'd like to issue a call to adopt the text of: > > > > draft-jones-insipid-session-id-reqts-03 > > > > http://www.ietf.org/id/draft-jones-insipid-session-id-reqts-03.txt > > > > for this work. > > > > The intent of the milestone is for a document that has: > > - use cases > > - requirements > > - how requirements are derived from the use cases > > > > There is still material to be added in this respect, but this can > be done as a WG item. (And I would encourage all to contribute to > the use cases in parallel to this call, i.e. separate mail threads). > > > > It is also appropriate to respond indicating that only part of > the text is acceptable (in which case we can defer the remaining > text for further consideration as input to the deliverable). > > > > Note that the text does not have to be perfect at this stage, > merely that you believe the text is appropriate for progressing by > comment and review within the scope of WG discussions and WGLC. > > > > Please respond (Yes, Yes but only for sections ... / except for > sections ..., or No) by close of business on the 5th July (so that > assuming assent, we can meet the -00 cutoff and issue this as a WG > item before IETF#84). > > > > Regards > > > > Keith > > > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From mary.ietf.barnes@gmail.com Tue Jun 26 12:41:59 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAF021F85A2 for ; Tue, 26 Jun 2012 12:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.642 X-Spam-Level: X-Spam-Status: No, score=-103.642 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iV1iGJrlL3H for ; Tue, 26 Jun 2012 12:41:58 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4960421F846D for ; Tue, 26 Jun 2012 12:41:58 -0700 (PDT) Received: by yenq13 with SMTP id q13so314474yen.31 for ; Tue, 26 Jun 2012 12:41:58 -0700 (PDT) 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=bep/aFLPhkh3fWSXrOpoU7Bey1kbYUI+pmxd98i1iKU=; b=Nrwel78ZTWt7XCA/ss5m9MLrxaX38Qae3wiEBH0Tp6gY/RlrdgYtVMgnEMkZ0zQGVH CxJFXoFAWxY0iULZd2tMTGBNeybyip8TQXrvrwu2y3ix31WvUHU1LeeWG4xV4irREj5r RtAdIDgDrmRDsHxwb57lVOQnNK2zk+5M/0bpVnhdsA0Cte4anmmU0hP6aufLzqcOhwC7 FSBMfScvej2qksuKYLKjnRU/mDnX7Gz7KRfzRTKssZm6wiT3zd93bEgXovWYdKmiU4+P witFxgeH28zK2G1oSZUdYEXh9evMjtFnpQBPaFvz4MVoEhn0M8045Dv/m2xIbJVYXot/ tBHw== MIME-Version: 1.0 Received: by 10.60.18.114 with SMTP id v18mr17617554oed.34.1340739717692; Tue, 26 Jun 2012 12:41:57 -0700 (PDT) Received: by 10.182.38.67 with HTTP; Tue, 26 Jun 2012 12:41:57 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jun 2012 14:41:57 -0500 Message-ID: From: Mary Barnes To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=f46d0444eba59bfc4804c3654a3e Cc: "insipid@ietf.org" Subject: Re: [Insipid] Call for WG adoption of text to X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 19:41:59 -0000 --f46d0444eba59bfc4804c3654a3e Content-Type: text/plain; charset=ISO-8859-1 Yes. On Tuesday, June 26, 2012, DRAGE, Keith (Keith) wrote: > (As WG cochair) > > In pursuance of the charter milestone: > > Aug 2012 Requirements and use cases for new identifier sent to IESG > (as informational) > > I'd like to issue a call to adopt the text of: > > draft-jones-insipid-session-id-reqts-03 > > http://www.ietf.org/id/draft-jones-insipid-session-id-reqts-03.txt > > for this work. > > The intent of the milestone is for a document that has: > - use cases > - requirements > - how requirements are derived from the use cases > > There is still material to be added in this respect, but this can be done > as a WG item. (And I would encourage all to contribute to the use cases in > parallel to this call, i.e. separate mail threads). > > It is also appropriate to respond indicating that only part of the text is > acceptable (in which case we can defer the remaining text for further > consideration as input to the deliverable). > > Note that the text does not have to be perfect at this stage, merely that > you believe the text is appropriate for progressing by comment and review > within the scope of WG discussions and WGLC. > > Please respond (Yes, Yes but only for sections ... / except for sections > ..., or No) by close of business on the 5th July (so that assuming assent, > we can meet the -00 cutoff and issue this as a WG item before IETF#84). > > Regards > > Keith > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > --f46d0444eba59bfc4804c3654a3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes.

On Tuesday, June 26, 2012, DRAGE, Keith (Keith) w= rote:
(As WG cochair)

In pursuance of the charter milestone:

Aug 2012 =A0 =A0 =A0 =A0Requirements and use cases for new identifier sent = to IESG (as informational)

I'd like to issue a call to adopt the text of:

draft-jones-insipid-session-id-reqts-03

http://www.ietf.org/id/draft-jones-insipid-session-id= -reqts-03.txt

for this work.

The intent of the milestone is for a document that has:
- =A0 =A0 =A0 use cases
- =A0 =A0 =A0 requirements
- =A0 =A0 =A0 how requirements are derived from the use cases

There is still material to be added in this respect, but this can be done a= s a WG item. (And I would encourage all to contribute to the use cases in p= arallel to this call, i.e. separate mail threads).

It is also appropriate to respond indicating that only part of the text is = acceptable (in which case we can defer the remaining text for further consi= deration as input to the deliverable).

Note that the text does not have to be perfect at this stage, merely that y= ou believe the text is appropriate for progressing by comment and review wi= thin the scope of WG discussions and WGLC.

Please respond (Yes, Yes but only for sections ... / except for sections ..= ., or No) by close of business on the 5th July (so that assuming assent, we= can meet the -00 cutoff and issue this as a WG item before IETF#84).

Regards

Keith


_______________________________________________
insipid mailing list
insipid@ietf.org
https://www.ietf.org/mailman/listinfo/insipid
--f46d0444eba59bfc4804c3654a3e-- From laura.liess.dt@googlemail.com Wed Jun 27 02:19:29 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B23D21F8663 for ; Wed, 27 Jun 2012 02:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGOxfvVSocRR for ; Wed, 27 Jun 2012 02:19:29 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D4E9F21F865E for ; Wed, 27 Jun 2012 02:19:28 -0700 (PDT) Received: by ggnc4 with SMTP id c4so765893ggn.31 for ; Wed, 27 Jun 2012 02:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Pn1ry7gZTPJ1iy7sj1yh+/CnJkF6buGdlxEJJ1d68K0=; b=FkwSK9yf9UaWNC7quQqpOJ8XxE3o4/LpObNRGrIjHXWamAiAJwG+YHpwbQWWlXLUs4 8zKUBQycMXatiPNQ6BxgjWEhrsbq7ImiEwj+6C/Qk3RFA+M+pSPnHmNuCeMUyAzGiy2T 7wM1/kqZ6wdQZPZduTIgv0mDnZsbiuTAKt9tZzvPYAX8b3VPoj8PUbnqrzqyR+ZS/uVI w9u1EuSAHNZCyzzj6f8w5MIpYa9kflgjF1mByQzzBLMaVSms2Z6fwG7ZRHULFlr7OQDR mgmG5INW0nyp2Iv3btE390ajIfHe+0pCkjszCNTfakMxuBCbW//Rp5uXWywEOAsAtBbS kdjw== MIME-Version: 1.0 Received: by 10.50.219.194 with SMTP id pq2mr800785igc.25.1340788768073; Wed, 27 Jun 2012 02:19:28 -0700 (PDT) Received: by 10.231.10.130 with HTTP; Wed, 27 Jun 2012 02:19:28 -0700 (PDT) Date: Wed, 27 Jun 2012 11:19:28 +0200 Message-ID: From: Laura Liess To: Paul Jones Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "insipid@ietf.org" Subject: [Insipid] Text proposal for the "SIP traffic monitoring" use case X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 09:19:29 -0000 Paul, Please find enclosed a text proposal for the use case "SIP traffic monitori= ng": SIP traffic monitoring UA-A and UA-B communicate using SIP phone calls and SIP messaging with a SIP B2BUA acting as a middlebox. The B2BUA changes any SIP header revealing information related to the SIP user, device or domain identity. The service provider uses an external device to monitor and log =93on the wire=94 all SIP traffic passed through the B2BUA. =A0In case of failures being reported by the customers or of security issues (e.g. theft of service), the service provider has to analyse the logs for the past days or weeks and correlate those messages which where, at some point in time, components of a single end-to-end SIP session (e.g., parts of the same phone call or transfer of the same message). For this scenario, we must consider three particular use cases: a) =A0 =A0 =A0The UA-A and UA-B software can be upgraded by the service pro= vider to support the new identifier. . =A0 =A0 =A0 =A0Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, = REQ8. b) =A0 =A0 =A0Only the UA-A software can be upgraded by the service provide= r to support the new identifier, the UA-B software can not. =A0 =A0 =A0 =A0Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, = REQ7, REQ8. c) =A0 =A0 =A0Neither the UA-A nor the UA-B software can be upgraded by the service provider to support the new identifier, the UA-B software can not. =A0 =A0 =A0 =A0Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, = REQ7, REQ8. Thanks Laura From laura.liess.dt@googlemail.com Wed Jun 27 02:25:06 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189A921F8661 for ; Wed, 27 Jun 2012 02:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJqdtFYRVUHu for ; Wed, 27 Jun 2012 02:25:05 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B11F21F8602 for ; Wed, 27 Jun 2012 02:25:05 -0700 (PDT) Received: by yenq13 with SMTP id q13so767016yen.31 for ; Wed, 27 Jun 2012 02:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=826x+/PybB3x1mzPi+CdGzIRkAMtA/5tTLZXy8B3AsI=; b=QPFdxxWo2V65yuNCzOhyVF596P92F1Uw6KtgRgpUGz5Z0/MLy+6IC7lrQ1Hmebxpvz ww78qpzWtjYgUdtjJW3Os9xypcRHpTLQK2MLfE8cJ3H1SkE0ayR9Y2+uYpgTf/+KJhB0 yNnby8IxJcEK760Ctm0wp3SmYS0S0XHBRm7nuuGjZhCIJ22YHIeKbPDo6GMtPB0hG/kH cutNg110taoxXicltQHDHqohtxKwCLx5ZhvE20Scdpmx2ed2Cv+fQnqOXt+XBZhzFjg0 FSeVseBVTFUQxm3+ZQSq9nvbTS7zqj1koEQKqMm3jh7IDW2hl9A1xrWghobpDKeMz/iZ gaBw== MIME-Version: 1.0 Received: by 10.50.189.135 with SMTP id gi7mr823577igc.8.1340789104857; Wed, 27 Jun 2012 02:25:04 -0700 (PDT) Received: by 10.231.10.130 with HTTP; Wed, 27 Jun 2012 02:25:04 -0700 (PDT) Date: Wed, 27 Jun 2012 11:25:04 +0200 Message-ID: From: Laura Liess To: insipid@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [Insipid] REQ1a X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 09:25:06 -0000 Hi, I think REQ 1a is needed. But I propose, instead of an additional REQ1a, to extend REQ1 and write =93=85.to identify those dialogs, transactions and messages which were at some point=85=94 instead of =93=85.to identify those dialogs which were at some point=85=94 . What do you think? Thanks Laura From salvatore.loreto@ericsson.com Wed Jun 27 03:28:10 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76EB21F869A for ; Wed, 27 Jun 2012 03:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUl3DaE87VCo for ; Wed, 27 Jun 2012 03:28:10 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2906421F85B6 for ; Wed, 27 Jun 2012 03:28:01 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-24-4feae0301bdc Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8E.4C.11869.030EAEF4; Wed, 27 Jun 2012 12:28:00 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.0; Wed, 27 Jun 2012 12:27:59 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E14852326 for ; Wed, 27 Jun 2012 13:27:59 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 01B5153304 for ; Wed, 27 Jun 2012 13:28:00 +0300 (EEST) Received: from n106.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AD9D55316C for ; Wed, 27 Jun 2012 13:27:59 +0300 (EEST) Message-ID: <4FEAE02F.5070000@ericsson.com> Date: Wed, 27 Jun 2012 13:27:59 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070001050107070306000201" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM+Jvra7Bg1f+BqsviljMv/+MyYHRY8mS n0wBjFFcNimpOZllqUX6dglcGZ2TlrEXXFWvmHbUo4HxrUwXIyeHhICJxOOVFxkhbDGJC/fW s3UxcnEICZxilJi8dw+Us4FRoufnHnYI5xKjxMaLB5khnKOMEseuNjBBOPsYJXb3dbGBDOMV 0Ja4NeU0E4jNIqAqcXvHWRYQm03ATOL5wy1A3RwcogLJEn//p0OUC0qcnPkErEREQETi990p 7CC2MFD5j6ZeqPmLGCW2P7kINp9TIFDi1rYHYPOZBcIkrqzph3pCTeLquU3MILaQgJZE79lO pgmMwrOQ7JiFpAXCtpW4MOc6VFxeYvvbOcwQtq7Ehf9TUMQXMLKtYhTOTczMSS830kstykwu Ls7P0ytO3cQIjIqDW36r7mC8c07kEKM0B4uSOK/11j3+QgLpiSWp2ampBalF8UWlOanFhxiZ ODilGhhjGXP4Jt+UrUpdLm7zQJTJ8U1NsubGvmkL4vZPzH2oWvz+Z9fiir+Mzv9v7f8i9WFH 9OTNbROd1oW+aOnYP/Vp09FIn5ovTw9m/b2Q0SqXfOelXqTwOsdvn4rP6okJp84OPhXtVsK9 6eCvXnW7QGafuXkeB5yLJhUc1M02VCjw2LREc7HRD14lluKMREMt5qLiRAA9i6fHWAIAAA== Subject: Re: [Insipid] Call for WG adoption of text to X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 10:28:10 -0000 --------------070001050107070306000201 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit +1 > > On Tuesday, June 26, 2012, DRAGE, Keith (Keith) wrote: > > (As WG cochair) > > In pursuance of the charter milestone: > > Aug 2012 Requirements and use cases for new identifier sent > to IESG (as informational) > > I'd like to issue a call to adopt the text of: > > draft-jones-insipid-session-id-reqts-03 > > http://www.ietf.org/id/draft-jones-insipid-session-id-reqts-03.txt > > for this work. > > The intent of the milestone is for a document that has: > - use cases > - requirements > - how requirements are derived from the use cases > > There is still material to be added in this respect, but this can > be done as a WG item. (And I would encourage all to contribute to > the use cases in parallel to this call, i.e. separate mail threads). > > It is also appropriate to respond indicating that only part of the > text is acceptable (in which case we can defer the remaining text > for further consideration as input to the deliverable). > > Note that the text does not have to be perfect at this stage, > merely that you believe the text is appropriate for progressing by > comment and review within the scope of WG discussions and WGLC. > > Please respond (Yes, Yes but only for sections ... / except for > sections ..., or No) by close of business on the 5th July (so that > assuming assent, we can meet the -00 cutoff and issue this as a WG > item before IETF#84). > > Regards > > Keith > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > --------------070001050107070306000201 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit +1


On Tuesday, June 26, 2012, DRAGE, Keith (Keith) wrote:
(As WG cochair)

In pursuance of the charter milestone:

Aug 2012        Requirements and use cases for new identifier sent to IESG (as informational)

I'd like to issue a call to adopt the text of:

draft-jones-insipid-session-id-reqts-03

http://www.ietf.org/id/draft-jones-insipid-session-id-reqts-03.txt

for this work.

The intent of the milestone is for a document that has:
-       use cases
-       requirements
-       how requirements are derived from the use cases

There is still material to be added in this respect, but this can be done as a WG item. (And I would encourage all to contribute to the use cases in parallel to this call, i.e. separate mail threads).

It is also appropriate to respond indicating that only part of the text is acceptable (in which case we can defer the remaining text for further consideration as input to the deliverable).

Note that the text does not have to be perfect at this stage, merely that you believe the text is appropriate for progressing by comment and review within the scope of WG discussions and WGLC.

Please respond (Yes, Yes but only for sections ... / except for sections ..., or No) by close of business on the 5th July (so that assuming assent, we can meet the -00 cutoff and issue this as a WG item before IETF#84).

Regards

Keith


_______________________________________________
insipid mailing list
insipid@ietf.org
https://www.ietf.org/mailman/listinfo/insipid


--------------070001050107070306000201-- From R.Jesske@telekom.de Wed Jun 27 03:56:39 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6003E21F8685 for ; Wed, 27 Jun 2012 03:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xyMtj4TNs4w for ; Wed, 27 Jun 2012 03:56:38 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id E5BDC21F866B for ; Wed, 27 Jun 2012 03:56:37 -0700 (PDT) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 27 Jun 2012 12:56:28 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 27 Jun 2012 12:56:22 +0200 From: To: , Date: Wed, 27 Jun 2012 12:56:20 +0200 Thread-Topic: [Insipid] Call for WG adoption of text to Thread-Index: Ac1UT5X/Adx2x00mQrWfXaN5hlMrSwAA+FIg Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D1435151789@HE111648.emea1.cds.t-internal.com> References: <4FEAE02F.5070000@ericsson.com> In-Reply-To: <4FEAE02F.5070000@ericsson.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_580BEA5E3B99744AB1F5BFF5E9A3C67D1435151789HE111648emea1_" MIME-Version: 1.0 Subject: Re: [Insipid] Call for WG adoption of text to X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 10:56:39 -0000 --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D1435151789HE111648emea1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 ________________________________ Von: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] Im Auftrag = von Salvatore Loreto Gesendet: Mittwoch, 27. Juni 2012 12:28 An: insipid@ietf.org Betreff: Re: [Insipid] Call for WG adoption of text to +1 On Tuesday, June 26, 2012, DRAGE, Keith (Keith) wrote: (As WG cochair) In pursuance of the charter milestone: Aug 2012 Requirements and use cases for new identifier sent to IESG = (as informational) I'd like to issue a call to adopt the text of: draft-jones-insipid-session-id-reqts-03 http://www.ietf.org/id/draft-jones-insipid-session-id-reqts-03.txt for this work. The intent of the milestone is for a document that has: - use cases - requirements - how requirements are derived from the use cases There is still material to be added in this respect, but this can be done a= s a WG item. (And I would encourage all to contribute to the use cases in p= arallel to this call, i.e. separate mail threads). It is also appropriate to respond indicating that only part of the text is = acceptable (in which case we can defer the remaining text for further consi= deration as input to the deliverable). Note that the text does not have to be perfect at this stage, merely that y= ou believe the text is appropriate for progressing by comment and review wi= thin the scope of WG discussions and WGLC. Please respond (Yes, Yes but only for sections ... / except for sections ..= ., or No) by close of business on the 5th July (so that assuming assent, we= can meet the -00 cutoff and issue this as a WG item before IETF#84). Regards Keith _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D1435151789HE111648emea1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+1

Von: insipid-bounces@ietf.org=20 [mailto:insipid-bounces@ietf.org] Im Auftrag von Salvatore=20 Loreto
Gesendet: Mittwoch, 27. Juni 2012 12:28
An:=20 insipid@ietf.org
Betreff: Re: [Insipid] Call for WG adoption of t= ext=20 to

+1


On Tuesday, June 26, 2012, DRAGE, Keith (Keith) wrote: (As WG cochair)

In pursuance of the charter=20 milestone:

Aug 2012        Requirements and = use=20 cases for new identifier sent to IESG (as informational)

I'd lik= e to=20 issue a call to adopt the text=20 of:

draft-jones-insipid-session-id-reqts-03

http://www.ietf.org/id/draft-jones-insipid-ses= sion-id-reqts-03.txt

for=20 this work.

The intent of the milestone is for a document that=20 has:
-       use cases
-      =20 requirements
-       how requirements are derived fro= m the=20 use cases

There is still material to be added in this respect, b= ut=20 this can be done as a WG item. (And I would encourage all to contribute= to=20 the use cases in parallel to this call, i.e. separate mail=20 threads).

It is also appropriate to respond indicating that only= part=20 of the text is acceptable (in which case we can defer the remaining tex= t for=20 further consideration as input to the deliverable).

Note that th= e=20 text does not have to be perfect at this stage, merely that you believe= the=20 text is appropriate for progressing by comment and review within the sc= ope=20 of WG discussions and WGLC.

Please respond (Yes, Yes but only fo= r=20 sections ... / except for sections ..., or No) by close of business on = the=20 5th July (so that assuming assent, we can meet the -00 cutoff and issue= this=20 as a WG item before=20 IETF#84).

Regards

Keith


______________________= _________________________
insipid=20 mailing list
insipid@ietf.org
= https://www.ietf.org/mailman/listinfo/insipid<= /A>


--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D1435151789HE111648emea1_-- From shida@ntt-at.com Wed Jun 27 04:00:04 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C11221F8653 for ; Wed, 27 Jun 2012 04:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.336 X-Spam-Level: X-Spam-Status: No, score=-101.336 tagged_above=-999 required=5 tests=[AWL=0.928, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Y892zOujFem for ; Wed, 27 Jun 2012 04:00:03 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id B357821F8685 for ; Wed, 27 Jun 2012 04:00:02 -0700 (PDT) Received: from [211.13.69.210] (port=53419 helo=[192.168.1.10]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SjpyX-0008Hz-2c; Wed, 27 Jun 2012 05:59:57 -0500 Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: multipart/alternative; boundary="Apple-Mail=_F99EEEB8-934D-4A95-B85D-A11CBF377D7A" From: Shida Schubert In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D1435151789@HE111648.emea1.cds.t-internal.com> Date: Wed, 27 Jun 2012 19:59:54 +0900 Message-Id: <7768CD54-DD4D-4016-BA27-0C092C169335@ntt-at.com> References: <4FEAE02F.5070000@ericsson.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D1435151789@HE111648.emea1.cds.t-internal.com> To: X-Mailer: Apple Mail (2.1280) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.10]) [211.13.69.210]:53419 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: salvatore.loreto@ericsson.com, insipid@ietf.org Subject: Re: [Insipid] Call for WG adoption of text to X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 11:00:04 -0000 --Apple-Mail=_F99EEEB8-934D-4A95-B85D-A11CBF377D7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1=20 On Jun 27, 2012, at 7:56 PM, = wrote: > +1 >=20 > Von: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] Im = Auftrag von Salvatore Loreto > Gesendet: Mittwoch, 27. Juni 2012 12:28 > An: insipid@ietf.org > Betreff: Re: [Insipid] Call for WG adoption of text to >=20 > +1 >=20 >>=20 >> On Tuesday, June 26, 2012, DRAGE, Keith (Keith) wrote: >> (As WG cochair) >>=20 >> In pursuance of the charter milestone: >>=20 >> Aug 2012 Requirements and use cases for new identifier sent to = IESG (as informational) >>=20 >> I'd like to issue a call to adopt the text of: >>=20 >> draft-jones-insipid-session-id-reqts-03 >>=20 >> http://www.ietf.org/id/draft-jones-insipid-session-id-reqts-03.txt >>=20 >> for this work. >>=20 >> The intent of the milestone is for a document that has: >> - use cases >> - requirements >> - how requirements are derived from the use cases >>=20 >> There is still material to be added in this respect, but this can be = done as a WG item. (And I would encourage all to contribute to the use = cases in parallel to this call, i.e. separate mail threads). >>=20 >> It is also appropriate to respond indicating that only part of the = text is acceptable (in which case we can defer the remaining text for = further consideration as input to the deliverable). >>=20 >> Note that the text does not have to be perfect at this stage, merely = that you believe the text is appropriate for progressing by comment and = review within the scope of WG discussions and WGLC. >>=20 >> Please respond (Yes, Yes but only for sections ... / except for = sections ..., or No) by close of business on the 5th July (so that = assuming assent, we can meet the -00 cutoff and issue this as a WG item = before IETF#84). >>=20 >> Regards >>=20 >> Keith >>=20 >>=20 >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid --Apple-Mail=_F99EEEB8-934D-4A95-B85D-A11CBF377D7A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii R.Jesske@telekom.de> <R.Jesske@telekom.de> = wrote:
+1

Von: insipid-bounces@ietf.org=20 [mailto:insipid-bounces@ietf.org] Im Auftrag von Salvatore=20 Loreto
Gesendet: Mittwoch, 27. Juni 2012 12:28
An:=20= insipid@ietf.org
Betreff: = Re: [Insipid] Call for WG adoption of text=20 to

+1


On Tuesday, June 26, 2012, DRAGE, Keith = (Keith) wrote:
(As WG = cochair)

In pursuance of the charter=20 milestone:

Aug 2012        Requirements = and use=20 cases for new identifier sent to IESG (as informational)

I'd = like to=20 issue a call to adopt the text=20 of:

draft-jones-insipid-session-id-reqts-03

http://www.ietf.org/id/draft-jones-insipid-sessio= n-id-reqts-03.txt

for=20 this work.

The intent of the milestone is for a document that=20= has:
-       use cases
-      =20= requirements
-       how requirements are derived = from the=20 use cases

There is still material to be added in this = respect, but=20 this can be done as a WG item. (And I would encourage all to = contribute to=20 the use cases in parallel to this call, i.e. separate mail=20 threads).

It is also appropriate to respond indicating that = only part=20 of the text is acceptable (in which case we can defer the remaining = text for=20 further consideration as input to the deliverable).

Note that = the=20 text does not have to be perfect at this stage, merely that you = believe the=20 text is appropriate for progressing by comment and review within the = scope=20 of WG discussions and WGLC.

Please respond (Yes, Yes but only = for=20 sections ... / except for sections ..., or No) by close of business = on the=20 5th July (so that assuming assent, we can meet the -00 cutoff and = issue this=20 as a WG item before=20 = IETF#84).

Regards

Keith


_________________________= ______________________
insipid=20 mailing list
insipid@ietf.org
https://www.ietf.org/mailman/listinfo/insipid=


_______________________________________________
insipid mailing = list
insipid@ietf.org
https://www.ietf.= org/mailman/listinfo/insipid

= --Apple-Mail=_F99EEEB8-934D-4A95-B85D-A11CBF377D7A-- From md3135@att.com Wed Jun 27 04:37:31 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77B021F8682 for ; Wed, 27 Jun 2012 04:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92wDyDpwo9oc for ; Wed, 27 Jun 2012 04:37:30 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id E0DFE21F867C for ; Wed, 27 Jun 2012 04:37:29 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 970faef4.2aaadc626940.776203.00-589.2134330.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 27 Jun 2012 11:37:29 +0000 (UTC) X-MXL-Hash: 4feaf0792a06cd0c-9316b6565794b6e48d0650eb4e04c3e1ecd0792f Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 470faef4.0.776187.00-322.2134286.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 27 Jun 2012 11:37:24 +0000 (UTC) X-MXL-Hash: 4feaf0743a9cfe84-faffa2c5cba5155446d7f725be88391a47e51b42 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5RBbNaq024137; Wed, 27 Jun 2012 07:37:24 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5RBbKPQ024134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jun 2012 07:37:20 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by sflint01.pst.cso.att.com (RSA Interceptor); Wed, 27 Jun 2012 07:37:08 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0298.004; Wed, 27 Jun 2012 07:37:08 -0400 From: "DOLLY, MARTIN C" To: "DRAGE, Keith (Keith)" , "insipid@ietf.org" Thread-Topic: [Insipid] Call for WG adoption of text to Thread-Index: Ac1Tg/KbWPYrQuCaRMCVkuYAj8xh5wA1Romg Date: Wed, 27 Jun 2012 11:37:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.82.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=ZA2WezJmpioA:10 a=RV7fWtZah_cA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=48vgC7mUAAAA:8 a=HBZzQ1QjDbzCK7QA5h4A:9 a=] X-AnalysisOut: [CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] Subject: Re: [Insipid] Call for WG adoption of text to X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 11:37:31 -0000 Yes, AT&T is supportive. -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of DRAGE, Keith (Keith) Sent: Tuesday, June 26, 2012 6:11 AM To: insipid@ietf.org Subject: [Insipid] Call for WG adoption of text to (As WG cochair) In pursuance of the charter milestone: Aug 2012 Requirements and use cases for new identifier sent to IESG (as in= formational) I'd like to issue a call to adopt the text of: draft-jones-insipid-session-id-reqts-03 http://www.ietf.org/id/draft-jones-insipid-session-id-reqts-03.txt=20 for this work. The intent of the milestone is for a document that has: - use cases - requirements - how requirements are derived from the use cases There is still material to be added in this respect, but this can be done a= s a WG item. (And I would encourage all to contribute to the use cases in p= arallel to this call, i.e. separate mail threads).=20 It is also appropriate to respond indicating that only part of the text is = acceptable (in which case we can defer the remaining text for further consi= deration as input to the deliverable). Note that the text does not have to be perfect at this stage, merely that y= ou believe the text is appropriate for progressing by comment and review wi= thin the scope of WG discussions and WGLC. Please respond (Yes, Yes but only for sections ... / except for sections ..= ., or No) by close of business on the 5th July (so that assuming assent, we= can meet the -00 cutoff and issue this as a WG item before IETF#84). Regards Keith _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Wed Jun 27 19:38:03 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6115A11E8131 for ; Wed, 27 Jun 2012 19:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4108uhPwRlaa for ; Wed, 27 Jun 2012 19:38:02 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 558DD11E80B8 for ; Wed, 27 Jun 2012 19:37:59 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q5S2buDN026651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 22:37:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1340851077; bh=3YSUCnAAlpjLGOZEIIMT/60dhn5S2ZXEIA/awSLZcVs=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=dj/2EcCGSL5m1RoNpx0vWWm7dB0juU3iWSl2tzS8ennu41/6IH2hQHj800Ls541Mo sJH4wZT8fTyi/lPq0ckgcNsLQa6EH5YtZkYr71DupPzP2zcvBWqXKqLYfPvZZwmd69 qkIUmgTlXgYNJ6bTWBzcJsO7+02z0o/u6PSHJ4g0= From: "Paul E. Jones" To: "'DRAGE, Keith \(Keith\)'" , References: In-Reply-To: Date: Wed, 27 Jun 2012 22:38:04 -0400 Message-ID: <04f201cd54d7$0bb670a0$232351e0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK7RB41zBRhsBQ7e9n1g4StVSTSxZUzGakQ Content-Language: en-us Subject: Re: [Insipid] Query on solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 02:38:03 -0000 Keith, > (I agree it is a bit contrived as stated, but I am convinced all the > elements of it exist in the multiple call multiple in progress transfers > that exist on attendants consoles on enterprise networks). No worries. I like corner cases, myself, as I hate it when things do not work. > A calls B Session ID would be A1 || B1 > A makes a second call to B Session ID would be A2 || B2 > B calls C Session ID would be B3 || C1 > B makes a second call to B I assume you meant C, in which case Session ID would be B4 || C2 > B transfers the first call from A to the first call to C Do you mean is truly transferred a particular call to a particular call? As in a call join? In the case of joining, then A1 || B1 disappears. Also, B3 || C1 disappears. The joined call would have a Session ID of A1 || C1. Now, had B just transferred that first call with A to C, then the session ID might have been A1 || C3 (or something). Then the call B3 || C1 disappears. > B transfers the second call from A to the second call to C Again, I assume this is a call join. We would have a resulting call between A and C with the Session ID A2 || C2. > Does the solution provided in draft-jones-insipid-session-id-00 allow me > to: > > - identify from the session identifier the relationship between the > first call before transfer and the first call after transfer, and One cannot necessarily understand what the relationship is, but one could observe that there is a relationship. > - the relationship between the second call before transfer and the > second call after transfer Same thing. Nothing about the IDs explain what the relationships are. > at both the UA of user A and at the UA of user C, and if so how? > > There may be readers who are also interested in doing this at an SBC near > each of these users, but that is not my question. Exactly what would people want to do? Understand there is a relationship or understand there is a particular type of relationship? Paul From keith.drage@alcatel-lucent.com Thu Jun 28 03:47:11 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C7921F862B for ; Thu, 28 Jun 2012 03:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.899 X-Spam-Level: X-Spam-Status: No, score=-109.899 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2NIVzqbqAm1 for ; Thu, 28 Jun 2012 03:47:11 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id BBC5F21F85E4 for ; Thu, 28 Jun 2012 03:47:06 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q5SAiGHB032377 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Jun 2012 12:47:04 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 28 Jun 2012 12:46:41 +0200 From: "DRAGE, Keith (Keith)" To: "Paul E. Jones" , "insipid@ietf.org" Date: Thu, 28 Jun 2012 12:46:40 +0200 Thread-Topic: [Insipid] Query on solution draft Thread-Index: AQK7RB41zBRhsBQ7e9n1g4StVSTSxZUzGakQgACTdwA= Message-ID: References: <04f201cd54d7$0bb670a0$232351e0$@packetizer.com> In-Reply-To: <04f201cd54d7$0bb670a0$232351e0$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [Insipid] Query on solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 10:47:12 -0000 I was only interested in identifying if a relationship could be identified,= not the form of that relationship, i.e. that in some way call 1 from A-C i= s some reincarnation of call 1 from A-B (as opposed to call 2), not that th= is occurred because B transferred the call to C (that should be handed by s= ervice specific mechanisms where privacy of that information may well be de= fined). But part of my lack of understanding is what happens on the protocol when o= nly half ID's are sent. Any chance of indicating (according to the current draft) which messages ca= rry which half IDs? Keith -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com]=20 Sent: 28 June 2012 03:38 To: DRAGE, Keith (Keith); insipid@ietf.org Subject: RE: [Insipid] Query on solution draft Keith, > (I agree it is a bit contrived as stated, but I am convinced all the > elements of it exist in the multiple call multiple in progress transfers > that exist on attendants consoles on enterprise networks). No worries. I like corner cases, myself, as I hate it when things do not work. =20 > A calls B Session ID would be A1 || B1 > A makes a second call to B Session ID would be A2 || B2 > B calls C Session ID would be B3 || C1 > B makes a second call to B I assume you meant C, in which case Session ID would be B4 || C2 =20 > B transfers the first call from A to the first call to C Do you mean is truly transferred a particular call to a particular call? A= s in a call join? In the case of joining, then A1 || B1 disappears. Also, B3 || C1 disappears. The joined call would have a Session ID of A1 || C1. Now, had B just transferred that first call with A to C, then the session I= D might have been A1 || C3 (or something). Then the call B3 || C1 disappears= . > B transfers the second call from A to the second call to C Again, I assume this is a call join. We would have a resulting call betwee= n A and C with the Session ID A2 || C2. =20 > Does the solution provided in draft-jones-insipid-session-id-00 allow me > to: >=20 > - identify from the session identifier the relationship between the > first call before transfer and the first call after transfer, and One cannot necessarily understand what the relationship is, but one could observe that there is a relationship. =20 > - the relationship between the second call before transfer and the > second call after transfer Same thing. Nothing about the IDs explain what the relationships are. > at both the UA of user A and at the UA of user C, and if so how? > > There may be readers who are also interested in doing this at an SBC near > each of these users, but that is not my question. Exactly what would people want to do? Understand there is a relationship o= r understand there is a particular type of relationship? Paul From andrew.hutton@siemens-enterprise.com Thu Jun 28 07:30:35 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB7421F85D1 for ; Thu, 28 Jun 2012 07:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+-tMRIb7qxm for ; Thu, 28 Jun 2012 07:30:33 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id CAD4721F858F for ; Thu, 28 Jun 2012 07:30:32 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id F0F8123F0556; Thu, 28 Jun 2012 16:30:30 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.34]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Thu, 28 Jun 2012 16:30:30 +0200 From: "Hutton, Andrew" To: "DRAGE, Keith (Keith)" , "insipid@ietf.org" Thread-Topic: [Insipid] Call for WG adoption of text to Thread-Index: Ac1Tg/KbWPYrQuCaRMCVkuYAj8xh5wBtdaBQ Date: Thu, 28 Jun 2012 14:30:29 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF031381@MCHP04MSX.global-ad.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.251.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] Call for WG adoption of text to X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 14:30:35 -0000 Hi, I am ok with adopting this draft. However I still have some concerns about the use case and associated requir= ements relating to associating media with signaling using this identifier. = Although this might be useful in some circumstances I don't think it is wit= hin the scope of the charter and potentially opens up some complexity that = in the interest of getting things done we should avoid. Also we probably need to look more closely at the transfer use cases but we= can do this after adoption. Regards Andy > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of DRAGE, Keith (Keith) > Sent: 26 June 2012 06:11 > To: insipid@ietf.org > Subject: [Insipid] Call for WG adoption of text to >=20 > (As WG cochair) >=20 > In pursuance of the charter milestone: >=20 > Aug 2012 Requirements and use cases for new identifier sent to IESG > (as informational) >=20 > I'd like to issue a call to adopt the text of: >=20 > draft-jones-insipid-session-id-reqts-03 >=20 > http://www.ietf.org/id/draft-jones-insipid-session-id-reqts-03.txt >=20 > for this work. >=20 > The intent of the milestone is for a document that has: > - use cases > - requirements > - how requirements are derived from the use cases >=20 > There is still material to be added in this respect, but this can be > done as a WG item. (And I would encourage all to contribute to the use > cases in parallel to this call, i.e. separate mail threads). >=20 > It is also appropriate to respond indicating that only part of the text > is acceptable (in which case we can defer the remaining text for > further consideration as input to the deliverable). >=20 > Note that the text does not have to be perfect at this stage, merely > that you believe the text is appropriate for progressing by comment and > review within the scope of WG discussions and WGLC. >=20 > Please respond (Yes, Yes but only for sections ... / except for > sections ..., or No) by close of business on the 5th July (so that > assuming assent, we can meet the -00 cutoff and issue this as a WG item > before IETF#84). >=20 > Regards >=20 > Keith >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Thu Jun 28 08:48:33 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99D821F853D for ; Thu, 28 Jun 2012 08:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoGEHOq7Ha5q for ; Thu, 28 Jun 2012 08:48:32 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF0921F8442 for ; Thu, 28 Jun 2012 08:48:32 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q5SFmS5A019629 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Jun 2012 11:48:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1340898508; bh=azc4mh9cVn6G3Eaxwr3D5UVlozQtZ5Oz0yh0ujsHVLc=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=aEbdnAGVoLPTaM7LTMaP5P8NMnowBT472cEENAflgWqomatCnAu6fft5CNbMMy8bp rOxH7SnDjxGTUup1uHJ2wUJ1KZ0xi/8fyJ+/f3qx1KIkk1NlwvkJqLfZgkv7PioLbT pxaRiBmrSij4i35tXZs2XpySotaFsw0JyOZN3MWM= From: "Paul E. Jones" To: "'DRAGE, Keith \(Keith\)'" , References: <04f201cd54d7$0bb670a0$232351e0$@packetizer.com> In-Reply-To: Date: Thu, 28 Jun 2012 11:48:37 -0400 Message-ID: <05df01cd5545$7bdb5ad0$73921070$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK7RB41zBRhsBQ7e9n1g4StVSTSxQHV1wfwAlkbTJiVEolbQA== Content-Language: en-us Subject: Re: [Insipid] Query on solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:48:33 -0000 Keith, The current thinking was that all messages from Alice would contain Alice's Session-ID-UUID header. Likewise, all messages from Bob would contain Bob's Session-ID-UUID. We've had some discussion about having endpoints insert the entire Session-ID value once it is known. In that case, Bob would include the entire Session-ID in 1xx, 2xx messages. However, I've not fully considered what happens in that case when calls are joined to different calls on two ends at the same time. I think there are some race condition opportunities in that case. So, it might be that, rather than including the entire Session-ID concatenated as we prescribed, we could include each as separate components like: Session-ID: L:local_value; R:remote_value Local and remote is a matter of perspective, but we could work out the language. Bottom line is that we have something proposed, but are willing to consider other approaches. Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of DRAGE, Keith (Keith) > Sent: Thursday, June 28, 2012 6:47 AM > To: Paul E. Jones; insipid@ietf.org > Subject: Re: [Insipid] Query on solution draft > > I was only interested in identifying if a relationship could be > identified, not the form of that relationship, i.e. that in some way call > 1 from A-C is some reincarnation of call 1 from A-B (as opposed to call > 2), not that this occurred because B transferred the call to C (that > should be handed by service specific mechanisms where privacy of that > information may well be defined). > > But part of my lack of understanding is what happens on the protocol when > only half ID's are sent. > > Any chance of indicating (according to the current draft) which messages > carry which half IDs? > > Keith > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: 28 June 2012 03:38 > To: DRAGE, Keith (Keith); insipid@ietf.org > Subject: RE: [Insipid] Query on solution draft > > Keith, > > > (I agree it is a bit contrived as stated, but I am convinced all the > > elements of it exist in the multiple call multiple in progress > > transfers that exist on attendants consoles on enterprise networks). > > No worries. I like corner cases, myself, as I hate it when things do not > work. > > > A calls B > > Session ID would be A1 || B1 > > > A makes a second call to B > > Session ID would be A2 || B2 > > > B calls C > > Session ID would be B3 || C1 > > > B makes a second call to B > > I assume you meant C, in which case > > Session ID would be B4 || C2 > > > B transfers the first call from A to the first call to C > > Do you mean is truly transferred a particular call to a particular call? > As in a call join? In the case of joining, then A1 || B1 disappears. > Also, B3 > || C1 disappears. The joined call would have a Session ID of A1 || C1. > > Now, had B just transferred that first call with A to C, then the session > ID might have been A1 || C3 (or something). Then the call B3 || C1 > disappears. > > > B transfers the second call from A to the second call to C > > Again, I assume this is a call join. We would have a resulting call > between A and C with the Session ID A2 || C2. > > > Does the solution provided in draft-jones-insipid-session-id-00 allow > > me > > to: > > > > - identify from the session identifier the relationship between the > > first call before transfer and the first call after transfer, and > > One cannot necessarily understand what the relationship is, but one could > observe that there is a relationship. > > > - the relationship between the second call before transfer and the > > second call after transfer > > Same thing. Nothing about the IDs explain what the relationships are. > > > at both the UA of user A and at the UA of user C, and if so how? > > > > There may be readers who are also interested in doing this at an SBC > > near each of these users, but that is not my question. > > Exactly what would people want to do? Understand there is a relationship > or understand there is a particular type of relationship? > > Paul > > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From jmpolk@cisco.com Thu Jun 28 12:46:18 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B2811E8085 for ; Thu, 28 Jun 2012 12:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.472 X-Spam-Level: X-Spam-Status: No, score=-110.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFrg7lyiRBXr for ; Thu, 28 Jun 2012 12:46:17 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A652B11E8083 for ; Thu, 28 Jun 2012 12:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=4883; q=dns/txt; s=iport; t=1340912777; x=1342122377; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=f9LGJ2XKOPxs6q+GA+W0A6cW+KT3Raz51NGWDmX5djU=; b=hLvcBwQz5Y0TOqsLS1uitdjQ439hqVd/FGEYQsNTSoXELSrv1DJnNLpQ 1AlJ7LKeI8jOnAI/SfUr3RUovgf0M8iBaQGDpXjkcqFUdvJ015SZ3Mytj /ui8EHNF6tSn6j1QRTTDjDwrxOahFujtKp5UFZw62bM9yuff4rggEbhvu Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADmz7E+rRDoJ/2dsb2JhbAA7CrYrgQeCGAEBAQQBAQEPASUCNAQTBAcEEQQBAQEeCQcZDh8JCAYBCQkbB4doDJg7oG8EizcQhXoDiEqbBYFmgn0 X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="50497005" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 28 Jun 2012 19:46:17 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5SJkG0P004325; Thu, 28 Jun 2012 19:46:16 GMT Message-Id: <201206281946.q5SJkG0P004325@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Jun 2012 14:46:17 -0500 To: "DRAGE, Keith (Keith)" , "Paul E. Jones" , "insipid@ietf.org" From: James Polk In-Reply-To: References: <04f201cd54d7$0bb670a0$232351e0$@packetizer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Insipid] Query on solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 19:46:18 -0000 Keith I believe it is harder to determine the 'relationship' if only half keys are sent in SIP (after the initial INVITE which can only have 1 half key). The only issue IMO is Session-ID header-value size (i.e., it'll be twice as long, and there will be a lot of characters in any UUID/GUID). If we agree that once the whole Session-ID is compiled, meaning the GUID from UA1 and the GUID from UA2 are concatenated in some order, that header value remains on in all SIP messages between those 2 UAs until session termination or a transfer or join operation occurs. I think this is the right way forward. Is this agreeable to everyone? If that is agreeable, once a session (UA1|UA2) is transferred by UA2 for UA1 to 'talk' to UA3, UA1's same GUID is what survives intact in this new Session-ID value (UA1|UA3). Knowing the GUIDs from each UA MUST be different for different sessions, it doesn't matter how many times any two or more UAs call other UAs. Further, by doing simple tracking of a database of GUIDs for previous sessions, it will be fairly trivial to track the evolution of the same session that was transferred or joined several times throughout its lifetime by tracking GUIDs. In other words, once a GUID (i.e., half key) is assigned to a session, it is paired with another GUID to form a Session-ID. If that session is transferred or joined to another UA, only 1 of the GUIDs is replaced during that join or transfer, meaning there is a retained relationship. The same is true during the next transfer or join (one GUID is retained and the other is replaced), which can be tracked fairly easily. Is this clearer? James At 05:46 AM 6/28/2012, DRAGE, Keith (Keith) wrote: >I was only interested in identifying if a relationship could be >identified, not the form of that relationship, i.e. that in some way >call 1 from A-C is some reincarnation of call 1 from A-B (as opposed >to call 2), not that this occurred because B transferred the call to >C (that should be handed by service specific mechanisms where >privacy of that information may well be defined). > >But part of my lack of understanding is what happens on the protocol >when only half ID's are sent. > >Any chance of indicating (according to the current draft) which >messages carry which half IDs? > >Keith > >-----Original Message----- >From: Paul E. Jones [mailto:paulej@packetizer.com] >Sent: 28 June 2012 03:38 >To: DRAGE, Keith (Keith); insipid@ietf.org >Subject: RE: [Insipid] Query on solution draft > >Keith, > > > (I agree it is a bit contrived as stated, but I am convinced all the > > elements of it exist in the multiple call multiple in progress transfers > > that exist on attendants consoles on enterprise networks). > >No worries. I like corner cases, myself, as I hate it when things do not >work. > > > A calls B > >Session ID would be A1 || B1 > > > A makes a second call to B > >Session ID would be A2 || B2 > > > B calls C > >Session ID would be B3 || C1 > > > B makes a second call to B > >I assume you meant C, in which case > >Session ID would be B4 || C2 > > > B transfers the first call from A to the first call to C > >Do you mean is truly transferred a particular call to a particular call? As >in a call join? In the case of joining, then A1 || B1 disappears. Also, B3 >|| C1 disappears. The joined call would have a Session ID of A1 || C1. > >Now, had B just transferred that first call with A to C, then the session ID >might have been A1 || C3 (or something). Then the call B3 || C1 disappears. > > > B transfers the second call from A to the second call to C > >Again, I assume this is a call join. We would have a resulting call between >A and C with the Session ID A2 || C2. > > > Does the solution provided in draft-jones-insipid-session-id-00 allow me > > to: > > > > - identify from the session identifier the relationship between the > > first call before transfer and the first call after transfer, and > >One cannot necessarily understand what the relationship is, but one could >observe that there is a relationship. > > > - the relationship between the second call before transfer and the > > second call after transfer > >Same thing. Nothing about the IDs explain what the relationships are. > > > at both the UA of user A and at the UA of user C, and if so how? > > > > There may be readers who are also interested in doing this at an SBC near > > each of these users, but that is not my question. > >Exactly what would people want to do? Understand there is a relationship or >understand there is a particular type of relationship? > >Paul > > > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From jmpolk@cisco.com Thu Jun 28 12:47:06 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C921511E8087 for ; Thu, 28 Jun 2012 12:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.483 X-Spam-Level: X-Spam-Status: No, score=-110.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CBIUBo5y4Ya for ; Thu, 28 Jun 2012 12:47:06 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 008EA11E8083 for ; Thu, 28 Jun 2012 12:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=4860; q=dns/txt; s=iport; t=1340912826; x=1342122426; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=qYncU/hvaFGiVP2HJiuPJwHyECTZx7J6HjhoogAP654=; b=KfMVg5Yy3lsvPGumnp/IhabeBFzCTXNsTJrCwiKQ5iTpqtBNAg2HYtx/ s/qIsrj+EkcA1Ht/jaI4HWK2zMTtUwhOHDlN2ewNkIUW+Vg12SRtzw3R3 JhJFkuVgvhU8JMvGFkFe9JowKze2n4pjZ0cqf+jjvAaMUaNETQhLKQ3eL I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGe07E+rRDoH/2dsb2JhbAA7CrYrgQeCGAEBAQQBAQEPASUCNAQTBAcEEQQBAQEeCQcZDh8JCAYBCQkbB4doDJg6oG8EizcQhXoDiEqbBYFmgn0 X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="50497062" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 28 Jun 2012 19:47:05 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5SJl5bY016986; Thu, 28 Jun 2012 19:47:05 GMT Message-Id: <201206281947.q5SJl5bY016986@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Jun 2012 14:47:05 -0500 To: "Paul E. Jones" , "'DRAGE, Keith (Keith)'" , From: James Polk In-Reply-To: <05df01cd5545$7bdb5ad0$73921070$@packetizer.com> References: <04f201cd54d7$0bb670a0$232351e0$@packetizer.com> <05df01cd5545$7bdb5ad0$73921070$@packetizer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Insipid] Query on solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 19:47:07 -0000 At 10:48 AM 6/28/2012, Paul E. Jones wrote: >Keith, > >The current thinking was that all messages from Alice would contain Alice's >Session-ID-UUID header. Likewise, all messages from Bob would contain Bob's >Session-ID-UUID. > >We've had some discussion about having endpoints insert the entire >Session-ID value once it is known. In that case, Bob would include the >entire Session-ID in 1xx, 2xx messages. However, I've not fully considered >what happens in that case when calls are joined to different calls on two >ends at the same time. I think there are some race condition opportunities >in that case. So, it might be that, rather than including the entire >Session-ID concatenated as we prescribed, we could include each as separate >components like: > Session-ID: L:local_value; R:remote_value I think this is unnecessary. James >Local and remote is a matter of perspective, but we could work out the >language. > >Bottom line is that we have something proposed, but are willing to consider >other approaches. > >Paul > > > -----Original Message----- > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > > Of DRAGE, Keith (Keith) > > Sent: Thursday, June 28, 2012 6:47 AM > > To: Paul E. Jones; insipid@ietf.org > > Subject: Re: [Insipid] Query on solution draft > > > > I was only interested in identifying if a relationship could be > > identified, not the form of that relationship, i.e. that in some way call > > 1 from A-C is some reincarnation of call 1 from A-B (as opposed to call > > 2), not that this occurred because B transferred the call to C (that > > should be handed by service specific mechanisms where privacy of that > > information may well be defined). > > > > But part of my lack of understanding is what happens on the protocol when > > only half ID's are sent. > > > > Any chance of indicating (according to the current draft) which messages > > carry which half IDs? > > > > Keith > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: 28 June 2012 03:38 > > To: DRAGE, Keith (Keith); insipid@ietf.org > > Subject: RE: [Insipid] Query on solution draft > > > > Keith, > > > > > (I agree it is a bit contrived as stated, but I am convinced all the > > > elements of it exist in the multiple call multiple in progress > > > transfers that exist on attendants consoles on enterprise networks). > > > > No worries. I like corner cases, myself, as I hate it when things do not > > work. > > > > > A calls B > > > > Session ID would be A1 || B1 > > > > > A makes a second call to B > > > > Session ID would be A2 || B2 > > > > > B calls C > > > > Session ID would be B3 || C1 > > > > > B makes a second call to B > > > > I assume you meant C, in which case > > > > Session ID would be B4 || C2 > > > > > B transfers the first call from A to the first call to C > > > > Do you mean is truly transferred a particular call to a particular call? > > As in a call join? In the case of joining, then A1 || B1 disappears. > > Also, B3 > > || C1 disappears. The joined call would have a Session ID of A1 || C1. > > > > Now, had B just transferred that first call with A to C, then the session > > ID might have been A1 || C3 (or something). Then the call B3 || C1 > > disappears. > > > > > B transfers the second call from A to the second call to C > > > > Again, I assume this is a call join. We would have a resulting call > > between A and C with the Session ID A2 || C2. > > > > > Does the solution provided in draft-jones-insipid-session-id-00 allow > > > me > > > to: > > > > > > - identify from the session identifier the relationship between the > > > first call before transfer and the first call after transfer, and > > > > One cannot necessarily understand what the relationship is, but one could > > observe that there is a relationship. > > > > > - the relationship between the second call before transfer and the > > > second call after transfer > > > > Same thing. Nothing about the IDs explain what the relationships are. > > > > > at both the UA of user A and at the UA of user C, and if so how? > > > > > > There may be readers who are also interested in doing this at an SBC > > > near each of these users, but that is not my question. > > > > Exactly what would people want to do? Understand there is a relationship > > or understand there is a particular type of relationship? > > > > Paul > > > > > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Thu Jun 28 13:09:47 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2976311E8098 for ; Thu, 28 Jun 2012 13:09:47 -0700 (PDT) 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=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcPapPg5lz8n for ; Thu, 28 Jun 2012 13:09:46 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDC021F84FB for ; Thu, 28 Jun 2012 13:09:45 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta05.westchester.pa.mail.comcast.net with comcast id Tovf1j0041vXlb855w9itF; Thu, 28 Jun 2012 20:09:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id Tw9j1j00Z3ZTu2S3dw9jgl; Thu, 28 Jun 2012 20:09:43 +0000 Message-ID: <4FECBA04.6060208@alum.mit.edu> Date: Thu, 28 Jun 2012 16:09:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <04f201cd54d7$0bb670a0$232351e0$@packetizer.com> <05df01cd5545$7bdb5ad0$73921070$@packetizer.com> <201206281947.q5SJl5bY016986@mtv-core-2.cisco.com> In-Reply-To: <201206281947.q5SJl5bY016986@mtv-core-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] Query on solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 20:09:47 -0000 On 6/28/12 3:47 PM, James Polk wrote: > At 10:48 AM 6/28/2012, Paul E. Jones wrote: >> Keith, >> >> The current thinking was that all messages from Alice would contain >> Alice's >> Session-ID-UUID header. Likewise, all messages from Bob would contain >> Bob's >> Session-ID-UUID. >> >> We've had some discussion about having endpoints insert the entire >> Session-ID value once it is known. In that case, Bob would include the >> entire Session-ID in 1xx, 2xx messages. However, I've not fully >> considered >> what happens in that case when calls are joined to different calls on two >> ends at the same time. I think there are some race condition >> opportunities >> in that case. So, it might be that, rather than including the entire >> Session-ID concatenated as we prescribed, we could include each as >> separate >> components like: >> Session-ID: L:local_value; R:remote_value > > I think this is unnecessary. There is no fundamental difference between: Session-ID: L:local_value; R:remote_value and Session-ID: local_value:remote_value And regarding which order they are concatenated, there are two choices: - Order them when concatenated, and use literal string compare. E.g. always arrange : such that < - Transmit the two parts in arbitrary order, but order them at time of comparison. E.g. if you want to compare A:B to C:D, compare min(A,B) to min(C,D) and max(A,B) to max(C,D) Regarding size to carry both parts rather than one part, a UUID is 128 bits in binary. That's 32 bytes in hex, or 24 bytes in base 64. Two of them is double that. Perhaps add one for a separator. E.g. Session-ID: hVpd7YQgRW2nD22h7q60JQ==:srfBElmCRp2QB23b7Mpk0w== (That is standard base 64 rep. The == at the end is artifact of that encoding when the number of bits isn't a multiple of 6. If its known that the length is always 32 bits, then the == could be dropped.) Thanks, Paul From gsalguei@cisco.com Thu Jun 28 14:53:48 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12AE11E80C7 for ; Thu, 28 Jun 2012 14:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugw3KeDuKgjK for ; Thu, 28 Jun 2012 14:53:48 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 1F49F11E80C6 for ; Thu, 28 Jun 2012 14:53:48 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q5SLrkru015965 for ; Thu, 28 Jun 2012 17:53:46 -0400 (EDT) Received: from rtp-gsalguei-8719.cisco.com (rtp-gsalguei-8719.cisco.com [10.116.61.58]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q5SLrjd4023847 for ; Thu, 28 Jun 2012 17:53:46 -0400 (EDT) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jun 2012 17:53:45 -0400 Message-Id: <97D3C2F5-A26D-493A-B571-D39E0E4671DE@cisco.com> To: insipid@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [Insipid] INSIPID meeting at IETF84 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 21:53:49 -0000 Folks: We have been been granted a two hour slot for Vancouver, Wednesday, Afternoon Session I 1300-1500 Room Name: Regency A Chairs will be finalizing the agenda over the next few weeks. In the = meantime we encourage folks to submit any candidate solutions for = session id that they wish to be considered by the WG. if you have such = plans and would like to present at the upcoming INSIPID session in = Vancouver please send presenter name, length of presentation, and = Internet Draft(s) related to your presentation to = insipid-chairs@tools.ietf.org. Thanks, Gonzalo (as co-chair) From paulej@packetizer.com Thu Jun 28 19:18:58 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CFF11E8085 for ; Thu, 28 Jun 2012 19:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKJqYEcN+1qi for ; Thu, 28 Jun 2012 19:18:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id F061E21F8569 for ; Thu, 28 Jun 2012 19:18:57 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q5T2IsHM010082 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Jun 2012 22:18:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1340936335; bh=3TPodHJOkc/D6wYWyX+72/aSQnLbeBpYuueCxVK2A6g=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=jdpkOdfMMwvgMpvoEAH6A/xCrRGov6v3N8jwAb6mHpUtlM7RY5CRqO5FS0eW3KBW5 Qdk3LC2FDYm7t3vtNrUvAYcSJO0+3U/rqeIWCs45LLba25RMAwnVvkPq+dv3DH3B3F lqGCKuqqVfTgQDDLg++j5elkX5weaRIF3H9rYCqk= From: "Paul E. Jones" To: "'James Polk'" , "'DRAGE, Keith \(Keith\)'" , References: <04f201cd54d7$0bb670a0$232351e0$@packetizer.com> <201206281946.q5SJkG0P004325@mtv-core-4.cisco.com> In-Reply-To: <201206281946.q5SJkG0P004325@mtv-core-4.cisco.com> Date: Thu, 28 Jun 2012 22:19:04 -0400 Message-ID: <06a401cd559d$8ecfec70$ac6fc550$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK7RB41zBRhsBQ7e9n1g4StVSTSxQHV1wfwAlkbTJgCnzjdJ5T+P3RQ Content-Language: en-us Subject: Re: [Insipid] Query on solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 02:18:58 -0000 James, > If we agree that once the whole Session-ID is compiled, meaning the GUID > from UA1 and the GUID from UA2 are concatenated in some order, that header > value remains on in all SIP messages between those 2 UAs until session > termination or a transfer or join operation occurs. > > I think this is the right way forward. Is this agreeable to everyone? I'm OK with that so long as we indicate directionality. In the rare event that two ends are joined to different calls are roughly the same time, I would want intermediaries and the remote system to be able to tell which of the two values UUIDs belong to the remote device. Thus, something like: Session-ID: S:x;R:y (referring to the sender (S) of the message and the assumed recipient (R)). If we do not do this, then Carol might receive this: Session-ID: XY And Carol knows her UUID is L and has no idea which value (X or Y) belongs to the remote device. It's a rare case, but we can avoid it ever becoming an issue by keeping the two UUIDs separated somehow. This can be through "S:" tags or the order of placement (sender || receiver). Paul From salvatore.loreto@ericsson.com Fri Jun 29 05:10:56 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A4B21F86F1 for ; Fri, 29 Jun 2012 05:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id le65GHlGUK2g for ; Fri, 29 Jun 2012 05:10:55 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5837221F86B1 for ; Fri, 29 Jun 2012 05:10:55 -0700 (PDT) X-AuditID: c1b4fb30-b7fb46d0000064f2-ab-4fed9b4e8ea8 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 15.3A.25842.E4B9DEF4; Fri, 29 Jun 2012 14:10:54 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.0; Fri, 29 Jun 2012 14:10:53 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E08572885 for ; Fri, 29 Jun 2012 15:10:53 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id F420C53310 for ; Fri, 29 Jun 2012 15:10:53 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 97D545315B for ; Fri, 29 Jun 2012 15:10:53 +0300 (EEST) Message-ID: <4FED9B4D.1080704@ericsson.com> Date: Fri, 29 Jun 2012 15:10:53 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <04f201cd54d7$0bb670a0$232351e0$@packetizer.com> <201206281946.q5SJkG0P004325@mtv-core-4.cisco.com> <06a401cd559d$8ecfec70$ac6fc550$@packetizer.com> In-Reply-To: <06a401cd559d$8ecfec70$ac6fc550$@packetizer.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUyM+Jvra7f7Lf+Bg//ilnMv/+MyYHRY8mS n0wBjFFcNimpOZllqUX6dglcGZ2ftrAUfOWp2DC7oIFxElcXIyeHhICJxNItv9kgbDGJC/fW g9lCAqcYJV590+hi5AKyNzBKLGo9xgbhXGKU6G+8zAjhHGWUmNE4hQXCOccoMe1sPztIP6+A tsS9dZOZQWwWAVWJc03HwWw2ATOJ5w+3ANkcHKICyRJ//6dDlAtKnJz5hAXEFhEQkfh9dwrY GGEBPYlf799CnXSESWJmpwSIzSlgK7HyBUScGci+MOc6C4QtL7H97RxmiHfUJK6e28QM0asl 0Xu2k2kCo8gsJOtmIWmfhaR9ASPzKkbh3MTMnPRyc73Uoszk4uL8PL3i1E2MwAA/uOW3wQ7G TffFDjFKc7AoifPqqe73FxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cA4scE/Y2ng0RkPw5+5 fLlW8n/BAe2JF5YK30zunm3wO2dK/+Ku6kJV/deXN9Xv/bs39Y17606XwNMy/xlaDvcUf13k 7MaWti/sjM4h2eUae+7W+P1UPKnIKRbnc2yDhnTZ0gmLG/LSv5/xMJb4XtHl+2J/aCazW/nr hJb06RXM1xL5Xt5Z/mW9EktxRqKhFnNRcSIAcqortD4CAAA= Subject: Re: [Insipid] Query on solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 12:10:56 -0000 On 6/29/12 5:19 AM, Paul E. Jones wrote: > James, > >> If we agree that once the whole Session-ID is compiled, meaning the GUID >> from UA1 and the GUID from UA2 are concatenated in some order, that header >> value remains on in all SIP messages between those 2 UAs until session >> termination or a transfer or join operation occurs. >> >> I think this is the right way forward. Is this agreeable to everyone? > I'm OK with that so long as we indicate directionality. In the rare event > that two ends are joined to different calls are roughly the same time, I > would want intermediaries and the remote system to be able to tell which of > the two values UUIDs belong to the remote device. Thus, something like: > > Session-ID: S:x;R:y > > (referring to the sender (S) of the message and the assumed recipient (R)). I agree that if we choose to insert the entire Session-ID concatenated it would be better also have a way to separate the components so to discriminate them but I am not completely convinced that we need the entire Session-ID concatenated Salvatore > > If we do not do this, then Carol might receive this: > > Session-ID: XY > > And Carol knows her UUID is L and has no idea which value (X or Y) belongs > to the remote device. It's a rare case, but we can avoid it ever becoming > an issue by keeping the two UUIDs separated somehow. This can be through > "S:" tags or the order of placement (sender || receiver). > > Paul > > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Fri Jun 29 06:53:37 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A60421F86E5 for ; Fri, 29 Jun 2012 06:53:37 -0700 (PDT) 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=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64PtBBE6dWXc for ; Fri, 29 Jun 2012 06:53:36 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3AC21F8731 for ; Fri, 29 Jun 2012 06:53:35 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta03.westchester.pa.mail.comcast.net with comcast id UBfx1j0090xGWP853DtaK8; Fri, 29 Jun 2012 13:53:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id UDtU1j00G3ZTu2S3YDtUPl; Fri, 29 Jun 2012 13:53:28 +0000 Message-ID: <4FEDB35D.3020001@alum.mit.edu> Date: Fri, 29 Jun 2012 09:53:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <04f201cd54d7$0bb670a0$232351e0$@packetizer.com> <201206281946.q5SJkG0P004325@mtv-core-4.cisco.com> <06a401cd559d$8ecfec70$ac6fc550$@packetizer.com> In-Reply-To: <06a401cd559d$8ecfec70$ac6fc550$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] Query on solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 13:53:37 -0000 On 6/28/12 10:19 PM, Paul E. Jones wrote: > James, > >> If we agree that once the whole Session-ID is compiled, meaning the GUID >> from UA1 and the GUID from UA2 are concatenated in some order, that header >> value remains on in all SIP messages between those 2 UAs until session >> termination or a transfer or join operation occurs. >> >> I think this is the right way forward. Is this agreeable to everyone? > > I'm OK with that so long as we indicate directionality. In the rare event > that two ends are joined to different calls are roughly the same time, I > would want intermediaries and the remote system to be able to tell which of > the two values UUIDs belong to the remote device. Thus, something like: > > Session-ID: S:x;R:y > > (referring to the sender (S) of the message and the assumed recipient (R)). > > If we do not do this, then Carol might receive this: > > Session-ID: XY > > And Carol knows her UUID is L and has no idea which value (X or Y) belongs > to the remote device. It's a rare case, but we can avoid it ever becoming > an issue by keeping the two UUIDs separated somehow. This can be through > "S:" tags or the order of placement (sender || receiver). Be careful here. You seem to be trying to pile on two different semantics. On one hand you are trying to associate each "half" of the id with the end that assigned it. On the other hand, for comparing two IDs you don't care what end is associated with what half - you want the IDs from two messages sent in opposite directions to compare equal. For precedent, what you are describing is very comparable to the from-tag and to-tag. What Paul J is suggesting (S:, R:) can work as long as comparison rules are properly defined. E.g. (as I already proposed) to compare IDs X and Y, compare min(Xs, Xr) to min(Ys, Yr) and max(Xs, Xr) to max(Ys, Yr). I'm inclined to suggest the following format: Session-ID: from=x; to=y to show the similarity to from and to tags. Thanks, Paul From jmpolk@cisco.com Fri Jun 29 11:22:43 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5429621F864B for ; Fri, 29 Jun 2012 11:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.206 X-Spam-Level: X-Spam-Status: No, score=-110.206 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6YFt8d1jXBs for ; Fri, 29 Jun 2012 11:22:42 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 51E5321F867A for ; Fri, 29 Jun 2012 11:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=3591; q=dns/txt; s=iport; t=1340994162; x=1342203762; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=wxjd4GXVEeLMQW3+vsaNwJvdRsbYwn8sfTT0FRg6XCk=; b=EoAk+xDrENBN6dnmkQlcn1U2MM06tLfT9bGVfaI0K89HoKyU1m2wrGRm OAroSAL6jjEP/S0widIzzc0B2H82XQFH8ZMKFhUcKcwDpw/4Ej2dm3Du9 Jwy14q6KivgD8M0gzscw1WCcDIRnO8e0bLT4fB8OOtiwndQFTVAz3Wa4T s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAALy7U+rRDoH/2dsb2JhbABFDrZIgQeCGAEBAQMBAQEBDwElAjQQCwcEDgoeEBkOMAYBCQkbB4dkBAybXKA7BIs3hgoDiEqbBoFmgiZXgTgF X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="50510689" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 29 Jun 2012 18:22:38 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5TIMcbq011640; Fri, 29 Jun 2012 18:22:38 GMT Message-Id: <201206291822.q5TIMcbq011640@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 29 Jun 2012 13:22:38 -0500 To: Paul Kyzivat , From: James Polk In-Reply-To: <4FEDB35D.3020001@alum.mit.edu> References: <04f201cd54d7$0bb670a0$232351e0$@packetizer.com> <201206281946.q5SJkG0P004325@mtv-core-4.cisco.com> <06a401cd559d$8ecfec70$ac6fc550$@packetizer.com> <4FEDB35D.3020001@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Insipid] Query on solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 18:22:43 -0000 At 08:53 AM 6/29/2012, Paul Kyzivat wrote: >On 6/28/12 10:19 PM, Paul E. Jones wrote: >>James, >> >>>If we agree that once the whole Session-ID is compiled, meaning the GUID >>>from UA1 and the GUID from UA2 are concatenated in some order, that header >>>value remains on in all SIP messages between those 2 UAs until session >>>termination or a transfer or join operation occurs. >>> >>>I think this is the right way forward. Is this agreeable to everyone? >> >>I'm OK with that so long as we indicate directionality. In the rare event >>that two ends are joined to different calls are roughly the same time, I >>would want intermediaries and the remote system to be able to tell which of >>the two values UUIDs belong to the remote device. Thus, something like: >> >> Session-ID: S:x;R:y >> >>(referring to the sender (S) of the message and the assumed recipient (R)). >> >>If we do not do this, then Carol might receive this: >> >> Session-ID: XY >> >>And Carol knows her UUID is L and has no idea which value (X or Y) belongs >>to the remote device. It's a rare case, but we can avoid it ever becoming >>an issue by keeping the two UUIDs separated somehow. This can be through >>"S:" tags or the order of placement (sender || receiver). > >Be careful here. You seem to be trying to pile on two different >semantics. On one hand you are trying to associate each "half" of >the id with the end that assigned it. On the other hand, for >comparing two IDs you don't care what end is associated with what >half - you want the IDs from two messages sent in opposite >directions to compare equal. > >For precedent, what you are describing is very comparable to the >from-tag and to-tag. > >What Paul J is suggesting (S:, R:) can work as long as comparison >rules are properly defined. E.g. (as I already proposed) to compare >IDs X and Y, compare min(Xs, Xr) to min(Ys, Yr) and max(Xs, Xr) to max(Ys, Yr). > >I'm inclined to suggest the following format: > > Session-ID: from=x; to=y > >to show the similarity to from and to tags. What I originally proposed was to order Alice's GUID first, then Bob's, but make it implicit in which all observers of the Session-ID header value could easily determine which was the initiator and which was the responder - but only if the GUIDs were always of a known/fixed length (i.e., always 24 or 32 bytes for each GUID). This is instead of the analysis of which GUID is a greater value vs. which is a lessor value and concatenate that way. With that model, when Bob transfers Alice to Carol, Alice's GUID would remain part of the Session-ID while Bob's would be replaced by Carol's (once she responds). Now, I know I haven't thought about all versions of joins to appreciate if there is a corner case of join that breaks this model. But, I'm not sure we need to include the 'S:' & 'R:' or 'from=' & 'to=' unless we determine we need to be explicit. If that's the case, I'd like to see (i.e., a diagram of) an example of that corner case. WRT the idea of whether or not to have the GUIDs present in the Session-ID header value, this is clean and not left to assumption as to what is the other GUID value that is not in that SIP message. It's not like we're attempting to hide one GUID from being seen on the wire, that's what TLS is for if that's a concern. James > Thanks, > Paul >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Sat Jun 30 08:54:07 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7403021F8594 for ; Sat, 30 Jun 2012 08:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIrQ6Fign4hW for ; Sat, 30 Jun 2012 08:54:06 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2622421F85C6 for ; Sat, 30 Jun 2012 08:54:04 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id Ueef1j0061swQuc55fu5Co; Sat, 30 Jun 2012 15:54:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id Ufu21j0053ZTu2S3bfu2Pn; Sat, 30 Jun 2012 15:54:02 +0000 Message-ID: <4FEF211C.8030806@alum.mit.edu> Date: Sat, 30 Jun 2012 11:54:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: James Polk References: <04f201cd54d7$0bb670a0$232351e0$@packetizer.com> <201206281946.q5SJkG0P004325@mtv-core-4.cisco.com> <06a401cd559d$8ecfec70$ac6fc550$@packetizer.com> <4FEDB35D.3020001@alum.mit.edu> <201206291822.q5TIMcbq011640@mtv-core-2.cisco.com> In-Reply-To: <201206291822.q5TIMcbq011640@mtv-core-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: insipid@ietf.org Subject: Re: [Insipid] Query on solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 15:54:07 -0000 On 6/29/12 2:22 PM, James Polk wrote: > At 08:53 AM 6/29/2012, Paul Kyzivat wrote: >> On 6/28/12 10:19 PM, Paul E. Jones wrote: >>> James, >>> >>>> If we agree that once the whole Session-ID is compiled, meaning the >>>> GUID >>>> from UA1 and the GUID from UA2 are concatenated in some order, that >>>> header >>>> value remains on in all SIP messages between those 2 UAs until session >>>> termination or a transfer or join operation occurs. >>>> >>>> I think this is the right way forward. Is this agreeable to everyone? >>> >>> I'm OK with that so long as we indicate directionality. In the rare >>> event >>> that two ends are joined to different calls are roughly the same time, I >>> would want intermediaries and the remote system to be able to tell >>> which of >>> the two values UUIDs belong to the remote device. Thus, something like: >>> >>> Session-ID: S:x;R:y >>> >>> (referring to the sender (S) of the message and the assumed recipient >>> (R)). >>> >>> If we do not do this, then Carol might receive this: >>> >>> Session-ID: XY >>> >>> And Carol knows her UUID is L and has no idea which value (X or Y) >>> belongs >>> to the remote device. It's a rare case, but we can avoid it ever >>> becoming >>> an issue by keeping the two UUIDs separated somehow. This can be through >>> "S:" tags or the order of placement (sender || receiver). >> >> Be careful here. You seem to be trying to pile on two different >> semantics. On one hand you are trying to associate each "half" of the >> id with the end that assigned it. On the other hand, for comparing two >> IDs you don't care what end is associated with what half - you want >> the IDs from two messages sent in opposite directions to compare equal. >> >> For precedent, what you are describing is very comparable to the >> from-tag and to-tag. >> >> What Paul J is suggesting (S:, R:) can work as long as comparison >> rules are properly defined. E.g. (as I already proposed) to compare >> IDs X and Y, compare min(Xs, Xr) to min(Ys, Yr) and max(Xs, Xr) to >> max(Ys, Yr). >> >> I'm inclined to suggest the following format: >> >> Session-ID: from=x; to=y >> >> to show the similarity to from and to tags. > > What I originally proposed was to order Alice's GUID first, then Bob's, > but make it implicit in which all observers of the Session-ID header > value could easily determine which was the initiator and which was the > responder - but only if the GUIDs were always of a known/fixed length > (i.e., always 24 or 32 bytes for each GUID). This is instead of the > analysis of which GUID is a greater value vs. which is a lessor value > and concatenate that way. I don't understand. Once a dialog is established, it needs to be the case that the sessionid is the same for messages sent by Alice and those sent by Bob. And I don't think you can count of figuring out which end initiated the dialog. (In some cases with B2BUAs, both ends may initiate, or sometimes the middle initiates toward both ends.) Thanks, Paul > With that model, when Bob transfers Alice to Carol, Alice's GUID would > remain part of the Session-ID while Bob's would be replaced by Carol's > (once she responds). > > Now, I know I haven't thought about all versions of joins to appreciate > if there is a corner case of join that breaks this model. But, I'm not > sure we need to include the 'S:' & 'R:' or 'from=' & 'to=' unless we > determine we need to be explicit. If that's the case, I'd like to see > (i.e., a diagram of) an example of that corner case. > > WRT the idea of whether or not to have the GUIDs present in the > Session-ID header value, this is clean and not left to assumption as to > what is the other GUID value that is not in that SIP message. It's not > like we're attempting to hide one GUID from being seen on the wire, > that's what TLS is for if that's a concern. > > James > > >> Thanks, >> Paul >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > >