IETF Logo Mail Archive

Re: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-06: (with DISCUSS and COMMENT)

Alan DeKok <aland@freeradius.org> Mon, 20 August 2018 21:50 UTC

Return-Path: <aland@freeradius.org>
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 8F02B128CF3; Mon, 20 Aug 2018 14:50:49 -0700 (PDT)
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 X33M-FQ6WT1Z; Mon, 20 Aug 2018 14:50:47 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1F11252B7; Mon, 20 Aug 2018 14:50:47 -0700 (PDT)
Received: from [192.168.46.58] (198-84-237-221.cpe.teksavvy.com [198.84.237.221]) by mail.networkradius.com (Postfix) with ESMTPSA id F33E13953; Mon, 20 Aug 2018 21:50:45 +0000 (UTC)
From: Alan DeKok <aland@freeradius.org>
Message-Id: <5B036BBE-CFF6-4311-8DDE-286FF6323B9E@freeradius.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_F109D5C2-4FE6-4B88-8BB0-D4F3F8983FA1"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 20 Aug 2018 17:50:42 -0400
In-Reply-To: <A2FC945F-7277-4824-BAB1-2A4319E18C60@nostrum.com>
Cc: Winter Stefan <stefan.winter@restena.lu>, radext@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org
To: Ben Campbell <ben@nostrum.com>
References: <153436290915.3118.1227345371925581329.idtracker@ietfa.amsl.com> <78BEFFD7-2B87-4EC1-A1A3-8BDD7AB97C5F@freeradius.org> <A2FC945F-7277-4824-BAB1-2A4319E18C60@nostrum.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/yHuZ24zb7_e9xwzQCXjTx-tffGA>
Subject: Re: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-06: (with DISCUSS and COMMENT)
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.27
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: Mon, 20 Aug 2018 21:50:50 -0000

> On Aug 20, 2018, at 5:45 PM, Ben Campbell <ben@nostrum.com> wrote:
> 
> Just to be clear, I was thinking about actual normative text, not just the adding of a new attribute. The first paragraph of §3.1 says:
> 
> " When a Visited Network proxies an Access-Request or Accounting-Request packet outside of its network, it SHOULD include an Operator-Name attribute in the packet, as discussed in Section 4.1 of[RFC5580]”
> 
> The SHOULD is a new normative requirement that relates to Access-Request of Accounting-Request. I can accept that we are talking about “proxies that implement this extension”, if that is the intent. But if the intent was that proxies in general SHOULD do this, that seems different.

  The intent was that the quoted sentence applied to implementations of this document.  Not to all RADIUS proxies, even if they didn't implement this spec.

  Alan DeKok.

v2.23.0 | Report a Bug | By Email