IETF Logo Mail Archive

Re: [Dime] Avi Lior Review of draft-ietf-dime-extended-naptr-02

jouni korhonen <jouni.nospam@gmail.com> Tue, 05 October 2010 09:08 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E10C3A6EFF for <dime@core3.amsl.com>; Tue, 5 Oct 2010 02:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.373
X-Spam-Level:
X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 1f6QdR02ahoa for <dime@core3.amsl.com>; Tue, 5 Oct 2010 02:08:45 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id DBC3B3A6EF1 for <dime@ietf.org>; Tue, 5 Oct 2010 02:08:44 -0700 (PDT)
Received: by fxm6 with SMTP id 6so4197850fxm.31 for <dime@ietf.org>; Tue, 05 Oct 2010 02:09:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=qQ8nkmtVgIYbt3ZL/+/PDgKlGApNAH2G+dk0qlwRrD0=; b=i/W9yMGblIo7CTW3j3vPRu1uXsp1NvhTxqaOceXmKjhi+7Ad2/WAjjv5fb1H2nMSdc o33xzdEJUk/Ep6t7L52eloP78rp0L66dPbJ1DhqP7v+fY6VjwSFleo8kxJeF0bIyLet5 q49PBOCiF5HS3CpIBL93ZXzjSufTvZuT1TP6A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=TCzR/ijerODGjUYT99T647BxauvtI2LozZTkWtGHzKmdZSvx6/SR9O8m2bot/ukM/S +KFEc+cJ6QMRJM6AxxaWWq3LPIsFR1EUlSNLzLjugTEc4ProlQvNma2DUc/ugnl0kI88 ymUnDqYn2XHFeYkOZsv9kxCMjO/P184nzpeqo=
Received: by 10.223.111.70 with SMTP id r6mr10125431fap.92.1286269781336; Tue, 05 Oct 2010 02:09:41 -0700 (PDT)
Received: from [10.254.0.48] ([192.100.123.77]) by mx.google.com with ESMTPS id b36sm2744948faq.11.2010.10.05.02.09.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 Oct 2010 02:09:40 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="windows-1252"
From: jouni korhonen <jouni.nospam@gmail.com>
In-Reply-To: <80E8ADA3-C07F-4F24-AE69-FDC4EEFC89A2@bridgewatersystems.com>
Date: Tue, 05 Oct 2010 12:09:35 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <A01DD1F8-E1EF-40E8-80BB-DC4F093027D0@gmail.com>
References: <B4B762B06D90774E9E8016C89B66AF87589A5240@m679t05.fpmis.bridgewatersys.com> <94FE4DE4-BF0F-4EC9-A721-50DF8F5D778B@bridgewatersystems.com> <AANLkTik9gZBNrkietPJujahOK-xBLXsBBpByfkMS0tak@mail.gmail.com> <4740121D-55DC-4D7F-AB5D-1D1DA7B8A86C@bridgewatersystems.com> <AANLkTimC-OMm2JmMFkUA1UQJxfL=X73nH2dfr8SC-T+9@mail.gmail.com> <80E8ADA3-C07F-4F24-AE69-FDC4EEFC89A2@bridgewatersystems.com>
To: Avi Lior <avi@bridgewatersystems.com>
X-Mailer: Apple Mail (2.1078)
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] Avi Lior Review of draft-ietf-dime-extended-naptr-02
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Oct 2010 09:08:46 -0000

Hi Avi,

First, thanks for thorough review comments. Some points below.

On Oct 4, 2010, at 7:40 PM, Avi Lior wrote:

> I realize that the issue I am raising is not really with your draft.  Perhaps Dime should liaise with DNS to change this matter.

We did liaise to some extent already.. and that lead to this RFC3958 stuff. But yes, I'll look into this (as in a Dime chair mode)

> 
> After all, Dime relaxed SDO requirements for their Diameter Applications and if NAPTR  is going to be used by SDO they will have to write an RFC (sure any old RFC but an RFC nevertheless).  Seems to be that the IETF/IESG should address this issue.
> 
> Unless of course we think that NAPTR will hardly ever be used.  Perhaps you can weigh in on how popular NAPTR will be.

That is a good question. As far as I know, at least one external body has already put a reference to extended NAPTRs into their own specifications.

- Jouni



> 
> 
> On 04-10-2010, at 10:38 , Mark Jones wrote:
> 
>> See inline.
>> 
>> On Sat, Oct 2, 2010 at 4:48 PM, Avi Lior <avi@bridgewatersystems.com> wrote:
>> <snip>
>>>>> Specifically if I have a vendor specific application id and I want to use this scheme now I have to write an RFC?
>>>>> 
>>>> 
>>>> Yes but the S-NAPTR allocation policy allows an RFC “of any category”
>>>> (not standards track) so this should not present a major impediment to
>>>> vendors/SDOs that require this optimization.
>>> 
>>> Okay.  Doesnt scale well at all.
>> 
>> We presented the alternatives at IETF77 and this was the favoured
>> approach despite the additional specification effort for a non-IETF
>> SDO. It is the price to be paid for reusing an existing S-NAPTR
>> registry that does not have a "First Come; First Served" allocation
>> policy. A small consolation is that the IANA allocation policy for
>> S-NATPR service tags is not as strict as that originally used for
>> vendor-specific Diameter command codes ("Specification Required in
>> form of an RFC" vs "IETF Consensus").
>> 
>> Regards
>> Mark
> 
> Avi Lior
> avi@bridgewatersystems.com
> office: +1 613-591-9104x6417
>    cell: +1 613-796-4183
> 
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime

v2.46.0 | Report a Bug | By Email | System Status