Re-, FWIW, -18 includes now this note:
NEW: Note that the following subsections introduce some data nodes that enclose textual descriptions (e.g., VPN service (Section 7.3), VPN node (Section 7.5), or VPN network access (Section 7.6)). Such descriptions are not intended for random end users but for network/system/software engineers that use their local context to provide and interpret such information. Therefore, no mechanism for language tagging is needed. Cheers, Med > -----Message d'origine----- > De : BOUCADAIR Mohamed INNOV/NET > Envoyé : jeudi 2 juin 2022 07:08 > À : 'Francesca Palombini' <[email protected]>; The > IESG <[email protected]> > Cc : [email protected]; [email protected]; > [email protected]; [email protected] > Objet : RE: Francesca Palombini's No Objection on draft-ietf- > opsawg-l2nm-17: (with COMMENT) > > 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
