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

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Feb 2018 13:19:13 +0100

Hi IPWAVErs,

I submitted a new version of the IPv6-over-OCB draft - the 17th.

The ChangeLog is:

         Susbtituted "MUST be increased" to "is increased" in the
         MTU section, about fragmentation.

The phrases in question are:

NEW:

>                                       If IPv6 packets of size larger than
>     1500 bytes are sent on an 802.11-OCB interface card then the IP stack
>     MUST fragment.  In case there are IP fragments, the field "Sequence
>     number" of the 802.11 Data header containing the IP fragment field is
>     increased.

OLD:

>                                       If IPv6 packets of size larger than
>     1500 bytes are sent on an 802.11-OCB interface card then the IP stack
>     MUST fragment.  In case there are IP fragments, the field "Sequence
>     number" of the 802.11 Data header containing the IP fragment field
>     MUST be increased.

Alex

-------- Message transféré --------
Sujet : 	New Version Notification for 
draft-ietf-ipwave-ipv6-over-80211ocb-17.txt
Date : 	Thu, 15 Feb 2018 04:15:12 -0800
De : 	[email-masked]
Pour : 	Jerome Haerri <[email-masked]>, 
[email-masked], Jerome Haerri <[email-masked]>, 
Alexandre Petrescu <[email-masked]>, Alexandre Petrescu 
<[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-17.txt
has been successfully submitted by Alexandre Petrescu and posted to the
IETF repository.

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	17
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:	2018-02-15
Group:		ipwave
Pages:		39
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-17.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-17
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-17
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-17

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

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Feb 2018 13:20:12 +0100

Tony,

I hope this is fine?

Alex

Le 15/02/2018 à 13:19, Alexandre Petrescu a écrit :
> URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-17.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-17
> Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-17
> Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-17
> 
> Abstract:
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: [email-masked]
Date: Thu, 15 Feb 2018 08:32:17 -0800

> I hope this is fine?

Thank you for making this change while we discuss it.

May I also suggest some additional wordsmithing?

>>>    MUST fragment.  

Could you please substitute ‘the MTU’ instead of ‘1500 bytes’ in this sentence.

If the MTU has been changed from the default of 1500 bytes, we want the IP-OBU to fragment based on the configured MTU, not based on the default.

Since this is IPv6, this should only happen at the original packet source.

Tony

---

From: Nabil Benamar <[email-masked]>
Date: Thu, 15 Feb 2018 16:39:20 +0000

Yes, I agree with Tony....We do not need to stick with the 1500 bytes value.

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

On Thu, Feb 15, 2018 at 4:32 PM, <[email-masked]> wrote:

> If the MTU has been changed from the default of 1500 bytes, we want the
> IP-OBU to fragment based on the configured MTU, not based on the default.
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Feb 2018 18:30:21 +0100

I agree, I will update

(we do stick with the default 1500, but in the subsequent phrase we talk 
about MTU instead of 1500)

Le 15/02/2018 à 17:39, Nabil Benamar a écrit :
> On Thu, Feb 15, 2018 at 4:32 PM, <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>     > I hope this is fine?
> 
> 
> 
>     If the MTU has been changed from the default of 1500 bytes, we want
>     the IP-OBU to fragment based on the configured MTU, not based on the
>     default.
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/its>
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Feb 2018 19:19:30 +0100

Le 15/02/2018 à 18:48, Dick Roy a écrit :
> You should make it clear wherever you state that an MTU is 1500 that such a
> restriction applies to 802.3 ethernet, and that other DLL protocols have
> other MTU sizes/lengths.

WEll but here we are in that ethernet case, not in the case of other DLL 
protocols.

When we write Internet Draft for IP over DLL protocol then we will write 
another value for the MTU in there.

> BTW - I believe you should also make it clear, if
> you are going to stress MTU sizes, that that is a MAC frame size limit, and
> the MSDU (NPDU) must account for the MAC header size lest fragmentation
> happen at the MAC.

I believe that's what the current text tries to say.

>  This is why 1609.3 has a WSMMaxLength default of 1400,
> not 1500.

That, allow me to remark, sounds dubious.  It's as if a MAC header was 
of precisely 100byte length...  Or maybe the specifier just wanted to be 
on the safe side and added approximately 100 bytes to be sure.

Alex

> 
> RR
> 
> -----Original Message-----
> From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Thursday, February 15, 2018 9:30 AM
> To: Nabil Benamar; Tony Li
> Cc: [email-masked]
> Subject: Re: [ipwave] New Version Notification for

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 16 Feb 2018 05:40:37 +0200

> I agree, I will update
That field is not sequence number field, but sequence control field. Each
sequence control field contains two subfields, the sequence number , and
fragment number. I think we should increase the fragment number within the
sequence control field.

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 16 Feb 2018 12:18:47 +0200

On Fri, Feb 16, 2018 at 9:10 AM, Dick Roy <[email-masked]> wrote:

> The field in question is a MAC fragmentation control field, NOT a network
> layer control field.  Any thought that the IPv6 protocol should update, or
> cause to be updated, a fragmentation control field in a lower layer is
> misguided, a layer violation, and will not work w.p.1.
>
>
>
> I highly recommend you not do this.
>

I agree with you. My reply just was to answer if the WG-and-authors
insisted to go that path,

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 16 Feb 2018 12:46:38 +0200

On Thu, Feb 15, 2018 at 2:19 PM, Alexandre Petrescu <
[email-masked]> wrote:

> Replace last sentence above>

In case there are IP fragments, the subfield fragment number within the
field "Sequence
   control" of The 802.11 data header containing the IP fragment is
increased by MAC layer.

AB

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 16 Feb 2018 12:03:40 +0100

Le 16/02/2018 à 11:46, Abdussalam Baryun a écrit :
> 
> 
> On Thu, Feb 15, 2018 at 2:19 PM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi IPWAVErs,
> 

Is the combination of Fragment Number and Sequence Number subfields 
called "Sequence control" by IEEE?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 16 Feb 2018 12:15:22 +0100

This is the NEW text in my local copy.  There is some issue with the 
submission system (wrong date, and new Trust 200912 instead of 200902). 
I will submit as soon as the system works.

>                                                           If IPv6
>           packets of size larger than the MTU are sent on an
>           802.11-OCB interface card then the IP stack MUST fragment.
>           In case there are IPv6 fragments, the subfield "Fragment
>           number" within the field "Sequence control" of the 802.11
>           Data header containing the IPv6 fragment is increased by the
>           MAC layer.

Alex

Le 16/02/2018 à 12:03, Alexandre Petrescu a écrit :
>> In case there are IP fragments, the subfield fragment number within 
>> the field "Sequence

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 16 Feb 2018 17:42:42 +0200

On Fri, Feb 16, 2018 at 1:03 PM, Alexandre Petrescu <
[email-masked]> wrote:

>> [email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>>     Hi IPWAVErs,
>>
> Is the combination of Fragment Number and Sequence Number subfields called
> "Sequence control" by IEEE?
>

Yes, as in ieee802.11-2016-std- p646,  the sequence control is 2 octets, 4
bits only for fragment number and 12 for sequence.

B0                              B3   B4
    B15

+-----------------+--------------------------+

| Fragment number |       Sequence number    |

+-----------------+--------------------------+

The sequence number within the Sequence Control field remains the same for
all fragments, while the fragment number within the Sequence Control field
increments for each fragment.

AB

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 16 Feb 2018 16:45:40 +0100

Le 16/02/2018 à 16:42, Abdussalam Baryun a écrit :
> 
> 
> On Fri, Feb 16, 2018 at 1:03 PM, Alexandre Petrescu 
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
> 
>              Hi IPWAVErs,
> 
>         In case there are IP fragments, the subfield fragment number
>         within the field "Sequence
>              control" of The 802.11 data header containing the IP
>         fragment is increased by MAC layer.
> 
> 
> Yes, as in ieee802.11-2016-std- p646,  the sequence control is 2 octets, 
> 4 bits only for fragment number and 12 for sequence.
> 
> B0   B3   B4                        B15
> 
> The sequence number within the Sequence Control field remains the same 
> for all fragments, while the fragment number within the Sequence Control 
> field increments for each fragment.

Thanks for the explanation.  Makes sense.

Do they say whether the fragments are IP fragments or not?

Because in implementation, whenever there is an IP fragment, that 
fragment number field is incremented.

And there seems to be strong opposition we write this.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 16 Feb 2018 17:53:22 +0100

Le 16/02/2018 à 17:20, Dick Roy a écrit :
> "Do they say whether the fragments are IP fragments or not?"
> 
> Of course 802.11 does not say anything about what is being 
> fragmented. It DOES NOT KNOW!  How can it unless it inspects the 
> MSDU, and 802.11 DOES NOT DO THAT!

Well 802.11 does inspect the *DU for which it is in charge, and that
contains the EtherType which is 0x86DD which stands for IPv6.

> Nor does it care! Any reference, especially if it's normative, to
> 802.11 fragmentation should be removed from the draft.

If we remove that frag text should we also delete de implementation of it?

Alex

> 
> RR
> 
> -----Original Message----- From: its [mailto:[email-masked]]
> On Behalf Of Alexandre Petrescu Sent: Friday, February 16, 2018 7:46
> AM To: Abdussalam Baryun Cc: [email-masked] Subject: Re: [ipwave] Fwd:
> New Version Notification for
>> <mailto:[email-masked]>>
> wrote:
>> 
>> 
>> 
>> <[email-masked] <mailto:[email-masked]>
>> Susbtituted "MUST be increased" to "is increased" in the MTU 
>> section, about fragmentation.
>> 
>> If IPv6 packets of size larger than 1500 bytes are sent on an 
>> 802.11-OCB interface card then the IP stack MUST fragment.  In
>> case there are IP fragments, the field "Sequence number" of the
>> 802.11 Data header containing the IP fragment field is increased.
>> 
>> 
>> within the field "Sequence control" of The 802.11 data header
>> containing the IP fragment is increased by MAC layer.
>> 
>> 
>> Yes, as in ieee802.11-2016-std- p646,  the sequence control is 2 
>> octets, 4 bits only for fragment number and 12 for sequence.
>> 
>> B0   B3   B4                        B15
>> 
>> The sequence number within the Sequence Control field remains the 
>> same for all fragments, while the fragment number within the 
>> Sequence Control field increments for each fragment.
> 
> _______________________________________________ its mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/its
> 
>

---

From: Tony Li <[email-masked]>
Date: Fri, 16 Feb 2018 08:55:29 -0800

>> Of course 802.11 does not say anything about what is being fragmented. It DOES NOT KNOW!  How can it unless it inspects the MSDU, and 802.11 DOES NOT DO THAT!
> 

Yes please.

That’s just a fundamental confusion of the word ‘fragment’ being used independently by two layers. They should NEVER be tied together.

Tony

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 16 Feb 2018 19:39:26 +0200

On Fri, Feb 16, 2018 at 5:45 PM, Alexandre Petrescu <
[email-masked]> wrote:

> [...]

We always try to make sense or explain reasons so we go forward,

> Do they say whether the fragments are IP fragments or not?

we are discussing IPv6, why we think about other,

>
> Because in implementation, whenever there is an IP fragment, that fragment
> number field is incremented.
>

ok

> And there seems to be strong opposition we write this.

Why, when was it off list?

Just make a decision so we go forward, I don't want us to delay, let us
decide together and move on, I agreed with some participant in that we
leave the mac  functions to it, but I don't say we don't discuss what to
write in reasonable engineering way.

Yes they oppose that writing text that includes something IP canot do in
MAC.

 I mentioned it is  fragment increase by MAC layer, while you posted the
question. I seen no opposition to my new text. Furthermore, IMHO, they need
to give reasonable reason, or as you said it makes sense,

However, we don't forget that this MAC has limited fragmentation numbers so
only 16, but IP has more, so we can recommend here.

What you think?

AB

---

From: Tony Li <[email-masked]>
Date: Fri, 16 Feb 2018 09:44:07 -0800

>  I mentioned it is  fragment increase by MAC layer, while you posted the question. I seen no opposition to my new text.

I am opposed to your proposal.  You have not fixed the problem. This document should have NO mention of fragmentation at all.

Tony

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 16 Feb 2018 20:02:41 +0200

On Fri, Feb 16, 2018 at 6:20 PM, Dick Roy <[email-masked]> wrote:

> Of course 802.11 does not say anything about what is being fragmented.  It
> DOES NOT KNOW!  How can it unless it inspects the MSDU, and 802.11 DOES NOT
> DO THAT! Nor does it care!

it should care to do it job, better service to upper layers,

> Any reference, especially if it's normative, to

we are saying if IPv6 fragments transmitted on ieee802.11, we don't care
about mac but about best practice for IPv6 transmission on such media (I
will not say careless media but wireless ).

AB

> Sent: Friday, February 16, 2018 7:46 AM
> To: Abdussalam Baryun
> Cc: [email-masked]
> Subject: Re: [ipwave] Fwd: New Version Notification for

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 19 Feb 2018 15:18:13 +0100

Le 16/02/2018 à 19:26, Dick Roy a écrit :
> Sent: Friday, February 16, 2018 8:53 AM
> To: [email-masked]; 'Abdussalam Baryun'
> Cc: [email-masked]
> [RR] It ONLY does that on a DL_Unitdata.indication, NOT on a .request.

Yes, and the .indication could contain an IPv6 data packet that has a an 
IPv6 Extension header titled Fragment.

The MAC layer could have found that header, or maybe it was indicated by 
some other instruction in the same computer that this data structure to 
become a packet is an IP fragment.

> Indications go up the stack, requests go down!

> [RR] Absolutely!

Well, but that is hard to achieve, because there are many implementations.

That said.

If there is nobody in need of this fragmentation aspect (the IP fragment 
is preceded by a fragment indication in the MAC header) then maybe we 
could be silent about it, and remove that sentence which tells what MAC 
does.  It is not normative text, it is just observation.

Alex

---

From: Tony Li <[email-masked]>
Date: Mon, 19 Feb 2018 07:51:39 -0800

> The MAC layer could have found that header, or maybe it was indicated by some other instruction in the same computer that this data structure to become a packet is an IP fragment.

Think about that.  The MAC layer could look inside the IPv6 packet. Parse it. Look for an extension header. Skip past the Hop-by-Hop Options header, Destination Options header, and Routing header. And only then realize that it has a Fragment Header.

> If there is nobody in need of this fragmentation aspect (the IP fragment is preceded by a fragment indication in the MAC header) then maybe we could be silent about it, and remove that sentence which tells what MAC does.  It is not normative text, it is just observation.

The text as written is ambiguous and will lead to inconsistent implementations. Because you have not used normative RFC 2119 language, some people will ignore it. However, some people will take a natural language English implementation and implement it.

Worse yet, experienced implementors will look at the spec and question the sanity of it.

Tony

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 21 Feb 2018 06:17:44 +0200

On Tue, Feb 20, 2018 at 7:55 AM, Dick Roy <[email-masked]> wrote:

> Please understand that fragmentation at any given layer is handled by that
> layer and that layer only.

ok,  agree that each layer does its fragmentation, so we can suggest to
change or delete the last sentence

OLD>

the MTU are sent on an 802.11-OCB interface card then the IP stack

MUST fragment. In case there are IPv6 fragments, the subfield

"Fragment number" within the field "Sequence control" of the 802.11

Data header containing the IPv6 fragment is increased by the MAC

layer.

NEW>

the MTU are sent on an 802.11-OCB interface card then the IP stack

MUST fragment.

Another NEW option>

the MTU are sent on an 802.11-OCB interface card then the IP stack

MUST fragment. The MAC sublayer may fragment IPv6 packets or
fragments, while increasing the subfield

"Fragment number" within the field "Sequence control" of the 802.11

Data header containing the IPv6 packet or fragment.

AB> it states in the document that MAC sublayer may not fragment depending
on the capability of receiver/destination. There is a management
negotiation that informs about capabilities.

Regards

AB

---

From: Tony Li <[email-masked]>
Date: Tue, 20 Feb 2018 21:01:47 -0800

> the MTU are sent on an 802.11-OCB interface card then the IP stack

Thank you, this is a vast improvement. 

Now, I’ll point out that the remaining sentence is highly redundant: fragmentation is already well defined in terms of the MTU.  RFC 2460, section 4.5 says:

"The Fragment header is used by an IPv6 source to send a packet larger
   than would fit in the path MTU to its destination.  (Note: unlike
   IPv4, fragmentation in IPv6 is performed only by source nodes, not by
   routers along a packet's delivery path -- see section 5.)”

> MUST fragment. The MAC sublayer may fragment IPv6 packets or fragments, while increasing the subfield
> 

First, this should never happen, as it implies that the packet is both less than or equal to the MTU and at the same time larger than the MTU.  Second, I can’t quote chapter and verse, but I’d bet that this is already covered in 802.11-OCB.  Thus, it’s again redundant.

I’ll propose a third alternative: how about we just delete the paragraph entirely?

> AB> it states in the document that MAC sublayer may not fragment depending on the capability of receiver/destination. There is a management negotiation that informs about capabilities.
> 

All nodes on an IP subnet are presumed to be using the same MTU layer, thus, fragmentation should be done by the packet source and never again. In particular IPv6 should never, ever inject a packet that needs MAC fragmentation.

Tony

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 21 Feb 2018 14:04:35 +0200

> Thank you, this is a vast improvement.

No problem, I always try to work with the WG to improve our work,

>
> Now, I’ll point out that the remaining sentence is highly redundant:
> fragmentation is already well defined in terms of the MTU.  RFC 2460,
> section 4.5 says:
>

The redundant does not harm, but we don't forget that that sentence was
there and I am not sure who was interested to keep it, maybe redundant to
clarify the 1500 MTU issue,

> First, this should never happen, as it implies that the packet is both
> less than or equal to the MTU and at the same time larger than the MTU.
> Second, I can’t quote chapter and verse, but I’d bet that this is already
> covered in 802.11-OCB.  Thus, it’s again redundant.
>

I don't think so, because 802.11-OCB does fragmentation not based on MTU
issues, but based on reliability of wireless communication and improvement
and efficiency, reed the section of fragmentation/defagmentation
section 10.2.7

in that section 10.2.7 -std-802.11-2016>

Fragmentation creates MPDUs smaller than the original MSDU or MMPDU length
to increase

reliability, by increasing the probability of successful transmission (as
defined in 10.2.2) of the MSDU or

MMPDU when channel characteristics limit reception reliability for longer
frames.

AB> it is important to clarify that both layer do fragmentation in
different purposes, and it can happen in such medium and environment,

> I’ll propose a third alternative: how about we just delete the paragraph

But why? however, I never opposed WG decision of fragment text, only if
there are good reasons,

> All nodes on an IP subnet are presumed to be using the same MTU layer,
> thus, fragmentation should be done by the packet source and never again. In
> particular IPv6 should never, ever inject a packet that needs MAC
> fragmentation.
>

Again, MAC fragmentation is important for using the channel and reliability
of MAC-transmissions. This fragmentation mechanism is done through using
management frames between MAC entities and MLME. Shorter frames get faster
transmitted and also MSDUs specially when using PHY layer capabilities,

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 21 Feb 2018 14:11:52 +0200

> particular IPv6 should never, ever inject a packet that needs MAC

Again, MAC fragmentation is important for using the wireless channel and
reliability of MAC-transmissions. Figure 5 in our draft defines the
reference model and also in the std-802.11 while including MLME and PLME.
This fragmentation mechanism is done through using
management frames/negotiation between MAC entities and MLME. Shorter frames
get faster transmitted and also MSDUs specially when using PHY
layer capabilities,

AB

---

From: [email-masked]
Date: Wed, 21 Feb 2018 07:19:50 -0800

> The redundant does not harm, but we don't forget that that sentence was there and I am not sure who was interested to keep it, maybe redundant to clarify the 1500 MTU issue,

Redundancy is unnecessary and always creates the potential for conflicting interpretations between two documents. These are protocol specifications we’re writing, not Dickensian novels. If we do not mean to revise or update the behavior described in another document, we should not be restating it.

Our focus should be purely on the interaction between IPv6 and IEEE 802.11-OCB.  We shouldn’t go repeating the fundamentals of either side of the interaction.

>> The MAC sublayer may fragment IPv6 packets or fragments, while increasing the subfield
>> 
> I don't think so, because 802.11-OCB does fragmentation not based on MTU issues, but based on reliability of wireless communication and improvement and efficiency, reed the section of fragmentation/defagmentation section 10.2.7
> 
> Fragmentation creates MPDUs smaller than the original MSDU or MMPDU length to increase
> 
> reliability, by increasing the probability of successful transmission (as defined in 10.2.2) of the MSDU or
> 
> MMPDU when channel characteristics limit reception reliability for longer frames.
> 

Thank you for the clarification.  Again, given that, mentioning OCB fragmentation is again unnecessary. It is wholly independent of IPv6.

> AB> it is important to clarify that both layer do fragmentation in different purposes, and it can happen in such medium and environment,
> 

I think it raises more confusion than clarity.  

> But why? however, I never opposed WG decision of fragment text, only if there are good reasons,

Because it adds no value. What would an implementer do differently with the proposed text? If it does not affect the bits on the wire, then it doesn’t need to be in the spec.

Tony