Yes. I've just verified it. Nikolai, thanks for raising it. Regards, Rob
From: Joe Clarke (jclarke) <jcla...@cisco.com> Sent: 13 October 2022 13:48 To: mohamed.boucad...@orange.com; RFC Errata System <rfc-edi...@rfc-editor.org>; nmal...@ieee.org Cc: luis-angel.mu...@vodafone.com; opsawg@ietf.org; Rob Wilton (rwilton) <rwil...@cisco.com> Subject: Re: [Editorial Errata Reported] RFC9291 (7162) Agreed. Rob? Joe From: OPSAWG <opsawg-boun...@ietf.org<mailto:opsawg-boun...@ietf.org>> on behalf of mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Date: Thursday, October 13, 2022 at 7:29 AM To: RFC Errata System <rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>>, nmal...@ieee.org<mailto:nmal...@ieee.org> <nmal...@ieee.org<mailto:nmal...@ieee.org>> Cc: luis-angel.mu...@vodafone.com<mailto:luis-angel.mu...@vodafone.com> <luis-angel.mu...@vodafone.com<mailto:luis-angel.mu...@vodafone.com>>, opsawg@ietf.org<mailto:opsawg@ietf.org> <opsawg@ietf.org<mailto:opsawg@ietf.org>> Subject: Re: [OPSAWG] [Editorial Errata Reported] RFC9291 (7162) Hi Nikolai, all, Thank you for reporting this. This editorial erratum should be accepted. Thanks. Cheers, Med > -----Message d'origine----- > De : RFC Errata System > <rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>> > Envoyé : jeudi 13 octobre 2022 13:23 > À : rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org> > Cc : nmal...@ieee.org<mailto:nmal...@ieee.org>; BOUCADAIR Mohamed INNOV/NET > <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>; > oscar.gonzalezded...@telefonica.com<mailto:oscar.gonzalezded...@telefonica.com>; > samier.barguilgiraldo....@telefonica.com<mailto:samier.barguilgiraldo....@telefonica.com>; > luis- > angel.mu...@vodafone.com<mailto:angel.mu...@vodafone.com>; > opsawg@ietf.org<mailto:opsawg@ietf.org> > Objet : [Editorial Errata Reported] RFC9291 (7162) > > The following errata report has been submitted for RFC9291, "A > YANG Network Data Model for Layer 2 VPNs". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7162 > > -------------------------------------- > Type: Editorial > Reported by: Nikolai Malykh <nmal...@ieee.org<mailto:nmal...@ieee.org>> > > Section: 9 > > Original Text > ------------- > 'ethernet-segments' and 'vpn-services': An attacker who is > able to > access network nodes can undertake various attacks, such as > deleting a running L2VPN service, interrupting all the > traffic of > a client. In addition, an attacker may modify the > attributes of a > running service (e.g., QoS, bandwidth) or an ES, leading to > malfunctioning of the service and therefore to SLA > violations. In > addition, an attacker could attempt to create an L2VPN > service, > add a new network access, or intercept/redirect the traffic > to a > non-authorized node. In addition to using NACM to prevent > authorized access, such activity can be detected by > adequately > monitoring and tracking network configuration changes. > > > Corrected Text > -------------- > 'ethernet-segments' and 'vpn-services': An attacker who is > able to > access network nodes can undertake various attacks, such as > deleting a running L2VPN service, interrupting all the > traffic of > a client. In addition, an attacker may modify the > attributes of a > running service (e.g., QoS, bandwidth) or an ES, leading to > malfunctioning of the service and therefore to SLA > violations. In > addition, an attacker could attempt to create an L2VPN > service, > add a new network access, or intercept/redirect the traffic > to a > non-authorized node. In addition to using NACM to prevent > unauthorized access, such activity can be detected by > adequately > monitoring and tracking network configuration changes. > > > Notes > ----- > Typo in last sentence, should be "unauthorized". > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, > please use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party can log > in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC9291 (draft-ietf-opsawg-l2nm-19) > -------------------------------------- > Title : A YANG Network Data Model for Layer 2 VPNs > Publication Date : September 2022 > Author(s) : M. Boucadair, Ed., O. Gonzalez de Dios, Ed., > S. Barguil, L. Munoz > Category : PROPOSED STANDARD > Source : Operations and Management Area Working Group > Area : Operations and Management > Stream : IETF > Verifying Party : IESG _________________________________________________________________________________________________________________________ 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 OPSAWG@ietf.org<mailto:OPSAWG@ietf.org> https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg