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

[Mirja Kuehlewind <[e-mail]>]

Hi everybody,

Yes, this text would work for me.

Thanks!
Mirja


> On 16. Jul 2019, at 22:07, Nabil Benamar <[e-mail]> wrote:
> 
> Hi Russ, Mirja,
> 
> 
> I'm fine with this text.
> 
> Mirja, please let me know if it is OK for you so that I include this change in the next version of the draft.
> 
> On Tue, Jul 16, 2019 at 8:42 PM Russ Housley <[e-mail]> wrote:
> Mirja:
> 
> The safety messages defined in IEEE 1902.2 do not use IP, but you are right that this document should not have to change if such a thing were to be defined in the future.
> 
> I suggest:
> 
>   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 SHOULD 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 11, 2019, at 11:57 AM, Mirja Kuehlewind <[e-mail]> wrote:
> > 
> > Hi Russ,
> > 
> > This would also be good and address my discuss. However, IP is not really a specific service and I could well imagine that in future there could also be a more critical service that is implemented over IP (for whatever reason). To leave this as generic as possible, which I think a mapping document should be, I would recommend to us SHOULD or no normative language at all.
> > 
> > Mirja
> > 
> > 
> > 
> >> On 11. Jul 2019, at 17:51, Russ Housley <[e-mail]> wrote:
> >> 
> >> 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]> wrote:
> >>> Thanks. Removing this text entirely is a good option.
> >>> 
> >>> Mirja
> >>> 
> >>> 
> >>>> On 10. Jul 2019, at 13:39, Nabil Benamar <[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]> 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]> 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]> 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
> >>>>> 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/
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> ----------------------------------------------------------------------
> >>>>> 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]
> >>> 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]
> >> 
> > 
> 
> 
> 
> -- 
> 
> Best Regards
> 
> Nabil Benamar
> Associate Professor
> Department of Computer Sciences
> School of Technology
> Moulay Ismail University 
> Meknes. Morocco
> 
>