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

Ben Campbell <ben@nostrum.com> Mon, 20 August 2018 21:45 UTC

Return-Path: <ben@nostrum.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 055A9129619; Mon, 20 Aug 2018 14:45:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 oBKKDYEcvu3f; Mon, 20 Aug 2018 14:45:30 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CA4F128BAC; Mon, 20 Aug 2018 14:45:30 -0700 (PDT)
Received: from [10.0.1.95] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7KLjKwB047500 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 20 Aug 2018 16:45:23 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.95]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <A2FC945F-7277-4824-BAB1-2A4319E18C60@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_896EAB4A-F625-4752-AC28-6144463CAF85"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 20 Aug 2018 16:45:19 -0500
In-Reply-To: <78BEFFD7-2B87-4EC1-A1A3-8BDD7AB97C5F@freeradius.org>
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: Alan DeKok <aland@freeradius.org>
References: <153436290915.3118.1227345371925581329.idtracker@ietfa.amsl.com> <78BEFFD7-2B87-4EC1-A1A3-8BDD7AB97C5F@freeradius.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/7MXKCNpGOswpHiJEMtYOivUlcmE>
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:45:32 -0000

Oops, I failed to scroll down when reading this the first time. I have one comment on a comment:

> On Aug 15, 2018, at 8:14 PM, Alan DeKok <aland@freeradius.org> wrote:
> 
>> §3.1 and §3,3: Do the normative changes to Access-Request and
>> Accounting-Request mean that this draft needs to update documents other than
>> just RFC 5176?
> 
>  The document does not provide for normative changes to Access-Request or Accounting-Request packets.  As with other RFCs that define new RADIUS attributes (e.g. 5580), it does not update RFC 2865 or 2866.


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.

Thanks,

Ben.