IETF Logo Mail Archive

Re: [radext] Extended IDs

Peter Deacon <peterd@iea-software.com> Wed, 13 December 2017 01:41 UTC

Return-Path: <peterd@iea-software.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C83126CBF for <radext@ietfa.amsl.com>; Tue, 12 Dec 2017 17:41:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 zf5PxHAYd9Yl for <radext@ietfa.amsl.com>; Tue, 12 Dec 2017 17:41:49 -0800 (PST)
Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id 87AEE120727 for <radext@ietf.org>; Tue, 12 Dec 2017 17:41:49 -0800 (PST)
Received: from smurf (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id <B0006062029@aspen.iea-software.com>; Tue, 12 Dec 2017 17:41:49 -0800
Date: Tue, 12 Dec 2017 17:41:52 -0800
From: Peter Deacon <peterd@iea-software.com>
To: "Naiming Shen (naiming)" <naiming@cisco.com>
cc: "radext@ietf.org" <radext@ietf.org>
In-Reply-To: <EE3BB1A7-EAD9-4BE1-9EA2-B780580E5C95@cisco.com>
Message-ID: <alpine.WNT.2.21.1.1712121704430.2252@smurf>
References: <fef698a5-9802-c9be-04d7-1e869651c988@restena.lu> <dfd0ff02-c9e8-7253-4fb4-1e6def3e93b2@restena.lu> <933E6F70-A7C1-4168-9AC9-F925EF78D9E2@jisc.ac.uk> <AE2036D0-1294-45B5-A0D7-16F91E0B4248@cisco.com> <alpine.WNT.2.21.1.1712121615090.2252@smurf> <EE3BB1A7-EAD9-4BE1-9EA2-B780580E5C95@cisco.com>
User-Agent: Alpine 2.21.1 (WNT 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="-1014921081-9837-1513128124=:2252"
Content-ID: <alpine.WNT.2.21.1.1712121722230.2252@smurf>
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/zq01U0pb8mySwepb8LIwdlZS3wk>
Subject: Re: [radext] Extended IDs
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 13 Dec 2017 01:41:51 -0000

On Wed, 13 Dec 2017, Naiming Shen (naiming) wrote:

> then the Client which initiated this can detect the returned packets, 
> and terminate the extended-ID scheme. it’s up to the implementation to 
> detect this.

How specifically can this be achieved?  What is your proposal?  Risks? 
Implementation complexity?

> also I can not imaging the server-status will be returned to the Client 
> correctly in this case to ‘fool’ the Client the Proxy-A supports this 
> feature.

Does extended id draft support manual configuration?

The question on the table is not whether extended id is good or bad in a 
vacuum.  The question is which of the options is technically the better 
option on the merits.

regards,
Peter

v2.23.0 | Report a Bug | By Email