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

[Alexandre Petrescu <[e-mail]>]

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
>