[ipwave] Tsvart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46
Joerg Ott via Datatracker <noreply@ietf.org> Thu, 27 June 2019 16:38 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 D750012016A; Thu, 27 Jun 2019 09:38:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joerg Ott via Datatracker <noreply@ietf.org>
To: tsv-art@ietf.org
Cc: ietf@ietf.org, its@ietf.org, draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.98.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Joerg Ott <jo@acm.org>
Message-ID: <156165351682.21357.6959207590092474225@ietfa.amsl.com>
Date: Thu, 27 Jun 2019 09:38:36 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/LbzKLZ6vCaYoxGZg5d_0CuFJN9g>
Subject: [ipwave] Tsvart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46
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, 27 Jun 2019 16:38:37 -0000
Reviewer: Joerg Ott Review result: On the Right Track This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. The draft discusses the most basic operation of IPv6 over IEEE 802.11-OCB, i.e., a flavour of ad-hoc networks specifically for vehicular connectivity (formerly known as IEEE 802.11p). The document mainly covers question of mapping IPv6 packets to the MAC layer frames, discusses aspects of address assignment and subnets, and neighbour discovery. The core document is rather short but has extensive appendices. There are no clear transport issues in this document. The main relevant aspect would be MTU size, which is in line with standard IPv6. But the document discusses (section 4.2) that all IPv6 packets should be mapped to the same class of service. So, there is no service differentiation expected (diffserv, for example)? However, I do not consider the document to be really ready because of structure and writing clarity. This is surprising for version -46! There is a need for improvement to make the document properly understandable by the reader. I am actually wondering why this document is sent out for last call given the state the text is in. Detailed comments: In several places, the text reminds of patent jargon. Should I worry? There doesn't appear to be any IPR disclosure. p5, 1st line: packet->packets The use of RFC 2026 language needs improvement. sect. 4.4: transition time is not defined "no generic meaning" -- means what? This section is confusing. Please describe a concrete sequence of actions sect. 4.5: external references for standards are surely the right way. But the reader may benefit from some informal self-contained description. sect. 4.5.2: anythings needs to be said about multicast reception? sect 4.6: Clarify "A subnet may be formed over 802.11-OCB interfaces of vehicles that are in close range (not by their in-vehicle interfaces)." further. sect. 5: explain briefly how certificates are supposed to work with variable addresses. App. E: why would high mobility affect encapsulation"? App. G: Ok to show complete packet formats. But then maybe also give specific examples? And why do you describe this as capturing what is received rather than how to construct something to sent out? App. I: reliable multicast used incorrectly "TBD TBD TBD" Nits: "mode.A", "; The", "on another hand", "At application layer" "attacker can therefore just sit in the near range of vehicles" "perform attacks without needing to physically break any wall." "embarking an" "outdoors public environments" "attacker sniffers" "indoor settings" "eventual conflicts" "internet" expand all acronyms, also in the appendices Why has sect. 5.3 bullets?
- [ipwave] Tsvart last call review of draft-ietf-ip… Joerg Ott via Datatracker
- Re: [ipwave] Tsvart last call review of draft-iet… Nabil Benamar
- Re: [ipwave] [Tsv-art] Tsvart last call review of… Joerg Ott
- Re: [ipwave] [Tsv-art] Tsvart last call review of… Suresh Krishnan
- Re: [ipwave] [Tsv-art] Tsvart last call review of… Nabil Benamar
- Re: [ipwave] [Tsv-art] Tsvart last call review of… Joerg Ott
- Re: [ipwave] [Tsv-art] Tsvart last call review of… Nabil Benamar
- Re: [ipwave] [Tsv-art] Tsvart last call review of… Joerg Ott
- Re: [ipwave] [Tsv-art] Tsvart last call review of… Nabil Benamar
- Re: [ipwave] Tsvart last call review of draft-iet… Alexandre Petrescu
- Re: [ipwave] Tsvart last call review of draft-iet… Alexandre Petrescu
- Re: [ipwave] Tsvart last call review of draft-iet… Nabil Benamar
- Re: [ipwave] Tsvart last call review of draft-iet… Nabil Benamar
- Re: [ipwave] Tsvart last call review of draft-iet… Nabil Benamar
- Re: [ipwave] Tsvart last call review of draft-iet… Joerg Ott
- Re: [ipwave] Tsvart last call review of draft-iet… Nabil Benamar
- Re: [ipwave] Tsvart last call review of draft-iet… Nabil Benamar