Re: [STDS-802-11-TGM] Minutes posted for Oct 12th Telecon
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Sorry, one more:
> > 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 ...
IEEE 802.1X EAPOL PDUs are transmitted in one or more IEEE 802.11 Data frames
known as EAPOL-Key frames ...
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: Mark Rison [mailto:m.rison@xxxxxxxxxxx]
> Sent: 29 October 2012 06:04
> 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
_______________________________________________________________________________