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

From: <[email-masked]>
Date: Thu, 28 Oct 2021 12:38:27 +0000

Hi Julian,

Moving the discussion to the list to have more eyes from the WG on this particular point:

“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://github.com/IETF-OPSAWG-WG/lxnm/issues/353.

Cheers,
Med

De : julianL999 <[email-masked]>
Envoyé : mercredi 27 octobre 2021 17:46
À : IETF-OPSAWG-WG/lxnm <[email-masked]>
Cc : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Comment <[email-masked]>
Objet : Re: [IETF-OPSAWG-WG/lxnm] inbound/outbound terminology (Issue #353)

Hi Med

In https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l2nm-09 it says as follows, maybe it is a typo?

container svc-outbound-bandwidth {
if-feature "vpn-common:outbound-bw";
description
"From the PE perspective, the service outbound
bandwidth of the connection.";

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)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://github.com/IETF-OPSAWG-WG/lxnm/issues/353#issuecomment-953059202>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADXR6VZSFIYRMPT32WGNE3DUJAUFNANCNFSM5GXLDWMQ>.
Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

_________________________________________________________________________________________________________________________

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.

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Thu, 28 Oct 2021 12:44:37 +0000

On 10/28/21 08:38, [email-masked]<mailto:[email-masked]> wrote:
Hi Julian,

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.

Joe

Cheers,
Med

De : julianL999 <[email-masked]><mailto:[email-masked]>
Envoyé : mercredi 27 octobre 2021 17:46
À : IETF-OPSAWG-WG/lxnm <[email-masked]><mailto:[email-masked]>
Cc : BOUCADAIR Mohamed INNOV/NET <[email-masked]><mailto:[email-masked]>; Comment <[email-masked]><mailto:[email-masked]>
Objet : Re: [IETF-OPSAWG-WG/lxnm] inbound/outbound terminology (Issue #353)

Hi Med

—

---

From: tom petch <[email-masked]>
Date: Thu, 28 Oct 2021 16:10:36 +0000

From: OPSAWG <[email-masked]> on behalf of Joe Clarke (jclarke) <jclarke=[email-masked]>
Sent: 28 October 2021 13:44

<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!

Tom Petch

Joe

Cheers,
Med

Hi Med

—

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Thu, 28 Oct 2021 16:29:04 +0000

> 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 appro…

Yes, I see what you mean.  They were very clear in those descriptions,
even addressing the SM discrepancies.

Joe

---

From: Julian Lucek <[email-masked]>
Date: Fri, 29 Oct 2021 11:08:07 +0000

> 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$ .
    >

    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