[Teas] Re: New Version Notification for draft-ietf-teas-rfc8776-update-14.txt
Italo Busi <Italo.Busi@huawei.com> Tue, 12 November 2024 13:01 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 2153DC15108B for <teas@ietfa.amsl.com>; Tue, 12 Nov 2024 05:01:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 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_VALIDITY_SAFE_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 H1z8wYhRgC_i for <teas@ietfa.amsl.com>; Tue, 12 Nov 2024 05:01:10 -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 37943C14F707 for <teas@ietf.org>; Tue, 12 Nov 2024 05:01:09 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4XnmhJ1lf3z6K9FW; Tue, 12 Nov 2024 20:59:12 +0800 (CST)
Received: from frapeml500005.china.huawei.com (unknown [7.182.85.13]) by mail.maildlp.com (Postfix) with ESMTPS id 9F437140B2A; Tue, 12 Nov 2024 21:01:06 +0800 (CST)
Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml500005.china.huawei.com (7.182.85.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Tue, 12 Nov 2024 14:01:06 +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; Tue, 12 Nov 2024 14:01:06 +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+et65nVP7Knz4iQgAUkvQCAAc8MQIAEryKwgAAa4rA=
Date: Tue, 12 Nov 2024 13:01:06 +0000
Message-ID: <23f5ea96e57649609502f3214177d393@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>
In-Reply-To: <DU2PR02MB10160B03E377B253CF7DD7F2888592@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.203.246.202]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Message-ID-Hash: Y3V2ADE52ODTBQIKWJUBVKAXYSU3E56T
X-Message-ID-Hash: Y3V2ADE52ODTBQIKWJUBVKAXYSU3E56T
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/WxUDALj-1LHXWi_Zd_rEFSqshIw>
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>
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%7CTWFpbGZsb3d8eyJFbXB0 > 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%7CTWFpbGZsb3d8eyJWIjoiMC > 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.
- [Teas] FW: New Version Notification for draft-iet… Italo Busi
- [Teas] Re: New Version Notification for draft-iet… mohamed.boucadair
- [Teas] Re: New Version Notification for draft-iet… Italo Busi
- [Teas] Re: New Version Notification for draft-iet… mohamed.boucadair
- [Teas] Re: New Version Notification for draft-iet… Italo Busi
- [Teas] Re: New Version Notification for draft-iet… mohamed.boucadair
- [Teas] Re: New Version Notification for draft-iet… Italo Busi