Re: [OPSAWG] [IETF-OPSAWG-WG/lxnm] inbound/outbound terminology (Issue #353)

mohamed.boucadair@orange.com Mon, 08 November 2021 07:14 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9873A0DFF for <opsawg@ietfa.amsl.com>; Sun, 7 Nov 2021 23:14:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgK78TPGRhxB for <opsawg@ietfa.amsl.com>; Sun, 7 Nov 2021 23:14:24 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1133A0E02 for <opsawg@ietf.org>; Sun, 7 Nov 2021 23:14:24 -0800 (PST)
Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar26.francetelecom.fr (ESMTP service) with ESMTPS id 4Hnj6644Y7zFqnL; Mon, 8 Nov 2021 08:14:22 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1636355662; bh=ZSuIexLZUi+eFAR8FiKkSlvP8v3uItCVp7YA8NEOCI8=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=EV1BgcpNtbZomFy7ulNOXjJ2Nx47HeZmZiHr+YFvoPH6qSwtoRiMamkHvE5DSdwwD fcgQgxKcX1IWpcl6Jb4lL5CdUUKo0LPJnO59UoVaIXgmvu/OFKW7+50I1Hy7yOON/J wYlVBhy6YZk4GJjIEYc7KW+ptW8rsdSon6wQTeThctjb1GQn3MMV8J22QERjL/EM9j 20P7b4uvaqpfjlGyJtfz7rzbuztoWeUVwR9Nnma63/rPA+RSncgCURTZsNOBSqKVMd hupR3AUWzIn9mvNYc4gy1QfIAklFX9QlTGlzorvtmwA+jFCCb+4YyGc4TRF5KyeJIG njNsz60tXCVZQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar05.francetelecom.fr (ESMTP service) with ESMTPS id 4Hnj662lwKz2xCC; Mon, 8 Nov 2021 08:14:22 +0100 (CET)
From: mohamed.boucadair@orange.com
To: Julian Lucek <jlucek@juniper.net>, "Joe Clarke (jclarke)" <jclarke@cisco.com>, tom petch <ietfc@btconnect.com>, "Joe Clarke (jclarke)" <jclarke=40cisco.com@dmarc.ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: [OPSAWG] [IETF-OPSAWG-WG/lxnm] inbound/outbound terminology (Issue #353)
Thread-Index: AQHXyk6eDjDx/FKXyki4H9XbUBoAfav5S4Jg
Content-Class:
Date: Mon, 08 Nov 2021 07:14:21 +0000
Message-ID: <9733_1636355662_6188CE4E_9733_496_1_787AE7BB302AE849A7480A190F8B93303544B2BD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <IETF-OPSAWG-WG/lxnm/issues/353@github.com> <IETF-OPSAWG-WG/lxnm/issues/353/953059202@github.com> <18574_1635424709_617A99C5_18574_414_1_787AE7BB302AE849A7480A190F8B933035436F0E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BN9PR11MB537122A2B999A0D807A0406DB8869@BN9PR11MB5371.namprd11.prod.outlook.com> <AM7PR07MB6248C2107CD7187F468C850AA0869@AM7PR07MB6248.eurprd07.prod.outlook.com> <BN9PR11MB53717F668860605599C2EF00B8869@BN9PR11MB5371.namprd11.prod.outlook.com> <637FFA80-0DAD-4320-865C-7D22BBB24956@juniper.net>
In-Reply-To: <637FFA80-0DAD-4320-865C-7D22BBB24956@juniper.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2021-11-08T07:13:55Z; 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_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=54934359-9850-4168-8322-bab26afb6415; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/SJ5G3YOHGX3ptD53xqePo3_7T38>
Subject: Re: [OPSAWG] [IETF-OPSAWG-WG/lxnm] inbound/outbound terminology (Issue #353)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Nov 2021 07:14:29 -0000

Hi Julian, all,

The proposed change is now implemented in -10. 

Thank you for raising this. 

Cheers,
Med

> -----Message d'origine-----
> De : Julian Lucek <jlucek@juniper.net>
> Envoyé : vendredi 29 octobre 2021 13:08
> À : Joe Clarke (jclarke) <jclarke@cisco.com>; tom petch
> <ietfc@btconnect.com>; Joe Clarke (jclarke)
> <jclarke=40cisco.com@dmarc.ietf.org>; BOUCADAIR Mohamed INNOV/NET
> <mohamed.boucadair@orange.com>; opsawg@ietf.org
> Objet : Re: [OPSAWG] [IETF-OPSAWG-WG/lxnm] inbound/outbound terminology
> (Issue #353)
> 
> 
> 
>     > “But I would urge you to change the terminology to "PE-to-CE-
> bandwidth" /"CE-to-PE-bandwidth" to make it super-explicit, the current
> terminology has been causing endless confusion to implementers (I realise
> it's inherited from the service models, but changing the terminology in
> LXNM would cure the problem well)”
>     > All, Julian raised early this week a comment about an L2NM
> terminology we are inheriting from the service model. The full context of
> this discussion can be seen at:
> https://urldefense.com/v3/__https://github.com/IETF-OPSAWG-
> WG/lxnm/issues/353__;!!NEt6yMaO-gk!ReRxmR5F6z_pKtX7BhgdObWeu4Fcy-
> LBM0ZthSDuvFlmOdmDYHq0tMvAIHpYPusN$ .
>     >
>     > As a contributor, reading the current draft text in conjunction with
> the YANG model description, I agree with Julian.  It's confusing.  Typo
> aside, I had to jump back and forth a couple of times to grok things
> correctly.  Aligning the terminology in the module with text in Section
> 7.6.4 in terms of CE vs. PE and direction would help.
>     >
>     > <tp>
>     >
>     > Or you could align it with l3nm where a similar issue was raised and
> the wording was changed to make it clearer.  The wording does not use PE
> or CE, and is the wording that that the  IESG has approved!
> 
>     Yes, I see what you mean.  They were very clear in those descriptions,
>     even addressing the SM discrepancies.
> 
>     Joe
> 
> It would be highly preferable for the leaf names to be self-explanatory,
> for the benefit of those reading the model itself or using auto-generated
> structures derived from it. In v18 of the l3nm, the leaf names are
> "inbound-bandwidth" and "outbound-bandwidth" so one needs to read the
> description to understand from whose perspective those directions are.
> 
> Julia
> 
> 
> Juniper Business Use Only

_________________________________________________________________________________________________________________________

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.