Re: [ipwave] Mirja Kühlewind's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)

[Alexandre Petrescu <[e-mail]>]

Jérôme,

Here are some additional thoughts...

Le 20/07/2019 à 13:56, Jérôme Härri a écrit :
> Dear Alex, All,
> 
> I guess that on this aspect, we will need to agree that we disagree :-)
> 
> As accessing the ITS-G5 spectrum (so far) is still restricted by using 
> the ETSI stack, and as the ETSI stack uses QoS mapping to the QoSheaders 
> (the DCC and media-dependant Geonet specifications), then QoSheader are 
> required to access the ITS-G5 spectrum in EU...I shall also mention 
> (again..) that at that stage, accessing the ITS-G5 spectrum with 'pure' 
> IP over OCB is not allowed for _commercial usage_, as for this to 
> happen, two major aspects must be enforced:
> 
> 1) a security framework is required

The security framework may indeed be required.

But is it feasible?

Many of dployed RSUs I have been listening to dont implement it.  Only a 
minority does (one or two out of 20).

There are many CAMs, DENMs and SPAT-EMs on the road that are unsecured.
> 2) a mechanism to enforce IP-over-OCB to respect the duty cycle

One can try to implement QoS Data headers with IP.  And then, one should 
prove somehow that the QoS Data headers for IP do bring in some benefit 
compared to just Data headers.

I think there is no implementation and no preliminary prototype of 
implementation of IP with QoS Data headers on OCB.

> Both of these are not available so far for IP-over-OCB…but I am not sure 
> (and I guess other might have different perspective on this, in order to 
> make this draft move on), is that such restrictions are ‘spectrum’ 
> specific…, which is outside the scope of the IETF (as I understand 
> it)…so, I would not see such lack of specification blocking the current 
> draft, considering the fact that it includes a mention that 
> regional/national restrictions could apply, which would need an 
> additional specifications (at a later stage…).

I am trying to understand what you say.

You say that security framework and duty cycle are not available for 
IP-over-OCB.  I agree with you.

Then you say that lack of spec - presumably spec of security and duty 
cycling - should not block the advancement of IP-over-OCB.  I also agree 
with you.

But this is not what I meant.

I meant this: there is no implementation of IPV6-over-OCB with QoS Data 
headers.  As such the advancement of the IP-over-OCB spec SHOULD NOT be 
pursued in this direction.

> So, to my perspective, it is not what is 'available' but what is 
> 'required'…and this is pretty clear (and came straight from the ETSI ITS 
> chairs...)..
> 
> Yet, I also think that from a global perspective, IP-over-OCB should not 
> enforce using QoSHeaders, considering
> 
> 1) IP would provide the required priorization of channel access

Agreed.

> 2) the draft would indicate that this possibility is subject to 
> national/regional regulations that could say it differently.

No.

The national/regional regulations may stumble very hard when it comes to 
Internet.  Witness how GDPR makes that access to some website is simply 
blocked.

> And one last thing: if you access ITS-G5 with nonQoSheader and other 
> stations have QoS headers, then you will systematically loose !! That is 
> just due to the fact that nonQoSheaders can access the channel only 
> after an IDLE DIFS time...while nonQoSheader uses IDLE AIFS times, which 
> for 3 queues out of 4 are shorter than the DIFS...(not mentioning the 
> CW, which is also significantly shorter) So, I would say that using 
> nonQoSHeader will lead to performance drop when competing with other 
> ITS-G5/DSRC traffic on a same channel...(as most ITS-G5/DSRC traffic is 
> broadcast, their CW will never increase (while yours might) and always 
> be smaller than your NonQoSHeader profile).

I agree with you.  However, I do not fear the situation of 
systematically losing.

I trust more in the growth of channel capacity that will accomodate more 
as time goes by.  And so in an area whose size is defined by restricted 
power levels there would be enough space for all these IP and safety 
messages.

I fear more that QoS Data headers are put there below IP as a pretext, 
without demonstrating something guaranteed for the safety messages.

How would the benefits of an implementation of QoS Data headers below IP 
be demonstrated?  We tried with the tc command (that is in the IP 
fields, not in the 802.11 QoS Data fields), and iperf, and we could not 
demonstrate benefits of QoS: packets get lost despite QoS guarantees. 
Certainly, that is not 802.11 headers, but it is something to give an idea.

Alex

> 
> My two cents,
> 
> 
> BR,
> 
> Jérôme
> 
> -----Original Message-----
> From: its [mailto:[e-mail]] On Behalf Of Alexandre Petrescu
> Sent: Tuesday 16 July 2019 21:53
> To: Russ Housley
> Cc: Nabil Benamar; Mirja Kuehlewind; IESG; its
> Subject: Re: [ipwave] Mirja Kühlewind's Discuss on 
> draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)
> 
> Russ,
> 
> Sorry if the open-vs-closed text adds no clarity, but I do not know how
> 
> to express it better.
> 
> I think the special-purpose frequency allocation for 802.11-OCB does not
> 
> impose QoS Data headers, even though it does tell that range is for
> 
> safety applications for ITS.  I may be wrong though.
> 
> Finally, as far as I know, there are no IPv6-over-OCB implementations
> 
> with QoS Data headers, even if there are many implementations of CAM
> 
> and BSM over 802.11-OCB with such headers.  But I will be happy to stand
> 
> corrected if this were the case: is there an implementation of
> 
> IPv6-over-OCB with QoS Data headers?
> 
> Alex
> 
> Le 16/07/2019 à 18:56, Russ Housley a écrit :
> 
>  > Alex:
> 
>  >
> 
>  > I am very uncomfortable with your proposed text.  IEEE 802.11-OCB
> 
>  > uses special-purpose frequency allocation.  I think the text about
> 
>  > open vs. closed systems is going to add confusion, not clarity.
> 
>  >
> 
>  > Russ
> 
>  >
> 
>  >
> 
>  >> On Jul 16, 2019, at 4:36 AM, Alexandre Petrescu
> 
>  >> <[e-mail]> wrote:
> 
>  >>
> 
>  >> Russ,
> 
>  >>
> 
>  >> Le 15/07/2019 à 16:38, Russ Housley a écrit :
> 
>  >>> Alex: Of course, jamming will deny service, regardless of the
> 
>  >>> values used for the QoS bits. What would you like to see instead
> 
>  >>>  of the second MUST? Russ
> 
>  >>
> 
>  >> I would like to see something like this:
> 
>  >>
> 
>  >> OLD:
> 
>  >>> IP packets MUST be transmitted over 802.11-OCB media as QoS Data
> 
>  >>> frames whose format is specified in IEEE 802.11 spec
> 
>  >>> [IEEE-802.11-2016]. The IPv6 packet transmitted on 802.11-OCB are
> 
>  >>> 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 D), 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.
> 
>  >>
> 
>  >> NEW:
> 
>  >>> The IPv6 packets transmitted on 802.11-OCB are 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 D), the value of the
> 
>  >>>  Type field MUST be set to 0x86DD (IPv6). In open systems, the
> 
>  >>> 802.11 header preceding the IP header transmitted over 802.11-OCB
> 
>  >>> media MUST be an 802.11 Data header. In such systems, receivers
> 
>  >>> of IP packets over 802.11-OCB MUST understand and fully parse IP
> 
>  >>> packets preceded by 802.11 Data headers.  Receivers SHOULD NOT
> 
>  >>> drop IP packets preceded by 802.11 QoS Data headers. In closed
> 
>  >>> systems, the 802.11 header preceding the IP header transmitted
> 
>  >>> over 802.11-OCB media SHOULD be an 802.11 QoS Data header.  In
> 
>  >>> such systems, receivers of IP packets over 802.11-OCB MUST
> 
>  >>> understand and fully parse IP packets preceded by 802.11 QoS Data
> 
>  >>> headers.  In such systems, it is required that 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. The
> 
>  >>> frame format of 802.11 Data headers and QoS Data headers is
> 
>  >>> specifed in IEEE 802.11 spec [IEEE-802.11-2016].
> 
>  >>
> 
>  >> Alex
> 
>  >>
> 
>  >>>> On Jul 15, 2019, at 9:32 AM, Alexandre Petrescu
> 
>  >>>> <[e-mail]> wrote:
> 
>  >>>>
> 
>  >>>>
> 
>  >>>>
> 
>  >>>> Le 13/07/2019 à 04:53, Russ Housley a écrit :
> 
>  >>>>> Alex: I did not add or remove any MUST statements.  I only
> 
>  >>>>> added a phrase of rationale.
> 
>  >>>>
> 
>  >>>> I agree that the 2nd MUST was there before, and that a phrase
> 
>  >>>> of rationale was added.
> 
>  >>>>
> 
>  >>>> The phrase of rationale motivates the 2nd MUST.  It is
> 
>  >>>> logical.
> 
>  >>>>
> 
>  >>>> I agree with the rationale but I disagree with the MUST.
> 
>  >>>>
> 
>  >>>> (It is possible to implement the rationale without doing the
> 
>  >>>> MUST.  I.e. it is possible to guarantee time-sensitiveness and
> 
>  >>>>  criticality of safety by increasing bandwidth; reserving QoS
> 
>  >>>> priorities is but an alternative to satisfy the rationale
> 
>  >>>> within a limited bandwidth.)
> 
>  >>>>
> 
>  >>>> (the bandwidth available on 802.11 in OCB mode currently peaks
> 
>  >>>>  at 16Mbit/s theoretical within a range of approximately 1km
> 
>  >>>> measured.  The number of OCB interfaces in an OCB subnet of
> 
>  >>>> that physical size is less than hundreds, and certainly not
> 
>  >>>> thousands.  Within these dimensions, criticality and
> 
>  >>>> time-sensitiveness could be happening naturally.  An increase
> 
>  >>>> in theoretical bandwidth to approximately 54mbit/s would be
> 
>  >>>> even more sufficient)
> 
>  >>>>
> 
>  >>>> (disturbing the time-sensitiveness and criticality of safety
> 
>  >>>> can be realized despite the guarantees offered by QoS
> 
>  >>>> priorities; radio jamming and IP security attacks are easy to
> 
>  >>>> perform and would overcome QoS priorities.)
> 
>  >>>>
> 
>  >>>> Alex
> 
>  >>>>
> 
>  >>>>> Russ
> 
>  >>>>>> On Jul 12, 2019, at 8:32 AM, Alexandre Petrescu
> 
>  >>>>>> <[e-mail]> wrote:
> 
>  >>>>>>
> 
>  >>>>>> hats and freedoms are valuable.
> 
>  >>>>>>
> 
>  >>>>>> I disagree with the second MUST.  I will write a draft
> 
>  >>>>>> IPv6-over-OCB without QoS headers.
> 
>  >>>>>>
> 
>  >>>>>> Alex
> 
>  >>>>>>
> 
>  >>>>>> Le 11/07/2019 à 17:51, Russ Housley a écrit :
> 
>  >>>>>>> I suggest that the MUST statement remain, but that a bit
> 
>  >>>>>>>  of rationale be provided: The IPv6 packet transmitted on
> 
>  >>>>>>>  802.11-OCB are 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 D), 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
> 
>  >>>>>>>  (QoS with a 'Background' user priority), reserving
> 
>  >>>>>>> higher priority values for safety-critical and
> 
>  >>>>>>> time-sensitive traffic [IEEE-1609.2]. Russ
> 
>  >>>>>>>> On Jul 10, 2019, at 7:40 PM, John Kenney
> 
>  >>>>>>>> <[e-mail]
> 
>  >>>>>>>> <mailto:[e-mail]>> wrote:
> 
>  >>>>>>>>
> 
>  >>>>>>>> Hi All:
> 
>  >>>>>>>>
> 
>  >>>>>>>> I have no desire to re-litigate the QoS issue. However,
> 
>  >>>>>>>> it's important to remember that IP-over-OCB will
> 
>  >>>>>>>> typically share public regulated spectrum with non-IP
> 
>  >>>>>>>> safety-of-life communications. In the US, FCC
> 
>  >>>>>>>> regulations require that such safety communications
> 
>  >>>>>>>> have access priority over other communications [47 CFR
> 
>  >>>>>>>>  § 90.377(d)] .  I would be cautious about removing the
> 
>  >>>>>>>>  current language unless you are convinced that doing
> 
>  >>>>>>>> so will not adversely affect non-IP safety
> 
>  >>>>>>>> communications.
> 
>  >>>>>>>>
> 
>  >>>>>>>> Best Regards, John
> 
>  >>>>>>>>
> 
>  >>>>>>>> On Wed, Jul 10, 2019 at 6:18 AM Mirja Kuehlewind
> 
>  >>>>>>>> <[e-mail] <mailto:[e-mail]>>
> 
>  >>>>>>>> wrote:
> 
>  >>>>>>>>
> 
>  >>>>>>>> Thanks. Removing this text entirely is a good option.
> 
>  >>>>>>>>
> 
>  >>>>>>>> Mirja
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >>>>>>>>> On 10. Jul 2019, at 13:39, Nabil Benamar
> 
>  >>>>>>>> <[e-mail]
> 
>  >>>>>>>> <mailto:[e-mail]>> wrote:
> 
>  >>>>>>>>>
> 
>  >>>>>>>>> Hi Mirja,
> 
>  >>>>>>>>>
> 
>  >>>>>>>>> Actually, the text was written some time ago and
> 
>  >>>>>>>>> different views
> 
>  >>>>>>>> were shared in the group. I think we need to remove
> 
>  >>>>>>>> this text to avoid confusion.
> 
>  >>>>>>>>>
> 
>  >>>>>>>>> On Wed, Jul 10, 2019 at 8:44 AM Mirja Kuehlewind
> 
>  >>>>>>>> <[e-mail] <mailto:[e-mail]>>
> 
>  >>>>>>>> wrote:
> 
>  >>>>>>>>> Hi Nabil,
> 
>  >>>>>>>>>
> 
>  >>>>>>>>> I think my point was slightly different. Dorothy
> 
>  >>>>>>>>> mainly advised
> 
>  >>>>>>>> you _how_ to specify the priority. However my question
> 
>  >>>>>>>>  is rather _if_ that is needed and if it is really
> 
>  >>>>>>>> appropriate to use a MUST here. Can you further explain
> 
>  >>>>>>>> why that is seen as a mandatory requirement?
> 
>  >>>>>>>>>
> 
>  >>>>>>>>> Mirja
> 
>  >>>>>>>>>
> 
>  >>>>>>>>>
> 
>  >>>>>>>>>
> 
>  >>>>>>>>>> On 9. Jul 2019, at 23:29, Nabil Benamar
> 
>  >>>>>>>> <[e-mail]
> 
>  >>>>>>>> <mailto:[e-mail]>> wrote:
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> Hi Mirja,
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> Thank you for your review and comments.
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> You raised a very important point that was
> 
>  >>>>>>>>>> discussed
> 
>  >>>>>>>> extensively on the ML and then we asked the IEEE 802.11
> 
>  >>>>>>>> members (thanks to Dorothy Stanly) to provide us with a
> 
>  >>>>>>>> review to help us clarify this point.
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> Here is what we got from them:
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> .  Suggest to simply state that the data is
> 
>  >>>>>>>>>> transmitted with
> 
>  >>>>>>>> “User Priority” of Background (numerically 1 or 2), and
> 
>  >>>>>>>> leave the internal details of how this is accomplished
> 
>  >>>>>>>> to the 802.11 specification.
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> User Priority is typically described as a simple
> 
>  >>>>>>>>>> integer (not
> 
>  >>>>>>>> a binary value), and the mapping of this User Priority
> 
>  >>>>>>>>  to TID header value is another 802.11 detail, best
> 
>  >>>>>>>> left to the 802.11 specification.  For example: in the
> 
>  >>>>>>>>  802.11 specification the TID field is specified to be
> 
>  >>>>>>>> 4 bits in the header.  The use of these 4 bits to carry
> 
>  >>>>>>>> the User Priority information is an internal
> 
>  >>>>>>>> specification of 802.11 and potentially subject to
> 
>  >>>>>>>> change..
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> Suggest using terminology from the MAC SAP in IEEE
> 
>  >>>>>>>>>>  Std
> 
>  >>>>>>>> 802.11-2016 Clause 5.2.  This clause intentionally
> 
>  >>>>>>>> abstracts the exact details of 802..11’s internal
> 
>  >>>>>>>> operation, while describing specifically the behavior
> 
>  >>>>>>>> required by the user.  For example, the following
> 
>  >>>>>>>> text:
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> “In the 802.11 header, the value of the Subtype
> 
>  >>>>>>>>>> sub-field in
> 
>  >>>>>>>> the Frame Control field MUST be set to 8 (i.e. 'QoS
> 
>  >>>>>>>> Data'); the value of the Traffic Identifier (TID)
> 
>  >>>>>>>> sub-field of the QoS Control field of the 802.11 header
> 
>  >>>>>>>> MUST be set to binary 001 (i.e.  User Priority
> 
>  >>>>>>>> 'Background', QoS Access Category 'AC_BK').”
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> could be replaced by:
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> “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.”
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> Thanks again.
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> On Tue, Jul 9, 2019 at 5:43 PM Mirja Kühlewind via
> 
>  >>>>>>>>>>  Datatracker
> 
>  >>>>>>>> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>  >>>>>>>>>> Mirja Kühlewind has entered the following ballot
> 
>  >>>>>>>>>> position for
> 
>  >>>>>>>>>> draft-ietf-ipwave-ipv6-over-80211ocb-49: Discuss
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> When responding, please keep the subject line
> 
>  >>>>>>>>>> intact and reply
> 
>  >>>>>>>> to all
> 
>  >>>>>>>>>> email addresses included in the To and CC lines.
> 
>  >>>>>>>>>> (Feel free to
> 
>  >>>>>>>> cut this
> 
>  >>>>>>>>>> introductory paragraph, however.)
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> Please refer to
> 
>  >>>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >> for more information about IESG DISCUSS and COMMENT positions.
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> The document, along with other ballot positions,
> 
>  >>>>>>>>>> can be found
> 
>  >>>>>>>> here:
> 
>  >>>>>>>>>>
> 
>  >>>>>>>> 
> https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >>
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>>
> 
>  >>>>>>>> 
> ----------------------------------------------------------------------
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >> DISCUSS:
> 
>  >>>>>>>>>>
> 
>  >>>>>>>> 
> ----------------------------------------------------------------------
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >>
> 
>  >>>>>>>>>> One point on this sentence, which I believe was
> 
>  >>>>>>>>>> also commented
> 
>  >>>>>>>> in the TSV-ART
> 
>  >>>>>>>>>> review (Thanks Jörg!):
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> sec 4.2: "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."
> 
>  >>>>>>>>>> I don't think this should be a MUST requirement. I
> 
>  >>>>>>>>>> assume the
> 
>  >>>>>>>> assumption here
> 
>  >>>>>>>>>> is that IP traffic is always some "random" data
> 
>  >>>>>>>>>> that is less
> 
>  >>>>>>>> important than
> 
>  >>>>>>>>>> other V2V communication. However, this is a generic
> 
>  >>>>>>>>>> mapping
> 
>  >>>>>>>> document and should
> 
>  >>>>>>>>>> therefore probably not make such an assumption (or
> 
>  >>>>>>>>>>  at least it
> 
>  >>>>>>>> would need to be
> 
>  >>>>>>>>>> spelled out).
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>>
> 
>  >>>>>>>> 
> ----------------------------------------------------------------------
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >> COMMENT:
> 
>  >>>>>>>>>>
> 
>  >>>>>>>> 
> ----------------------------------------------------------------------
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >>
> 
>  >>>>>>>>>> One editorial high level comment: I seams like all
> 
>  >>>>>>>>>>  text that
> 
>  >>>>>>>> was somehow deemed
> 
>  >>>>>>>>>> as out fo scope for the main body of this document
> 
>  >>>>>>>>>>  got stuffed
> 
>  >>>>>>>> into the
> 
>  >>>>>>>>>> appendix. Please consider removing what is really
> 
>  >>>>>>>>>> not needed
> 
>  >>>>>>>> in this document
> 
>  >>>>>>>>>> as these pages also take review and RFC Editor
> 
>  >>>>>>>>>> time,
> 
>  >>>>>>>> especially as they seem to
> 
>  >>>>>>>>>> have received less review and therefore have more
> 
>  >>>>>>>>>> nits.
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> nit: sec 4.5.2 s/in OCB mode.A  A future
> 
>  >>>>>>>>>> improvement/in OCB
> 
>  >>>>>>>> mode. A future
> 
>  >>>>>>>>>> improvement/
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> --
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> Best Regards
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>> Nabil Benamar Associate Professor Department of
> 
>  >>>>>>>>>> Computer Sciences School of Technology Moulay
> 
>  >>>>>>>>>> Ismail University Meknes. Morocco
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>>
> 
>  >>>>>>>>>
> 
>  >>>>>>>>>
> 
>  >>>>>>>>>
> 
>  >>>>>>>>> --
> 
>  >>>>>>>>>
> 
>  >>>>>>>>> Best Regards
> 
>  >>>>>>>>>
> 
>  >>>>>>>>> Nabil Benamar Associate Professor Department of
> 
>  >>>>>>>>> Computer Sciences School of Technology Moulay Ismail
> 
>  >>>>>>>>>  University Meknes. Morocco
> 
>  >>>>>>>>>
> 
>  >>>>>>>>>
> 
>  >>>>>>>>
> 
>  >>>>>>>> _______________________________________________ its
> 
>  >>>>>>>> mailing list [e-mail] <mailto:[e-mail]>
> 
>  >>>>>>>> https://www.ietf.org/mailman/listinfo/its
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >>>>>>>>
> 
>  >>>>>>>> -- John Kenney Director and Sr. Principal Researcher
> 
>  >>>>>>>> Toyota InfoTech Labs 465 Bernardo Avenue Mountain View,
> 
>  >>>>>>>> CA 94043 Tel: [phone]. Mobile: [phone]
> 
>  >>>>>>> _______________________________________________ its
> 
>  >>>>>>> mailing list [e-mail]
> 
>  >>>>>>> https://www.ietf.org/mailman/listinfo/its
> 
>  >>>>
> 
>  >>>> _______________________________________________ its mailing
> 
>  >>>> list [e-mail] https://www.ietf.org/mailman/listinfo/its
> 
>  >>
> 
>  >> _______________________________________________ its mailing list
> 
>  >> [e-mail] https://www.ietf.org/mailman/listinfo/its
> 
>  >
> 
>  >
> 
> _______________________________________________
> 
> its mailing list
> 
> [e-mail]
> 
> https://www.ietf.org/mailman/listinfo/its
>