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

Benjamin Kaduk <> Wed, 15 August 2018 20:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D90C1310A6; Wed, 15 Aug 2018 13:01:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gcBnVwt-RpOH; Wed, 15 Aug 2018 13:01:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E745D131109; Wed, 15 Aug 2018 13:01:30 -0700 (PDT)
X-AuditID: 1209190d-1fdff700000016c8-a5-5b748699ab66
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 2A.E2.05832.996847B5; Wed, 15 Aug 2018 16:01:29 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id w7FK1RLm001972; Wed, 15 Aug 2018 16:01:28 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id w7FK1LT6021316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 15 Aug 2018 16:01:24 -0400
Date: Wed, 15 Aug 2018 15:01:21 -0500
From: Benjamin Kaduk <>
To: Alan DeKok <>
Cc: Ben Campbell <>,, Winter Stefan <>, The IESG <>,,
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMKsWRmVeSWpSXmKPExsUixCmqrDuzrSTa4GS3gcWZjdNYLOZ3nma3 mPfkKavFjD8TmS2ednxhsmh5NZPNYl5DI7sDu8eziZMZPZYs+cnkMWvnExaP5V0+ASxRXDYp qTmZZalF+nYJXBkPH11jL9gqWtE0/RJ7A2OPYBcjJ4eEgInEy30n2LsYuTiEBBYzSUyd/4MN wtnIKHHvxmcmCOcqk8Tqw3dYQFpYBFQlfn36yQhiswmoSDR0X2YGsUWA4tuWXAYbxSxwnFFi 17O5YA3CAjkSzWdXs4PYvED7/k4/DrXvM6PE0wO/GSESghInZz4Ba2AWUJf4M+8S0FQOIFta Yvk/DoiwvETz1tlgyzgFnCS2nDjDCmKLCihL7O07xD6BUXAWkkmzkEyahTBpFpJJCxhZVjHK puRW6eYmZuYUpybrFicn5uWlFuka6eVmluilppRuYgTHhyTvDsZ/d70OMQpwMCrx8D4wLIkW Yk0sK67MPcQoycGkJMqrX10cLcSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEV40PqJw3JbGyKrUo HyYlzcGiJM57ryY8WkggPbEkNTs1tSC1CCYrw8GhJMHLB0wDQoJFqempFWmZOSUIaSYOTpDh PEDDP7aCDC8uSMwtzkyHyJ9i1OX4837qJGYhlrz8vFQpcd55IEUCIEUZpXlwc0BpTSJ7f80r RnGgt4R5zUHW8QBTItykV0BLmICWJIsUgiwpSURISTUwnlFa6mCXGODnNjvH6cZUQa/mWQld yj+mfb/t73J+haWVq2/d456c2feWJ1QeV4g91Gr+evECxZYDDyWMuJ8mmxZ6zdDfNIl7/QOn HSZndp95WrtC5FHSzv4Z0w7NMLM1q3f/fdtkjcH0gybsWjqf1WxXaKydtJxlS9CenIZ9X6bm pp8yiP3Ur8RSnJFoqMVcVJwIAKzq3jZGAwAA
Archived-At: <>
Subject: Re: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Aug 2018 20:01:39 -0000

On Wed, Aug 15, 2018 at 11:24:20AM -0400, Alan DeKok wrote:
> On Aug 15, 2018, at 10:46 AM, Ben Campbell <> wrote:
> > Yes, but as you allude to below, this document depends on 5176. Given that it is an extension to 5176,  I’d say that it effectively incorporates 5176 by reference.
>   Which means what?  That this document is really part of 5176, and that the caveats given in Section 1.1 should be applied, even though they don't apply to this document?
>   I'm not sure I follow that logic.  "IF A then B" means that if A is false, then B is also false.
> >> Can we have a standards track document which depends on an informational document?
> > 
> > There’s the problem. According to RFC 2026, we cannot. The IESG can make exceptions under specific circumstances (see RFCs 3967 and 4897). The point of my DISCUSS is to force discussion of whether it is appropriate to make an exception for this draft.
>   We already have RFC 5080 (proposed standard) which updates RFC 2866 (informational).
>   Even more strongly, RFC 5080 points out errors in both the spec *and* in implementations.
>   Which means that RFC 5080 took the opposite decision of 5176.  It marked existing implementations as non-compliant.  The reasons for that decision are historical.
> > My initial thoughts is that it is not appropriate to do so. This draft is a relatively small extension to 5176. It might be different if this draft incidentally depended on 5176, but in this case the informational RFC is the entire foundation of this draft.
> > 
> > If it’s important to make this draft standards track, then we should look into promoting 5176 to standards track.
>   Along with RFC 2866 (RADIUS accounting), RFC 2867, RFC 2868, RC 5997, RFC 6613 (TCP transport), RFC 6614 (TLS transport), and RFC 7360 (DTLS transport).  And probably more.  All of those documents are informational.  There have been discussions over the years about making them all standards track.
>   However, the sad truth is that the RADIUS WG is essentially dead at this point.  There is little interest in revisiting 20 year-old specs, just to have them promoted to standards track.  And even if they were made standards track, the consensus has been that little of the content would change.
>   As for this document, the WG was in favour of making it standards track, and it had support from the previous AD.  Exceptions have been made in the past in similar circumstances.
>   I'm arguing this point simply because I'm not convinced by the counter-arguments.

Ultimately this is a decision for the IESG to make; it's seeming like we'll
need to have a conversation on tomorrow's telechat.