This is a follow-up to my earlier IoT directorate review.  In that review I raised four issues:

1. Proper illustration of EMSK key derivation (this is somewhat optional)
2. Terminology alignment
3. MTU issues
4. A difference between how EAP is used (e.g., without IP connectivity) and this work.

All four points have (mostly) been addressed, although I have comments on the last one.  There is a
key deployment aspect missing that I would suggest the WG consider:

When dealing with EAP at the 802.1X layer, since the device doesn't have an IP address, in effect
from the application point of view, and even at certain kernel layers, the interface is down.  That
means that no address has been assigned, and from the network edge standpoint, no IEEE 802.1q VLANs assigned either.

One complication that remains is this: if the network enables access based on VLAN assignments, then
the L3 address may need to change.  Upper layers in the client need to be prepared for that, and address plans may need to take it into account.  I suggest that some operational cautions be added to address
these points.

In addition, and without going into a whole lot of detail, if this method is being made use of by a mesh
network for permitting access, it must be clear how both admission and removal are handled; or an
applicability statement should be added that until someone does that work, this document should not be
recommended for such networks.