Re: [dispatch] To-URI in domain-registration

Paul Kyzivat <pkyzivat@cisco.com> Fri, 30 October 2009 23:37 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0BBA3A688F for <dispatch@core3.amsl.com>; Fri, 30 Oct 2009 16:37:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.572
X-Spam-Level:
X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 olAleZqD66nc for <dispatch@core3.amsl.com>; Fri, 30 Oct 2009 16:37:01 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B32003A67FB for <dispatch@ietf.org>; Fri, 30 Oct 2009 16:37:01 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAD4V60qrR7Hu/2dsb2JhbADIGpgzhDoE
X-IronPort-AV: E=Sophos;i="4.44,656,1249257600"; d="scan'208";a="47505179"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 30 Oct 2009 23:37:19 +0000
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9UNbIt2002852; Fri, 30 Oct 2009 23:37:19 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 19:37:18 -0400
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 19:37:18 -0400
Message-ID: <4AEB78AD.5070608@cisco.com>
Date: Fri, 30 Oct 2009 19:37:17 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "Middleton, David (NSN - US/Boca Raton)" <david.middleton@nsn.com>
References: <E6C2E8958BA59A4FB960963D475F7AC31A0A7C9F34@mail> <09B7DBFE70A9E24BBB21689DAD3A06141B09D891@zcarhxm1.corp.nortel.com><9AAEDF491EF7CA48AB587781B8F5D7C6024FEFD3@srvxchg3.cablelabs.com> <024101ca528e$fbd0a8b0$f371fa10$@us> <159B27ECF9D16E40BD7ABD5778522B0103792C9C@USCHEXC006.nsn-intra.net>
In-Reply-To: <159B27ECF9D16E40BD7ABD5778522B0103792C9C@USCHEXC006.nsn-intra.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 30 Oct 2009 23:37:18.0077 (UTC) FILETIME=[EB0C8AD0:01CA59B9]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] To-URI in domain-registration
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Oct 2009 23:37:04 -0000

David,

IIUC, you are proposing a case such as:

- a customer of sp.net has domain cust.sp.net
- the customer has two PBX systems, east and west.
- you propose that they register, respectively
   To: east@cust.sp.net, and
   To: west@cust.sp.net.
- then numbers assigned to the customer are routed
   something like:
   1-212-555-88xx -> contact from east@cust.sp.net
   1-408-555-88xx -> contact from west@cust.sp.net
- also, routing for names be something like:
   bob@cust.sp.net   -> contact from east@cust.sp.net
   carol@cust.sp.net -> "
   ted@cust.sp.net   -> contact from west@cust.sp.net
   alice@cust.sp.net -> "
   others...

Is that right?

You then can't describe that as setting up routing paths for 
cust.sp.net. You are instead describing some entirely different routing 
algorithm based on the user part.

Subdomains east.cust.sp.net and west.cust.sp.net solve this problem in 
large part - at least for the numbers.

You clearly don't find that acceptable for the names. If those names 
were exposed to end users I wouldn't find it acceptable either. (I want 
to be pkyzivat@cisco.com, not pkyzivat@east.cisco.com.)

The question is whether this is the best way to solve that problem.

I think that solution won't be very acceptable to an SP, or to the 
customer of that SP. Having the SP provision every one of your users 
just isn't going to be popular with anyone. (Unless the SP gets a big 
enough per-user fee.)

Its not quite as much of a problem with numbers, because they are likely 
to be managed in blocks. And the numbers are really owned/managed by the 
SP anyway so they are forced to do something about them.

This is also a problem that is not unique to this SP interconnect 
mechanism. It is pretty much the same problem in any big company with a 
lot of sites, even if they have a private network connecting all the sites.

What you need in this case is a proxy at the company domain level 
(cust.sp.net in this case perhaps) that has the roster of all usernames 
and a mapping to a subdomain - mapping bob@cust.sp.net to 
bob@east.cust.sp.net.

Then, the company has one server registering To:cust.sp.net to provide 
this mapping, and other servers registering To:east.cust.sp.net, ...

	Thanks,
	Paul


Middleton, David (NSN - US/Boca Raton) wrote:
> Some colleagues have pointed out an aspect that I had not considered concerning the domain registration To: user part.  There are cases where an Enterprise has multiple PBXs that register and calls should be routed to one of the PBXs based on which user is called.  In other words, instead of the Enterprise with multiple PBXs appearing as one logical PBX, the Enterprise customer wants the service provider to take responsibility for distributing the calls to the specific PBX that hosts the called user.
> 
> While this problem could be solved with a local policy to choose one of several contacts it is not as clean an approach as being able to treat each registration as a separate entity with it's own contact(s).  While one could propose that these be treated separately by making different sub-domains, the Enterprise most assuredly will not want to publish this sub-domain on business cards, etc. when using e-mail style addresses.  Besides, it would cause the address to change if the user moves from one PBX to another as might happen with a physical move.
> 
> Another aspect to consider is that the Enterprise user, in this scenario, is only reachable via one registered "To: user@host".  So not having separate registrations would result in a more complex definition and implementation of things like (a.) is there an unexpired binding and (b.) picking appropriate contacts by q-value.
> 
> I think this makes a strong case for having a user part in the To: header and treating each unique user@host as a separate registration à la RFC 3264.
> 
> In summary, I support Option 1) as well.
> 
> - David
> 
>  
> 
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Richard Shockey
> Sent: Wednesday, October 21, 2009 4:42 PM
> To: dispatch@ietf.org
> Subject: Re: [dispatch] To-URI in domain-registration
> 
> +1 to Option 1) as well
> 
>>  -----Original Message-----
>>  From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
>>  Behalf Of David Hancock
>>  Sent: Wednesday, October 21, 2009 4:05 PM
>>  To: Brian Lindsay; Hadriel Kaplan; dispatch@ietf.org
>>  Subject: Re: [dispatch] To-URI in domain-registration
>>  
>>  
>>  Hadriel - I'd prefer option 1) as well.
>>  
>>  David
>>  
>>  > -----Original Message-----
>>  > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org]
>>  On
>>  > Behalf Of Brian Lindsay
>>  > Sent: Wednesday, October 21, 2009 1:53 PM
>>  > To: Hadriel Kaplan; dispatch@ietf.org
>>  > Subject: Re: [dispatch] To-URI in domain-registration
>>  >
>>  >  Hi Hadriel,
>>  >
>>  >     Per my comment yesterday, I'd prefer (1).
>>  >
>>  >     Thanks.
>>  >
>>  > -----Original Message-----
>>  > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org]
>>  On
>>  > Behalf Of Hadriel Kaplan
>>  > Sent: Wednesday, October 21, 2009 3:43 PM
>>  > To: dispatch@ietf.org
>>  > Subject: [dispatch] To-URI in domain-registration
>>  >
>>  > Howdy,
>>  > I'd like to get a consensus call on the question of what the To-URI
>>  > should be for the REGISTER request of a domain registration, before
>>  > finishing the next rev of the draft.  This will affect quite a bit
>>  of
>>  > text in the draft (e.g., examples), and I think that the decision
>>  about
>>  > that will also affect whether we need more than a Require:option-tag
>>  as
>>  > well.
>>  >
>>  > The choices right now are:
>>  > 1) Mandate the To-URI be in the syntactical form of an AoR,
>>  including
>>  > the user@ portion, the same as the From-URI.
>>  > 	Pros: closer to what current proprietary and other-SDO
>>  > mechanisms do, on the wire.  Therefore, presumably less of a change
>>  and
>>  > less barrier to adoption.
>>  > 2) Mandate the To-URI be a domain only (no user@), while the From-
>>  URI
>>  > remains the "AoR" of the PBX registering.
>>  > 	Pros: semantically accurate (you're registering a domain, not an
>>  > AoR), and may obviate the need for a new header or param to indicate
>>  > this new mechanism is being used.
>>  >
>>  > Can people please indicate which they'd prefer?
>>  >
>>  > Thanks!
>>  > -hadriel
>>  > _______________________________________________
>>  > dispatch mailing list
>>  > dispatch@ietf.org
>>  > https://www.ietf.org/mailman/listinfo/dispatch
>>  > _______________________________________________
>>  > dispatch mailing list
>>  > dispatch@ietf.org
>>  > https://www.ietf.org/mailman/listinfo/dispatch
>>  _______________________________________________
>>  dispatch mailing list
>>  dispatch@ietf.org
>>  https://www.ietf.org/mailman/listinfo/dispatch
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>