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

Ben Campbell <ben@nostrum.com> Wed, 15 August 2018 14:46 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 D6B03130F7F; Wed, 15 Aug 2018 07:46:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 l7Uo_CVnj3eH; Wed, 15 Aug 2018 07:46:44 -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 D8AC4130E42; Wed, 15 Aug 2018 07:46:43 -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 w7FEkcg7080133 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 15 Aug 2018 09:46:39 -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: <22938F82-F957-4356-AC12-5DECE2926260@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_30DEA916-08CB-40B9-8D81-DD911D1B1E66"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 15 Aug 2018 09:46:37 -0500
In-Reply-To: <4D83C0DB-8A53-408D-9CDE-D4B11D27DD30@freeradius.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-radext-coa-proxy@ietf.org, Winter Stefan <stefan.winter@restena.lu>, radext-chairs@ietf.org, radext@ietf.org
To: Alan DeKok <aland@freeradius.org>
References: <153430309790.27225.13672171828804687460.idtracker@ietfa.amsl.com> <4D83C0DB-8A53-408D-9CDE-D4B11D27DD30@freeradius.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/2tvAqgzj88aBIyt0aNyeORUxPpY>
Subject: Re: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-05: (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: Wed, 15 Aug 2018 14:46:46 -0000


> On Aug 15, 2018, at 6:45 AM, Alan DeKok <aland@freeradius.org> wrote:
> 
> On Aug 14, 2018, at 11:18 PM, Ben Campbell <ben@nostrum.com> wrote:
>> This draft is standards track, yet it primarily serves to extend RFC 5176.
> 
>  By adding new capabilities which are not implemented anywhere.

Granted.

> 
>> That
>> RFC is informational. The shepherd writeup argues that this is okay because it
>> seems like 5176 should have been standards track. But the applicability
>> statement RFC 5176 explains why it was informational, and the reasons seem
>> convincing.
> 
>  Those reasons apply to RFC 5176.  They don't apply to this document.
> 

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.

>  Can we have a standards track document which defines *new* capabilities?  Capabilities which do not affect any existing implementation or deployment?

Sure, that defines many, if not most, standards track documents.

> 
>  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.

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.

Thanks,

Ben.

> 
>> Therefore I do not think it is appropriate to publish this draft as
>> Standards Track. I think it would be fine to progress it as Informational (or
>> even Experimental) if it included an applicability statement explaining why in
>> order to avoid the appearance of a standard masquerading as an Informational
>> RFC.
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> (My review is not yet complete; I wanted to get the DISUSS point out with as
>> much discussion time as possible. I expect to follow up with an update sometime
>> before the telechat.)
>> 
>> 
>