Subject: [OPSAWG] Externalize some data nodes for better flexibilty (RE: [Last-Call] Yangdoctors last call review of draft-ietf-opsawg-l2nm-07)

From: <[email-masked]>
Date: Tue, 5 Oct 2021 12:21:35 +0000

Hi all, 

Lada made a comment about the flexibility of the module (see below). A proposal to address the comment is to move the ethernet segment part into a separate module as suggested in the following PR: https://github.com/IETF-OPSAWG-WG/lxnm/pull/349/files. The change is straightforward and has the merit to preserve the same global structure for both L2NM and L3NM. 

Please review the PR and share your thoughts. 

Of course, do no change is still an option.

Cheers,
Med

> >> -----Message d'origine-----
> >> De : Ladislav Lhotka via Datatracker <[email-masked]> Envoyé :
> >> mardi 5 octobre 2021 10:04 À : [email-masked] Cc :
> >> [email-masked]; [email-masked];
> >> [email-masked] Objet : Yangdoctors last call review of
> >> draft-ietf-opsawg-l2nm-07
> >>
> >> Reviewer: Ladislav Lhotka
> >> Review result: Ready with Issues
> >>
> >> **** General comments
> >>
> >> The ietf-l2vpn-ntw module with about 400 data nodes represents an
> >> impressive amount of work. Its size, however, raises some concerns in
> >> terms of manageability. For example, if the ITU-T Y-1731
> >> recommendation ever gets updated (I don't know how likely this is),
> >> the module will have to be updated.
> >> I would therefore suggest to consider factoring out such parts into
> >> separate modules.
> >
> > [Med] We have already made an effort to factorize many items in:
> > * I-D.ietf-vpn-common
> > * two separate IANA-maintained modules
> >
> > One candidate "externalization" that I think would work to address your
> concern is to move ethernet-segments (and esi types) into a separate
> module.
> >
> > I have a preference to work in that direction vs. touching the OAM part.
> >
> > Would that solve your concern? Thank you.
> 
> I think it is up to the authors and WG to consider what to do, maybe
> nothing. I am not an expert in this domain, so I have no strong opinion,
> but it is certainly better to think twice because the module structure
> cannot be easily changed afterwards.

_________________________________________________________________________________________________________________________

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: Moti Morgenstern <[email-masked]>
Date: Tue, 5 Oct 2021 12:43:12 +0000

Hi,

I think it's OK to manage the ES object via a separate module. 
It is very same approach as in https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-yang-07 (which expired two years ago). 

Regards,
Moti

-----Original Message-----
From: OPSAWG <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, October 5, 2021 3:22 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [EXTERNAL] [OPSAWG] Externalize some data nodes for better flexibilty (RE: [Last-Call] Yangdoctors last call review of draft-ietf-opsawg-l2nm-07)

Hi all, 

Lada made a comment about the flexibility of the module (see below). A proposal to address the comment is to move the ethernet segment part into a separate module as suggested in the following PR: https://clicktime.symantec.com/3QU3R71WM87hLHH56QkYggD6H2?u=https%3A%2F%2Fgithub.com%2FIETF-OPSAWG-WG%2Flxnm%2Fpull%2F349%2Ffiles. The change is straightforward and has the merit to preserve the same global structure for both L2NM and L3NM. 

Cheers,
Med

> >> impressive amount of work. Its size, however, raises some concerns 
> >> in terms of manageability. For example, if the ITU-T Y-1731 
> nothing. I am not an expert in this domain, so I have no strong 
> opinion, but it is certainly better to think twice because the module 
> structure cannot be easily changed afterwards.

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-masked]
https://clicktime.symantec.com/3Ur78Ht4sGyPAUod8ApTUTZ6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawg

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

---

From: <[email-masked]>
Date: Mon, 11 Oct 2021 09:58:41 +0000

Hi all, 

As there was no objection against this proposal, we merged this PR. 

Cheers,
Med

> De : [email-masked] <[email-masked]>
> Envoyé : mardi 5 octobre 2021 14:22
> À : [email-masked]; [email-masked]
> Cc : [email-masked]
> Objet : Externalize some data nodes for better flexibilty (RE: [Last-Call]
> Yangdoctors last call review of draft-ietf-opsawg-l2nm-07)
> 
> Hi all,
> 
> Lada made a comment about the flexibility of the module (see below). A
> proposal to address the comment is to move the ethernet segment part into
> a separate module as suggested in the following PR:
> https://github.com/IETF-OPSAWG-WG/lxnm/pull/349/files. The change is
> straightforward and has the merit to preserve the same global structure
> for both L2NM and L3NM.
> 
> __________________________________________________________________________
> 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.