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

[Mirja Kuehlewind <[e-mail]>]

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
> 
>