Re: [Tsv-art] Tsvart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46

[Nabil Benamar <[e-mail]>]

Dear reviewer,

Thank you for your comments.

Kindly, see my answers in-line below.



On Thu, Jun 27, 2019 at 5:38 PM Joerg Ott via Datatracker <[e-mail]>
wrote:

> 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
> [e-mail] 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)?
>

We have not treated this detail in the current document.



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

The document will be proofred once again before  becoming an RFC.

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

Are you referring to page 5 or paragraph 5?

>
> The use of RFC 2026 language needs improvement.
>

I didn't get your point. Would you please clarify on how we can tackle this
issue, if any?

>
> sect. 4.4: transition time is not defined
>

The IP-OBUs that are based on embedded platforms can only use the former
(MAC-based) whereas more powerful platforms (native x86) can use RFC8064. The
majority of IP-OBUs are embedded platforms.  I'm not sure whether they can
use RFC8064.


> "no generic meaning" -- means what?
>

No generic meaning' - means that the bits in the Interface Identifiers are
'opaque'.  Earlier, the u/g bits in IID had a significance (it meant
'unique/global'). A concept updated by RFC7136.



> This section is confusing. Please describe a concrete sequence of actions.


Would you show us how we can improve this section?

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

-- 

Best Regards

Nabil Benamar
Associate Professor
Department of Computer Sciences
School of Technology
Moulay Ismail University
Meknes. Morocco