[Teas] Re: New Version Notification for draft-ietf-teas-rfc8776-update-14.txt

Italo Busi <Italo.Busi@huawei.com> Fri, 15 November 2024 20:11 UTC

Return-Path: <Italo.Busi@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E720FC169414 for <teas@ietfa.amsl.com>; Fri, 15 Nov 2024 12:11:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 dFRQ4bG5KtKz for <teas@ietfa.amsl.com>; Fri, 15 Nov 2024 12:11:07 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC404C1CAE6C for <teas@ietf.org>; Fri, 15 Nov 2024 12:11:06 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Xqp6x00b3z6L767; Sat, 16 Nov 2024 04:10:48 +0800 (CST)
Received: from frapeml100006.china.huawei.com (unknown [7.182.85.201]) by mail.maildlp.com (Postfix) with ESMTPS id 3D962140136; Sat, 16 Nov 2024 04:11:05 +0800 (CST)
Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml100006.china.huawei.com (7.182.85.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Fri, 15 Nov 2024 21:11:04 +0100
Received: from frapeml500007.china.huawei.com ([7.182.85.172]) by frapeml500007.china.huawei.com ([7.182.85.172]) with mapi id 15.01.2507.039; Fri, 15 Nov 2024 21:11:04 +0100
From: Italo Busi <Italo.Busi@huawei.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: New Version Notification for draft-ietf-teas-rfc8776-update-14.txt
Thread-Index: AQHbLxZYEBEQaMg4sE6hE+et65nVP7Knz4iQgAUkvQCAAc8MQIAEryKwgAAa4rCAACM3IIAFJcRA
Date: Fri, 15 Nov 2024 20:11:04 +0000
Message-ID: <89d7d8f129bd4d96b2975b3a9db99b9f@huawei.com>
References: <173076507638.238.14305891068967673938@dt-datatracker-5f77bcf4bd-vglkb> <6d839c14e925479599b671b6e0e35b03@huawei.com> <DU2PR02MB101609235F1FABEE0507FB419885D2@DU2PR02MB10160.eurprd02.prod.outlook.com> <57e9f1c643ad4019abb08a61ac7be6a6@huawei.com> <DU2PR02MB10160B03E377B253CF7DD7F2888592@DU2PR02MB10160.eurprd02.prod.outlook.com> <23f5ea96e57649609502f3214177d393@huawei.com> <DU2PR02MB10160E039A04DDB0340335F0988592@DU2PR02MB10160.eurprd02.prod.outlook.com>
In-Reply-To: <DU2PR02MB10160E039A04DDB0340335F0988592@DU2PR02MB10160.eurprd02.prod.outlook.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=dbc7b6a1-fb23-4f2f-8d20-03a5a3e19f71;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2024-11-12T09:54:41Z;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20;
x-originating-ip: [10.45.151.155]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Message-ID-Hash: LOSMHL5Y6MJQYRBKSP65ODHO2KZA2LKA
X-Message-ID-Hash: LOSMHL5Y6MJQYRBKSP65ODHO2KZA2LKA
X-MailFrom: Italo.Busi@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-teas.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Teas] Re: New Version Notification for draft-ietf-teas-rfc8776-update-14.txt
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/t5ngra-49Tm6jV9ZwoScJRdSbgE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Owner: <mailto:teas-owner@ietf.org>
List-Post: <mailto:teas@ietf.org>
List-Subscribe: <mailto:teas-join@ietf.org>
List-Unsubscribe: <mailto:teas-leave@ietf.org>

Thanks Med

Your text looks better. I have updated the text in github with some tweak to avoid repeating "For example" twice (there was already an example):

https://github.com/tsaad-dev/te/commit/8ebdaa77cff565e55e1beafd4dea1b89c064f1a3

Italo

> -----Original Message-----
> From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
> Sent: martedì 12 novembre 2024 14:52
> To: Italo Busi <Italo.Busi@huawei.com>; teas@ietf.org
> Subject: RE: New Version Notification for draft-ietf-teas-rfc8776-update-14.txt
> 
> Re-,
> 
> I would indicate path-metric-hop to better link the example with the identities
> discussed in that bullet:
> 
> NEW:
>  For example, the measurement unit is not applicable for the number of hops
> metric ('path-metric-hop').
> 
> Thanks.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Italo Busi <Italo.Busi@huawei.com> Envoyé : mardi 12 novembre
> > 2024 14:01 À : BOUCADAIR Mohamed INNOV/NET
> > <mohamed.boucadair@orange.com>; teas@ietf.org Objet : RE: New Version
> > Notification for draft-ietf-teas-rfc8776- update-14.txt
> >
> > Hi Med,
> >
> > What about adding the following sentence?
> >
> > "For example, for the number of hops metric for which a measurement
> > unit is not applicable"
> >
> > Thanks, Italo
> >
> > > -----Original Message-----
> > > From: mohamed.boucadair@orange.com
> > <mohamed.boucadair@orange.com>
> > > Sent: martedì 12 novembre 2024 10:57
> > > To: Italo Busi <Italo.Busi@huawei.com>; teas@ietf.org
> > > Subject: RE: New Version Notification for
> > > draft-ietf-teas-rfc8776-update-14.txt
> > >
> > > Hi Italo,
> > >
> > > Thanks for taking care of the comments.
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : Italo Busi <Italo.Busi@huawei.com> Envoyé : samedi 9
> > novembre
> > > > 2024 12:13 À : BOUCADAIR Mohamed INNOV/NET
> > > > <mohamed.boucadair@orange.com>; teas@ietf.org Objet : RE: New
> > > > Version Notification for draft-ietf-teas-rfc8776- update-
> > 14.txt
> > > >
> > > >
> > > > Thanks Med
> > > >
> > > > I have updated the draft in github to address most of your
> > comments.
> > > > You can check the diff at:
> > > >
> > > >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > > Fauthor-tools.ietf.org%2Fdiff%3Fdoc_1%3Ddraft-ietf-teas-
> > rfc8776-
> > > > update-
> > > > 14%26url_2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Ftsaad-
> > > > dev%2Fte%2Frefs%2Fheads%2Fmaster%2Fdrafts%2Fte-types-
> > > > update%2Fdraft-ietf-teas-rfc8776-
> > > >
> > >
> >
> update.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C35f03
> > > 7
> > > >
> > >
> >
> 43b5324ccf4fbd08dd00af9341%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
> > > 0
> > > > %7C0%7C638667476300995946%7CUnknown%7CTWFpbGZsb3d8eyJFbX
> B0
> > > eU1hcGk
> > > >
> > iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldU
> > > >
> > >
> IjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fJlu8LBEMlX9Vh6MB2FOfqajgBtRa3e
> > > X3
> > > > 4NJeGMz38o%3D&reserved=0
> > > >
> > > > These are the comments for which I would need more input from
> > the
> > > > TEAS
> > > > WG:
> > > >
> > > > > * " The derived identities SHOULD describe the ..": I
> > wouldn't
> > > > > surprised if you receive a comment about why this is not a
> > > > MUST. You
> > > > > may explain an exception in the text if you have one in
> > mind.
> > > >
> > > > An exception is the number of hops which do not have a
> > measurement
> > > > unit, so it cannot be a MUST. Spelling out the exception is
> > not
> > > > future
> > > > proof: we do not wish to precluding future definitions of
> > other
> > > > identities similar which do not have measurement units.
> > > >
> > >
> > > [Med] I'm afraid you misread my comment. This is not about
> > listing
> > > every exception but indicating an example of when the SHOULD
> > can be ignored.
> > > Listing the # of hops as an example would be great.
> > >
> > > As a reminder, RFC2119 says the following:
> > >
> > > 3. SHOULD   This word, or the adjective "RECOMMENDED", mean
> > that there
> > >    may exist valid reasons in particular circumstances to
> > ignore a
> > >    particular item, but the full implications must be
> > understood and
> > >    carefully weighed before choosing a different course.
> > >
> > > > > * I like this text, but is this used by other standard
> > models
> > > > outside IETF?
> > > > >
> > > > > CURRENT:
> > > > >          The container has been renamed as 'explicit-route-
> > > > objects'.
> > > > >          This change is not affecting any IETF standard
> > YANG
> > > > models
> > > > >          since this grouping has not yet been used by any
> > YANG
> > > > model
> > > > >          defined in existing IETF RFCs.
> > > > >
> > > >
> > > > The text reflects the decision based on the discussion on the
> > > > list:
> > > >
> > > >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > > Fmailarchive.ietf.org%2Farch%2Fmsg%2Fteas%2Fcmf7KsRBxFQZ6oaf-
> > > >
> > >
> mzWTdZxAYQ%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%
> > > 7C35f
> > > >
> > >
> >
> 03743b5324ccf4fbd08dd00af9341%7C90c7a20af34b40bfbc48b9253b6f5d20%
> > > >
> > >
> 7C0%7C0%7C638667476301021706%7CUnknown%7CTWFpbGZsb3d8eyJFbXB
> > > 0eU1h
> > > >
> > cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI
> > > >
> > >
> ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yy0Y10Irdm9SFG8vuVzgotO1cEN
> > > NHj
> > > > y%2FD7XVyJ84Uow%3D&reserved=0
> > > >
> > > > IMHO, it is quite unlikely that other SDOs are importing this
> > > > grouping from RFC 8776 but I do not think we can write
> > anything
> > > > about this in an IETF draft/RFC so better to keep silent on
> > this
> > > > point
> > >
> > > [Med] I wasn't asking for any change here but interested to
> > hear if
> > > this was used outside. Thanks
> > >
> > > >
> > > > > * I still find identifiers such as "
> > > > > path-computation-error-destination-unknown-
> > > > > in-domain" to be toooooo long, but...
> > > >
> > > > At this stage, there is nothing I can do.
> > > >
> > >
> > > [Med] :-)
> > >
> > > > Just a side comment:
> > > >
> > > > > * "revision  2024-10-30" and file name should be
> > consistent.
> > > > Fix the date.
> > > >
> > > > This is another example of why I do not like duplicated
> > information
> > > > to be manually kept updated: this duplicated information
> > quickly
> > > > gets out of synch if authors or reviewers are not carefully
> > enough
> > > > to double check it
> > > >
> > > > An automatic tool to automatically keep this text in synch
> > or, at
> > > > least, flag the nit before submission would be very useful
> > > >
> > >
> > > [Med] Agree.
> > >
> > > > Italo
> > > >
> > > > > -----Original Message-----
> > > > > From: mohamed.boucadair@orange.com
> > > > <mohamed.boucadair@orange.com>
> > > > > Sent: venerdì 8 novembre 2024 08:18
> > > > > To: Italo Busi <Italo.Busi@huawei.com>; teas@ietf.org
> > > > > Subject: RE: New Version Notification for
> > > > > draft-ietf-teas-rfc8776-update-14.txt
> > > > >
> > > > > Hi Italo,
> > > > >
> > > > > Many thanks for the effort put in this document.
> > > > >
> > > > > I used a diff vs the original RFC to do a final check:
> > > > https://author-
> > > > > tools.ietf.org/diff?doc_1=rfc8776&doc_2=draft-ietf-teas-
> > > > rfc8776-update
> > > > > -
> > > > > 14&wdiff=1
> > > > >
> > > > > For the record, I consider the comments I raised as closed.
> > > > >
> > > > > FWIW, find below some nits/comments that you can consider
> > for a
> > > > future
> > > > > iteration when you will have other reviews:
> > > > >
> > > > > * I would invert the ordering of 1.2/1.3 so that mapping
> > with
> > > > 8776 is
> > > > > preserved
> > > > > * Introduction: s/ YANG models and obsoletes/ YANG modules
> > and
> > > > > obsoletes (or YANG data models and obsoletes)
> > > > > * Section 3.1: To ease referring by future documents, you
> > may
> > > > convert
> > > > > the text starting with " The "xxx" module contains the
> > > > following "
> > > > > into subsections
> > > > > * Idem as previous comment for Section 3.2
> > > > > * Section 3.1: s/No standard LPS provisioning/No standard
> > LP
> > > > > provisioning
> > > > > * " The derived identities SHOULD describe the ..": I
> > wouldn't
> > > > > surprised if you receive a comment about why this is not a
> > > > MUST. You
> > > > > may explain an exception in the text if you have one in
> > mind.
> > > > > * Don't be restrictive in how this will be used:
> > > > >
> > > > > OLD:
> > > > >    path-computation-error-reason:  A base YANG identity for
> > > > reporting
> > > > >       path computation error reasons as defined in Section
> > > > 3.1.1.
> > > > >
> > > > > NEW:
> > > > >    path-computation-error-reason:  A base YANG identity for
> > > > indicating
> > > > >       path computation error reasons as defined in Section
> > > > 3.1.1.
> > > > >
> > > > > (idem in the wording in 3.1.1)
> > > > >
> > > > > * These entries are listed as identities, while these are
> > > > groupings.
> > > > > Please fix
> > > > > that:
> > > > >
> > > > > CURRENT:
> > > > >
> > > > >    The "ietf-te-types" module contains the following YANG
> > > > reusable
> > > > >    identities:
> > > > >    ...
> > > > >    explicit-route-hop:  A YANG grouping that defines
> > supported
> > > > explicit
> > > > >       routes as defined in [RFC3209] and [RFC3477].
> > > > >    ...
> > > > >
> > > > >    encoding-and-switching-type:  This is a common grouping
> > to
> > > > define the
> > > > >       LSP encoding and switching types.
> > > > >
> > > > > * Explicit this is to clarify what an IANA module is not
> > used
> > > > here
> > > > >
> > > > > OLD:
> > > > >    The derived identities are defined in the "ietf-te-
> > types"
> > > > module
> > > > >    because there are error reasons which are:
> > > > >
> > > > > NEW:
> > > > >    The derived identities are defined in the "ietf-te-
> > types"
> > > > module
> > > > >    instead of an IANA-maintained module because there are
> > error
> > > > > reasons which are:
> > > > >
> > > > > * Section 3.2: I would split the identities vs groupings
> > > > > * I like this text, but is this used by other standard
> > models
> > > > outside IETF?
> > > > >
> > > > > CURRENT:
> > > > >          The container has been renamed as 'explicit-route-
> > > > objects'.
> > > > >          This change is not affecting any IETF standard
> > YANG
> > > > models
> > > > >          since this grouping has not yet been used by any
> > YANG
> > > > model
> > > > >          defined in existing IETF RFCs.
> > > > >
> > > > > * "revision  2024-10-30" and file name should be
> > consistent.
> > > > Fix the date.
> > > > > * I still find identifiers such as "
> > > > > path-computation-error-destination-unknown-
> > > > > in-domain" to be toooooo long, but...
> > > > > * " "At least one node identifier MUST be present.";  I
> > don't
> > > > think
> > > > > you need the normative language here as you already have a
> > must
> > > > statement.
> > > > > * Idem in
> > > > >
> > > > > "                 "At least one node identifier and at
> > least
> > > > one Link
> > > > >                  Termination Point (LTP) identifier MUST be
> > > > present."; "
> > > > >
> > > > >
> > > > > Cheers,
> > > > > Med
> > > > >
> > > > >
> > > > > Orange Restricted
> > > > >
> > > > > > -----Message d'origine-----
> > > > > > De : Italo Busi <Italo.Busi=40huawei.com@dmarc.ietf.org>
> > > > > > Envoyé : mardi 5 novembre 2024 00:10 À : teas@ietf.org
> > > > Objet :
> > > > > > [Teas] FW: New Version Notification for draft-ietf-teas-
> > > > > > rfc8776-update-14.txt
> > > > > >
> > > > > > Dear TEAS WG and chairs,
> > > > > >
> > > > > > I have just uploaded an updated version of the draft
> > > > addressing all
> > > > > > the comments received during the second Working group
> > last
> > > > call of
> > > > > > draft-ietf-teas-rfc8776-update-13 and discussion on the
> > WG
> > > > mailing
> > > > > > list
> > > > > >
> > > > > > I believe the draft is not ready to go to IESG
> > > > > >
> > > > > > Thanks, Italo (on behalf of co-authors/contributors)
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: internet-drafts@ietf.org <internet-
> > drafts@ietf.org>
> > > > > > > Sent: martedì 5 novembre 2024 01:05
> > > > > > > To: Aihua Guo <aihuaguo.ietf@gmail.com>; Igor Bryskin
> > > > > > > <i_bryskin@yahoo.com>; Italo Busi
> > <Italo.Busi@huawei.com>;
> > > > > > Tarek Saad
> > > > > > > <tsaad.net@gmail.com>; Xufeng Liu
> > > > <xufeng.liu.ietf@gmail.com>
> > > > > > > Subject: New Version Notification for
> > > > > > > draft-ietf-teas-rfc8776-update-14.txt
> > > > > > >
> > > > > > > A new version of Internet-Draft draft-ietf-teas-
> > rfc8776-
> > > > update-
> > > > > > 14.txt
> > > > > > > has been successfully submitted by Italo Busi and
> > posted to
> > > > the
> > > > > > IETF repository.
> > > > > > >
> > > > > > > Name:     draft-ietf-teas-rfc8776-update
> > > > > > > Revision: 14
> > > > > > > Title:    Common YANG Data Types for Traffic
> > Engineering
> > > > > > > Date:     2024-11-05
> > > > > > > Group:    teas
> > > > > > > Pages:    154
> > > > > > > URL:
> > > > > >
> > > >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > > > > Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-teas-rfc8776-
> > > > update-
> > > > > >
> > > > >
> > > >
> > >
> >
> 14.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C26c442cf5
> > > > > 2
> > > > > >
> > > > >
> > >
> 2b4778426208dcfd2e4716%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
> > > > > C0
> > > > > > %7C638663622429788248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC
> > > 4wL
> > > > > jAwMDA
> > > > > >
> > > > >
> > > >
> > >
> >
> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdat
> > > > > >
> > > > >
> > >
> a=hApMC%2Bb%2FKohyTzQJBIZ9ac0tKOzIqFZoVFo14Erf0IM%3D&reserved=0
> > > > > > > Status:
> > > > > >
> > > >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > > > > Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-teas-rfc8776-
> > > > > >
> > > > >
> > >
> update%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C26c4
> > > > > 42c
> > > > > >
> > > > >
> > > >
> > >
> >
> f522b4778426208dcfd2e4716%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%
> > > > > >
> > > > >
> > >
> 7C0%7C638663622429807585%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > > > > wLjAw
> > > > > >
> > > > >
> > > >
> > >
> >
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&
> > > > > s
> > > > > >
> > > > >
> > >
> data=2%2FJV94ILkIg0Gr6M29gWhYPnsVMFv5%2F7YM9dsZs%2Bs7c%3D&rese
> > > > > rve
> > > > > > d=0
> > > > > > > HTMLized:
> > > > > > >
> > > > > >
> > > >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > > > > Fdata
> > > > > > > tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-teas-
> > rfc8776-
> > > > > > &data=05%7C02%
> > > > > > >
> > > > > >
> > > > >
> > >
> 7Cmohamed.boucadair%40orange.com%7C26c442cf522b4778426208dcfd2e
> > > > > 47
> > > > > > 16%7C
> > > > > > >
> > > > > >
> > > > >
> > >
> 90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638663622429822216%
> > > > > 7CU
> > > > > > nknow
> > > > > > >
> > > > > >
> > > >
> > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > > > > > WwiLC
> > > > > > >
> > > > > >
> > > > >
> > >
> JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=xYJwo5A14GdYtVLDsrzVXxHSigD1js
> > > > > g1w
> > > > > > Jx9tL
> > > > > > > FoMEo%3D&reserved=0
> > > > > > > update
> > > > > > > Diff:
> > > > > >
> > > >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > > > > Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-teas-
> > > > rfc8776-
> > > > > >
> > > > >
> > >
> &data=05%7C02%7Cmohamed.boucadair%40orange.com%7C26c442cf522b4
> > > > > 778
> > > > > >
> > > > >
> > >
> 426208dcfd2e4716%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> > > > > 638
> > > > > >
> > > > >
> > >
> 663622429836473%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> > > > > LCJQI
> > > > > >
> > > > >
> > > >
> > >
> >
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=hFW
> > > > > a
> > > > > >
> ZMR8jikNKAVcwSRrPYk%2FXPnzkc%2FQSlW2225ZksM%3D&reserved=0
> > > > > > > update-14
> > > > > > >
> > > > > > > Abstract:
> > > > > > >
> > > > > > >    This document defines a collection of common data
> > types,
> > > > > > identities,
> > > > > > >    and groupings in YANG data modeling language.  These
> > > > derived
> > > > > > common
> > > > > > >    data types, identities and groupings are intended to
> > be
> > > > > > imported by
> > > > > > >    other modules, e.g., those which model the Traffic
> > > > > > Engineering (TE)
> > > > > > >    configuration and state capabilities.
> > > > > > >
> > > > > > >    This document obsoletes RFC 8776.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > The IETF Secretariat
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Teas mailing list -- teas@ietf.org To unsubscribe send an
> > email
> > > > > > to teas-leave@ietf.org
> > > > >
> > > >
> > >
> >
> _________________________________________________________________
> > > > > ___________________________________________
> > > > > 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.
> > > >
> > >
> > >
> >
> _________________________________________________________________
> > > ___________________________________________
> > > 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.
> >
> 
> _________________________________________________________________
> ___________________________________________
> 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.