Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core
RFC 7458

Note: This ballot was opened for revision 09 and is now closed.

(Brian Haberman) Yes

(Jari Arkko) No Objection

Alissa Cooper (was Discuss) No Objection

Comment (2014-12-22 for -15)
No email
send info
Thanks for addressing my DISCUSS.

(Spencer Dawkins) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2014-09-15 for -12)
No email
send info
Thanks for handling IANA's concerns.

(Stephen Farrell) (was Discuss) No Objection

Comment (2014-12-31 for -15)
No email
send info
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=

(Joel Jaeggli) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2014-09-23 for -12)
No email
send info
[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

(Kathleen Moriarty) No Objection

Comment (2014-08-07 for -11)
No email
send info
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) No Objection