Re: [e2md] Draft charter, comments inline <dw>

Otmar Lendl <lendl@nic.at> Mon, 08 March 2010 09:48 UTC

Return-Path: <lendl@nic.at>
X-Original-To: e2md@core3.amsl.com
Delivered-To: e2md@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C763A682A for <e2md@core3.amsl.com>; Mon, 8 Mar 2010 01:48:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.28
X-Spam-Level:
X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1]
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 ZgqtGxf0-E7s for <e2md@core3.amsl.com>; Mon, 8 Mar 2010 01:48:30 -0800 (PST)
Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 8DEFC3A6804 for <e2md@ietf.org>; Mon, 8 Mar 2010 01:48:26 -0800 (PST)
Received: from [10.10.0.242] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id 098CC4C534 for <e2md@ietf.org>; Mon, 8 Mar 2010 10:48:29 +0100 (CET)
Message-ID: <4B94C7ED.20108@nic.at>
Date: Mon, 08 Mar 2010 10:48:29 +0100
From: Otmar Lendl <lendl@nic.at>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: e2md@ietf.org
References: <6D332FF8-7815-423F-94ED-52293A13CDEC@softarmor.com> <000001cabd6c$3389ffc0$9a9dff40$@us> <alpine.DEB.2.00.1003062312110.28763@softronics.hoeneisen.ch> <00b601cabe15$a585cb00$f0916100$@us> <34B1E314-CCF3-4FA8-996D-682BC3200D5C@nzrs.net.nz>
In-Reply-To: <34B1E314-CCF3-4FA8-996D-682BC3200D5C@nzrs.net.nz>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [e2md] Draft charter, comments inline <dw>
X-BeenThere: e2md@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" <e2md.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/e2md>, <mailto:e2md-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/e2md>
List-Post: <mailto:e2md@ietf.org>
List-Help: <mailto:e2md-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/e2md>, <mailto:e2md-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Mar 2010 09:48:32 -0000

A few comments from my side:

On 07.03.2010 22:35, Jay Daley wrote:
> 
> 1.  Creating a new DDDS is not difficult and both far more appropriate
> and deliverable than a new RR.  

Yes. See e.g.
http://tools.ietf.org/id/draft-lendl-domain-policy-ddds-02.txt where I key
off the domain and not ENUM-like on the E.164.

> In fact a new RR would be quite wrong
> for this.  We have NAPTR and have to stick with until someone, anyone
> please, comes up with a complete replacement.

Well, you can either go with an ENUM clone, or you might want to restrict
what features of the NAPTR you actually want to use, e.g.

* non-terminals
* RE parsing

I don't have the reference handy, but under the name S-NAPTR something a
bit more lightweight has already been proposed. This is still the same
NAPTR RR on the wire, just the interpretation changed a bit.

> 2.  The privacy issues are out of scope for this group to try to solve
> and are identical to those that come with ENUM, where they have been
> adequately addressed in the CNAM draft.

Yes and no. In terms of PII, yes.

But if you talk about SPIDs and call routing, I have the nagging feeling
that a lot of folks here and in other IETF lists miss the fact that once
you consider multi-homed corporate PBXs and want to do fully featured call
routing from/to them, then the global E.164->SPID mapping data must
de-facto be public.

There just is no way around that.

otmar
-- 
// Otmar Lendl <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 //