Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11
draft-ietf-ipwave-ipv6-over-80211ocb-52

Thank you for addressing my DISCUSS and some of the COMMENTs.

(Resolved comments removed)

(5) Section 1.  Per “The resulting stack inherits from IPv6 over Ethernet [RFC2462], but operates over …”, what exactly is being inherited?  What does “inherited” mean in this case?

(6) Section 4.3.  Per “Among these types of addresses only the IPv6 link-local addresses can be formed using an EUI-64 identifier, in particular during transition time”, the meaning of the “in particular during transition time isn’t clear in the text.  Should it say "in particular as all clients are upgraded to this specification?"

(9) Section 5.  What is “protected 802.11” mentioned in “Such a link is less protected …”?

(10) Section 5.2.  SHA256 needs a reference.

(11) Editorial Nits
** Section 4.5.  Typo.  s/.A  A future/.  A future/

** Section 5.1.  Typo.  s/Futhermore/Furthermore/

** Section 5.1.  Typo.  s/pricavy/privacy/

** Section 5.2. Typo.  s/admninistered/ administered/

** Appendix H.  Duplicate word. s/section Section 2/Section 2/

Thank you  for the work put into this document. Interesting use case ;-)

Beside the 3 COMMENTs below, I have a question: my understanding is that this is a P2P link, so, layer-3 multicast packets could easily be sent over unicast layer-2 IF the other peer is known with its layer-2 address which is possibly known when forming a OCB "association" (but I am not a WiFi person at all). Just curious here ;-)

Regards,

-éric

== COMMENTS ==

-- Section 3 --

It is unclear whether a IP-OBU <-> IP-OBU is a use case of this document (it is mentionned in 4.6 though but it would help the reader to have it mentioned in section 3).

-- Section 4.4 --

In the discussion of SLAAC, there should be a mention on the presence or absence of Router Advertisement and if RA are used:
- which entity sends this RA (probably IP-RSU), 
- does RA contain PIO ?
- what are the recommendation for router lifetime (and PIO timers) ?

-- Missing --

Duplicate Address Detection is only mentioned in Appendix I and it is unclear whether optimistic DAD (even for LLA) should/must be used.

Thank you addressing my DISCUSS and COMMENT.

§4.3: I think that the MAYs used in this section are out of place as they only state facts and not Normative behavior.   s/MAY/may

§4.5.2: "Future improvement to this specification SHOULD consider solutions for these problems."  I understand the interest to consider the problems...but I don't think there's any Normative action that results from using SHOULD.  s/SHOULD/should

A very simple point to fix, and Nabil has already queued it up for the next revision:
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.

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

Thanks for addressing my discuss!

One editorial high level comment: I seams like all text that was somehow deemed as out fo scope for the main body of this document got stuffed into the appendix. Please consider removing what is really not needed in this document as these pages also take review and RFC Editor time, especially as they seem to have received less review and therefore have more nits.

nit: sec 4.5.2 s/in OCB mode.A  A future improvement/in OCB mode. A future improvement/