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

[Russ Housley <[e-mail]>]

Alex:

Of course, jamming will deny service, regardless of the values used for the QoS bits.

What would you like to see instead of the second MUST?

Russ

> On Jul 15, 2019, at 9:32 AM, Alexandre Petrescu <[e-mail]> wrote:
> 
> 
> 
> Le 13/07/2019 à 04:53, Russ Housley a écrit :
>> Alex:
>> I did not add or remove any MUST statements.  I only added a phrase of rationale.
> 
> I agree that the 2nd MUST was there before, and that a phrase of rationale was added.
> 
> The phrase of rationale motivates the 2nd MUST.  It is logical.
> 
> I agree with the rationale but I disagree with the MUST.
> 
> (It is possible to implement the rationale without doing the MUST.  I.e. it is possible to guarantee time-sensitiveness and criticality of safety by increasing bandwidth; reserving QoS priorities is but an alternative to satisfy the rationale within a limited bandwidth.)
> 
> (the bandwidth available on 802.11 in OCB mode currently peaks at 16Mbit/s theoretical within a range of approximately 1km measured.  The number of OCB interfaces in an OCB subnet of that physical size is less than hundreds, and certainly not thousands.  Within these dimensions, criticality and time-sensitiveness could be happening naturally.  An increase in theoretical bandwidth to approximately 54mbit/s would be even more sufficient)
> 
> (disturbing the time-sensitiveness and criticality of safety can be realized despite the guarantees offered by QoS priorities; radio jamming and IP security attacks are easy to perform and would overcome QoS priorities.)
> 
> Alex
> 
>> Russ
>>> On Jul 12, 2019, at 8:32 AM, Alexandre Petrescu <[e-mail]> wrote:
>>> 
>>> hats and freedoms are valuable.
>>> 
>>> I disagree with the second MUST.  I will write a draft IPv6-over-OCB without QoS headers.
>>> 
>>> Alex
>>> 
>>> Le 11/07/2019 à 17:51, Russ Housley a écrit :
>>>> 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] <mailto:[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
>>>>>    > > 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] <mailto:[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]
>>>> _______________________________________________
>>>> its mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/its
> 
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its