[ipwave] Barry Leiba's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)

Barry Leiba via Datatracker <noreply@ietf.org> Thu, 11 July 2019 04:01 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: its@ietf.org
Delivered-To: its@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5836120098; Wed, 10 Jul 2019 21:01:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, Carlos Bernardos <cjbc@it.uc3m.es>, ipwave-chairs@ietf.org, cjbc@it.uc3m.es, its@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.98.3
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <156281766686.15253.17107868671965711674.idtracker@ietfa.amsl.com>
Date: Wed, 10 Jul 2019 21:01:06 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/YKtL0VxC3zd8xeqkFP9BWf5ZiB0>
Subject: [ipwave] Barry Leiba'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
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: Thu, 11 Jul 2019 04:01:07 -0000

Barry Leiba 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:
----------------------------------------------------------------------

A very simple point to fix:

I think that IEEE-802.11-2016 should be normative because it is the reference
for 802.11-OCB and is the subject of a MUST in Section 4.2.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

These are all editorial comments:

— Section 4.4 —

   For Interface Identifiers for
   IPv6 address of type 'Link-Local' are discussed in Section 4.3.

There’s something wrong with that sentence.  Maybe it’s just that the first
 word needs to be struck?

   Regardless of how
   to form the IID, its length is 64 bits, as is the case of the IPv6
   over Ethernet [RFC2464].

There’s something wrong with this sentence too, but I don’t know what the fix
is: I don’t know what the “as is the case...” part is meant to say.  Can you
try rephrasing?

   If
   semantically opaque IIDs are needed, they MAY be generated using the
   method for generating semantically opaque IIDs

This isn’t wrong with the “MAY”, but I think it really is just a non-keyword
“may”.

— Section 4.5.2 —

   The meaning of the value "3333"
   mentioned in that section 7 of [RFC2464]

As you’ve just given the section reference in the previous sentence, I think it
reads better to use the context and just say, “The meaning of the value "3333"
mentioned there”.

— Section 4.6 —

   A subnet may be formed over 802.11-OCB interfaces of vehicles that
   are in close range (not by their in-vehicle interfaces).

At first I tried to understand what the in-vehicle interfaces had to do with
the close range.  I think it’s clearer with this word order:

NEW
   When vehicles are in close range, a subnet may be formed over
   802.11-OCB interfaces (not by their in-vehicle interfaces).
END

   An IPv6 subnet on which Neighbor Discovery protocol (ND) can be
   mapped on an OCB network if all nodes share a single broadcast
   Domain, which is generally the case for P2P OCB links;

This isn’t a complete sentence: it has a subject, but no verb.  What is it
trying to say?  Also, the semicolon should be a period, as it’s not useful to
chain it onto the following sentence.

   strict (e.g. fast drive through IP-RSU coverage)

The “e.g.” needs a comma after it (or change it to “such as with”), and
“fast-drive-through” needs to be hyphenated, as a compound modifier.

— Section 5 —

   application-layer mechanisms are out-of-
   scope of this document.

Here, “out of scope” should not be hyphenated (it’s not a modifier).

   and performs attacks
   without needing to physically break any wall.

“and performs attacks” shoud be “and perform attacks”.
The “physically break any wall” part seems kind of odd, as there are clearly no
physical walls involved at all.  What are you really trying to say?

   The potential attack vectors are: MAC address spoofing, IP address
   and session hijacking, and privacy violation Section 5.1.

What is “Section 5.1” about?  Is that meant to be a citation, like “[Section
5.1]” ?

— Section 5.1 —

   A vehicle embarking an IP-
   OBU whose egress interface is 802.11-OCB may expose itself to
   eavesdropping and subsequent correlation of data; this may reveal
   data considered private by the vehicle owner; there is a risk of
   being tracked.

It’s awkward to chain three sentences with semicolons.  I would separate the
first one: change the first semicolon into a period.

   as dynamically changing MAC addresses Section 5.2, semantically
   opaque Interface Identifiers and stable Interface Identifiers
   Section 4.4.

The two section references should be bracketed, as “[Section 5.2]”.

   Futhermore, for
   pricavy concerns ([RFC8065]) recommends

Make it, “Futhermore, for privacy concerns, [RFC8065] recommends“.

— Section 5.1.1 —

   means, or other visual information (car color, others) MAY constitute
   privacy risks.

This “MAY” should definitely be “may”: it’s just a statement of fact.

— Section 5.2 —

   In 802.11-OCB networks, the MAC addresses MAY change during well
   defined renumbering events.

Also a statement of fact, so “may”.