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

[Nabil Benamar <[e-mail]>]

Much much appreciated, Barry!

Thanks to everybody reviewing, commenting and proofreading this draft.

Yours.

On Thu, Jul 11, 2019 at 2:36 PM Barry Leiba <[e-mail]> wrote:

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


-- 

Best Regards

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