A YANG Network Data Model for Layer 3 VPNs
RFC 9182

Thank you for the work on this document, and for addressing my review comments.

Francesca

It would be useful to summarize this document's relationship to RFC8299 in the abstract.

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 7.6.3. , paragraph 43, nit:
> icates which BFD flavor is used to setup the session (e.g., classic BFD [RFC
>                                    ^^^^^
The verb "set up" is spelled as two words. The noun "setup" is spelled as one.

Section 7.7. , paragraph 1, nit:
> y applicable if both RP redundancy and and delivery through optimal path are
>                                    ^^^^^^^
Possible typo: you repeated a word.

Section 8. , paragraph 8, nit:
>  VPLS and, VXLAN. Other values may defined, if needed."; leaf type { type ide
>                                    ^^^^^^^
The modal verb "may" requires the verb's base form.

Section 8. , paragraph 32, nit:
> cription "Reference to the TCP-AO key chain."; reference "RFC 8177: YANG Key
>                                   ^^^^^^^^^
This word is normally spelled as one.

Section 8. , paragraph 32, nit:
> description "Reference to the MD5 key chain."; reference "RFC 8177: YANG Key
>                                   ^^^^^^^^^
This word is normally spelled as one.

Section 8. , paragraph 32, nit:
> f; description "Customer-supplied key chain."; } } } } } container service {
>                                   ^^^^^^^^^
This word is normally spelled as one.

Section 8. , paragraph 32, nit:
> cast static source/group associated to to IGMP session"; leaf group-addr { ty
>                                     ^^^^^
Possible typo: you repeated a word.

Document references draft-ietf-opsawg-vpn-common-09, but -10 is the latest
available revision.

Obsolete reference to RFC4447, obsoleted by RFC8077 (this may be on purpose).

These URLs point to tools.ietf.org, which is being deprecated:
 * http://tools.ietf.org/wg/opsawg/

Thanks for addressing my DISCUSS

Thank you to Rifaat Shekh-Yusef for the SECDIR review.

Thank you for addressing my DISCUSS and COMMENT feedback.

I originally balloted Abstain, but after discussions and explanations from Rob I'm moving to No Objection.

I agree with Alvaro that there are inconsistencies that make deriving the mapping between the model and implementations tricky. However, I don't really think that that is the "fault" of this document, but rather is an artifact of the fact that there are so many different "types" of VPNs, and every standard/implementation/vendor has their own special knobs and features. This makes creating a generic model largely impossible - it either needs to be so restrictive that it is basically pointless, or so comprehensive that it is unwieldily.
I think that this document did a good job of trying to thread this needle (and I thank/congratulate the authors), but I still think that it is not really usable. 
I also support Erik's discuss on Sec 7.6.2 -- this is also (I think) an artifact of trying to cover both too much and too little.

The -11 version addresses my discuss point. Thanks for addressing it.

Thanks for the many updates in the -12 through -14.
Just one final comment on the new changes:

Section 7.6.3

   The L3NM supports the configuration of one or more IPv4/IPv6 static
   routes.  Since the same structure is used for both IPv4 and IPv6, it
   was considered to have one single container to group both static
   entries independently of their address family, but that design was
   abandoned to ease the mapping with the structure in [RFC8299].

This paragraph appears both at the end of 7.6.3 and at the start of
7.6.3.1; presumably only the latter is needed.

I finally found the time to go through that document and have no objection with it going forward.