YANG Data Model for L3VPN Service Delivery
draft-ietf-l3sm-l3vpn-service-model-19

This is generally a well written document, so only a couple of nits:

leaf country-code {
        type string;
        description
         "Country of the site.";
       }

2 letter country codes? 3 letted country codes? Please add a normative reference. (I think you meant 2-letter ISO country codes.)

14.2.  Informative References

   [I-D.ietf-netconf-restconf]
              Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", draft-ietf-netconf-restconf-17 (work in
              progress), September 2016.

This should be Normative due to RFC 2119 language used when mentioning RESTCONF. However it doesn't look like RESTCONF needs any normative language when mentioned. For example:

The configuration of network elements MAY be done by CLI,
   or by NETCONF ([RFC6241])/RESTCONF ([I-D.ietf-netconf-restconf])
   coupled with specific configuration YANG data models (BGP, VRF, BFD
   ...) or any other way.

I don't think use of MAY is correct here, because it is not an implementation choice that affects use of your document. I would just change "MAY" to "can".

There is another similar use later in the document.

First, thank you very much for a well-written and easy to read and understand document.
There are a few places where expanding acronyms would be useful - but the RFC Editor can deal with those.

Nit:  Top of page 42 - sentence fragment 
"  Each constraint is expressed as "I want my current site-network-
   access to be <constraint-type> (e.g. pe-diverse, pop-diverse) from
   these <target> site-network-accesses".  In addition,
"
Model described as proposed - less tentative language for a standard is appropriate now.

Would suggest s/zip code/postal code/ since zip code is a US-only concept.

Les Ginsberg did the rtg-dir review: https://mailarchive.ietf.org/arch/msg/l3sm/NKEk7xO8RRUvBlNRP81RukOgzyo

This is a nicely readable document, especially given its size. I just have a few minor comments:

- There are a number of uses of MAY that seem more like statements of fact than permission to do something. Some of these take the form of "MAY decide" or "MAY want" that might be more appropriate if reformulated along the lines of "MAY do":
-- 5.6.3, last paragraph: "Other parameters like the requested svc-input-bandwidth, svc-output-
   bandwidth MAY help to decide the access type to be used."
-- 5.6.7, last paragraph: "Note that a service provider MAY decide..."
-- 5.11.6, last paragraph: "...user MAY decide..."
-- 5.13.1, first paragraph: "...a customer MAY want to..."
-- 7, 2nd paragraph: "The management system MAY be modular..." and "... the component...MAY be different."

- 14.2: As currently used, I think the references to restconf and to RFC6536 should be normative.

Thanks for addressing the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg06909.html

I'm sure the RFC editor would catch this, but IPsec instances should be replaced:
s/IPSec/IPsec/

Please spell out acronyms, e.g. OSS, CLI,ASM, SSM, RP, DHCP, OAM , BFD, LIME, VRF and many more... That would at least help me a lot :-)

Two question mainly on the transport constraints part (sec 5.13.2):

1) I don't really understand why there is bandwidth as a service parameter (section 5.12.1) and a transport constraint on bandwidth. Isn't that the same? Can you explain!

2) There is a transport constraint on path-diversity. Shouldn't that be a side specific parameter because that information in needed when placement is considered? And respectively isn't side-diversity already covered by Site network accesses parameters (sec 5.3.2)?

- 5.9.1: Just curious, the text says "   The current model
does not support any authentication parameters..." is that
because there's no user or host authentication?

- 5.9.2: I wondered why the empty "pki" container? Would it
not have been useul to define what's needed there, or do
you just never see IPsec using IKE for these VPNs? (Which
would be a bit sad;-)

Thanks for addressing my DISCUSS point by adding a new address allocation type (dhcp-slaac).