Re: [ipwave] ND an link-layer acks - text

[Alexandre Petrescu <[e-mail]>]

Le 06/12/2018 à 14:39, Dick Roy a écrit :
> Because there will be many situations in OCB operation where IPv6 is either
> NOT deployed (and therefore not used), or is simply unavailable for a
> variety of reasons, all well-known.  In such situations, ND can NOT be used.
> That's why I suggest "can be" rather than "is".  Now that you see the point,
> feel free to change the text to make this point if you like.

I see the point.

I propose the following: the IETF Internet Draft says "ND is used" and 
another SDO says "WSMP is used".

Do you disagree with this proposal?

Alex

> 
> 
> 
> -----Original Message-----
> From: its [mailto:[e-mail]] On Behalf Of Alexandre Petrescu
> Sent: Wednesday, December 5, 2018 11:39 PM
> To: [e-mail]; 'Dorothy Stanley'
> Cc: [e-mail]; [e-mail]; 'John Kenney';
> [e-mail]; lorenzo=[e-mail];
> [e-mail]
> Subject: Re: [ipwave] ND an link-layer acks - text
> 
> Why dont you agree with 'is used'?
> 
> Le 06/12/2018 à 02:21, Dick Roy a écrit :
>> I'd suggest:
>>
>> "The Neighbor Discovery protocol (ND) [RFC4861] can be used over IEEE
>> 802.11-OCB links."
>>
>> ------------------------------------------------------------------------
>>
>> *From:*its [mailto:[e-mail]] *On Behalf Of *Dorothy Stanley
>> *Sent:* Wednesday, December 5, 2018 12:42 PM
>> *To:* Alexandre Petrescu
>> *Cc:* [e-mail]; [e-mail]; [e-mail]; John
>> Kenney; lorenzo=[e-mail]; [e-mail]
>> *Subject:* Re: [ipwave] ND an link-layer acks - text
>>
>> Alexandre,
>>
>> I am fine with the proposed new text.
>>
>> Dorothy
>>
>> ----------------------
>> Dorothy Stanley
>> IEEE 802.11 WG Chair, [e-mail] <mailto:[e-mail]>
>> Hewlett Packard Enterprise
>> [e-mail] <mailto:[e-mail]>
>> [e-mail] <mailto:[e-mail]>
>> [phone] <tel:[phone]>
>>
>> On Wed, Dec 5, 2018 at 7:13 AM Alexandre Petrescu
>> <[e-mail] <mailto:[e-mail]>>
> wrote:
>>
>>      Hello Dorothy,
>>
>>      I thus suggest the following text.  Do you agree with this text?
>>
>>      NEW:
>>        > The Neighbor Discovery protocol (ND) [RFC4861] is used over
>>        > 802.11-OCB links.
>>
>>      OLD:
>>      > The Neighbor Discovery protocol (ND) [RFC4861] is used over
>>      > 802.11-OCB links.  Due to lack of link-layer acknowledgements in
>>      > 802.11-OCB for both unicast and multicast, we can expect higher
>>      > unicast loss than for 802.11 BSS.  The ND retransmissions are
>>      > supposed to handle loss of unicast and/or multicast just as it does
>>      > for other link types.
>>
>>      Alex
>>
>>
>>
>>
>>
>>
> -------------------------ignore-------------------------------------------
>>      Because:
>>      Yous suggest one might mention DSRC apps rarely rely on Acks: I think
>>      it's hard to talk about DSRC applications in a network-layer document;
>>      but I tend to agree with you about the presence of Acks in OCB
>>      implementations, some times (not always); for the broadcast/multicast
>>      term: I find the term ambiguous: IPv6 does not know about
>>      'broadcast' at
>>      all (and that's an IPv6-over-WiFi matter, not OCB in particular).
>>
>>
>>      Le 05/12/2018 à 15:24, Dorothy Stanley a écrit :
>>      > Hello Alexandre,
>>      >
>>      > The sentence " Due to lack of association operations in 802.11-OCB,
>>      > we can expect higher packet loss than for 802.11 BSS."
>>      >
>>      > is not correct.  The lack of acknowledgements for
> broadcast/multicast
>>      >  traffic is the same in OCB and BSS operation. The presence of
>>      > acknowledgements for unicast trafic is the same in OCB and BSS
>>      > operation. The lack of asssociation operation is irrelevant.
>>      >
>>      > If the intent is to say that unacknowledged broadcast traffic is
>>      > heavily used in DSRC applications, then just say that.
>>      >
>>      > I suggest deleting the current sentence.
>>      >
>>      > Dorothy
>>      >
>>      > ---------------------- Dorothy Stanley IEEE 802.11 WG Chair,
>>      > [e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>> Hewlett Packard
>>      > Enterprise [e-mail] <mailto:[e-mail]>
>>      > <mailto:[e-mail]
> <mailto:[e-mail]>>
>>      [e-mail] <mailto:[e-mail]>
>>      > <mailto:[e-mail] <mailto:[e-mail]>> +1
>>      630-363-1389 <tel:[phone]>
>>      >
>>      >
>>      >
>>      > On Wed, Dec 5, 2018 at 2:52 AM Alexandre Petrescu
>>      > <[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail]
>>      <mailto:[e-mail]>>>
>>      > wrote:
>>      >
>>      > John, Jérôme :  you seem to be agreeing.
>>      >
>>      > So, how about this text proposal?
>>      >
>>      > NEW:
>>      >> The Neighbor Discovery protocol (ND) [RFC4861] is used over
>>      >> 802.11-OCB links.  Due to lack of association operations in
>>      >> 802.11-OCB, we can expect higher packet loss than for 802.11 BSS.
>>      >> The ND retransmissions are supposed to handle loss of IP unicast
>>      >> and/or IP multicast just as it does for other link types.
>>      >
>>      > (remark 'lack of association operations' instead of 'lack of
>>      > link-layer acks')
>>      >
>>      > OLD:
>>      >> The Neighbor Discovery protocol (ND) [RFC4861] is used over
>>      >> 802.11-OCB links.  Due to lack of link-layer acknowledgements in
>>      >> 802.11-OCB for both unicast and multicast, we can expect higher
>>      >> unicast loss than for 802.11 BSS.  The ND retransmissions are
>>      >> supposed to handle loss of unicast and/or multicast just as it
>>      >> does for other link types.
>>      > I will not modify this text until I dont have agreements and from
>>      > you and from a representative of 6MAN WG.  It's a text that has been
> 
>>      > crafted in fine detail.
>>      >
>>      > Alex
>>      >
>>      > Le 05/12/2018 à 03:09, Jérôme Härri a écrit :
>>      >> Hi All,
>>      >>
>>      >> I support John's comment. ITS-G5/DSRC/OCB can fully do unicast
>>      >> with acks. It is the application that chose not to use this but
>>      >> rather broadcast. And even considering broadcast, I do not think we
>>      >> have higher packet losses. Just that we do not retransmit, as it
>>      >> is broadcast. Maybe we should mention reduced 'application-layer
>>      >> reliability' so something in that direction..
>>      >>
>>      >>
>>      >> BR,
>>      >>
>>      >> Jérôme
>>      >>
>>      >> *From:*its [mailto:[e-mail]
> <mailto:[e-mail]>
>>      > <mailto:[e-mail] <mailto:[e-mail]>>] *On
> Behalf Of
>>      *John Kenney
>>      >> *Sent:* Tuesday 04 December 2018 16:38 *To:* Alexandre Petrescu
>>      >> *Cc:* its; Dorothy Stanley *Subject:* Re: [ipwave] Fwd: New
>>      >> Version Notification for
>>      >> draft-ietf-ipwave-ipv6-over-80211ocb-31.txt
>>      >>
>>      >> Hi,
>>      >>
>>      >> Caveat: I know nothing about Neighbor Discovery protocol.
>>      >>
>>      >> I see this in the proposed new text:
>>      >>
>>      >> Due to lack of link-layer acknowledgements in 802.11-OCB, we can
>>      >> expect higher packet loss than for 802.11 BSS.
>>      >>
>>      >> I don't understand why it is expected that OCB has a lack of
>>      >> link-layer acknowledgments.  OCB uses link layer acks the same  way
>>      >> as 802.11 BSS uses them.   If I send a unicast 802.11 packet
>>      >> outside the context of a BSS, I expect an 802.11 ACK. If I don't
>>      >> get the 802.11 ACK, I go through exponential backoff and
>>      >> retransmit.  Just like normal 802.11.  Maybe I'm missing
>>      >> something.
>>      >>
>>      >> Best Regards,
>>      >>
>>      >> John
>>      >>
>>      >> On Tue, Dec 4, 2018 at 7:11 AM Alexandre Petrescu
>>      >> <[e-mail] <mailto:[e-mail]>
>>      > <mailto:[e-mail]
> <mailto:[e-mail]>>
>>      > <mailto:[e-mail]
> <mailto:[e-mail]>
>>      > <mailto:[e-mail]
> <mailto:[e-mail]>>>>
>>      >> wrote:
>>      >>
>>      >>
>>      >>
>>      >> Le 04/12/2018 à 16:04, Dorothy Stanley a écrit :
>>      >>> Hello Alexandre, all,
>>      >>>
>>      >>> I am sharing the following information from John Kenny (
>>      >>> [e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>
>>      > <mailto:[e-mail] <mailto:[e-mail]>
>>      > <mailto:[e-mail]
> <mailto:[e-mail]>>>
>>      >> <mailto:[e-mail]
> <mailto:[e-mail]>
>>      >> <mailto:[e-mail]
> <mailto:[e-mail]>>
>>      >> <mailto:[e-mail]
> <mailto:[e-mail]>
>>      > <mailto:[e-mail]
> <mailto:[e-mail]>>>>), who is
>>      >>> actively involved in 802.11p implementation and deployments:
>>      >>> "OCB can use unicast in the same way as other flavors of  802.11
>>      >>> ( individually addressed 802.11 MAC PDU that is ACKed using
>>      >>> 802.11 procedures ). I find this is a common misunderstanding
>>      >>> (indeed, I am in a meeting right now where this very point came
>>      >>> up about 20 minutes ago). Probably the confusion is partly due to
>>      >>> the fact that a great deal of DSRC attention is focused on the
>>      >>> broadcast Basic Safety Message. Some people think that DSRC is
>>      >>> only BSMs, or only broadcast messages. But, there are some
>>      >>> important unicast applications as well."
>>      >>>
>>      >>> Thus a change is needed in 4.7, either delete the second
>>      >>> sentence or modify to reflect that unicast is acknowledged.
>>      >>
>>      >> I propose
>>      >>
>>      >> NEW:
>>      >>> The Neighbor Discovery protocol (ND) [RFC4861] is used over
>>      >>> 802.11-OCB links.  Due to lack of link-layer acknowledgements  in
>>      >>> 802.11-OCB, we can expect higher packet loss than for 802.11
>>      >>> BSS. The ND retransmissions are supposed to handle loss of IP
>>      >>> unicast and/or IP multicast just as it does for other link
>>      >>> types.
>>      >>
>>      >> (remark disappeared 'unicast' and 'multicast' from 2nd phrase, and
>>      >> added 'IP' in front of unicast and multicast in 3rd phrase).
>>      >>
>>      >> OLD:
>>      >>> The Neighbor Discovery protocol (ND) [RFC4861] is used over
>>      >>> 802.11-OCB links.  Due to lack of link-layer acknowledgements  in
>>      >>> 802.11-OCB for both unicast and multicast, we can expect higher
>>      >>> unicast loss than for 802.11 BSS.  The ND retransmissions are
>>      >>> supposed to handle loss of unicast and/or multicast just as it
>>      >>> does for other link types.
>>      >>
>>      >> Would this be agreed by John Kenney.
>>      >>
>>      >> Alex
>>      >>
>>      >>>
>>      >>> Thanks,
>>      >>>
>>      >>> Dorothy
>>      >>>
>>      >>> ---------------------- Dorothy Stanley IEEE 802.11 WG Chair,
>>      >>> [e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>
>>      > <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>>
>>      >> <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>
>>      > <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>>> Hewlett
>>      >> Packard
>>      >>> Enterprise [e-mail]
> <mailto:[e-mail]>
>>      > <mailto:[e-mail] <mailto:[e-mail]>>
>>      <mailto:[e-mail] <mailto:[e-mail]>
>>      > <mailto:[e-mail] <mailto:[e-mail]>>>
>>      >>> <mailto:[e-mail]
> <mailto:dstanley@arubanetworks..com>
>>      > <mailto:[e-mail]
> <mailto:[e-mail]>>
>>      >> <mailto:[e-mail]
> <mailto:[e-mail]>
>>      > <mailto:[e-mail]
> <mailto:[e-mail]>>>>
>>      [e-mail] <mailto:[e-mail]>
>>      > <mailto:[e-mail] <mailto:[e-mail]>>
>>      >> <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>>
>>      >>> <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>
>>      > <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:dstanley1389@gmail..com>>>>
>>      >> [phone] <tel:[phone]>
>>      >>>
>>      >>>
>>      >>>
>>      >>> On Mon, Nov 19, 2018 at 10:07 AM Alexandre Petrescu
>>      >>> <[e-mail]
> <mailto:[e-mail]>
>>      >>> <mailto:[e-mail]
> <mailto:[e-mail]>>
>>      >> <mailto:[e-mail]
> <mailto:[e-mail]>
>>      > <mailto:[e-mail]
> <mailto:[e-mail]>>>
>>      >> <mailto:[e-mail]
> <mailto:[e-mail]>
>>      > <mailto:[e-mail]
> <mailto:[e-mail]>>
>>      >> <mailto:[e-mail]
> <mailto:[e-mail]>
>>      > <mailto:[e-mail]
> <mailto:[e-mail]>>>>>
>>      >>> wrote:
>>      >>>
>>      >>> Hi IPWAVErs,
>>      >>>
>>      >>> Following the discussion during presentation of the IPv6/OCB
>>      >>> slides by Nabil during IPWAVE WG meeting, I have updated the
>>      >>> IPv6/OCB draft.
>>      >>>
>>      >>> This is the ChangeLog:
>>      >>>
>>      >>> - filled in the section titled "Pseudonym Handling"; -  removed a
>>      >>> 'MAY NOT' phrase about possibility of having other prefix than
>>      >>> the LL on the link between cars; - shortened and improved the
>>      >>> paragraph about Mobile IPv6, now with DNAv6; - improved the ND
>>      >>> text about ND retransmissions with relationship to packet loss;
>>      >>> - changed the title of an appendix from 'EPD' to 'Protocol
>>      >>> Layering'; - improved the 'Aspects introduced by OCB' appendix
>>      >>> with a few phrases about the channel use and references.
>>      >>>
>>      >>> This fixes all issues about ND and pseudonym handling.
>>      >>>
>>      >>> Alex
>>      >>>
>>      >>> -------- Message transféré -------- Sujet : New Version
>>      >>> Notification for draft-ietf-ipwave-ipv6-over-80211ocb-31.txt
>>      >>> Date : Mon, 19 Nov 2018 10:01:52 -0800 De :
>>      >>> [e-mail] <mailto:[e-mail]>
>>      > <mailto:[e-mail] <mailto:[e-mail]>>
>>      >> <mailto:[e-mail] <mailto:[e-mail]>
>>      >> <mailto:[e-mail]
> <mailto:[e-mail]>>>
>>      >>> <mailto:[e-mail] <mailto:[e-mail]>
>>      >>> <mailto:[e-mail]
> <mailto:[e-mail]>>
>>      >> <mailto:[e-mail] <mailto:[e-mail]>
>>      > <mailto:[e-mail]
> <mailto:[e-mail]>>>> Pour :
>>      Jerome Haerri
>>      >>> <[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>
>>      > <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>>
>>      >> <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>
>>      >> <mailto:Jerome.Haerri@eurecom <mailto:Jerome.Haerri@eurecom>.
>>      >> <mailto:Jerome.Haerri@eurecom
> <mailto:Jerome.Haerri@eurecom>.>.fr>>>,
>>      >>> [e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>
>>      > <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:ipwave-chairs@ietf..org>>>
>>      >> <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>
>>      > <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:ipwave-chairs@ietf..org>>>>,
>>      >> Jerome Haerri
>>      >>> <[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>
>>      > <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>>
>>      >> <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>
>>      >> <mailto:jerome.haerri@eurecom <mailto:jerome.haerri@eurecom>.
>>      >> <mailto:jerome.haerri@eurecom
> <mailto:jerome.haerri@eurecom>.>.fr>>>,
>>      >>> Alexandre Petrescu <[e-mail]
> <mailto:[e-mail]>
>>      > <mailto:[e-mail]
> <mailto:[e-mail]>>
>>      >> <mailto:[e-mail]
> <mailto:[e-mail]>
>>      >> <mailto:[e-mail]
> <mailto:[e-mail]>>>
>>      >>> <mailto:[e-mail]
> <mailto:[e-mail]>
>>      >>> <mailto:[e-mail]
> <mailto:[e-mail]>>
>>      >> <mailto:[e-mail]
> <mailto:[e-mail]>
>>      > <mailto:[e-mail]
> <mailto:[e-mail]>>>>>,
>>      Alexandre Petrescu
>>      >>> <[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>
>>      > <mailto:[e-mail] <mailto:[e-mail]>
>>      > <mailto:[e-mail]
> <mailto:[e-mail]>>>
>>      >> <mailto:[e-mail]
> <mailto:[e-mail]>
>>      >> <mailto:[e-mail]
> <mailto:[e-mail]>>
>>      >> <mailto:[e-mail]
> <mailto:[e-mail]>
>>      > <mailto:[e-mail]
> <mailto:[e-mail]>>>>>, Nabil
>>      >>> Benamar <[e-mail] <mailto:[e-mail]>
>>      > <mailto:[e-mail] <mailto:[e-mail]>>
>>      <mailto:[e-mail] <mailto:[e-mail]>
>>      > <mailto:[e-mail] <mailto:[e-mail]>>>
>>      >> <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>
>>      > <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>>>>,
>>      >>> Thierry Ernst <[e-mail]
> <mailto:[e-mail]>
>>      > <mailto:[e-mail] <mailto:[e-mail]>>
>>      >> <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>>
>>      >>> <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>
>>      >> <mailto:[e-mail] <mailto:[e-mail]>
>>      > <mailto:[e-mail]
> <mailto:[e-mail]>>>>>,
>>      Jong-Hyouk Lee
>>      >>> <[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>
>>      > <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>>
>>      >> <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>
>>      > <mailto:[e-mail] <mailto:[e-mail]>
>>      <mailto:[e-mail] <mailto:[e-mail]>>>>>
>>      >>>
>>      >>>
>>      >>> A new version of I-D,
>>      >>> draft-ietf-ipwave-ipv6-over-80211ocb-31.txt has been successfully
>>      >>> submitted by Alexandre Petrescu and posted to the IETF
>>      >>> repository.
>>      >>>
>>      >>> Name:           draft-ietf-ipwave-ipv6-over-80211ocb Revision:
>>      >>> 31 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-11-19
>>      >>> Group: ipwave Pages: 41 URL:
>>      >>>
>>      >>
>>      >
> https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-31
> .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-31
>>      >
>>      >>>
>>      >
>>      >>>
>>      >>>
>>      >> 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-31
>>      >
>>      >
>>      >
>>      >>
>>      >>
>>      >>
>>      >>>
>>      >>>
>>      >>>
>>      >> 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 <http://tools.ietf.org> <http://tools.ietf.org>
>>      >>> <http://tools.ietf.org>
>>      > <http://tools.ietf.org>.
>>      >>>
>>      >>> The IETF Secretariat
>>      >>>
>>      >>> _______________________________________________ its mailing list
>>      >>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>>      <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>>      > <mailto:[e-mail] <mailto:[e-mail]>>> <mailto:[e-mail]
>>      <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>>      >> <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>>      <mailto:[e-mail]>>>>
>>      >>> https://www.ietf.org/mailman/listinfo/its
>>      >>>
>>      >>
>>      >> _______________________________________________ its mailing list
>>      >> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>>      <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>>      > <mailto:[e-mail] <mailto:[e-mail]>>>
>>      >> https://www.ietf.org/mailman/listinfo/its
>>      >>
>>      >>
>>      >> --
>>      >>
>>      >> John Kenney
>>      >>
>>      >> Director and Principal Researcher
>>      >>
>>      >> Toyota InfoTechnology Center, USA
>>      >>
>>      >> 465 Bernardo Avenue
>>      >>
>>      >> Mountain View, CA 94043
>>      >>
>>      >> Tel: [phone]. Mobile: [phone]
>>      >>
>>      >
>>      > _______________________________________________ its mailing list
>>      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>>      <mailto:[e-mail]>>
>>      > https://www.ietf.org/mailman/listinfo/its
>>      >
>>
> 
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its
> 
>