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

Russ Housley <housley@vigilsec.com> Tue, 16 July 2019 19:42 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870DD12004C for <its@ietfa.amsl.com>; Tue, 16 Jul 2019 12:42:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcqfvoYLVqT1 for <its@ietfa.amsl.com>; Tue, 16 Jul 2019 12:42:04 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F6C31200C5 for <its@ietf.org>; Tue, 16 Jul 2019 12:42:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8E470300AED for <its@ietf.org>; Tue, 16 Jul 2019 15:22:46 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5LOWaJ9Oyq1z for <its@ietf.org>; Tue, 16 Jul 2019 15:22:43 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 05A983004A7; Tue, 16 Jul 2019 15:22:42 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <B5DC7859-FDD4-4EF9-82A6-3DE09E068C77@kuehlewind.net>
Date: Tue, 16 Jul 2019 15:41:58 -0400
Cc: Nabil Benamar <n.benamar@est.umi.ac.ma>, IESG <iesg@ietf.org>, its <its@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D52B176-89B5-4322-93B9-2F6ABA6EFFFA@vigilsec.com>
References: <156269059867.15866.17764812378863873209.idtracker@ietfa.amsl.com> <CAD8vqFdPYvDOq2hELAyWiVw29214K7oBi7sH+TBzWTQmzQ33og@mail.gmail.com> <4FA280F6-FD9F-4DBA-991B-D0A3033FB124@kuehlewind.net> <CAD8vqFcMSQoGp3FavcR14a9B0k9s61+hy6urruXnGkdT-W0OYA@mail.gmail.com> <61138CEA-2D49-48C3-846E-D93DB17DDB27@kuehlewind.net> <CAP6QOWRx_tKDOZ65kykNt6vb0Fdj63+Z+RusLBq_hoknAv94=Q@mail.gmail.com> <2E61E2A9-10C4-4C7B-B738-EFC450D96EBF@vigilsec.com> <B5DC7859-FDD4-4EF9-82A6-3DE09E068C77@kuehlewind.net>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/MsGwfYL5E0KJu2McQ81AVti2-Fc>
Subject: Re: [ipwave] Mirja Kühlewind's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2019 19:42:08 -0000

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 <ietf@kuehlewind.net> 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 <housley@vigilsec.com> 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 <jkenney@us.toyota-itc.com> 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 <ietf@kuehlewind.net> wrote:
>>> Thanks. Removing this text entirely is a good option.
>>> 
>>> Mirja
>>> 
>>> 
>>>> On 10. Jul 2019, at 13:39, Nabil Benamar <n.benamar@est.umi.ac.ma> 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 <ietf@kuehlewind.net> 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 <n.benamar@est.umi.ac.ma> 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 <noreply@ietf.org> 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
>>> its@ietf.org
>>> 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: 650-694-4160. Mobile: 650-224-6644
>> 
>