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

[Russ Housley <[e-mail]>]

Alex:

I did not add or remove any MUST statements.  I only added a phrase of rationale.

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