> “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
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
