Hi Radek, Thanks for your helpful comments. We agree with your analysis and suggestions. It is acceptable to configure both PM types, although using both PM types is redundant. We have updated the YANG model as you suggested. Please see the diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-08. Thanks, Bo -----Original Message----- From: Radek Krejčí via Datatracker [mailto:noreply@xxxxxxxx] Sent: Wednesday, April 27, 2022 4:49 PM To: yang-doctors@xxxxxxxx Cc: draft-ietf-opsawg-yang-vpn-service-pm.all@xxxxxxxx; last-call@xxxxxxxx; opsawg@xxxxxxxx Subject: Yangdoctors last call review of draft-ietf-opsawg-yang-vpn-service-pm-07 Reviewer: Radek Krejčí Review result: Ready with Nits The draft addresses/fixes previous comments. The draft, as well as the module, is well written and the only issue I've found is kind of unclear use for the /nw:networks/nw:network/nt:link/pm-attributes/vpn-pm-type choice. I don't understand the logic of having one case config true and the second one config false. Does it mean that the second one is the default? Then it should be stated in the choice. I'm not an expert in the area, but I understand the choice as a way for clients to select the type of performance monitoring. Then it is kind of confusing that I can actually select only one of the available types. What about having config true presence container in the second case and holding config false leaf(s) there, wouldn't it be more clear? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
