Subject: [ipwave] Title of draft-ietf-ipwave-ipv6-over-80211ocb-45

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 28 May 2019 13:52:23 +0000

Dear all:

Nabil and I are converging on the draft. One open item that deserves the group’s attention is the title.

The current title seems to indicate that the draft is *the* way of doing IPv6 over OCB when in fact it is the way to do that with minimal change to existing stacks.
As written, it indicates that IPWAVE is done and can close when in fact the work is just starting with 8 other drafts in progress. My suggestion is to change the title to add Minimal in it like we did multiple times at 6TiSCH.

Suggestion: change the title to:

Minimal support for IPv6 over IEEE Std 802.11 Networks operating Outside the Context of a Basic Service Set

This leaves opening for draft-jeong-ipwave-vehicular-mobility-management, draft-jeong-ipwave-vehicular-neighbor-discovery, and so on.

Does that make sense?

Pascal

From: Pascal Thubert (pthubert)
Sent: mardi 28 mai 2019 10:49
To: Nabil Benamar <[email-masked]>
Cc: [email-masked]
Subject: RE: [ipwave] rereview of draft-ietf-ipwave-ipv6-over-80211ocb-45

Hello Nabil:

In the next rev I expect to see text in the intro that states the scope of reusing legacy stacks with minimal changes.

Expressed that way, the discussion on legacy ND only and using the Ethernet distribution system and then a frame translation to 802.11, all makes full sense.
Also, this prepares for the work that the group has already started, which involves new stack elements better suited for OCB.

This should also be in the title. Suggestion for the new title:

Minimal support for IPv6 over IEEE Std 802.11 Networks operating Outside the Context of a Basic Service Set

The ‘minimal’ avoids the risk that the reader thinks that this draft has it all and that IPWAVE can close after that.

All the best,

Pascal

From: Nabil Benamar <[email-masked]<mailto:[email-masked]>>
Sent: lundi 27 mai 2019 17:12
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [ipwave] rereview of draft-ietf-ipwave-ipv6-over-80211ocb-45

Hi Pascal,

We are converging :)

See below

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

On Mon, May 27, 2019 at 2:47 PM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Nabil:

I removed the places where we already agree. Please see below for the remaining details

>  This should be out of scope and inherited from IPv6 over WiFi. If the draft does not exist then let us do one, at 6MAN.
Yes, I support this idea to initiate a new draft in 6MAN. I'm in!

>  The introduction should clatify the scope, which appears to be do with what existing stacks can do and (sometimes) see what’s missing.
Here is the new introduction (first paragraph), are we missing something else?

"This document describes the transmission of IPv6 packets on IEEE Std

802.11-OCB networks [IEEE-802.11-2016] (a.k.a "802.11p" see

Appendix B, Appendix C and Appendix D). This involves the layering

of IPv6 networking on top of the IEEE 802.11 MAC layer, with an LLC

layer. Compared to running IPv6 over the Ethernet MAC layer, there

is no modification expected to IEEE Std 802.11 MAC and Logical Link

sublayers: 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."

Pascal, I have just received a detailed review from some IEEE-802.11 members, thanks to Dorothy! One of the recommendation is to remove section 4.2.1 completely.

>    Good, we are converging.

I agree. It seems that by describing specific values, the text is redundant with what’s already in IEEE Std 802.11-2016

  *   In the <reference> tag to the IEEE spec just use <date/> . This actually removes the date. Also please remove -2016 from the spec name, just leave generic 802.11 dateless.
Ok.

  *
  *   Placing a date is misguided since we do not have a dependency on one particular version of 802.11. Indeed we want your spec to apply to all versions starting current, which is what is implied by dateless.
That's perfect.

  *

>  Are we sure of that, don’t we map QoS from ToS bits as usual with 11e?

Here is the new text to replace that paragraph:

" “The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded by a Logical Link Control (LLC) header and an 802.11 header. In the LLC header, and in accordance with the EtherType Protocol Discrimination (EPD, see Appendix E<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#appendix-E>), the value of the Type field MUST be set to 0x86DD (IPv6). The mapping to the 802.11 data service MUST use a ‘priority’ value of 1, which specifies the use of QoS with a “Background” user priority."

>    Can’t we use different QoS values like we can on WiFi?
That was the recommendation of IEEE 802.11 members, and I updated the draft based on your review and their recommendations. Please feel free to suggest other text here.

   To simplify the Application Programming Interface (API) between the
   operating system and the 802.11-OCB media, device drivers MAY
   implement an Ethernet Adaptation Layer that translates Ethernet II
   frames to the 802.11 format and vice versa.  An Ethernet Adaptation
   Layer is described in Section 4.2.1.

>  Do not call that an adaptation layer. The may refers to using an Ethernet stack and then a translation from Ethernet Frames to 802.11 frames as specified by IEEE.
What do you suggest instead?

>    Maybe that “an implementation may IPv6 over Ethernet per RFC 2464 and then a frame translation from 802.3 to 802.11 in order to  minimize the code changes”.

>    If minimal impact on the stack is the actual goal of this draft, which I think it is. This is what justifies publish this hastily and then do the real work that implies larger changes.

Sounds good for me!

4.4.  Stateless Autoconfiguration

   There are several types of IPv6 addresses [RFC4291], [RFC4193], that
   MAY be assigned to an 802.11-OCB interface.  This section describes
   the formation of Interface Identifiers for IPv6 addresses of type
   'Global' or 'Unique Local'.  For Interface Identifiers for IPv6
   address of type 'Link-Local' see Section 4.3.

>  Not really interesting. More important is to say that autoconf is defined in RFC 4862 and that is missing.
Didn't get your point! What is missing?

>    IPv6 autoconf is described in RFC 4862. This section does not refer to it, but rather duplicates the previous about address types, which is far from interesting.

>    I suggest you remove the text above and add a sentence that roughly introduce RFC 4862. Note that RFC 8505 does not change the autoconfiguration though it changes the way DAD is achieved.

Ok. I will include it in -46

>  MUST +> MAY. Say the scope of this doc only considers ND but neither RFC 8505 nor IPWAVE drafts.

Here is the new text as agreed last time with Brian:

"The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be
supported over 802.11-OCB links."

>   Yes, that works.

>  Remove or turn it the other way around like future solutions to OCB should consider solutions for avoiding broadcast.
I will reformulate in the following manner:

Transmitting ND packets may prove to have some performance issues.  These issues may be exacerbated in OCB
   mode.  Future solutions to OCB should consider solutions for avoiding broadcast.  The best of current knowledge indicates the kinds of issues that may arise with ND in OCB mode; they are described in Appendix J.

>    Good

All the best,

Pascal

Thank you once again.

I will publish version 46 soon.

>    Please ping me when done; do not forget to scope the document so that it is minimizing changes to existing stack and leveraging Ethernet implementation, with IPv6 ND and so on, and a focus on P2P over link local.

All the best,

Pascal

Thank you, Pascal for your time.

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 28 May 2019 19:40:58 +0200

On Tue, May 28, 2019 at 3:53 PM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Dear all:
>
> *   Nabil and I are converging on the draft. One open item that deserves
> the group’s attention is the title.   The current title seems to indicate
> that the draft is *the* way of doing IPv6 over OCB when in fact it is the
> way to do that with minimal change to existing stacks.*
>

we don't need to make changes to stacks if it works, so why adding minimal,
we may say simple way is more reasonable but minimal in used in LLN
networks or in networks of tiny nodes, we are doing large nodes with high
storage and computing,

* As written, it indicates that IPWAVE is done and can close when in fact
> the work is just starting with 8 other drafts in progress. My suggestion is
> to change the title to add Minimal in it like we did multiple times at
> 6TiSCH. *
>

I think IPWAVE is not done after this draft published, many WGs in IETF
don't close until the participants conclude, and we did not even suggest
that on the list.

> *   Suggestion: change the title to:   Minimal support for IPv6 over IEEE
> Std 802.11 Networks operating Outside the Context of a Basic Service Set *
>
don't agree

> *  This leaves opening for
> draft-jeong-ipwave-vehicular-mobility-management,
> draft-jeong-ipwave-vehicular-neighbor-discovery, and so on.*
>

even with the title decided by the WG, those drafts are to be considered.
Not sure what you mean!

> *   Does that make sense? *
>

Not clear, because the 6TiSCH  technology is different than ieee802.11ocb,
in 6TiSCH you may do minimals, and while using tiny nodes you need
cooperation and less use of nodes limited memory. In main WAVE networks we
have no memory limitations.

AB

>
>
> *From: Pascal Thubert (pthubert) Sent: mardi 28 mai 2019 10:49 To: Nabil
> Benamar <[email-masked]
> *> Cc: [email-masked]
> * Subject: RE: [ipwave] rereview of draft-ietf-ipwave-ipv6-over-*
> *80211ocb-45*
>
>
>
> *Hello Nabil:*
>
>
>
> *In the next rev I expect to see text in the intro that states the scope
> of reusing legacy stacks with minimal changes. *
>
>
>
> *Expressed that way, the discussion on legacy ND only and using the
> Ethernet distribution system and then a frame translation to 802.11, all
> makes full sense.*
>
> *Also, this prepares for the work that the group has already started,
> which involves new stack elements better suited for OCB.*
>
>
>
> *This should also be in the title. Suggestion for the new title: *
>
>
>
>
>
> *Minimal support for IPv6 over IEEE Std 802.11 Networks operating Outside
> the Context of a Basic Service Set*
>
>
>
>
>
> *The ‘minimal’ avoids the risk that the reader thinks that this draft has
> it all and that IPWAVE can close after that.*
>
>
>
> *All the best,*
>
>
>
> *Pascal*
>
>
>
> *From: Nabil Benamar <[email-masked]
>
> *> Sent: lundi 27 mai 2019 17:12 To: Pascal Thubert (pthubert) <*
> [email-masked]
> *> Cc: [email-masked]
> * Subject: Re: [ipwave] rereview of draft-ietf-ipwave-ipv6-over-*
> *80211ocb-45*
>
>
>
> *Hi Pascal,*
>
>
>
> *We are converging :)*
>
>
>
> *See below*
>
>
>
>
>
> *Best regards*
>
> *Nabil Benamar*
>
> * -------------------*
>
> * نبيل بنعمرو*
>
>
>
>
>
>
>
> *On Mon, May 27, 2019 at 2:47 PM Pascal Thubert (pthubert) <*
> [email-masked]*> wrote:*
>
> *Hello Nabil:*
>
>
>
> *I removed the places where we already agree. Please see below for the
> remaining details*
>
>
>
> * Ø  This should be out of scope and inherited from IPv6 over WiFi. If the
> draft does not exist then let us do one, at 6MAN.*
>
> *Yes, I support this idea to initiate a new draft in 6MAN. I'm in! *
>
> * Ø  The introduction should clatify the scope, which appears to be do
> with what existing stacks can do and (sometimes) see what’s missing.*
>
> *Here is the new introduction (first paragraph), are we missing something
> else?*
>
>
>
> *"This document describes the transmission of IPv6 packets on IEEE Std*
>
> * 802.11-OCB networks [IEEE-802.11-2016] (a.k.a "802.11p" see*
>
> * Appendix B, Appendix C and Appendix D). This involves the layering*
>
> * of IPv6 networking on top of the IEEE 802.11 MAC layer, with an LLC*
>
> * layer. Compared to running IPv6 over the Ethernet MAC layer, there*
>
> * is no modification expected to IEEE Std 802.11 MAC and Logical Link*
>
> * sublayers: 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."*
>
>
>
>
>
> *Pascal, I have just received a detailed review from some IEEE-802.11
> members, thanks to Dorothy! One of the recommendation is to remove section
> 4.2.1 completely.*
>
>
>
> *Ø    Good, we are converging.*
>
>
>
>
>
>
>
> *I agree. It seems that by describing specific values, the text is
> redundant with what’s already in IEEE Std 802.11-2016*
>
>
>    - * In the <reference> tag to the IEEE spec just use <date/> . This
>    actually removes the date. Also please remove -2016 from the spec name,
>    just leave generic 802.11 dateless.*
>
> *Ok. *
>
>
>    -
>    - * Placing a date is misguided since we do not have a dependency on
>    one particular version of 802.11. Indeed we want your spec to apply to all
>    versions starting current, which is what is implied by dateless.*
>
> *That's perfect. *
>
>
>    -
>
>
>
>
>
>
>
> * Ø  Are we sure of that, don’t we map QoS from ToS bits as usual with
> 11e?*
>
>
>
> *Here is the new text to replace that paragraph:*
>
>
>
> *" “The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded
> by a Logical Link Control (LLC) header and an 802.11 header. In the LLC
> header, and in accordance with the EtherType Protocol Discrimination (EPD,
> see Appendix E
> <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#appendix-E>),
> the value of the Type field MUST be set to 0x86DD (IPv6). The mapping to
> the 802.11 data service MUST use a ‘priority’ value of 1, which specifies
> the use of QoS with a “Background” user priority."*
>
>
>
> *Ø    Can’t we use different QoS values like we can on WiFi?*
>
> *That was the recommendation of IEEE 802.11 members, and I updated the
> draft based on your review and their recommendations. Please feel free to
> suggest other text here. *
>
>
>
>
>
>
>
> *   To simplify the Application Programming Interface (API) between the*
>
> *   operating system and the 802.11-OCB media, device drivers MAY*
>
> *   implement an Ethernet Adaptation Layer that translates Ethernet II*
>
> *   frames to the 802.11 format and vice versa.  An Ethernet Adaptation*
>
> *   Layer is described in Section 4.2.1.*
>
>
>
> * Ø  Do not call that an adaptation layer. The may refers to using an
> Ethernet stack and then a translation from Ethernet Frames to 802.11 frames
> as specified by IEEE.*
>
> *What do you suggest instead? *
>
>
>
>
>
> *Ø    Maybe that “an implementation may IPv6 over Ethernet per RFC 2464
> and then a frame translation from 802.3 to 802.11 in order to  minimize the
> code changes”.*
>
> *Ø    If minimal impact on the stack is the actual goal of this draft,
> which I think it is. This is what justifies publish this hastily and then
> do the real work that implies larger changes.*
>
> *Ø     *
>
> *Sounds good for me! *
>
>
>
>
>
>
>
>
>
> *4.4.  Stateless Autoconfiguration*
>
>
>
> *   There are several types of IPv6 addresses [RFC4291], [RFC4193], that*
>
> *   MAY be assigned to an 802.11-OCB interface.  This section describes*
>
> *   the formation of Interface Identifiers for IPv6 addresses of type*
>
> *   'Global' or 'Unique Local'.  For Interface Identifiers for IPv6*
>
> *   address of type 'Link-Local' see Section 4.3.*
>
>
>
> * Ø  Not really interesting. More important is to say that autoconf is
> defined in RFC 4862 and that is missing.*
>
> *Didn't get your point! What is missing? *
>
>
>
>
>
>
>
> *Ø    IPv6 autoconf is described in RFC 4862. This section does not refer
> to it, but rather duplicates the previous about address types, which is far
> from interesting.*
>
> *Ø    I suggest you remove the text above and add a sentence that roughly
> introduce RFC 4862. Note that RFC 8505 does not change the
> autoconfiguration though it changes the way DAD is achieved.*
>
>
>
>
>
> *Ok. I will include it in -46 *
>
>
>
>
>
> * Ø  MUST +> MAY. Say the scope of this doc only considers ND but neither
> RFC 8505 nor IPWAVE drafts.*
>
>
>
> *Here is the new text as agreed last time with Brian:*
>
>
>
> *"The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be*
>
> *supported over 802.11-OCB links."*
>
>
>
>
>
>
>
> * Ø   Yes, that works. *
>
>
>
>
>
> * Ø  Remove or turn it the other way around like future solutions to OCB
> should consider solutions for avoiding broadcast.*
>
> *I will reformulate in the following manner:*
>
>
>
> *Transmitting ND packets may prove to have some performance issues.  These
> issues may be exacerbated in OCB*
>
> *   mode.  Future solutions to OCB should consider solutions for avoiding
> broadcast.  The best of current knowledge indicates the kinds of issues
> that may arise with ND in OCB mode; they are described in Appendix J.*
>
>
>
>
>
> *Ø    Good*
>
>
>
>
>
>
>
>
>
> *All the best,*
>
>
>
> *Pascal*
>
>
>
>
>
> *Thank you once again.*
>
>
>
> *I will publish version 46 soon.*
>
>
>
>
>
>
>
> *Ø    Please ping me when done; do not forget to scope the document so
> that it is minimizing changes to existing stack and leveraging Ethernet
> implementation, with IPv6 ND and so on, and a focus on P2P over link local.*
>
>
>
> *All the best,*
>
>
>
> * Pascal*
>
>
>
> *Thank you, Pascal for your time.*
>
>
>
>
> * _______________________________________________ its mailing list
> [email-masked] <[email-masked]> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its> *

---

From: Russ Housley <[email-masked]>
Date: Wed, 29 May 2019 16:51:38 -0400

Pascal, I think that Basic support ..." would be a better title.

Rus

> On May 28, 2019, at 9:52 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Dear all:
>  
> To: Nabil Benamar <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> From: Nabil Benamar <[email-masked] <mailto:[email-masked]>> 
> To: Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> On Mon, May 27, 2019 at 2:47 PM Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> wrote:
> Hello Nabil:
>  
> Ø  This should be out of scope and inherited from IPv6 over WiFi. If the draft does not exist then let us do one, at 6MAN.
> 
> Ø  The introduction should clatify the scope, which appears to be do with what existing stacks can do and (sometimes) see what’s missing.
> 
> Ø    Good, we are converging.
> 
>  
>  
>  
> In the <reference> tag to the IEEE spec just use <date/> . This actually removes the date. Also please remove -2016 from the spec name, just leave generic 802.11 dateless.
> Ok. 
>  
> Placing a date is misguided since we do not have a dependency on one particular version of 802.11. Indeed we want your spec to apply to all versions starting current, which is what is implied by dateless.
> That's perfect. 
>  
>  
>  
>  
> Ø  Are we sure of that, don’t we map QoS from ToS bits as usual with 11e?
> 
>  
> " “The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded by a Logical Link Control (LLC) header and an 802.11 header. In the LLC header, and in accordance with the EtherType Protocol Discrimination (EPD, see Appendix E <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#appendix-E>), the value of the Type field MUST be set to 0x86DD (IPv6). The mapping to the 802.11 data service MUST use a ‘priority’ value of 1, which specifies the use of QoS with a “Background” user priority."
>  
> Ø    Can’t we use different QoS values like we can on WiFi?
> 
> Ø  Do not call that an adaptation layer. The may refers to using an Ethernet stack and then a translation from Ethernet Frames to 802.11 frames as specified by IEEE.
> 
> Ø    Maybe that “an implementation may IPv6 over Ethernet per RFC 2464 and then a frame translation from 802.3 to 802.11 in order to  minimize the code changes”.
> 
> Ø    If minimal impact on the stack is the actual goal of this draft, which I think it is. This is what justifies publish this hastily and then do the real work that implies larger changes.
> 
> Ø     
> 
> Sounds good for me! 
>  
>  
>  
>  
> Ø  Not really interesting. More important is to say that autoconf is defined in RFC 4862 and that is missing.
> 
> Ø    IPv6 autoconf is described in RFC 4862. This section does not refer to it, but rather duplicates the previous about address types, which is far from interesting.
> 
> Ø    I suggest you remove the text above and add a sentence that roughly introduce RFC 4862. Note that RFC 8505 does not change the autoconfiguration though it changes the way DAD is achieved.
> 
>  
>  
> Ø  MUST +> MAY. Say the scope of this doc only considers ND but neither RFC 8505 nor IPWAVE drafts.
> 
>  
> Ø   Yes, that works. 
> Ø  Remove or turn it the other way around like future solutions to OCB should consider solutions for avoiding broadcast.
> 
> Ø    Good
> Ø    Please ping me when done; do not forget to scope the document so that it is minimizing changes to existing stack and leveraging Ethernet implementation, with IPv6 ND and so on, and a focus on P2P over link local.
> 
>  
> All the best,
>  
> Pascal
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 29 May 2019 21:08:54 +0000

Basic works for me, Russ.

Regards,

Pascal

Le 29 mai 2019 à 22:51, Russ Housley <[email-masked]<mailto:[email-masked]>> a écrit :

Rus

On May 28, 2019, at 9:52 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Dear all:

Does that make sense?

Pascal

To: Nabil Benamar <[email-masked]<mailto:[email-masked]>>

Hello Nabil:

All the best,

Pascal

Hi Pascal,

We are converging :)

See below

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

Ok.

  *

That's perfect.

  *

Sounds good for me!

All the best,

Pascal

Thank you once again.

All the best,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 29 May 2019 21:21:07 +0000

On second thoughts basic reads as barebone but in fact the Ethernet stack is complex. What we do is minimal changes to it.

So why exactly does basic seem better to you Russ?

Pascal

________________________________
De : Russ Housley <[email-masked]>
Envoyé : mercredi, mai 29, 2019 10:51 PM
À : Pascal Thubert (pthubert)
Cc : [email-masked]
Objet : Re: Title of draft-ietf-ipwave-ipv6-over-80211ocb-45

Rus

Dear all:

Does that make sense?

Pascal

Hello Nabil:

All the best,

Pascal

Hi Pascal,

We are converging :)

See below

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

Ok.

  *

That's perfect.

  *

Sounds good for me!

All the best,

Pascal

Thank you once again.

All the best,

Pascal

---

From: Russ Housley <[email-masked]>
Date: Wed, 29 May 2019 17:39:06 -0400

I worry that "minimal" sounds like something was left out, but that is not the case.

Russ

> On May 29, 2019, at 5:21 PM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> De : Russ Housley <[email-masked] <mailto:[email-masked]>>
> Cc : [email-masked] <mailto:[email-masked]>
>> On May 28, 2019, at 9:52 AM, Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Dear all:
>>

---

From: Nabil Benamar <[email-masked]>
Date: Wed, 29 May 2019 21:45:36 +0000

Hi Russ, Pascal

That was exactly what I was thinking about the "minimal" term in the title!

'Basic'...works for me.

On Wed, May 29, 2019, 21:39 Russ Housley <[email-masked]> wrote:

> On second thoughts basic reads as barebone but in fact the Ethernet stack
> is complex. What we do is minimal changes to it.
>
> ------------------------------
> *De :* Russ Housley <[email-masked]>
> *Envoyé :* mercredi, mai 29, 2019 10:51 PM
> *À :* Pascal Thubert (pthubert)
> *Cc :* [email-masked]
> *Objet :* Re: Title of draft-ietf-ipwave-ipv6-over-80211ocb-45
>
>
> The current title seems to indicate that the draft is **the** way of
> doing IPv6 over OCB when in fact it is the way to do that with minimal
> change to existing stacks.
> As written, it indicates that IPWAVE is done and can close when in fact
> 6TiSCH.
> This leaves opening for draft-jeong-ipwave-vehicular-mobility-management,
> draft-jeong-ipwave-vehicular-neighbor-discovery, and so on.
>
> Does that make sense?
>
> Pascal
>
> *From:* Pascal Thubert (pthubert)
> *Sent:* mardi 28 mai 2019 10:49
> *To:* Nabil Benamar <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* RE: [ipwave] rereview of
> draft-ietf-ipwave-ipv6-over-80211ocb-45
>
> Hello Nabil:
>
> In the next rev I expect to see text in the intro that states the scope of
> reusing legacy stacks with minimal changes.
>
> Expressed that way, the discussion on legacy ND only and using the
> makes full sense.
> Also, this prepares for the work that the group has already started, which
> involves new stack elements better suited for OCB.
>
> The ‘minimal’ avoids the risk that the reader thinks that this draft has
> it all and that IPWAVE can close after that.
>
> All the best,
>
> Pascal
>
> *From:* Nabil Benamar <[email-masked]>
> *Sent:* lundi 27 mai 2019 17:12
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [ipwave] rereview of
> draft-ietf-ipwave-ipv6-over-80211ocb-45
>
> Hi Pascal,
>
> We are converging :)
>
> See below
>
>
> Best regards
> Nabil Benamar
> -------------------
> نبيل بنعمرو
>
>
>
> On Mon, May 27, 2019 at 2:47 PM Pascal Thubert (pthubert) <
> Ø  This should be out of scope and inherited from IPv6 over WiFi. If the
> draft does not exist then let us do one, at 6MAN.
>
> Ø  The introduction should clatify the scope, which appears to be do with
> what existing stacks can do and (sometimes) see what’s missing.
>
> Pascal, I have just received a detailed review from some IEEE-802.11
> 4.2.1 completely.
> I agree. It seems that by describing specific values, the text is
> redundant with what’s already in IEEE Std 802.11-2016
>
>
>    - In the <reference> tag to the IEEE spec just use <date/> . This
>    just leave generic 802.11 dateless.
>
> Ok.
>
>
>    -
>    - Placing a date is misguided since we do not have a dependency on one
>    particular version of 802.11. Indeed we want your spec to apply to all
>    versions starting current, which is what is implied by dateless.
>
> That's perfect.
>
>
>    -
>
>
>
>
>
>
> " “The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded
> the use of QoS with a “Background” user priority."
>
>
> That was the recommendation of IEEE 802.11 members, and I updated the
> suggest other text here.
> Ø  Do not call that an adaptation layer. The may refers to using an
> as specified by IEEE.
> Ø    Maybe that “an implementation may IPv6 over Ethernet per RFC 2464
> code changes”.
> Ø    If minimal impact on the stack is the actual goal of this draft,
> do the real work that implies larger changes.
>
> Ø
>
> Sounds good for me!
>
>
>
>
>
>
>
> Ø    IPv6 autoconf is described in RFC 4862. This section does not refer
> from interesting.
> Ø    I suggest you remove the text above and add a sentence that roughly
> autoconfiguration though it changes the way DAD is achieved.
>
>
> Ø  Remove or turn it the other way around like future solutions to OCB
> should consider solutions for avoiding broadcast.
>
>    mode.  Future solutions to OCB should consider solutions for avoiding
> that may arise with ND in OCB mode; they are described in Appendix J.
>
>
>
> Ø    Good
>
>
>
>
>
> All the best,
>
> Pascal
>
>
>
> Thank you once again.
>
> Ø    Please ping me when done; do not forget to scope the document so
> implementation, with IPv6 ND and so on, and a focus on P2P over link local.
>
> All the best,
>
> Pascal
>
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 30 May 2019 05:28:18 +0000

Oh yes a lot is left out.

Applicability of existing RFCs is not studied e.g., Wireless ND.
There is already work at IPWAVE that suggests new options.
What’s in is what you can do with an Ethernet stack and a translation.
This is a lot less than on WiFi because OCB as no BSS.

On the bright side if nothing was left out the WG could close...

Regards,

Pascal

Le 29 mai 2019 à 23:39, Russ Housley <[email-masked]<mailto:[email-masked]>> a écrit :

Russ

On May 29, 2019, at 5:21 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Pascal

________________________________
De : Russ Housley <[email-masked]<mailto:[email-masked]>>
Envoyé : mercredi, mai 29, 2019 10:51 PM
À : Pascal Thubert (pthubert)
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: Title of draft-ietf-ipwave-ipv6-over-80211ocb-45

Rus

Dear all:

Does that make sense?

Pascal

Hello Nabil:

All the best,

Pascal

Hi Pascal,

We are converging :)

See below

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

Ok.

  *

That's perfect.

  *

Sounds good for me!

All the best,

Pascal

Thank you once again.

All the best,

Pascal

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Thu, 30 May 2019 09:35:47 +0200

Hi Pascal,

I also prefer "Basic" because the doc's scope is to provide a basic support
of IPv6 over IEEE 802.11-OCB networks, meaning simple scenarios and
not-optimized operation. To me "minimal" has negative implications and I
don't like it. Using "Basic" leaves room for potential future optimizations
and/or updates to the basic spec.

I think "Basic" is a good compromise between what you suggests and what has
been the WG consensus so far (leaving the title as is). Let's use "Basic"
and move on with the document. We need to make it progress in order to be
able to discuss of potential future work.

Thanks,

Carlos

On Thu, May 30, 2019 at 7:28 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Le 29 mai 2019 à 23:39, Russ Housley <[email-masked]> a écrit :
>

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

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 30 May 2019 16:36:25 +0000

I am not sure either about such fundamental changes after WGLC, and at this stage.  All these changes are based on on one reviewer feedback, reverting a consensus established over a 2 year time. I cannot also ignore the fact that one of the lead author went silent for bizarre reasons, and these changes are now creeping in. There are clear statements on what the draft can do, or cannot do, and so cannot see objective reasoning in trying to dumb it down further. For what?

Sri

From: its <[email-masked]<mailto:[email-masked]>> on behalf of CARLOS JESUS BERNARDOS CANO <[email-masked]<mailto:[email-masked]>>
Date: Thursday, May 30, 2019 at 12:35 AM
To: "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>
Cc: Russ Housley <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ipwave] Title of draft-ietf-ipwave-ipv6-over-80211ocb-45

Hi Pascal,

I also prefer "Basic" because the doc's scope is to provide a basic support of IPv6 over IEEE 802.11-OCB networks, meaning simple scenarios and not-optimized operation. To me "minimal" has negative implications and I don't like it. Using "Basic" leaves room for potential future optimizations and/or updates to the basic spec.

I think "Basic" is a good compromise between what you suggests and what has been the WG consensus so far (leaving the title as is). Let's use "Basic" and move on with the document. We need to make it progress in order to be able to discuss of potential future work.

Thanks,

Carlos

On Thu, May 30, 2019 at 7:28 AM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Oh yes a lot is left out.

Regards,

Pascal

Russ

On second thoughts basic reads as barebone but in fact the Ethernet stack is complex. What we do is minimal changes to it..

Pascal

Rus

Dear all:

The current title seems to indicate that the draft is *the* way of doing IPv6 over OCB when in fact it is the way to do that with minimal change to existing stacks.
As written, it indicates that IPWAVE is done and can close when in fact the work is just starting with 8 other drafts in progress. My suggestion is to change the title to add Minimal in it like we did multiple times at 6TiSCH..

Does that make sense?

Pascal

Hello Nabil:

All the best,

Pascal

Hi Pascal,

We are converging :)

See below

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

Ok.

  *

That's perfect.

  *

Sounds good for me!

All the best,

Pascal

Thank you once again.

All the best,

Pascal

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

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 30 May 2019 21:14:35 +0000

Hello Carlos

6TiSCH published a number of minimal specs and we certainly did not mean it pejoratively.
Basic is very similar and it works with me too...

All the best,

Pascal

Le 30 mai 2019 à 18:36, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> a écrit :

Sri

Hi Pascal,

Thanks,

Carlos

Regards,

Pascal

Russ

Pascal

Rus

Dear all:

Does that make sense?

Pascal

Hello Nabil:

All the best,

Pascal

Hi Pascal,

We are converging :)

See below

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

Ok.

  *

That's perfect.

  *

Sounds good for me!

All the best,

Pascal

Thank you once again.

All the best,

Pascal