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

[<[e-mail]>]

Dear Stephen, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Stephen Farrell [mailto:[e-mail]]
> Envoyé : jeudi 15 septembre 2016 00:56
> À : The IESG
> Cc : [e-mail]; [e-mail];
> [e-mail]; MORAND Lionel IMT/OLN; [e-mail]
> Objet : Stephen Farrell's Discuss on draft-ietf-radext-ip-port-radius-ext-
> 11: (with DISCUSS and COMMENT)
> 
> 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?
> 

[Med] As a side effect of processing other comments, we don't have any more such identifier in the new revision of the draft. The point raised in this DISCUSS is not valid anymore. 

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

[Med] Will skip those as those are discussed in other threads.

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

[Med] A reply is available now at: https://www.ietf.org/mail-archive/web/secdir/current/msg06846.html