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

[Ballot comment]
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  (e.g. pe-diverse, pop-diverse) from
  these  site-network-accesses".  In addition,
"
Model described as proposed - less tentative language for a standard is appropriate now.

[Ballot discuss]
I do have a concern about the definition of the IPv6 address allocation mechanisms. It looks like the service model assumes that one of these mechanisms will be used, while in reality more than one of these mechanisms might be in use at the same time. I just wanted to make sure that this was a considered decision and not an oversight.

[Ballot comment]
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)?

[Ballot discuss]

(1) In 5.9.2, how are pre shared keys (PSK) updated or
rotated?  Don't you at least need some key id or versioning
or old/new thing defined? (Apologies if that "just works"
via some yang magic of which I'm unaware:-)

(2) When someone wants to use IPsec with PSK, wouldn't you
also need to specify algorithms etc to get interop?  I see
there's an "algorithm" string in the yang module, but that
seems too underspecified to be useful.

[Ballot comment]

- 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;-)

[Ballot comment]
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.

[Ballot comment]
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.

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

2 letter country codes? 3 letted country codes?
Reference?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-l3sm-l3vpn-service-model-16.txt. If any part of this review is inaccurate, please let us know.

Upon approval of this document, we understand that there are two registry actions to complete.

First, in the ns subregistry of the IETF XML Registry a single new namespace is to be registered as follows:

ID: yang:ietf-l3vpn-svc
URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names subregistry in the YANG Parameters registry located at:

https://www.iana.org/assignments/yang-parameters/

a single, new module name is to be registered as follows:

Name: ietf-l3vpn-svc
Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
Prefix: l3vpn-svc
Module:
Reference: [ RFC-to-be ]

We understand that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: l3sm@ietf.org, l3sm-chairs@ietf.org, draft-ietf-l3sm-l3vpn-service-model@ietf.org, "Qin Wu" , bclaise@cisco.com, bill.wu@huawei.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (YANG Data Model for L3VPN service delivery) to Proposed Standard


The IESG has received a request from the L3VPN Service Model  WG (l3sm)
to consider the following document:
- 'YANG Data Model for L3VPN service delivery'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-10-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines a YANG data model that can be used for
  communication between customers and network operators and to deliver
  a Layer 3 Provider Provisioned VPN service.  The document is limited
  to the BGP PE-based VPNs as described in [RFC4026], [RFC4110] and
  [RFC4364].  This model is intended to be instantiated at management
  system to deliver the overall service.  This model is not a
  configuration model to be used directly on network elements.  This
  model provides an abstracted view of the Layer 3 IPVPN service
  configuration components.  It will be up to a management system to
  take this as an input and use specific configurations models to
  configure the different network elements to deliver the service.  How
  configuration of network elements is done is out of scope of the
  document.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc4026: Provider Provisioned Virtual Private Network (VPN) Terminology (Informational - IETF stream)
Note that some of these references may already be listed in the acceptable Downref Registry.

Document Writeup for draft-ietf-l3sm-l3vpn-service-model

(1) What type of RFC is being requested?
Why is this the proper type of RFC?
Is this type of RFC indicated in the title page header?

The type of RFC being requested is Proposed Standard since this document includes YANG model that is being standardized. It also serves as framework to evaluate the set of YANG models that have already been developed or are under development, and helps identify any missing models or details. It is also viewed as driving requirements for protocol configuration model so that the service parameters can be mapped into inputs used by the protocol models.

The type of RFC has been indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up.

Technical Summary:

  This document defines a YANG data model that can be used for communication
  between customers and network operators, and to provide input to automated
  control and configuration applications used to deliver a Layer 3 Provider
  Provisioned VPN service.  The document is limited to the BGP PE-based VPNs
  as described in RFC4110 and RFC4364.  This model is intended to be instantiated
  at management system to deliver the overall service.  This model is not a
  configuration model to be used directly on network elements.  This model
  provides an abstracted view of the Layer 3 IPVPN service configuration components. 
  It will be up to a management system to take this as an input and use
  specific configurations models to configure the different network
  elements to deliver the service.  How configuration of network
  elements is done is out of scope of the document.

Working Group Summary:

Consensus was complete in the working group after one and half year of development.
A first WGLC was largely silent reflecting (the chairs believe) satisfaction with previous discussions.
But after solicitation, a number of people from network operators responded that they considered
the document ready.
A few last-minute questions were received and handled.

Document Quality:

The shepherd is aware of a proof-of-concept implementation based on an earlier version of the document.
This document is ready to ship, but there are a few minor editorial changes arising from document
shepherd review - these can be handled during IETF last call.

Personnel:

Qin Wu is the Document Shepherd.
Benoit Claise is the responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document
Shepherd. If this version of the document is not ready for publication, please explain
why the document is being forwarded to the IESG.

The document shepherd reviewed the documents for correctness after earlier
reviews done when the documents were Last Called.

Only one minor issue that was found is that the reference to RFC6020 should be replaced
by RFC 7950 since YANG has been proposed to be used for RESTCONF and YANG version 1.1,
i.e.,RFC7950 can be used to well support RESTCONF.

This and a few minor editorial changes arising from document shepherd review can be handled
during IETF last call.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that
have been performed?

There are no concerns from document Shepherd.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security,
operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that
took place.

The early review were requested from YANG Doctor.
In addition, the documents already received additional sufficient review from Landry and Jean-Philippe
representing the operators.

A final YANG Doctor review has been commissioned and is promised to arrive during IETF last call.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document
that the Responsible Area Director and/or the IESG should be aware of?

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance
with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The authors confirmed conformance to BCPs 78 and 79 during the work on the document.
They have just been asked to explicitly reconfirm this for the completed document.

(8) Has an IPR disclosure been filed that references this document?

No

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence
of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is solid consensus of all people who have contributed to L3SM Service Model.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

None.

(11) Identify any ID nits the Document Shepherd has found in this document.

One minor Nits was found in this document is:
"
  ** There are 31 instances of too long lines in the document, the longest
    one being 13 characters in excess of 72.
"
This is a function of how the YANG tree is presented as a figure by XML2RFC.
The RFC Editor can resolve the issue.

(12) Describe how the document meets any required formal review criteria, such as the
MIB Doctor, media type, and URI type reviews.

Early YANG Doctor review was provided.
A further YANG Doctor review has been requested.
The module parses cleanly.

(13) Have all references within this document been identified as either normative or informative?

Yes. The Document Shepherd checked all this as part of the document review.

(14) Are there normative references to documents that are not ready for advancement or are
otherwise in an unclear state? 

No. All normative references are to RFCs.

(15) Are there downward normative references references (see RFC 3967)?

No. All normative references are upward.

(16) Will publication of this document change the status of any existing RFCs?

No. No impact on status of existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section.

The IANA considerations section is consistent with the body of the
document and contains all of the information necessary for IANA to
create and populate the new registry.

(18) List any new IANA registries that require Expert Review for future allocations.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

ID-NITS done.
YANG validation done.
XML code snippet validation done.
No BNF, MIB definitions in draft.

Document Writeup for draft-ietf-l3sm-l3vpn-service-model

(1) What type of RFC is being requested?
Why is this the proper type of RFC?
Is this type of RFC indicated in the title page header?

The type of RFC being requested is Proposed Standard since this document includes YANG model that is being standardized. It also serves as framework to evaluate the set of YANG models that have already been developed or are under development, and helps identify any missing models or details. It is also viewed as driving requirements for protocol configuration model so that the service parameters can be mapped into inputs used by the protocol models.

The type of RFC has been indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up.

Technical Summary:

  This document defines a YANG data model that can be used for communication
  between customers and network operators, and to provide input to automated
  control and configuration applications used to deliver a Layer 3 Provider
  Provisioned VPN service.  The document is limited to the BGP PE-based VPNs
  as described in RFC4110 and RFC4364.  This model is intended to be instantiated
  at management system to deliver the overall service.  This model is not a
  configuration model to be used directly on network elements.  This model
  provides an abstracted view of the Layer 3 IPVPN service configuration components. 
  It will be up to a management system to take this as an input and use
  specific configurations models to configure the different network
  elements to deliver the service.  How configuration of network
  elements is done is out of scope of the document.

Working Group Summary:

Consensus was complete in the working group after one and half year of development.
A first WGLC was largely silent reflecting (the chairs believe) satisfaction with previous discussions.
But after solicitation, a number of people from network operators responded that they considered
the document ready.
A few last-minute questions were received and handled.

Document Quality:

The shepherd is aware of a proof-of-concept implementation based on an earlier version of the document.
This document is ready to ship, but there are a few minor editorial changes arising from document
shepherd review - these can be handled during IETF last call.

Personnel:

Qin Wu is the Document Shepherd.
Benoit Claiseis the responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document
Shepherd. If this version of the document is not ready for publication, please explain
why the document is being forwarded to the IESG.

The document shepherd reviewed the documents for correctness after earlier
reviews done when the documents were Last Called.

Only one minor issue that was found is that the reference to RFC6020 should be replaced
by RFC 7950 since YANG has been proposed to be used for RESTCONF and YANG version 1.1,
i.e.,RFC7950 can be used to well support RESTCONF.

This and a few minor editorial changes arising from document shepherd review can be handled
during IETF last call.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that
have been performed?

There are no concerns from document Shepherd.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security,
operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that
took place.

The early review were requested from YANG Doctor.
In addition, the documents already received additional sufficient review from Landry and Jean-Philippe
representing the operators.

A final YANG Doctor review has been commissioned and is promised to arrive during IETF last call.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document
that the Responsible Area Director and/or the IESG should be aware of?

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance
with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The authors confirmed conformance to BCPs 78 and 79 during the work on the document.
They have just been asked to explicitly reconfirm this for the completed document.

(8) Has an IPR disclosure been filed that references this document?

No

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence
of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is solid consensus of all people who have contributed to L3SM Service Model.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

None.

(11) Identify any ID nits the Document Shepherd has found in this document.

One minor Nits was found in this document is:
"
  ** There are 31 instances of too long lines in the document, the longest
    one being 13 characters in excess of 72.
"
This is a function of how the YANG tree is presented as a figure by XML2RFC.
The RFC Editor can resolve the issue.

(12) Describe how the document meets any required formal review criteria, such as the
MIB Doctor, media type, and URI type reviews.

Early YANG Doctor review was provided.
A further YANG Doctor review has been requested.
The module parses cleanly.

(13) Have all references within this document been identified as either normative or informative?

Yes. The Document Shepherd checked all this as part of the document review.

(14) Are there normative references to documents that are not ready for advancement or are
otherwise in an unclear state? 

No. All normative references are to RFCs.

(15) Are there downward normative references references (see RFC 3967)?

No. All normative references are upward.

(16) Will publication of this document change the status of any existing RFCs?

No. No impact on status of existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section.

The IANA considerations section is consistent with the body of the
document and contains all of the information necessary for IANA to
create and populate the new registry.

(18) List any new IANA registries that require Expert Review for future allocations.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

ID-NITS done.
YANG validation done.
XML code snippet validation done.
No BNF, MIB definitions in draft.

Document Writeup for draft-ietf-l3sm-l3vpn-service-model

(1) What type of RFC is being requested?
Why is this the proper type of RFC?
Is this type of RFC indicated in the title page header?

The type of RFC being requested is Standard Track since this document includes YANG model that is being standardized. It also serves as framework to evaluate the set of YANG models that have already been developed or are under development, and helps identify any missing models or details. It is also viewed as driving requirements for protocol configuration model so that the service parameters can be mapped into inputs used by the protocol models.

The type of RFC has been indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up.

Technical Summary:

  This document defines a YANG data model that can be used for communication
  between customers and network operators, and to provide input to automated
  control and configuration applications used to deliver a Layer 3 Provider
  Provisioned VPN service.  The document is limited to the BGP PE-based VPNs
  as described in RFC4110 and RFC4364.  This model is intended to be instantiated
  at management system to deliver the overall service.  This model is not a
  configuration model to be used directly on network elements.  This model
  provides an abstracted view of the Layer 3 IPVPN service configuration components. 
  It will be up to a management system to take this as an input and use
  specific configurations models to configure the different network
  elements to deliver the service.  How configuration of network
  elements is done is out of scope of the document.

Working Group Summary:

Consensus was complete in the working group after one and half year of development.
A first WGLC was largely silent reflecting (the chairs believe) satisfaction with previous discussions.
But after solicitation, a number of people from network operators responded that they considered
the document ready.
A few last-minute questions were received and handled.

Document Quality:

The shepherd is aware of a proof-of-concept implementation based on an earlier version of the document.
This document is ready to ship, but there are a few minor editorial changes arising from document
shepherd review - these can be handled during IETF last call.

Personnel:

Document Shepherd: Qin Wu (bill.wu@huawei.com)
AD responsible: Benoit Claise

(3) Briefly describe the review of this document that was performed by the Document
Shepherd. If this version of the document is not ready for publication, please explain
why the document is being forwarded to the IESG.

The document shepherd reviewed the documents for correctness after earlier
reviews done when the documents were Last Called.

Only one minor issue that was found is that the reference to RFC6020 should be replaced
by RFC 7950 since YANG has been proposed to be used for RESTCONF and YANG version 1.1,
i.e.,RFC7950 can be used to well support RESTCONF.

This and a few minor editorial changes arising from document shepherd review can be handled
during IETF last call.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that
have been performed?

There are no concerns from document Shepherd.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security,
operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that
took place.

The early review were requested from YANG Doctor.
In addition, the documents already received additional sufficient review from Landry and Jean-Philippe
representing the operators.

A final YANG Doctor review has been commissioned and is promised to arrive during IETF last call.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document
that the Responsible Area Director and/or the IESG should be aware of?

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance
with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The authors confirmed conformance to BCPs 78 and 79 during the work on the document.
They have just been asked to explicitly reconfirm this for the completed document.

(8) Has an IPR disclosure been filed that references this document?

No

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence
of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is solid consensus of all people who have contributed to L3SM Service Model.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

None.

(11) Identify any ID nits the Document Shepherd has found in this document.

One minor Nits was found in this document is:
"
  ** There are 31 instances of too long lines in the document, the longest
    one being 13 characters in excess of 72.
"
This is a function of how the YANG tree is presented as a figure by XML2RFC.
The RFC Editor can resolve the issue.

(12) Describe how the document meets any required formal review criteria, such as the
MIB Doctor, media type, and URI type reviews.

Early YANG Doctor review was provided.
A further YANG Doctor review has been requested.
The module parses cleanly.

(13) Have all references within this document been identified as either normative or informative?

Yes. The Document Shepherd checked all this as part of the document review.

(14) Are there normative references to documents that are not ready for advancement or are
otherwise in an unclear state? 

No. All normative references are to RFCs.

(15) Are there downward normative references references (see RFC 3967)?

No. All normative references are upward.

(16) Will publication of this document change the status of any existing RFCs?

No. No impact on status of existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section.

The IANA considerations section is consistent with the body of the
document and contains all of the information necessary for IANA to
create and populate the new registry.

(18) List any new IANA registries that require Expert Review for future allocations.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

ID-NITS done.
YANG validation done.
XML code snippet validation done.
No BNF, MIB definitions in draft.

The type of RFC being requested is Proposed Standard since this document serves as framework to
evaluate the set of YANG models that have already been developed or are under development, and
help identify any missing models or details and it is also viewed as driving requirements for
protocol configuration model so that the service parameters can be mapped into inputs used by
the protocol models.