Subject: [OPSAWG] Yangdoctors last call review of draft-ietf-opsawg-vpn-common-06

From: Radek Krejčí via Datatracker <[email-masked]>
Date: Sun, 28 Mar 2021 08:04:18 -0700

Reviewer: Radek Krejčí
Review result: Ready with Nits

The I-D document contains a single YANG module ietf-vpn-common.

The I-D as well as the module itself are in a good shape, I have just two notes:

* module's description
This is my fault since I came with it in the previous review. There should be
really `Section 4.c` as you had. What confused me is how the RFC shows it in
its htmlized version, where the link is connected just with the 'Section 4'
string and pointing to the RFC itself instead of actually referenced Trust
legal document.

* `service-status` grouping
While the `status-timestamp` grouping was modified since my previous review,
the `service-status` still contains only the service-status/status/oper-status
container with the config false flag. My arguments are still the same, the
description of the other items there says that they are status information, so
they should be specified that way. The uses statement doesn't have its own
config statement, so if you want to place the mentioned groupings into config
true data, an extra grouping or refine will be required.

---

From: <[email-masked]>
Date: Mon, 29 Mar 2021 06:48:38 +0000

Hi Radek, 

Many thanks for the review. 

Please see the changes at: https://github.com/IETF-OPSAWG-WG/lxnm/commit/e856ce054bfc942f2522f683da14d6b99f52a9a2 

Cheers,
Med

> -----Message d'origine-----
> De : Radek Krejčí via Datatracker [mailto:[email-masked]]
> Envoyé : dimanche 28 mars 2021 17:04
> À : [email-masked]
> Cc : [email-masked]; [email-masked];
> [email-masked]
> Objet : Yangdoctors last call review of draft-ietf-opsawg-vpn-common-
> 06
> 
> Reviewer: Radek Krejčí
> This is my fault since I came with it in the previous review. There
> should be really `Section 4.c` as you had. What confused me is how
> the RFC shows it in its htmlized version, where the link is connected
> just with the 'Section 4'
> string and pointing to the RFC itself instead of actually referenced
> Trust legal document.
> 
> While the `status-timestamp` grouping was modified since my previous
> review, the `service-status` still contains only the service-
> status/status/oper-status container with the config false flag. My
> arguments are still the same, the description of the other items
> there says that they are status information, so they should be
> specified that way. The uses statement doesn't have its own config
> statement, so if you want to place the mentioned groupings into
> config true data, an extra grouping or refine will be required.
> 
> 

_________________________________________________________________________________________________________________________

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.