From wwwrun@rfc-editor.org Thu Dec 6 14:34:58 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE02A21F86A8; Thu, 6 Dec 2012 14:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSX2NfxV5hKc; Thu, 6 Dec 2012 14:34:58 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 143A621F866C; Thu, 6 Dec 2012 14:34:58 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0E2E172F4F0; Thu, 6 Dec 2012 14:26:38 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121206222638.0E2E172F4F0@rfc-editor.org> Date: Thu, 6 Dec 2012 14:26:38 -0800 (PST) Cc: sipcore@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] RFC 6794 on A Framework for Session Initiation Protocol (SIP) Session Policies X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 22:34:58 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6794 Title: A Framework for Session Initiation Protocol (SIP) Session Policies Author: V. Hilt, G. Camarillo, J. Rosenberg Status: Standards Track Stream: IETF Date: December 2012 Mailbox: volker.hilt@bell-labs.com, Gonzalo.Camarillo@ericsson.com, jdrosen@jdrosen.net Pages: 36 Characters: 94464 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-session-policy-framework-10.txt URL: http://www.rfc-editor.org/rfc/rfc6794.txt Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies. [STANDARDS-TRACK] This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From christer.holmberg@ericsson.com Mon Dec 10 02:04:10 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA3821F8E64 for ; Mon, 10 Dec 2012 02:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.157 X-Spam-Level: X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrnYSShK9ruw for ; Mon, 10 Dec 2012 02:04:06 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id F1F0321F8E5E for ; Mon, 10 Dec 2012 02:04:05 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-8c-50c5b394100b Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 42.9E.24873.493B5C05; Mon, 10 Dec 2012 11:04:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0318.001; Mon, 10 Dec 2012 11:04:04 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: Draft new: draft-holmberg-sipcore-received-realm-00 Thread-Index: Ac3WvTkjByInUM1RTJSbqOOOIsdUsg== Date: Mon, 10 Dec 2012 10:04:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B051CFAESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+Jvje6UzUcDDN5N1rH4+mMTmwOjx5Il P5kCGKO4bFJSczLLUov07RK4MjY2fGYp2CNXsWj6e+YGxp9SXYwcHBICJhLLZqd3MXICmWIS F+6tZ+ti5OIQEjjEKLHv8CpGCGcJo8TFh5PZQRrYBCwkuv9pgzSICGhKLP+2lR3EFhawkdi5 9RETRNxRYsWdJewQtp7E43/vWUBsFgFVia3v/rOCjOEV8JY43SEAEmYE2vv91BqwVmYBcYlb T+YzQdwjILFkz3lmCFtU4uXjf6wQJytKLO+XgyjPlzh2+xgjiM0rIChxcuYTlgmMQrOQTJqF pGwWkjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ipE9NzEzJ73caBMjMOAPbvmtuoPx zjmRQ4zSHCxK4rzWW/f4CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAMubLc8cCFxbUz9um1 Wt172tEim6z8/O3lfYIvm7qvXZtvHvcu9G6WwCMR/paPu9fMTOWNfDCR0eE8P+OxVtFWzTRX 0dnK/5L9HzDnCLAf+hL4kCFk1pFbT398dfbMcc46eY7j3GbucOuX1x7F35zLdH4rC+tWF38D j0BOsajsrlNz41Qe7JNTYinOSDTUYi4qTgQAJ7TWs0YCAAA= Subject: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 10:04:11 -0000 --_000_7594FB04B1934943A5C02806D1A2204B051CFAESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We've submitted a new draft, draft-holmberg-sipcore-received-realm-00.txt, = which allows network entry points to indicate the preceding network, from w= here a request is received. The information can be used inside the network,= to provide services, routing etc, based on the information. The indication= is conveyed as a new Via header field parameter, "received-realm". In 3GPP, there is currently a use-case where the information is used to pro= vide services within a transit network. Another use-case, also documented i= n the draft, is transit routing. http://www.ietf.org/id/draft-holmberg-sipcore-received-realm-00.txt Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B051CFAESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We’ve submitted a new draft, draft-holmberg-si= pcore-received-realm-00.txt, which allows network entry points to indicate = the preceding network, from where a request is received. The information ca= n be used inside the network, to provide services, routing etc, based on the information. The indication is conveye= d as a new Via header field parameter, “received-realm”.

 

In 3GPP, there is currently a use-case where the inf= ormation is used to provide services within a transit network. Another use-= case, also documented in the draft, is transit routing.

 

http://www.ietf.org/id/draft-holmberg-sipcore-r= eceived-realm-00.txt

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B051CFAESESSMB209ericsso_-- From oej@edvina.net Mon Dec 10 05:08:19 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E2621F8E79 for ; Mon, 10 Dec 2012 05:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UExcC3C6oPyj for ; Mon, 10 Dec 2012 05:08:18 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id EF05221F8E32 for ; Mon, 10 Dec 2012 05:08:16 -0800 (PST) Received: from [192.168.40.36] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 93AE0754A8A7; Mon, 10 Dec 2012 13:08:14 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_9F8151F8-2859-41BD-B654-6DAA36660EAD" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> Date: Mon, 10 Dec 2012 14:08:15 +0100 Message-Id: <36CDA58A-78F4-4E73-8A90-849D4C676E60@edvina.net> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1499) Cc: "sipcore@ietf.org" , "Olle E. Johansson" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 13:08:19 -0000 --Apple-Mail=_9F8151F8-2859-41BD-B654-6DAA36660EAD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 10 dec 2012 kl. 11:04 skrev Christer Holmberg = : > Hi, > =20 > We=92ve submitted a new draft, = draft-holmberg-sipcore-received-realm-00.txt, which allows network entry = points to indicate the preceding network, from where a request is = received. The information can be used inside the network, to provide = services, routing etc, based on the information. The indication is = conveyed as a new Via header field parameter, =93received-realm=94. > =20 > In 3GPP, there is currently a use-case where the information is used = to provide services within a transit network. Another use-case, also = documented in the draft, is transit routing. > =20 > http://www.ietf.org/id/draft-holmberg-sipcore-received-realm-00.txt > =20 I think using the keyword "realm" here is unfortunate, since it's an = important concept in SIP authentication. =46rom a quick reading, I don't see that you refer to the authentication = realm, but introduce "realm" for something else. Also, I don't see any comparision with SIP history and why that can't be = used. Maybe SIP identity can add a secure way of handling this situation too. /O= --Apple-Mail=_9F8151F8-2859-41BD-B654-6DAA36660EAD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
10 dec 2012 kl. = 11:04 skrev Christer Holmberg <christer.holmberg@ericsson.= com>:

Hi,
We=92ve submitted a = new draft, draft-holmberg-sipcore-received-realm-00.txt, which allows = network entry points to indicate the preceding network, from where a = request is received. The information can be used inside the network, to = provide services, routing etc, based on the information. The indication = is conveyed as a new Via header field parameter, = =93received-realm=94.
In 3GPP, there is = currently a use-case where the information is used to provide services = within a transit network. Another use-case, also documented in the = draft, is transit routing.
=46rom a quick reading, I don't = see that you refer to the authentication realm, but introduce "realm" = for something
else.

Also, I don't see = any comparision with SIP history and why that can't be used. Maybe SIP = identity can add a secure
way of handling this situation = too.

/O
= --Apple-Mail=_9F8151F8-2859-41BD-B654-6DAA36660EAD-- From christer.holmberg@ericsson.com Mon Dec 10 05:28:45 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11D821F8DDD for ; Mon, 10 Dec 2012 05:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbivLs1aAsYz for ; Mon, 10 Dec 2012 05:28:43 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C272621F8C14 for ; Mon, 10 Dec 2012 05:28:42 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-c7-50c5e389fe1c Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 73.F2.24873.983E5C05; Mon, 10 Dec 2012 14:28:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0318.001; Mon, 10 Dec 2012 14:28:41 +0100 From: Christer Holmberg To: "Olle E. Johansson" Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 Thread-Index: Ac3WvTkjByInUM1RTJSbqOOOIsdUsgAEc8yAAAKVjyA= Date: Mon, 10 Dec 2012 13:28:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B051F0C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> <36CDA58A-78F4-4E73-8A90-849D4C676E60@edvina.net> In-Reply-To: <36CDA58A-78F4-4E73-8A90-849D4C676E60@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B051F0CESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+JvjW7n46MBBh+O6lq8XH2I2eLrj01s Dkwe09auZPVYsuQnUwBTFJdNSmpOZllqkb5dAlfG5l0qBdP9KpZt38fSwHjUtYuRk0NCwETi 0Zo1TBC2mMSFe+vZuhi5OIQEDjFK9D+bxA7hLGGUeP37HWsXIwcHm4CFRPc/bZAGEQENiQtf rrCB2MwCmhKPdu4FGyQs4CWx/c8UNogab4kZWzvZIWwriYaHX5hBbBYBVYnpradYQGxeoJq7 zbMYQWwhgXqJuzcWgNVwCthJfP+7AayXEei476cgDmUWEJe49WQ+1NECEkv2nGeGsEUlXj7+ B3amhICixPJ+OYjyfIkFW9ayQ6wSlDg58wnLBEbRWUgmzUJSNgtJGURcR2LB7k9sELa2xLKF r5lh7DMHHjMhiy9gZF/FyJ6bmJmTXm60iREYTwe3/FbdwXjnnMghRmkOFiVxXuute/yFBNIT S1KzU1MLUovii0pzUosPMTJxcEo1MPbxdN0I2Vbh9sCMedVGq1R7V+5sbTadbdWnbgYar/jN 1aBsxRp6ZYqxZzfv8hSrV1waiuL5vDfD+T+smfv1c6SzxZOVLAtMXqleEtTw2bcmzehw7ao5 gQrRicHcXz7pLZrbZKFSxiRrH/7qzVyFj7kLL0l8V5YTexuyLeged8n7y3NPNOUUKrEUZyQa ajEXFScCAItYDI51AgAA Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 13:28:45 -0000 --_000_7594FB04B1934943A5C02806D1A2204B051F0CESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, If "realm" is bad wording, that can be changed :) SIP history (assuming you refer to History-Info), we were thinking about th= at, but it's is not really the same semantics, and there is no redirection = or retargeting taking place in this case. It would probably be good to add a few words about that, though. Regards, Christer From: Olle E. Johansson [mailto:oej@edvina.net] Sent: 10. joulukuuta 2012 15:08 To: Christer Holmberg Cc: Olle E. Johansson; sipcore@ietf.org Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 10 dec 2012 kl. 11:04 skrev Christer Holmberg >: Hi, We've submitted a new draft, draft-holmberg-sipcore-received-realm-00.txt, = which allows network entry points to indicate the preceding network, from w= here a request is received. The information can be used inside the network,= to provide services, routing etc, based on the information. The indication= is conveyed as a new Via header field parameter, "received-realm". In 3GPP, there is currently a use-case where the information is used to pro= vide services within a transit network. Another use-case, also documented i= n the draft, is transit routing. http://www.ietf.org/id/draft-holmberg-sipcore-received-realm-00.txt I think using the keyword "realm" here is unfortunate, since it's an import= ant concept in SIP authentication. >From a quick reading, I don't see that you refer to the authentication real= m, but introduce "realm" for something else. Also, I don't see any comparision with SIP history and why that can't be us= ed. Maybe SIP identity can add a secure way of handling this situation too. /O --_000_7594FB04B1934943A5C02806D1A2204B051F0CESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

If “realm” is= bad wording, that can be changed :)

 <= /p>

SIP history (assuming you= refer to History-Info), we were thinking about that, but it’s is not= really the same semantics, and there is no redirection or retargeting taking place in this case.

 <= /p>

It would probably be good= to add a few words about that, though.

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: Olle E. = Johansson [mailto:oej@edvina.net]
Sent: 10. joulukuuta 2012 15:08
To: Christer Holmberg
Cc: Olle E. Johansson; sipcore@ietf.org
Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-re= alm-00

 

 



Hi,

 

We’ve submitted a new draft, draf= t-holmberg-sipcore-received-realm-00.txt, which allows network entry points= to indicate the preceding network, from where a request is received. The information can be used inside the network, to provide services, routi= ng etc, based on the information. The indication is conveyed as a new Via h= eader field parameter, “received-realm”.

 

In 3GPP, there is currently a use-case = where the information is used to provide services within a transit network.= Another use-case, also documented in the draft, is transit routing.

 

 

 

I think using the keyword "realm" here is = unfortunate, since it's an important concept in SIP authentication.

From a quick reading, I don't see that you refer to = the authentication realm, but introduce "realm" for something

else.

 

Also, I don't see any comparision with SIP history a= nd why that can't be used. Maybe SIP identity can add a secure

way of handling this situation too.

 

/O

--_000_7594FB04B1934943A5C02806D1A2204B051F0CESESSMB209ericsso_-- From worley@shell01.TheWorld.com Mon Dec 10 08:16:05 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B873E21F853A for ; Mon, 10 Dec 2012 08:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9gyRX6zZdRY for ; Mon, 10 Dec 2012 08:16:04 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5D04621F8532 for ; Mon, 10 Dec 2012 08:16:03 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qBAGFgpZ003704; Mon, 10 Dec 2012 11:15:44 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id qBAGFfOE2759308; Mon, 10 Dec 2012 11:15:41 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qBAGFeha2750607; Mon, 10 Dec 2012 11:15:40 -0500 (EST) Date: Mon, 10 Dec 2012 11:15:40 -0500 (EST) Message-Id: <201212101615.qBAGFeha2750607@shell01.TheWorld.com> From: worley@alum.mit.edu (Dale R. Worley) Sender: worley@alum.mit.edu (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 16:16:05 -0000 > From: Christer Holmberg > > We've submitted a new draft, > draft-holmberg-sipcore-received-realm-00.txt, which allows network > entry points to indicate the preceding network, from where a request > is received. The information can be used inside the network, to > provide services, routing etc, based on the information. The > indication is conveyed as a new Via header field parameter, > "received-realm". It's an interesting question what this "realm" really is. Currently, we have History-Info, and we have the Via "received" parameter. But it seems clear to me that the real intention is to identify "From which service provider's network was this request received?" And that information is not the same as knowing which particular host it was received from. The difficulty I see is that there is no standardizable way of designating this. Within any one network, there may be standard designators of origin networks, but globally there won't be. This is in contrast with History-Info and "received", which specify IP addresses or DNS names, which have global meanings (more or less). So it seems to me that all that can be standardized is the particular method for carrying this information and some of its syntax. It's really just a private extension to Via that never really needs to interwork between systems that aren't in one administrative domain. As written, the draft seems to gloss over this issue; it mentions a "network realm value" without mentioning that these values are not standardized. There are also some interesting security considerations if a host attaches a fraudulent "received-realm" to a request before forwarding it to another network... Dale From oej@edvina.net Mon Dec 10 08:24:26 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC2521F84FC for ; Mon, 10 Dec 2012 08:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKkk-2zc0GfY for ; Mon, 10 Dec 2012 08:24:26 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id C67C321F8534 for ; Mon, 10 Dec 2012 08:24:24 -0800 (PST) Received: from [IPv6:2001:16d8:cc57:1000::42:1003] (unknown [IPv6:2001:16d8:cc57:1000::42:1003]) by smtp7.webway.se (Postfix) with ESMTPA id EB81A754A8A7; Mon, 10 Dec 2012 16:24:16 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <201212101615.qBAGFeha2750607@shell01.TheWorld.com> Date: Mon, 10 Dec 2012 17:24:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0A2DE818-32D6-4820-8D11-A14AB68B88C0@edvina.net> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> <201212101615.qBAGFeha2750607@shell01.TheWorld.com> To: worley@alum.mit.edu (Dale R. Worley) X-Mailer: Apple Mail (2.1499) Cc: sipcore@ietf.org, "Olle E. Johansson" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 16:24:27 -0000 10 dec 2012 kl. 17:15 skrev worley@alum.mit.edu (Dale R. Worley): >> From: Christer Holmberg >>=20 >> We've submitted a new draft, >> draft-holmberg-sipcore-received-realm-00.txt, which allows network >> entry points to indicate the preceding network, from where a request >> is received. The information can be used inside the network, to >> provide services, routing etc, based on the information. The >> indication is conveyed as a new Via header field parameter, >> "received-realm". >=20 > It's an interesting question what this "realm" really is. Currently, > we have History-Info, and we have the Via "received" parameter. But > it seems clear to me that the real intention is to identify "From > which service provider's network was this request received?" And that > information is not the same as knowing which particular host it was > received from. >=20 > The difficulty I see is that there is no standardizable way of > designating this. Within any one network, there may be standard > designators of origin networks, but globally there won't be. This is > in contrast with History-Info and "received", which specify IP > addresses or DNS names, which have global meanings (more or less). >=20 > So it seems to me that all that can be standardized is the particular > method for carrying this information and some of its syntax. It's > really just a private extension to Via that never really needs to > interwork between systems that aren't in one administrative domain. >=20 > As written, the draft seems to gloss over this issue; it mentions a > "network realm value" without mentioning that these values are not > standardized. >=20 It also says "globally unique" - so why not just use a domain or host = name? > There are also some interesting security considerations if a host > attaches a fraudulent "received-realm" to a request before forwarding > it to another network... The security part was missing... Which is why I hinted at SIP identity. Use a domain as a globally unique network identifier then sign it. If the goal is to use it for routing responses to the specific network, we should look into that issue, but I'm not clear on what the problem to = be solved is. /O= From christer.holmberg@ericsson.com Mon Dec 10 08:25:10 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBA621F853B for ; Mon, 10 Dec 2012 08:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.164 X-Spam-Level: X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2irdLjbcOdd for ; Mon, 10 Dec 2012 08:25:10 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id CD7B921F8534 for ; Mon, 10 Dec 2012 08:25:09 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-c2-50c60ce3f252 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 4C.52.04318.3EC06C05; Mon, 10 Dec 2012 17:25:08 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0318.001; Mon, 10 Dec 2012 17:25:07 +0100 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 Thread-Index: Ac3WvTkjByInUM1RTJSbqOOOIsdUsgANIWGaAAAeTp8= Date: Mon, 10 Dec 2012 16:25:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B05216C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se>, <201212101615.qBAGFeha2750607@shell01.TheWorld.com> In-Reply-To: <201212101615.qBAGFeha2750607@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvje4TnmMBBnPuS1h8/bGJzeLq5B9M Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGkqOSBS3CFSfvNTA1MC7j72Lk5JAQMJE4 tGseE4QtJnHh3nq2LkYuDiGBQ4wSiw9PY4FwljBKXPm4GijDwcEmYCHR/U8bpEFEQEuie8MU FhCbWUBT4tHOvWCDhAW8JLb/mcIGUeMtMWNrJzuEbSUxv/cGM4jNIqAq0bRrHdhIXqCaKf0J IGEhgXqJj3uPgLVyCjhI3Hu6hBXEZgS67fupNUwQq8Qlbj2ZD3WzgMSSPeeZIWxRiZeP/7FC 2IoSO8+2M0PU60gs2P2JDcLWlli28DVYnFdAUOLkzCcsExjFZiEZOwtJyywkLbOQtCxgZFnF yJ6bmJmTXm6+iREYHwe3/DbYwbjpvtghRmkOFiVxXj3V/f5CAumJJanZqakFqUXxRaU5qcWH GJk4OKUaGKWbps6N5GvTFmH7mJsSd7R/8mmrq9+Vr1tz/3cqszmzN8+GQXDHKZ4jsgyTbdNP PdePeO+RKCWpyeO+cIXQk79TZrtFT1FO/1N8y/u0TPqHmHmOAfOWc2w/JD+R+0fJ1BUPf8yX /1n4mYNvwkfXBcIJWhzWJc/fLLr4IfxhdrNP2d4ZvbwS7UosxRmJhlrMRcWJAAQD215dAgAA Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 16:25:11 -0000 Hi Dale, >> We've submitted a new draft, >> draft-holmberg-sipcore-received-realm-00.txt, which allows network >> entry points to indicate the preceding network, from where a request >> is received. The information can be used inside the network, to >> provide services, routing etc, based on the information. The >> indication is conveyed as a new Via header field parameter, >> "received-realm". > > It's an interesting question what this "realm" really is. Currently, > we have History-Info, and we have the Via "received" parameter. But > it seems clear to me that the real intention is to identify "From > which service provider's network was this request received?" And that > information is not the same as knowing which particular host it was > received from. Correct. > The difficulty I see is that there is no standardizable way of > designating this. Within any one network, there may be standard > designators of origin networks, but globally there won't be. This is > in contrast with History-Info and "received", which specify IP > addresses or DNS names, which have global meanings (more or less). > > So it seems to me that all that can be standardized is the particular > method for carrying this information and some of its syntax. It's > really just a private extension to Via that never really needs to > interwork between systems that aren't in one administrative domain. > > As written, the draft seems to gloss over this issue; it mentions a > "network realm value" without mentioning that these values are not > standardized. Very good point. The idea is not to standardize, or to create some kind of registry, where t= he "network realm values" would be standardized. In many cases, the value will only be consumed within a network, so the net= work operator can use whatever values he wants. If there are cases where so= me interworking is needed, operators need to deal with that as part of thei= r interworking agreement. > There are also some interesting security considerations if a host > attaches a fraudulent "received-realm" to a request before forwarding > it to another network... The idea is that the network that receives the request indicates where it c= ame from. Ie it would not need to trust a value coming from the adjacent ne= twork, but it would need to be able to verify from where the request comes. Regards, Christer From christer.holmberg@ericsson.com Mon Dec 10 08:29:29 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A9E21F84ED for ; Mon, 10 Dec 2012 08:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.167 X-Spam-Level: X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHweApzdxR8K for ; Mon, 10 Dec 2012 08:29:28 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B8BCA21F84EB for ; Mon, 10 Dec 2012 08:29:23 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-20-50c60de27534 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id CA.DC.24873.2ED06C05; Mon, 10 Dec 2012 17:29:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0318.001; Mon, 10 Dec 2012 17:29:21 +0100 From: Christer Holmberg To: "Olle E. Johansson" , "Dale R. Worley" Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 Thread-Index: Ac3WvTkjByInUM1RTJSbqOOOIsdUsgANIWGa///xU4CAABEWHw== Date: Mon, 10 Dec 2012 16:29:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B05218F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> <201212101615.qBAGFeha2750607@shell01.TheWorld.com>, <0A2DE818-32D6-4820-8D11-A14AB68B88C0@edvina.net> In-Reply-To: <0A2DE818-32D6-4820-8D11-A14AB68B88C0@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje4j3mMBBnO26lq8XH2I2eLrj01s Flcn/2ByYPb4+/4Dk8e0tStZPZYs+ckUwBzFZZOSmpNZllqkb5fAldHYvJOt4IlwxdzTk1ka GF/zdzFyckgImEhc+fmDEcIWk7hwbz1bFyMXh5DAIUaJVV33WCCcJYwSzeduMncxcnCwCVhI dP/TBjFFBIIknj7zBOllFtCUeLRzLxOILSzgJbH9zxQ2EFtEwFtixtZOdohyJ4mdh6NAwiwC qhLb771nBbF5gUoaZ99lgti0mVHi8NW1YHM4Bewkbh1azQ5iMwLd9v3UGiaIXeISt57MZ4K4 WUBiyZ7zzBC2qMTLx/9YIWxFiZ1n25kh6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzUIy dhaSlllIWmYhaVnAyLKKkT03MTMnvdxoEyMwag5u+a26g/HOOZFDjNIcLErivNZb9/gLCaQn lqRmp6YWpBbFF5XmpBYfYmTi4JRqYExObI1svJKnuOTTFOEfX1WnnWA62jJ1pcJtFalLQsou 1T1Owj0BH7gZVv+SWvGNxzppHe96L6OJZlzGc+Kvs7HuDE4MD+N3epk9bXZ4W8uBHVxxE9P/ +EoW/LJfw5C5+mtexvfZb9OMZwmzca8xemwluuOXj4Z8tL/MG5VuJplThi9yoi1eKLEUZyQa ajEXFScCADZYENJoAgAA Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 16:29:29 -0000 Hi, >>> We've submitted a new draft, >>> draft-holmberg-sipcore-received-realm-00.txt, which allows network >>> entry points to indicate the preceding network, from where a request >>> is received. The information can be used inside the network, to >>> provide services, routing etc, based on the information. The >>> indication is conveyed as a new Via header field parameter, >>> "received-realm". >> >> It's an interesting question what this "realm" really is. Currently, >> we have History-Info, and we have the Via "received" parameter. But >> it seems clear to me that the real intention is to identify "From >> which service provider's network was this request received?" And that >> information is not the same as knowing which particular host it was >> received from. >> >> The difficulty I see is that there is no standardizable way of >> designating this. Within any one network, there may be standard >> designators of origin networks, but globally there won't be. This is >> in contrast with History-Info and "received", which specify IP >> addresses or DNS names, which have global meanings (more or less). >> >> So it seems to me that all that can be standardized is the particular >> method for carrying this information and some of its syntax. It's >> really just a private extension to Via that never really needs to >> interwork between systems that aren't in one administrative domain. >> >> As written, the draft seems to gloss over this issue; it mentions a >> "network realm value" without mentioning that these values are not >> standardized. >> > > It also says "globally unique" - so why not just use a domain or host nam= e? That is actually the idea :) My appologies if we didn't make it clear. I am not sure whether the value actually has to be globally unique, as long= as it's unique within the network that uses the value. >> There are also some interesting security considerations if a host >> attaches a fraudulent "received-realm" to a request before forwarding >> it to another network... > > The security part was missing... Which is why I hinted at SIP identity. > Use a domain as a globally unique network identifier then sign it. > > If the goal is to use it for routing responses to the specific network, > we should look into that issue, but I'm not clear on what the problem to = be solved is. That is not the goal. Responses are routed as defined in RFC 3261, and this= draft doesn't change that. Regards, Christer From oej@edvina.net Mon Dec 10 08:41:32 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D4721F854F for ; Mon, 10 Dec 2012 08:41:32 -0800 (PST) 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.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tem2bEJK-ZEo for ; Mon, 10 Dec 2012 08:41:28 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id ECE2421F8548 for ; Mon, 10 Dec 2012 08:41:27 -0800 (PST) Received: from [192.168.40.36] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 74AF5754A8A7; Mon, 10 Dec 2012 16:41:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <7594FB04B1934943A5C02806D1A2204B05218F@ESESSMB209.ericsson.se> Date: Mon, 10 Dec 2012 17:41:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <676582FB-92BD-4CB4-858E-C9D44ECB78C4@edvina.net> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> <201212101615.qBAGFeha2750607@shell01.TheWorld.com>, <0A2DE818-32D6-4820-8D11-A14AB68B88C0@edvina.net> <7594FB04B1934943A5C02806D1A2204B05218F@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1499) Cc: "Dale R. Worley" , "sipcore@ietf.org" , "Olle E. Johansson" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 16:41:32 -0000 10 dec 2012 kl. 17:29 skrev Christer Holmberg = : >=20 > Hi, >=20 >>>> We've submitted a new draft, >>>> draft-holmberg-sipcore-received-realm-00.txt, which allows network >>>> entry points to indicate the preceding network, from where a = request >>>> is received. The information can be used inside the network, to >>>> provide services, routing etc, based on the information. The >>>> indication is conveyed as a new Via header field parameter, >>>> "received-realm". >>>=20 >>> It's an interesting question what this "realm" really is. = Currently, >>> we have History-Info, and we have the Via "received" parameter. But >>> it seems clear to me that the real intention is to identify "From >>> which service provider's network was this request received?" And = that >>> information is not the same as knowing which particular host it was >>> received from. >>>=20 >>> The difficulty I see is that there is no standardizable way of >>> designating this. Within any one network, there may be standard >>> designators of origin networks, but globally there won't be. This = is >>> in contrast with History-Info and "received", which specify IP >>> addresses or DNS names, which have global meanings (more or less). >>>=20 >>> So it seems to me that all that can be standardized is the = particular >>> method for carrying this information and some of its syntax. It's >>> really just a private extension to Via that never really needs to >>> interwork between systems that aren't in one administrative domain. >>>=20 >>> As written, the draft seems to gloss over this issue; it mentions a >>> "network realm value" without mentioning that these values are not >>> standardized. >>>=20 >>=20 >> It also says "globally unique" - so why not just use a domain or host = name? >=20 > That is actually the idea :) My appologies if we didn't make it clear. >=20 > I am not sure whether the value actually has to be globally unique, as = long as it's unique within the network that uses the value. >=20 >>> There are also some interesting security considerations if a host >>> attaches a fraudulent "received-realm" to a request before = forwarding >>> it to another network... >>=20 >> The security part was missing... Which is why I hinted at SIP = identity. >> Use a domain as a globally unique network identifier then sign it. >>=20 >> If the goal is to use it for routing responses to the specific = network, >> we should look into that issue, but I'm not clear on what the problem = to be solved is. >=20 > That is not the goal. Responses are routed as defined in RFC 3261, and = this draft doesn't change that. So what is the problem you are trying to solve, Christer? /O= From christer.holmberg@ericsson.com Mon Dec 10 08:54:31 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBF321F84C7 for ; Mon, 10 Dec 2012 08:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgOJEIZs9d-e for ; Mon, 10 Dec 2012 08:54:30 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6656C21F84C6 for ; Mon, 10 Dec 2012 08:54:30 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-51-50c613c54d22 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A3.8F.24873.5C316C05; Mon, 10 Dec 2012 17:54:29 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0318.001; Mon, 10 Dec 2012 17:54:29 +0100 From: Christer Holmberg To: "Olle E. Johansson" Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 Thread-Index: Ac3WvTkjByInUM1RTJSbqOOOIsdUsgANIWGa///xU4CAABEWH///87UAgAATDN8= Date: Mon, 10 Dec 2012 16:54:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B05229B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> <201212101615.qBAGFeha2750607@shell01.TheWorld.com>, <0A2DE818-32D6-4820-8D11-A14AB68B88C0@edvina.net> <7594FB04B1934943A5C02806D1A2204B05218F@ESESSMB209.ericsson.se>, <676582FB-92BD-4CB4-858E-C9D44ECB78C4@edvina.net> In-Reply-To: <676582FB-92BD-4CB4-858E-C9D44ECB78C4@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje5R4WMBBps3Klu8XH2I2eLrj01s Flcn/2ByYPb4+/4Dk8e0tStZPZYs+ckUwBzFZZOSmpNZllqkb5fAlfFz2j6mggbJipbePSwN jDNEuhg5OSQETCSu3HnOBmGLSVy4tx7I5uIQEjjEKPHq3nFGCGcJo8TNdTdZuhg5ONgELCS6 /2mDNIgIaEhc+HIFrJlZIFji2JrHLCC2sICXxPY/U9ggarwlZmztZIew/STe7nrCDjKGRUBV 4nSPPEiYF6jk0MNtUKuWM0lsbf3KCJLgFLCTuHVqCSuIzQh03PdTa5ggdolL3HoynwniaAGJ JXvOM0PYohIvH/9jhbAVJXaebWeGqNeRWLD7E9Sd2hLLFr5mhlgsKHFy5hOWCYxis5CMnYWk ZRaSlllIWhYwsqxiZM9NzMxJLzfaxAiMm4NbfqvuYLxzTuQQozQHi5I4r/XWPf5CAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGHfVLunxfGlxYcKUEuGkh31TunnD/gvezeyWmXlwtkv57EPX bCz36Pd+WDTFLF7yosYE59d/Hl1ZZOJXmPj2wb1Z4sqP2a5yu+tdV5afU/Wtzmcpx5XbIoWh p5+x7nrg+dCmQfX2nJz6R/tPzlyzweL79YvMnKtPcXoqPedRFb/2eTJLSqfvDx0lluKMREMt 5qLiRAD1E5ukaQIAAA== Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 16:54:31 -0000 Hi, >>>>> We've submitted a new draft, >>>>> draft-holmberg-sipcore-received-realm-00.txt, which allows network >>>>> entry points to indicate the preceding network, from where a request >>>>> is received. The information can be used inside the network, to >>>>> provide services, routing etc, based on the information. The >>>>> indication is conveyed as a new Via header field parameter, >>>>> "received-realm". >>>> >>>> It's an interesting question what this "realm" really is. Currently, >>>> we have History-Info, and we have the Via "received" parameter. But >>>> it seems clear to me that the real intention is to identify "From >>>> which service provider's network was this request received?" And that >>>> information is not the same as knowing which particular host it was >>>> received from. >>>> >>>> The difficulty I see is that there is no standardizable way of >>>> designating this. Within any one network, there may be standard >>>> designators of origin networks, but globally there won't be. This is >>>> in contrast with History-Info and "received", which specify IP >>>> addresses or DNS names, which have global meanings (more or less). >>>> >>>> So it seems to me that all that can be standardized is the particular >>>> method for carrying this information and some of its syntax. It's >>>> really just a private extension to Via that never really needs to >>>> interwork between systems that aren't in one administrative domain. >>>> >>>> As written, the draft seems to gloss over this issue; it mentions a >>>> "network realm value" without mentioning that these values are not >>>> standardized. >>>> >>> >>> It also says "globally unique" - so why not just use a domain or host n= ame? >> >> That is actually the idea :) My appologies if we didn't make it clear. >> >> I am not sure whether the value actually has to be globally unique, as l= ong as it's unique within the network that uses the value. >> >>>> There are also some interesting security considerations if a host >>>> attaches a fraudulent "received-realm" to a request before forwarding >>>> it to another network... >>> >>> The security part was missing... Which is why I hinted at SIP identity. >>> Use a domain as a globally unique network identifier then sign it. >>> >>> If the goal is to use it for routing responses to the specific network, >>> we should look into that issue, but I'm not clear on what the problem t= o be solved is. >> >> That is not the goal. Responses are routed as defined in RFC 3261, and t= his draft doesn't change that. > > So what is the problem you are trying to solve, Christer? To allow the entry point for network X to insert an indication from which n= etwork the requests was received, so that other entities (e.g. Application = Servers or routing functions) within network X can use the information to m= ake service/routing decisions. Nothing more than that, really :) In transit networks, services and routing decissions are often applied base= d on the preceding network (rather than users, as the transit network typic= ally does not have any user information). Regards, Christer From pkyzivat@alum.mit.edu Mon Dec 10 09:16:09 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40CD21F8521 for ; Mon, 10 Dec 2012 09:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.372 X-Spam-Level: X-Spam-Status: No, score=-0.372 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBSZjFm6-CNY for ; Mon, 10 Dec 2012 09:16:09 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 0610621F850D for ; Mon, 10 Dec 2012 09:16:08 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta03.westchester.pa.mail.comcast.net with comcast id ZobJ1k0051vXlb853tG8o7; Mon, 10 Dec 2012 17:16:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id ZtG81k0063ZTu2S3dtG8BA; Mon, 10 Dec 2012 17:16:08 +0000 Message-ID: <50C618D7.4040201@alum.mit.edu> Date: Mon, 10 Dec 2012 12:16:07 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355159768; bh=hOch45WZuBgYRy6HiGq6eGZdHfiokq43e/grp7V9YXY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FupmN+bElZBugaZe7C3vi3T/SgesftWKCznRIBsknEXtkD6wNIHXrhREGIpq5MqHi 793L4GBKYXkpLrljW2nfpTOwyn9z6iNO7aitYtLWABK5/shCtwpdRyYxsTNIPPytBG aO/nBElOhRZcRQMwGefY9iDtQMQ3qKT5m1sYucgWN+5UK/k5iwLF6IZBGWyrewbFTV thNIthrYpUsXQrtSEbkwHboiF2OXlmUMLw2Iv75gEP+OIGJgO7xfxhwnBd66zp6weZ auyXIdcZJ8inf82f1CfHySwfR78ylDanA7Rm+ovo+AAw0sanXd8RpZVAm7wbSbXJbT D6SDs99Fd5Tig== Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 17:16:09 -0000 [as sipcore co-chair] While a little discussion on this list won't hurt, IMO it is premature to assume that this will be sipcore work. (In fact, the proposed mechanism falls outside the scope of sipcore.) It strikes me that this subject might be of interest to people who don't follow sipcore closely. (If there are any interested in RAI that don't follow sipcore closely.) For instance, the people who care about DRINKS and the now closed SPEERMINT. Also, as often happens, this draft starts with the solution before there has been discussion and refinement of the problem. So, I think this might be more appropriately discussed in DISPATCH, but I'll listen to arguments to the contrary. Thanks, Paul On 12/10/12 5:04 AM, Christer Holmberg wrote: > Hi, > > We’ve submitted a new draft, > draft-holmberg-sipcore-received-realm-00.txt, which allows network entry > points to indicate the preceding network, from where a request is > received. The information can be used inside the network, to provide > services, routing etc, based on the information. The indication is > conveyed as a new Via header field parameter, “received-realm”. > > In 3GPP, there is currently a use-case where the information is used to > provide services within a transit network. Another use-case, also > documented in the draft, is transit routing. > > http://www.ietf.org/id/draft-holmberg-sipcore-received-realm-00.txt > > Regards, > > Christer > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From richard@shockey.us Mon Dec 10 09:31:33 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA5D21F84CE for ; Mon, 10 Dec 2012 09:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.324 X-Spam-Level: X-Spam-Status: No, score=-102.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRaM0R6ddXwX for ; Mon, 10 Dec 2012 09:31:32 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id ADF1C21F8502 for ; Mon, 10 Dec 2012 09:31:32 -0800 (PST) Received: (qmail 14644 invoked by uid 0); 10 Dec 2012 17:30:43 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy11.bluehost.com with SMTP; 10 Dec 2012 17:30:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=NJkmkW+dkWM/GIjCIwqLlgQuoifLX2cPFG/eWHZstVQ=; b=HVQUQ+tbfUdmNGLsXtf4Jx8/dSMeEnCtF6AVOwf8LHDUOe3X2PvceMoCEDGjCPFQqM3Myd5XcrSqXloF9NU4DimiQDr63ibRbkqH8/BDWxk1oshIgekohpLB+3AtlYpF; Received: from [71.191.243.130] (port=56449 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Ti7Bh-00043b-Ts; Mon, 10 Dec 2012 10:30:42 -0700 From: "Richard Shockey" To: "'Christer Holmberg'" , "'Olle E. Johansson'" References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> <201212101615.qBAGFeha2750607@shell01.TheWorld.com>, <0A2DE818-32D6-4820-8D11-A14AB68B88C0@edvina.net> <7594FB04B1934943A5C02806D1A2204B05218F@ESESSMB209.ericsson.se>, <676582FB-92BD-4CB4-858E-C9D44ECB78C4@edvina.net> <7594FB04B1934943A5C02806D1A2204B05229B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B05229B@ESESSMB209.ericsson.se> Date: Mon, 10 Dec 2012 12:30:40 -0500 Message-ID: <007401cdd6fc$1486e5a0$3d94b0e0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3WvTkjByInUM1RTJSbqOOOIsdUsgANIWGa///xU4CAABEWH///87UAgAATDN////SusA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Cc: "'Dale R. Worley'" , sipcore@ietf.org Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 17:31:33 -0000 IMHO this would be very very useful. The use cases are well understood. -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Monday, December 10, 2012 11:54 AM To: Olle E. Johansson Cc: Dale R. Worley; sipcore@ietf.org Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 Hi, >>>>> We've submitted a new draft, >>>>> draft-holmberg-sipcore-received-realm-00.txt, which allows network >>>>> entry points to indicate the preceding network, from where a >>>>> request is received. The information can be used inside the >>>>> network, to provide services, routing etc, based on the >>>>> information. The indication is conveyed as a new Via header field >>>>> parameter, "received-realm". >>>> >>>> It's an interesting question what this "realm" really is. >>>> Currently, we have History-Info, and we have the Via "received" >>>> parameter. But it seems clear to me that the real intention is to >>>> identify "From which service provider's network was this request >>>> received?" And that information is not the same as knowing which >>>> particular host it was received from. >>>> >>>> The difficulty I see is that there is no standardizable way of >>>> designating this. Within any one network, there may be standard >>>> designators of origin networks, but globally there won't be. This >>>> is in contrast with History-Info and "received", which specify IP >>>> addresses or DNS names, which have global meanings (more or less). >>>> >>>> So it seems to me that all that can be standardized is the >>>> particular method for carrying this information and some of its >>>> syntax. It's really just a private extension to Via that never >>>> really needs to interwork between systems that aren't in one administrative domain. >>>> >>>> As written, the draft seems to gloss over this issue; it mentions a >>>> "network realm value" without mentioning that these values are not >>>> standardized. >>>> >>> >>> It also says "globally unique" - so why not just use a domain or host name? >> >> That is actually the idea :) My appologies if we didn't make it clear. >> >> I am not sure whether the value actually has to be globally unique, as long as it's unique within the network that uses the value. >> >>>> There are also some interesting security considerations if a host >>>> attaches a fraudulent "received-realm" to a request before >>>> forwarding it to another network... >>> >>> The security part was missing... Which is why I hinted at SIP identity. >>> Use a domain as a globally unique network identifier then sign it. >>> >>> If the goal is to use it for routing responses to the specific >>> network, we should look into that issue, but I'm not clear on what the problem to be solved is. >> >> That is not the goal. Responses are routed as defined in RFC 3261, and this draft doesn't change that. > > So what is the problem you are trying to solve, Christer? To allow the entry point for network X to insert an indication from which network the requests was received, so that other entities (e.g. Application Servers or routing functions) within network X can use the information to make service/routing decisions. Nothing more than that, really :) In transit networks, services and routing decissions are often applied based on the preceding network (rather than users, as the transit network typically does not have any user information). Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From oej@edvina.net Mon Dec 10 09:32:05 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550EA21F851A for ; Mon, 10 Dec 2012 09:32:05 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JU-dXjQlOapV for ; Mon, 10 Dec 2012 09:32:04 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 4875121F84CE for ; Mon, 10 Dec 2012 09:32:03 -0800 (PST) Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 80EAD754A8B3; Mon, 10 Dec 2012 17:32:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <7594FB04B1934943A5C02806D1A2204B05229B@ESESSMB209.ericsson.se> Date: Mon, 10 Dec 2012 18:32:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> <201212101615.qBAGFeha2750607@shell01.TheWorld.com>, <0A2DE818-32D6-4820-8D11-A14AB68B88C0@edvina.net> <7594FB04B1934943A5C02806D1A2204B05218F@ESESSMB209.ericsson.se>, <676582FB-92BD-4CB4-858E-C9D44ECB78C4@edvina.net> <7594FB04B1934943A5C02806D1A2204B05229B@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1499) Cc: "Dale R. Worley" , "sipcore@ietf.org" , "Olle E. Johansson" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 17:32:05 -0000 10 dec 2012 kl. 17:54 skrev Christer Holmberg = : >=20 > Hi, >=20 >>>>>> We've submitted a new draft, >>>>>> draft-holmberg-sipcore-received-realm-00.txt, which allows = network >>>>>> entry points to indicate the preceding network, from where a = request >>>>>> is received. The information can be used inside the network, to >>>>>> provide services, routing etc, based on the information. The >>>>>> indication is conveyed as a new Via header field parameter, >>>>>> "received-realm". >>>>>=20 >>>>> It's an interesting question what this "realm" really is. = Currently, >>>>> we have History-Info, and we have the Via "received" parameter. = But >>>>> it seems clear to me that the real intention is to identify "From >>>>> which service provider's network was this request received?" And = that >>>>> information is not the same as knowing which particular host it = was >>>>> received from. >>>>>=20 >>>>> The difficulty I see is that there is no standardizable way of >>>>> designating this. Within any one network, there may be standard >>>>> designators of origin networks, but globally there won't be. This = is >>>>> in contrast with History-Info and "received", which specify IP >>>>> addresses or DNS names, which have global meanings (more or less). >>>>>=20 >>>>> So it seems to me that all that can be standardized is the = particular >>>>> method for carrying this information and some of its syntax. It's >>>>> really just a private extension to Via that never really needs to >>>>> interwork between systems that aren't in one administrative = domain. >>>>>=20 >>>>> As written, the draft seems to gloss over this issue; it mentions = a >>>>> "network realm value" without mentioning that these values are not >>>>> standardized. >>>>>=20 >>>>=20 >>>> It also says "globally unique" - so why not just use a domain or = host name? >>>=20 >>> That is actually the idea :) My appologies if we didn't make it = clear. >>>=20 >>> I am not sure whether the value actually has to be globally unique, = as long as it's unique within the network that uses the value. >>>=20 >>>>> There are also some interesting security considerations if a host >>>>> attaches a fraudulent "received-realm" to a request before = forwarding >>>>> it to another network... >>>>=20 >>>> The security part was missing... Which is why I hinted at SIP = identity. >>>> Use a domain as a globally unique network identifier then sign it. >>>>=20 >>>> If the goal is to use it for routing responses to the specific = network, >>>> we should look into that issue, but I'm not clear on what the = problem to be solved is. >>>=20 >>> That is not the goal. Responses are routed as defined in RFC 3261, = and this draft doesn't change that. >>=20 >> So what is the problem you are trying to solve, Christer? >=20 > To allow the entry point for network X to insert an indication from = which network the requests was received, so that other entities (e.g. = Application Servers or routing functions) within network X can use the = information to make service/routing decisions. Nothing more than that, = really :) >=20 > In transit networks, services and routing decissions are often applied = based on the preceding network (rather than users, as the transit = network typically does not have any user information). So what's the reason to insert it into the Via header? The benefit is = that you get it in the responses, which you claim you don't need. Why not a new header, like originating-domain or something else? /O= From christer.holmberg@ericsson.com Mon Dec 10 12:15:49 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCB421F8634 for ; Mon, 10 Dec 2012 12:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nG-WSsmK1sDQ for ; Mon, 10 Dec 2012 12:15:48 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CB43321F8633 for ; Mon, 10 Dec 2012 12:15:47 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-0a-50c642f22b85 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A6.6D.24873.2F246C05; Mon, 10 Dec 2012 21:15:46 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0318.001; Mon, 10 Dec 2012 21:15:46 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 Thread-Index: Ac3WvTkjByInUM1RTJSbqOOOIsdUsgANG+aAAAgkdVk= Date: Mon, 10 Dec 2012 20:15:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B05252C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se>, <50C618D7.4040201@alum.mit.edu> In-Reply-To: <50C618D7.4040201@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+Jvje4np2MBBhumylqs2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGqc1fWAvuCVbcPPCMpYFxN18XIyeHhICJ xOJls9khbDGJC/fWs3UxcnEICRxilNjQfpUZwlnCKLG3dxtrFyMHB5uAhUT3P22QBhGBQImr SyYwg9jCAl4S2/9MYYOIe0vM2NrJDlIuImAlsb7TAiTMIqAqsfzZOkYQmxeoZN6GXywgtpBA tsT0YydZQMo5BXQkdk7KAwkzAp3z/dQaJhCbWUBc4taT+UwQZwpILNlznhnCFpV4+fgf2GES AooSy/vlIMoNJN6fm88MYWtLLFv4mhliq6DEyZlPWCYwis5CMnUWkpZZSFpmIWlZwMiyipE9 NzEzJ73caBMjMAoObvmtuoPxzjmRQ4zSHCxK4rzWW/f4CwmkJ5akZqemFqQWxReV5qQWH2Jk 4uCUamAMUF2S5C8w1/WB++R/gqv7+55NnhOwvf9yhmAyn8Km9N9sjWpFj1s6qxMt94fozz88 4axXl4B6sdvdg3O4zs/9t+OYBt8yJoG9p2Rjjtpm5DAXW+VvEImwCfyufvKi5pW+6DW7b7LN 2Tn/zvIJ/wxCLs5+JmmaWlhSpBRmWPf7vcC37sAtjSZKLMUZiYZazEXFiQCsJVBkUAIAAA== Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 20:15:49 -0000 Hi Paul, >[as sipcore co-chair] > >While a little discussion on this list won't hurt, IMO it is premature >to assume that this will be sipcore work. (In fact, the proposed >mechanism falls outside the scope of sipcore.) I believe Via header parameters are within the scope of sipcore. (For example, we did the keep parameter in sipcore.) >It strikes me that this subject might be of interest to people who don't f= ollow sipcore closely. >(If there are any interested in RAI that don't follow sipcore closely.) >For instance, the people who care about DRINKS and the now closed SPEERMIN= T. > >Also, as often happens, this draft starts with the solution before there >has been discussion and refinement of the problem. > >So, I think this might be more appropriately discussed in DISPATCH, but >I'll listen to arguments to the contrary. In general, I agree with you, and we were thinking about taking it to DISPA= TCH. However, as this is only about an indicator, in typical cases inserted and = consumed within a network, and it can be done using an existing header fiel= d, we thought that it could be taken directly to SIPCORE. But, community decides :) Regards, Christer On 12/10/12 5:04 AM, Christer Holmberg wrote: > Hi, > > We=92ve submitted a new draft, > draft-holmberg-sipcore-received-realm-00.txt, which allows network entry > points to indicate the preceding network, from where a request is > received. The information can be used inside the network, to provide > services, routing etc, based on the information. The indication is > conveyed as a new Via header field parameter, =93received-realm=94. > > In 3GPP, there is currently a use-case where the information is used to > provide services within a transit network. Another use-case, also > documented in the draft, is transit routing. > > http://www.ietf.org/id/draft-holmberg-sipcore-received-realm-00.txt > > Regards, > > Christer > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Mon Dec 10 12:18:53 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160AB21F8635 for ; Mon, 10 Dec 2012 12:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.202 X-Spam-Level: X-Spam-Status: No, score=-6.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSJYskkv0pLT for ; Mon, 10 Dec 2012 12:18:52 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id EF5F821F8634 for ; Mon, 10 Dec 2012 12:18:51 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-d6-50c643aa0def Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FF.A9.10459.AA346C05; Mon, 10 Dec 2012 21:18:51 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.001; Mon, 10 Dec 2012 21:18:50 +0100 From: Christer Holmberg To: "Olle E. Johansson" Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 Thread-Index: Ac3WvTkjByInUM1RTJSbqOOOIsdUsgANIWGa///xU4CAABEWH///87UAgAATDN////scAIAAPod5 Date: Mon, 10 Dec 2012 20:18:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B05254B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> <201212101615.qBAGFeha2750607@shell01.TheWorld.com>, <0A2DE818-32D6-4820-8D11-A14AB68B88C0@edvina.net> <7594FB04B1934943A5C02806D1A2204B05218F@ESESSMB209.ericsson.se>, <676582FB-92BD-4CB4-858E-C9D44ECB78C4@edvina.net> <7594FB04B1934943A5C02806D1A2204B05229B@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje5q52MBBm/6OSxerj7EbPH1xyY2 i6uTfzA5MHv8ff+ByWPa2pWsHkuW/GQKYI7isklJzcksSy3St0vgyrix+z1bwTSZii+LFrE3 MN4W62Lk5JAQMJFYsOA4M4QtJnHh3nq2LkYuDiGBQ4wSv772sEI4SxglJq2/zdLFyMHBJmAh 0f1PG6RBREBD4sKXK2wgNrNAsMSxNY9ZQGxhAS+J7X+msEHUeEvM2NrJDmFHSfx4uZ4VxGYR UJVY9+smWJwXqGZdzxt2iF2zmSWaH/wCS3AK2Ems3HMDzGYEuu77qTVMEMvEJW49mc8EcbWA xJI956E+EJV4+fgfK8idEgKKEsv75SDKdSQW7P4Edae2xLKFr5kh9gpKnJz5hGUCo9gsJFNn IWmZhaRlFpKWBYwsqxjZcxMzc9LLDTcxAuPm4JbfujsYT50TOcQozcGiJM7LlbTfX0ggPbEk NTs1tSC1KL6oNCe1+BAjEwenVANjs1bkgoqFQWXeTauTpz1vz7S59nxDYca66rKknZZCyS8i NPk+lt5hmPM+OvKLFOs5NbW/6QXGX6sPndF2/Gh352BCSfppg5cnTBk6X125UBDwtn1KavXR 3627Xgfy37J83+y9Lk999ZoFevWL9DaecjD9sPncqhP1VuFb1787+Fvx5SaGxF8ySizFGYmG WsxFxYkAwpWwdGkCAAA= Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 20:18:53 -0000 Hi, >>>>>>> We've submitted a new draft, >>>>>>> draft-holmberg-sipcore-received-realm-00.txt, which allows network >>>>>>> entry points to indicate the preceding network, from where a reques= t >>>>>>> is received. The information can be used inside the network, to >>>>>>> provide services, routing etc, based on the information. The >>>>>>> indication is conveyed as a new Via header field parameter, >>>>>>> "received-realm". >>>>>> >>>>>> It's an interesting question what this "realm" really is. Currently= , >>>>>> we have History-Info, and we have the Via "received" parameter. But >>>>>> it seems clear to me that the real intention is to identify "From >>>>>> which service provider's network was this request received?" And th= at >>>>>> information is not the same as knowing which particular host it was >>>>>> received from. >>>>>> >>>>>> The difficulty I see is that there is no standardizable way of >>>>>> designating this. Within any one network, there may be standard >>>>>> designators of origin networks, but globally there won't be. This i= s >>>>>> in contrast with History-Info and "received", which specify IP >>>>>> addresses or DNS names, which have global meanings (more or less). >>>>>> >>>>>> So it seems to me that all that can be standardized is the particula= r >>>>>> method for carrying this information and some of its syntax. It's >>>>>> really just a private extension to Via that never really needs to >>>>>> interwork between systems that aren't in one administrative domain. >>>>>> >>>>>> As written, the draft seems to gloss over this issue; it mentions a >>>>>> "network realm value" without mentioning that these values are not >>>>>> standardized. >>>>>> >>>>> >>>>> It also says "globally unique" - so why not just use a domain or host= name? >>>> >>>> That is actually the idea :) My appologies if we didn't make it clear. >>>> >>>> I am not sure whether the value actually has to be globally unique, as= long as it's unique within the network that uses the value. >>>> >>>>>> There are also some interesting security considerations if a host >>>>>> attaches a fraudulent "received-realm" to a request before forwardin= g >>>>>> it to another network... >>>>> >>>>> The security part was missing... Which is why I hinted at SIP identit= y. >>>>> Use a domain as a globally unique network identifier then sign it. >>>>> >>>>> If the goal is to use it for routing responses to the specific networ= k, >>>>> we should look into that issue, but I'm not clear on what the problem= to be solved is. >>>> >>>> That is not the goal. Responses are routed as defined in RFC 3261, and= this draft doesn't change that. >>> >>> So what is the problem you are trying to solve, Christer? >> >> To allow the entry point for network X to insert an indication from whic= h network the requests was received, so that other entities (e.g. Applicati= on Servers or routing functions) within network X can use the information t= o make service/routing decisions. Nothing more than that, really :) >> >> In transit networks, services and routing decissions are often applied b= ased on the preceding network (rather than users, as the transit network ty= pically does not have any user information). > > So what's the reason to insert it into the Via header? The benefit is tha= t you get it in the responses, which you claim you don't need. > > Why not a new header, like originating-domain or something else? Sure, it could also be done using a new header. Regards, Christer From oej@edvina.net Mon Dec 10 12:50:26 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95AC021F8689 for ; Mon, 10 Dec 2012 12:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7Wv4Z2xnVS9 for ; Mon, 10 Dec 2012 12:50:26 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 5612A21F8646 for ; Mon, 10 Dec 2012 12:50:24 -0800 (PST) Received: from [IPv6:2001:16d8:cc57:1000::42:1004] (unknown [IPv6:2001:16d8:cc57:1000::42:1004]) by smtp7.webway.se (Postfix) with ESMTPA id 90D13754A8AA; Mon, 10 Dec 2012 20:50:22 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <7594FB04B1934943A5C02806D1A2204B05254B@ESESSMB209.ericsson.se> Date: Mon, 10 Dec 2012 21:50:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <85C7D643-D1C1-4EF6-9FED-2616CCFBE221@edvina.net> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> <201212101615.qBAGFeha2750607@shell01.TheWorld.com>, <0A2DE818-32D6-4820-8D11-A14AB68B88C0@edvina.net> <7594FB04B1934943A5C02806D1A2204B05218F@ESESSMB209.ericsson.se>, <676582FB-92BD-4CB4-858E-C9D44ECB78C4@edvina.net> <7594FB04B1934943A5C02806D1A2204B05229B@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B05254B@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1499) Cc: "Dale R. Worley" , "sipcore@ietf.org" , "Olle E. Johansson" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 20:50:26 -0000 10 dec 2012 kl. 21:18 skrev Christer Holmberg = : >=20 > Hi, >=20 >>>>>>>> We've submitted a new draft, >>>>>>>> draft-holmberg-sipcore-received-realm-00.txt, which allows = network >>>>>>>> entry points to indicate the preceding network, from where a = request >>>>>>>> is received. The information can be used inside the network, to >>>>>>>> provide services, routing etc, based on the information. The >>>>>>>> indication is conveyed as a new Via header field parameter, >>>>>>>> "received-realm". >>>>>>>=20 >>>>>>> It's an interesting question what this "realm" really is. = Currently, >>>>>>> we have History-Info, and we have the Via "received" parameter. = But >>>>>>> it seems clear to me that the real intention is to identify = "From >>>>>>> which service provider's network was this request received?" = And that >>>>>>> information is not the same as knowing which particular host it = was >>>>>>> received from. >>>>>>>=20 >>>>>>> The difficulty I see is that there is no standardizable way of >>>>>>> designating this. Within any one network, there may be standard >>>>>>> designators of origin networks, but globally there won't be. = This is >>>>>>> in contrast with History-Info and "received", which specify IP >>>>>>> addresses or DNS names, which have global meanings (more or = less). >>>>>>>=20 >>>>>>> So it seems to me that all that can be standardized is the = particular >>>>>>> method for carrying this information and some of its syntax. = It's >>>>>>> really just a private extension to Via that never really needs = to >>>>>>> interwork between systems that aren't in one administrative = domain. >>>>>>>=20 >>>>>>> As written, the draft seems to gloss over this issue; it = mentions a >>>>>>> "network realm value" without mentioning that these values are = not >>>>>>> standardized. >>>>>>>=20 >>>>>>=20 >>>>>> It also says "globally unique" - so why not just use a domain or = host name? >>>>>=20 >>>>> That is actually the idea :) My appologies if we didn't make it = clear. >>>>>=20 >>>>> I am not sure whether the value actually has to be globally = unique, as long as it's unique within the network that uses the value. >>>>>=20 >>>>>>> There are also some interesting security considerations if a = host >>>>>>> attaches a fraudulent "received-realm" to a request before = forwarding >>>>>>> it to another network... >>>>>>=20 >>>>>> The security part was missing... Which is why I hinted at SIP = identity. >>>>>> Use a domain as a globally unique network identifier then sign = it. >>>>>>=20 >>>>>> If the goal is to use it for routing responses to the specific = network, >>>>>> we should look into that issue, but I'm not clear on what the = problem to be solved is. >>>>>=20 >>>>> That is not the goal. Responses are routed as defined in RFC 3261, = and this draft doesn't change that. >>>>=20 >>>> So what is the problem you are trying to solve, Christer? >>>=20 >>> To allow the entry point for network X to insert an indication from = which network the requests was received, so that other entities (e.g. = Application Servers or routing functions) within network X can use the = information to make service/routing decisions. Nothing more than that, = really :) >>>=20 >>> In transit networks, services and routing decissions are often = applied based on the preceding network (rather than users, as the = transit network typically does not have any user information). >>=20 >> So what's the reason to insert it into the Via header? The benefit is = that you get it in the responses, which you claim you don't need. >>=20 >> Why not a new header, like originating-domain or something else? >=20 > Sure, it could also be done using a new header. It that's the case, why make it complicated and add it to Via? Now, is the reason for this that most people and IP address and not = domain to via so that it's hard to get the information needed by = inspecting the via headers? I guess I need to read the docs on History-info to find out why you = can't use that. A lot of work has been done to create that solution. I = must have missed something important.=20 /O= From christer.holmberg@ericsson.com Tue Dec 11 00:01:02 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFEA21F8746 for ; Tue, 11 Dec 2012 00:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.203 X-Spam-Level: X-Spam-Status: No, score=-6.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuXyw2BUlT33 for ; Tue, 11 Dec 2012 00:01:02 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BBA9621F86FE for ; Tue, 11 Dec 2012 00:00:59 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-ab-50c6e839f371 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E8.74.24873.938E6C05; Tue, 11 Dec 2012 09:00:58 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0318.001; Tue, 11 Dec 2012 09:00:57 +0100 From: Christer Holmberg To: "Olle E. Johansson" Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 Thread-Index: Ac3WvTkjByInUM1RTJSbqOOOIsdUsgANIWGa///xU4CAABEWH///87UAgAATDN////scAIAAPod5///44oD//zZocA== Date: Tue, 11 Dec 2012 08:00:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B052841@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> <201212101615.qBAGFeha2750607@shell01.TheWorld.com>, <0A2DE818-32D6-4820-8D11-A14AB68B88C0@edvina.net> <7594FB04B1934943A5C02806D1A2204B05218F@ESESSMB209.ericsson.se>, <676582FB-92BD-4CB4-858E-C9D44ECB78C4@edvina.net> <7594FB04B1934943A5C02806D1A2204B05229B@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B05254B@ESESSMB209.ericsson.se> <85C7D643-D1C1-4EF6-9FED-2616CCFBE221@edvina.net> In-Reply-To: <85C7D643-D1C1-4EF6-9FED-2616CCFBE221@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvja7Vi2MBBge/MFm8XH2I2eLrj01s Flcn/2ByYPb4+/4Dk8e0tStZPZYs+ckUwBzFZZOSmpNZllqkb5fAlfHo+xuWgjf8FfsWrmBq YDzG08XIySEhYCKxe+ktdghbTOLCvfVsXYxcHEIChxglPvS0MEI4SxglrrYtBMpwcLAJWEh0 /9MGaRAR0JC48OUKG4jNLBAscWzNYxYQW1jAS2L7nylsEDXeEjO2drJD2FkSezoWgtksAqoS a+8dZgUZyQtUs+C/I8SqWSwSW/98AavhFLCT6P92CmwmI9Bx30+tYYLYJS5x68l8JoijBSSW 7DnPDGGLSrx8/A9spoSAosTyfjmIch2JBbs/QZ2pLbFs4Wuwcl4BQYmTM5+wTGAUm4Vk6iwk LbOQtMxC0rKAkWUVI3tuYmZOernRJkZg1Bzc8lt1B+OdcyKHGKU5WJTEea237vEXEkhPLEnN Tk0tSC2KLyrNSS0+xMjEwSnVwChyPtl525Pu1ScO7aw4/Ov64mX9jFxZ/g+sq55vfqeVy9F2 2XBedkRHiKmNIVvxki2+S/W+Ri691tuVILqofOKJB3vPy16RPGGxb0/35l13844qiEddy2lx cNG9XW4vJ501k7knKzws5eiryJeN7Oee3naZ4Hlon7vAzq+Lq0WXXPitccf1QYUSS3FGoqEW c1FxIgD0aq81aAIAAA== Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 08:01:02 -0000 Hi, ... >>>>> So what is the problem you are trying to solve, Christer? >>>>=20 >>>> To allow the entry point for network X to insert an indication from=20 >>>> which network the requests was received, so that other entities=20 >>>> (e.g. Application Servers or routing functions) within network X can=20 >>>> use the information to make service/routing decisions. Nothing more=20 >>>> than that, really :) >>>>=20 >>>> In transit networks, services and routing decissions are often applied= based on the preceding network (rather than users, as the transit network = typically does not have any user information). >>>=20 >>> So what's the reason to insert it into the Via header? The benefit is t= hat you get it in the responses, which you claim you don't need. >>>=20 >>> Why not a new header, like originating-domain or something else? >>=20 >> Sure, it could also be done using a new header. > > It that's the case, why make it complicated and add it to Via? Why do you think adding it to Via makes it complicated? However, I'm not religious regarding the solution. If the community thinks = a new header field is more suitable, then fine. > Now, is the reason for this that most people and IP address and not domai= n to via so that it's hard to get the information needed by inspecting the = via headers? No. The reason is simply that this is a small piece of information, that we= think fits into an existing header field. > I guess I need to read the docs on History-info to find out why you can't= use that. A lot of work has been done to create that solution. I must have= missed something important.=20 Please do - and I'd be more than happy to be proven wrong regarding the usa= ge of H-I :) But, again, my understanding of H-I is more about recording redirections/re= targets, so that receivers of the request will get that information. In my = opinion it's different semantics from what we're trying to do with this dra= ft. Regards, Christer From michael@voip.co.uk Tue Dec 11 03:25:07 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA3121F85E6 for ; Tue, 11 Dec 2012 03:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmxH9jAyV8XN for ; Tue, 11 Dec 2012 03:25:07 -0800 (PST) Received: from na3sys009aog135.obsmtp.com (na3sys009aog135.obsmtp.com [74.125.149.84]) by ietfa.amsl.com (Postfix) with SMTP id D7BAA21F84C9 for ; Tue, 11 Dec 2012 03:25:06 -0800 (PST) Received: from mail-vc0-f198.google.com ([209.85.220.198]) (using TLSv1) by na3sys009aob135.postini.com ([74.125.148.12]) with SMTP ID DSNKUMcYElyxX3zG215oDfTKEoj8vyJBp9z4@postini.com; Tue, 11 Dec 2012 03:25:06 PST Received: by mail-vc0-f198.google.com with SMTP id n11so7021739vch.1 for ; Tue, 11 Dec 2012 03:25:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=9ULGTD2Ks58/0j3ZHMi0lC/aQFejE4FCU291htt0woU=; b=Tjd54AvaRtHszKtIpEb/okTUSG4QJHXK1Q3gsBWQlWbSMlP9/tTgdMw5Oz5jAYp2/N cvp6nlJSUESsIqFxF9vvCwDtKU9SJad/XZMUKhPFv7d91Cvb2oBdQ3tpCUOc2kXt52uZ Wwep78prfFzs7Dp3sIEllHQjHpt7w4ZjOmIsT+XeaOdlnl3hmJIL9lKg//Ipf3UsWW0s FCLYePxlLjqzKUHFlIlduk9C08ZQdB6XV53WXl0hf6uJRir87d75eeI5ZnIrHcCseHlz oNXOEQjizD9uPy4YBuMnzF22VPoVE7oBoJcKAhWsKEFVNzpbtuO+a69z/PzSD6HzNiJ7 QQ4Q== Received: by 10.58.162.130 with SMTP id ya2mr11228870veb.2.1355225105877; Tue, 11 Dec 2012 03:25:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.162.130 with SMTP id ya2mr11228864veb.2.1355225105729; Tue, 11 Dec 2012 03:25:05 -0800 (PST) Received: by 10.58.250.132 with HTTP; Tue, 11 Dec 2012 03:25:05 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B052841@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> <201212101615.qBAGFeha2750607@shell01.TheWorld.com> <0A2DE818-32D6-4820-8D11-A14AB68B88C0@edvina.net> <7594FB04B1934943A5C02806D1A2204B05218F@ESESSMB209.ericsson.se> <676582FB-92BD-4CB4-858E-C9D44ECB78C4@edvina.net> <7594FB04B1934943A5C02806D1A2204B05229B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B05254B@ESESSMB209.ericsson.se> <85C7D643-D1C1-4EF6-9FED-2616CCFBE221@edvina.net> <7594FB04B1934943A5C02806D1A2204B052841@ESESSMB209.ericsson.se> Date: Tue, 11 Dec 2012 11:25:05 +0000 Message-ID: From: Michael Procter To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlbuaB2+UnLS/1GWhJbM4XuVuvxiA0H0EvckIczuw27Gkleq83hJqmLFMiWmgK5z11Nhhi4oC6Og+R+d0VeMAF0sz9zxwtgPgW75Th8pumU13Sf3ZjeE+PQrxUdN1RExr+Ww7Mf4RYZsrnOvWigZiI5iegV6g== Cc: "Dale R. Worley" , "sipcore@ietf.org" , "Olle E. Johansson" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 11:25:07 -0000 >> I guess I need to read the docs on History-info to find out why you can't use that. A lot of work has been done to create that solution. I must have missed something important. > > Please do - and I'd be more than happy to be proven wrong regarding the usage of H-I :) > > But, again, my understanding of H-I is more about recording redirections/retargets, so that receivers of the request will get that information. In my opinion it's different semantics from what we're trying to do with this draft. > I've reread the rfc4244bis draft this morning, and from my understanding of your requirements, using H-I seems like a good fit. Syntactically, we could define a new hi-extension to record the source information. Semantically, it seems to fit too. The introduction to rfc4244bis states it defines H-I: to provide a standard mechanism for capturing the request history information to enable a wide variety of services for networks and end-users. I don't want to encourage a jump to defining mechanism too early, but I think it might help explain your requirements if you discussed why H-I isn't suitable. Regards, Michael From michael@voip.co.uk Tue Dec 11 03:45:00 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6535821F869F for ; Tue, 11 Dec 2012 03:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9edNjoPOHIn for ; Tue, 11 Dec 2012 03:45:00 -0800 (PST) Received: from na3sys009aog130.obsmtp.com (na3sys009aog130.obsmtp.com [74.125.149.143]) by ietfa.amsl.com (Postfix) with SMTP id C298521F869B for ; Tue, 11 Dec 2012 03:44:59 -0800 (PST) Received: from mail-vc0-f198.google.com ([209.85.220.198]) (using TLSv1) by na3sys009aob130.postini.com ([74.125.148.12]) with SMTP ID DSNKUMccu3VlZdZ/k2YR/iksV+/ZTEGlAElL@postini.com; Tue, 11 Dec 2012 03:44:59 PST Received: by mail-vc0-f198.google.com with SMTP id n11so7052656vch.1 for ; Tue, 11 Dec 2012 03:44:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=rVBe8Y3BZ5vMP0iPPy7SXcUB18AmNlp1uDosG2Z5Q5w=; b=YY16MWaUXONHJyncDP/LsHpkKILzV0pYodEZ/85LFmQk+hwCPiR1mmJTt8PEkKnLKw 2quynMD3tj188rbJgO3IZuNBqJb97iyBtThd0wOwqabQPNNQGQA0dyUgHMddIJSX4cM8 VbgJnmrA70CuZK0q1zTzFoIffvnLOytMwRN2mduoxQne+lBitokrUEb5DoFXExbuBbrl jMMAYDIL0vvmBu+S9FmtoeyuTUEWWgvrxRp1ifRaQDpHSyad5wCnlozBq1eCed5wwZj9 4XYL0V/YcDPB8EiG2J4mT/jZ1nJHY1RaHCCiIzepMOKIqPXQGQpvrzld44h75sCXd0O9 fUqw== Received: by 10.52.155.205 with SMTP id vy13mr5046732vdb.119.1355226298381; Tue, 11 Dec 2012 03:44:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.155.205 with SMTP id vy13mr5046730vdb.119.1355226298290; Tue, 11 Dec 2012 03:44:58 -0800 (PST) Received: by 10.58.250.132 with HTTP; Tue, 11 Dec 2012 03:44:58 -0800 (PST) Date: Tue, 11 Dec 2012 11:44:58 +0000 Message-ID: From: Michael Procter To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmtTinJN6YS+VfC3QXOsAdDm+h5kqJVYnmbXJGKAjrf8aTUaRnTxYTTfWzEuScB/onS/uh5cVROEy2scNcF2QWs7S80ZmlVk41ojt7roe4Ub/lMHbSXp54UahdQwh22O59xs3Tz04/6rGLid63RkNfzLQuyMQ== Subject: [sipcore] Typo in 4244bis-callflows? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 11:45:00 -0000 Section 3.1, F9: History-Info: ;\ index=1.2.1>;index=1.2.1;rc=1.2 I've just spent a while trying to work out the significance of the index parameter being both a uri parameter and a header parameter before realising that there is a typo here! I think it should actually read: History-Info: ;\ index=1.2.1;rc=1.2 The same error is repeated in F11 and F12 Regards, Michael From worley@shell01.TheWorld.com Tue Dec 11 07:24:04 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4187221F8816 for ; Tue, 11 Dec 2012 07:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.753 X-Spam-Level: X-Spam-Status: No, score=-2.753 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brM3xlan7Rc6 for ; Tue, 11 Dec 2012 07:24:03 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB7A21F8690 for ; Tue, 11 Dec 2012 07:24:03 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qBBFNcDq013390 for ; Tue, 11 Dec 2012 10:23:41 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id qBBFNcwV2808101 for ; Tue, 11 Dec 2012 10:23:38 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qBBFNZ9i2806348; Tue, 11 Dec 2012 10:23:35 -0500 (EST) Date: Tue, 11 Dec 2012 10:23:35 -0500 (EST) Message-Id: <201212111523.qBBFNZ9i2806348@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: <7594FB04B1934943A5C02806D1A2204B052841@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> <201212101615.qBAGFeha2750607@shell01.TheWorld.com>, <0A2DE818-32D6-4820-8D11-A14AB68B88C0@edvina.net> <7594FB04B1934943A5C02806D1A2204B05218F@ESESSMB209.ericsson.se>, <676582FB-92BD-4CB4-858E-C9D44ECB78C4@edvina.net> <7594FB04B1934943A5C02806D1A2204B05229B@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B05254B@ESESSMB209.ericsson.se> <85C7D643-D1C1-4EF6-9FED-2616CCFBE221@edvina.net> <7594FB04B1934943A5C02806D1A2204B052841@ESESSMB209.ericsson.se> Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 15:24:04 -0000 The question that I do not see an answer for is "Why does this need to be standardized?" By the nature of the problem it addresses, the production and consumption of this indicator will always be within the same, centrally-administered network. The administrator of each such network can choose their own way to indicate the call source. It may be advantageous regarding equipment acquisition to have every vendor's equipment do it the same way, but that is a 3GPP issue, not an *Internet* issue. Dale From pkyzivat@alum.mit.edu Tue Dec 11 09:46:10 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C56821F8889 for ; Tue, 11 Dec 2012 09:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lH2YIxer8S3Q for ; Tue, 11 Dec 2012 09:46:09 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 9624721F8888 for ; Tue, 11 Dec 2012 09:46:09 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta03.westchester.pa.mail.comcast.net with comcast id aAd11k0041GhbT853Hm8xy; Tue, 11 Dec 2012 17:46:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id aHm81k00v3ZTu2S3THm845; Tue, 11 Dec 2012 17:46:08 +0000 Message-ID: <50C7715F.30500@alum.mit.edu> Date: Tue, 11 Dec 2012 12:46:07 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se>, <50C618D7.4040201@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B05252C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B05252C@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355247968; bh=ub3F4wHtQ85Te+NHaqCw2Gd6/FdzKMR3Dp9Tb0d0/84=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eUOre94gDgISgzWVxdGij06Gc7UTc0LE48g/SzdA+Xh877Kvyg2GBJJQR0mgNZofQ KuALWUU/i4xgXRFBZ+/2fwlABycG9ARewh1pHDEIGwnz8sMMSZgRD1JCUyoPaMMcA5 wmblqVQc7tarTc4pLtfjYFO3HQ3lFnjWnz/EsKqDkJ3FPQz04zKXcQeuwFyxXMJSY4 DS+RarqgnB1UTLbxTzOTibulfM8FUqhjeyPstatAoOJXBvS6dst2YqD5znkyS6t0R4 zi9O5N3kDpBNZFLZOEIX2DLLXdqhOC8zME5aTbWI3eMmiPJ0jVXomikPFoZLMGtQOu +5PHCp0ovKCpA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 17:46:10 -0000 On 12/10/12 3:15 PM, Christer Holmberg wrote: > > Hi Paul, > >> [as sipcore co-chair] >> >> While a little discussion on this list won't hurt, IMO it is premature >> to assume that this will be sipcore work. (In fact, the proposed >> mechanism falls outside the scope of sipcore.) > > I believe Via header parameters are within the scope of sipcore. I checked the charter before saying that: The SIPCore working group will concentrate on specifications that update or replace the core SIP specifications. In this context, "update" means replacing or modifying protocol elements in the above listed RFCs in ways that would affect most or all implementations of those RFCs alone. Extensions to SIP that add new functionality that would not be required of all implementations will be done outside of this WG. The process and requirements for such extensions are documented in RFC 5727, "Change Process for the Session Initiation Protocol". As I read things, even adding a parameter to the Via header can be done via a non-standards-track RFC. > (For example, we did the keep parameter in sipcore.) Keep (arguably) affected a lot of implementations. I think it was still a gray area. I also think that some of these things can benefit from being discussed in SIPCORE because that is where the appropriate expertise is. >> It strikes me that this subject might be of interest to people who don't follow sipcore closely. >> (If there are any interested in RAI that don't follow sipcore closely.) >> For instance, the people who care about DRINKS and the now closed SPEERMINT. >> >> Also, as often happens, this draft starts with the solution before there >> has been discussion and refinement of the problem. >> >> So, I think this might be more appropriately discussed in DISPATCH, but >> I'll listen to arguments to the contrary. > > In general, I agree with you, and we were thinking about taking it to DISPATCH. > > However, as this is only about an indicator, in typical cases inserted and consumed within a network, and it can be done using an existing header field, we thought that it could be taken directly to SIPCORE. > > But, community decides :) SIPCORE hasn't been busy lately. So I don't want to send you away to avoid the work in sipcore. :-) My main point is to get requirements addressed before focus on the solution. It is the chosen solution that brought you to sipcore. And I think dispatch is a better place to start discussion of the requirements. Some of the comments already raised are at that level. I've been glad to see them - they are similar to ones that I was going to raise. For the time being, since some discussion has already begun, (and because the participation in dispatch and sipcore is largely the same), I'm ok with having the discussion continue here. I would like to hear more about: - what a "realm" is, - who names them, - what the namespace is for them, - what happens when transiting multiple realms, - relationship to Trust Domains (RFC 3324) Thanks, Paul From christer.holmberg@ericsson.com Wed Dec 12 01:38:39 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6DC21F897C for ; Wed, 12 Dec 2012 01:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Xdu8yoEcmFx for ; Wed, 12 Dec 2012 01:38:38 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D98A121F895A for ; Wed, 12 Dec 2012 01:38:37 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-bc-50c8509ceae4 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 9E.66.24873.C9058C05; Wed, 12 Dec 2012 10:38:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0318.001; Wed, 12 Dec 2012 10:38:36 +0100 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 Thread-Index: Ac3WvTkjByInUM1RTJSbqOOOIsdUsgANG+aAAAgkdVkAKzJegAAewx4w Date: Wed, 12 Dec 2012 09:38:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B053C6D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se>, <50C618D7.4040201@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B05252C@ESESSMB209.ericsson.se> <50C7715F.30500@alum.mit.edu> In-Reply-To: <50C7715F.30500@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvje7cgBMBBvtmMVus2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG+9vT2Qve8VdsfXqAsYFxL08XIyeHhICJ xNu/vUwQtpjEhXvr2boYuTiEBA4xSmz7NgPKWcIo8fb/GcYuRg4ONgELie5/2iCmiICGxKSt aiC9zAKaEo927gWbIyzgJbH9zxQ2EFtEwFtixtZOdgjbTaJnahMrSCuLgKpE+9dikDAvUMnX Zy/ASoQEzjJKzOgTBbE5BbQkOn/dYQaxGYFO+35qDRPEKnGJW0/mQ50sILFkz3lmCFtU4uXj f2DjJQQUJZb3y0GU60gs2P2JDcLWlli28DUzxFpBiZMzn7BMYBSbhWTqLCQts5C0zELSsoCR ZRUje25iZk56udEmRmB0HNzyW3UH451zIocYpTlYlMR5rbfu8RcSSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXAKLgr1jdkb/1RAeNFTSyFwWwiej4Bm5dUG1zi+pR/5rd3xC+76N/MHw9djJco vV8RVnLD7V+wR7LE7XWtniyBslxtLAH2/w9sFnLi/ah7ckuiSIGPpWTtURnPD9+jspfJL9j8 7Nuzr5xXPsneXXDu/mHmuUeiHpZp/og+fD160tyWyefyUznzlViKMxINtZiLihMBAvubxlwC AAA= Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 09:38:39 -0000 Hi, > My main point is to get requirements addressed before focus on the soluti= on. It is the chosen solution that=20 > brought you to sipcore. And I think dispatch is a better place to start d= iscussion of the requirements. Some of the comments already raised are at t= hat level.=20 > I've been glad to see them - they are similar to ones that I was going to= raise. > > For the time being, since some discussion has already begun, (and because= the participation in dispatch and sipcore is largely the same), I'm ok wit= h having the discussion continue here. > > I would like to hear more about: > - what a "realm" is, Bad wording :) It should really be an indicator identifying the preceding n= etwork. > - who names them, The network operators that insert and consume them. > - what the namespace is for them, Within the network operator that inserts and consumes them. For example, if you represent my preceding network, I can identity it as pa= uls.network.com. But, from a protocol perspective there is no need for you = to know that I am using that value. (Of course, for administrative purposes, it may be a good thing if you and = I agree on the values as part of our agreement.) > - what happens when transiting multiple realms, The requirement is to be able to identify the preceding network. There is n= o requirement to identity "5 networks down the path", eventhough such infor= mation might be present (depending on what information element is used to c= arry the information). > - relationship to Trust Domains (RFC 3324) If e.g. a transit network is going to provide service(s) to the preceding n= etwork, there obviously need to be some agreement and trust between them. A= nd, the entry point needs to be able to verify from where a request comes. But, as far as the indicator itself is concerned, as it is meant to be inse= rted and consumed within the same network, I see no relationship with Trust= Domains. Regards, Christer From christer.holmberg@ericsson.com Wed Dec 12 01:57:19 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08B321F898B for ; Wed, 12 Dec 2012 01:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrDVRlU5am7h for ; Wed, 12 Dec 2012 01:57:18 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE0421F8975 for ; Wed, 12 Dec 2012 01:57:18 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-07-50c854fd7345 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 83.A4.10459.DF458C05; Wed, 12 Dec 2012 10:57:17 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0318.001; Wed, 12 Dec 2012 10:57:16 +0100 From: Christer Holmberg To: Michael Procter Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 Thread-Index: Ac3WvTkjByInUM1RTJSbqOOOIsdUsgANIWGa///xU4CAABEWH///87UAgAATDN////scAIAAPod5///44oD//zZocP/+QgGA//smpwA= Date: Wed, 12 Dec 2012 09:57:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B053CB3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> <201212101615.qBAGFeha2750607@shell01.TheWorld.com> <0A2DE818-32D6-4820-8D11-A14AB68B88C0@edvina.net> <7594FB04B1934943A5C02806D1A2204B05218F@ESESSMB209.ericsson.se> <676582FB-92BD-4CB4-858E-C9D44ECB78C4@edvina.net> <7594FB04B1934943A5C02806D1A2204B05229B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B05254B@ESESSMB209.ericsson.se> <85C7D643-D1C1-4EF6-9FED-2616CCFBE221@edvina.net> <7594FB04B1934943A5C02806D1A2204B052841@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvje7fkBMBBlP2yFo0bu9nsXi5+hCz xdcfm9gsrk7+weTA4vH3/Qcmj2lrV7J6LFnyk8nj3o8jbAEsUVw2Kak5mWWpRfp2CVwZ++98 YCt4xVMxf/k7tgbGaVxdjJwcEgImEnMvzGaCsMUkLtxbz9bFyMUhJHCIUWLF1IfMEM4SRol7 m9eydjFycLAJWEh0/9MGaRAR0JDo2zuXDcRmFqiU+NN3ihXEFhbwktj+ZwobRI23xIytnewg rSICZRI97ZwgYRYBVYkj/zexgNi8QCWH7s4Bu0FIYAGrRMMLC5ByToFAibvdciBhRqDTvp9a wwSxSVzi1pP5UCcLSCzZc54ZwhaVePn4H9iREgKKEsv75SDKdSQW7P4EdaS2xLKFr5khtgpK nJz5hGUCo9gsJFNnIWmZhaRlFpKWBYwsqxjZcxMzc9LLDTcxAqPo4JbfujsYT50TOcQozcGi JM7LlbTfX0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjF9uuq7npfYKOQgInft8SnFZzmMXt pNYZnVnnTpxTPlryoP6Q9zxVu9rc9pPdBWHsZhs/3xK5ZJjz3/dJbITb4xcZD8JZjn6LsXXj OsgVL5B6mOFHjFWHQj377I97Dtf0yMuuTNva37tg7pGv2fvn3mazNX/BOVvA7ZhQzzfV9952 c50yn0kqsRRnJBpqMRcVJwIAb6gU9nACAAA= Cc: "Dale R. Worley" , "sipcore@ietf.org" , "Olle E. Johansson" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 09:57:19 -0000 Hi, >>> I guess I need to read the docs on History-info to find out why you can= 't use that. A lot of work has been done to create that solution. I must ha= ve missed something important. >> >> Please do - and I'd be more than happy to be proven wrong regarding=20 >> the usage of H-I :) >> >> But, again, my understanding of H-I is more about recording redirections= /retargets, so that receivers of the request will get that information. In = my opinion it's different semantics from what we're trying to do with this = draft. >> > > I've reread the rfc4244bis draft this morning, and from my understanding = of your requirements, using H-I seems like a good fit. > Syntactically, we could define a new hi-extension to record the source in= formation. Semantically, it seems to fit too. The introduction to rfc4244b= is states it defines H-I: > > to provide a > standard mechanism for capturing the request history information to > enable a wide variety of services for networks and end-users. > > I don't want to encourage a jump to defining mechanism too early, but I t= hink it might help explain your requirements if you discussed why H-I isn't= suitable. Well, my understanding is still that the semantics are different. History-Info is about recording things that may change in a request, e.g. t= he target, so that a receiver later can track the history of the request. The network entry point doesn't change anything in the request. So, there i= s no need to insert hi-targeted-to-uri, and the hi-index would not represen= t a request forward or retarget. Regards, Christer From christer.holmberg@ericsson.com Wed Dec 12 02:00:47 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F4A21F8992 for ; Wed, 12 Dec 2012 02:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z489kldaNKv2 for ; Wed, 12 Dec 2012 02:00:47 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5227C21F8990 for ; Wed, 12 Dec 2012 02:00:42 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-e3-50c855c91b7c Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id BA.9A.24873.9C558C05; Wed, 12 Dec 2012 11:00:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0318.001; Wed, 12 Dec 2012 11:00:40 +0100 From: Christer Holmberg To: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 Thread-Index: AQHN17N8ByInUM1RTJSbqOOOIsdUspgUvkCA Date: Wed, 12 Dec 2012 10:00:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B053CCE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> <201212101615.qBAGFeha2750607@shell01.TheWorld.com>, <0A2DE818-32D6-4820-8D11-A14AB68B88C0@edvina.net> <7594FB04B1934943A5C02806D1A2204B05218F@ESESSMB209.ericsson.se>, <676582FB-92BD-4CB4-858E-C9D44ECB78C4@edvina.net> <7594FB04B1934943A5C02806D1A2204B05229B@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B05254B@ESESSMB209.ericsson.se> <85C7D643-D1C1-4EF6-9FED-2616CCFBE221@edvina.net> <7594FB04B1934943A5C02806D1A2204B052841@ESESSMB209.ericsson.se> <201212111523.qBBFNZ9i2806348@shell01.TheWorld.com> In-Reply-To: <201212111523.qBBFNZ9i2806348@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvje7J0BMBBjMnSll8/bGJzeLliTIH Jo/J+78yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK+PApSamgu1sFf3djawNjF2sXYycHBICJhL9 b3czQthiEhfurWfrYuTiEBI4xCjxvfUAlLOEUWLCzgdAHRwcbAIWEt3/tEEaRASCJDZ1rmAG sYUFvCS2/5nCBhH3lpixtZMdwjaS2HR4CTNIK4uAqsTuTgWQMC9Qyb8PIBNBxk9ilfh8fCbY EZwCDhJvTu4GO44R6KDvp9YwgdjMAuISt57MZ4I4VEBiyZ7zzBC2qMTLx//ATpMQUJRY3i8H Ua4jsWD3JzYIW1ti2cLXzBB7BSVOznzCMoFRdBaSqbOQtMxC0jILScsCRpZVjOy5iZk56eVG mxiBcXBwy2/VHYx3zokcYpTmYFES57XeusdfSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6PG 9oVt/2JslJXl9A5y2fZdPmq+R/FpU3bp3o2lfdkW/juDpe7dzlorULr1SaLiu2nP1V31Nlbe 0l6f6PnmxOrHFqZS9b/dX6x/LDMh0OMB112jBeVGb0JbV05RZP+9+4ncy2eTN4qUSOvFOBq6 9bDs09zWsGPl+Qv68SUly9N9MtZOMaqbm67EUpyRaKjFXFScCAB5RqkNUQIAAA== Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 10:00:47 -0000 Hi, > The question that I do not see an answer for is "Why does this need to be= standardized?" By the nature of the problem it addresses, the production= =20 > and consumption of this indicator will always be within the same, central= ly-administered network. The administrator of each such network can=20 > choose their own way to indicate the call source. It may be advantageous= regarding equipment acquisition to have every vendor's equipment do=20 > it the same way, but that is a 3GPP issue, not an *Internet* issue. There may be a need for networks outside 3GPP to use a mechanism like this. And, eventhough only used within a network, as you said there may be boxes = of different vendors etc in that network, why it is useful to have a standa= rdized mechanism. Regards, Christer From worley@shell01.TheWorld.com Wed Dec 12 07:35:46 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3073021F8445 for ; Wed, 12 Dec 2012 07:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7JpjmRtUFA6 for ; Wed, 12 Dec 2012 07:35:45 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id A356521F8442 for ; Wed, 12 Dec 2012 07:35:44 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qBCFYr23023696; Wed, 12 Dec 2012 10:34:55 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id qBCFYqB82881444; Wed, 12 Dec 2012 10:34:52 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qBCFYlGt2873014; Wed, 12 Dec 2012 10:34:47 -0500 (EST) Date: Wed, 12 Dec 2012 10:34:47 -0500 (EST) Message-Id: <201212121534.qBCFYlGt2873014@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B053CCE@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> <201212101615.qBAGFeha2750607@shell01.TheWorld.com>, <0A2DE818-32D6-4820-8D11-A14AB68B88C0@edvina.net> <7594FB04B1934943A5C02806D1A2204B05218F@ESESSMB209.ericsson.se>, <676582FB-92BD-4CB4-858E-C9D44ECB78C4@edvina.net> <7594FB04B1934943A5C02806D1A2204B05229B@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B05254B@ESESSMB209.ericsson.se> <85C7D643-D1C1-4EF6-9FED-2616CCFBE221@edvina.net> <7594FB04B1934943A5C02806D1A2204B052841@ESESSMB209.ericsson.se> <201212111523.qBBFNZ9i2806348@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B053CCE@ESESSMB209.ericsson.se> Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 15:35:46 -0000 > From: Christer Holmberg > > There may be a need for networks outside 3GPP to use a mechanism like this. > > And, eventhough only used within a network, as you said there may be > boxes of different vendors etc in that network, why it is useful to > have a standardized mechanism. In that regard, I think you want to express the concept of the draft differently. In a sense, you aren't *standardizing* a syntax and semantics for a particular parameter, you're *reserving* a particular parameter name (against future standardization) so that networks (and their suppliers) can consistently use that parameter name for a private purpose. Based on that concept of what the draft is doing, you want to change the ABNF from: via-params =/ received-realm received-realm = "received-realm" EQUAL hostname to: received-realm = "received-realm" EQUAL gen-value That way, private users of "received-realm" aren't constrained in the syntax that they might choose to use. Dale From christer.holmberg@ericsson.com Wed Dec 12 07:47:43 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6242921F841B for ; Wed, 12 Dec 2012 07:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndogw2OW2U2V for ; Wed, 12 Dec 2012 07:47:42 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4B90421F8200 for ; Wed, 12 Dec 2012 07:47:41 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-34-50c8a71cfe79 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 20.33.24873.C17A8C05; Wed, 12 Dec 2012 16:47:40 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0318.001; Wed, 12 Dec 2012 16:47:40 +0100 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 Thread-Index: AQHN17N8ByInUM1RTJSbqOOOIsdUspgUvkCAgACPYkSAAAJtMw== Date: Wed, 12 Dec 2012 15:47:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B054171@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> <201212101615.qBAGFeha2750607@shell01.TheWorld.com>, <0A2DE818-32D6-4820-8D11-A14AB68B88C0@edvina.net> <7594FB04B1934943A5C02806D1A2204B05218F@ESESSMB209.ericsson.se>, <676582FB-92BD-4CB4-858E-C9D44ECB78C4@edvina.net> <7594FB04B1934943A5C02806D1A2204B05229B@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B05254B@ESESSMB209.ericsson.se> <85C7D643-D1C1-4EF6-9FED-2616CCFBE221@edvina.net> <7594FB04B1934943A5C02806D1A2204B052841@ESESSMB209.ericsson.se> <201212111523.qBBFNZ9i2806348@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B053CCE@ESESSMB209.ericsson.se>, <201212121534.qBCFYlGt2873014@shell01.TheWorld.com> In-Reply-To: <201212121534.qBCFYlGt2873014@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvja7M8hMBBlsb9S2+/tjEZvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlXFq336mguccFRNXHGNrYPzB1sXIwSEhYCJx 7RRfFyMnkCkmceHeeqAwF4eQwCFGiS/r9zFDOEsYJd7t72cCaWATsJDo/qcNYooIaEp0LMgB 6WUGMh/t3MsEYgsLeEls/zOFDcQWEfCWmLG1kx3CdpK4snsKmM0ioCqx9NgqMJsXqKb37n0m iFUdbBJt676wgsznFHCQ+PZNH6SGEei276fWMEHsEpe49WQ+E8TNAhJL9pxnhrBFJV4+/scK YStKfHy1jxGiXkdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPYLCRjZyFpmYWkZRaSlgWMLKsY 2XMTM3PSy402MQKj4+CW36o7GO+cEznEKM3BoiTOa711j7+QQHpiSWp2ampBalF8UWlOavEh RiYOTqkGRu/Dq6fM++bva3ZDxDA5ZI7k0T+SSldP2PubRK9kSypu0b572D3w8dRfK1/tUX1w eteZuB7WXv+53vXLv0/4fttRj/XuqcVfJ7H8ff7vJPf+TfrqBz/Kad2zSVI3zZvVzvrO8Uuo h+UC1ZztYR/lE7Tmnp35zuyQ5Nq4LYYx8xsbTqedeqdzdIMSS3FGoqEWc1FxIgAvhj0pXAIA AA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 15:47:43 -0000 Hi, >> There may be a need for networks outside 3GPP to use a mechanism like th= is. >> >> And, eventhough only used within a network, as you said there may be >> boxes of different vendors etc in that network, why it is useful to >> have a standardized mechanism. > > In that regard, I think you want to express the concept of the draft > differently. In a sense, you aren't *standardizing* a syntax and > semantics for a particular parameter, you're *reserving* a particular > parameter name (against future standardization) so that networks (and > their suppliers) can consistently use that parameter name for a > private purpose. > > Based on that concept of what the draft is doing, you want to change > the ABNF from: > > via-params =3D/ received-realm > > received-realm =3D "received-realm" EQUAL hostname > > to: > > received-realm =3D "received-realm" EQUAL gen-value > > That way, private users of "received-realm" aren't constrained in the > syntax that they might choose to use. I see no harm in having a syntax, but I don't have strong opinion... Regards, Christer From pkyzivat@alum.mit.edu Wed Dec 12 08:55:21 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C605821E80E4 for ; Wed, 12 Dec 2012 08:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7jjiqLkr3WL for ; Wed, 12 Dec 2012 08:55:12 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD4B21E8084 for ; Wed, 12 Dec 2012 08:55:06 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta14.westchester.pa.mail.comcast.net with comcast id ad4n1k0040vyq2s5Egv4Kb; Wed, 12 Dec 2012 16:55:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id agv41k00S3ZTu2S3Rgv46p; Wed, 12 Dec 2012 16:55:04 +0000 Message-ID: <50C8B6E8.5060803@alum.mit.edu> Date: Wed, 12 Dec 2012 11:55:04 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se>, <50C618D7.4040201@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B05252C@ESESSMB209.ericsson.se> <50C7715F.30500@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B053C6D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B053C6D@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355331304; bh=Xje5Jigwe1nl6hNrPkkSFzgab4qgZvuNIQUPJE936d4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ayTvhbSdymj5jE8njPO+w4rgsdXCnREFIs8irt34CuAhmuc3wEM0GHS6rs1g5Xy1o bZjrLmkNk5p/9rClQRdaW4vwQBC0XKvYUrxDSKDreFgKPBG/LwfEXenv0Xog+7sx2P eTE6hxb8B0GyLKxi90HH2CHumgd2ic27flrC/HJx/y67kIam+7+/XILEVia/UDO8eh HEsrsqjxwMuyO2C6ReiSDDGuBiLVwmLjUrrAxXIylyKNVZU+gSg6kAJ4qhLrKu9YT1 tY/O35T6oDGcmsPkBhlZp0vekkreSzb8gay+EArNZTWK2wY+TCI+/bRO57Bxre5dqa KToChcrowALvw== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 16:55:22 -0000 On 12/12/12 4:38 AM, Christer Holmberg wrote: > Hi, > >> My main point is to get requirements addressed before focus on the solution. It is the chosen solution that >> brought you to sipcore. And I think dispatch is a better place to start discussion of the requirements. Some of the comments already raised are at that level. >> I've been glad to see them - they are similar to ones that I was going to raise. >> >> For the time being, since some discussion has already begun, (and because the participation in dispatch and sipcore is largely the same), I'm ok with having the discussion continue here. >> >> I would like to hear more about: >> - what a "realm" is, > > Bad wording :) It should really be an indicator identifying the preceding network. I don't care about the word "realm". My question is about the concept of a "network" that has a name. Is every node (or perhaps network interface) part of such a network? Can a node (ore network interface) be simultaneously part of more than one network, or have more than one network name? >> - who names them, > > The network operators that insert and consume them. So the recipient of messages assigns the names based on information available to it? >> - what the namespace is for them, > > Within the network operator that inserts and consumes them. > > For example, if you represent my preceding network, I can identity it as pauls.network.com. But, from a protocol perspective there is no need for you to know that I am using that value. The syntax in the draft says . But are these actual registered DNS names? Or are these simply arbitrary identifiers that follow the syntax of hostnames? What is the mechanism for assigning these so that all the nodes that are assigning and interpreting these do so in a consistent way? > (Of course, for administrative purposes, it may be a good thing if you and I agree on the values as part of our agreement.) > >> - what happens when transiting multiple realms, > > The requirement is to be able to identify the preceding network. There is no requirement to identity "5 networks down the path", eventhough such information might be present (depending on what information element is used to carry the information). It would be good to be clear about that. >> - relationship to Trust Domains (RFC 3324) > > If e.g. a transit network is going to provide service(s) to the preceding network, there obviously need to be some agreement and trust between them. And, the entry point needs to be able to verify from where a request comes. > > But, as far as the indicator itself is concerned, as it is meant to be inserted and consumed within the same network, I see no relationship with Trust Domains. Superficially there seems to be some similarity between this and the process of inserting and removing asserted identities at trust boundaries. ISTM there should be some thought into whether this is coincidental or is significant. I guess you are assuming that the identifier is preserved from a request to a response, even if the request traverses several transit networks? And even if there is limited trust between those networks? (Use of Via implies this. This might be necessary in case a network needs to apply some services to a response.) Thanks, Paul From christer.holmberg@ericsson.com Wed Dec 12 12:05:07 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFC211E80D7 for ; Wed, 12 Dec 2012 12:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOIE69Ry4qER for ; Wed, 12 Dec 2012 12:05:04 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 76C0F11E80BF for ; Wed, 12 Dec 2012 12:05:03 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-16-50c8e36d4801 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 15.25.10459.D63E8C05; Wed, 12 Dec 2012 21:05:01 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0318.001; Wed, 12 Dec 2012 21:05:00 +0100 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 Thread-Index: Ac3WvTkjByInUM1RTJSbqOOOIsdUsgANG+aAAAgkdVkAKzJegAAewx4wABG/EAAAB8vRaQ== Date: Wed, 12 Dec 2012 20:05:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B054375@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se>, <50C618D7.4040201@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B05252C@ESESSMB209.ericsson.se> <50C7715F.30500@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B053C6D@ESESSMB209.ericsson.se>, <50C8B6E8.5060803@alum.mit.edu> In-Reply-To: <50C8B6E8.5060803@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+JvjW7u4xMBBmdvS1is2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGry8djAUrNSrmPDzE2MDYqtDFyMkhIWAi cezfdUYIW0ziwr31bF2MXBxCAocYJS69eckE4SxhlPj7fxpQhoODTcBCovufNogpIqAhMWmr Gkgvs4CmxKOde5lAbGEBL4ntf6awgdgiAt4SM7Z2skPYYRKXz/8Fq2ERUJXYd3U3mM0LVLPm UBM7xKr1TBIrz8xjBJnPKaAjsfwrD0gNI9Bt30+tYYLYJS5x68l8JoibBSSW7DnPDGGLSrx8 /I8VwlaU+PhqHyNEvY7Egt2f2CBsbYllC18zQ+wVlDg58wnLBEaxWUjGzkLSMgtJyywkLQsY WVYxsucmZuaklxtuYgRGyMEtv3V3MJ46J3KIUZqDRUmclytpv7+QQHpiSWp2ampBalF8UWlO avEhRiYOTqkGRuvzDfNNbj1POn3ho8fs3V1CCQ5i8lfS/WydgoS1NYTv+G07rHlg22WeF1Mn 7iye2jfBKd/VTnPPpvP/L98+luKmN2HulKtspToKcq5qjpbuoUX7NZv98tcYpulNOHDqSdl0 M7dX39WKnfJuie+ar8zdJpc/o1fR+ftEHd+3pq8TWNb4WwhOUWIpzkg01GIuKk4EABm0ezFe AgAA Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 20:05:07 -0000 Hi, >>> My main point is to get requirements addressed before focus on the solu= tion. It is the chosen solution that >>> brought you to sipcore. And I think dispatch is a better place to start= discussion of the requirements. Some of the comments already raised are at= that level. >>> I've been glad to see them - they are similar to ones that I was going = to raise. >>> >>> For the time being, since some discussion has already begun, (and becau= se the participation in dispatch and sipcore is largely the same), I'm ok w= ith having the discussion continue here. >>> >>> I would like to hear more about: >>> - what a "realm" is, >> >> Bad wording :) It should really be an indicator identifying the precedin= g network. > > I don't care about the word "realm". My question is about the concept of > a "network" that has a name. It's simply an identifier. > Is every node (or perhaps network interface) part of such a network? Can > a node (ore network interface) be simultaneously part of more than one > network, or have more than one network name? HOW the entry point identifies the preceding network is outside the scope. = It's something that the network operators have to define, and agree upon as= part of their interconnect/transit agreement. >>> - who names them, >> >> The network operators that insert and consume them. > > So the recipient of messages assigns the names based on information avail= able to it? Correct. >>> - what the namespace is for them, >> >> Within the network operator that inserts and consumes them. >> >> For example, if you represent my preceding network, I can identity it as= pauls.network.com. But, from a protocol perspective there is no need for y= ou to know that I am using that value. > > The syntax in the draft says . But are these actual registered > DNS names? Or are these simply arbitrary identifiers that follow the > syntax of hostnames? They don't have to be actual registered DNS names, but from my understandin= g when talking to people that would often be the case. That's also the reas= on is used in the syntax. But, as commented by Dale, the identifier doesn't have to be a hostname - i= t can be whatever value. So, if people don't like using , we can = use e.g. . > What is the mechanism for assigning these so that all the nodes that are = assigning and interpreting these do so in a consistent way? As the entities that insert (the network entry point) and consume (e.g. an = application server) the values are part of the same network, the network op= erator assigns the values, and configures the affected nodes to use the cor= rect values. >> (Of course, for administrative purposes, it may be a good thing if you a= nd I agree on the values as part of our agreement.) >> >>> - what happens when transiting multiple realms, >> >> The requirement is to be able to identify the preceding network. There i= s no requirement to identity "5 networks down the path", eventhough such in= formation might be present (depending on what information element is used t= o carry the information). > > It would be good to be clear about that. I agree that it can be more clear. Good point. >>> - relationship to Trust Domains (RFC 3324) >> >> If e.g. a transit network is going to provide service(s) to the precedin= g network, there obviously need to be some agreement and trust between them= . And, the entry point needs to be able to verify from where a request come= s. >> >> But, as far as the indicator itself is concerned, as it is meant to be i= nserted and consumed within the same network, I see no relationship with Tr= ust Domains. > > Superficially there seems to be some similarity between this and the > process of inserting and removing asserted identities at trust > boundaries. ISTM there should be some thought into whether this is > coincidental or is significant. > > I guess you are assuming that the identifier is preserved from a request > to a response, even if the request traverses several transit networks? It's not needed (eventhough it may of course happen if a Via header field p= arameter is used). It only needs to be preserved inside the network that in= serts and consumes the value. > And even if there is limited trust between those networks? (Use of Via > implies this. This might be necessary in case a network needs to apply > some services to a response.) If my network doesn't want the succeeding network to know anything about th= e preceding network (identified by the value), it can of course remove the = value before forwarding the request to the succeeding network. It could do = that even if there is a trust relationship, as the succeeding network isn't= supposed to do anything with the identifier.=20 (The succeeding network might then itself insert a value on its own, indica= tinig that the request came from my network. But there is no requirement th= at the succeeding network need to know from where my network got the reques= t). Regards, Christer From adam@nostrum.com Wed Dec 12 12:16:15 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CDE1F0CC7 for ; Wed, 12 Dec 2012 12:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, SPF_PASS=-0.001, URI_NOVOWEL=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYaHhqtUAqfd for ; Wed, 12 Dec 2012 12:16:15 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A88661F0CC2 for ; Wed, 12 Dec 2012 12:16:14 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qBCKG5pF014218 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 12 Dec 2012 14:16:06 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50C8E605.9000606@nostrum.com> Date: Wed, 12 Dec 2012 14:16:05 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se>, <50C618D7.4040201@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B05252C@ESESSMB209.ericsson.se> <50C7715F.30500@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B053C6D@ESESSMB209.ericsson.se>, <50C8B6E8.5060803@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B054375@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B054375@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 20:16:15 -0000 On 12/12/12 14:05, Christer Holmberg wrote: > They don't have to be actual registered DNS names, but from my understanding when talking to people that would often be the case. That's also the reason is used in the syntax. What I'm seeing here is that these identifiers are only going to be of use in conjunction with bilateral agreements between peering partners. If that's the case, couldn't such partners collude to use FQDNs in the "host" production of Via header fields? Via: SIP/2.0/TCP p24-i379-c1054.foobarcom.net;branch=Z9hG4bK3cGRRPtc;received=192.0.2.26 It's pretty clear that any message containing that Via header field transited foobarcom.net at some point during its journey. And that's what you're trying to do here, right? /a From christer.holmberg@ericsson.com Thu Dec 13 00:40:58 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B5221F8A69 for ; Thu, 13 Dec 2012 00:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.962 X-Spam-Level: X-Spam-Status: No, score=-5.962 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfUbGqgXEfDX for ; Thu, 13 Dec 2012 00:40:57 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 03D4421F86D5 for ; Thu, 13 Dec 2012 00:40:56 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-cc-50c99497122b Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 31.37.10459.79499C05; Thu, 13 Dec 2012 09:40:55 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0318.001; Thu, 13 Dec 2012 09:40:55 +0100 From: Christer Holmberg To: Adam Roach Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 Thread-Index: Ac3WvTkjByInUM1RTJSbqOOOIsdUsgANG+aAAAgkdVkAKzJegAAewx4wABG/EAAAB8vRaf//+cuA//8hacA= Date: Thu, 13 Dec 2012 08:40:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0547C2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se>, <50C618D7.4040201@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B05252C@ESESSMB209.ericsson.se> <50C7715F.30500@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B053C6D@ESESSMB209.ericsson.se>, <50C8B6E8.5060803@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B054375@ESESSMB209.ericsson.se> <50C8E605.9000606@nostrum.com> In-Reply-To: <50C8E605.9000606@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje70KScDDLZttrTY83cRu8WKDQdY Lb7+2MTmwOzx9/0HJo8lS34yecza+YQlgDmKyyYlNSezLLVI3y6BK2PTyofMBWt5Ku7vWMnc wPiDs4uRk0NCwETi851XjBC2mMSFe+vZuhi5OIQEDjFK7H60mRnCWcIocfLvb6YuRg4ONgEL ie5/2iANIgKKEm2HbzKDhJkFAiXutYqDhIUFvCS2/5nCBlHiLTFjayc7hJ0k8fogyBRODhYB VYmfRx6ygNi8QDX3/x+G2juDWWJ+zypWkASngLbEyYblYEWMQMd9P7UGrJlZQFzi1pP5TBBH C0gs2XOeGcIWlXj5+B8ryD0SQLct75eDKNeRWLD7ExuErS2xbOFrZoi9ghInZz5hmcAoNgvJ 1FlIWmYhaZmFpGUBI8sqRvbcxMyc9HLDTYzAqDm45bfuDsZT50QOMUpzsCiJ83Il7fcXEkhP LEnNTk0tSC2KLyrNSS0+xMjEwSnVwCidk+f6hndOU2JZx1Khyu6XAq1J8gwvQxOy/3eKZR55 fnvPx3s29qn1Bf+Cat5N82bQSUu+dnnLbLbqe5Lzv86Tks4JTJPQb5F/unTj07YY1mzHF5tD Aj7dzOecJfFj6mpluafzf7XLpGeu2Xv+XpHw7XSDUO049fvRoq0bqvLWylg8Kny4WYmlOCPR UIu5qDgRAMq6BeloAgAA Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 08:40:58 -0000 Hi Adam, >> They don't have to be actual registered DNS names, but from my understan= ding when talking to people that would often be the case. That's also the r= eason is used in the syntax. > > What I'm seeing here is that these identifiers are only going to be of us= e in conjunction with bilateral agreements between peering partners.=20 > If that's the case, couldn't such partners collude to use FQDNs in the "h= ost" production of Via header fields? > > Via: SIP/2.0/TCP p24-i379-c1054.foobarcom.net;branch=3DZ9hG4bK3cGRRPtc;re= ceived=3D192.0.2.26 > > It's pretty clear that any message containing that Via header field trans= ited foobarcom.net at some point during its journey. And that's what you're= trying to do here, right? I was asking the same thing, and there are couple of issues: First, in many cases entities insert IP addresses, instead of FQDNs. And, e= specially in case of enterprise networks things like Inverse DNS won't work= . Second, it requires more processing when the consuming entities need to sca= n through the list of Via headers, perform "string compares" until it finds= the first Via FQDN that doesn't represent a node within its own network, r= ather than simply looking for the parameter. So, from a protocol perspective I agree with you that it probably could be = done already, and that receive-realm is more about an optimization: one ent= ity does the "hard work", inserts the indicator, and other entities within = the network can then simply use it. Regards, Christer From pkyzivat@alum.mit.edu Thu Dec 13 16:05:51 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81FA21F89D0 for ; Thu, 13 Dec 2012 16:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJ+nDFAvf9r6 for ; Thu, 13 Dec 2012 16:05:51 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 25CB121F89A0 for ; Thu, 13 Dec 2012 16:05:49 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id b8MT1k00F1YDfWL53C5pXR; Fri, 14 Dec 2012 00:05:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id bC5o1k00n3ZTu2S3gC5pvo; Fri, 14 Dec 2012 00:05:49 +0000 Message-ID: <50CA6D5B.6090707@alum.mit.edu> Date: Thu, 13 Dec 2012 19:05:47 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B054E83@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B054E83@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355443549; bh=zTkrS63dxTX/x5Ut0djAWnv7dQ5bjPheHLWplIbuiUM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kKHBSilMdvTPheRybs/2qCo+oJQPf8KZS5zlL/0V1TsrG11a4B70T2BXFNPuBN2V8 JAMbnvFSBRe2xZgHNai6W3IaxLaGUaqdXr1Vu8a0JvE51Sd2Ry5EG6oxqm5JPpPEgo suIlYjV1zp0iWI73IHw/0Z97nHckNe/kBMxds3XJDWj8IdQmwr7Mn1h0U9oVxYzETm UIbeLtlJCDmru5ahQVsi+Rel6kF5sf9kjFb43Pus0NVDy9v13PE7zHxg+Fp8abrrW7 41mpsR0hvzFKlF4DdrRW0YPEC8cx7i9N6/LV2qHLH5j5jIiuDxvwzSiegoaasmWnNj Ir2+uOCiiGNHQ== Cc: SIPCORE Subject: Re: [sipcore] Status of Priority registry X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 00:05:51 -0000 On 12/13/12 10:02 AM, Christer Holmberg wrote: > Hi, > > What is the status of the Priority header field registry? > > As the request for a registration template was withdrawn, and there was > not a decision (AFAIK) to define the existing 3261 values, are there any > other issues which prevents the draft from being moved forward? > > Or, has it already been moved forward? :) Sorry for not announcing results before. The period for the simultaneous call for adoption and WGLC completed. There was consensus to adopt. The only significant issue that I saw wrt WGLC was whether there should be an IANA registration prototype. That was proposed by Christer, and he subsequently withdrew that proposal. The only other person arguing in favor of that was Keith. IMO we have consensus to consider this document complete as written after being renamed as a WG draft. Keith - please let me know if you have serious objection to this. Adam has informed me that he will post a WG version asap - hopefully tomorrow. Once he has done this we will inform ecrit so they can appropriately reference the new draft. I plan to forward this on to our AD shortly. Thanks, Paul From keith.drage@alcatel-lucent.com Thu Dec 13 16:25:13 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356D021F8BF2 for ; Thu, 13 Dec 2012 16:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.145 X-Spam-Level: X-Spam-Status: No, score=-110.145 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTCIWPVUMYBc for ; Thu, 13 Dec 2012 16:25:09 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id C542721F8BEC for ; Thu, 13 Dec 2012 16:25:07 -0800 (PST) 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 qBE0P33o012250 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 14 Dec 2012 01:25:03 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 14 Dec 2012 01:25:03 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , Christer Holmberg Date: Fri, 14 Dec 2012 01:25:02 +0100 Thread-Topic: [sipcore] Status of Priority registry Thread-Index: Ac3ZjtEhSw9mJKxpSHe+u4/FJv+/xgAAjoDg Message-ID: References: <7594FB04B1934943A5C02806D1A2204B054E83@ESESSMB209.ericsson.se> <50CA6D5B.6090707@alum.mit.edu> In-Reply-To: <50CA6D5B.6090707@alum.mit.edu> 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 Cc: SIPCORE Subject: Re: [sipcore] Status of Priority registry X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 00:25:13 -0000 Go back and read the messages - Christer proposed a template, I objected to= a template, and Christer withdrew the proposal. As the justification for not needing it is that we have a registration poli= cy that requires an RFC, we'd only need to revisit this if we changed the r= egistration policy to something more relaxed. The other issues was the updates or not, and the AD has spoken on this one = (in that it does update). Regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Paul Kyzivat > Sent: 14 December 2012 00:06 > To: Christer Holmberg > Cc: SIPCORE > Subject: Re: [sipcore] Status of Priority registry >=20 > On 12/13/12 10:02 AM, Christer Holmberg wrote: > > Hi, > > > > What is the status of the Priority header field registry? > > > > As the request for a registration template was withdrawn, and there was > > not a decision (AFAIK) to define the existing 3261 values, are there an= y > > other issues which prevents the draft from being moved forward? > > > > Or, has it already been moved forward? :) >=20 > Sorry for not announcing results before. >=20 > The period for the simultaneous call for adoption and WGLC completed. > There was consensus to adopt. >=20 > The only significant issue that I saw wrt WGLC was whether there should > be an IANA registration prototype. That was proposed by Christer, and he > subsequently withdrew that proposal. The only other person arguing in > favor of that was Keith. >=20 > IMO we have consensus to consider this document complete as written > after being renamed as a WG draft. >=20 > Keith - please let me know if you have serious objection to this. >=20 > Adam has informed me that he will post a WG version asap - hopefully > tomorrow. Once he has done this we will inform ecrit so they can > appropriately reference the new draft. >=20 > I plan to forward this on to our AD shortly. >=20 > Thanks, > Paul >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Fri Dec 14 07:34:21 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B002421F87C7 for ; Fri, 14 Dec 2012 07:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J16YGOpALb0b for ; Fri, 14 Dec 2012 07:34:21 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id C82DB21F86A9 for ; Fri, 14 Dec 2012 07:34:20 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta03.westchester.pa.mail.comcast.net with comcast id bNzj1k0050vyq2s53TaLEE; Fri, 14 Dec 2012 15:34:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id bTaK1k00H3ZTu2S3RTaK7L; Fri, 14 Dec 2012 15:34:20 +0000 Message-ID: <50CB46FB.7020602@alum.mit.edu> Date: Fri, 14 Dec 2012 10:34:19 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <7594FB04B1934943A5C02806D1A2204B054E83@ESESSMB209.ericsson.se> <50CA6D5B.6090707@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355499260; bh=ea7jZwBZAyA7ckVn/MjIga7VrMzk0CXwrEGbGEPES3M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eSK1c1FlkkMI2Nq/48bC9EeXj/KPVY1SAWAeVhbPwjUj9Q/CJblb+ZUD+hgOUyflM beLHmAUHQqISo7Df4K0HKe7LI16dsvO4auJZ36SsJJBv61N1jaj1GxQwPo5CPzqoDI EOSs4SA/Dd4DVtMIKBgSBETJjLtbEJhn8D0cfB5xaLWqzb8lIQAnJ9/L9QqtCxkrEN SRrm2do2aIq2zI2ZoI9A0WSUXlbvFaQzH3o8SE9fgAW+fWDI7UmJkhjoOWi/7/txXL npPKynN4751sQ5VBdIFB/3y5Yda8BkbHc9sQ0aQ7Tye1tq2OHn1VWd7njfQTRNDPPU yqbzLcEkrcjAA== Cc: SIPCORE Subject: Re: [sipcore] Status of Priority registry X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 15:34:21 -0000 On 12/13/12 7:25 PM, DRAGE, Keith (Keith) wrote: > Go back and read the messages - Christer proposed a template, I objected to a template, and Christer withdrew the proposal. > > As the justification for not needing it is that we have a registration policy that requires an RFC, we'd only need to revisit this if we changed the registration policy to something more relaxed. > > The other issues was the updates or not, and the AD has spoken on this one (in that it does update). OK, sorry. So there is no disagreement at all now. Good. Thanks, Paul > Regards > > Keith > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: 14 December 2012 00:06 >> To: Christer Holmberg >> Cc: SIPCORE >> Subject: Re: [sipcore] Status of Priority registry >> >> On 12/13/12 10:02 AM, Christer Holmberg wrote: >>> Hi, >>> >>> What is the status of the Priority header field registry? >>> >>> As the request for a registration template was withdrawn, and there was >>> not a decision (AFAIK) to define the existing 3261 values, are there any >>> other issues which prevents the draft from being moved forward? >>> >>> Or, has it already been moved forward? :) >> >> Sorry for not announcing results before. >> >> The period for the simultaneous call for adoption and WGLC completed. >> There was consensus to adopt. >> >> The only significant issue that I saw wrt WGLC was whether there should >> be an IANA registration prototype. That was proposed by Christer, and he >> subsequently withdrew that proposal. The only other person arguing in >> favor of that was Keith. >> >> IMO we have consensus to consider this document complete as written >> after being renamed as a WG draft. >> >> Keith - please let me know if you have serious objection to this. >> >> Adam has informed me that he will post a WG version asap - hopefully >> tomorrow. Once he has done this we will inform ecrit so they can >> appropriately reference the new draft. >> >> I plan to forward this on to our AD shortly. >> >> Thanks, >> Paul >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > From internet-drafts@ietf.org Fri Dec 14 16:28:55 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F90421F8B34; Fri, 14 Dec 2012 16:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaaOEr-r5jaK; Fri, 14 Dec 2012 16:28:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BED21F8AD7; Fri, 14 Dec 2012 16:28:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121215002854.2416.53712.idtracker@ietfa.amsl.com> Date: Fri, 14 Dec 2012 16:28:54 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-priority-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 00:28:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : IANA Registry for the Session Initiation Protocol (SIP) = "Priority" Header Field Author(s) : Adam Roach Filename : draft-ietf-sipcore-priority-00.txt Pages : 3 Date : 2012-12-14 Abstract: This document defines a new IANA registry to keep track of the values defined for the Session Initiation Protocol (SIP) "Priority" header field. It updates RFC 3261. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-priority There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-priority-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From btv1==69844116b32==HKaplan@acmepacket.com Mon Dec 17 10:21:56 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DCC21F8B28 for ; Mon, 17 Dec 2012 10:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryrdR1SLM8m5 for ; Mon, 17 Dec 2012 10:21:55 -0800 (PST) Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id 4647A21F8AFE for ; Mon, 17 Dec 2012 10:21:54 -0800 (PST) X-ASG-Debug-ID: 1355768508-03fc2110a7369cf0001-zLx1xO Received: from Mail2.acmepacket.com (mail2.acmepacket.com [10.0.0.22]) by mx2.acmepacket.com with ESMTP id xQWSGkYpvsTf1rHN (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Dec 2012 13:21:48 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL1.acmepacket.com ([169.254.1.21]) by Mail2.acmepacket.com ([169.254.2.189]) with mapi id 14.02.0283.003; Mon, 17 Dec 2012 13:21:48 -0500 From: Hadriel Kaplan To: Christer Holmberg Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-ASG-Orig-Subj: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 Thread-Index: AQHN3INgAGbKWamIMEK1W9WbNw/t2A== Date: Mon, 17 Dec 2012 18:21:47 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: multipart/alternative; boundary="_000_A121CCDBF5C5421A8DA152D83D2894A9acmepacketcom_" MIME-Version: 1.0 X-Barracuda-Connect: mail2.acmepacket.com[10.0.0.22] X-Barracuda-Start-Time: 1355768508 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.117287 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 18:21:56 -0000 --_000_A121CCDBF5C5421A8DA152D83D2894A9acmepacketcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable A mechanism for this already exists, and has been in fairly wide deployment= for many years: the trunk-group/trunk-context identifiers in RFC 4904. The advantages of doing it as a trunk-context param instead of a Via-header= param is that (1) it can be used to indicate the ingress domain info regar= dless of whether it came in on SIP, H.323, WebRTC, or TDM, and (2) does not= require the pass-through or creation of an extra Via header if the ingress= node is a B2BUA such as an SBC. The downside is that it requires adding the tgrp/trunk-context params to th= e Contact URI, which is a no-no for a SIP Proxy to do. -hadriel On Dec 10, 2012, at 5:04 AM, Christer Holmberg > wrote: Hi, We=92ve submitted a new draft, draft-holmberg-sipcore-received-realm-00.txt= , which allows network entry points to indicate the preceding network, from= where a request is received. The information can be used inside the networ= k, to provide services, routing etc, based on the information. The indicati= on is conveyed as a new Via header field parameter, =93received-realm=94. In 3GPP, there is currently a use-case where the information is used to pro= vide services within a transit network. Another use-case, also documented i= n the draft, is transit routing. http://www.ietf.org/id/draft-holmberg-sipcore-received-realm-00.txt Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_A121CCDBF5C5421A8DA152D83D2894A9acmepacketcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

A mechanism for this already exists, and has been in fairly wide deplo= yment for many years: the trunk-group/trunk-context identifiers in RFC 4904= .

The advantages of doing it as a trunk-context param instead of a Via-h= eader param is that (1) it can be used to indicate the ingress domain info = regardless of whether it came in on SIP, H.323, WebRTC, or TDM, and (2) doe= s not require the pass-through or creation of an extra Via header if the ingress node is a B2BUA such as an = SBC.

The downside is that it requires adding the tgrp/trunk-context params = to the Contact URI, which is a no-no for a SIP Proxy to do.

-hadriel


On Dec 10, 2012, at 5:04 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote= :

Hi,
 
We=92ve submitted a new draft, draft-holmberg-sipcore-received-realm-00.txt= , which allows network entry points to indicate the preceding network, from= where a request is received. The information can be used inside the networ= k, to provide services, routing etc, based on the information. The indication is conveyed as a new Via header f= ield parameter, =93received-realm=94.
 
In 3GPP, there is currently a use-case where the information is used to pro= vide services within a transit network. Another use-case, also documented i= n the draft, is transit routing.
 
 
Regards,
 
Christer
 
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/= sipcore

--_000_A121CCDBF5C5421A8DA152D83D2894A9acmepacketcom_-- From christer.holmberg@ericsson.com Mon Dec 17 10:29:02 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6C521F8B6E for ; Mon, 17 Dec 2012 10:29:02 -0800 (PST) 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.036, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPsHieIz2VGh for ; Mon, 17 Dec 2012 10:29:01 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1505C21F8B64 for ; Mon, 17 Dec 2012 10:29:00 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-62-50cf646b39b3 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FD.56.10459.B646FC05; Mon, 17 Dec 2012 19:28:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.43]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 19:28:59 +0100 From: Christer Holmberg To: Hadriel Kaplan Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 Thread-Index: Ac3WvTkjByInUM1RTJSbqOOOIsdUsgFvcTqAAAI54co= Date: Mon, 17 Dec 2012 18:28:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B06896E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvjW52yvkAg5UrrS3mXn7ObvH1xyY2 ByaPTZM3s3ksWfKTKYApissmJTUnsyy1SN8ugStj62+WgkMCFRf37WVqYNzP28XIySEhYCLx YukZJghbTOLCvfVsILaQwCFGicfN7l2MXED2YkaJZ0c6GbsYOTjYBCwkuv9pg9SICGhLXJq0 lRXEZhbQlHi0cy/YHGEBL4ntf6awQdR4S8zY2skOYVtJLJg+mwXEZhFQlbiy5iMziM0LVHNj ZzsjxK5GRoltE/rBmjkFnCRWd50GW8AIdNz3U2uYIJaJS9x6Mh/qaAGJJXvOM0PYohIvH/9j BblTQkBRYnm/HES5gcT7c/OZIWxtiWULX0PtFZQ4OfMJywRGsVlIps5C0jILScssJC0LGFlW MbLnJmbmpJcbbmIExsfBLb91dzCeOidyiFGag0VJnJcrab+/kEB6YklqdmpqQWpRfFFpTmrx IUYmDk6pBsbYwmnKfgZqJkdiZfYfOrB0xyLx193mz9Y9PvmiSuiO1cz0rNulfWfk4p/q3rPT 9L3i/EfmUWe578n1rcwcEjdDLq3ls4qastOk91yBwr7wsIyIiYVym4NMGFtEplu8qb01uZIx 655hb/CbH169E4Pc7rDpJSqYWv62/WeT8iMjMkzVp5TDRImlOCPRUIu5qDgRAPKqR9xdAgAA Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 18:29:02 -0000 Hi, > A mechanism for this already exists, and has been in fairly wide deployme= nt for many years: the trunk-group/trunk-context identifiers in RFC 4904. > > The advantages of doing it as a trunk-context param instead of a Via-head= er param is that (1) it can be used to indicate the ingress domain info reg= ardless=20 > of whether it came in on SIP, H.323, WebRTC, or TDM, and (2) does not req= uire the pass-through or creation of an extra Via header if the ingress nod= e is a B2BUA such as an SBC. The idea is that the ingress node inserts the value, so pass-through is not= an issue. > The downside is that it requires adding the tgrp/trunk-context params to = the Contact URI, which is a no-no for a SIP Proxy to do. Correct. In addition, the request might traverse multiple networks, each wi= th its own ingress node - which would have to remove any existing Contact v= alue, and insert a new one. It was suggested in 3GPP to use a feature-capability indicator for this, bu= t that suggestion was not accepted as it is not about indicating support fo= r a feature. Regards, Christer On Dec 10, 2012, at 5:04 AM, Christer Holmberg > wrote: Hi, We=92ve submitted a new draft, draft-holmberg-sipcore-received-realm-00.txt= , which allows network entry points to indicate the preceding network, from= where a request is received. The information can be used inside the networ= k, to provide services, routing etc, based on the information. The indicati= on is conveyed as a new Via header field parameter, =93received-realm=94. In 3GPP, there is currently a use-case where the information is used to pro= vide services within a transit network. Another use-case, also documented i= n the draft, is transit routing. http://www.ietf.org/id/draft-holmberg-sipcore-received-realm-00.txt Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From btv1==69844116b32==HKaplan@acmepacket.com Mon Dec 17 10:54:16 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F4621F89E5 for ; Mon, 17 Dec 2012 10:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZR-s-DUk5un9 for ; Mon, 17 Dec 2012 10:54:16 -0800 (PST) Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 64F5F21F8A94 for ; Mon, 17 Dec 2012 10:54:14 -0800 (PST) X-ASG-Debug-ID: 1355770452-03fc200e933bf10001-zLx1xO Received: from Mail2.acmepacket.com (mail2.acmepacket.com [10.0.0.22]) by mx1.acmepacket.com with ESMTP id xzJcwnAWA08ZKuYA (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Dec 2012 13:54:12 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL1.acmepacket.com ([169.254.1.21]) by Mail2.acmepacket.com ([169.254.2.189]) with mapi id 14.02.0283.003; Mon, 17 Dec 2012 13:54:12 -0500 From: Hadriel Kaplan To: Christer Holmberg Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-ASG-Orig-Subj: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 Thread-Index: AQHN3IfnRZ3V1rRQNUOrAVppxHTc/g== Date: Mon, 17 Dec 2012 18:54:11 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B06896E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B06896E@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail2.acmepacket.com[10.0.0.22] X-Barracuda-Start-Time: 1355770452 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.117289 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "sipcore@ietf.org Core\) WG" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 18:54:16 -0000 On Dec 17, 2012, at 1:28 PM, Christer Holmberg wrote: > The idea is that the ingress node inserts the value, so pass-through is n= ot an issue. Ah, I missed the part of it adding it to its own Via, rather than the recei= ved Via. >> The downside is that it requires adding the tgrp/trunk-context params to= the Contact URI, which is a no-no for a SIP Proxy to do. >=20 > Correct. In addition, the request might traverse multiple networks, each = with its own ingress node - which would have to remove any existing Contact= value, and insert a new one. Actually, I think that's a benefit of trunk-group... you've stated the cont= ext info is only relevant to the local domain, so passing it on to other do= mains makes no sense. Right? But if it *is* important/useful to pass onto= other downstream domains, then putting it in the Via won't work because of= downstream B2BUAs removing Via's (as they should). Don't get me wrong - I've always hated that trunk-group stuff is in the Con= tact URI - but it's a working solution that's been used successfully for a = long time. Do you think there's sufficient cause/issues/demand to provide = yet another way to do the same thing? (I don't know if there is/isn't, just= asking) If there is, I suggest this be done following the trunk group syntax exactl= y, so that "interworking" it only requires blind copying from one header/UR= I location to another. In fact, maybe this thing should be an update to RF= C 4904. -hadriel From christer.holmberg@ericsson.com Mon Dec 17 11:07:37 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC2721F8B66 for ; Mon, 17 Dec 2012 11:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.215 X-Spam-Level: X-Spam-Status: No, score=-6.215 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNqe0z1x98O5 for ; Mon, 17 Dec 2012 11:07:37 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D152C21F8B64 for ; Mon, 17 Dec 2012 11:07:36 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-f6-50cf6d77191a Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8C.99.10459.77D6FC05; Mon, 17 Dec 2012 20:07:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.43]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 20:07:35 +0100 From: Christer Holmberg To: Hadriel Kaplan Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 Thread-Index: Ac3WvTkjByInUM1RTJSbqOOOIsdUsgFvcTqAAAI54cr///c+gIAAEagq Date: Mon, 17 Dec 2012 19:07:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0689ED@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B051CFA@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B06896E@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+JvjW5F7vkAg/3vmSzmXn7ObvH1xyY2 ByaPTZM3s3ksWfKTKYApissmJTUnsyy1SN8ugSvjyr5DrAWPBCqm929hbWCczdvFyMkhIWAi sePednYIW0ziwr31bF2MXBxCAocYJR6dXcoO4SxmlLjw8SFLFyMHB5uAhUT3P22QBhEBbYlL k7aygtjMAkYSM368BrOFBbwktv+ZwgZR4y0xY2snO0iriICbxJlVYLtYBFQl9v55wQxi8wKV rD57BmrvT0aJv3NbwIo4BZwkXp5qBJvDCHTc91NrmCB2iUvcejKfCeJoAYkle84zQ9iiEi8f /2MF2SUhoCixvF8OolxHYsHuT2wQtrbEsoWvofYKSpyc+YRlAqPYLCRTZyFpmYWkZRaSlgWM LKsY2XMTM3PSyw03MQIj5OCW37o7GE+dEznEKM3BoiTOy5W0319IID2xJDU7NbUgtSi+qDQn tfgQIxMHp1QDYx170alurieFWuujGheHHxZj9hdbnPKkJ0JqytzS0l95c9OXumXve8XXXX3z tlKYn9X12/Y5N3RDdtxsn7uVN9m6fkZ/8S/vHUqNty7s5pW9tKCEpfWywGM79cTfchPWZpm6 WugbvPiTuEvr1bQeuem/pnRPcz70kDs+6PW/1U5pO1xY9/TmKbEUZyQaajEXFScCANuzvURe AgAA Cc: "sipcore@ietf.org Core\) WG" Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-received-realm-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 19:07:38 -0000 Hi, >> The idea is that the ingress node inserts the value, so pass-through is = not an issue. > > Ah, I missed the part of it adding it to its own Via, rather than the rec= eived Via. The example flow shows the difference, but having more normative text about= the difference would probably be useful :) Another reason we chose adding the value to its own Via was to allow e.g. a= PSTN gateway (or any other entity that doesn't receive a SIP request with = Via headers) to use the mechanism. >>> The downside is that it requires adding the tgrp/trunk-context params t= o the Contact URI, which is a no-no for a SIP Proxy to do. >> >> Correct. In addition, the request might traverse multiple networks, each= with its own ingress node - which would have to remove any existing Contac= t value, and insert a new one. > > Actually, I think that's a benefit of trunk-group... you've stated the co= ntext info is only relevant to the local domain, so passing it on to other = domains makes no sense. Right? Correct. > But if it *is* important/useful to pass onto other downstream domains, th= en putting it in the Via won't work because of downstream B2BUAs removing V= ia's (as they should). Correct. But, there are no requiements to pass this information onto other = downstream domains. > Don't get me wrong - I've always hated that trunk-group stuff is in the C= ontact URI - but it's a working solution that's been used successfully for = a long time. Do you think there's sufficient=20 > cause/issues/demand to provide yet another way to do the same thing? (I d= on't know if there is/isn't, just asking) I'm not sure it's the same thing. Couldn't the trunk-group (as defined in R= FC 4904) be something that you actually want to pass on to downstream domai= ns? > If there is, I suggest this be done following the trunk group syntax exac= tly, so that "interworking" it only requires blind copying from one header/= URI location to another. In fact, maybe this thing should be an update to = RFC 4904. I'm not religious when it comes to the syntax. Regards, Christer From christer.holmberg@ericsson.com Wed Dec 19 03:35:29 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4F421F8806 for ; Wed, 19 Dec 2012 03:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYKs2SP727be for ; Wed, 19 Dec 2012 03:35:29 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9732E21F8802 for ; Wed, 19 Dec 2012 03:35:28 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-81-50d1a67e911e Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0D.F4.10459.F76A1D05; Wed, 19 Dec 2012 12:35:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.43]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 12:35:26 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: Draft new version: rkeep Thread-Index: Ac3d3IcaTSXQKePgRi2D/SSYz54kFA== Date: Wed, 19 Dec 2012 11:35:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B06C65D@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B06C65DESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+JvjW79sosBBvce8Ft8/bGJzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGYtXNLAV7JGt6D12krWB8ZpkFyMnh4SAicTxS4tYIGwxiQv3 1rN1MXJxCAkcYpS49uMPE4SzmFFi7qEV7F2MHBxsAhYS3f+0QRpEBDQlln/byg5iCwsoSvxY sJwNpEREQE3iRk8aRImexN27/9hAbBYBVYnnE+aC2bwC3hJLps4E28sItPf7qTVMIDazgLjE rSfzmSDuEZBYsuc8M4QtKvHy8T9WkPESQKuW98tBlOdLXOyfCDVSUOLkzCcsExiFZiGZNAtJ 2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI3tuYmZOernhJkZgyB/c8lt3B+Op cyKHGKU5WJTEecNcLwQICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYJzSdSO0fl2D6Z31+5Vc 9TeVZ36p/3Bqioj5ZS9pNsuO218yJE/btYStSpmw7Cd7xQf52obLS9suW6zqFLJ7HuX4dX6G J4Od3ET/k1YaIhN2TF51RSZv/nHRid6VtSUFwlLzNGbtrN0/xVhFrWl+kNI5A32xVfFPFA9c VQzbn/a8cIK1g8m0KiWW4oxEQy3mouJEAHI+0vBHAgAA Subject: [sipcore] Draft new version: rkeep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 11:35:30 -0000 --_000_7594FB04B1934943A5C02806D1A2204B06C65DESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version of the rkeep (reverse keep-alive) draft. I've tried to address the received comments. I did some editorial correctio= ns, added an example flow, corrected a reference, and added some text about= forking. Paul had one question about why one cannot re-negotiate the sending of keep= -alives during a dialog. I was going to look into that, but haven't found a= nything, so for now I haven't changed anything. I'll continue to look into = it. The reason MAY be that we simply saw no reason for allowing it when wor= king on RFC 6223 (which rkeep inherits much of its procedures from). Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B06C65DESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new version of the rkeep (rev= erse keep-alive) draft.

 

I’ve tried to address the received comments. I= did some editorial corrections, added an example flow, corrected a referen= ce, and added some text about forking.

 

Paul had one question about why one cannot re-negoti= ate the sending of keep-alives during a dialog. I was going to look into th= at, but haven’t found anything, so for now I haven’t changed an= ything. I’ll continue to look into it. The reason MAY be that we simply saw no reason for allowing it when working on RFC 62= 23 (which rkeep inherits much of its procedures from).

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B06C65DESESSMB209ericsso_-- From rjsparks@nostrum.com Wed Dec 19 08:55:28 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CB821F8750 for ; Wed, 19 Dec 2012 08:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9IXUsaGdOlM for ; Wed, 19 Dec 2012 08:55:27 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6C87E21F84DB for ; Wed, 19 Dec 2012 08:55:27 -0800 (PST) Received: from unnumerable.local (pool-173-71-45-100.dllstx.fios.verizon.net [173.71.45.100]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qBJGtQn8073392 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 19 Dec 2012 10:55:26 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <50D1F17E.5040808@nostrum.com> Date: Wed, 19 Dec 2012 10:55:26 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "sipcore@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.71.45.100 is authenticated by a trusted mechanism) Subject: [sipcore] AD Review: draft-ietf-sipcore-priority X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 16:55:28 -0000 Summary: Ready for IETF Last Call - which I've requested (extending it by a week for the holidays). Watch for it's announcement shortly. Reviewing the WG threads, there is one message from Hannes which has not received a response. Please discuss it before the IETF LC period expires. RjS From iesg-secretary@ietf.org Wed Dec 19 09:30:41 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E26221F8932; Wed, 19 Dec 2012 09:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShapJZhLNQpw; Wed, 19 Dec 2012 09:30:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B0C21F8488; Wed, 19 Dec 2012 09:30:41 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121219173041.15946.7174.idtracker@ietfa.amsl.com> Date: Wed, 19 Dec 2012 09:30:41 -0800 Cc: sipcore@ietf.org Subject: [sipcore] Last Call: (IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 17:30:41 -0000 The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a new IANA registry to keep track of the values defined for the Session Initiation Protocol (SIP) "Priority" header field. It updates RFC 3261. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sipcore-priority/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sipcore-priority/ballot/ No IPR declarations have been submitted directly on this I-D. From rjsparks@nostrum.com Wed Dec 19 09:45:51 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F11521F87B2 for ; Wed, 19 Dec 2012 09:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5PlMW7UKScO for ; Wed, 19 Dec 2012 09:45:50 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 351C921F8615 for ; Wed, 19 Dec 2012 09:45:50 -0800 (PST) Received: from unnumerable.local (pool-173-71-45-100.dllstx.fios.verizon.net [173.71.45.100]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qBJHjhBS079117 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 19 Dec 2012 11:45:44 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <50D1FD47.207@nostrum.com> Date: Wed, 19 Dec 2012 11:45:43 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <50A160D8.8030602@alum.mit.edu> <50B68A43.8040605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0493C3@ESESSMB209.ericsson.se> <999913AB42CC9341B05A99BBF358718D0229B91C@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D0229B91C@FIESEXC035.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.71.45.100 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] Proposal: Call for adoption& WGLC: draft-roach-sipcore-priority-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 17:45:51 -0000 For clarity - this was the message I was pointing to in my AD review. RjS On 11/29/12 6:20 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > I fear you guys read a bit too much into the term "template". > > IANA typically wants to know what information a request for adding a new > value into an existing registry should contain. This is called the > template. As mentioned, here the required info is pretty obvious: a > label and a reference to a document that contains the semantic. If you > want to make it 100% clear add a sentence: "Registration requests to > IANA must include a label (value for the priority header field) and a > reference to a document that explains the semantic of that label." > > What is, however, missing from the IANA consideration is an indication > whether you envision entries to be updated, deleted, or deprecated. I > would write "Updating, deleting, or deprecating of entries in the > registry is not envisioned." > > Ciao > Hannes > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of ext Christer Holmberg >> Sent: Thursday, November 29, 2012 1:51 PM >> To: DRAGE, Keith (Keith); Paul Kyzivat; sipcore@ietf.org >> Subject: Re: [sipcore] Proposal: Call for adoption& WGLC: draft-roach- >> sipcore-priority-00 >> >> Hi, >> >>> Regarding 1), noone has yet responded as to why we need a template > for >> a document where registration requires IETF work. The template >>> is in my view there to ensure all the information that is needed is >> available for expert review. The document management of an internet >>> draft means that if information is needed for review the next > revision >> can provide it. We only need a template if someone decides a different >>> registration policy is needed. >> Fair enough. I hereby withdraw my request for a template :) >> >> Regards, >> >> Christer >> >> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: 28 November 2012 22:04 >>> To: sipcore@ietf.org >>> Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: >>> draft-roach- >>> sipcore-priority-00 >>> >>> The WGLC and adoption deadline has now passed for >>> draft-roach-sipcore-priority-00. Nine people (other than chairs and >>> authors) made meaningful comments. >>> >>> I conclude there is consensus to adopt this draft as a wg document. >>> >>> Regarding WGLC, two notable issues were raised, and I don't yet see > a >>> clear consensus on those issues: >>> >>> - should there be a registration template? >>> Christer advocates this, Keith opposes, Adam finds it > unnecessary. >>> - should this document also spell out the semantics of all the >> priority >>> values defined in 3261? (Currently it only defines "emergency".) >>> Dan, James, and Roy in favor, Adam and I prefer not to do it *in >> this >>> document*. >>> >>> So, I will ask Adam to submit a wg draft version of this document, >>> otherwise unchanged. >>> >>> While he is doing that, I would like to get a broader consensus on >> the >>> issues above. I'll post a separate question on each of those, to > keep >>> the discussions separate. >>> >>> Thanks, >>> Paul >>> >>> On 11/12/12 3:49 PM, Paul Kyzivat wrote: >>>> PLEASE RESPOND TO THIS MESSAGE >>>> >>>> This is a request to the sipcore wg to adopt the new individual >>>> draft draft-roach-sipcore-priority-00, and a start of WGLC on that >>>> document, to end on Sunday, November 25, 2012. (This is a trivial >>>> doc to review, but people may be slow getting back to work after >> the >>>> meeting and there is a holiday coming in the US, so I'm giving > more >>>> time than I otherwise >>>> would.) >>>> >>>> The reason for this is that the ecrit wg wants to define a new >> value >>>> for the Priority header field. RFC 3261 defines that header field >>>> and an initial set of values. It also mentions the possibility of >> extension. >>>> But it failed to establish an IANA registry for that purpose, and >>>> didn't otherwise define a process for extension. >>>> >>>> The intro to *this* document explains its purpose: >>>> >>>> This document defines a new IANA registry to keep track of the >>> values >>>> defined for the Session Initiation Protocol (SIP) "Priority" >> header >>>> field. This header field was defined in [RFC3261], section >> 20.26. >>>> It was clearly specified in a way that allows for the creation >>>> of >>> new >>>> values beyond those originally specified; however, no registry >> has >>>> been established for it. >>>> >>>> Once that is done, ecrit will be able to make their extension in >>>> accord with the registration procedures that have been defined. > The >>>> registration policy is "IETF Review", so discussion of the merits >> of >>>> that new value can be discussed as part of the review of *that* >>>> document: draft-ietf-ecrit-psap-callback. >>>> >>>> REQUESTED ACTIONS: >>>> >>>> - indicate (ASAP) willingness, or not, for the sipcore wg to work >> on >>>> this problem, and adopt this draft as the basis for that work. >>>> >>>> - provide any comments you have on this document before the end of >>>> the WGLC period (Friday, November 25.) >>>> >>>> Thanks, >>>> Paul >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From jmpolk@cisco.com Thu Dec 20 11:01:40 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90B121F89F2 for ; Thu, 20 Dec 2012 11:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPlSnqneHKAl for ; Thu, 20 Dec 2012 11:01:40 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0603021F8982 for ; Thu, 20 Dec 2012 11:01:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1555; q=dns/txt; s=iport; t=1356030100; x=1357239700; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=hkSNRifbs3Tf/84MMmxnNy5Fux4iGwlG209sy1sQ1Eg=; b=gubbAVXX00Pl1yQDcL1y/AaBv6szy3A93Zu5ZBcNi1GdGLTrlfFm9vU5 Q66z16GuuF8XUuJSHViZY+INVPot7V10vFaELbBJhSX3C0KROYOSnloyg yNRLj1cfREW2npLcZ4iRRQSAEiHIowyIb9mn0ejtbNAmC2GJcx+UxnZVw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKFf01CtJV2a/2dsb2JhbABFDr1kFnOCHgEBAQQBAQEaGwI0CxAHBA4KHhAZDjAGARKIEwy5WASMUoRDA4hinXGCNl0 X-IronPort-AV: E=Sophos;i="4.84,326,1355097600"; d="scan'208";a="155204090" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 20 Dec 2012 19:01:39 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) (authenticated bits=0) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBKJ1dIs022964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 19:01:39 GMT Message-Id: <201212201901.qBKJ1dIs022964@rcdn-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Dec 2012 13:01:39 -0600 To: Paul Kyzivat , Christer Holmberg From: James Polk In-Reply-To: <50CA6D5B.6090707@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B054E83@ESESSMB209.ericsson.se> <50CA6D5B.6090707@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: SIPCORE Subject: Re: [sipcore] Status of Priority registry X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 19:01:40 -0000 At 06:05 PM 12/13/2012, Paul Kyzivat wrote: >On 12/13/12 10:02 AM, Christer Holmberg wrote: >>Hi, >> >>What is the status of the Priority header field registry? >> >>As the request for a registration template was withdrawn, and there was >>not a decision (AFAIK) to define the existing 3261 values, are there any >>other issues which prevents the draft from being moved forward? >> >>Or, has it already been moved forward? :) > >Sorry for not announcing results before. > >The period for the simultaneous call for adoption and WGLC completed. >There was consensus to adopt. > >The only significant issue that I saw wrt WGLC was whether there >should be an IANA registration prototype. That was proposed by >Christer, and he subsequently withdrew that proposal. The only other >person arguing in favor of that was Keith. so my proposal on Nov 13th is going to be ignored or was deemed less than significant... James >IMO we have consensus to consider this document complete as written >after being renamed as a WG draft. > >Keith - please let me know if you have serious objection to this. > >Adam has informed me that he will post a WG version asap - hopefully >tomorrow. Once he has done this we will inform ecrit so they can >appropriately reference the new draft. > >I plan to forward this on to our AD shortly. > > Thanks, > Paul > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Thu Dec 20 12:05:11 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABE921F8A87 for ; Thu, 20 Dec 2012 12:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.413 X-Spam-Level: X-Spam-Status: No, score=-0.413 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrtVEpWfWgjc for ; Thu, 20 Dec 2012 12:05:11 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 0124621F89FD for ; Thu, 20 Dec 2012 12:05:10 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta07.westchester.pa.mail.comcast.net with comcast id dvx81k0031ZXKqc57w5ACo; Thu, 20 Dec 2012 20:05:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id dw5A1k0033ZTu2S3hw5A67; Thu, 20 Dec 2012 20:05:10 +0000 Message-ID: <50D36F74.7090305@alum.mit.edu> Date: Thu, 20 Dec 2012 15:05:08 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: James Polk References: <7594FB04B1934943A5C02806D1A2204B054E83@ESESSMB209.ericsson.se> <50CA6D5B.6090707@alum.mit.edu> <201212201901.qBKJ1dIs022964@rcdn-core-3.cisco.com> In-Reply-To: <201212201901.qBKJ1dIs022964@rcdn-core-3.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1356033910; bh=30pk7Kl6v40mZVC8Zcjao521wzY+VQx9WsulZXxXPOI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NYU5zGcitk202WDLFP9D5RZt8/nrivssiymwmMopYeDhDIm2IWmOACN30KdfCCKd6 /iQ7dCKCj6pmt+6XvNF2LW96Yc2y3lcLVk29SkXF/54pAgd7peVpT8mGSJ7EtXe8gC l5LyZonyUE+vrpXAd3SIhzvD7rxuGGcoj1Xq1AU7kzUR0RAIA7y0WTo+T1eW4Xb5rk P7qvr5F04WEjc6Vdm8Lc54hKOMoyG4DluU3VzJEF2BF+NR5TZfCViZaleRXjz5ll/3 AD11CDBdBdqmXNUt3JDnmkid3j9Kyt+U2f0HBsr6FZP7ZrdwQJf6UbxrukVwe4tML7 Ww1ZWSEFr+dyg== Cc: SIPCORE Subject: Re: [sipcore] Status of Priority registry X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 20:05:11 -0000 On 12/20/12 2:01 PM, James Polk wrote: > At 06:05 PM 12/13/2012, Paul Kyzivat wrote: >> On 12/13/12 10:02 AM, Christer Holmberg wrote: >>> Hi, >>> >>> What is the status of the Priority header field registry? >>> >>> As the request for a registration template was withdrawn, and there was >>> not a decision (AFAIK) to define the existing 3261 values, are there any >>> other issues which prevents the draft from being moved forward? >>> >>> Or, has it already been moved forward? :) >> >> Sorry for not announcing results before. >> >> The period for the simultaneous call for adoption and WGLC completed. >> There was consensus to adopt. >> >> The only significant issue that I saw wrt WGLC was whether there >> should be an IANA registration prototype. That was proposed by >> Christer, and he subsequently withdrew that proposal. The only other >> person arguing in favor of that was Keith. > > so my proposal on Nov 13th is going to be ignored or was deemed less > than significant... > > I'm sorry James. I forgot about that one. That got wound up in the discussion of whether we were going to update the definitions of each of the values defined in 3261. We ultimately decided not to do that *in this draft* - that if we want to do that it can be a separate (and more controversial) effort. I did forget to mention that in the shepherd writeup. I perhaps should submit an updated one to include that issue. Thanks, Paul