Re: [ipwave] Éric Vyncke's No Objection on draft-ietf-ipwave-ipv6-over-80211ocb-48: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Nabil,

Thank you for your prompt reply.

May I suggest to make the text of section 3 clearer about the participants IP-OBU and IP-RSU ?

About DAD, the reference should rather be SLAAC RFC 4862 and there should be more text in the document IMHO

Hope this helps

Regards

-éric


From: iesg <[e-mail]> on behalf of Nabil Benamar <[e-mail]>
Date: Sunday, 7 July 2019 at 22:16
To: Eric Vyncke <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, The IESG <[e-mail]>, Carlos Bernardos <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-ipwave-ipv6-over-80211ocb-48: (with COMMENT)

Dear Éric,

I would like to sincerely thank you for your review. Much appreciated!

Please see my answers in-line below.

On Sun, Jul 7, 2019 at 4:33 PM Éric Vyncke via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-ipwave-ipv6-over-80211ocb-48: No Objection

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/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

Intersting comment. The thing is that there is no association process in OCB. Though it belongs to the IEEE 802.11 familly, there are some differences.
As we said in the text:

OCB (outside the context of a basic service set - BSS): is a mode of

   operation in which a STA is not a member of a BSS and does not

   utilize IEEE Std 802.11 authentication, association, or data
   confidentiality.


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


The link model is the following: STA --- 802.11-OCB --- STA.  In
   vehicular networks, STAs can be IP-RSUs and/or IP-OBUs

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

I agree. We need to add a mention about who sends RAs

-- Missing --

Duplicate Address Detection is only mentioned in Appendix I and it is unclear
whether optimistic DAD (even for LLA) should/must be used.
In section 4.5.1, we say that :

This document is scoped for Address Resolution (AR) and Duplicate
   Address Detection (DAD) per RFC 4861<https://tools.ietf.org/html/rfc4861>

Thanks again.

--

Best Regards

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