Re: [e2md] RFC 5507 & RFC 5395
Jim Reid <jim@rfc1035.com> Mon, 17 May 2010 11:51 UTC
Return-Path: <jim@rfc1035.com>
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 4AEB728C16A for <e2md@core3.amsl.com>; Mon, 17 May 2010 04:51:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.098
X-Spam-Level:
X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_50=0.001]
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 lj1Lz-NXi04V for <e2md@core3.amsl.com>; Mon, 17 May 2010 04:51:03 -0700 (PDT)
Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id B32903A6847 for <e2md@ietf.org>; Mon, 17 May 2010 04:44:41 -0700 (PDT)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 175DB1542837; Mon, 17 May 2010 12:44:31 +0100 (BST)
Message-Id: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com>
From: Jim Reid <jim@rfc1035.com>
To: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
In-Reply-To: <alpine.DEB.2.00.1005161433580.31324@softronics.hoeneisen.ch>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 17 May 2010 12:44:30 +0100
References: <alpine.DEB.2.00.1005161433580.31324@softronics.hoeneisen.ch>
X-Mailer: Apple Mail (2.936)
Cc: "E.164 To MetaData BOF discussion list" <e2md@ietf.org>
Subject: Re: [e2md] RFC 5507 & RFC 5395
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, 17 May 2010 11:51:04 -0000
On 16 May 2010, at 13:35, Bernie Hoeneisen wrote: > To address the various objections I recommend everyone to read at > least the former (RFC 5507), as it explains quite some arguments > grey-beards and others have expressed before and during the BoF. Bernie, while these links are useful they don't really help us make progress. In the context of the discussion on this list RFC5507 pretty much says there are two choices open to us: a new RRtype or a new subtype of an existing RRtype (=> NAPTR). If it's the latter, careful attention to the size of the returned RRset is necessary. This is not news. So we're still running around in circles. Without clear use cases and/ or requirements, it's not possible to decide which of the two approaches above makes more sense. I am frustrated and disappointed that this information is still to be presented here (other than in vague anecdotal terms). It's pointless to continue a technical discussion unless there is an generally accepted problem statement. With that in mind, I make the following suggestion. Could whoever is in charge of this BOF ask those who have use cases and requirements to submit them and set a deadline for that input? If nothing is forthcoming, then there isn't a problem to work on and we can all go home. And if we get that info, there would at least be a basis for a problem statement that could then be analysed and perhaps worked on.
- [e2md] RFC 5507 & RFC 5395 Bernie Hoeneisen
- Re: [e2md] RFC 5507 & RFC 5395 Jim Reid
- [e2md] Problem statement, Requirements and Use Ca… Bernie Hoeneisen
- Re: [e2md] Problem statement, Requirements and Us… PFAUTZ, PENN L (ATTCORP)
- Re: [e2md] Problem statement, Requirements and Us… Ray Bellis
- Re: [e2md] Problem statement, Requirements and Us… Dean Willis
- Re: [e2md] Problem statement, Requirements and Us… PFAUTZ, PENN L (ATTCORP)
- [e2md] the RFC5935 process Jim Reid
- Re: [e2md] Problem statement, Requirements and Us… Dean Willis
- Re: [e2md] the RFC5935 process Ray Bellis
- Re: [e2md] Problem statement, Requirements and Us… Cartwright, Kenneth
- Re: [e2md] Problem statement, Requirements and Us… Richard Shockey
- [e2md] Problem statement, Requirements and Use Ca… PFAUTZ, PENN L (ATTCORP)
- Re: [e2md] Problem statement, Requirements and Us… Tony Rutkowski
- Re: [e2md] Problem statement, Requirements and Us… PFAUTZ, PENN L (ATTCORP)
- Re: [e2md] Problem statement, Requirements and Us… Tony Rutkowski
- Re: [e2md] Problem statement, Requirements and Us… Cartwright, Kenneth
- Re: [e2md] Problem statement, Requirements and Us… Cartwright, Kenneth
- Re: [e2md] Problem statement, Requirements and Us… Tony Rutkowski
- Re: [e2md] Problem statement, Requirements and Us… PFAUTZ, PENN L (ATTCORP)
- Re: [e2md] Problem statement, Requirements and Us… Tony Rutkowski
- Re: [e2md] Problem statement, Requirements and Us… Sumanth Channabasappa
- Re: [e2md] Problem statement, Requirements and Us… Richard Shockey
- Re: [e2md] Problem statement, Requirements and Us… Cartwright, Kenneth
- [e2md] Shall we go this way? (was Re: Problem sta… Bernie Hoeneisen
- Re: [e2md] Shall we go this way? (was Re: Problem… Dave CROCKER