Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-message for "config false"

Jürgen Schönwälder <jschoenwaelder@constructor.university> Thu, 16 November 2023 10:29 UTC

Return-Path: <jschoenwaelder@constructor.university>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA9FC151545 for <netmod@ietfa.amsl.com>; Thu, 16 Nov 2023 02:29:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.607
X-Spam-Level:
X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 vDFJizVWSKui for <netmod@ietfa.amsl.com>; Thu, 16 Nov 2023 02:29:44 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5899DC15C282 for <netmod@ietf.org>; Thu, 16 Nov 2023 02:29:43 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 20A4644A6; Thu, 16 Nov 2023 11:29:40 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Dqybklqftm8k; Thu, 16 Nov 2023 11:29:39 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (not verified)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 16 Nov 2023 11:29:39 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD62220150; Thu, 16 Nov 2023 11:29:39 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id nJsz3LVV8pHO; Thu, 16 Nov 2023 11:29:38 +0100 (CET)
Received: from localhost (alice.jacobs.jacobs-university.de [10.50.244.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 919A520095; Thu, 16 Nov 2023 11:29:38 +0100 (CET)
Date: Thu, 16 Nov 2023 11:29:38 +0100
From: Jürgen Schönwälder <jschoenwaelder@constructor.university>
To: mohamed.boucadair@orange.com
Cc: Kent Watsen <kent@watsen.net>, "Jason Sterne (Nokia)" <jason.sterne@nokia.com>, "netmod@ietf.org" <netmod@ietf.org>, "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
Message-ID: <ZVXvEkKdNPOHAT2F@alice.eecs.jacobs-university.de>
Reply-To: Jürgen Schönwälder <jschoenwaelder@constructor.university>
Mail-Followup-To: mohamed.boucadair@orange.com, Kent Watsen <kent@watsen.net>, "Jason Sterne (Nokia)" <jason.sterne@nokia.com>, "netmod@ietf.org" <netmod@ietf.org>, "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
References: <DU2PR02MB101603161862E378A02A4BDD388A0A@DU2PR02MB10160.eurprd02.prod.outlook.com> <ZUICMr0AgbPip1qK@alice.eecs.jacobs-university.de> <BY5PR11MB4196CCB231A271136077F2FAB5A6A@BY5PR11MB4196.namprd11.prod.outlook.com> <DM6PR08MB5084EBAE193D62AF9FF922449BAAA@DM6PR08MB5084.namprd08.prod.outlook.com> <0100018ba6be8b0f-4059eb68-ec6a-46d9-9b2d-48ee5fbd7b2c-000000@email.amazonses.com> <0100018ba8db1249-d264fc02-db48-4899-9692-2c0cb44bfcb1-000000@email.amazonses.com> <DU2PR02MB10160CB77CF3F9A990CDFB48388B0A@DU2PR02MB10160.eurprd02.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <DU2PR02MB10160CB77CF3F9A990CDFB48388B0A@DU2PR02MB10160.eurprd02.prod.outlook.com>
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Siyn0_y4JFCPnMr3f7lXpkhG4bE>
Subject: Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-message for "config false"
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2023 10:29:49 -0000

I think an important piece is missing here is, namely _who_ is doing
the validation and who is in charge of keeping things valid. For
config data, the server has the task to keep the config datastores
valid (or more precisely the resulting intended configuration).

For state data, if the server's state does not satisfy the
constraints, then this is what the server's true state is. It is then
at best a client's job to check whether a server's state is valid.
(And then there are subtleties like whether it is at all feasible for
a client to obtain a consistent snapshot of the server's state.)

/js

On Thu, Nov 16, 2023 at 09:33:05AM +0000, mohamed.boucadair@orange.com wrote:
> Hi all, 
> 
> Thank you all for the feedback. 
> 
> Here is the text I suggest to capture the outcome of the discussion: 
> 
>    Section 8.1 of [RFC7950] includes a provision for defining a
>    constraint on state data and specifies that the constraint must be
>    true in a valid state data.  However, Section 5.3 of [RFC8342] soften
>    that behavior by allowing semantic constraints to be violated under
>    some circumstances to help detecting anomalies.  Relaxing validation
>    constraints on state data is meant to reveal deviations of the
>    observed behavior vs. intended behavior of a managed entity and
>    hopefully trigger corrective actions by a management system.  From
>    that perspective, it is RECOMMENDED to avoid defining constraints on
>    state data that would hinder the detection of abnormal behaviors of a
>    managed entity.
> 
> Comments are still welcome.
> 
> You can also proposed change here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fboucadair%2Frfc8407bis%2Fpull%2F24%2Ffiles&data=05%7C01%7Cjschoenwae%40constructor.university%7C26abf6cf21c74491173d08dbe6871eeb%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638357240241272993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=js2FRW5aKEFjQCMqqOrM%2FjeRQ3hOu267C8hi6NkfGP4%3D&reserved=0
> 
> Thanks. 
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : netmod <netmod-bounces@ietf.org> De la part de Kent Watsen
> > Envoyé : mardi 7 novembre 2023 09:17
> > À : Jason Sterne (Nokia) <jason.sterne@nokia.com>
> > Cc : Jürgen Schönwälder <jschoenwaelder@constructor.university>;
> > netmod@ietf.org; Rob Wilton (rwilton)
> > <rwilton=40cisco.com@dmarc.ietf.org>
> > Objet : Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-
> > message for "config false"
> > 
> > My confusion, sorry, I was thinking "mandatory".
> > 
> > Must statements on opstate are useful, but less important.
> > 
> > Kent
> > 
> > 
> > > On Nov 6, 2023, at 5:26 PM, Kent Watsen <kent@watsen.net> wrote:
> > >
> > > "Must" statements on opstate usefully helps clients know when
> > certain values will always appear, enabling better optimization and
> > usability.
> > >
> > > E.g., for Syslog messages, there must always be a timestamp,
> > severity, and a message.  It would be unhelpful for the server to not
> > declare its intention to always send these fields.
> > >
> > > Kent
> > >
> > >
> > >> On Nov 6, 2023, at 10:49 AM, Jason Sterne (Nokia)
> > <jason.sterne@nokia.com> wrote:
> > >>
> > >> +1 on what Jurgen and Rob are pointing out here.
> > >>
> > >> I'm not sure it makes a ton of sense to actually have a lot of
> > "must" statements in state models. We could consider discouraging
> > them?  (but we need to continue *allowing* them).
> > >>
> > >> Jason
> > >>
> > >>> -----Original Message-----
> > >>> From: netmod <netmod-bounces@ietf.org> On Behalf Of Rob Wilton
> > >>> (rwilton)
> > >>> Sent: Thursday, November 2, 2023 5:17 AM
> > >>> To: Jürgen Schönwälder <jschoenwaelder@constructor.university>;
> > >>> mohamed.boucadair@orange.com
> > >>> Cc: netmod@ietf.org
> > >>> Subject: Re: [netmod] draft-ietf-netmod-rfc8407bis: must +
> > >>> error-message for "config false"
> > >>>
> > >>>
> > >>> CAUTION: This is an external email. Please be very careful when
> > >>> clicking links or opening attachments. See the URL nok.it/ext for
> > >>> additional information.
> > >>>
> > >>>
> > >>>
> > >>> Specifically regarding MUST statements on state date, RFC 8342
> > >>> section 5.3, also has this statement (which effectively aligns to
> > Jürgen's last paragraph):
> > >>>
> > >>>  <operational> SHOULD conform to any constraints specified in the
> > >>> data  model, but given the principal aim of returning "in use"
> > >>> values, it  is possible that constraints MAY be violated under
> > some
> > >>> circumstances  (e.g., an abnormal value is "in use", the structure
> > >>> of a list is  being modified, or remnant configuration (see
> > Section
> > >>> 5.3.1) still  exists).  Note that deviations SHOULD be used when
> > it
> > >>> is known in  advance that a device does not fully conform to the
> > >>> <operational>  schema.
> > >>>
> > >>>  Only semantic constraints MAY be violated.  These are the YANG
> > >>> "when", "must", "mandatory", "unique", "min-elements", and
> > >>> "max-elements" statements; and the uniqueness of key values.
> > >>>
> > >>>  Syntactic constraints MUST NOT be violated, including
> > hierarchical
> > >>> organization, identifiers, and type-based constraints.  If a node
> > in
> > >>> <operational> does not meet the syntactic constraints, then it
> > MUST
> > >>> NOT be returned, and some other mechanism should be used to flag
> > >>> the error.
> > >>>
> > >>> Regards,
> > >>> Rob
> > >>>
> > >>>
> > >>> -----Original Message-----
> > >>> From: netmod <netmod-bounces@ietf.org> On Behalf Of Jürgen
> > >>> Schönwälder
> > >>> Sent: Wednesday, November 1, 2023 7:46 AM
> > >>> To: mohamed.boucadair@orange.com
> > >>> Cc: netmod@ietf.org
> > >>> Subject: Re: [netmod] draft-ietf-netmod-rfc8407bis: must +
> > >>> error-message for "config false"
> > >>>
> > >>> Here is what RFC 7950 says:
> > >>>
> > >>> 7.5.4.1.  The "error-message" Statement
> > >>>
> > >>>    The "error-message" statement, which is optional, takes a
> > string as
> > >>>    an argument.  If the constraint evaluates to "false", the
> > string is
> > >>>    passed as <error-message> in the <rpc-error> in NETCONF.
> > >>>
> > >>> Since state data is not (directly) modified by processing RPCs,
> > >>> which <rpc-error> would carry the <error-message>? If the answer
> > is
> > >>> 'none', then why define an <error-message> for state data?
> > >>>
> > >>> My take has always been that operational state data should report
> > as
> > >>> much as possible the true state of the device - even if the
> > current
> > >>> state violates certain constraints. The entity to check
> > constraints
> > >>> would be a managing system, not the managed system. That said, the
> > >>> wording in section 7.5.4.1 indicates that the designers had
> > servers
> > >>> processing RPCs in mind.
> > >>>
> > >>> /js
> > >>>
> > >>> On Tue, Oct 31, 2023 at 10:40:15AM +0000,
> > >>> mohamed.boucadair@orange.com wrote:
> > >>>> Hi all,
> > >>>>
> > >>>> In the context of
> > >>>>
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd%2F&data=05%7C01%7Cjschoenwae%40constructor.university%7C26abf6cf21c74491173d08dbe6871eeb%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638357240241272993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Nx8ws2dhHwjFe%2Bspaz1LvlMefkF8CbP6FkMeTzYVZWc%3D&reserved=0
> > >>>> atatracker.ietf.org%2Fdoc%2Fdraft-ietf-pce-pcep-
> > yang%2F&data=05%7C0
> > >>>>
> > 1%7Cmohamed.boucadair%40orange.com%7Cc1ac68c885cb4711756508dbdf69fe
> > >>>>
> > 8f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638349418553384436%
> > >>>>
> > 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> > >>>>
> > 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BHSDJ75gIDhVPGK6Wd4jw
> > >>>> nVqvoPmod8Tdgqs2aE2My4%3D&reserved=0,
> > >>> Dhruv has received in the past a comment about the use of "must +
> > >>> error- message" for "config false" data nodes. He reported that
> > >>> comment at
> > >>>
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma%2F&data=05%7C01%7Cjschoenwae%40constructor.university%7C26abf6cf21c74491173d08dbe6871eeb%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638357240241272993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6ytUTAcaVbwKNF%2B8ZZlkvseqgwlZdxbxCCHqr4mE%2Fsw%3D&reserved=0
> > >>> ilarchive.ietf.org%2Farch%2Fmsg%2Fyang-
> > &data=05%7C01%7Cmohamed.bouca
> > >>>
> > dair%40orange.com%7Cc1ac68c885cb4711756508dbdf69fe8f%7C90c7a20af34b4
> > >>>
> > 0bfbc48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown%7CTWFpbGZ
> > >>>
> > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > >>>
> > %3D%7C3000%7C%7C%7C&sdata=zDx1qDuMLXzjpfQu8W0TmTT40rEzuAPP%2F%2Bzs9i
> > >>> pRN1w%3D&reserved=0 doctors/gWnXnyNHPVv_nZB1PQjThAwP1JY/, but
> > >>> without any follow-up.
> > >>>>
> > >>>> rfc7950#section-8.1 includes a provision for the use of "must"
> > for
> > >>>> state
> > >>> data, but silent about the use of error-message. Some guidance for
> > >>> authors may be useful here.
> > >>>>
> > >>>> The following options are being considered:
> > >>>>
> > >>>> (1) Remove both must and error-message for config false data
> > nodes
> > >>>> (2) Remove error-message but keep the must
> > >>>> (3) keep both
> > >>>>
> > >>>> I think that (3) is OK as this is a formal way to detect
> > anomalies
> > >>>> in state
> > >>> data, but I'm open to hear what the WG thinks.
> > >>>>
> > >>>> Opinions whether we need to include a mention about this in
> > >>>> draft-ietf-
> > >>> netmod-rfc8407bis are welcome.
> > >>>>
> > >>>> Thank you.
> > >>>>
> > >>>> Cheers,
> > >>>> Med
> > >>>>
> > >>>>
> > >>> __________________________________________________________________
> > >>> __________________________________________
> > >>>> Ce message et ses pieces jointes peuvent contenir des
> > informations
> > >>> confidentielles ou privilegiees et ne doivent donc
> > >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous
> > >>>> avez recu
> > >>> ce message par erreur, veuillez le signaler
> > >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les
> > >>>> messages
> > >>> electroniques etant susceptibles d'alteration,
> > >>>> Orange decline toute responsabilite si ce message a ete altere,
> > >>>> deforme ou
> > >>> falsifie. Merci.
> > >>>>
> > >>>> This message and its attachments may contain confidential or
> > >>>> privileged
> > >>> information that may be protected by law;
> > >>>> they should not be distributed, used or copied without
> > authorisation.
> > >>>> If you have received this email in error, please notify the
> > sender
> > >>>> and delete
> > >>> this message and its attachments.
> > >>>> As emails may be altered, Orange is not liable for messages that
> > >>>> have
> > >>> been modified, changed or falsified.
> > >>>> Thank you.
> > >>>
> > >>>> _______________________________________________
> > >>>> netmod mailing list
> > >>>> netmod@ietf.org
> > >>>>
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw%2F&data=05%7C01%7Cjschoenwae%40constructor.university%7C26abf6cf21c74491173d08dbe6871eeb%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638357240241272993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OJ3I%2BwvsYluLgpNsKaOSL1siw8pJ8D41jxS%2FXxGpBhc%3D&reserved=0
> > >>>>
> > ww.ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7Cmohamed.bo
> > >>>>
> > ucadair%40orange.com%7Cc1ac68c885cb4711756508dbdf69fe8f%7C90c7a20af
> > >>>>
> > 34b40bfbc48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown%7CTW
> > >>>>
> > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> > >>>>
> > CI6Mn0%3D%7C3000%7C%7C%7C&sdata=xv80aOKrF0iGDzNvoa%2FemQBlo9GT9JUPH
> > >>>> D%2Fuq8OW%2Bz4%3D&reserved=0
> > >>>
> > >>>
> > >>> --
> > >>> Jürgen Schönwälder              Constructor University Bremen
> > gGmbH
> > >>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
> > Germany
> > >>> Fax:   +49 421 200 3103
> > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcon%2F&data=05%7C01%7Cjschoenwae%40constructor.university%7C26abf6cf21c74491173d08dbe6871eeb%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638357240241272993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oFaKvNYLqctFxYwSsw14RnEnSUnWYBX9CIks24fLOL8%3D&reserved=0
> > structor.university%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7
> > Cc1ac68c885cb4711756508dbdf69fe8f%7C90c7a20af34b40bfbc48b9253b6f5d20%7
> > C0%7C0%7C638349418553384436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata
> > =76T5wjMZGFhAXNT2WqG9BsJSqAeBI0eAz2fhoHpvD%2B4%3D&reserved=0>
> > >>>
> > >>> _______________________________________________
> > >>> netmod mailing list
> > >>> netmod@ietf.org
> > >>>
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww%2F&data=05%7C01%7Cjschoenwae%40constructor.university%7C26abf6cf21c74491173d08dbe6871eeb%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638357240241272993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8YeUMEvX%2FrKlruKyiLtLK40vBhXFI43ViAmqiYjY%2BTs%3D&reserved=0
> > >>>
> > w.ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7Cmohamed.bouc
> > >>>
> > adair%40orange.com%7Cc1ac68c885cb4711756508dbdf69fe8f%7C90c7a20af34b
> > >>>
> > 40bfbc48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown%7CTWFpbG
> > >>>
> > Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> > >>>
> > 0%3D%7C3000%7C%7C%7C&sdata=xv80aOKrF0iGDzNvoa%2FemQBlo9GT9JUPHD%2Fuq
> > >>> 8OW%2Bz4%3D&reserved=0
> > >>> _______________________________________________
> > >>> netmod mailing list
> > >>> netmod@ietf.org
> > >>>
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww%2F&data=05%7C01%7Cjschoenwae%40constructor.university%7C26abf6cf21c74491173d08dbe6871eeb%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638357240241272993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8YeUMEvX%2FrKlruKyiLtLK40vBhXFI43ViAmqiYjY%2BTs%3D&reserved=0
> > >>>
> > w.ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7Cmohamed.bouc
> > >>>
> > adair%40orange.com%7Cc1ac68c885cb4711756508dbdf69fe8f%7C90c7a20af34b
> > >>>
> > 40bfbc48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown%7CTWFpbG
> > >>>
> > Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> > >>>
> > 0%3D%7C3000%7C%7C%7C&sdata=xv80aOKrF0iGDzNvoa%2FemQBlo9GT9JUPHD%2Fuq
> > >>> 8OW%2Bz4%3D&reserved=0
> > >> _______________________________________________
> > >> netmod mailing list
> > >> netmod@ietf.org
> > >>
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%2F&data=05%7C01%7Cjschoenwae%40constructor.university%7C26abf6cf21c74491173d08dbe6871eeb%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638357240241272993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7EavHsPCJ3GuwUfWxm2Oy4b66auVaT4DeCGqXe6VZaw%3D&reserved=0
> > >>
> > .ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7Cmohamed.boucad
> > >>
> > air%40orange.com%7Cc1ac68c885cb4711756508dbdf69fe8f%7C90c7a20af34b40b
> > >>
> > fbc48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown%7CTWFpbGZsb3
> > >>
> > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> > >>
> > 7C3000%7C%7C%7C&sdata=xv80aOKrF0iGDzNvoa%2FemQBlo9GT9JUPHD%2Fuq8OW%2B
> > >> z4%3D&reserved=0
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%2F&data=05%7C01%7Cjschoenwae%40constructor.university%7C26abf6cf21c74491173d08dbe6871eeb%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638357240241272993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7EavHsPCJ3GuwUfWxm2Oy4b66auVaT4DeCGqXe6VZaw%3D&reserved=0.
> > >
> > ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7Cmohamed.boucadai
> > >
> > r%40orange.com%7Cc1ac68c885cb4711756508dbdf69fe8f%7C90c7a20af34b40bfbc
> > >
> > 48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown%7CTWFpbGZsb3d8ey
> > >
> > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> > >
> > 0%7C%7C%7C&sdata=xv80aOKrF0iGDzNvoa%2FemQBlo9GT9JUPHD%2Fuq8OW%2Bz4%3D&
> > > reserved=0
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%2F&data=05%7C01%7Cjschoenwae%40constructor.university%7C26abf6cf21c74491173d08dbe6871eeb%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638357240241272993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7EavHsPCJ3GuwUfWxm2Oy4b66auVaT4DeCGqXe6VZaw%3D&reserved=0.
> > ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7Cmohamed.boucadai
> > r%40orange.com%7Cc1ac68c885cb4711756508dbdf69fe8f%7C90c7a20af34b40bfbc
> > 48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown%7CTWFpbGZsb3d8ey
> > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> > 0%7C%7C%7C&sdata=xv80aOKrF0iGDzNvoa%2FemQBlo9GT9JUPHD%2Fuq8OW%2Bz4%3D&
> > reserved=0
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 

-- 
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://constructor.university/>