[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”.
- [ipwave] Barry Leiba's Discuss on draft-ietf-ipwa… Barry Leiba via Datatracker
- Re: [ipwave] Barry Leiba's Discuss on draft-ietf-… Nabil Benamar
- Re: [ipwave] Barry Leiba's Discuss on draft-ietf-… Barry Leiba
- Re: [ipwave] Barry Leiba's Discuss on draft-ietf-… Nabil Benamar
- Re: [ipwave] Barry Leiba's Discuss on draft-ietf-… Alexandre Petrescu