Hi Francesca, Tanks for the review.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Francesca Palombini via Datatracker <[email protected]> > Envoyé : mercredi 1 juin 2022 23:27 > À : The IESG <[email protected]> > Cc : [email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > Objet : Francesca Palombini's No Objection on draft-ietf-opsawg- > l2nm-17: (with COMMENT) > > Francesca Palombini has entered the following ballot position for > draft-ietf-opsawg-l2nm-17: No Objection > > When responding, please keep the subject line intact and reply to > all email addresses included in the To and CC lines. (Feel free to > cut this introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot- > positions/ > for more information about how to handle DISCUSS and COMMENT > positions. > > > The document, along with other ballot positions, can be found > here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/ > > > > ------------------------------------------------------------------ > ---- > COMMENT: > ------------------------------------------------------------------ > ---- > > # ART AD Review of draft-ietf-opsawg-l2nm-17 > > cc @fpalombini > > Thank you for the work on this document. > > I have a couple of comments, hopefully easy to fix. > > I have not finished reviewing the examples in appendix, I might > update this > ballot if I have additional comments. > [Med] Noted. > Francesca > > ## Comments > > ### boolean for enabled/disabled > > Section 8.4: > ``` > "Controls whether loss measurement is > enabled/disabled."; > ``` > ``` > "Controls whether ingress > replication is > enabled/disabled."; > ``` > ``` > "Controles whether P2MP replication > is > enabled/disabled."; > ``` > Suggest rephrasing for clarity as other boolean fields: "Controls > whether X is > enabled ('true') or disabled ('false')."; > [Med] Fixed. > ### needs a language tag > > Section 8.4: > ``` > leaf description { > type string; > description > "A textual description of the VPN network > access."; > ``` > ``` > leaf description { > type string; > description > "Textual description of a VPN node."; > } > ``` > As these fields contain human-readable text, I believe it might > need a language > tag, or specify why a tag is not needed, as specified by RFC 5646. [Med] The language tag is not needed here because this is not intended to be exposed widely but for engineers, who are likely those who filled these descriptions. That’s the same reasoning why there is no language tag for the description leaf in the interface module (RFC8343): leaf description { type string; description "A textual description of the interface. A server implementation MAY map this leaf to the ifAlias MIB object. Such an implementation needs to use some mechanism to handle the differences in size and characters allowed between this leaf and ifAlias. The definition of such a mechanism is outside the scope of this document. Since ifAlias is defined to be stored in non-volatile storage, the MIB implementation MUST map ifAlias to the value of 'description' in the persistently stored configuration."; reference "RFC 2863: The Interfaces Group MIB - ifAlias"; } Please note also that we do have the following: +--rw vpn-service* [vpn-id] +--rw vpn-id vpn-common:vpn-id +--rw vpn-name? string +--rw vpn-description? string <=========== that is inherited from 9181, and for which no language tag is needed/define. > I think that > such a tag is not necessary for pw-description and vpn-description > as, if I > read them correctly, that is covered by the docs where those are > initially > defined (for example, for pw-description, this is covered by the > last paragraph > of section 5.5 of RFC 4447). Do let me know if I missed these > vpn-network-access description and vpn-node description, and their > language are > also described here or inherited from another doc. > > ## Notes > > This review is in the ["IETF Comments" Markdown format][ICMF], You > can use the > [`ietf-comments` tool][ICT] to automatically convert this review > into > individual GitHub issues. > > [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md > [ICT]: https://github.com/mnot/ietf-comments > > _________________________________________________________________________________________________________________________ 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
