Subject: Re: [ipwave] New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-45.txt

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Wed, 1 May 2019 14:00:53 +0200

Hi Sri,

OK, I think it’s a good idea to add more details. Nabil, can you please
draft something and share it on the mailing list so we can agree on it and
then add it to the draft?

Thanks!

Carlos

On Tue, 30 Apr 2019 at 18:08, Sri Gundavelli (sgundave) <[email-masked]>
wrote:

> Hi Nabil:
>
> I think IESG will ask for more details than this. You may want to qualify
> in very specific terms on where the default ND is expected to work as
> expected and where it will fail.
>
> You may want to construct some text based on the Brian’s review.
>
>
> Sri
>
>
> From: its <[email-masked]> on behalf of NABIL BENAMAR <
> [email-masked]>
> Date: Tuesday, April 30, 2019 at 3:30 AM
> To: "[email-masked]" <[email-masked]>
> Subject: Re: [ipwave] New Version Notification for
> draft-ietf-ipwave-ipv6-over-80211ocb-45.txt
>
> Dear IPwavers
>
> Yesterday, we have submitted a new version (45) of the
> draft-ietf-ipwave-ipv6-over-80211ocb.
> Based on the messages exchanged in the ML, we have tightened the scope of
> this document by precising in the abstract the following:
>
> Old:
>
> "This document describes these parameters for IPv6 and IEEE 802.11-OCB
> networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other
> known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer."
>
> New:
>
> "This document describes how IPv6 (including addressing and basic ND) can
> be used to communicate among nodes in range of one another over IEEE
> 802.11-OCB. Optimizations and usage of IPv6 over more complex scenarios is
> not covered and is subject of future work."
>
>
> Your comments are Welcome as always.
>
>
>
> On Mon, Apr 29, 2019 at 10:03 PM NABIL BENAMAR <[email-masked]>
> wrote:
>
>> Dear IPWAVErs,
>>
>> This is the version -45.
>>
>> We have changed the text in the abstract to narrow the scope of this
>> draft.
>>
>> Your comments are welcome!
>>
>>
>>
>> ---------- Forwarded message ---------
>> From: <[email-masked]>
>> Date: Mon, Apr 29, 2019 at 9:58 PM
>> Subject: New Version Notification for
>> draft-ietf-ipwave-ipv6-over-80211ocb-45.txt
>> To: Jerome Haerri <[email-masked]>, <[email-masked]
>> <ipwave-chairs@ietf..org>>, Jerome Haerri <[email-masked]>,
>> Nabil Benamar <[email-masked]>, Thierry Ernst <
>> [email-masked]>, Jong-Hyouk Lee <[email-masked]>
>>
>>
>>
>> A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-45.txt
>> has been successfully submitted by Nabil Benamar and posted to the
>> IETF repository.
>>
>> Name:           draft-ietf-ipwave-ipv6-over-80211ocb
>> Revision:       45
>> Title:          Transmission of IPv6 Packets over IEEE 802.11 Networks
>> operating in mode Outside the Context of a Basic Service Set
>> (IPv6-over-80211-OCB)
>> Document date:  2019-04-29
>> Group:          ipwave
>> Pages:          43
>> URL:
>> https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-45.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
>> Htmlized:
>> https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-45
>>
>> Abstract:
>>    In order to transmit IPv6 packets on IEEE 802.11 networks running
>>    outside the context of a basic service set (OCB, earlier "802.11p")
>>    there is a need to define a few parameters such as the supported
>>    Maximum Transmission Unit size on the 802.11-OCB link, the header
>>    format preceding the IPv6 header, the Type value within it, and
>>    others.  This document describes how IPv6 (including addressing and
>>    basic ND) can be used to communicate among nodes in range of one
>>    another over IEEE 802.11-OCB.  Optimizations and usage of IPv6 over
>>    more complex scenarios is not covered and is subject of future work.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>>
>> --
>>
>> Best Regards
>>
>> Nabil Benamar
>> Associate Professor
>> Department of Computer Sciences
>> School of Technology
>> University Moulay Ismail
>> Meknes. Morocco
>>
>>
>>
>
> --
>
> Best Regards
>
> Nabil Benamar
> Associate Professor
> Department of Computer Sciences
> School of Technology
> University Moulay Ismail
> Meknes. Morocco
>
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>
-- 
Sent from a mobile device, please excuse any brevity or typing errors.

---

From: NABIL BENAMAR <[email-masked]>
Date: Wed, 1 May 2019 18:42:06 +0100

Hi Sri,

Thank you for your message.

In the current version of the draft there are two clear texts about the ND
limitations:

The subnet structure on which the Neighbor Discovery protocol (ND) *on*

*   OCB works ok is a single-link subnet*; the status of ND operation on a

   subnet that covers *multiple OCB links* that repeat the signal at PHY

   layer, or the messages at MAC layer, *is unknown*.

The baseline Neighbor Discovery protocol (ND) [RFC4861
<https://tools.ietf.org/html/rfc4861>] MUST be used

   over 802.11-OCB links.  Transmitting ND packets may prove to have

   some performance issues.  These issues may be exacerbated in OCB

   mode.  Solutions for these problems SHOULD consider the OCB mode of

   operation.  The best of current knowledge indicates the kinds of

   issues that may arise with ND in OCB mode; they are described in

   Appendix J
<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#appendix-J>
.

Can I ask you what should be added more than this?

Thank you again for your continuous help.

-- 

Best Regards

Nabil Benamar
Associate Professor

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 2 May 2019 01:51:24 +0000

Hi Nabil,

You may want to look at all the threads from Brian and others on various issues, and craft some text summarizing those gaps/issues. In your shoe, I would probably reach out to them to workout the text, or find some agreement that they are OK with the below text.

My idea is not to create more work here, but I am almost certain this will come back.

Regards
Sri

From: NABIL BENAMAR <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 1, 2019 at 10:42 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ipwave] New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-45.txt

Hi Sri,

In the current version of the draft there are two clear texts about the ND limitations:

The subnet structure on which the Neighbor Discovery protocol (ND) on

   OCB works ok is a single-link subnet; the status of ND operation on a

   subnet that covers multiple OCB links that repeat the signal at PHY

   layer, or the messages at MAC layer, is unknown.

The baseline Neighbor Discovery protocol (ND) [RFC4861<https://tools.ietf.org/html/rfc4861>] MUST be used

   Appendix J<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#appendix-J>.

On Tue, Apr 30, 2019 at 5:08 PM Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Nabil:

I think IESG will ask for more details than this. You may want to qualify in very specific terms on where the default ND is expected to work as expected and where it will fail.

Sri

From: its <[email-masked]<mailto:[email-masked]>> on behalf of NABIL BENAMAR <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 30, 2019 at 3:30 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ipwave] New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-45.txt

Dear IPwavers

Yesterday, we have submitted a new version (45) of the draft-ietf-ipwave-ipv6-over-80211ocb.
Based on the messages exchanged in the ML, we have tightened the scope of this document by precising in the abstract the following:

Old:

"This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer."

New:

"This document describes how IPv6 (including addressing and basic ND) can be used to communicate among nodes in range of one another over IEEE 802.11-OCB. Optimizations and usage of IPv6 over more complex scenarios is not covered and is subject of future work."

On Mon, Apr 29, 2019 at 10:03 PM NABIL BENAMAR <[email-masked]<mailto:[email-masked]>> wrote:
Dear IPWAVErs,

This is the version -45.

We have changed the text in the abstract to narrow the scope of this draft.

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Apr 29, 2019 at 9:58 PM
Subject: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-45.txt
To: Jerome Haerri <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:ipwave-chairs@ietf..org>>, Jerome Haerri <[email-masked]<mailto:[email-masked]>>, Nabil Benamar <[email-masked]<mailto:[email-masked]>>, Thierry Ernst <[email-masked]<mailto:[email-masked]>>, Jong-Hyouk Lee <[email-masked]<mailto:[email-masked]>>

Name:           draft-ietf-ipwave-ipv6-over-80211ocb
Revision:       45
Title:          Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
Document date:  2019-04-29
Group:          ipwave
Pages:          43
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-45.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-45

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

--

Best Regards

Nabil Benamar
Associate Professor

--

Best Regards

Nabil Benamar
Associate Professor

--

Best Regards

Nabil Benamar
Associate Professor

---

From: NABIL BENAMAR <[email-masked]>
Date: Thu, 2 May 2019 08:13:15 +0100

Thank you Sri....will do without hesitation!

On Thu, May 2, 2019, 02:51 Sri Gundavelli (sgundave) <[email-masked]>
wrote:

> Hi Nabil,
>
> You may want to look at all the threads from Brian and others on various
> issues, and craft some text summarizing those gaps/issues. In your shoe, I
> would probably reach out to them to workout the text, or find some
> agreement that they are OK with the below text.
>
> From: NABIL BENAMAR <[email-masked]>
> To: Sri Gundavelli <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>> "This document describes how IPv6 (including addressing and basic ND)
>> can be used to communicate among nodes in range of one another over IEEE

---

From: NABIL BENAMAR <[email-masked]>
Date: Fri, 3 May 2019 18:30:51 +0100

Hi Brian

I'm coming back to you to ask you what are the remaining points about all
ND issues that you still need to be addressed in the current version of the
draft.

On Thu, May 2, 2019, 08:13 NABIL BENAMAR <[email-masked]> wrote:

>>> I think IESG will ask for more details than this. You may want to
>>> qualify in very specific terms on where the default ND is expected to work
>>> as expected and where it will fail.
>>>
>>> Based on the messages exchanged in the ML, we have tightened the scope
>>> of this document by precising in the abstract the following:
>>>
>>> Old:
>>>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 4 May 2019 08:18:59 +1200

Nabil,

It's on my reading list, which has got a bit long in redent days.

Regards
   Brian Carpenter

On 04-May-19 05:30, NABIL BENAMAR wrote:
> Hi Brian 
> 
> I'm coming back to you to ask you what are the remaining points about all ND issues that you still need to be addressed in the current version of the draft.
> 
> On Thu, May 2, 2019, 08:13 NABIL BENAMAR <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     On Thu, May 2, 2019, 02:51 Sri Gundavelli (sgundave) <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         Hi Nabil,
> 
>         From: NABIL BENAMAR <[email-masked] <mailto:[email-masked]>>
>         To: Sri Gundavelli <[email-masked] <mailto:[email-masked]>>
>         Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>         The subnet structure on which the Neighbor Discovery protocol (ND) _on_
> 
>         _   OCB works ok is a single-link subnet_; the status of ND operation on a
> 
>            subnet that covers _multiple OCB links_ that repeat the signal at PHY
> 
>            layer, or the messages at MAC layer, _is unknown_.
> 
> 
> 
>         The baseline Neighbor Discovery protocol (ND) [RFC4861 <https://tools.ietf.org/html/rfc4861>] MUST be used
> 
>            Appendix J <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#appendix-J>.
> 
> 
>         On Tue, Apr 30, 2019 at 5:08 PM Sri Gundavelli (sgundave) <[email-masked] <mailto:[email-masked]>> wrote:
> 
>             Hi Nabil:
> 
>             From: its <[email-masked] <mailto:[email-masked]>> on behalf of NABIL BENAMAR <[email-masked] <mailto:[email-masked]>>
>             To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>             On Mon, Apr 29, 2019 at 10:03 PM NABIL BENAMAR <[email-masked] <mailto:[email-masked]>> wrote:
> 
>                 Dear IPWAVErs,
> 
>                 This is the version -45. 
> 
>                 From: <[email-masked] <mailto:[email-masked]>>
>                 To: Jerome Haerri <[email-masked] <mailto:[email-masked]>>, <[email-masked] <mailto:ipwave-chairs@ietf..org>>, Jerome Haerri <[email-masked] <mailto:[email-masked]>>, Nabil Benamar <[email-masked] <mailto:[email-masked]>>, Thierry Ernst <[email-masked] <mailto:[email-masked]>>, Jong-Hyouk Lee <[email-masked] <mailto:[email-masked]>>
> 
> 
> 
>                 until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org>.
> 
>                 The IETF Secretariat
> 
> 
> 
>                 -- 
> 
>                 Best Regards
> 
>                 Nabil Benamar
>                 Associate Professor

---

From: NABIL BENAMAR <[email-masked]>
Date: Fri, 3 May 2019 21:23:29 +0100

Thanks Brian for accepting to help. I need to come up with a text that will
make everybody satisfied!  I hope so ...

On Fri, May 3, 2019 at 9:19 PM Brian E Carpenter <
[email-masked]> wrote:

> > I'm coming back to you to ask you what are the remaining points about
> all ND issues that you still need to be addressed in the current version of
> the draft.
> >
> >     On Thu, May 2, 2019, 02:51 Sri Gundavelli (sgundave) <
> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >         Hi Nabil,
> >
> >         You may want to look at all the threads from Brian and others on
> various issues, and craft some text summarizing those gaps/issues. In your
> shoe, I would probably reach out to them to workout the text, or find some
> >         The baseline Neighbor Discovery protocol (ND) [RFC4861 <
> https://tools.ietf.org/html/rfc4861>] MUST be used
> >
> >            Appendix J <
> https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#appendix-J
> >.
> >
> >
> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >             Hi Nabil:
> >
> >             I think IESG will ask for more details than this. You may
> want to qualify in very specific terms on where the default ND is expected
> to work as expected and where it will fail.
> >
> >             From: its <[email-masked] <mailto:[email-masked]>>
> on behalf of NABIL BENAMAR <[email-masked] <mailto:
> [email-masked]>>
> >             Yesterday, we have submitted a new version (45) of
> the draft-ietf-ipwave-ipv6-over-80211ocb.
> >             Based on the messages exchanged in the ML, we have
> tightened the scope of this document by precising in the abstract the
> following:
> >
> >             Old:
> >
> >             "This document describes these parameters for IPv6 and IEEE
> 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB
> similarly to other known 802.11 and Ethernet layers - by using an Ethernet
> Adaptation Layer."
> >
> >             New:
> >
> >             "This document describes how IPv6 (including addressing and
> basic ND) can be used to communicate among nodes in range of one another
> over IEEE 802.11-OCB. Optimizations and usage of IPv6 over more complex
> scenarios is not covered and is subject of future work."
> >
> >
> >             On Mon, Apr 29, 2019 at 10:03 PM NABIL BENAMAR <
> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >                 Dear IPWAVErs,
> >
> >                 This is the version -45.
> >
> >                 To: Jerome Haerri <[email-masked] <mailto:
> [email-masked]>>, <[email-masked] <mailto:
> ipwave-chairs@ietf..org>>, Jerome Haerri <[email-masked]
> <mailto:[email-masked]>>, Nabil Benamar <[email-masked]
> <mailto:[email-masked]>>, Thierry Ernst <[email-masked]
> <mailto:[email-masked]>>, Jong-Hyouk Lee <[email-masked]
> <mailto:[email-masked]>>
> >
> >
> >
> >                 A new version of I-D,
> >                 Title:          Transmission of IPv6 Packets over IEEE
> 802.11 Networks operating in mode Outside the Context of a Basic Service
> Set (IPv6-over-80211-OCB)

-- 

Best Regards

Nabil Benamar
Associate Professor

---

From: NABIL BENAMAR <[email-masked]>
Date: Sun, 5 May 2019 12:47:16 +0100

Hi Brian,

I will remove this sentence "However, this does not apply if TBD TBD TBD"
from the Appendix J.
I will also make sure that we have only "link-local" throughout the
document to be compatible with RFC4291.

Pascal,

We have tightened the scope in version 45 of the document. Do you still
have concerns about  ND?

On Sat, May 4, 2019 at 5:23 AM Brian E Carpenter <
[email-masked]> wrote:

> Hi Nabil,
>
> There is one sentence in Appendix J that needs to be completed or removed:
>
> "However, this does not apply if TBD TBD TBD."
>
> Since you now say in the main text that "The subnet structure on which the
> Neighbor Discovery protocol (ND) on OCB works ok is a single-link subnet;"
> I think it would be OK to simply remove that sentence in the Appendix.
>
> For me it seems OK now. I assume you will also get final comments from
> Pascal.
>
> NIT: I noticed that both "link local" and "link-local" are used, which is
> confusing when searching the document for that topic. RFC4291 only uses
> "link-local".
>
> Regards
>    Brian Carpenter
>
> On 02-May-19 19:16, NABIL BENAMAR wrote:
> > Hi Brian
> >
> all ND issues that you still to be addressed in the current version of the
> draft.
> >
> >
> > Your help is much appreciated
> >
> > From:<[email-masked] <mailto:[email-masked]>>
> > Date: Mon, Apr 29, 2019, 21:58
> [email-masked]>>, Jerome Haerri <[email-masked] <mailto:
> [email-masked]>>, Nabil Benamar <[email-masked]

-- 

Best Regards

Nabil Benamar
Associate Professor

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 6 May 2019 08:07:37 +1200

Hi Nabil,

> Do you still have concerns about  ND?

Not as far as this document is concerned. I think the wider issues raised in draft-thubert-6man-ipv6-over-wireless are important, but that's a separate discussion.

Regards
   Brian

On 05-May-19 23:47, NABIL BENAMAR wrote:
> Hi Brian,
> 
> I will remove this sentence "However, this does not apply if TBD TBD TBD" from the Appendix J. 
> I will also make sure that we have only "link-local" throughout the document to be compatible with RFC4291.
> 
> Pascal,
> 
> We have tightened the scope in version 45 of the document. Do you still have concerns about  ND?
> 
> On Sat, May 4, 2019 at 5:23 AM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Nabil,
> 
>     Since you now say in the main text that "The subnet structure on which the Neighbor Discovery protocol (ND) on OCB works ok is a single-link subnet;" I think it would be OK to simply remove that sentence in the Appendix.
> 
>     For me it seems OK now. I assume you will also get final comments from Pascal.
> 
>     NIT: I noticed that both "link local" and "link-local" are used, which is confusing when searching the document for that topic. RFC4291 only uses "link-local".
> 
>     Regards
>        Brian Carpenter
> 
>     > I'm coming back to you to ask you what are the remaining points about all ND issues that you still to be addressed in the current version of the draft.
>     >
>     >
>     > From:<[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>     > To: Jerome Haerri <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>, <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>, Jerome Haerri <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>, Nabil Benamar <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>, Thierry Ernst <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>, Jong-Hyouk Lee <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>     >
>     >
>     >
>     > until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> <http://tools.ietf.org>.
>     >
>     > The IETF Secretariat
>     >
> 
> 
> 
> -- 
> 
> Best Regards
> 
> Nabil Benamar
> Associate Professor

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 6 May 2019 09:39:31 +0000

Hello Nabil:

First things first I still do not find a section on the scope of the document, or at least text in the introduction that says that the document focuses on P2P communication over link local.

The way it is written now the draft still claims that it covers all IPv6 over OCB and that IPv6 ND is a MUST. How could I agree with that? Confined to a P2P link, I may agree that it works but the text as written prevents WiND on OCB which is plain absurd.

Even if you are not experienced with WiND, you can not publish something that makes believe that RFC 4861 applies to all subnet models, because it does not. I wrote draft-thubert-6man-ipv6-over-wireless to explain that. If you disagree,  we can have that discussion on 6MAN against my draft.

You also need to explain what you mean by address mapping. I understand between the lines that you mean the association of the Link-Layer Address with the IPv6 address, that could be more clear. For 4.5.1, RFC 4861 does not tell you how you map your own MAC address, it only resolves that of the peer. I agree that RFC 2464 has misleading text on that but please do not quote it. 

If your assumption is that IPv6 over OCB encapsulation is IPv6 over IEEE 802.3 and then a translation to 802.11, then you do not need a section 4.5 at all, just inherit from RFC 2464. In my mind it is enough to say that IPv6 encapsulation over OCB is IPv6 over Ethernet followed by Ethernet to 802.11 translation. This is enough to replace both 4.2.1 and 4.5. If you want to say more, you can only summarize what the IEEE does with a reference, but not make it look like you are specifying it. I guess 802.11p already explains how to set the 4 MAC addresses and the from/to Distribution System in the Frame Control field when translating from Ethernet frames, doesn't it? 

Note: the main draft only mentions RFC 4861 though section 4.4 discusses autoconf, I suggest you add a ref to RFC 4862 there.

All the best,

Pascal

> -----Original Message-----
> From: Brian E Carpenter <[email-masked]>
> Sent: dimanche 5 mai 2019 22:08
> To: NABIL BENAMAR <[email-masked]>; [email-masked]; Pascal
> Thubert (pthubert) <[email-masked]>
> Subject: Re: Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-
> 80211ocb-45.txt
> 
> Hi Nabil,
> 
> Not as far as this document is concerned. I think the wider issues raised in
> draft-thubert-6man-ipv6-over-wireless are important, but that's a separate
> discussion.
> 
> Regards
>    Brian
> 
> > I will remove this sentence "However, this does not apply if TBD TBD
> > TBD" from the Appendix J. I will also make sure that we have only "link-local"
> throughout the document to be compatible with RFC4291.
> >
> > Pascal,
> >
> > On Sat, May 4, 2019 at 5:23 AM Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> >
> >     Hi Nabil,
> >
> >     Since you now say in the main text that "The subnet structure on which
> the Neighbor Discovery protocol (ND) on OCB works ok is a single-link subnet;"
> all ND issues that you still to be addressed in the current version of the draft.
> >     >
> >     >
> >     > From:<[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>
> >     > To: Jerome Haerri <[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>, <[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>, Jerome Haerri
> <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>,
> Nabil Benamar <[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>, Thierry Ernst <[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>, Jong-Hyouk Lee <[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>
> >     >
> >     >
> >     >
> operating in mode Outside the Context of a Basic Service Set (IPv6-over-
> 80211-OCB)
> >     > until the htmlized version and diff are available at tools.ietf.org
> <http://tools.ietf.org> <http://tools.ietf.org>.
> >     >
> >     > The IETF Secretariat
> >     >
> >
> >
> >
> > --
> >
> > Best Regards
> >
> > Nabil Benamar
> > Associate Professor

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 6 May 2019 11:42:28 +0200

For address mapping - see rfc2464.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 6 May 2019 12:37:34 +0200

Le 06/05/2019 à 11:39, Pascal Thubert (pthubert) a écrit :
> Hello Nabil:
> 
> First things first I still do not find a section on the scope of the
> document, or at least text in the introduction that says that the
> document focuses on P2P communication over link local.

PAscal,

Please note that in our demonstrator of IPv6-over-OCB we do P2P but also 
this:

  P
P2P

which means there are three Peers in the subnet.

For this reason, I do not understand why you suggest the document 
focuses on P2P communication.

Alex

> 
> The way it is written now the draft still claims that it covers all
> IPv6 over OCB and that IPv6 ND is a MUST. How could I agree with
> that? Confined to a P2P link, I may agree that it works but the text
> as written prevents WiND on OCB which is plain absurd.
> 
> Even if you are not experienced with WiND, you can not publish
> something that makes believe that RFC 4861 applies to all subnet
> models, because it does not. I wrote
> draft-thubert-6man-ipv6-over-wireless to explain that. If you
> disagree,  we can have that discussion on 6MAN against my draft.
> 
> You also need to explain what you mean by address mapping. I
> understand between the lines that you mean the association of the
> Link-Layer Address with the IPv6 address, that could be more clear.
> For 4.5.1, RFC 4861 does not tell you how you map your own MAC
> address, it only resolves that of the peer. I agree that RFC 2464 has
> misleading text on that but please do not quote it.
> 
> If your assumption is that IPv6 over OCB encapsulation is IPv6 over
> IEEE 802.3 and then a translation to 802.11, then you do not need a
> section 4.5 at all, just inherit from RFC 2464. In my mind it is
> enough to say that IPv6 encapsulation over OCB is IPv6 over Ethernet
> followed by Ethernet to 802.11 translation. This is enough to replace
> both 4.2.1 and 4.5. If you want to say more, you can only summarize
> what the IEEE does with a reference, but not make it look like you
> are specifying it. I guess 802.11p already explains how to set the 4
> MAC addresses and the from/to Distribution System in the Frame
> Control field when translating from Ethernet frames, doesn't it?
> 
> Note: the main draft only mentions RFC 4861 though section 4.4
> discusses autoconf, I suggest you add a ref to RFC 4862 there.
> 
> All the best,
> 
> Pascal
> 
>> -----Original Message----- From: Brian E Carpenter
>> <[email-masked]> Sent: dimanche 5 mai 2019 22:08 To:
>> NABIL BENAMAR <[email-masked]>; [email-masked]; Pascal 
>> Thubert (pthubert) <[email-masked]> Subject: Re: Fwd: New
>> Version Notification for draft-ietf-ipwave-ipv6-over- 
>> 80211ocb-45.txt
>> 
>> Hi Nabil,
>> 
>> Not as far as this document is concerned. I think the wider issues
>> raised in draft-thubert-6man-ipv6-over-wireless are important, but
>> that's a separate discussion.
>> 
>> Regards Brian
>> 
>>> I will remove this sentence "However, this does not apply if TBD
>>> TBD TBD" from the Appendix J. I will also make sure that we have
>>> only "link-local"
>>> There is one sentence in Appendix J that needs to be completed
>>> or
>> removed:
>>> 
>> the Neighbor Discovery protocol (ND) on OCB works ok is a
>> single-link subnet;" I think it would be OK to simply remove that
>> sentence in the Appendix.
>>> 
>> confusing when searching the document for that topic. RFC4291 only
>> uses "link-local".
>>> 
>>> Regards Brian Carpenter
>>> 
>>>> Date: Mon, Apr 29, 2019, 21:58 Subject: New Version
>>>> Notification for draft-ietf-ipwave-ipv6-over-
>> 80211ocb-45.txt
>> <mailto:[email-masked]
>> <mailto:[email-masked]>>>, Nabil Benamar
>> <[email-masked] <mailto:[email-masked]>
>> <mailto:[email-masked] <mailto:[email-masked]>>>,
>> Thierry Ernst <[email-masked] 
>> <mailto:[email-masked]>>>, Jong-Hyouk Lee
>> <[email-masked] <mailto:[email-masked]>
>> <mailto:[email-masked] <mailto:[email-masked]>>>
>>>> 
>>>> 
>>>> 
>>>> A new version of I-D,
>>>> draft-ietf-ipwave-ipv6-over-80211ocb-45.txt has been
>>>> successfully submitted by Nabil Benamar and posted to the IETF
>>>> repository.
>>>> 
>>>> Name:           draft-ietf-ipwave-ipv6-over-80211ocb Revision:
>>>> 45 Title:          Transmission of IPv6 Packets over IEEE
>>>> 802.11 Networks
>> (IPv6-over- 80211-OCB)
>>>> Document date:  2019-04-29 Group:          ipwave Pages:
>>>> 43 URL:
>>>> Abstract: In order to transmit IPv6 packets on IEEE 802.11
>>>> networks running outside the context of a basic service set
>>>> (OCB, earlier "802.11p") there is a need to define a few
>>>> parameters such as the supported Maximum Transmission Unit size
>>>> on the 802.11-OCB link, the header format preceding the IPv6
>>>> header, the Type value within it, and others.  This document
>>>> describes how IPv6 (including addressing and basic ND) can be
>>>> used to communicate among nodes in range of one another over
>>>> IEEE 802.11-OCB.  Optimizations and usage of IPv6 over more
>>>> complex scenarios is not covered and is subject of future
>>>> work.
>>>> 
>>>> 
>>>> 
>>>> 
>>> Nabil Benamar Associate Professor Department of Computer
>>> Sciences School of Technology University Moulay Ismail Meknes.
>>> Morocco
>>> 
>>> 
> 
> _______________________________________________ its mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>

---

From: Nabil Benamar <[email-masked]>
Date: Mon, 6 May 2019 11:47:48 +0100

Hi Pascal,

Thanks for your email. See my answers below

On Mon, May 6, 2019 at 10:40 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> document, or at least text in the introduction that says that the document
> focuses on P2P communication over link local.
>

I have already discussed this point with Alex. Previous experiments were
done with three Peers in the subnet.

>
> The way it is written now the draft still claims that it covers all IPv6
> over OCB and that IPv6 ND is a MUST. How could I agree with that? Confined
> to a P2P link, I may agree that it works but the text as written prevents
> WiND on OCB which is plain absurd.

IPv6 ND is a MUST because without ND there is no IPv6 (RA, RS, NA, NS,
etc...). I should add that I'm not aware of the works of WiND! It may work,
but it is out of scope of the current draft!

>
>
> Even if you are not experienced with WiND, you can not publish something
> that makes believe that RFC 4861 applies to all subnet models, because it
> does not. I wrote draft-thubert-6man-ipv6-over-wireless to explain that. If
> you disagree,  we can have that discussion on 6MAN against my draft.
>

This is out of scope of the current draft. This discussion should be done
in 6man not in IPwave.

>
> You also need to explain what you mean by address mapping. I understand
> between the lines that you mean the association of the Link-Layer Address
> with the IPv6 address, that could be more clear. For 4.5.1, RFC 4861 does
> not tell you how you map your own MAC address, it only resolves that of the
> peer. I agree that RFC 2464 has misleading text on that but please do not
> quote it.
>

I can reformulate this text.

>
> If your assumption is that IPv6 over OCB encapsulation is IPv6 over IEEE
> 802.3 and then a translation to 802.11, then you do not need a section 4.5
> at all, just inherit from RFC 2464. In my mind it is enough to say that
> IPv6 encapsulation over OCB is IPv6 over Ethernet followed by Ethernet to
> 802.11 translation. This is enough to replace both 4.2.1 and 4.5. If you
> want to say more, you can only summarize what the IEEE does with a
> reference, but not make it look like you are specifying it. I guess 802.11p
> already explains how to set the 4 MAC addresses and the from/to
> Distribution System in the Frame Control field when translating from
> Ethernet frames, doesn't it?
>

Let me suggest a new text to the WG.

>
> Note: the main draft only mentions RFC 4861 though section 4.4 discusses
> autoconf, I suggest you add a ref to RFC 4862 there.
>

Ok.

> raised in

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 6 May 2019 11:53:10 +0000

Hello Nabil

I have already discussed this point with Alex. Previous experiments were done with three Peers in the subnet.

Ø    This is not an article about an experimentation. And my review is not the review of an article. This is about a standard track document. I’m talking about technical correctness.

Ø    If you intend to talk about subnets you need to explain which subnet models you plan to support. There are many in the wireless world. 3 cars is not a model, it is an experimentation.

Ø    You can find help in my 6man draft. I suggest you take the time to read it. Else I’m probably wasting my time.

IPv6 ND is a MUST because without ND there is no IPv6 (RA, RS, NA, NS, etc...). I should add that I'm not aware of the works of WiND! It may work, but it is out of scope of the current draft!

Ø    We do LPWAN without ND. And your MUST excludes WiND. Clearly you do not know what you are doing by excluding it. So don’t. Just say that IPv6 ND can be used as opposed to making it MUST. And if you extend your scope beyond P2P say under which condition. It’s all discussed in my 6man draft, learn from it.

Ø    The scope of this draft is still missing. I recommended to you to start there, define what your scope is. Right now it says IPv6 over OCB which means everything should be in there. Which also means that RFC 4861 is all you need. This is plain wrong.

This is out of scope of the current draft. This discussion should be done in 6man not in IPwave.

  *   Scope? Which scope? Write it in the I-draft else this is an empty claim.
  *   IOv6 over OCB is a case of IPv6 over wireless. My draft discusses ND for wireless. It is actually supposed to help you. You could consider what models exist and decide which you want to support.

cheers,

Pascal

> From: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>
> To: NABIL BENAMAR <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Pascal
> Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> wrote:
> >
> >     Hi Nabil,
> >
> >     > From:<[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
> >     > To: Jerome Haerri <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>>>, <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>>>, Jerome Haerri
> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>,
> Nabil Benamar <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>>>, Thierry Ernst <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>>>, Jong-Hyouk Lee <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>>>
> >     >
> >     >
> >     >
> >     > until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>

_______________________________________________
its mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/its

---

From: Nabil Benamar <[email-masked]>
Date: Mon, 6 May 2019 13:21:44 +0100

Hi Pascal,

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

On Mon, May 6, 2019 at 12:53 PM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Ø    This is not an article about an experimentation. And my review is
> not the review of an article. This is about a standard track document. I’m
> talking about technical correctness.
>
> Ø    If you intend to talk about subnets you need to explain which subnet
> models you plan to support. There are many in the wireless world. 3 cars is
> not a model, it is an experimentation.
>
> Ø    You can find help in my 6man draft. I suggest you take the time to
> read it. Else I’m probably wasting my time.
>
You need to be patient as we -authors- are with ALL the reviews we get  from
ALL!
I will read your draft.

> Ø    We do LPWAN without ND. And your MUST excludes WiND. Clearly you do
> not know what you are doing by excluding it. So don’t. Just say that IPv6
> ND can be used as opposed to making it MUST.
>
There was no intention to exclude WiND. However, I can adjust the text and
say that "IPv6 ND can be used". I also need the feedback from the WG
participants and chairs on this particular point.

> And if you extend your scope beyond P2P say under which condition. It’s
> all discussed in my 6man draft, learn from it.
>
I learn from all published drafts and RFCs.

> Ø    The scope of this draft is still missing. I recommended to you to
> start there, define what your scope is. Right now it says IPv6 over OCB
> which means everything should be in there. Which also means that RFC 4861
> is all you need. This is plain wrong.
>
We have already tightened the scope but it seems not suffisant!

>    - Scope? Which scope? Write it in the I-draft else this is an empty
>    claim.
>    - IOv6 over OCB is a case of IPv6 over wireless. My draft discusses ND
>    for wireless. It is actually supposed to help you. You could consider what
>    models exist and decide which you want to support.
>
> Ok. Will do

>    -

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 May 2019 08:30:46 +1200

> We have already tightened the scope but it seems not suffisant! 

I suspect that the problem is that this statement is only found
on page 8:

This limitation of scope should probably be indicated in the Abstract and in
the Introduction. For example, in the Abstract:

OLD:
   This document describes how IPv6 (including addressing and
   basic ND) can be used to communicate among nodes in range of one
   another over IEEE 802.11-OCB.  

NEW:
   This document describes how IPv6 (including addressing and
   basic ND) can be used to communicate among nodes in range of one
   another over a single IEEE 802.11-OCB link. 

In the Introduction:

OLD:
   IPv6 works fine directly over 802.11-OCB too, with an LLC
   layer.

NEW:
   IPv6 works normally over a single IEEE 802.11-OCB link with an LLC
   layer. Multi-link scenarios are out of scope for the present document.

I hope this helps.

Regards
   Brian

On 07-May-19 00:21, Nabil Benamar wrote:
> 
> Hi Pascal,
> 
> 
> Best regards
> Nabil Benamar
> -------------------
> نبيل بنعمرو
> 
> 
> 
> 
> 
> 
> 
> On Mon, May 6, 2019 at 12:53 PM Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hello Nabil____
> 
>     __ __
> 
>         First things first I still do not find a section on the scope of the document, or at least text in the introduction that says that the document focuses on P2P communication over link local.____
> 
>     __ __
> 
>     I have already discussed this point with Alex. Previous experiments were done with three Peers in the subnet.____
> 
>     __ __
> 
>     __Ø    __This is not an article about an experimentation. And my review is not the review of an article. This is about a standard track document. I’m talking about technical correctness.____
> 
>     __Ø    __If you intend to talk about subnets you need to explain which subnet models you plan to support. There are many in the wireless world. 3 cars is not a model, it is an experimentation.____
> 
>     __Ø    __You can find help in my 6man draft. I suggest you take the time to read it. Else I’m probably wasting my time.
> 
> You need to be patient as we -authors- are with ALL the reviews we get  from ALL!
> I will read your draft.
> 
>         The way it is written now the draft still claims that it covers all IPv6 over OCB and that IPv6 ND is a MUST. How could I agree with that? Confined to a P2P link, I may agree that it works but the text as written prevents WiND on OCB which is plain absurd.____
> 
>     __ __
> 
>     IPv6 ND is a MUST because without ND there is no IPv6 (RA, RS, NA, NS, etc...). I should add that I'm not aware of the works of WiND! It may work, but it is out of scope of the current draft!____
> 
>     __ __
> 
>     __Ø    __We do LPWAN without ND. And your MUST excludes WiND. Clearly you do not know what you are doing by excluding it. So don’t. Just say that IPv6 ND can be used as opposed to making it MUST.
> 
> There was no intention to exclude WiND. However, I can adjust the text and say that "IPv6 ND can be used". I also need the feedback from the WG participants and chairs on this particular point.
> 
>     And if you extend your scope beyond P2P say under which condition. It’s all discussed in my 6man draft, learn from it.
> 
>     ____
>     __Ø    __The scope of this draft is still missing. I recommended to you to start there, define what your scope is. Right now it says IPv6 over OCB which means everything should be in there. Which also means that RFC 4861 is all you need. This is plain wrong.
> 
>     ____
>     __
>         Even if you are not experienced with WiND, you can not publish something that makes believe that RFC 4861 applies to all subnet models, because it does not. I wrote draft-thubert-6man-ipv6-over-wireless to explain that. If you disagree,  we can have that discussion on 6MAN against my draft.____
> 
>     __ __
> 
>     This is out of scope of the current draft. This discussion should be done in 6man not in IPwave.____
> 
>     __ __
> 
>       * Scope? Which scope? Write it in the I-draft else this is an empty claim.____
>       * ____
>     __ __
>         > From: Brian E Carpenter <[email-masked] <mailto:[email-masked]>>
>         > To: NABIL BENAMAR <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Pascal
>         > Thubert (pthubert) <[email-masked] <mailto:[email-masked]>>
>         > <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>         > wrote:
>         > >
>         > >     Hi Nabil,
>         > >
>         > >     > Hi Brian
>         > >     >
>         > >     > I'm coming back to you to ask you what are the remaining points about
>         > >     >
>         > >     >
>         > >     > Your help is much appreciated
>         > >     >
>         > >     > ---------- Forwarded message ---------
>         > >     > From:<[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>         > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>
>         > >     > Date: Mon, Apr 29, 2019, 21:58
>         > >     > Subject: New Version Notification for draft-ietf-ipwave-ipv6-over-
>         > 80211ocb-45.txt
>         > >     > To: Jerome Haerri <[email-masked] <mailto:[email-masked]>
>         > <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>         > <mailto:[email-masked] <mailto:[email-masked]>>>>, <[email-masked] <mailto:[email-masked]>
>         > <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>         > <mailto:[email-masked] <mailto:[email-masked]>>>>, Jerome Haerri
>         > <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>         > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>,
>         > Nabil Benamar <[email-masked] <mailto:[email-masked]>
>         > <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>         > <mailto:[email-masked] <mailto:[email-masked]>>>>, Thierry Ernst <[email-masked] <mailto:[email-masked]>
>         > <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>         > <mailto:[email-masked] <mailto:[email-masked]>>>>, Jong-Hyouk Lee <[email-masked] <mailto:[email-masked]>
>         > <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>         > <mailto:[email-masked] <mailto:[email-masked]>>>>
>         > >     >
>         > >     >
>         > >     >
>         > >     > A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-45.txt
>         > >     > has been successfully submitted by Nabil Benamar and posted to the
>         > >     > IETF repository.
>         > >     >
>         > >     > Name:           draft-ietf-ipwave-ipv6-over-80211ocb
>         > >     > Revision:       45
>         > >     > Title:          Transmission of IPv6 Packets over IEEE 802.11 Networks
>         > >     > Document date:  2019-04-29
>         > >     > Group:          ipwave
>         > >     > Pages:          43
>         > >     > URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-
>         > over-80211ocb-45.txt
>         > >     > Status:         https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-
>         > 80211ocb/
>         > >     > Htmlized:       https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-
>         > 80211ocb-45
>         > >     > Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-
>         > ipv6-over-80211ocb
>         > >     > Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-
>         > 80211ocb-45
>         > >     >
>         > >     > Abstract:
>         > >     >    In order to transmit IPv6 packets on IEEE 802.11 networks running
>         > >     >    outside the context of a basic service set (OCB, earlier "802.11p")
>         > >     >    there is a need to define a few parameters such as the supported
>         > >     >    Maximum Transmission Unit size on the 802.11-OCB link, the header
>         > >     >    format preceding the IPv6 header, the Type value within it, and
>         > >     >    others.  This document describes how IPv6 (including addressing and
>         > >     >    basic ND) can be used to communicate among nodes in range of one
>         > >     >    another over IEEE 802.11-OCB.  Optimizations and usage of IPv6 over
>         > >     >    more complex scenarios is not covered and is subject of future work.
>         > >     >
>         > >     >
>         > >     >
>         > >     >
>         > >     > Please note that it may take a couple of minutes from the time of
>         > submission
>         > >     > until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org>
>         > >     >
>         > >     > The IETF Secretariat
>         > >     >
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/its____
>

---

From: Nabil Benamar <[email-masked]>
Date: Mon, 6 May 2019 21:54:43 +0100

Thank you Brian,

I agree on your text.

However, there is another point about ND. Pascal is suggesting to replace
the MUST by "can" in the following sentence. What do you think?

   over 802.11-OCB links.

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

On Mon, May 6, 2019 at 9:30 PM Brian E Carpenter <
[email-masked]> wrote:

> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >     Hello Nabil____
> >
> >     __ __
> >
> >         First things first I still do not find a section on the scope of
> the document, or at least text in the introduction that says that the
> document focuses on P2P communication over link local.____
> >
> >     __ __
> >
> >     I have already discussed this point with Alex. Previous experiments
> were done with three Peers in the subnet.____
> >
> >     __ __
> >
> >     __Ø    __This is not an article about an experimentation. And my
> review is not the review of an article. This is about a standard track
> document. I’m talking about technical correctness.____
> >
> >     __Ø    __If you intend to talk about subnets you need to explain
> which subnet models you plan to support. There are many in the wireless
> world. 3 cars is not a model, it is an experimentation.____
> >
> >     __Ø    __You can find help in my 6man draft. I suggest you take the
> time to read it. Else I’m probably wasting my time.
> >
> >         The way it is written now the draft still claims that it covers
> all IPv6 over OCB and that IPv6 ND is a MUST. How could I agree with that?
> Confined to a P2P link, I may agree that it works but the text as written
> prevents WiND on OCB which is plain absurd.____
> >
> >     __ __
> >
> >     IPv6 ND is a MUST because without ND there is no IPv6 (RA, RS, NA,
> NS, etc...). I should add that I'm not aware of the works of WiND! It may
> work, but it is out of scope of the current draft!____
> >
> >     __ __
> >
> >     __Ø    __We do LPWAN without ND. And your MUST excludes WiND.
> Clearly you do not know what you are doing by excluding it. So don’t. Just
> say that IPv6 ND can be used as opposed to making it MUST.
> >
> > There was no intention to exclude WiND. However, I can adjust the text
> and say that "IPv6 ND can be used". I also need the feedback from the WG
> >     And if you extend your scope beyond P2P say under which condition.
> It’s all discussed in my 6man draft, learn from it.
> >
> >     __Ø    __The scope of this draft is still missing. I recommended to
> you to start there, define what your scope is. Right now it says IPv6 over
> OCB which means everything should be in there. Which also means that RFC
> 4861 is all you need. This is plain wrong.
> >
> something that makes believe that RFC 4861 applies to all subnet models,
> because it does not. I wrote draft-thubert-6man-ipv6-over-wireless to
> explain that. If you disagree,  we can have that discussion on 6MAN against
> my draft.____
> >
> >     __ __
> >
> >       * IOv6 over OCB is a case of IPv6 over wireless. My draft
> discusses ND for wireless. It is actually supposed to help you. You could
> consider what models exist and decide which you want to support.
> >
> > Ok. Will do
> >
> >       * ____
> >
> >     __ __
> >
> >
> >         cheers,
> >
> >         Pascal
> >
> >         > To: NABIL BENAMAR <[email-masked] <mailto:
> [email-masked]>>; [email-masked] <mailto:[email-masked]>; Pascal
> >         > <[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>>
> >         > wrote:
> >         > >
> >         > >     Hi Nabil,
> >         > >
> >         > >     There is one sentence in Appendix J that needs to be
> completed or
> >         > removed:
> >         > >
> single-link subnet;"
> >         > >     > From:<[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>
> >         > <mailto:[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>>>
> [email-masked]>
> >         > <mailto:[email-masked] <mailto:
> [email-masked]>> <mailto:[email-masked] <mailto:
> [email-masked]>
> >         > <mailto:[email-masked] <mailto:
> [email-masked]>>>>, <[email-masked] <mailto:
> [email-masked]>
> >         > <mailto:[email-masked] <mailto:[email-masked]>>
> <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>
> >         > <mailto:[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>>>,
> >         > <mailto:[email-masked] <mailto:
> [email-masked]>> <mailto:[email-masked] <mailto:
> [email-masked]>
> >         > <mailto:[email-masked] <mailto:
> [email-masked]>>>>, Thierry Ernst <[email-masked]
> <mailto:[email-masked]>
> >         > <mailto:[email-masked] <mailto:
> [email-masked]>> <mailto:[email-masked] <mailto:
> [email-masked]>
> >         > <mailto:[email-masked] <mailto:
> [email-masked]>>>>, Jong-Hyouk Lee <[email-masked] <mailto:
> [email-masked]>
> >         > <mailto:[email-masked] <mailto:[email-masked]>>
> <mailto:[email-masked] <mailto:[email-masked]>
> (IPv6-over-
> >         > >     > until the htmlized version and diff are available at
> tools.ietf.org <http://tools.ietf.org>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 May 2019 09:58:27 +1200

On 07-May-19 08:54, Nabil Benamar wrote:
> Thank you Brian,
> 
> I agree on your text.
> 
> However, there is another point about ND. Pascal is suggesting to replace the MUST by "can" in the following sentence. What do you think?
> 

Not sure. I suppose the point is that if nothing else is available, ND is necessary. How about saying "MUST be supported", which really means mandatory to implement rather than mandatory to use?

(Or more complicated text to say the same thing.)

   Brian
> 
> 
> 
> 
> 
> 
> 
> Best regards
> Nabil Benamar
> -------------------
> نبيل بنعمرو
> 
> 
> 
> 
> 
> 
> 
> On Mon, May 6, 2019 at 9:30 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > On Mon, May 6, 2019 at 12:53 PM Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     Hello Nabil____
>     >
>     >     __ __
>     >
>     >         > -----Original Message-----
>     >         > From: Brian E Carpenter <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>     >         > Sent: dimanche 5 mai 2019 22:08
>     >         > To: NABIL BENAMAR <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>; [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>; Pascal
>     >         > Thubert (pthubert) <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>     >         > Subject: Re: Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-
>     >         > 80211ocb-45.txt
>     >         >
>     >         > Hi Nabil,
>     >         >
>     >         > > Do you still have concerns about  ND?
>     >         >
>     >         > Not as far as this document is concerned. I think the wider issues raised in
>     >         > draft-thubert-6man-ipv6-over-wireless are important, but that's a separate
>     >         > discussion.
>     >         >
>     >         > Regards
>     >         >    Brian
>     >         >
>     >         > On 05-May-19 23:47, NABIL BENAMAR wrote:
>     >         > > Hi Brian,
>     >         > >
>     >         > > I will remove this sentence "However, this does not apply if TBD TBD
>     >         > > TBD" from the Appendix J. I will also make sure that we have only "link-local"
>     >         > throughout the document to be compatible with RFC4291.
>     >         > >
>     >         > > Pascal,
>     >         > >
>     >         > > We have tightened the scope in version 45 of the document. Do you still
>     >         > have concerns about  ND?
>     >         > >
>     >         > > On Sat, May 4, 2019 at 5:23 AM Brian E Carpenter
>     >         > <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>
>     >         > wrote:
>     >         > >
>     >         > >     Hi Nabil,
>     >         > >
>     >         > >     There is one sentence in Appendix J that needs to be completed or
>     >         > removed:
>     >         > >
>     >         > >     "However, this does not apply if TBD TBD TBD."
>     >         > >
>     >         > >     Since you now say in the main text that "The subnet structure on which
>     >         > the Neighbor Discovery protocol (ND) on OCB works ok is a single-link subnet;"
>     >         > I think it would be OK to simply remove that sentence in the Appendix.
>     >         > >
>     >         > >     For me it seems OK now. I assume you will also get final comments from
>     >         > Pascal.
>     >         > >
>     >         > >     NIT: I noticed that both "link local" and "link-local" are used, which is
>     >         > confusing when searching the document for that topic. RFC4291 only uses
>     >         > "link-local".
>     >         > >
>     >         > >     Regards
>     >         > >        Brian Carpenter
>     >         > >
>     >         > >     On 02-May-19 19:16, NABIL BENAMAR wrote:
>     >         > >     > Hi Brian
>     >         > >     >
>     >         > >     > I'm coming back to you to ask you what are the remaining points about
>     >         > all ND issues that you still to be addressed in the current version of the draft.
>     >         > >     >
>     >         > >     >
>     >         > >     > Your help is much appreciated
>     >         > >     >
>     >         > >     > ---------- Forwarded message ---------
>     >         > >     > From:<[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>     >         > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>>
>     >         > >     > Date: Mon, Apr 29, 2019, 21:58
>     >         > >     > Subject: New Version Notification for draft-ietf-ipwave-ipv6-over-
>     >         > 80211ocb-45.txt
>     >         > >     > To: Jerome Haerri <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >         > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >         > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>>, <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >         > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >         > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>>, Jerome Haerri
>     >         > <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>     >         > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>>,
>     >         > Nabil Benamar <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >         > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >         > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>>, Thierry Ernst <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >         > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >         > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>>, Jong-Hyouk Lee <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >         > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >         > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>>
>     >         > >     >
>     >         > >     >
>     >         > >     >
>     >         > >     > A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-45.txt
>     >         > >     > has been successfully submitted by Nabil Benamar and posted to the
>     >         > >     > IETF repository.
>     >         > >     >
>     >         > >     > Name:           draft-ietf-ipwave-ipv6-over-80211ocb
>     >         > >     > Revision:       45
>     >         > >     > Title:          Transmission of IPv6 Packets over IEEE 802.11 Networks
>     >         > operating in mode Outside the Context of a Basic Service Set (IPv6-over-
>     >         > 80211-OCB)
>     >         > >     > Document date:  2019-04-29
>     >         > >     > Group:          ipwave
>     >         > >     > Pages:          43
>     >         > >     > URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-
>     >         > over-80211ocb-45.txt
>     >         > >     > Status:         https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-
>     >         > 80211ocb/
>     >         > >     > Htmlized:       https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-
>     >         > 80211ocb-45
>     >         > >     > Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-
>     >         > ipv6-over-80211ocb
>     >         > >     > Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-
>     >         > 80211ocb-45
>     >         > >     >
>     >         > >     > Abstract:
>     >         > >     >    In order to transmit IPv6 packets on IEEE 802.11 networks running
>     >         > >     >    outside the context of a basic service set (OCB, earlier "802.11p")
>     >         > >     >    there is a need to define a few parameters such as the supported
>     >         > >     >    Maximum Transmission Unit size on the 802.11-OCB link, the header
>     >         > >     >    format preceding the IPv6 header, the Type value within it, and
>     >         > >     >    others.  This document describes how IPv6 (including addressing and
>     >         > >     >    basic ND) can be used to communicate among nodes in range of one
>     >         > >     >    another over IEEE 802.11-OCB.  Optimizations and usage of IPv6 over
>     >         > >     >    more complex scenarios is not covered and is subject of future work.
>     >         > >     >
>     >         > >     >
>     >         > >     >
>     >         > >     >
>     >         > >     > Please note that it may take a couple of minutes from the time of
>     >         > submission
>     >         > >     > until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> <http://tools.ietf.org>
>     >         > <http://tools.ietf.org> <http://tools.ietf.org>.
>     >         > >     >
>     >         > >     > The IETF Secretariat
>     >         > >     >
>     >         > >
>     >         > >
>     >         > >
>     >         > > --
>     >         > >
>     >         > > Best Regards
>     >         > >
>     >         > > Nabil Benamar
>     >         > > Associate Professor
>     >         > > Department of Computer Sciences
>     >         > > School of Technology
>     >         > > University Moulay Ismail
>     >         > > Meknes. Morocco
>     >         > >
>     >         > >
>     >
>     >         [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 7 May 2019 10:57:10 +0200

Pascal,

I and you discussed this several times and you refuse, or unable to,
help unblock the situation.  You continue blocking it.

This is my last time I reply to the topic described below.

[...]
> section 4.5 at all, just inherit from RFC 2464.

How to 'inherit'?  You need to refer to a document.  That's what we did:
we referred to RFC2464.

> In my mind it is enough to say that IPv6 encapsulation over OCB is 
> IPv6 over Ethernet followed by Ethernet to 802.11 translation.

That's what we did: section 4.2.1 "Ethernet Adaptation Layer".

We did not call it 'translation', because 'translation' has a different
meaning: Address Translation is a different matter than what an
Adaptation Layer does.

> This is enough to replace both 4.2.1 and 4.5. If you want to say 
> more, you can only summarize what the IEEE does with a reference,
> but not make it look like you are specifying it.

What is the IEEE reference to be used to replace 4.2.1?

> I guess 802.11p already explains how to set the 4 MAC addresses and 
> the from/to Distribution System in the Frame Control field when 
> translating from Ethernet frames, doesn't it?

In section 4.2.1 "Ethernet Adaptation Layer",

We specified the mapping of two addresses: the Receiver and Transmitter
address fields into Dst and Src addresses of the Ethernet II addresses.
  We did not specify the mapping of 4 MAC addresses.  Is 802.11p
explaining the mapping of these two addresses?  Is 802.11p explaining
mapping of more than two addresses?

This matter of 4 addresses was already discussed extensively on the
mailing list.  This text is the result of that discussion.

Further, we specified the mapping of the value of the Type field of the
LLC Header into the Ethernet II Type field.  Is 802.11p explaining this
value for Type?

Finally, as a side note, in section 4.2 "Frame Format", we specified the
Subtype sub-field in the Frame Control - assumed to carry an IPv6
packet, as this is an IPv6-over-OCB - to be set to 8 ('QoS Data').  Is
802.11p specifying this?

Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 May 2019 15:27:09 +0000

I'm happy with all of Brian's suggestions below.

Starting with ND in P2P cases enables to experiment with the current stacks. I'm just concerned that as usual the temporary solution gets cast in stone. This is why I do not want to oversell what you can do with classical ND. This is why I feel better with other IPv6-over-foo that evaluated WiND and went for it day 1, e.g., Bluetooth or 802.15.4.

On the bright side this was a trigger for writing https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless, which was needed anyway. OCB is mentioned as an example of Direct MAC without emulation, so basically the models we can build are the same as with 802.15.4 just larger in size, higher in throughput, and possibly less stable in case of mobility. If I got something wrong about OCB in the draft please let me know.

All the best,

Pascal

> Sent: lundi 6 mai 2019 23:58
> To: Nabil Benamar <[email-masked]>
> Cc: Pascal Thubert (pthubert) <[email-masked]>; NABIL BENAMAR
> <[email-masked]>; [email-masked]; Alexandre Petrescu
> <[email-masked]>; Carlos Jesús Bernardos Cano
> <[email-masked]>; Russ Housley <[email-masked]>
> Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-
> over-80211ocb-45.txt
> 
> Not sure. I suppose the point is that if nothing else is available, ND is
> necessary. How about saying "MUST be supported", which really means
> mandatory to implement rather than mandatory to use?
> 
> > On Mon, May 6, 2019 at 9:30 PM Brian E Carpenter
> >     > On Mon, May 6, 2019 at 12:53 PM Pascal Thubert (pthubert)
> <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >     >
> >     >     Hello Nabil____
> >     >
> >     >     __ __
> >     >
> focuses on P2P communication over link local.____
> >     >
> >     >     __ __
> >     >
> review is not the review of an article. This is about a standard track document.
> I’m talking about technical correctness.____
> >     >
> >     >     __Ø    __If you intend to talk about subnets you need to explain which
> subnet models you plan to support. There are many in the wireless world. 3
> cars is not a model, it is an experimentation.____
> >     >
> to a P2P link, I may agree that it works but the text as written prevents WiND
> on OCB which is plain absurd.____
> >     >
> >     >     __ __
> >     >
> NS, etc...). I should add that I'm not aware of the works of WiND! It may work,
> but it is out of scope of the current draft!____
> >     >
> >     >     __ __
> >     >
> Clearly you do not know what you are doing by excluding it. So don’t. Just say
> that IPv6 ND can be used as opposed to making it MUST.
> >     >
> >     >     __Ø    __The scope of this draft is still missing. I recommended to you
> to start there, define what your scope is. Right now it says IPv6 over OCB
> which means everything should be in there. Which also means that RFC 4861 is
> all you need. This is plain wrong.
> >     >
> because it does not. I wrote draft-thubert-6man-ipv6-over-wireless to explain
> that. If you disagree,  we can have that discussion on 6MAN against my
> draft.____
> >     >
> >     >     __ __
> >     >
> in 6man not in IPwave.____
> >     >
> >     >     __ __
> >     >
> >     >       * IOv6 over OCB is a case of IPv6 over wireless. My draft discusses ND
> >     >         > From: Brian E Carpenter <[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>
> >     >         > To: NABIL BENAMAR <[email-masked]
> <mailto:[email-masked]>>>; [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>; Pascal
> >     >         > Thubert (pthubert) <[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>
> >     >         > <[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
> <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]
> <mailto:[email-masked]>>>>
> >     >         > wrote:
> >     >         > >
> >     >         > >     Hi Nabil,
> >     >         > >
> >     >         > >     > From:<[email-masked] <mailto:internet-
> [email-masked]> <mailto:[email-masked] <mailto:internet-
> [email-masked]>> <mailto:[email-masked] <mailto:internet-
> [email-masked]> <mailto:[email-masked] <mailto:internet-
> [email-masked]>>>
> >     >         > <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>
> <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>>>
> >     >         > >     > To: Jerome Haerri <[email-masked]
> <mailto:[email-masked]>>
> >     >         > <mailto:[email-masked]
> <mailto:[email-masked]>>> <mailto:[email-masked]
> <mailto:[email-masked]>>
> >     >         > <mailto:[email-masked]
> <mailto:[email-masked]>>>>>, <[email-masked]
> <mailto:[email-masked]>>
> >     >         > <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>
> >     >         > <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>>>, Jerome
> Haerri
> >     >         > <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>
> >     >         > <mailto:[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>> <mailto:[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>>>,
> >     >         > Nabil Benamar <[email-masked]
> <mailto:[email-masked]>>
> >     >         > <mailto:[email-masked]
> <mailto:[email-masked]>>> <mailto:[email-masked]
> <mailto:[email-masked]>>
> >     >         > <mailto:[email-masked]
> <mailto:[email-masked]>>>>>, Thierry Ernst
> <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>
> >     >         > <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>
> <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>
> >     >         > <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>>>, Jong-
> Hyouk Lee <[email-masked] <mailto:[email-masked]>
> >     >         > <mailto:[email-masked] <mailto:[email-masked]>
> >     >         > <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>>>
> >     >         > >     >
> >     >         > >     >
> >     >         > >     >
> >     >         > >     > until the htmlized version and diff are available at
> tools.ietf.org <http://tools.ietf.org> <http://tools.ietf.org>

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Tue, 7 May 2019 17:36:00 +0200

Hi Pascal, Brian,

Good you are happy with the latest edits. We want to move this doc forward.

If someone else in the WG has any additional comments, please raise your
voice now. If no additional comments are received, we will proceed with the
current version at the end of this week.

Thanks,

Carlos

On Tue, May 7, 2019 at 5:27 PM Pascal Thubert (pthubert) <[email-masked]>
wrote:

> Starting with ND in P2P cases enables to experiment with the current
> stacks. I'm just concerned that as usual the temporary solution gets cast
> in stone. This is why I do not want to oversell what you can do with
> classical ND. This is why I feel better with other IPv6-over-foo that
> evaluated WiND and went for it day 1, e.g., Bluetooth or 802.15.4.
>
> On the bright side this was a trigger for writing
> https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless, which
> was needed anyway. OCB is mentioned as an example of Direct MAC without
> emulation, so basically the models we can build are the same as with
> 802.15.4 just larger in size, higher in throughput, and possibly less
> stable in case of mobility. If I got something wrong about OCB in the draft
> please let me know.
>
> All the best,
>
> Pascal
>
> document
> document.
> > >     > You need to be patient as we -authors- are with ALL the reviews
> we
> > get  from ALL!
> > >     > I will read your draft.
> > >     >
> explain
> > >     >       * Scope? Which scope? Write it in the I-draft else this is
> an empty
> > claim.____
> discusses ND
> > >     >         > From: Brian E Carpenter <[email-masked]
> > >     >         > To: NABIL BENAMAR <[email-masked]
> > >     >         > Thubert (pthubert) <[email-masked]
> > >     >         > Subject: Re: Fwd: New Version Notification for
> draft-ietf-ipwave-
> > ipv6-over-
> > >     >         > 80211ocb-45.txt
> > >     >         >
> > >     >         > Hi Nabil,
> > >     >         >
> > >     >         > draft-thubert-6man-ipv6-over-wireless are important,
> but that's a
> > separate
> > >     >         > discussion.
> > >     >         >
> > >     >         > Regards
> > >     >         >    Brian
> > >     >         >
> > TBD
> > >     >         > > TBD" from the Appendix J. I will also make sure that
> we have
> > only "link-local"
> > >     >         > > We have tightened the scope in version 45 of the
> document. Do
> > you still
> > >     >         > have concerns about  ND?
> > >     >         > >
> > >     >         > <[email-masked]
> > >     >         > >     Since you now say in the main text that "The
> subnet structure
> > on which
> > >     >         > the Neighbor Discovery protocol (ND) on OCB works ok
> is a single-
> > link subnet;"
> > >     >         > I think it would be OK to simply remove that sentence
> in the
> > Appendix.
> > >     >         > >
> > >     >         > >     For me it seems OK now. I assume you will also
> get final
> > comments from
> > >     >         > Pascal.
> > >     >         > >
> > >     >         > >     NIT: I noticed that both "link local" and
> "link-local" are used,
> > which is
> > >     >         > confusing when searching the document for that topic.
> RFC4291
> > only uses
> > >     >         > "link-local".
> > >     >         > >
> > >     >         > >     Regards
> > >     >         > >        Brian Carpenter
> > >     >         > >
> > >     >         > >     > I'm coming back to you to ask you what are the
> remaining
> > points about
> > >     >         > all ND issues that you still to be addressed in the
> current version of
> > the draft.
> > >     >         > >     >
> > >     >         > >     >
> internet-
> [email-masked]>
> draft-ietf-ipwave-ipv6-
> > over-
> > >     >         > <mailto:[email-masked]
> > >     >         > <mailto:[email-masked]
> > >     >         > <mailto:[email-masked]
> > >     >         > <mailto:[email-masked]
> > >     >         > >     > has been successfully submitted by Nabil
> Benamar and
> > posted to the
> > >     >         > >     > IETF repository.
> > >     >         > >     >
> > >     >         > >     > Name:
> > >     >         > >     > Title:          Transmission of IPv6 Packets
> over IEEE 802.11
> > Networks
> https://www.ietf.org/internet-drafts/draft-ietf-
> > ipwave-ipv6-
> > >     >         > over-80211ocb-45.txt
> > >     >         > >     > Status:
> https://datatracker.ietf.org/doc/draft-ietf-
> > ipwave-ipv6-over-
> > >     >         > 80211ocb/
> > >     >         > >     > Htmlized:
> https://tools.ietf.org/html/draft-ietf-ipwave-
> > ipv6-over-
> > >     >         > 80211ocb-45
> > >     >         > >     > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-
> > ietf-ipwave-
> > >     >         > ipv6-over-80211ocb
> > >     >         > >     > Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-
> > ipwave-ipv6-over-
> > >     >         > 80211ocb-45
> > >     >         > >     >
> > >     >         > >     > Abstract:
> > >     >         > >     >    In order to transmit IPv6 packets on IEEE
> 802.11 networks
> > running
> > >     >         > >     >    outside the context of a basic service set
> (OCB, earlier
> > "802.11p")
> > >     >         > >     >    there is a need to define a few parameters
> such as the
> > supported
> > >     >         > >     >    Maximum Transmission Unit size on the
> 802.11-OCB link,
> > the header
> > >     >         > >     >    format preceding the IPv6 header, the Type
> value within it,
> > and
> > >     >         > >     >    others.  This document describes how IPv6
> (including
> > addressing and
> > >     >         > >     >    basic ND) can be used to communicate among
> nodes in
> > range of one
> Optimizations and usage of
> > IPv6 over
> > >     >         > >     >    more complex scenarios is not covered and
> is subject of
> > future work.
> > >     >         > >     >
> > >     >         > >     >
> > >     >         > >     >
> > >     >         > >     >
> > >     >         > >     > Please note that it may take a couple of
> minutes from the
> > time of
> > >     >         > submission

-- 
Special Issue "Beyond 5G Evolution":
https://www.mdpi.com/journal/electronics/special_issues/beyond_5g

---

From: Nabil Benamar <[email-masked]>
Date: Tue, 7 May 2019 17:32:52 +0000

Thank you Pascal, Brian,

To summarize, we have 3 changes as follows:

OLD

The baseline Neighbor Discovery protocol (ND) [RFC4861 <
https://tools.ietf.org/html/rfc4861>] MUST be used over 802.11-OCB links.

NEW

The baseline Neighbor Discovery protocol (ND) [RFC4861 <
https://tools.ietf.org/html/rfc4861>] MUST be supported over 802.11-OCB
links.

This limitation of scope will be indicated in the Abstract and in the
Introduction in the following fashion:

in the Abstract:

OLD:

NEW:

In the Introduction:

OLD:
   IPv6 works fine directly over 802.11-OCB too, with an LLC layer.

NEW:

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

On Tue, May 7, 2019 at 3:36 PM CARLOS JESUS BERNARDOS CANO <[email-masked]>
wrote:

> On Tue, May 7, 2019 at 5:27 PM Pascal Thubert (pthubert) <
>> > >     >       * Scope? Which scope? Write it in the I-draft else this
>> is an empty
>> > claim.____
>> > >     >         > > TBD" from the Appendix J. I will also make sure
>> that we have
>> > only "link-local"
>> > <mailto:[email-masked] <mailto:[email-masked]
>> >
>> > >     >         > >     > I'm coming back to you to ask you what are
>> the remaining
>> > points about