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

[Barry Leiba <[e-mail]>]

Thanks for the quick reply, Nabil, and I will clear my DISCUSS now in
anticipation of the reference change.

Barry

On Thu, Jul 11, 2019 at 4:39 AM Nabil Benamar <[e-mail]> wrote:
>
> 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
>
>