Re: [radext] Proposed new charter text

Peter Deacon <peterd@iea-software.com> Mon, 23 March 2015 23:03 UTC

Return-Path: <peterd@iea-software.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6C51A0155 for <radext@ietfa.amsl.com>; Mon, 23 Mar 2015 16:03:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ddvsGRs50Sf for <radext@ietfa.amsl.com>; Mon, 23 Mar 2015 16:03:36 -0700 (PDT)
Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id 42A2A1A0263 for <radext@ietf.org>; Mon, 23 Mar 2015 16:03:36 -0700 (PDT)
Received: from SMURF.peterd.ws (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id <B0005964496@aspen.iea-software.com>; Mon, 23 Mar 2015 16:03:36 -0700
Date: Mon, 23 Mar 2015 16:03:42 -0700
From: Peter Deacon <peterd@iea-software.com>
To: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <1A6EF1EA-3412-4AAA-9646-3FD18EC0C4E4@deployingradius.com>
Message-ID: <alpine.WNT.2.20.1.1503231554360.3600@SMURF>
References: <5502B836.5000100@restena.lu> <alpine.WNT.2.20.1.1503221133420.3600@SMURF> <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> <alpine.WNT.2.20.1.1503221518060.3600@SMURF> <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com> <alpine.WNT.2.20.1.1503221852040.3600@SMURF> <5FA970CC-2E05-4EFC-8AE6-840D334B28E4@deployingradius.com> <alpine.WNT.2.20.1.1503230923000.3600@SMURF> <1A6EF1EA-3412-4AAA-9646-3FD18EC0C4E4@deployingradius.com>
User-Agent: Alpine 2.20.1 (WNT 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="1059913119-7280-1427151822=:3600"
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/naWFxnneZy1-96141077zT7XiMQ>
Cc: radext@ietf.org
Subject: Re: [radext] Proposed new charter text
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2015 23:03:39 -0000

On Mon, 23 Mar 2015, Alan DeKok wrote:

>> No unfortunately this does not work across administrative domains as 
>> operators are able to affect operation of unrelated sessions belonging 
>> to other operators without the checks in place.  While all parties 
>> explicitly trust roaming infrastructure they may not necessarily trust 
>> each other.

>  i.e. what you’re saying is that there is a requirement for home server 
> A to NOT be allowed to disconnect users for home server B in a visited 
> network.  That is a *new* requirement, which doesn’t negate my comments 
> above.

I recommend effective means of isolation of administrative domains be 
explicitly required as part of any charter for this work item.

Even if many of details are left up to implementations there has to be a 
reasonable enabling means.  Without it I don't support the work item as 
resulting product would not be suitable for deployment.

regards,
Peter