Skip to main content

Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core
draft-ietf-netext-wifi-epc-eap-attributes-16

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=