From: Julian Lucek <[email protected]> Sent: 08 November 2021 08:40 Hi Med
This is great, thank you making the change. Would it be possible to make the same change in the L3NM as well? <tp> Julian Note that L3NM has been approved by the IESG and is now in the RFC Editor's queue so making changes to it is a step backward in IETF processing and so could require some steps to be performed a further time. Tom Petch thanks Julian On 08/11/2021, 07:14, "[email protected]" <[email protected]> wrote: [External Email. Be cautious of content] Hi Julian, all, The proposed change is now implemented in -10. Thank you for raising this. Cheers, Med > -----Message d'origine----- > De : Julian Lucek <[email protected]> > Envoyé : vendredi 29 octobre 2021 13:08 > À : Joe Clarke (jclarke) <[email protected]>; tom petch > <[email protected]>; Joe Clarke (jclarke) > <[email protected]>; BOUCADAIR Mohamed INNOV/NET > <[email protected]>; [email protected] > 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. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
