Re: [arch-d] ETSI Liaison Work

"BRUNGARD, DEBORAH A" <> Tue, 30 June 2020 16:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E99CC3A0B33; Tue, 30 Jun 2020 09:24:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FiNju-BQ-t8b; Tue, 30 Jun 2020 09:24:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 93A923A0B29; Tue, 30 Jun 2020 09:24:09 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 05UGC4Bk040234; Tue, 30 Jun 2020 12:23:56 -0400
Received: from ( []) by with ESMTP id 32056uwhx9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jun 2020 12:23:56 -0400
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id 05UGMsxX017897; Tue, 30 Jun 2020 12:22:54 -0400
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id 05UGMmwK017776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Jun 2020 12:22:48 -0400
Received: from ( []) by (Service) with ESMTP id 412A6400B577; Tue, 30 Jun 2020 16:22:48 +0000 (GMT)
Received: from (unknown []) by (Service) with ESMTPS id 258F7400B576; Tue, 30 Jun 2020 16:22:48 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 30 Jun 2020 12:22:47 -0400
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Tue, 30 Jun 2020 12:22:46 -0400
Received: from ([]) by ([]) with mapi id 15.01.1979.003; Tue, 30 Jun 2020 12:22:46 -0400
To: Lizhenbin <>, Rob Sayre <>
CC: "" <>, "IETF discussion list" <>
Thread-Topic: ETSI Liaison Work
Thread-Index: AQHWTRGcU0zThx82q0OKD9LjPKKCwKjvbPiAgAHfYkA=
Date: Tue, 30 Jun 2020 16:22:46 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4418f515538649d1b3c264b7ff19b471attcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-06-30_06:2020-06-30, 2020-06-30 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 suspectscore=0 mlxscore=0 adultscore=0 cotscore=-2147483648 phishscore=0 spamscore=0 impostorscore=0 bulkscore=0 clxscore=1011 malwarescore=0 priorityscore=1501 lowpriorityscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006300115
Archived-At: <>
Subject: Re: [arch-d] ETSI Liaison Work
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Jun 2020 16:24:12 -0000

Hi Rob-
My perspective below-

From: Architecture-discuss <> On Behalf Of Lizhenbin
Sent: Monday, June 29, 2020 2:54 AM
To: Rob Sayre <>
Cc:; IETF discussion list <>
Subject: [arch-d] 答复: ETSI Liaison Work

Hi Rob,

Thank very much for paying attention to the work. Please refer to my reply inline identified by '[Robin]'.

Best Regards,

Zhenbin (Robin)

发件人: ietf [] 代表 Rob Sayre []
发送时间: 2020年6月28日 14:00
收件人: IETF discussion list;<>
主题: ETSI Liaison Work

I had some questions about why the IETF might establish a formal liaison relationship with ETSI, and why that might appear in IAB minutes, rather than in the IETF/IESG. The document in question is here:<>

"3. ETSI Liaison Work
Zhenbin Li suggested that the IETF might want to consider trying to establish a formal liaison with ETSI, noting a concern that there might be overlap between work in the IETF TEAS WG and the ETSI Industry Specification Group on Zero touch network and Service Management (ZSM).


Zhenbin Li agreed to follow up with Deborah Brungard and the Routing Area Directors about whether there is need for a formal liaison relationship with ETSI, and report back to the IAB."
[Robin] Thanks Paul to propose the following link which explains why IAB discussed the work.<>

In addition, since there is no formal liaison between IETF and IAB and I work for the Liaison Oversight Program, I took the work to investigate the requirements for the liaison with IETF.<>

ETSI had been unfamiliar to me, but I recently reviewed an ETSI application for a TLS code point assignment:<>

I was surprised that the IETF would entertain a 99-page PDF that no individual signed their name to, but I do agree that code point assignment is not meant to be a gatekeeping mechanism.

I did more research into ETSI after that, and this article turned up:<>
[Robin] In fact the discussion for the liaison work is triggered by Daniele Ceccarelli (CCAMP WG Chair) this time. He asked if IETF needs to set up the liaison because of he had seen requests coming from NFV, ZSM and the new working group on security (don't remember the name) in ETSI which has a very high overlap with what we're doing in TEAS, CCAMP, OPSAWG. After discussion in the IAB meeting, it is suggested to discuss with Deborah and the routing ADs about the need. That is the reason why the RTG area is mentioned specially.
In the IAB meeting held on June 17, the need was discussed according to the feedback from Daniele Ceccarelli, Gonzalo Camarillo and Deborah Brungard and my collected information on the organization of ETSI. It seems that there is no need from Routing for a formal liaison relationship with ETSI at the working level. And the IAB discussed that there seems not much need to set up the higher level liaison with ETSI temporarily.
I think your proposed reference is very helpful to understand more about the possible liaison work between ETSI and IETF. I will go on to collect these feedback and propose them for IAB to evaluate. More suggestions on the work are welcome.

For the routing area, TEAS had a request from ZSM on the status of some of TEAS documents. There have been no others. ETSI NFV, ETSI ZSM, TEAS are looking at similar applications – buzzwords of the industry – SDN, NFV, network slicing, zero touch. As usual, different SDOs choose different paths on solution work e.g. ETSI NFV is concentrated on TOSCA. There are many SDOs overlapping in this space e.g. ONF is another one. What is different from previous needed liaison activity when we did need a liaison manager at the working group level, for example, ITU-T SG15’s work on GMPLS and TMPLS, these groups are not modifying IETF routing area protocols. They may be choosing different ways to model e.g. ETSI NFV MANO model for APIs. Similar to IETF’s approach to other SDOs, it really is not for IETF to say “choose our model/acronyms/solution” when not involving our protocols. Companies may not want the different paths on solution work, but as RFC4929 notes, it is the expectation for the companies participating in these SDOs to contribute to that SDO, not the IETF liaison process to mandate (RFC4052).

There are two aspects to the liaison process – the exchange of information on work, which can be done without a designated formal liaison manager, and the designation of a formal liaison manager:

Considering the routing area work at this time, I didn’t see that conditions warranted to recommend to the IAB that we needed to have formal liaison managers appointed to oversee ETSI ZSM and ETSI NFV work. A formal liaison manager at the level of overall ETSI work, e.g. our 3GPP formal manager, Gonzalo, may be of interest but that would be for the IAB working with ETSI to determine if mutual interest as usually the partnering organization also chooses a contact from their side.
I would like to hear more from Zhenbin Li, Deborah Brungard, and the Routing Area Directors about this proposal.