Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 12 April 2019 20:28 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D37D12006D; Fri, 12 Apr 2019 13:28:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTRZbiWXZMLr; Fri, 12 Apr 2019 13:28:41 -0700 (PDT)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2B6120145; Fri, 12 Apr 2019 13:28:39 -0700 (PDT)
Received: by mail-pl1-x62a.google.com with SMTP id ck15so5660173plb.3; Fri, 12 Apr 2019 13:28:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=m4Bm2CqQ897i8Jfzzd/zqgAzZLse8dPQRhyflO/OITM=; b=nMzTbYQYYkKo399WxIDyheR6E6G0XEH1AIaPJku5DqbAQAO9PFwZFr4fu/LWYqaakd +UCWVbPA8Gc+whIa5FbH4lBIaoZiUb2RIPQ6OYvu5sFg236MGe8vH9T1MMIGTuZOtKhb +qlAarvTSYpJv+znkX/t+VlCJrahvBKKALDfutZnWiWHFTxchMjBjhoiO+QtowuxYqtO N6m4GsVP0RL3xoK+U1ICeqiZ38BDoTJcl0nQbzXjZK5r1e2TuSny/io9/RVNXKjNk+ev XMtaNxOiCJ9p3zxhmiO0LVcl084TE8rx8T+d0bx3dfOzdf40o/iebmHFpqqyW/JWTD+t tjcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=m4Bm2CqQ897i8Jfzzd/zqgAzZLse8dPQRhyflO/OITM=; b=ZOmwekZD7LRaEq9idg0rxpWmkaCOlXzeOkHMFGVd6FgDb5/XmiqysKMSbBRny5wCK3 J51IvaOZPPAgIyYP/OVdpJF7oIu/Of4hSNvjcco9S99VI5Jqz2WVwxPvfhB6zhJ40g2+ Uwb+EDfJ7OttNjyDzzUoC0p8lsnDyVPHNahoJcw/af8AE7wQjNrC04d4jrg7ZJD72sQJ gHe+L2ba2DcIy5bxtPrOu2KNmTCmeY5+sK03ak3uNg7t47gNNt0mRn8cRGYwdZwBp7u1 M3EInL5Ys8es8/CePE860702SDgRz3XMw6Y1iN0QGHsX5gycb7cFgEK/IIlGU481I0KH rmOw==
X-Gm-Message-State: APjAAAWAKL2EgMZVj7gaMwoPh2Fvasp1mJe+hEUnkZreAjFqyxyq6kWV GbweFz3/wSJz16ZSAgAM/PW0ogpi
X-Google-Smtp-Source: APXvYqxYOijNnxzfz3XQ0Q4O810lGwKwxq5lupaPi7rIKJtXaj6mRP5vOP7+QbgpsuY/zXQDiZhpXw==
X-Received: by 2002:a17:902:ba8b:: with SMTP id k11mr60649841pls.40.1555100917864; Fri, 12 Apr 2019 13:28:37 -0700 (PDT)
Received: from [192.168.178.30] ([118.148.72.205]) by smtp.gmail.com with ESMTPSA id c3sm58886999pfo.2.2019.04.12.13.28.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Apr 2019 13:28:36 -0700 (PDT)
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>, Nabil Benamar <benamar73@gmail.com>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: "ietf@ietf.org" <ietf@ietf.org>, "its@ietf.org" <its@ietf.org>, "int-dir@ietf.org" <int-dir@ietf.org>, Nabil Benamar <n.benamar@est.umi.ac.ma>, "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org" <draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org>
References: <155169869045.5118.3508360720339540639@ietfa.amsl.com> <a8aad636-069c-4451-dbf1-72c1db2204ef@gmail.com> <CAD8vqFfx_FVi5NobrR1p6xEKjkSNa1_ZejgrEs3JPDHJQoxD7A@mail.gmail.com> <MN2PR11MB356570FDBC5798F155DDEE25D82C0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMugd_Xce5cWLtVB4DbR1ZEaFbdfiRpXre9oq61ukRC+n+3cZw@mail.gmail.com> <D8D5F0B7.2F2BB8%sgundave@cisco.com> <D8D5F510.2F2BC8%sgundave@cisco.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <3e716b4b-8236-0488-309c-7cd3a54db7b5@gmail.com>
Date: Sat, 13 Apr 2019 08:28:33 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <D8D5F510.2F2BC8%sgundave@cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/62jRkpNeJif612ycjEhZ5cmdVrg>
Subject: Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2019 20:28:46 -0000

On 13-Apr-19 02:59, Sri Gundavelli (sgundave) wrote:
> If you go back and check 2017 archives, I did raise many of these issues.  But, we clearly decided to limit the scope excluding address configuration, DAD, ND aspect, link models. When there is such a scope statement, it should clearly move these comments to the draft that defines how ND works for 802.11-OCB links.

This is of course possible. In general the IETF hasn't done that, but has
followed the lead set by RFC 2464 with the complete specification of
IPv6-over-foo in one document.

However, I don't believe that publishing an RFC about the frame format
without *simultaneously* publishing an RFC about ND etc would be a good
idea. That would leave developers absolutely unable to write useful
code, and might easily lead to incompatible implementations. Since
we'd presumably like Fords to be able to communicate with Peugeots,
that seems like a bad idea.

Regards
   Brian

> https://mailarchive.ietf.org/arch/msg/its/9NvUfRigGd4Klu0Q2Ee-63ziATw
> 
> https://mailarchive.ietf.org/arch/msg/its/VcrwNSvNJVIZNcRLNjDY0iSw3CA
> 
> Sri
> 
> 
> 
> 
> From: its <its-bounces@ietf.org <mailto:its-bounces@ietf.org>> on behalf of Sri Gundavelli <sgundave@cisco.com <mailto:sgundave@cisco.com>>
> Date: Friday, April 12, 2019 at 7:38 AM
> To: Nabil Benamar <benamar73@gmail.com <mailto:benamar73@gmail.com>>, "Pascal Thubert (pthubert)" <pthubert@cisco.com <mailto:pthubert@cisco.com>>
> Cc: "ietf@ietf.org <mailto:ietf@ietf.org>" <ietf@ietf.org <mailto:ietf@ietf.org>>, "its@ietf.org <mailto:its@ietf.org>" <its@ietf.org <mailto:its@ietf.org>>, "int-dir@ietf.org <mailto:int-dir@ietf.org>" <int-dir@ietf.org <mailto:int-dir@ietf.org>>, Nabil Benamar <n.benamar@est.umi.ac.ma <mailto:n.benamar@est.umi.ac.ma>>, "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org <mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org>" <draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org <mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org>>, Alexandre Petrescu <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>
> Subject: Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34
> 
> I am not following these discussions.  From my point of view, many of the discussions are totally out of scope for this document.
> 
> Some one needs to moderate these discussions. 
> 
> Sri
> 
> 
> 
> From: its <its-bounces@ietf.org <mailto:its-bounces@ietf.org>> on behalf of Nabil Benamar <benamar73@gmail.com <mailto:benamar73@gmail.com>>
> Date: Friday, April 12, 2019 at 7:34 AM
> To: "Pascal Thubert (pthubert)" <pthubert@cisco.com <mailto:pthubert@cisco.com>>
> Cc: "ietf@ietf.org <mailto:ietf@ietf.org>" <ietf@ietf.org <mailto:ietf@ietf.org>>, "its@ietf.org <mailto:its@ietf.org>" <its@ietf.org <mailto:its@ietf.org>>, "int-dir@ietf.org <mailto:int-dir@ietf.org>" <int-dir@ietf.org <mailto:int-dir@ietf.org>>, Nabil Benamar <n.benamar@est.umi.ac.ma <mailto:n.benamar@est.umi.ac.ma>>, "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org <mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org>" <draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org <mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org>>, Alexandre Petrescu <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>
> Subject: Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34
> 
> Hello Pascal,
> 
> I seconded Akex and would like to suggest you to add the missing text in the draft. 
> 
> Best regards
> Nabil
> 
>    
> 
> On Mon, Apr 8, 2019, 14:01 Pascal Thubert (pthubert) <pthubert@cisco.com <mailto:pthubert@cisco.com>> wrote:
> 
>     Hello Nabil.____
> 
>     __ __
> 
>     You will get a number of IESG reviews as part of the submission process, one per area. This is just a beginning…____
> 
>     __ __
> 
>     Cheers,____
> 
>     __ __
> 
>     Pascal____
> 
>     __ __
> 
>     *From:* NABIL BENAMAR <n.benamar@est.umi.ac.ma <mailto:n.benamar@est.umi.ac.ma>>
>     *Sent:* lundi 8 avril 2019 17:53
>     *To:* Alexandre Petrescu <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>
>     *Cc:* Pascal Thubert (pthubert) <pthubert@cisco.com <mailto:pthubert@cisco.com>>; int-dir@ietf.org <mailto:int-dir@ietf.org>; ietf@ietf.org <mailto:ietf@ietf.org>; its@ietf.org <mailto:its@ietf.org>; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org <mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf...org>
>     *Subject:* Re: Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34____
> 
>     __ __
> 
>     Yes definitely Alex....____
> 
>     __ __
> 
>     There have been many reviews until now. This should be a late or final review.____
> 
>     __ __
> 
>     On Mon, Apr 8, 2019, 10:01 Alexandre Petrescu <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> wrote:____
> 
>         As a note: please improve the title of this.____
> 
>         It is not an early review.____
> 
>         It is a late review.____
> 
>         There have been several reviews of this document until here, and two shepherd reviews.____
> 
>         Alex____
> 
>         Le 04/03/2019 à 12:24, Pascal Thubert a écrit :____
> 
>             Reviewer: Pascal Thubert____
> 
>             Review result: Not Ready____
> 
>             __ __
> 
>             Reviewer: Pascal Thubert____
> 
>             Review result: Not ready. Need to clarify IEEE relationship, IOW which SDO____
> 
>             defines the use of L2 fields, what this spec enforces vs. recognizes as being____
> 
>             used that way based on IEEE work. The use of IPv6 ND requires a lot more____
> 
>             thoughts, recommendation to use 6LoWPAN ND. The definition of a subnet is____
> 
>             unclear. It seems that RSUs would have prefixes but that is not discussed.____
> 
>             __ __
> 
>             I am an assigned INT and IOT directorates reviewer for <____
> 
>             draft-ietf-ipwave-ipv6-over-80211ocb-34 >. These comments were written____
> 
>             primarily for the benefit of the Internet Area Directors. Document editors and____
> 
>             shepherd(s) should treat these comments just like they would treat comments____
> 
>             from any other IETF contributors and resolve them along with any other Last____
> 
>             Call comments that have been received. For more details on the INT Directorate,____
> 
>             see https://datatracker.ietf.org/group/intdir/about/____
> 
>             __ __
> 
>             Majors issues____
> 
>             -----------------____
> 
>             __ __
> 
>             “____
> 
>             __ __
> 
>             o  Exceptions due to different operation of IPv6 network layer on____
> 
>                   802.11 than on Ethernet.____
> 
>             __ __
> 
>             “____
> 
>             Is this doc scoped to OCB or 802.11 in general? Is there an expectation that an____
> 
>             implementer of IPv6 over Wi-Fi refers to this doc? Spelled as above, it seems____
> 
>             that you are defining the LLC. Figure 1 shows the proposed adaptation layer as____
> 
>             IEEE LLC work. Who defines those fields, IETF or IEEE, or mixed? Who defines____
> 
>             their use? If this spec defines a new LLC header (vs. how to use an IEEE field)____
> 
>              then it should be very clear, and the newly defined fields should be isolated____
> 
>             from IEEE fields.____
> 
>             __ __
> 
>             "____
> 
>                The IPv6 packet transmitted on 802.11-OCB MUST be immediately____
> 
>                preceded by a Logical Link Control (LLC) header and an 802.11 header.____
> 
>             __ __
> 
>             "____
> 
>             Is there anything new or specific to OCB vs. classical 802.11 operations?____
> 
>             If/when this is echoing the IEEE specs then this text should not use uppercase____
> 
>             but say something like: 'Per IEEE Std 802.11, the IPv6 packet transmitted on____
> 
>             802.11-OCB is immediately  preceded by a Logical Link Control (LLC) header and____
> 
>             an 802.11 header ...'____
> 
>             __ __
> 
>             different things? Why define both?____
> 
>             __ __
> 
>             "   An 'adaptation' layer is inserted between a MAC layer and the____
> 
>                Networking layer.  This is used to transform some parameters between____
> 
>                their form expected by the IP stack and the form provided by the MAC____
> 
>                layer.____
> 
>             "____
> 
>             Is this different from what an AP does when it bridges Wi-Fi to Ethernet? Is____
> 
>             this IETF business?____
> 
>             __ __
> 
>             "____
> 
>                The Receiver and Transmitter Address fields in the 802.11 header MUST____
> 
>                contain the same values as the Destination and the Source Address____
> 
>                fields in the Ethernet II Header, respectively.____
> 
>             "____
> 
>             Same,  this is IEEE game isn't it?____
> 
>             __ __
> 
>             "____
> 
>             __ __
> 
>             Solutions for these problems SHOULD____
> 
>                consider the OCB mode of operation.____
> 
>             "____
> 
>             This is not specific enough to be actionable. I suggest to remove this sentence.____
> 
>             It would be of interest for the people defining those solutions to understand____
> 
>             the specific needs of OCB vs. Wi Fi, but I do not see text about that.____
> 
>             __ __
> 
>             "____
> 
>             __ __
> 
>             The method of forming IIDs____
> 
>                described in section 4 of [RFC2464] MAY be used during transition____
> 
>                time.____
> 
>             "____
> 
>             Contradicts section 4.3 that says____
> 
>             "____
> 
>             Among these types of____
> 
>                addresses only the IPv6 link-local addresses MAY be formed using an____
> 
>                EUI-64 identifier.____
> 
>             "____
> 
>             __ __
> 
>             "____
> 
>             __ __
> 
>             This____
> 
>                subnet MUST use at least the link-local prefix fe80::/10 and the____
> 
>                interfaces MUST be assigned IPv6 addresses of type link-local.____
> 
>             "____
> 
>             If this is conforming IPv6 then the MUST is not needed.____
> 
>             __ __
> 
>             "____
> 
>                A subnet is formed by the external 802.11-OCB interfaces of vehicles____
> 
>                that are in close range (not by their in-vehicle interfaces).____
> 
>             "____
> 
>             Is the definition transitive? Do we really get a subnet?____
> 
>              A is close to  B who is close to C .... to Z, makes Paris one subnet! Are you____
> 
>              talking about a link, rather?____
> 
>             __ __
> 
>             "____
> 
>                The Neighbor Discovery protocol (ND) [RFC4861] MUST be used over____
> 
>                802.11-OCB links.____
> 
>             "____
> 
>             __ __
> 
>             IPv6 ND is not suited for a non-broadcast network. How does DAD work?____
> 
>             Maybe you could consider RFC 6775 / RFC 8505 instead.____
> 
>             __ __
> 
>             "____
> 
>             In the moment the MAC address is changed____
> 
>                on an 802.11-OCB interface all the Interface Identifiers of IPv6____
> 
>                addresses assigned to that interface MUST change.____
> 
>             "____
> 
>             Why is that? This is unexpected, and hopefully wrong.____
> 
>             __ __
> 
>             Minor issues____
> 
>             ---------------____
> 
>             __ __
> 
>             "   OCB (outside the context of a basic service set - BSS): A mode of____
> 
>                operation in which a STA is not a member of a BSS and does not____
> 
>                utilize IEEE Std 802.11 authentication, association, or data____
> 
>                confidentiality.____
> 
>             __ __
> 
>                802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB____
> 
>                attribute dot11OCBActivited is true.  Note: compliance with standards____
> 
>                and regulations set in different countries when using the 5.9GHz____
> 
>                frequency band is required.____
> 
>             "____
> 
>             __ __
> 
>             Are these 2 different things?____
> 
>             __ __
> 
>             "____
> 
>             Among these types of____
> 
>              addresses only the IPv6 link-local addresses MAY be formed using an____
> 
>               EUI-64 identifier.____
> 
>             "____
> 
>             This text should not be in a LL specific section since it deals with the other____
> 
>             addresses. Maybe rename the section to "addressing" or something?____
> 
>             __ __
> 
>             "____
> 
>                For privacy, the link-local address MAY be formed according to the____
> 
>                mechanisms described in Section 5.2.____
> 
>             "____
> 
>             The MAY is not helpful. I suggest to remove the sentence that does not bring____
> 
>             value vs. 5.2____
> 
>             __ __
> 
>             Could you make sections 4.3 and 4.5 contiguous?____
> 
>             __ __
> 
>             "____
> 
>             If semantically____
> 
>                opaque Interface Identifiers are needed, a potential method for____
> 
>                generating semantically opaque Interface Identifiers with IPv6____
> 
>                Stateless Address Autoconfiguration is given in [RFC7217]....____
> 
>             __ __
> 
>                Semantically opaque Interface Identifiers, instead of meaningful____
> 
>                Interface Identifiers derived from a valid and meaningful MAC address____
> 
>                ([RFC2464], section 4), MAY be needed in order to avoid certain____
> 
>                privacy risks.____
> 
>             __ __
> 
>             ...____
> 
>             __ __
> 
>                In order to avoid these risks, opaque Interface Identifiers MAY be____
> 
>                formed according to rules described in [RFC7217].  These opaque____
> 
>                Interface Identifiers are formed starting from identifiers different____
> 
>                than the MAC addresses, and from cryptographically strong material.____
> 
>                Thus, privacy sensitive information is absent from Interface IDs, and____
> 
>                it is impossible to calculate the initial value from which the____
> 
>                Interface ID was calculated.____
> 
>             __ __
> 
>             "____
> 
>             Duplicate and mis ordered text, isn't it?____
> 
>             __ __
> 
>             " For this reason, an attacker may realize many____
> 
>                attacks on privacy.____
> 
>             "____
> 
>             Do we attack privacy? Maybe say that privacy is a real concern, and maybe move____
> 
>             that text to security section?____
> 
>             __ __
> 
>             "____
> 
>                The way Interface Identifiers are used MAY involve risks to privacy,____
> 
>                as described in Section 5.1.____
> 
>             "____
> 
>             Also duplicate____
> 
>             __ __
> 
>             Nits____
> 
>             ------____
> 
>             __ __
> 
>             "____
> 
>                IP packets MUST be transmitted over 802.11-OCB media as QoS Data____
> 
>                frames whose format is specified in IEEE Std 802.11.____
> 
>             "____
> 
>             Please add link to the reference____
> 
>             __ __
> 
>             " the 802.11 hidden node"____
> 
>             Do not use 802.11 standalone (multiple occurrences).____
> 
>             => "the IEEE Std. 802.11 [ ref ] hidden node", or just "the hidden terminal".____
> 
>             __ __
> 
>             BCP 14 text:____
> 
>             __ __
> 
>             Suggest to use this text:____
> 
>             “____
> 
>                The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",____
> 
>                "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and____
> 
>                "OPTIONAL" in this document are to be interpreted as described in____
> 
>                https://tools.ietf.org/html/bcp14 https://tools.ietf.org/html/bcp14____
> 
>                [https://tools.ietf.org/html/rfc2119][RFC8174] when, and only when, they____
> 
>                appear in all capitals, as shown here.____
> 
>             __ __
> 
>             “____
> 
>             __ __
> 
>             All the best____
> 
>             __ __
> 
>             Pascal____
> 
>             __ __
> 
>             __ __
> 
>             __ __
> 
>     _______________________________________________
>     its mailing list
>     its@ietf.org <mailto:its@ietf.org>
>     https://www.ietf.org/mailman/listinfo/its
>