Subject: Re: [ipwave] Tsvart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46

From: Nabil Benamar <[email-masked]>
Date: Wed, 3 Jul 2019 19:11:55 +0100

Dear reviewer,

Thank you for your comments.

Kindly, see my answers in-line below.

On Thu, Jun 27, 2019 at 5:38 PM Joerg Ott via Datatracker <[email-masked]>
wrote:

> Reviewer: Joerg Ott
> Review result: On the Right Track
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the
> document's
> authors and WG to allow them to address any issues raised and also to the
> IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> [email-masked] if you reply to or forward this review.
>
> The draft discusses the most basic operation of IPv6 over IEEE 802.11-OCB,
> i.e., a flavour of ad-hoc networks specifically for vehicular connectivity
> (formerly
>  known as IEEE 802.11p). The document mainly covers question of mapping
> IPv6
> packets to the MAC layer frames, discusses aspects of address assignment
> and
> subnets, and neighbour discovery. The core document is rather short but has
> extensive appendices.
>
> There are no clear transport issues in this document. The main relevant
> aspect would
> be MTU size, which is in line with standard IPv6. But the document
> discusses (section 4.2)
> that all IPv6 packets should be mapped to the same class of service. So,
> there is no
> service differentiation expected (diffserv, for example)?
>

We have not treated this detail in the current document.

>
> However, I do not consider the document to be really ready because of
> structure
> and writing clarity. This is surprising for version -46! There is a need
> for improvement
> to make the document properly understandable by the reader. I am actually
> wondering
> why this document is sent out for last call given the state the text is in.
>

The document will be proofred once again before  becoming an RFC.

>
> Detailed comments:
>
> In several places, the text reminds of patent jargon. Should I worry?
> There doesn't appear
> to be any IPR disclosure.
>
> p5, 1st line: packet->packets
>

Are you referring to page 5 or paragraph 5?

>
> The use of RFC 2026 language needs improvement.
>

I didn't get your point. Would you please clarify on how we can tackle this
issue, if any?

>
> sect. 4.4: transition time is not defined
>

The IP-OBUs that are based on embedded platforms can only use the former
(MAC-based) whereas more powerful platforms (native x86) can use RFC8064. The
majority of IP-OBUs are embedded platforms.  I'm not sure whether they can
use RFC8064.

> "no generic meaning" -- means what?
>

No generic meaning' - means that the bits in the Interface Identifiers are
'opaque'.  Earlier, the u/g bits in IID had a significance (it meant
'unique/global'). A concept updated by RFC7136.

> This section is confusing. Please describe a concrete sequence of actions.

Would you show us how we can improve this section?

>
>
> sect. 4.5: external references for standards are surely the right way. But
> the reader may benefit from some informal self-contained description.
>
> sect. 4.5.2: anythings needs to be said about multicast reception?
>
> sect 4.6: Clarify "A subnet may be formed over 802.11-OCB interfaces of
> vehicles that are in close range (not by their in-vehicle interfaces)."
> further.
>
> sect. 5: explain briefly how certificates are supposed to work with
> variable addresses.
>
> App. E: why would high mobility affect encapsulation"?
>
> App. G: Ok to show complete packet formats. But then maybe also give
> specific examples?
> And why do you describe this as capturing what is received rather than how
> to construct
> something to sent out?
>
> App. I: reliable multicast used incorrectly
> "TBD TBD TBD"
>
> Nits: "mode.A", "; The", "on another hand", "At application layer"
> "attacker can therefore just sit in the near range of vehicles"
> "perform attacks without needing to physically break any wall."
> "embarking an"
> "outdoors public environments"
> "attacker sniffers"
> "indoor settings"
> "eventual conflicts"
> "internet"
> expand all acronyms, also in the appendices
>
> Why has sect. 5.3 bullets?
>
>

-- 

Best Regards

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

---

From: Joerg Ott <[email-masked]>
Date: Thu, 4 Jul 2019 16:42:28 +0200

Hi,

quick responses inline:

> 
>     There are no clear transport issues in this document. The main
>     relevant aspect would
>     that all IPv6 packets should be mapped to the same class of service.
>     So, there is no

Indeed.  But the current document states that *all* IPv6 packets MUST be
mapped to the same class of service.  You should leave room for refining
this in the future since I would expect different traffic classes to
appear.

>     However, I do not consider the document to be really ready because
>     of structure
>     and writing clarity. This is surprising for version -46! There is a
>     need for improvement
>     to make the document properly understandable by the reader. I am
>     actually wondering

I am sorry but this is not acceptable.  You are asking other people
to read the document and comment on it.  As such, we may certainly
expect that what we get to review in last call is ready for RFC.
This document clearly is not.

>     Detailed comments:
> 
>     In several places, the text reminds of patent jargon. Should I
>     worry? There doesn't appear

Here, I'd really like to get an explicit response.

> Are you referring to page 5 or paragraph 5?

Page 5.  (Otherwise I would write para 5.)

> I didn't get your point. Would you please clarify on how we can tackle 
> this issue, if any?

RFC 2026 defines the proper use of MAY, MUST, SHOULD.  The document
does not appear to be consistently using the capitalized words properly
in all cases.  Just go through the document and check all pieces of
this normative language.

>     sect. 4.4: transition time is not defined >
> (MAC-based) whereas more powerful platforms (native x86) can use 
> RFC8064.The majority of IP-OBUs are embedded platforms.  I'm not sure 
> whether they can use RFC8064.

Ahh, this is what you mean by transition time.  I assumed that this 
would refer to the time moving from one point of attachment to another
or so.  Can you say a bit more to make this clear?
> No generic meaning' - means that the bits in the Interface Identifiers 
> are 'opaque'.  Earlier, the u/g bits in IID had a significance (it meant 

Great. Then specify opaque -- generic has no meaning this in this
context.

> Would you show us how we can improve this section?

Well, this should be up to the WG.  Just read it and try to
understand what it says rather than confirming what you know.

But, in general, as a reader I would expect to get a clear recipe
with explicit steps.

There are two kinds of identifiers: A and B.  If you need A, follow
these steps: 1., 2., 3., ...  If you need B, then ...
Here is some guidance when A or B is preferred.

Most of this may be in the section but it is hard to extract.

>     vehicles that are in close range (not by their in-vehicle
>     interfaces)." further.
> 
>     And why do you describe this as capturing what is received rather
>     than how to construct
>     something to sent out?
> 

In short: there is A LOT of work to be done before this is ready.

Jörg

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 4 Jul 2019 17:26:53 +0000

Hi Joerg,
  I just want to respond to two of your comments. I will let the authors chime in on the other comments.

> On Jul 4, 2019, at 10:42 AM, Joerg Ott <[email-masked]> wrote:
> ...

Are their specific parts of the document that you are concerned about here on the clarity front? I have read the document and have not had any clarity issues (but that might be because I have been reading this for too long).

> ...

The authors have confirmed that they have filed any necessary IPR disclosures as per BCP78/79 as documented in the shepherd writeup.

Thanks
Suresh

---

From: Nabil Benamar <[email-masked]>
Date: Thu, 4 Jul 2019 18:59:38 +0100

Hi Suresh, Jorg

Thank you for answering the two comments. I would not have said better!

On Thu, Jul 4, 2019 at 6:26 PM Suresh Krishnan <[email-masked]> wrote:

> Are their specific parts of the document that you are concerned about here
> on the clarity front? I have read the document and have not had any clarity
> issues (but that might be because I have been reading this for too long).
>
> > ...
> >>    Detailed comments:
> The authors have confirmed that they have filed any necessary IPR
> disclosures as per BCP78/79 as documented in the shepherd writeup.
>
> Thanks
> Suresh

-- 

Best Regards

Nabil Benamar
Associate Professor

---

From: Joerg Ott <[email-masked]>
Date: Thu, 4 Jul 2019 21:26:00 +0200

Hi,

re claritry: given the number of more than nits I found, the document
is clearly not ready.  And, sure, once you read something a number of
times (and were part of the discussion), this clearly has an effect.

Re patent jargon: ok.  I just looked at the IPR page and didn't see
anything come up.  It still appears strange to me to use this kind of
language in an Internet Draft.

Jörg

---

From: Nabil Benamar <[email-masked]>
Date: Thu, 4 Jul 2019 21:31:53 +0100

Hi,

Quick answers inline

> this in the future since I would expect different traffic classes to

We have not mentioned the class of service in the current document. We have
talked about address types.

> This document clearly is not.

If you see any remaing typos or grmmatical errors, kindly point us to the
exact lines.

> Here, I'd really like to get an explicit response.

It is simple. There is no IPR!

> >     p5, 1st line: packet->packets

Corrected in -47

> Page 5.  (Otherwise I would write para 5.)

Ok.

> in all cases.  Just go through the document and check all pieces of

Thank you for the reminder. However, we have already extinsively discussed
ALL of them in the mailing list. You may check -47.

> or so.  Can you say a bit more to make this clear?

Yes, I thought you were refering to  the length of time during which we
transition from the use of link-local addresses formed by deriving from
hardwired 48bit MAC identifiers, to the time where the link-local address
formed by deriving from more random identifiers (RFC8064).
Still, I'm not sure if IP-OBUs can use RFC8064! We need to ask in 6man.

> Ok. I agree.

> >     sect. 4.5.2: anythings needs to be said about multicast reception?
We have already pointed out that "These issues may be
   exacerbated in OCB mode. A  Future improvement to this specification

   SHOULD consider solutions for these problems. "

> >     vehicles that are in close range (not by their in-vehicle

in close range so that we can consider it's a P2P link.

> >     App. I: reliable multicast used incorrectly
Corrected in -47

> >     expand all acronyms, also in the appendices

Agreed. I will correct all these Nits. Thank you for pointing this out.

> >     Why has sect. 5.3 bullets?

Ok. We can remove those bullets

-- 

Best Regards

Nabil Benamar
Associate Professor

---

From: Joerg Ott <[email-masked]>
Date: Thu, 4 Jul 2019 22:40:14 +0200

Just one quick note: I am writing the TSV-ART review.  This means that I
am not necessarily on the IPWAVE mailing list, so I am not following
what you are discussing there.  It's good to see a new version -47
having done already some fixed (I got asked to review -46 when the WG
sent this off for last call).

If you send out an incomplete document (such as -46) for review, you
are wasting people's time because all those reviewers will have to go
through yet another version. This is, simply put, not helpful.

So, please, before the next version goes out for a last call, -5x or
something, please make sure that this is in a shape that you could
see published as is.

Jörg

On 04.07.19 22:31, Nabil Benamar wrote:
> Hi,
> 
> Quick answers inline
> 
> On Thu, Jul 4, 2019 at 3:42 PM Joerg Ott <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
>     quick responses inline:
> 
>      >
> We have not mentioned the class of service in the current document. We 
> have talked about address types.
> 
> 
>      >     why this document is sent out for last call given the state
>     the text
>      >     is in.
>      >
>      >
> If you see any remaing typos or grmmatical errors, kindly point us to 
> the exact lines.
> 
> 
>      >     Detailed comments:
>      >
> Thank you for the reminder. However, we have already extinsively 
> discussed ALL of them in the mailing list. You may check -47.
> 
> 
> hardwired 48bit MAC identifiers, to the time where the link-local 
> address formed by deriving from more random identifiers (RFC8064).
> We have already pointed out that "These issues may be exacerbated in OCB 
> mode.A Future improvement to this specification
> 
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art
>

---

From: Nabil Benamar <[email-masked]>
Date: Thu, 4 Jul 2019 21:50:56 +0100

I'm aware of this point. The thing is that I published -47 as a response
to Gen-ART reviewer for this draft. At the same time, we received your
feedback on -46!!

> through yet another version. This is, simply put, not helpful.

I agree. However, I did send version -47 after the LAST CALL deadline which
was 26 June. I did not know that there will be other incoming reviews!!

> something, please make sure that this is in a shape that you could

Thank you for the advice, but why necessairly -5x?

> >      >     This section is confusing. Please describe a concrete
> sequence of
> >      >     actions.
> >      >
> >      >
> >      >     sect. 4.5: external references for standards are surely the
> right
> >      >     way. But

-- 

Best Regards

Nabil Benamar
Associate Professor

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 5 Jul 2019 13:15:27 +0200

Le 27/06/2019 à 18:38, Joerg Ott via Datatracker a écrit :
[...]

The paragraph in question is this:
> 
> Appendix E.  Design Considerations
> 
> The networks defined by 802.11-OCB are in many ways similar to other 
> networks of the 802.11 family.  In theory, the encapsulation of IPv6 
> over 802.11-OCB could be very similar to the operation of IPv6 over 
> other networks of the 802.11 family.  However, the high mobility, 
> strong link asymmetry and very short connection makes the 802.11-OCB 
> link significantly different from other 802.11 networks.  Also, the 
> automotive applications have specific requirements for reliability, 
> security and privacy, which further add to the particularity of the 
> 802.11-OCB link.

There a huge list of Design Considerations in the main matter.  More and
more reviews led to skinning it to just one paragraph, depicted above.

Let me try to answer to the question of why would high mobility affect 
encapsulation.

First, the word encapsulation seems to have captured your attention.  I 
hope it is for a good reason, but frankly speaking I do not know the 
reason why it attracted it.  To clarify, let me say that the word 
'encapsulation' was used to signify 'carrying' IPv6 datagrams on 
802.11-OCB.  One expects IPv6 to be carried over OCB as over WiFi. 
('encapsulation' was not used to mean IPv6-in-IPv6 encapsulation and 
friends).

The high mobility in OCB is contrasted to low (or no) mobility in WiFi - 
it means that in WiFi users are near a fixed Access Point and dont move 
much.  But in OCB there are no access points and cars move a lot.

High mobility in OCB may need to avoid potential interference in order
to ensure safety.  TO achieve that, it may be possible that QoS concents
become more mandatory on OCB links (than on WiFi; on WiFi the QoS
concepts are almost absent in implementations).  Thus, there may be a
need of some mapping between IPv6 QoS-specific fields and 802.11-OCB 
QoS-specific fields.  There may be need of other  QoS-specific fields.

So, whereas an IPv6-over-WiFi spec (which does not exist, btw) has no 
mapping of QoS fields of how  IPv6 is 'carried' (encapsulated) on WiFi, 
an IPv6-over-OCB would need some mapping of this sort, so that IPv6 is 
better 'carried' over OCB.  Because of mobility.

QoS is just an example of why encapsulating (carrying) IPv6 on OCB may 
need more than just what is needed by carring IPv6 on WiFi.

There are other examples: IPv6 addressing in OCB links requires human 
intervention often - it's not as plug and play as IPv6 over WiFi.  That 
needs easy to remember and subnet-specific link local addresses, like 
fe80:1::1/32.  These addresses dont exist on IPv6 altogher, let alone 
IPv6-over-WiFi.

There are more examples.

Remark my own difficulty  of speculating on something which does not 
exist: IPv6 over WiFi specification.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 5 Jul 2019 13:16:43 +0200

note: my text is an explanation of how I see things.  I am not an author 
of the OCB document.  The OCB document has an Editor, and it belongs to 
the WG IPWAVE.

Alex

Le 05/07/2019 à 13:15, Alexandre Petrescu a écrit :
> First, the word encapsulation seems to have captured your attention.  
> I hope it is for a good reason, but frankly speaking I do not know the 
> The high mobility in OCB is contrasted to low (or no) mobility in WiFi 
> - it means that in WiFi users are near a fixed Access Point and dont 
> move much.  But in OCB there are no access points and cars move a lot.
>
> mapping of QoS fields of how  IPv6 is 'carried' (encapsulated) on 
> WiFi, an IPv6-over-OCB would need some mapping of this sort, so that 
> IPv6 is better 'carried' over OCB.  Because of mobility.
>
> intervention often - it's not as plug and play as IPv6 over WiFi.  
> That needs easy to remember and subnet-specific link local addresses, 
> like fe80:1::1/32.  These addresses dont exist on IPv6 altogher, let 
> alone IPv6-over-WiFi.
>
> There are more examples.
>

---

From: Nabil Benamar <[email-masked]>
Date: Fri, 5 Jul 2019 12:23:32 +0100

Dear Joerg,

I want to add more clarification to one of your comments

> vehicles that are in close range (not by their in-vehicle interfaces)."

The in-vehicle interface is the Ethernet interface of a Router situated in
the car.  By default, a Router has many and different interfaces. This
Router (in the car) has an Ethernet interface (in-vehicle) and an
802.11-OCB interface.  That OCB interface has an antenna towards the
outside of the car.

The subnet referred to by this text, is formed by the OCB interfaces (not
the Ethernet interfaces - 'in-vehicle') of the cars nearby.
The 'in-vehicle' interface can be Ethernet, Bluetooth or even WiFi (WiFi
onboard).

-- 

Best Regards

Nabil Benamar
Associate Professor

---

From: Nabil Benamar <[email-masked]>
Date: Fri, 5 Jul 2019 21:28:11 +0100

Hi Alex,

Thank you for your exhaustive clarifications!

Indeed, the word encapsulation may be understood/interpreted in different
ways!

I will replace it with 'Transportation' in the next update.

-- 

Best Regards

Nabil Benamar
Associate Professor

---

From: Nabil Benamar <[email-masked]>
Date: Mon, 8 Jul 2019 06:45:13 +0100

Hi Joerg,

I have submitted -48 which fixes all issues you mentioned in your review.
Please have a look and let me know if this version is OK.

Thank you.

-- 

Best Regards

Nabil Benamar
Associate Professor

---

From: Joerg Ott <[email-masked]>
Date: Mon, 8 Jul 2019 19:14:26 +0200

Hi Nabil,

are there any other pending updates or is this one final concerning all
the LC reviews?

Best,
Jörg

On 08.07.19 07:45, Nabil Benamar wrote:
> On Fri, Jul 5, 2019 at 12:23 PM Nabil Benamar <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Dear Joerg,
> 
>     The in-vehicle interface is the Ethernet interface of a Router
>     situated in the car. By default, a Router has many and different
>     interfaces. This Router(in the car) has an Ethernet interface
>     (in-vehicle) and an 802.11-OCB interface.  That OCB interface has an
>     antenna towards the outside of the car.
> 
>     The subnet referred to by this text, is formed by the OCB interfaces
>     (not the Ethernet interfaces - 'in-vehicle') of the cars nearby.
> 
>     The 'in-vehicle' interface can be Ethernet, Bluetooth or even WiFi
>     (WiFi onboard).
> 
> 
> 
> 
> 
> 
> 
>     -- 
> 
>     Best Regards
> 
>     Nabil Benamar
>     Associate Professor

---

From: Nabil Benamar <[email-masked]>
Date: Mon, 8 Jul 2019 19:28:54 +0100

Hi Joerg,

Thank you for your email.

I received some minor comments that I will reflect in a new version -49 to
be posted tonight.

---

From: Nabil Benamar <[email-masked]>
Date: Tue, 9 Jul 2019 10:48:52 +0100

Hi Joerg,

Just to let you know that I posted -49 yesterday.
Your comments are welcome.

https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-49

-- 

Best Regards

Nabil Benamar
Associate Professor