Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01

Stefan Winter <stefan.winter@restena.lu> Fri, 13 August 2010 09:16 UTC

Return-Path: <stefan.winter@restena.lu>
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 2E9783A68BC for <dime@core3.amsl.com>; Fri, 13 Aug 2010 02:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.297
X-Spam-Level:
X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 IiQeNgViL5tq for <dime@core3.amsl.com>; Fri, 13 Aug 2010 02:16:39 -0700 (PDT)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by core3.amsl.com (Postfix) with ESMTP id C7B643A685E for <dime@ietf.org>; Fri, 13 Aug 2010 02:16:38 -0700 (PDT)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 7B78F10598 for <dime@ietf.org>; Fri, 13 Aug 2010 11:17:15 +0200 (CEST)
Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 6F6E710586 for <dime@ietf.org>; Fri, 13 Aug 2010 11:17:15 +0200 (CEST)
Message-ID: <4C650D9B.1000503@restena.lu>
Date: Fri, 13 Aug 2010 11:17:15 +0200
From: Stefan Winter <stefan.winter@restena.lu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2
MIME-Version: 1.0
To: dime@ietf.org
References: <A0A5F8D2-62B7-40BF-A9C2-8ED231D6323E@gmail.com><4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net><4C5A6DA9.30309@nict.go.jp> <003201cb347a$0fb844a0$2f28cde0$@net> <4C5B65DB.3040006@nict.go.jp> <D109C8C97C15294495117745780657AE0CBB2CB1@ftrdmel1>
In-Reply-To: <D109C8C97C15294495117745780657AE0CBB2CB1@ftrdmel1>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV
Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01
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: Fri, 13 Aug 2010 09:16:40 -0000

> I think that the idea is not to say that RADIUS/Diameter interworking is
> not possible at all. The idea is more about to acknowledge the fact that
> RFC 4005 can not remain the de-facto and the only reference for
> RADIUS/Diameter translation as this section is under specified and not
> applicable anyway to all RADIUS/Diameter interworking scenarios. As
> something has to be done, it is proposed to remove anything about
> RADIUS/Diameter translation from RFC 4005. The NASREQ application is
> self-consistent without this part.

That seems like a good reasoning.

So: I support adoption of this document.

Greetings,

Stefan Winter

>>> The problem is that apparently nobody has _ever_ transitioned from
>>> RADIUS to Diameter and it appears as if nobody ever will.
>> I am not so pessimistic about Diameter :)
>>
>>>    Regarding EDUROAM, Diameter
>>> existed long before EDUROAM but they chose to hack RADIUS
>> in their own way.
>>> In any case, if they decided to migrate to Diameter they
>> could use the
>>> pointless tunneling protocol, retiring their RADIUS server when the
>>> transition was complete.
>> You are implying that each domain can retire its RADIUS
>> server only when
>> *all* the domains have moved all their clients to Diameter...
>> This reasoning may be possible in a single-domain context,
>> but it does not hold in a multi-domain roaming consortium case.
> About roaming issues, I think that we should make the difference between
> inter-domain and intra-domain. If there exists a solution for
> RADIUS/Diameter interworking, each domain could rely on either RADIUS or
> Diameter, and the interworking solution would be applied *only* between
> AAA servers/proxies. In intra-domain, if a single AAA server can support
> both RADIUS and Diameter clients, the migration path is quite simple,
> no?
>
>> Best regards,
>> Sebastien.
>>
>> --
>> Sebastien Decugis
>> Research fellow
>> Network Architecture Group
>> NICT (nict.go.jp)
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473