[radext] Stephen Farrell's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT)

"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Wed, 14 September 2016 22:56 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: radext@ietf.org
Delivered-To: radext@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1D812B0D8; Wed, 14 Sep 2016 15:56:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.33.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147389377247.29884.8510043117785245776.idtracker@ietfa.amsl.com>
Date: Wed, 14 Sep 2016 15:56:12 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/wRi6wlSqkl9PGKZy4TvyQseuXaA>
Cc: draft-ietf-radext-ip-port-radius-ext@ietf.org, lionel.morand@orange.com, radext-chairs@ietf.org, radext@ietf.org
Subject: [radext] Stephen Farrell's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT)
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.17
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, 14 Sep 2016 22:56:12 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-radext-ip-port-radius-ext-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


Sorry for not spotting this in other documents, but do we
understand the privacy characteristics of this ICMP
identifier? It may well be that the resolution of this
discuss requires some other document to exist (in which
case I'll get out of the way of this one) but I think we
ought be quite cautious in how we introduce  new functions
for identifiers that may be personally identifying, so I'd
like to chat about this a bit. Did the WG discuss the
privacy issues associated with this identifier?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- write-up: Yeah, major yuks to leaving design decisions
to IANA.  While the folks there are quite capable, they
are not able to make IETF consensus decisions.  If the WG
aren't sure, ask IANA personnel (or someone) and then
verify that that outcome garners rough consensus back in
the WG or using other IETF processes. So Alissa's discuss
point#4 is entirely, completely and fully correct and
a showstopper really.

- I also agree with the issue called out in Joel's comment
about mission creep and how this overlaps with PCP. Did
the WG consider whether or not it is a good idea for the
IETF to define multiple ways in which some of these
features can be added? If so, what is the justification
for there being more than one? (Is that somewhere in the
WG list archive? If not, it ought be.) It may well be that
having a RADIUS mechanism for this is also a good plan,
but I think that ought be justified.

- 4.1.4: using port 80 as an example is very 1990's. Would
it not be better to be more up to date? That's not just a
facetious point - web cameras being left open to the
Internet are a major swamp for botnet gestation. Better to
use a more desirable example really.

- The secdir review [1] also noted a bunch of issues that
as far as I can see received no response so far, but that
do deserve a response. (Apologies if I missed a response.)

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06736.html