Re: [STDS-802-11-TGM] Minutes posted for Oct 12th Telecon
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
OK. I think we've worked it all out then. I'll summarize the final results, try to find wording for "EAPOL* frame", and we'll have to ask about "IEEE" on references to 802.*
As for "eap message", that is _not_ the same thing as EAPOL PDU. Eap messages are "higher-layer" and are sent to the AS (RADIUS) server. They are encapsulated in EAPOL PDUs, which we then carry as Data frames. I note that 802.11 only uses this term in the context of 802.11u, though. And, I think those uses are correct as-is.
"eap authentication frame" is not used in 802.1X, it's something 802.11 invented. I think it should be "eap message" in the one place I could find it (which was Jouni's proposal).
Mark
-----Original Message-----
From: Mark Rison [mailto:m.rison@xxxxxxxxxxx]
Sent: Sunday, October 28, 2012 9:29 PM
To: Hamilton, Mark; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGM] Minutes posted for Oct 12th Telecon
> > Say "all or part of" instead of "some or all"
> I can live with it either way. I'm just trying to avoid grammar
> niggles. It should really be "all of or part of", or you need commas
> to make it clear the "of" goes with both choices of the or ("all, or
> part, of")
I don't think so. There can be no ambiguity as "An 802.11 data MPDU which carries all." and "An 802.11 data MPDU which carries all an 802.1X EAPOL PDU." make no sense.
> and I find both to be obtuse to read. So, I avoid that phrasing.
> But, it is common and everyone knows what it means.
My grep of 802.11-2012 gives:
all or part of: 13
all of or part of: 0
all of, or part of: 0
all, or part, of: 0
["some or all" is used, but only in the context of choosing items from a set, rather than choosing a slice of an item.]
> So, fine, either way.
> > don't say "802.11" as this is implicit in 3.2
> This was just to be very clear that the data MPDU was 802.11, since
> the EAPOL PDU is explicitly 802.1X. It seemed unbalanced to have one
> explicit and the other not. Again, though, I can live either way.
It seems to me that 802.11 can always be assumed if something else is not mentioned (though I will bring a comment to D1.0 asking exactly when the "IEEE" is needed -- is there such a thing as "ETSI 802.1X" or something?).
> > Define four terms: ...
> Ugh. Maybe we have to, but this is getting unnecessarily wordy. I'd
> like to just define EAPOL* frame, if we can think a way to do that in one definition.
I'm fine with that too, if you can find suitable wording to do it.
> > ... 802.1X EAPOL PDU of type EAPOL-Key. ...
> 802.1X uses the phrase EAPOL-Key PDU, I think we can, too, and avoid
> the wordiness. (Likewise on the
> rest.)
Fine. As I said, adjust the "of type" and "Request bit" bits to use the correct 802.1X terminology.
> > ... 802.1X EAPOL PDU of type EAPOL-Key with the Request bit set.
> Since the request bit is an 802.11 invention, within our Key
> Descriptor format, maybe we want to say "EAPOL-Key PDU with the 802.11
> Key Descriptor's Key Information Request bit set to one". Kind of wordy, but it's pretty hard to find all the pieces, without help.
Ah, OK. I'm fine with this.
> > EAPOL-Key is just one of the possible flavours
> You are correct. So, you suggestions for re-wording this are better
> (including the follow-on e-mails attempting to fix that one).
> > Is "EAPOL PDU" defined somewhere?
> Yes, in 802.1X (clause 11). I tried to make that clear in the
> sentence in 4.2.5. Maybe we should repeat the reference here?
I think so. Currently there are 0 instances of "EAPOL PDU" and Jouni's proposal didn't introduce any either. And no-one actually
*reads* clause 4, do they?
[I'm a bit fuzzy on all this. An "EAPOL PDU" is not the same thing as an "EAP message" (née "EAP authentication frame"), right?]
Mark
--
Mark RISON, Systems Architect, Wi-Fi English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0ZT Fax: +44 1223 TBCTBC
ROYAUME UNI WWW: http://www.samsung.com/uk
> -----Original Message-----
> From: Hamilton, Mark [mailto:Mark.Hamilton@xxxxxxxxxxx]
> Sent: 29 October 2012 11:25
> To: m.rison@xxxxxxxxxxx; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
> Subject: RE: [STDS-802-11-TGM] Minutes posted for Oct 12th Telecon
>
> > Say "all or part of" instead of "some or all"
> I can live with it either way. I'm just trying to avoid grammar
> niggles. It should really be "all of or part of", or you need commas
> to make it clear the "of" goes with both choices of the or ("all, or
> part, of") and I find both to be obtuse to read. So, I avoid that phrasing. But, it is common and everyone knows what it means. So, fine, either way.
>
> > don't say "802.11" as this is implicit in 3.2
> This was just to be very clear that the data MPDU was 802.11, since
> the EAPOL PDU is explicitly 802.1X. It seemed unbalanced to have one
> explicit and the other not. Again, though, I can live either way.
>
> > Define four terms: ...
> Ugh. Maybe we have to, but this is getting unnecessarily wordy. I'd
> like to just define EAPOL* frame, if we can think a way to do that in one definition.
> > ... 802.1X EAPOL PDU of type EAPOL-Key. ...
> 802.1X uses the phrase EAPOL-Key PDU, I think we can, too, and avoid
> the wordiness. (Likewise on the
> rest.)
> > ... 802.1X EAPOL PDU of type EAPOL-Key with the Request bit set.
> Since the request bit is an 802.11 invention, within our Key
> Descriptor format, maybe we want to say "EAPOL-Key PDU with the 802.11
> Key Descriptor's Key Information Request bit set to one". Kind of wordy, but it's pretty hard to find all the pieces, without help.
>
> > EAPOL-Key is just one of the possible flavours
> You are correct. So, you suggestions for re-wording this are better
> (including the follow-on e-mails attempting to fix that one).
>
> > Is "EAPOL PDU" defined somewhere?
> Yes, in 802.1X (clause 11). I tried to make that clear in the
> sentence in 4.2.5. Maybe we should repeat the reference here?
>
> Mark
>
>
> -----Original Message-----
> From: Mark Rison [mailto:m.rison@xxxxxxxxxxx]
> Sent: Sunday, October 28, 2012 3:04 PM
> To: Hamilton, Mark; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
> Subject: RE: [STDS-802-11-TGM] Minutes posted for Oct 12th Telecon
>
> > Ok, so then the proposal is:
>
> My proposal differs as follows:
>
> > Add a definition in subclause 3.2, "EAPOL-Key frame: An 802.11 data
> > MPDU which carries some or all of an 802.1X EAPOL PDU."
>
> 1) Say "all or part of" instead of "some or all"; don't say "802.11"
> as this is implicit in 3.2
>
> 2) Define four terms: a) EAPOL frame, b) EAPOL-Key frame, c) EAPOL-Key
> request frame and d) EAPOL- Start frame, including the fact that b)
> and d) are types of a) and c) is a type of b)
>
> So something like:
>
> EAPOL frame: A Data frame which carries all or part of an 802.1X EAPOL PDU.
> EAPOL-Key frame: An EAPOL frame which carries all or part of an 802.1X EAPOL PDU of type EAPOL-Key.
> EAPOL-Key request frame: An EAPOL-Key frame which carries all or part
> of an 802.1X EAPOL PDU of type EAPOL-Key with the Request bit set.
> EAPOL-Start frame: An EAPOL frame which carries all or part of an
> 802.1X EAPOL PDU of type EAPOL- Start.
>
> > Add a sentence to the end of the second paragraph of subclause 4.2.5:
> > "Within 802.11, EAPOL PDUs are carried as MSDUs within one or more
> > data MDPUs, as described in 802.1X-2010, clause 11; data MPDUs used
> > for this purpose are known
> within this Standard as EAPOL-Key frames."
>
> 3) They're known generally as EAPOL frames (unless I'm forgetting that
> we countermanded Jouni's original suggested mappings in the teleconf
> last week); EAPOL-Key is just one of the possible flavours
>
> So something like:
>
> Within 802.11, EAPOL PDUs are carried as MSDUs within one or more Data
> frames, as described in 802.1X- 2010, clause 11; Data frames used for
> this purpose are known within this Standard as EAPOL frames (or more specifically as EAPOL-Key frames, EAPOL-Key request frames and EAPOL-Start frames).
>
> > Change the start of the sentence in 4.10.2, "IEEE 802.1X
> > authentication frames are transmitted in IEEE
> > 802.11 data frames ..." to "IEEE 802.1X EAPOL PDUs are transmitted
> > in IEEE 802.11 data MPDUs known as EAPOL-Key frames ..."
>
> 4) Again, EAPOL-Key is just one of the flavours
>
> So something like:
>
> IEEE 802.1X EAPOL PDUs are transmitted in IEEE 802.11 Data frames known as EAPOL-Key frames ...
>
> [I'm not entirely sure about the "IEEE"s. When is it necessary to say
> "IEEE 802.1X/802.11" and when is "802.1X/802.11" sufficient?]
>
> > In the table in subclause 6.3.22.1.2, change "EAPOL-Key frame" to "EAPOL PDU"
>
> 5) Is "EAPOL PDU" defined somewhere? I can't find it in 802.11-2012
> and it's not one of Jouni's remappings
>
> > P.S., I’m using the term “data MPDU” loosely here. Do we need to be
> > more careful, or given our other changes around “data” and “management” etc, is this okay?
>
> My understanding of what we agreed under CID 100 is that we're
> changing all "[Dd]ata MPDU"s and "data frame"s to "Data frame"s.
>
> Mark
>
> P.S.: FWIW here's a rough concordance of things starting with "EAPOL",
> excluding "EAPOL-Key(", "EAPOL(" (a bug which I'll report on D1.0 unless we agree to fix it now) and "EAPOLKeyReceived":
>
> 148 EAPOL-Key frame
> 80 EAPOL-Key frames
> 19 EAPOL-Key message
> 14 EAPOL-Key IV
> 8 EAPOL-Start message
> 7 EAPOL-Key encryption
> 7 EAPOL Key
> 6 EAPOL-Key receive
> 6 EAPOL temporal
> 6 EAPOL replay
> 5 EAPOL-Key Received
> 4 EAPOL-Key state
> 4 EAPOL-Key messages
> 4 EAPOL-Key confirmation
> 4 EAPOL-Key MIC
> 4 EAPOL-Key 1
> 4 EAPOL-Key 0
> 4 EAPOL state
> 4 EAPOL STKMesgNo=
> 4 EAPOL
> 3 EAPOL-Key request
> 3 EAPOL-Key 4-Way
> 3 EAPOL keys
> 2 EAPOL-Start Request/Identity
> 2 EAPOL-Key denotes
> 2 EAPOL-Key Message
> 2 EAPOL-Key Key
> 2 EAPOL---Key Key
> 2 EAPOL request
> 2 EAPOL or
> 2 EAPOL 0
> 2 EAPOL
> 1 EAPOL-Start packet
> 1 EAPOL-Start are
> 1 EAPOL-Start and
> 1 EAPOL-Key response
> 1 EAPOL-Key integrity
> 1 EAPOL-Key has
> 1 EAPOL-Key exchange
> 1 EAPOL-Key acknowledgment
> 1 EAPOL-Key Request
> 1 EAPOL-Key Frames
> 1 EAPOL-Key Data
> 1 EAPOL-Key 1,1,1,0,GNonce,0
> 1 EAPOL-Key 1,1,0,0,GNonce,0
> 1 EAPOL protocol
> 1 EAPOL messages
> 1 EAPOL frames
> 1 EAPOL SMKMesgNo=
> 1 EAPOL MIC
> 1 EAPOL Extensible
> 1 EAPOL EtherType
> 1 EAPOL 179
> 1 EAPOL 1,1,1
>
> and here is "EAP" (other than "EAPOL"):
>
> 56 EAP Method
> 26 EAP method
> 26 EAP Vendor
> 22 EAP Type
> 19 EAP authentication
> 10 EAP type
> 5 EAP methods
> 5 EAP Authentication
> 4 EAP Success
> 3 EAP peer
> 2 EAP-Response/Identity EAP
> 2 EAP to
> 2 EAP or
> 2 EAP messages
> 2 EAP Request
> 2 EAP Authenticator
> 1 EAPEAP OL
> 1 EAP-method-specific With
> 1 EAP-based or
> 1 EAP-based authentication
> 1 EAP-TLS Authentication
> 1 EAP-Success the
> 1 EAP-Request/Identity messages
> 1 EAP-Request/Identity message
> 1 EAP-Request shown
> 1 EAP-Request message
> 1 EAP-Packet and
> 1 EAP-Method
> 1 EAP-MD5 is
> 1 EAP vendor
> 1 EAP number
> 1 EAP message
> 1 EAP identity
> 1 EAP exchange
> 1 EAP Response
> 1 EAP Extensible
> 1 EAP EAPEAP
> 1 EAP B39
> 1 EAP B
> 1 EAP
>
> --
> Mark RISON, Systems Architect, Wi-Fi English/Esperanto/Français
> Samsung Cambridge Solution Centre Tel: +44 1223 434600
> Innovation Park, Cambridge CB4 0ZT Fax: +44 1223 TBCTBC
> ROYAUME UNI WWW: http://www.samsung.com/uk
>
>
> > -----Original Message-----
> > From: Hamilton, Mark [mailto:Mark.Hamilton@xxxxxxxxxxx]
> > Sent: 29 October 2012 03:29
> > To: m.rison@xxxxxxxxxxx; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
> > Subject: RE: [STDS-802-11-TGM] Minutes posted for Oct 12th Telecon
> >
> > Ok, so then the proposal is:
> >
> >
> >
> > Add a definition in subclause 3.2, "EAPOL-Key frame: An 802.11 data
> > MPDU which carries some or all of an 802.1X EAPOL PDU."
> >
> >
> >
> > Add a sentence to the end of the second paragraph of subclause 4.2.5:
> > "Within 802.11, EAPOL PDUs are carried as MSDUs within one or more
> > data MDPUs, as described in 802.1X-2010, clause 11; data MPDUs used
> > for this purpose are known
> within this Standard as EAPOL-Key frames."
> >
> >
> >
> > Change the start of the sentence in 4.10.2, "IEEE 802.1X
> > authentication frames are transmitted in IEEE
> > 802.11 data frames ..." to "IEEE 802.1X EAPOL PDUs are transmitted
> > in IEEE 802.11 data MPDUs known as EAPOL-Key frames ..."
> >
> >
> >
> > In the table in subclause 6.3.22.1.2, change "EAPOL-Key frame" to "EAPOL PDU"
> >
> >
> >
> > Mark
> >
> >
> >
> > P.S., I’m using the term “data MPDU” loosely here. Do we need to be
> > more careful, or given our other changes around “data” and “management” etc, is this okay?
> >
> >
> >
> > -----Original Message-----
> > From: Mark Rison [mailto:m.rison@xxxxxxxxxxx]
> > Sent: Sunday, October 28, 2012 11:06 AM
> > To: Hamilton, Mark; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
> > Subject: RE: [STDS-802-11-TGM] Minutes posted for Oct 12th Telecon
> >
> >
> >
> > > Since you brought up fragmentation, while I doubt fragmentation of
> >
> > > EAPOL PDUs ever happens, we could perhaps cover this case more
> >
> > > correctly by saying that an EAPOL-Key frame is a data MPDU that
> >
> > > carries "some or all" of an EAPOL PDU. Thus, if an EAPOL PDU does
> >
> > > have to be carried via more than one data MPDU, each with a
> > > fragment, then each of those data MPDUs
> > is an EAPOL-Key frame. I think this still works, and keeps
> > everything consistent. But, I also think it is probably overkill.
> >
> >
> >
> > I think I would be happy if an EAPOL frame were described as
> > something which carried some or all of an EAPOL PDU.
> >
> >
> >
> > > But, I also think it is probably overkill.
> >
> >
> >
> > I don't think so. I really don't want to add anything which could
> > get people mixing MSDUs and MPDUs up.
> >
> >
> >
> > So how about:
> >
> >
> >
> > <<
> >
> > EAPOL frame: A Data frame which carries all or part of an 802.1X EAPOL PDU.
> >
> > EAPOL-Key frame: An EAPOL frame which carries all or part of an 802.1X EAPOL PDU of type EAPOL-Key.
> >
> > EAPOL-Key request frame: An EAPOL-Key frame which carries all or
> > part of an 802.1X EAPOL PDU of type EAPOL-Key with the Request bit set.
> >
> > EAPOL-Start frame: An EAPOL frame which carries all or part of an
> > 802.1X EAPOL PDU of type EAPOL- Start.
> >
> > [Adjust the "of type" and "Request bit" bits to use the correct
> > 802.1X terminology]
> >
> >
> >
> > Within 802.11, EAPOL PDUs, as described in 802.1X-2010 clause 11,
> > are carried in one or more Data frames; Data frames used for this
> > purpose are known within this Standard as EAPOL frames (and
> > sometimes more specifically as EAPOL-Key frames,
> EAPOL-Key request frames or EAPOL-Start frames).
> >
> >
> >
> > IEEE 802.1X EAPOL PDUs are transmitted in IEEE 802.11 Data frames known as EAPOL frames ...
> >
> > >>
> >
> >
> >
> > ? [I've adopted the "Data frame" (cf. data MPDU) terminology which
> > we agreed to under CID 100.]
> >
> >
> >
> > Mark
> >
> >
> >
> > --
> >
> > Mark RISON, Systems Architect, Wi-Fi English/Esperanto/Français
> >
> > Samsung Cambridge Solution Centre Tel: +44 1223 434600
> >
> > Innovation Park, Cambridge CB4 0ZT Fax: +44 1223 TBCTBC
> >
> > ROYAUME UNI WWW: http://www.samsung.com/uk <http://www.samsung.com/uk>
> >
> >
> >
> >
> >
> > > -----Original Message-----
> >
> > > From: Hamilton, Mark [mailto:Mark.Hamilton@xxxxxxxxxxx
> > > <mailto:Mark.Hamilton@xxxxxxxxxxx> ]
> >
> > > Sent: 29 October 2012 01:40
> >
> > > To: m.rison@xxxxxxxxxxx <mailto:m.rison@xxxxxxxxxxx> ;
> > > STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
> > <mailto:STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
> >
> > > Subject: RE: [STDS-802-11-TGM] Minutes posted for Oct 12th Telecon
> >
> > >
> >
> > > Mark,
> >
> > >
> >
> > > I was being quite specific, intentionally. We can argue about my
> >
> > > approach, but I don't think I mixing anything up.
> >
> > >
> >
> > > From 802.1X, "EAPOL PDUs" are exchanged between PAEs. And,
> > > further,
> >
> > > 802.1X specifically talks about these being exchanged by passing
> > > them
> >
> > > as MSDUs to the MAC Service. So, EAPOL PDUs _are_ 802.11 MSDUs
> > > (not "carried by" them). This all
> > makes sense, as 802.1X PAEs are MAC Service users.
> >
> > >
> >
> > > I have no opinion whether EAPOL PDUs can be fragmented by 802.11
> > > (or
> >
> > > any other MAC Service). I don't see why not - they are just
> > > another
> >
> > > MSDU at the level where fragmentation is done. Thus, again, I
> > > claim that EAPOL PDUs are MSDUs like
> > any other.
> >
> > >
> >
> > > What I am trying to convey with this new definition/concept is
> > > what an
> >
> > > "EAPOL-Key frame" (and its various other spellings) means. We
> > > call this a "frame" and the text
> > discusses these being "exchanged"
> >
> > > with peer entities. That means they are PDUs (to some entity).
> > > From 802.1X, its PDUs are EAPOL
> > PDUs.
> >
> > > But, also from 802.1X, these PDUs are delivered to the MAC Service
> > > (as
> >
> > > MSDUs) and are then carried 'on the wire' or 'on the air' (those
> > > are 802.1X's words) using 'EAPOL
> > frames' at the MAC Service layer.
> >
> > > That is, the MAC Service takes the EAPOL PDU and applies
> > > MAC-specific
> >
> > > procedure and protocol to result in the actual frame exchange that
> >
> > > carries the EAPOL PDUs to the peer PAE. In our case, we do that
> > > with
> >
> > > data MPDUs. I believe there is a simple mapping, then, that
> > > 802.11
> >
> > > has data MPDUs that carry lots of MSDUs. Sometimes those MSDUs
> > > happen to be EAPOL PDUs. And, in
> > that case, the data MPDUs can be referred to as EAPOL frames, or,
> > EAPOL-Key frames as we have
> chosen.
> >
> > >
> >
> > > The attempt is to explain what discussion like that in 4.5 and
> > > 4.10,
> >
> > > and pictures like Figure 12-2
> >
> > > (802.11-2012) are showing. I don't think it helps us to talk
> > > about
> >
> > > these being MSDUs, as that makes the terms "frame" or "exchange"
> > > in
> >
> > > this context very confusing with respect to the usage of these terms in the rest of the Standard.
> >
> > >
> >
> > > Since you brought up fragmentation, while I doubt fragmentation of
> >
> > > EAPOL PDUs ever happens, we could perhaps cover this case more
> >
> > > correctly by saying that an EAPOL-Key frame is a data MPDU that
> >
> > > carries "some or all" of an EAPOL PDU. Thus, if an EAPOL PDU does
> >
> > > have to be carried via more than one data MPDU, each with a
> > > fragment, then each of those data MPDUs
> > is an EAPOL-Key frame. I think this still works, and keeps
> > everything consistent. But, I also think it is probably overkill.
> >
> > >
> >
> > > Mark
> >
> > >
> >
> > > -----Original Message-----
> >
> > > From: Mark Rison [mailto:m.rison@xxxxxxxxxxx
> > > <mailto:m.rison@xxxxxxxxxxx> ]
> >
> > > Sent: Sunday, October 28, 2012 12:07 AM
> >
> > > To: Hamilton, Mark; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
> > > <mailto:STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
> >
> > > Subject: RE: [STDS-802-11-TGM] Minutes posted for Oct 12th Telecon
> >
> > >
> >
> > > I won't pretend to know about 802.1 or 802.1X, but I would like to
> >
> > > make sure we're not going to get our MSDUs and MPDUs mixed up again. So:
> >
> > >
> >
> > > > I looked at 802.1-2010 for an updated reference place for this
> >
> > > > concept. Looking there, I note that Clause 11 is where this 'frame'
> >
> > > > is defined in detail. And, that clause is quite consistent in
> > > > using
> >
> > > > the term 'EAPOL PDU' for the information units exchanged between
> >
> > > > PAEs. [...] EAPOL PDUs are MSDUs
> >
> > > to the MAC Service.
> >
> > >
> >
> > > So far so good...
> >
> > >
> >
> > > > Add a definition in subclause 3.2, "EAPOL-Key frame: An 802.11
> > > > data
> >
> > > > MPDU which carries an 802.1X EAPOL PDU."
> >
> > >
> >
> > > Unless 802.1X EAPOL PDUs can't be fragmented when carried over
> > > 802.11
> >
> > > (and I would be somewhat surprised by such a constraint) then
> > > surely it should be "An 802.11 MSDU
> > which carries"?
> >
> > >
> >
> > > > Add a sentence to the end of the second paragraph of subclause 4.2.5:
> >
> > > > "Within 802.11, EAPOL PDUs are carried as MSDUs within data
> > > > MDPUs,
> >
> > > > as described in 802.1X-2010, clause 11; data MPDUs used for this
> >
> > > > purpose are known within this Standard
> >
> > > as EAPOL-Key frames."
> >
> > >
> >
> > > Similarly, I think "MSDUs used for this purpose" would be better.
> >
> > > The reference to data MPDUs risks confusing things, so I would delete "within data MPDUs" too.
> >
> > >
> >
> > > Oh, and does 802.1X-2010 really describe carrying EAPOL PDUs as MSDUs?
> >
> > > Shouldn't the "as described" refer to the EAPOL PSDUs, not the (802.11) MSDUs?
> >
> > >
> >
> > > What about the "EAPOL-Start frame"s, "EAPOL frame"s and "EAPOL-Key
> >
> > > request frame"s of Jouni's suggestion, though?
> >
> > >
> >
> > > So I'm wondering (again, from my limited understanding of 802.1)
> >
> > > whether it shouldn't be something
> >
> > > like:
> >
> > >
> >
> > > <<
> >
> > > EAPOL frame: An 802.11 MSDU which carries an 802.1X EAPOL PDU.
> >
> > > EAPOL-Key frame: An EAPOL frame of type EAPOL-Key.
> >
> > > EAPOL-Key request frame: An EAPOL-Key frame with the Request bit set.
> >
> > > EAPOL-Start frame: An EAPOL frame of type EAPOL-Start.
> >
> > > [Adjust the "of type" and "Request bit" bits to use the correct
> > > 802.1X
> >
> > > terminology]
> >
> > >
> >
> > > Within 802.11, EAPOL PDUs, as described in 802.1X-2010 clause 11,
> > > are
> >
> > > carried as MSDUs; MSDUs used for this purpose are known within
> > > this
> >
> > > Standard as EAPOL frames (and sometimes more specifically as
> > > EAPOL- Key frames, EAPOL-Key request
> > frames or EAPOL-Start frames).
> >
> > > >>
> >
> > >
> >
> > > > Change the start of the sentence in 4.10.2, "IEEE 802.1X
> >
> > > > authentication frames are transmitted in IEEE
> >
> > > > 802.11 data frames ..." to "IEEE 802.1X EAPOL PDUs are
> > > > transmitted
> >
> > > > in IEEE 802.11 data MPDUs known as EAPOL-Key frames ..."
> >
> > >
> >
> > > "in IEEE 802.11 MSDUs". Also maybe "as EAPOL frames", per the above.
> >
> > >
> >
> > > > In the table in subclause 6.3.22.1.2, change "EAPOL-Key frame" to "EAPOL PDU"
> >
> > >
> >
> > > Mark
> >
> > >
> >
> > > --
> >
> > > Mark RISON, Systems Architect, Wi-Fi English/Esperanto/Français
> >
> > > Samsung Cambridge Solution Centre Tel: +44 1223 434600
> >
> > > Innovation Park, Cambridge CB4 0ZT Fax: +44 1223 TBCTBC
> >
> > > ROYAUME UNI WWW: http://www.samsung.com/uk <http://www.samsung.com/uk>
> >
> > >
> >
> > > > -----Original Message-----
> >
> > > > From: ***** IEEE stds-802-11-tgm List *****
> >
> > > > [mailto:STDS-802-11-TGM@xxxxxxxx
> > > > <mailto:STDS-802-11-TGM@xxxxxxxx> ] On Behalf Of Hamilton, Mark
> >
> > > > Sent: 28 October 2012 13:31
> >
> > > > To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
> > > > <mailto:STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
> >
> > > > Subject: Re: [STDS-802-11-TGM] Minutes posted for Oct 12th
> > > > Telecon
> >
> > > >
> >
> > > > --- This message came from the IEEE 802.11 Task Group M
> > > > Technical
> >
> > > > Reflector ---
> >
> > > >
> >
> > > > On Friday's teleconference, I took an action item to propose
> > > > some
> >
> > > > text setting a convention for the use of the term "EAPOL frame".
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > In investigating the wording for this, I looked at 802.1-2010
> > > > for an
> >
> > > > updated reference place for this concept. Looking there, I note
> >
> > > > that Clause 11 is where this 'frame' is defined in detail. And,
> >
> > > > that clause is quite consistent in using the term 'EAPOL PDU'
> > > > for
> >
> > > > the information units exchanged between PAEs. While other parts
> > > > of
> >
> > > > 802.1X are less consistent, this clause seems to layout the idea
> >
> > > > that EAPOL PDUs are exchanged via the MAC
> >
> > > transmission and reception of EAPOL frames. EAPOL PDUs are MSDUs to the MAC Service.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Thus, I propose:
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Add a definition in subclause 3.2, "EAPOL-Key frame: An 802.11
> > > > data
> >
> > > > MPDU which carries an 802.1X EAPOL PDU."
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Add a sentence to the end of the second paragraph of subclause 4.2.5:
> >
> > > > "Within 802.11, EAPOL PDUs are carried as MSDUs within data
> > > > MDPUs,
> >
> > > > as described in 802.1X-2010, clause 11; data MPDUs used for this
> >
> > > > purpose are known within this Standard
> >
> > > as EAPOL-Key frames."
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Change the start of the sentence in 4.10.2, "IEEE 802.1X
> >
> > > > authentication frames are transmitted in IEEE
> >
> > > > 802.11 data frames ..." to "IEEE 802.1X EAPOL PDUs are
> > > > transmitted
> >
> > > > in IEEE 802.11 data MPDUs known as EAPOL-Key frames ..."
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > In the table in subclause 6.3.22.1.2, change "EAPOL-Key frame" to "EAPOL PDU"
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > I also suggest we update the references to 802.1X to be to the
> >
> > > > 802.1X-2010 revision. On a quick scan, I don't see that there
> > > > is
> >
> > > > any terminology becomes out-of-date. There are a couple
> > > > specific
> >
> > > > clause references that need updating: in 11.6.2, clause
> > > > references
> >
> > > > to 7.1 need to be 11.3 for the first occurrence and 11 for the
> >
> > > > second. I believe we can just change
> >
> > > 802.1X-2004 to 802.1X-2011 in all other occurrences. But, I'm not
> > > an
> >
> > > expert on this, and experts should review for any subtle changes.
> >
> > > > I could perhaps submit this as a comment on D1.0, if we're more comfortable with that.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Lastly, I also found many uses of the phrase “802.1X frame(s)”
> > > > which
> >
> > > > I think slipped past Jouni’s list (by not having ‘EAPOL’ in
> > > > them),
> >
> > > > but should also be modified in the
> >
> > > same way.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > I welcome comments on any of the above.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Mark
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > -----Original Message-----
> >
> > > > From: ***** IEEE stds-802-11-tgm List *****
> >
> > > > [mailto:STDS-802-11-TGM@xxxxxxxx
> > > > <mailto:STDS-802-11-TGM@xxxxxxxx> ] On Behalf Of Jouni Malinen
> >
> > > > Sent: Friday, October 26, 2012 7:38 AM
> >
> > > > To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
> > > > <mailto:STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
> >
> > > > Subject: Re: [STDS-802-11-TGM] Minutes posted for Oct 12th
> > > > Telecon
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > --- This message came from the IEEE 802.11 Task Group M
> > > > Technical
> >
> > > > Reflector ---
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > On Fri, Oct 12, 2012 at 8:59 PM, Jon Rosdahl <jrosdahl@xxxxxxxx
> > > > <mailto:jrosdahl@xxxxxxxx
> > <mailto:jrosdahl@xxxxxxxx%20%3cmailto:jrosdahl@xxxxxxxx> > > wrote:
> >
> > > >
> >
> > > > > ACTION ITEM: Jouni to take some time to research and provide a
> >
> > > >
> >
> > > > > proposal for the usage of the “EAPOL_Key frame”’ name issue.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Existing references to Data frames that use EAPOL ethertype:
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > IEEE Std 802.11-2012:
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > EAPOL-Key frame
> >
> > > >
> >
> > > > EAPOL-Key Frame
> >
> > > >
> >
> > > > IEEE 802.1X EAPOL-Key frame
> >
> > > >
> >
> > > > 802.1X EAPOL-Key frame
> >
> > > >
> >
> > > > EAPOL-Key
> >
> > > >
> >
> > > > EAPOL-Key message
> >
> > > >
> >
> > > > EAPOL-Key Message
> >
> > > >
> >
> > > > EAPOL-Key 4-Way Handshake Message
> >
> > > >
> >
> > > > EAPOL-Key request frame
> >
> > > >
> >
> > > > EAPOL-Key Request frame
> >
> > > >
> >
> > > > EAPOL-Key request message
> >
> > > >
> >
> > > > EAPOL request message
> >
> > > >
> >
> > > > IEEE 802.1X EAPOL frame
> >
> > > >
> >
> > > > EAPOL message
> >
> > > >
> >
> > > > EAPOL-Start message
> >
> > > >
> >
> > > > EAPOL-Start packet
> >
> > > >
> >
> > > > IEEE 802.1X EAPOL-Start message
> >
> > > >
> >
> > > > EAP authentication frame
> >
> > > >
> >
> > > > EAP-Request/Identity message
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > IEEE Std 802.1X-2010
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > EAPOL PDU
> >
> > > >
> >
> > > > EAPOL frame
> >
> > > >
> >
> > > > EAPOL-Key
> >
> > > >
> >
> > > > EAPOL-Key frame
> >
> > > >
> >
> > > > EAPOL-Start
> >
> > > >
> >
> > > > EAPOL-Start frame
> >
> > > >
> >
> > > > EAPOL-Start PDU
> >
> > > >
> >
> > > > EAPOL-Start packet
> >
> > > >
> >
> > > > EAPOL-EAP frame
> >
> > > >
> >
> > > > EAP message
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > "EAPOL* frame" and "EAPOL*" are the most commonly used forms.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Proposal for P802.11-REVmc:
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > EAPOL-Key Frame --> EAPOL-Key frame
> >
> > > >
> >
> > > > IEEE 802.1X EAPOL-Key frame --> EAPOL-Key frame 802.1X EAPOL-Key
> >
> > > > frame
> >
> > > > --> EAPOL-Key frame EAPOL-Key message --> EAPOL-Key frame
> > > > --> EAPOL-Key
> >
> > > > Message --> EAPOL-Key frame EAPOL-Key Request frame --> EAPOL-
> > > > Key
> >
> > > > request frame EAPOL-Key request message --> EAPOL-Key request
> > > > frame
> >
> > > > EAPOL request message --> EAPOL-Key request frame IEEE 802.1X
> > > > EAPOL
> >
> > > > frame --> EAPOL frame EAPOL message --> EAPOL frame EAPOL- Start
> >
> > > > message --> EAPOL-Start frame EAPOL-Start packet --> EAPOL-Start
> >
> > > > frame IEEE 802.1X EAPOL-Start message --> EAPOL-Start frame EAP
> >
> > > > authentication frame --> EAP message
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > ________________________________________________________________
> > > > __
> > > > __
> >
> > > > __
> >
> > > > _________
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > IF YOU WISH to be Removed from this reflector, PLEASE DO NOT
> > > > send
> >
> > > > your request to this CLOSED reflector. We use this valuable tool
> > > > to communicate on the issues at
> > hand.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > SELF SERVICE OPTION:
> >
> > > >
> >
> > > > Point your Browser to -
> >
> > > > http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM
> > > > <http://listserv.ieee.org/cgi-
> > bin/wa?SUBED1=STDS-802-11-TGM>
> >
> > > > <http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM
> > > > <http://listserv.ieee.org/cgi-
> > bin/wa?SUBED1=STDS-802-11-TGM> > and
> >
> > > > then amend your subscription on the form provided. If you
> > > > require
> >
> > > > removal from the reflector press the
> >
> > > LEAVE button.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Further information can be found at:
> >
> > > > http://www.ieee802.org/11/Email_Subscribe.html
> > > > <http://www.ieee802.org/11/Email_Subscribe.html>
> >
> > > > <http://www.ieee802.org/11/Email_Subscribe.html
> > > > <http://www.ieee802.org/11/Email_Subscribe.html> >
> >
> > > >
> >
> > > > ________________________________________________________________
> > > > __
> > > > __
> >
> > > > __
> >
> > > > _________
> >
> > > >
> >
> > > > ________________________________________________________________
> > > > __
> > > > __
> >
> > > > __
> >
> > > > _________
> >
> > > >
> >
> > > > IF YOU WISH to be Removed from this reflector, PLEASE DO NOT
> > > > send
> >
> > > > your request to this CLOSED reflector. We use this valuable tool
> > > > to communicate on the issues at
> > hand.
> >
> > > >
> >
> > > > SELF SERVICE OPTION: Point your Browser to -
> >
> > > > http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-
> > > > <http://listserv.ieee.org/cgi-
> > bin/wa?SUBED1=STDS-802-11->
> >
> > > > TGM and then amend your subscription on the form provided. If
> > > > you
> >
> > > > require removal from the reflector press the LEAVE button.
> >
> > > >
> >
> > > > Further information can be found at:
> >
> > > > http://www.ieee802.org/11/Email_Subscribe.html
> > > > <http://www.ieee802.org/11/Email_Subscribe.html>
> >
> > > > ________________________________________________________________
> > > > __
> > > > __
> >
> > > > ___________
> >
> > >
> >
> >
> >
> >
> >
> >
>
>
_______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this
CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION:
Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and
then amend your subscription on the form provided. If you require removal from the reflector
press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________