Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core
RFC 7458
Yes
(Brian Haberman)
No Objection
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)
Note: This ballot was opened for revision 09 and is now closed.
Brian Haberman Former IESG member
Yes
Yes
(for -09)
Unknown
Adrian Farrel Former IESG member
(was Discuss)
No Objection
No Objection
(2014-09-15 for -12)
Unknown
Thanks for handling IANA's concerns.
Alissa Cooper Former IESG member
(was Discuss)
No Objection
No Objection
(2014-12-22 for -15)
Unknown
Thanks for addressing my DISCUSS.
Barry Leiba Former IESG member
(was Discuss)
No Objection
No Objection
(2014-09-23 for -12)
Unknown
[Clearing the DISCUSS about the normative references; thanks for fixing that in vesion -12. My non-blocking comments remain. They are non-blocking, but I think they really should be fixed, and fixing them should be very easy.] -- Section 2 -- The section title seems to be from an old version; please fix it. Section 2 has nothing to do with reference architecture. -- Section 5.2 -- In turn, the network provides what is supported. Do you mean to say, "provides a list of what is supported." ? Or what? I can't understand this sentence. -- Section 7 -- A specification would be required to request assignments from this registry; see [RFC5226]. The usual way to specify a well known registration policy from 5226 is to use its capitalized name exactly. I'd prefer to see that: NEW New assignments in this registry are made with the Specification Required policy [RFC5226]. END
Jari Arkko Former IESG member
No Objection
No Objection
(for -11)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -11)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-08-07 for -11)
Unknown
Thank you for addressing the SecDir review and adding text in the Security Considerations section on the concern described. https://www.ietf.org/mail-archive/web/secdir/current/msg04911.html
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -09)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -11)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2014-12-31 for -15)
Unknown
Thanks for addressing my discuss points and sorry for the delay in clearing - it took me a while to grok the various bits and pieces so as to be happy that your slightly shorthand way of describing how the IMEI is protected is ok. I'm now happy it's ok though so thanks again for bearing with me. (Took me a while e.g. to check if the ciphertext emitted could be the same or not but I think that's ok as IVs need to be random.) That said. I still hate the (ab)use of the word "trusted" here. If you could get rid of it, and you could, this would be a better document. There is no need for RFCs to use the same marketing jargon as other bodies or vendors and we're better off when we do not. While it's very late to add a new comment, I just noticed that the document doesn't actually include the word privacy at all. And I think that's a pity. (I did call this out as part of my discuss point 2 but mostly that was about the encryption part and that latter is what we discussed;-) Anyway, I think adding a sentence along these lines to the security considerations would be good: "Note that sending identifiers like the IMEI to networks can have significant privacy implications, allowing users to be unexpectedly tracked for example. Implementers ought consider those privacy issues and where possible attempt to mitigate them. See [refs] for some of the issues involved." And where [refs] could be a set of 2-3 references that you consider useful from [1] which looks like it has some good enough papers. [1] http://scholar.google.com/scholar?hl=en&q=imei+privacy&btnG=&as_sdt=1%2C5&as_sdtp=