Re: [martini] New text for gin section 7.1.1 first paragraph

Hadriel Kaplan <HKaplan@acmepacket.com> Wed, 29 September 2010 17:48 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: martini@core3.amsl.com
Delivered-To: martini@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035753A6F0C for <martini@core3.amsl.com>; Wed, 29 Sep 2010 10:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.479
X-Spam-Level:
X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vfe2uh6DDun0 for <martini@core3.amsl.com>; Wed, 29 Sep 2010 10:48:50 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 580F23A6F03 for <martini@ietf.org>; Wed, 29 Sep 2010 10:47:37 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 29 Sep 2010 13:47:41 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 29 Sep 2010 13:47:20 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
Date: Wed, 29 Sep 2010 13:47:20 -0400
Thread-Topic: [martini] New text for gin section 7.1.1 first paragraph
Thread-Index: Actf/l1veVzyGe0RQZai5C1HzE8f7A==
Message-ID: <98CD9FB7-3F10-4867-B9BD-32BACAB432B7@acmepacket.com>
References: <A444A0F8084434499206E78C106220CA01C81C2B32@MCHP058A.global-ad.net> <B1771F0F1F97A8478E2F449EA19CC7C5DA1A7EB3@ESESSCMS0365.eemea.ericsson.se> <A444A0F8084434499206E78C106220CA01C81C2D93@MCHP058A.global-ad.net> <F1A0ED6425368141998E077AC43334E425B8D6F6@gbplmail02.genband.com> <4CA21DF2.5080709@cisco.com> <DD8DA2BD-997C-420F-965F-98D9EEC7C6E9@acmepacket.com> <EDC0A1AE77C57744B664A310A0B23AE2173A6937@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE2173A6937@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "martini@ietf.org" <martini@ietf.org>
Subject: Re: [martini] New text for gin section 7.1.1 first paragraph
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/martini>
List-Post: <mailto:martini@ietf.org>
List-Help: <mailto:martini-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Sep 2010 17:48:52 -0000

Nothing prevents an Enterprise from getting their own Domain name, putting it in DNS, and using rfc3263.

What Martini is doing is letting an Enterprise take responsibility for a subset of an SSP's AoRs.  It's a contractual matter between the Enterprise and SSP what the terms of that responsibility-shifting is, and what features are available.  We (the IETF) need to provide the tools to let scenarios which need GRUU-type URIs to work in this context.  We have done that.  Mandating those tools be *implemented* by the SSP is another matter entirely.  

It's like mandating the SSP support TLS at every hop if they support GIN, so that the Enterprise has the opportunity to use SIPS URIs - after all, how can the Enterprise use SIPS without the SSP doing so?  Or mandating Hist-Info be implemented by the SSP if they do GIN, because otherwise the Enterprise may not be able to support something they need Hist-Info for.

-hadriel

On Sep 29, 2010, at 10:27 AM, DRAGE, Keith (Keith) wrote:

> I disagree.
> 
> In my view MARTINI is not defining a real registrar behaviour. The real registrar for the URI is in the PBX. What MARTINI is defining is some substitute behaviour (that happens to use a registrar in the SSP) for normal SIP routeing in order to reach the real registrar, WITH ALL THE INFORMATION the real registrar needs to do its job. Normal SIP routing does this. MARTINI should not provide a mechanism where suddenly you have a means of opting out of doing this.
> 
> regards
> 
> Keith