Subject: [ipwave] Fwd: RE: 802.11 Data vs 802.11 QoS Data - towards resolution

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 9 Mar 2018 21:05:00 +0100

by this email you will see opposition from Dick Roy.
(FYI the emails from Dick Roy dont show in archives, because of mailer 
problems).

-------- Message transféré --------
Sujet : 	RE: [ipwave] 802.11 Data vs 802.11 QoS Data - towards resolution
Date : 	Fri, 9 Mar 2018 08:50:06 -0800
De : 	Dick Roy <[email-masked]>
Répondre à : 	[email-masked]
Organisation : 	SRA
Pour : 	[email-masked], 'Alexandre Petrescu' <[email-masked]>
Copie à : 	[email-masked]

------------------------------------------------------------------------

*From:*its [mailto:[email-masked]] *On Behalf Of [email-masked]
*Sent:* Friday, March 9, 2018 8:36 AM
*To:* Alexandre Petrescu
*Cc:* [email-masked]
*Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data - towards resolution

Alex,

>> The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded
>> by a Logical Link Control (LLC) header and an 802.11 header; the value
>> of the Subtype sub-field in the Frame Control field of the 802.11
>> header MUST be set to 8 (i.e. 'QoS Data'); the value of the Traffic
>> Identifier (TID) sub-field of the QoS Control field of the 802.11
>> header MUST be set to binary 001 (i.e. User Priority 'Background', QoS
>> Access Category 'AC_BK').
>>
>
> Do you agree with the values?
>
I’m fine with this, thank you.

Others?  We need rough consensus….

*/[RR] I’m not fine with it, unless it is conditioned on transmissions 
being in Channel 172 in the US, and even that is problematic since we 
currently have NO rules in place that make such requirements! Requiring 
ALL Ipv6 packets to be carried in MAC frames of a single type (QoSData 
in this case) is simply a bad idea, and should NOT be done, neitherand 
exactly the same argument applies to the priority!/*

*//*

*/You asked again … and once more I say … don’t do it!/*

*//*

*/RR/*

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 13 Mar 2018 14:12:22 +0100

IPWAVErs,

On my side: (1) I counted roughly 8 opinions that would favor addition 
of this text, and roughly 3 against, and (2) since the report of use of 
IP-with-QoSData to connect to SCMS I am favoring it too.

All I can do is hope that in the future the cheap 802.11-OCB capable 
cards on linux will be able to do QoSData.

Other opinions?

> The IPv6 packet transmitted on 802.11-OCB MUST be immediately
> preceded by a Logical Link Control (LLC) header and an 802.11 header;
> the value of the Subtype sub-field in the Frame Control field of the
> 802.11 header MUST be set to 8 (i.e. 'QoS Data'); the value of the
> Traffic Identifier (TID) sub-field of the QoS Control field of the
> 802.11 header MUST be set to binary 001 (i.e. User Priority
> 'Background', QoS Access Category 'AC_BK').
Alex
(the submission system for new Internet Drafts is closed until Sunday).

Le 09/03/2018 à 21:05, Alexandre Petrescu a écrit :
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 19 Mar 2018 11:13:54 -0400

In the session earlier today, Alex offered text to resolve this topic.  He said:

   The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded
   by a Logical Link Control (LLC) header and an 802.11 header.  In the
   LLC header, and in accordance with the EtherType Protocol
   Discrimination (EPD), the value of the Type field MUST be set to
   0x86DD (IPv6).  In the 802.11 header, the value of the Subtype
   sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS
   Data'); the value of the Traffic Identifier (TID) sub-field of the QoS
   Control field of the 802.11 header MUST be set to binary 001 (i.e.
   User Priority 'Background', QoS Access Category 'AC_BK').

No one in the room raised any concern with this text.  If you have a concern, please speak on the list now.

In a another part of the meeting, Jérôme talked about Mapping IP to Access Category in 802.11-OCB.  It was pointed out that RFC 8325 was recently published on the standards track.  Tony Li pointed out that there is no integrity protection for these bits.

As an individual, I wonder if it would be better to say something like:  If DiffServ is being used, set the QoS Access Category as described in RFC 8325, otherwise set the QoS Access Category of 'AC_BK'.

What do others think?

Russ

---

From: [email-masked]
Date: Mon, 19 Mar 2018 16:07:46 +0000

Russ,

As the writer of the device driver has NO idea whether or not DiffServ is in use (a rare case), they are very likely to make the mistake that this is somehow beneficial when the converse is actually true.

There was also no discussion of the EAL, so I suspect that we still need to reach closure on that text.

Tony

> On Mar 19, 2018, at 3:13 PM, Russ Housley <[email-masked]> wrote:
>

---

From: François Simon <[email-masked]>
Date: Tue, 20 Mar 2018 10:18:05 -0400

MUST ..... AC_BK does not make sense.    Fygs

-----Original Message-----
From: its <[email-masked]> On Behalf Of Russ Housley
Sent: Monday, March 19, 2018 11:14 AM
To: [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data

What do others think?

Russ

---

From: [email-masked]
Date: Tue, 20 Mar 2018 14:24:28 +0000

What would make more sense?  You do not want people using higher priority. If you don’t say MUST, then everything will be marked as voice.

T

> On Mar 20, 2018, at 2:18 PM, François Simon <[email-masked]> wrote:
>

---

From: [email-masked]
Date: Tue, 20 Mar 2018 15:20:55 +0000

> On Mar 20, 2018, at 2:42 PM, [email-masked] wrote:
> 
> That said, ANYTHING the IETF says about this will be ignored, believe me. 
> J2945/1 and others will apply and they are m ost assuredly using ALL
> prioities.

No one is suggesting any restrictions for anything other than IP packets, so I don’t see your point.

T

---

From: [email-masked]
Date: Tue, 20 Mar 2018 16:11:27 +0000

> On Mar 20, 2018, at 3:35 PM, [email-masked] wrote:
> 
> Everything I said above applies to ANY NPDU, including an IPv6 NPDU! 
> Ch180 is liekly to have many ITS services that use IPv6, and those
> services will be prioitized and those prioirties will filter on down
> through UNITDATA.reuests to the MAC!  That's what I mean.  The guys
> deploying the system  will determine the prioities, not the ITETF.
> 
> Hope that clears it up...

It does completely.  

I’m beginning to realize that you object to standardization.  ;-)

If they choose not to comply with the RFC that’s fine. We’re not setting laws here.  But they should also not complain when they don’t interoperate or when they get hacked.

Tony

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 21 Mar 2018 10:31:42 +0200

+1

On Tue, Mar 20, 2018 at 4:18 PM, François Simon <[email-masked]> wrote:

> In a another part of the meeting, Jérôme talked about Mapping IP to Access
> Category in 802.11-OCB.  It was pointed out that RFC 8325 was recently
> published on the standards track.  Tony Li pointed out that there is no
> integrity protection for these bits.
>
> As an individual, I wonder if it would be better to say something like:
> If DiffServ is being used, set the QoS Access Category as described in RFC
> 8325, otherwise set the QoS Access Category of 'AC_BK'.
>
> What do others think?
>
> Russ
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 22 Mar 2018 01:15:40 +0200

> concern, please speak on the list now.

Suggest using SHOULD instead of MUST,

> integrity protection for these bits.

I support Jerome's comment. Regarding protections, it should be discussed
in the last section of security, not in the draft body, all RFCs do that.

> 8325, otherwise set the QoS Access Category of 'AC_BK'.

Yes that is correct, IMHO we need that in this draft.

AB