Re: [ipwave] Mirja Kühlewind's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)

[Russ Housley <[e-mail]>]

I suggest that the MUST statement remain, but that a bit of rationale be provided:

   The IPv6 packet transmitted on 802.11-OCB are 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, see Appendix D), the value of the Type field MUST be set to
   0x86DD (IPv6).  The mapping to the 802.11 data service MUST use a
   'priority' value of 1 (QoS with a 'Background' user priority), reserving
   higher priority values for safety-critical and time-sensitive
   traffic [IEEE-1609.2].   

Russ


> On Jul 10, 2019, at 7:40 PM, John Kenney <[e-mail]> wrote:
> 
> Hi All:
> 
> I have no desire to re-litigate the QoS issue. However, it's important to remember that IP-over-OCB will typically share public regulated spectrum with non-IP safety-of-life communications. In the US, FCC regulations require that such safety communications have access priority over other communications [47 CFR § 90.377(d)] .  I would be cautious about removing the current language unless you are convinced that doing so will not adversely affect non-IP safety communications.
> 
> Best Regards,
> John
> 
> On Wed, Jul 10, 2019 at 6:18 AM Mirja Kuehlewind <[e-mail] <mailto:[e-mail]>> wrote:
> Thanks. Removing this text entirely is a good option.
> 
> Mirja
> 
> 
> > On 10. Jul 2019, at 13:39, Nabil Benamar <[e-mail] <mailto:[e-mail]>> wrote:
> > 
> > Hi Mirja,
> > 
> > Actually, the text was written some time ago and different views were shared in the group. I think we need to remove this text to avoid confusion.
> > 
> > On Wed, Jul 10, 2019 at 8:44 AM Mirja Kuehlewind <[e-mail] <mailto:[e-mail]>> wrote:
> > Hi Nabil,
> > 
> > I think my point was slightly different. Dorothy mainly advised you _how_ to specify the priority. However my question is rather _if_ that is needed and if it is really appropriate to use a MUST here. Can you further explain why that is seen as a mandatory requirement?
> > 
> > Mirja
> > 
> > 
> > 
> > > On 9. Jul 2019, at 23:29, Nabil Benamar <[e-mail] <mailto:[e-mail]>> wrote:
> > > 
> > > Hi Mirja,
> > > 
> > > Thank you for your review and comments.
> > > 
> > > You raised a very important point that was discussed extensively on the ML and then we asked the IEEE 802.11 members (thanks to Dorothy Stanly) to provide us with a review to help us clarify this point.
> > > 
> > > Here is what we got from them:
> > > 
> > > .  Suggest to simply state that the data is transmitted with “User Priority” of Background (numerically 1 or 2), and leave the internal details of how this is accomplished to the 802.11 specification.
> > > 
> > > User Priority is typically described as a simple integer (not a binary value), and the mapping of this User Priority to TID header value is another 802.11 detail, best left to the 802.11 specification.  For example: in the 802.11 specification the TID field is specified to be 4 bits in the header.  The use of these 4 bits to carry the User Priority information is an internal specification of 802.11 and potentially subject to change.. 
> > > 
> > > Suggest using terminology from the MAC SAP in IEEE Std 802.11-2016 Clause 5.2.  This clause intentionally abstracts the exact details of 802..11’s internal operation, while describing specifically the behavior required by the user.  For example, the following text:
> > > 
> > > “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').” 
> > > 
> > > could be replaced by:
> > > 
> > > 
> > > “The mapping to the 802.11 data service MUST use a ‘priority’ value of 1, which specifies the use of QoS with a “Background” user priority.” 
> > > 
> > > 
> > > 
> > > Thanks again.
> > > 
> > > 
> > > On Tue, Jul 9, 2019 at 5:43 PM Mirja Kühlewind via Datatracker <[e-mail] <mailto:[e-mail]>> wrote:
> > > Mirja Kühlewind has entered the following ballot position for
> > > draft-ietf-ipwave-ipv6-over-80211ocb-49: Discuss
> > > 
> > > When responding, please keep the subject line intact and reply to all
> > > email addresses included in the To and CC lines. (Feel free to cut this
> > > introductory paragraph, however.)
> > > 
> > > 
> > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> > > for more information about IESG DISCUSS and COMMENT positions.
> > > 
> > > 
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ <https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/>
> > > 
> > > 
> > > 
> > > ----------------------------------------------------------------------
> > > DISCUSS:
> > > ----------------------------------------------------------------------
> > > 
> > > One point on this sentence, which I believe was also commented in the TSV-ART
> > > review (Thanks Jörg!):
> > > 
> > > sec 4.2: "The mapping to the 802.11 data service MUST use a
> > >    'priority' value of 1, which specifies the use of QoS with a
> > >    'Background' user priority."
> > > I don't think this should be a MUST requirement. I assume the assumption here
> > > is that IP traffic is always some "random" data that is less important than
> > > other V2V communication. However, this is a generic mapping document and should
> > > therefore probably not make such an assumption (or at least it would need to be
> > > spelled out).
> > > 
> > > 
> > > ----------------------------------------------------------------------
> > > COMMENT:
> > > ----------------------------------------------------------------------
> > > 
> > > One editorial high level comment: I seams like all text that was somehow deemed
> > > as out fo scope for the main body of this document got stuffed into the
> > > appendix. Please consider removing what is really not needed in this document
> > > as these pages also take review and RFC Editor time, especially as they seem to
> > > have received less review and therefore have more nits.
> > > 
> > > nit: sec 4.5.2 s/in OCB mode.A  A future improvement/in OCB mode. A future
> > > improvement/
> > > 
> > > 
> > > 
> > > 
> > > -- 
> > > 
> > > Best Regards
> > > 
> > > Nabil Benamar
> > > Associate Professor
> > > Department of Computer Sciences
> > > School of Technology
> > > Moulay Ismail University 
> > > Meknes. Morocco
> > > 
> > > 
> > 
> > 
> > 
> > -- 
> > 
> > Best Regards
> > 
> > Nabil Benamar
> > Associate Professor
> > Department of Computer Sciences
> > School of Technology
> > Moulay Ismail University 
> > Meknes. Morocco
> > 
> > 
> 
> _______________________________________________
> its mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>
> 
> 
> -- 
> John Kenney
> Director and Sr. Principal Researcher
> Toyota InfoTech Labs
> 465 Bernardo Avenue
> Mountain View, CA 94043
> Tel: [phone]. Mobile: [phone]