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

[Nabil Benamar <[e-mail]>]

Hi Barry,

Thank you for your review.

I'll update this reference in the next version.
Thank you for proofreading the paper and for your comments, which will be
reflected in the next version.

Much appreciated.

On Thu, Jul 11, 2019 at 5:01 AM Barry Leiba via Datatracker <
[e-mail]> wrote:

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

-- 

Best Regards

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