Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links

"Y. Richard Yang" <yry@cs.yale.edu> Sun, 09 July 2023 21:09 UTC

Return-Path: <yang.r.yang@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0161C151085 for <alto@ietfa.amsl.com>; Sun, 9 Jul 2023 14:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.693
X-Spam-Level:
X-Spam-Status: No, score=0.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.096, FREEMAIL_FROM=0.001, GOOGLE_DOC_SUSP=1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcA9BahtQMPy for <alto@ietfa.amsl.com>; Sun, 9 Jul 2023 14:09:37 -0700 (PDT)
Received: from mail-ua1-f48.google.com (mail-ua1-f48.google.com [209.85.222.48]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02109C14F74E for <alto@ietf.org>; Sun, 9 Jul 2023 14:09:36 -0700 (PDT)
Received: by mail-ua1-f48.google.com with SMTP id a1e0cc1a2514c-794d1714617so1339269241.0 for <alto@ietf.org>; Sun, 09 Jul 2023 14:09:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688936976; x=1691528976; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XUhZ28RvxnyaUJt2vNKY1Pjz/7bhmAylABN0702/nJs=; b=lRLfHJcNfbtagiqudoAZANOVFM3/St+Bkw/N18zzNDJtrW9fwPDPDFWhmH7f5k0Dod XL2OrPyy/5lxo4WfMQu2w+tvnOk0GRHwdo4aFAD5gr3NPY+dPTZsYHl1rEsve4a5F7L4 FyUCSwWAbGm3oZT87tNIYrMW+dfMSZSKhsPCfs4dus08Pi39Td7vwjnAzy/rvHqMzcsG vrsJiUY5Qyfygl/viOGJ3GvTEKjhHzI/qFDKKeyaKtuw1B2GA2oFEeemC80QM4/TC4KQ KhoTEYDHNJnCwO0caJRMLL0VgKY1UM2JGGVCciB9gpmO0m28S+TcLM78p5muku5Y8tbi FnyQ==
X-Gm-Message-State: ABy/qLYLidyGhfJBWPOBNdpYypI3MRF3P3RYOec++GYhGS7h9hIsJpRw jU75jIHc8VuLDZ61rs4qHbhecal17QoCfbDZqfs=
X-Google-Smtp-Source: APBJJlHFd7xaQX7Nny+4Iu0PpX6hksyZ5dnJrxppSY4rirNIkf1TgrRcO1cH8SqeyDoXrhcrHEOYd9XmOkrHLNMRSkM=
X-Received: by 2002:a67:ed1a:0:b0:444:c7fa:1aad with SMTP id l26-20020a67ed1a000000b00444c7fa1aadmr4591403vsp.17.1688936975533; Sun, 09 Jul 2023 14:09:35 -0700 (PDT)
MIME-Version: 1.0
References: <f0ac99965c004d2b82f373b9d417fc49@huawei.com> <DB9PR06MB79153104D53817C1952C38F59E33A@DB9PR06MB7915.eurprd06.prod.outlook.com>
In-Reply-To: <DB9PR06MB79153104D53817C1952C38F59E33A@DB9PR06MB7915.eurprd06.prod.outlook.com>
From: "Y. Richard Yang" <yry@cs.yale.edu>
Date: Sun, 09 Jul 2023 23:09:23 +0200
Message-ID: <CANUuoLpNYGmQ+4sBOb7Av_=J=Y_ozH4zRJg__1k6iQVM562auQ@mail.gmail.com>
To: LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>
Cc: Danny Lachos <dlachos@benocs.com>, IETF ALTO <alto@ietf.org>, Qin Wu <bill.wu@huawei.com>
Content-Type: multipart/alternative; boundary="000000000000798b330600144823"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/thXjdazcW2qWqX_VHljd-Y9qdr8>
Subject: Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Jul 2023 21:09:42 -0000

Hi Danny, Luis, Qin,

Very interesting discussions on BGP communities and ALTO network maps.

To better understand the discussion, can we say that there are two settings
or models:
1. ALTO on BGP (Bottom Up)
Given BGP model (the prefixes and their associated attributes announced by
BGP communities). We do not modify this BGP model (i.e., we do not change
the prefixes announced, we do not add/remove communities announced), and we
derive ALTO models on top. For example, assume that there are multiple BGP
routers, and then ALTO can combine the views of these routers to produce a
single view. I feel that this is the essence of Danny’s proposal.

2. ALTO driven BGP (Top Down)
There is info that ALTO need, for example, to derive the cost metric for a
given cost map or ECS. The info carried by BGP is driven (at least
modified) by ALTO.

It looks that the question by Danny uses more on 1, and the example by Luis
will use more on 2. They sure can be combined. Make sense?

Richard

On Sun, Jul 9, 2023 at 11:39 AM LUIS MIGUEL CONTRERAS MURILLO <
luismiguel.contrerasmurillo@telefonica.com> wrote:

> Hi Qin, Danny,
>
>
>
> Thanks for your questions and apologies for the late response.
>
>
>
> Certainly, the way in which BGP Communities can be handled is a matter of
> development with ideas / insights from the working group.
>
>
>
> As stated in the version -01 to be submitted (available here
> https://github.com/luismcontreras/alto-bgp-communities), I do foresee the
> following way of handling BGP Communities:
>
>
>
>    - In situations where a BGP Community and an ALTO PID scope the same
>    grouping of prefixes, leveraging BGP Communities simplifies network
>    operations by using an existing identifier for the purpose of retrieving
>    ALTO information.
>
>
>
>    - In situations where the purpose is to retrieve ALTO information
>    applicable to a superset of PIDs, a BGP Community can be defined in order
>    to group the prefixes of all those PIDs.
>
>
>
>    - In situations where the purpose is to retrieve ALTO information
>    applicable to a subset of prefixes across multiple PIDs, a BGP Community
>    can be defined in order to group the subset of prefixes of all the PIDs.
>
>
>
>
> In summary, what I would expect is to have new network maps working with
> the concept of BGP Community as object. The prefixes associated with each
> BGP Community will be defined at BGP level. I’m considering for this
> specific operator defined communities, for instance those that have a
> geographical meaning (e.g., prefixes in Region-1 vs Region-2, commonly
> defined to being associated to peering point 1 vs 2).
>
>
>
> Hope this clarifies the questions. Anyway, more discussions are needed in
> the WG for well defining how to work with Communities, as well as to
> identify limitations, if any.
>
>
>
> Best regards
>
>
>
> Luis
>
>
>
> *De:* Qin Wu <bill.wu@huawei.com>
> *Enviado el:* jueves, 6 de julio de 2023 4:18
> *Para:* Danny Lachos <dlachos@benocs.com>; LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmurillo@telefonica.com>; Y. Richard Yang <
> yry@cs.yale.edu>; IETF ALTO <alto@ietf.org>
> *Asunto:* RE: [alto] Topic B - maintenance of ALTO protocol // RE: June
> 20, 2023 meeting minutes and discussion working links
>
>
>
> Hi, Danny:
>
> BGP community can be seen as a tag attached to the BGP routes exchanged
> between two BGP peers.
>
> It is interesting to see ALTO network map can be generated based on
> BGP-communities, two questions I want to ask here:
>
>    1. We have many common BGP communities, e.g., local AS community,
>    route target community, route origin community, do you think all these
>    communities can be used to generate network map
>    2. For network map, we usually map IP addresses to PIDs, e.g.,
>
>
>
>        "network-map" : {
>
>          "PID0" : { "ipv6" : [ "::/0" ] },
>
>          "PID1" : { "ipv4" : [ "0.0.0.0/0" ] },
>
>          "PID2" : { "ipv4" : [ "192.0.2.0/24", "198.51.100.0/24" ] },
>
>          "PID3" : { "ipv4" : [ "192.0.2.0/25", "192.0.2.128/25" ] }
>
>        }
>
>       So when we introduce communities, do you think such mapping should
> be modified, replaced? What format will looks like?
>
>       e.g., should establish the mapping between PIDs and community or
> should we define the network map other than ipv4/ipv6 network map?
>
>
>
> -Qin
>
> *发件人**:* alto [mailto:alto-bounces@ietf.org <alto-bounces@ietf.org>] *代表 *Danny
> Lachos
> *发送时间**:* 2023年7月5日 15:59
> *收件人**:* LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmurillo@telefonica.com>; Y. Richard Yang <
> yry@cs.yale.edu>; IETF ALTO <alto@ietf.org>
> *主题**:* Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20,
> 2023 meeting minutes and discussion working links
>
>
>
> Hi Luis,
> Thanks for starting this thread
>
> See a quick comment below:
>
> 1/ extension of ALTO to consider operational simplicity. Here fits the
> proposal of introducing BGP communities in ALTO. The rationale is that
> operators use BGP communities quite often as mechanism for applying
> policies and determining certain behaviors on the IP addresses grouped in
> the form of communities. This seems quite useful as well at the time of
> exposing associated information (metrics, topology, etc) as enabled by
> ALTO. An initial draft can be found here:
> https://github.com/luismcontreras/alto-bgp-communities
>
> The plan is to generate version -01 for IETF 117.
>
> Regarding the use of BGP information (including BGP communities), I was
> wondering how to process this data. Should it be considered an aggregation
> process?
> This is because tons of data will eventually be received, and in this
> case, the BGP routing information could be aggregated into subnet prefixes
> grouped by their attributes (Communities, BGP nextHop, etc.).
> This process will massively compress the BGP data and then this
> re-structured and aggregated data could be used to generate, for instance,
> ALTO network maps based on BGP-Communities.
>
> Make sense?
>
> On 26.06.23 23:13, LUIS MIGUEL CONTRERAS MURILLO wrote:
>
> Hi all,
>
>
>
> Related to Topic B on maintenance of ALTO, as a way of summary of what has
> been discussed during the last weeks, we could have two major sub-topics:
>
>
>
> 1/ extension of ALTO to consider operational simplicity. Here fits the
> proposal of introducing BGP communities in ALTO. The rationale is that
> operators use BGP communities quite often as mechanism for applying
> policies and determining certain behaviors on the IP addresses grouped in
> the form of communities. This seems quite useful as well at the time of
> exposing associated information (metrics, topology, etc) as enabled by
> ALTO. An initial draft can be found here:
> https://github.com/luismcontreras/alto-bgp-communities
>
> The plan is to generate version -01 for IETF 117.
>
>
>
> 2/ security aspects of ALTO. This has been discussed in both one of the
> interim meetings (see
> https://datatracker.ietf.org/meeting/interim-2023-alto-05/materials/slides-interim-2023-alto-05-sessa-security-aspects-regarding-alto-luis-00)
> and one ad-hoc discussion meeting (
> https://mailarchive.ietf.org/arch/msg/alto/HnhO5H5xy4hBGtfm3JI7-K9mq3Y/).
> The rationale for this activity is to improve the security around the
> deployment and operation of ALTO in production networks. As commented
> during the interim, there are a number of security issues documented so
> far, like:
>
> 1.       A high-level discussion of security issues in the ALTO problem
> statement [RFC5693]
>
> 2.       Unwanted information disclosure risks, as well as specific
> security-related requirements in the ALTO requirements document [RFC6708].
>
> 3.       Issues related ALTO server discovery in [RFC7286]
>
> 4.       Identified cases for ALTO deployments in [RFC7971]
>
> 5.       Security considerations in the remaining RFCs
>
> However, new security concerns emerge from deployments, such as:
>
> 1.       Obfuscation of PIDs, and the handling of them in scenarios with
> multiple ALTO clients
>
> 2.       Mechanisms for isolation of the ALTO server from direct client
> interaction
>
> 3.       Secure retrieval of information from external components (e.g.,
> probes, etc)
>
> 4.       etc
>
> A potential first step could be to document these new security
> considerations and then concentrate on those not solved representing
> relevant threats in ALTO operation.
>
>
>
> There could be other relevant topics related to the maintenance of ALTO
> part from the two commented above.
>
>
>
> Any further ideas on this respect?
>
>
>
> Of course for those interested on the topics above, please comment.
>
>
>
> Thanks in advance
>
>
>
> Best regards
>
>
>
> Luis
>
>
>
> *De:* alto <alto-bounces@ietf.org> <alto-bounces@ietf.org> *En nombre de *Y.
> Richard Yang
> *Enviado el:* miércoles, 21 de junio de 2023 1:47
> *Para:* IETF ALTO <alto@ietf.org> <alto@ietf.org>
> *Asunto:* [alto] June 20, 2023 meeting minutes and discussion working
> links
>
>
>
> Hi all,
>
>
>
> As suggested by Ayoub, Jordi and others during the weekly meeting today,
> starting from today, the note taker will not only update the meeting
> minutes page (
> https://github.com/ietf-wg-alto/wg-materials/blob/main/meetings-ietf-alto/ietf-alto-2023.md),
> but also provide a text summary and comments, if appropriate, on the
> meeting. So below are my quick comments and the full meeting minutes are
> below; the archive is at the link above.
>
>
>
> Regarding comments, the most important item that I, as a note taker, take
> away is the wonderful discussion about how to organize future work
> discussions. In particular, the participants divided the potential work
> into 4 areas, and created 4 github issues. We also created a common Google
> doc to allow systematic write up. The links to them are below.
>
>
>
> In particular, the four areas and their coordinators are:
>
> - A: Integration of data sources and their exposures; coordinator: Jordi,
> Luis and Kai
>
> - B: Maintenance of ALTO protocol; coordinator: Luis, Richard
>
> - C: Security and trust; coordinators: Ayoub, Junichi, Motoyoshi
>
> - D: New architectural extensions; coordinators: Roland and Sabine
>
>
> We sure can adjust the coordinators. So so, please let me know, and we can
> adjust the page. The plan is that the coordinators will closely with the
> chairs (Qin and Med) to make concrete progress. The coordinators will kick
> off the discussions.
>
>
>
> Richard as note taker on June 20, 2023
>
>
>
> ==== Meeting Minutes Text ====
>
> *IETF, ALTO Meeting: June 20, 2023*
>
> *Agenda:*
>
> 1.       Transport and OAM documents
>
> 1.       Transport:
> https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/issues
>
> 2.       OAM:
> https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues
>
> 3.       ALTO Future Work:
> https://mailarchive.ietf.org/arch/msg/alto/uIFD6Dhikfu4J4PYcpJTbsiXbnE/
> https://github.com/ietf-wg-alto/wg-materials/blob/main/FutureALTO/alto-direction-of-work.md
>
> 4.       Preps for IETF 117:
>
> 1.       Drafts and presentations that the ALTO group plans to work on
>
> 2.       Agenda
>
> 5.       New revision of Green Networking Metrics draft in opsawg:
> https://datatracker.ietf.org/doc/draft-cx-opsawg-green-metrics/
>
> *Minutes*
>
> *Note taker: Richard
>
> 1.  Charter documents: transport and OAM updates
>
> 1.       OAM: Jensen and Med had a discussion on the draft and submit the
> revision to IESG. The document is now waiting for AD review.
>
> 2.       Transport: Richard sent a note to Martin Thompson, to provide
> the justification on introducing server push using PUSH PROMISE. It
> includes two basic reasonings: lower load, and the feature is optional; Kai
> updated that Med sent two pull requests and sent the latest version for AD
> review, and wait for updates.
>
> 2.  Updates on future work on ALTO
>
> 1.  Overview: Jordi started with an update on the planning: Please follow
> the ongoing conversation on the WG mailing list initiated by Sabine,
> engaged by Jordi and Luis; the WG welcomes conversations by all; please
> socialize the ideas; leadership is important and please take ownership;
> this WG meets each week, and we do not know any other IETF WG that meets
> each week, but because we meet each week, we do not use the mailing list,
> which may appear to be inactive by those not attending the weekly meeting.
>
> 2.  Individual topics:
>
> 1.       Jordi summarized that from the mailing list, item 3 appears to
> be the most preferred; please do discussions, propose a charter item and
> then write documents; The goal is to go to 117 and should be prepared.
>
> 2.       Richard commented that one of his focus points will be on data
> sources, which can be more informational than standard. Luis advised that
> there can be two types of approaches: bottom-up (individuals propose
> ideas), and top-down (chairs/AD guidance).
>
> 3.       Luis suggests that we should take a look at chair-mentioned
> items such as BGP communities, and security; mid-term: such as data
> sources, please go to the mailing list.
>
> 3.  Work organization: Meeting notes work plan: Ayoub gave the suggestion
> that note taker shares the note to the mailing list, some kind of annotated
> meeting minutes. Roland clarified that the sharing notes can be double
> sent, or summary/highlights, or up to note taker. Organizing discussions:
> Luis/Jordi: email as record, GitHub tickets to organize; Jordi creates 4
> tickets, and puts links to doc.
>
> 4.  Issues, leads, and working documents:
>
> 1.  Topic A:
>
> 1.       GitHub issue: #48
> <https://github.com/ietf-wg-alto/wg-materials/issues/48>
>
> 2.       Topic coordinator: Jordi, Kai
>
> 2.  Topic B:
>
> 1.       GitHub: #49
> <https://github.com/ietf-wg-alto/wg-materials/issues/49>
>
> 2.       Topic coordinator: Roland, Sabine
>
> 3.  Topic C:
>
> 1.       GitHub: #50
> <https://github.com/ietf-wg-alto/wg-materials/issues/50>
>
> 2.       Topic coordinator: Ayoub, Junichi, Motoyoshi
>
> 4.  Topic D:
>
> 1.       GitHub: #51
> <https://github.com/ietf-wg-alto/wg-materials/issues/51>
>
> 2.       Coordinator: Luis, Jordi
>
> 5.  Discussion Google doc:
>
> 1.
> https://docs.google.com/document/d/1rpziU7NZEE8f84XkJSjMhEIHUA5G7rXkGB5c_7UFxUY/edit?usp=sharing
>
> 6.  Goals: Enabling conversations and concrete documents (compute, edge
> service, etc), need to focus; real good way to make progress is
> internet-draft (ID) as ground truth, from dynamic to stable, with focus on
> writing drafts for concrete results).
>
>
> ------------------------------
>
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is confidential and
> privileged information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
> ------------------------------
>
>
> Le informamos de que el responsable del tratamiento de sus datos es la
> entidad del Grupo Telefónica vinculada al remitente, con la finalidad de
> mantener el contacto profesional y gestionar la relación establecida con el
> destinatario o con la entidad a la que está vinculado. Puede contactar con
> el responsable del tratamiento y ejercitar sus derechos escribiendo a
> privacidad.web@telefonica.com. Puede consultar información adicional
> sobre el tratamiento de sus datos en nuestra Política de Privacidad
> <https://www.telefonica.com/es/telefonica-politica-de-privacidad-de-terceros/>
> .
>
> We inform you that the data controller is the Telefónica Group entity
> linked to the sender, for the purpose of maintaining professional contact
> and managing the relationship established with the recipient or with the
> entity to which it is linked. You may contact the data controller and
> exercise your rights by writing to privacidad.web@telefonica.com. You may
> consult additional information on the processing of your data in our Privacy
> Policy
> <https://www.telefonica.com/en/wp-content/uploads/sites/5/2022/12/Telefonica-Third-data-subjects-Privacy-Policy.pdf>
> .
>
> Informamos que o responsável pelo tratamento dos seus dados é a entidade
> do Grupo Telefónica vinculada ao remetente, a fim de manter o contato
> professional e administrar a relação estabelecida com o destinatário ou com
> a entidade à qual esteja vinculado. Você pode entrar em contato com o
> responsável do tratamento de dados e exercer os seus direitos escrevendo a
> privacidad.web@telefonica.com. Você pode consultar informação adicional
> sobre o tratamento do seus dados na nossa Política de Privacidade
> <https://www.telefonica.com/es/politica-de-privacidade-de-terceiros/>.
>
>
>
> _______________________________________________
>
> alto mailing list
>
> alto@ietf.org
>
> https://www.ietf.org/mailman/listinfo/alto
>
> --
>
> Danny Lachos | Senior Network Engineer
>
>
>
> BENOCS GmbH, Berlin
>
> +49 305 7700 0417
>
> dlachos@benocs.com
>
> www.benocs.com
>
>
>
> Visit us on LinkedIn: https://www.linkedin.com/company/benocs/
>
>
> ------------------------------
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is confidential and
> privileged information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
> ------------------------------
>
>
> Le informamos de que el responsable del tratamiento de sus datos es la
> entidad del Grupo Telefónica vinculada al remitente, con la finalidad de
> mantener el contacto profesional y gestionar la relación establecida con el
> destinatario o con la entidad a la que está vinculado. Puede contactar con
> el responsable del tratamiento y ejercitar sus derechos escribiendo a
> privacidad.web@telefonica.com. Puede consultar información adicional
> sobre el tratamiento de sus datos en nuestra Política de Privacidad
> <https://www.telefonica.com/es/telefonica-politica-de-privacidad-de-terceros/>
> .
>
> We inform you that the data controller is the Telefónica Group entity
> linked to the sender, for the purpose of maintaining professional contact
> and managing the relationship established with the recipient or with the
> entity to which it is linked. You may contact the data controller and
> exercise your rights by writing to privacidad.web@telefonica.com. You may
> consult additional information on the processing of your data in our Privacy
> Policy
> <https://www.telefonica.com/en/wp-content/uploads/sites/5/2022/12/Telefonica-Third-data-subjects-Privacy-Policy.pdf>
> .
>
> Informamos que o responsável pelo tratamento dos seus dados é a entidade
> do Grupo Telefónica vinculada ao remetente, a fim de manter o contato
> professional e administrar a relação estabelecida com o destinatário ou com
> a entidade à qual esteja vinculado. Você pode entrar em contato com o
> responsável do tratamento de dados e exercer os seus direitos escrevendo a
> privacidad.web@telefonica.com. Você pode consultar informação adicional
> sobre o tratamento do seus dados na nossa Política de Privacidade
> <https://www.telefonica.com/es/politica-de-privacidade-de-terceiros/>.
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/
> <https://www.ietf.org/mailman/listinfo/alto>
>
-- 
Richard