[dispatch] Draft charter for domain registration work

"Elwell, John" <john.elwell@siemens-enterprise.com> Wed, 04 November 2009 13:57 UTC

Return-Path: <john.elwell@siemens-enterprise.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 5918C3A68F1 for <dispatch@core3.amsl.com>; Wed, 4 Nov 2009 05:57:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.079
X-Spam-Level:
X-Spam-Status: No, score=-6.079 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 AeIlMAgeihAg for <dispatch@core3.amsl.com>; Wed, 4 Nov 2009 05:57:13 -0800 (PST)
Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 1BB343A68E2 for <dispatch@ietf.org>; Wed, 4 Nov 2009 05:57:12 -0800 (PST)
Received: from mail3.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id nA4DvW6o026914 for <dispatch@ietf.org>; Wed, 4 Nov 2009 14:57:32 +0100
Received: from DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nA4DvWUv012678 for <dispatch@ietf.org>; Wed, 4 Nov 2009 14:57:32 +0100
Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.3.83]) by DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) with mapi; Wed, 4 Nov 2009 14:57:31 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: "dispatch@ietf.org" <dispatch@ietf.org>
Date: Wed, 04 Nov 2009 14:57:31 +0100
Thread-Topic: Draft charter for domain registration work
Thread-Index: AcpdVsB1/PYZJl+nREaLZTuG1cswWQ==
Message-ID: <7402509E63C5A145A6095D46C179A5B7058468FC4B@DEMCHP99E35MSX.ww902.siemens.net>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [dispatch] Draft charter for domain registration work
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: Wed, 04 Nov 2009 13:57:14 -0000

Below is an initial proposal for chartering this work:

John


Domain REGistration for SIP (DREGS)

Description of Working Group

The Domain REGistration for SIP (DREGS) working group is chartered to specify a means by which an entity authoritative for SIP URIs in a given domain can dynamically register reachability information for that domain with another domain.
The SIP protocol [RFC 3261 and its extensions] supports multiple means of obtaining the connection information necessary to deliver out-of-dialog SIP requests to their intended targets.  When a SIP Proxy needs to send a request to a target address-of-record (AoR) within its domain, it can use a location service to obtain the registered contact URI, together with any associated path information [RFC 3327], and build a route set to reach the target UA(s).  The SIP REGISTER method can be used to register contact URIs and path information. SIP-outbound [RFC 5626] enhances this mechanism to cater for UAs behind NATs and firewalls. When a SIP UA or Proxy needs to send a request to a target for which it is not authoritative, the UA/Proxy can use RFC3263 procedures for using DNS to resolve the next-hop connection information.
It is not uncommon, however, to use a dynamic registration mechanism to provide reachability information from a first domain to a second domain, to enable the second domain to deliver out-of-dialog requests targeted at the first domain. A typical example is a SIP-PBX in a small/medium business that needs to be reachable from a SIP Service Provider (SSP). Even if the SIP-PBX has its own domain name, it is expected that in most situations this will be a sub-domain of the service provider's domain name.  However, not every service provider wishes to maintain DNS infrastructure supporting dynamic registration, and not all SIP-PBXs support a dynamic DNS client. Furthermore, typical SSP deployments are such that a SIP proxy has to be traversed in order reach the SIP-PBX, and DNS does not provide a means of discovering this.
On the other hand, because a single SSP may support multiple thousands of such SMB SIP-PBX's, it is impractical and cost-prohibitive to manually provision their IP addresses in every SIP node along paths to those SIP-PBXs.  Furthermore, IP addresses can be dynamically assigned and therefore can potentially change relatively frequently.

In practice, a dynamic reachability mechanism is used, based on the SIP REGISTER method. Effectively a single REGISTER request registers the domain of the SIP-PBX, so that any out-of-dialog request targeted at a SIP URI in the SIP-PBX's domain can be delivered from the SSP to the SIP-PBX. However, implementations of this mechanism vary in details, leading to interoperability issues between SIP-PBXs and SSPs, and the need for equipment to support different variants.

The task of this working group is therefore to standardize a domain registration mechanism for SIP, based on the REGISTER method. The solution will utilize existing SIP mechanisms to the extent possible, although it is anticipated that small protocol extensions are likely to be required, and hence a standards track (rather than BCP) deliverable is expected. The solution will accommodate existing SIP extensions relating to registration (e.g., Path, Service-Route [RFC 3608] and SIP-outbound) by ensuring that they are not precluded from use in the context of domain registration, if they are deemed relevant. The solution will incorporate a compatibility mechanism to ensure a deterministic outcome when interworking with entities that do not support domain registration.

Goals and Milestones
Jan 2010	Domain registration specification WGLC
Feb 2010	Domain registration specification to IESG (PS)