Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications
draft-ietf-lime-yang-connectionless-oam-18

[Ballot comment]
Thank you very much for handling my Discuss so well and promptly. I am clearing based on the changes in
version -16. 
I've left the comments and Discuss below for clearer history.

====================
I took a quick look through version -15 and it looks like it addresses almost all of my serious Discuss points.
The only Discuss-worthy point is (c) below.  I have a few more points related to the changes that were made;
they are just comments & listed here to be with the original points.

For version 15:

a) In Sec 3.1,  it still says
" o  Router-id to represent the device or node.
      [I-D.ietf-spring-sr-yang]"

but [I-D.ietf.spring-sr-yang] has nothing to do with the router-id

b) In Section 4, thanks for adding urn:ietf:params:xml:ns:yang:ietf-lime-common-types - but
could it be a meaningful and accurate name like
  ietf-lime-time-types or ietf-time-types  (Benoit would know best structure)  that clearly
shows its intended scope for reuse and please fix the description for it too.

c)  [I-D.ietf-rtgwg-ni-model] is still listed as informative, but the model defined in there is imported
"import ietf-network-instance {
    prefix ni;
  }"  It needs to be normative

d) I-D.ietf-spring-sr-yang is still listed as informative - but not really correctly used as a reference.

=================


Thank you for your work on this document.  I have a number of serious concerns - but they all amount to fixing up your
references and slight restructuring  for clarity and reuse.

1) In Sec 3.1, the reference is system-id to represent the device or  node.[I-D.ietf-spring-sr-yang]
I believe that should be
"typedef router-id {
      type yang:dotted-quad;
      description
        "A 32-bit number in the dotted quad format assigned to each
          router. This number uniquely identifies the router within
          an Autonomous System.";
    }"
from draft-ietf-rtgwg-routing-types.
Certainly "[I-D.ietf-spring-sr-yang]" is NOT an informative reference with such a dependency.

I see that this document actually redefines router-id, instead of using it as part of the included import from
import ietf-routing-types {
  prefix rt;
  }
On p.27, I see "leaf system-id {
          type rt:router-id;
          description
            "System ID assigned to this node.";
        }"
so it is using the routing-yang-types, but renaming it as system-id, there.
Consistency isn't just the hobgoblin of little minds - it's actually useful.

In choice to-location, again "case system-id {
          leaf system-id-location {
            type router-id;
            description
              "System id location";
          }

          description
            "System ID";"
using the locally defined router-id and renaming it instead of using rt:router-id.


2) On p. 13 & 14, there are many identities associated with time and time-stamps.  I cannot believe that the best way
to handle these is by having them as part of an OAM model!  At a minimum, they should be defined as a separate module
and then included, even if it is in the same draft.  Then they will be available for reuse elsewhere.

3) This is extending [I-D.ietf-i2rs-yang-network-topo] - I do not believe this should be merely an informative reference.

4) I cannot tell if I-D.ietf-rtgwg-ni-model is informative or normative; it is not referenced in the draft - though there are fields
that are labeled NI without adequate description.

5) [I-D.ietf-rtgwg-routing-types] is not an informative reference.  Its module is imported and used.  It must be normative.

6) [I-D.ietf-spring-sr-yang] is listed as an informative reference, but if it were actually used as described, it would need to be normative.
Instead, I believe this can be removed as a reference.
==============================
a) Sec 3.8: It is unfortunate that the cc-session-statistics-data structure is not a list of {traffic type, cc-session-statistics}
instead of hardcoded members for IPv4 and IPv6 traffic only.  While it can still be extended for additional traffic types, the
naming may be inconsistent and there's no requirement that the contents are cc-session-statistics.

b) On p.9: " +--:(system-id)
      |                +--rw system-id-location?      router-id"

Why isn't this just named router-id instead of system-id, for consistency?  This comment applies throughout the draft.

c) The use of "tp" to mean test-point is a bit unfortunate in a model that is building off of the network topology one, which
uses "tp" for termination-point. 

d) On p. 13: "identity address-attribute-types {
    description
      "This is base identity of address
      attribute types which are ip-prefix,
      bgp, tunnel, pwe3, vpls, etc.";
  }"

I haven't a clue what is meant by a bgp address attribute type or a tunnel one.  Can you please expand the
description to be substantially more meaningful?  How is it used?

On p. 24, I see these defined
" case bgp {
            leaf bgp {
              type inet:ip-prefix;
              description
                "BGP Labeled Prefix ";
            }
          }
          case tunnel {

            leaf tunnel-interface {
              type uint32;
              description
                "VPN Prefix ";
            }
          }
          case pw {
            leaf remote-pe-address {
              type inet:ip-address;
              description
                "Remote pe address.";
            }
"
but unlike the other cases with clear descriptions and references to the relevant RFCs, these are NOT clear and do not even fully expand acronyms.

e) "grouping tp-address-ni "  Please expand what NI is the abbreviation for in the description.

[Ballot discuss]
I took a quick look through version -15 and it looks like it addresses almost all of my serious Discuss points.
The only Discuss-worthy point is (c) below.  I have a few more points related to the changes that were made;
they are just comments & listed here to be with the original points.

For version 15:

a) In Sec 3.1,  it still says
" o  Router-id to represent the device or node.
      [I-D.ietf-spring-sr-yang]"

but [I-D.ietf.spring-sr-yang] has nothing to do with the router-id

b) In Section 4, thanks for adding urn:ietf:params:xml:ns:yang:ietf-lime-common-types - but
could it be a meaningful and accurate name like
  ietf-lime-time-types or ietf-time-types  (Benoit would know best structure)  that clearly
shows its intended scope for reuse and please fix the description for it too.

c)  [I-D.ietf-rtgwg-ni-model] is still listed as informative, but the model defined in there is imported
"import ietf-network-instance {
    prefix ni;
  }"  It needs to be normative

d) I-D.ietf-spring-sr-yang is still listed as informative - but not really correctly used as a reference.

=================


Thank you for your work on this document.  I have a number of serious concerns - but they all amount to fixing up your
references and slight restructuring  for clarity and reuse.

1) In Sec 3.1, the reference is system-id to represent the device or  node.[I-D.ietf-spring-sr-yang]
I believe that should be
"typedef router-id {
      type yang:dotted-quad;
      description
        "A 32-bit number in the dotted quad format assigned to each
          router. This number uniquely identifies the router within
          an Autonomous System.";
    }"
from draft-ietf-rtgwg-routing-types.
Certainly "[I-D.ietf-spring-sr-yang]" is NOT an informative reference with such a dependency.

I see that this document actually redefines router-id, instead of using it as part of the included import from
import ietf-routing-types {
  prefix rt;
  }
On p.27, I see "leaf system-id {
          type rt:router-id;
          description
            "System ID assigned to this node.";
        }"
so it is using the routing-yang-types, but renaming it as system-id, there.
Consistency isn't just the hobgoblin of little minds - it's actually useful.

In choice to-location, again "case system-id {
          leaf system-id-location {
            type router-id;
            description
              "System id location";
          }

          description
            "System ID";"
using the locally defined router-id and renaming it instead of using rt:router-id.


2) On p. 13 & 14, there are many identities associated with time and time-stamps.  I cannot believe that the best way
to handle these is by having them as part of an OAM model!  At a minimum, they should be defined as a separate module
and then included, even if it is in the same draft.  Then they will be available for reuse elsewhere.

3) This is extending [I-D.ietf-i2rs-yang-network-topo] - I do not believe this should be merely an informative reference.

4) I cannot tell if I-D.ietf-rtgwg-ni-model is informative or normative; it is not referenced in the draft - though there are fields
that are labeled NI without adequate description.

5) [I-D.ietf-rtgwg-routing-types] is not an informative reference.  Its module is imported and used.  It must be normative.

6) [I-D.ietf-spring-sr-yang] is listed as an informative reference, but if it were actually used as described, it would need to be normative.
Instead, I believe this can be removed as a reference.

[Ballot comment]

==============================
a) Sec 3.8: It is unfortunate that the cc-session-statistics-data structure is not a list of {traffic type, cc-session-statistics}
instead of hardcoded members for IPv4 and IPv6 traffic only.  While it can still be extended for additional traffic types, the
naming may be inconsistent and there's no requirement that the contents are cc-session-statistics.

b) On p.9: " +--:(system-id)
      |                +--rw system-id-location?      router-id"

Why isn't this just named router-id instead of system-id, for consistency?  This comment applies throughout the draft.

c) The use of "tp" to mean test-point is a bit unfortunate in a model that is building off of the network topology one, which
uses "tp" for termination-point. 

d) On p. 13: "identity address-attribute-types {
    description
      "This is base identity of address
      attribute types which are ip-prefix,
      bgp, tunnel, pwe3, vpls, etc.";
  }"

I haven't a clue what is meant by a bgp address attribute type or a tunnel one.  Can you please expand the
description to be substantially more meaningful?  How is it used?

On p. 24, I see these defined
" case bgp {
            leaf bgp {
              type inet:ip-prefix;
              description
                "BGP Labeled Prefix ";
            }
          }
          case tunnel {

            leaf tunnel-interface {
              type uint32;
              description
                "VPN Prefix ";
            }
          }
          case pw {
            leaf remote-pe-address {
              type inet:ip-address;
              description
                "Remote pe address.";
            }
"
but unlike the other cases with clear descriptions and references to the relevant RFCs, these are NOT clear and do not even fully expand acronyms.

e) "grouping tp-address-ni "  Please expand what NI is the abbreviation for in the description.

[Ballot comment]
I fully agree with the readability comments - it needs a good editorial pass, and I feel it is unfair to give to the RFC Editor without one.

[Ballot comment]
I have some mostly editorial comments:

- I agree with Adam's comments about readability. Please also consider an editing pass for grammar--I noted some missing articles, plural disagreement, etc.

- Please check IDNits. It has some complaints about references. I will leave it to the authors to determine if they are real.

-1, paragraph starting with "The different OAM tools...": The phrase "After the connection is established" is missing an article.

-2.2: "RPC operation - A specific Remote Procedure Call.": That seems like a circular definition.

-3, first paragraph: 'The model augments "/networks/network/node" path...': missing article.

-3.1, 6th paragraph: "... these parameters are not explicit configured": s/explicit/explicitly

-5.2.1.2, 2nd paragraph: s/user/users

-6, third paragraph: " writable/creatable/deletable": Please don't use "/" as a substitute for conjunctions.

[Ballot comment]
Update: It seems the Gen-ART comments concerning the summary of the imported modules and their sources and the timestamps still need to be addressed. Sorry for missing this in my original ballot.

[Ballot comment]
I'd like to update my comment with some fairly mechanical suggestions for improvement that I believe will increase readability of the document greatly. In evaluating this document, I found a number of minor formatting issues that made it somewhat difficult to read.

1. Please ensure that all opening parentheses have a space before them and no space after them.

2. Please ensure that all closing parentheses have a space after them and no space before after them.

3. Please ensure that all quoted terms include both an opening quotation mark and a closing quotation mark.

4. Please ensure that there are no spaces between a quotation mark and the term it is quoting.

5. Please ensure that there *is* a space before an opening quotation mark

6. Please ensure that there *is* a space after a closing quotation mark (unless followed by another punctuation mark)

7. Please ensure that periods at the end of a sentence have no space before them and a space after them.

8. Please break up long paragraphs into separate paragraphs or bullet lists. The third paragraph of section 3 and the paragraph that forms section 3.3 are prime candidates for such an improvement.

9. Please double-check the formatting of the YANG module. The indentation is inconsistent and, in some places, can easily mislead the reader about the level of nesting and association of elements with each other.

My original comments follow.

------------------------------------------------------------

Please expand "EXP", "VPLS", and "LAG" on first use.

Section 3.2 refers to the "lime base model". Please define or expand "lime" or provide a citation that does so.

The id-nits tool reports that there are 6 instances of overly-long lines in the document. Given that these exist in code elements, the authors can probably make better decisions about how to resolve these than the RFC editor can.

Section 3.3 contains the following definition:

                list oam-neighboring-tps {
                  key "index";
                  leaf index {
                    type uint16 {
                        range "0..65536";
                    }

uint16 cannot represent 65536.

----------------------------------------

Later in the model:

container timestamp-80bit {
when "derived-from-or-self(../timestamp-type, 'cl-oam:ptp80')"{
        description
          "Only applies when 80bit PTP Timestamp.";
        }
  if-feature ptp-long-format;
      leaf timestamp-sec {
      type uint64 {
      range "0..281474976710656";
      }
      description
        "48bit Timestamp in seconds as per IEEE1588v2.";
      }
      leaf timestamp-nanosec {
      type uint32;
      description
        "Fractional part in nanoseconds as per IEEE1588v2
        or Fractional part in 64-bit NTP timestamp.";
      }
      description
      "Container for 64bit timestamp.";
    }

Issue 1: The 48-bit range should be 0..281474976710655, not 0..281474976710656

Issue 2: The description for this 80-bit timestamp container contains a description of "Container for 64bit timestamp."

----------------------------------------

Similar to issue 2 above, ntp-timestamp-32bit describes itself as a 64-bit timestamp.

[Ballot discuss]
Thank you for your work on this document.  I have a number of serious concerns - but they all amount to fixing up your
references and slight restructuring  for clarity and reuse.

1) In Sec 3.1, the reference is system-id to represent the device or  node.[I-D.ietf-spring-sr-yang]
I believe that should be
"typedef router-id {
      type yang:dotted-quad;
      description
        "A 32-bit number in the dotted quad format assigned to each
          router. This number uniquely identifies the router within
          an Autonomous System.";
    }"
from draft-ietf-rtgwg-routing-types.
Certainly "[I-D.ietf-spring-sr-yang]" is NOT an informative reference with such a dependency.

I see that this document actually redefines router-id, instead of using it as part of the included import from
import ietf-routing-types {
  prefix rt;
  }
On p.27, I see "leaf system-id {
          type rt:router-id;
          description
            "System ID assigned to this node.";
        }"
so it is using the routing-yang-types, but renaming it as system-id, there.
Consistency isn't just the hobgoblin of little minds - it's actually useful.

In choice to-location, again "case system-id {
          leaf system-id-location {
            type router-id;
            description
              "System id location";
          }

          description
            "System ID";"
using the locally defined router-id and renaming it instead of using rt:router-id.


2) On p. 13 & 14, there are many identities associated with time and time-stamps.  I cannot believe that the best way
to handle these is by having them as part of an OAM model!  At a minimum, they should be defined as a separate module
and then included, even if it is in the same draft.  Then they will be available for reuse elsewhere.

3) This is extending [I-D.ietf-i2rs-yang-network-topo] - I do not believe this should be merely an informative reference.

4) I cannot tell if I-D.ietf-rtgwg-ni-model is informative or normative; it is not referenced in the draft - though there are fields
that are labeled NI without adequate description.

5) [I-D.ietf-rtgwg-routing-types] is not an informative reference.  Its module is imported and used.  It must be normative.

6) [I-D.ietf-spring-sr-yang] is listed as an informative reference, but if it were actually used as described, it would need to be normative.
Instead, I believe this can be removed as a reference.

[Ballot comment]
a) Sec 3.8: It is unfortunate that the cc-session-statistics-data structure is not a list of {traffic type, cc-session-statistics}
instead of hardcoded members for IPv4 and IPv6 traffic only.  While it can still be extended for additional traffic types, the
naming may be inconsistent and there's no requirement that the contents are cc-session-statistics.

b) On p.9: " +--:(system-id)
      |                +--rw system-id-location?      router-id"

Why isn't this just named router-id instead of system-id, for consistency?  This comment applies throughout the draft.

c) The use of "tp" to mean test-point is a bit unfortunate in a model that is building off of the network topology one, which
uses "tp" for termination-point. 

d) On p. 13: "identity address-attribute-types {
    description
      "This is base identity of address
      attribute types which are ip-prefix,
      bgp, tunnel, pwe3, vpls, etc.";
  }"

I haven't a clue what is meant by a bgp address attribute type or a tunnel one.  Can you please expand the
description to be substantially more meaningful?  How is it used?

On p. 24, I see these defined
" case bgp {
            leaf bgp {
              type inet:ip-prefix;
              description
                "BGP Labeled Prefix ";
            }
          }
          case tunnel {

            leaf tunnel-interface {
              type uint32;
              description
                "VPN Prefix ";
            }
          }
          case pw {
            leaf remote-pe-address {
              type inet:ip-address;
              description
                "Remote pe address.";
            }
"
but unlike the other cases with clear descriptions and references to the relevant RFCs, these are NOT clear and do not even fully expand acronyms.

e) "grouping tp-address-ni "  Please expand what NI is the abbreviation for in the description.

[Ballot comment]
Please expand "EXP", "VPLS", and "LAG" on first use.

Section 3.2 refers to the "lime base model". Please define or expand "lime" or provide a citation that does so.

The id-nits tool reports that there are 6 instances of overly-long lines in the document. Given that these exist in code elements, the authors can probably make better decisions about how to resolve these than the RFC editor can.

Section 3.3 contains the following definition:

                list oam-neighboring-tps {
                  key "index";
                  leaf index {
                    type uint16 {
                        range "0..65536";
                    }

uint16 cannot represent 65536.

----------------------------------------

Later in the model:

container timestamp-80bit {
when "derived-from-or-self(../timestamp-type, 'cl-oam:ptp80')"{
        description
          "Only applies when 80bit PTP Timestamp.";
        }
  if-feature ptp-long-format;
      leaf timestamp-sec {
      type uint64 {
      range "0..281474976710656";
      }
      description
        "48bit Timestamp in seconds as per IEEE1588v2.";
      }
      leaf timestamp-nanosec {
      type uint32;
      description
        "Fractional part in nanoseconds as per IEEE1588v2
        or Fractional part in 64-bit NTP timestamp.";
      }
      description
      "Container for 64bit timestamp.";
    }

Issue 1: The 48-bit range should be 0..281474976710655, not 0..281474976710656

Issue 2: The description for this 80-bit timestamp container contains a description of "Container for 64bit timestamp."

----------------------------------------

Similar to issue 2 above, ntp-timestamp-32bit describes itself as a 64-bit timestamp.

[Ballot comment]
Can you add a sentence or two to the Security Considerations explaining why the nodes that are sensitive are sensitive?

I noticed a number of punctuation, spacing, and grammar errors. These will probably be caught by RFC-Ed but a proofread might help.

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

The IANA Services Operator has completed its review of draft-ietf-lime-yang-connectionless-oam-13, and we have a question for Benoit.

QUESTION: should the new YANG module be posted in the registry? If so, instructions should be added to the IANA Considerations section.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single new registration is to be made as follows:

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

The IESG-designated expert has reviewed and approved this request.

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

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

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

Name: ietf-connectionless-oam
Namespace: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam
Prefix: cl-oam
Module:
Reference: [ RFC-to-be ]

The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of this document.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-10-25):

From: The IESG
To: IETF-Announce
CC: Ron Bonica , cpignata@cisco.com, lime-chairs@ietf.org, Carlos Pignataro , bclaise@cisco.com, lime@ietf.org, draft-ietf-lime-yang-connectionless-oam@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Generic YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard


The IESG has received a request from the Layer Independent OAM Management in
the Multi-Layer Environment WG (lime) to consider the following document: -
'Generic YANG Data Model for Connectionless Operations, Administration,
  and Maintenance(OAM) protocols'
  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 2017-10-25. 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 presents a base YANG Data model for connectionless
  Operations Administration, and Maintenance(OAM) protocols.  It
  provides a technology-independent abstraction of key OAM constructs
  for connectionless protocols.  The base model presented here can be
  extended to include technology specific details.  This is leading to
  uniformity between OAM protocols and support both nested OAM
  workflows (i.e., performing OAM functions at different or same levels
  through a unified interface) and interacting OAM workflows ( i.e.,
  performing OAM functions at same levels through a unified interface).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam/ballot/


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

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document presents a base YANG Data model for connectionless
  Operations Administration, and Maintenance(OAM) protocols.  It
  provides a technology-independent abstraction of key OAM constructs
  for connectionless protocols. 

Working Group Summary

  This document is the product of an early split of LIME YANG
  Models into Connection-Oriented (C-O) OAM Models and
  Connectionless (CL, i.e., this) OAM Models. Further, the
  CL Model is further split into the Model (this document)
  and the retrieval methods (adjunct document).

Document Quality

  There are plans of and implementations of this specification.
  This includes at least two different implementations of
  the model, as well as product and demos at Bits-n-Bytes.
  Further, there are plans to finalize the implementation of
  this specification.

  The WG was very active in reviewing these documents.
  Notably, participants of the BFD and MPLS WGs were
  special reviewers.

  Additionally, worth mentioning Carl Moberg's YANG
  Doctor review which resulted in many fixes and
  improvements.

Personnel

  Carlos Pignataro 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.

  This version of the document is ready to be sent to the responsible AD.

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

  No concerns regarding both breath and depth of reviews.

(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.

  YANG, with review taken place by YANG Doctors (Carl Moberg)

(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? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  None.

(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.

  Yes, during WG adoption.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  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? 

  WG Agreement.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No threat of appeal.

  One working group participant has expressed discontent several
  times. In particular, this participant has expressed concern that
  his comments have not been addressed and also that he has
  not been given enough time to review. Part of that discussion can
  be seen at:
  https://mailarchive.ietf.org/arch/msg/lime/mxhWWvOUh3t_RGV-y4jx9SYBWQ4
  -> https://mailarchive.ietf.org/arch/msg/lime/C0jK4TZl1O7QM9mSF08CpNe0lSk
    -> https://mailarchive.ietf.org/arch/msg/lime/8NekB0HmACry-vjYM1h_S75WhAI
      -> https://mailarchive.ietf.org/arch/msg/lime/Y7W6EB9QUCvWZSdhUP4EhoTJ07c
      -> https://mailarchive.ietf.org/arch/msg/lime/kCCHIgU0Yj8A87Z6foE5koTa_5I
  -> https://mailarchive.ietf.org/arch/msg/lime/XWfZid1wp5JZImKNBxHDEtah6V0

  The WG held 4 "Editathon" interims in which we went comment-by-comment
  hosting a discussion and providing a disposition: https://datatracker.ietf.org/meeting/past#lime

  Further, both LIME WG Chairs believe there's been ample opportunity
  to share review and comments in multiple occasions, and that
  the document editors have responded timely and incorporated
  comments. In fact, multiple deadlines were given to this participant.
  Many of these deadlines were not respected, yet the WG and document
  editors waited and incorporated late comments just to get another
  deadline. This caused delay and broke the WG flow.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  None.

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

  YANG Doctor

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

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  All looks good.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  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.

  YANG Doctors Review.
  YANG Validator.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document presents a base YANG Data model for connectionless
  Operations Administration, and Maintenance(OAM) protocols.  It
  provides a technology-independent abstraction of key OAM constructs
  for connectionless protocols. 

Working Group Summary

  This document is the product of an early split of LIME YANG
  Models into Connection-Oriented (C-O) OAM Models and
  Connectionless (CL, i.e., this) OAM Models. Further, the
  CL Model is further split into the Model (this document)
  and the retrieval methods (adjunct document).

Document Quality

  There are plans of and implementations of this specification.
  This includes at least two different implementations of
  the model, as well as product and demos at Bits-n-Bytes.
  Further, there are plans to finalize the implementation of
  this specification.

  The WG was very active in reviewing these documents.
  Notably, participants of the BFD and MPLS WGs were
  special reviewers.

  Additionally, worth mentioning Carl Moberg's YANG
  Doctor review which resulted in many fixes and
  improvements.

Personnel

  Carlos Pignataro 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.

  This version of the document is ready to be sent to the responsible AD.

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

  No concerns regarding both breath and depth of reviews.

(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.

  YANG, with review taken place by YANG Doctors (Carl Moberg)

(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? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  None.

(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.

  Yes, during WG adoption.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  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? 

  WG Agreement.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No threat of appeal.

  One working group participant has expressed discontent several
  times. In particular, this participant has expressed concern that
  his comments have not been addressed and also that he has
  not been given enough time to review. Part of that discussion can
  be seen at:
  https://mailarchive.ietf.org/arch/msg/lime/mxhWWvOUh3t_RGV-y4jx9SYBWQ4
  -> https://mailarchive.ietf.org/arch/msg/lime/C0jK4TZl1O7QM9mSF08CpNe0lSk
    -> https://mailarchive.ietf.org/arch/msg/lime/8NekB0HmACry-vjYM1h_S75WhAI
      -> https://mailarchive.ietf.org/arch/msg/lime/Y7W6EB9QUCvWZSdhUP4EhoTJ07c
      -> https://mailarchive.ietf.org/arch/msg/lime/kCCHIgU0Yj8A87Z6foE5koTa_5I
  -> https://mailarchive.ietf.org/arch/msg/lime/XWfZid1wp5JZImKNBxHDEtah6V0

  The WG held 4 "Editathon" interims in which we went comment-by-comment
  hosting a discussion and providing a disposition: https://datatracker.ietf.org/meeting/past#lime

  Further, both LIME WG Chairs believe there's been ample opportunity
  to share review and comments in multiple occasions, and that
  the document editors have responded timely and incorporated
  comments.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  None.

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

  YANG Doctor

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

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  All looks good.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  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.

  YANG Doctors Review.
  YANG Validator.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document presents a base YANG Data model for connectionless
  Operations Administration, and Maintenance(OAM) protocols.  It
  provides a technology-independent abstraction of key OAM constructs
  for connectionless protocols. 

Working Group Summary

  This document is the product of an early split of LIME YANG
  Models into Connection-Oriented (C-O) OAM Models and
  Connectionless (CL, i.e., this) OAM Models. Further, the
  CL Model is further split into the Model (this document)
  and the retrieval methods (adjunct document).

Document Quality

  There are plans of and implementations of this specification.
  This includes at least two different implementations of
  the model, as well as product and demos at Bits-n-Bytes.
  Further, there are plans to finalize the implementation of
  this specification.

  The WG was very active in reviewing these documents.
  Notably, participants of the BFD and MPLS WGs were
  special reviewers.
  Additionally, worth mentioning Carl Moberg's YANG
  Doctor review which resulted in many fixes and
  improvements.

Personnel

  Carlos Pignataro 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.

  This version of the document is ready to be sent to the responsible AD.

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

  No concerns regarding both breath and depth of reviews.

(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.

  YANG, with review taken place by YANG Doctors (Carl Moberg)

(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? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  None.

(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.

  Yes, during WG adoption.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  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? 

  WG Agreement.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No threat of appeal.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  None.

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

  YANG Doctpr

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

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  All looks good.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  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.

  YANG Doctors Review.
  YANG Validator.

Changed consensus to Yes 6.3.  The PCRpt message

  A Path Computation LSP State Report message (also referred to as
  PCRpt message) is a PCEP message sent by a PCC to a PCE to report the
  current state or delegate control of an LSP.  The PCRpt message is
  extended to support the BU object.

  As per [STATEFUL-PCE], the format of the PCRpt message is as follows:

      <PCRpt Message> ::= <Common Header>
                          <state-report-list>

      where:

          <state-report-list> ::= <state-report> [<state-report-list>]

          <state-report> ::= [<SRP>]
                          <LSP>
                          <path>

          <path> ::= <intended_path><attribute-list>[<actual_path>]

  Where <attribute-list> is extended as per Section 6.2 for the BU
  object, and <intended_path> and <actual_path> are defined in
  [STATEFUL-PCE].

7.  Other Considerations

7.1.  Inter-domain Path Computation

  [RFC5441] describes the Backward Recursive PCE-Based Computation
  (BRPC) procedure to compute end to end optimized inter-domain path by
  cooperating PCEs.  The new metric types defined in this document can
  be applied to end to end path computation, in a similar manner to the
  existing IGP or TE metrics.  The new BU object defined in this
  document can be applied to end to end path computation, in a similar
  manner to a METRIC object with its B bit set to 1.

  All domains should have the same understanding of the METRIC (path
  delay variation etc.) and the BU object for end-to-end inter-domain
  path computation to make sense.  Otherwise, some form of metric
  normalization as described in [RFC5441] MUST be applied.

7.1.1.  Inter-AS Links

  The IGP in each neighbour domain can advertise its inter-domain TE
  link capabilities.  This has been described in [RFC5316] (IS-IS) and
  [RFC5392] (OSPF).  The network performance link properties are

Dhody, et al.          Expires December 26, 2016              [Page 19]
Internet-Draft                SERVICE-AWARE                    June 2016

  described in [RFC7471] and [RFC7810].  The same properties must be
  advertised using the mechanism described in [RFC5392] (OSPF) and
  [RFC5316] (IS-IS).

7.1.2.  Inter-Layer Path Computation

  [RFC5623] provides a framework for PCE-Based inter-layer MPLS and
  GMPLS Traffic Engineering.  Lower-layer LSPs that are advertised as
  TE links into the higher-layer network form a Virtual Network
  Topology (VNT).  The advertisement into the higher-layer network
  should include network performance link properties based on the end
  to end metric of the lower-layer LSP.  Note that the new metrics
  defined in this document are applied to end to end path computation,
  even though the path may cross multiple layers.

7.2.  Reoptimizing Paths

  [RFC6374] defines the measurement of loss, delay, and related metrics
  over LSPs.  A PCC can utilize these measurement techniques.  In case
  it detects a degradation of network performance parameters relative
  to the value of the constraint it gave when the path was set up, or
  relative to an implementation-specific threshold, it MAY ask the PCE
  to reoptimize the path by sending a PCReq with the R bit set in the
  RP object, as per [RFC5440].

  A PCC may also detect the degradation of an LSP without making any
  direct measurements, by monitoring the TED (as populated by the IGP)
  for changes in the network performance parameters of the links that
  carry its LSPs.  The PCC MAY issue a reoptimization request for any
  impacted LSPs.  For example, a PCC can monitor the link bandwidth
  utilization along the path by monitoring changes in the bandwidth
  utilization parameters of one or more links on the path in the TED.
  If the bandwidth utilization percentage of any of the links in the
  path changes to a value less than that required when the path was set
  up, or otherwise less than an implementation-specific threshold, then
  the PCC MAY issue an reoptimization request to a PCE.

  A stateful PCE can also determine which LSPs should be re-optimized
  based on network events or triggers from external monitoring systems.
  For example, when a particular link deteriorates and its loss
  increases, this can trigger the stateful PCE to automatically
  determine which LSP are impacted and should be reoptimized.

8.  IANA Considerations

Dhody, et al.          Expires December 26, 2016              [Page 20]
Internet-Draft                SERVICE-AWARE                    June 2016

8.1.  METRIC types

  IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
  at <http://www.iana.org/assignments/pcep>.  Within this registry IANA
  maintains one sub-registry for "METRIC object T field".  Six new
  metric types are defined in this document for the METRIC object
  (specified in [RFC5440]).

  IANA is requested to make the following allocations:

        Value      Description                        Reference
        ----------------------------------------------------------
        TBD1        Path Delay metric                  [This I.D.]
        TBD2        Path Delay Variation metric        [This I.D.]
        TBD3        Path Loss metric                  [This I.D.]
        TBD8        P2MP Path Delay metric            [This I.D.]
        TBD9        P2MP Path Delay variation metric  [This I.D.]
        TBD10      P2MP Path Loss metric              [This I.D.]

8.2.  New PCEP Object

  IANA maintains object class in the registry of PCEP Objects at the
  sub-registry "PCEP Objects".  One new allocation is requested as
  follows.

            Object Object    Name                  Reference
            Class  Type
            ---------------------------------------------------
            TBD4  1          BU                    [This I.D.]

8.3.  BU Object

  IANA is requested to create a new sub-registry to manage the
  codespace of the Type field of the BU Object.

  Codespace of the T field (BU Object)

            Type    Name                          Reference
            --------------------------------------------------
            1        LBU (Link Bandwidth            [This I.D.]
                    Utilization
            2        LRBU (Link Residual            [This I.D.]
                    Bandwidth Utilization

Dhody, et al.          Expires December 26, 2016              [Page 21]
Internet-Draft                SERVICE-AWARE                    June 2016

8.4.  OF Codes

  IANA maintains registry of Objective Function (described in
  [RFC5541]) at the sub-registry "Objective Function".  Three new
  Objective Functions have been defined in this document.

  IANA is requested to make the following allocations:

            Code    Name                          Reference
            Point
            --------------------------------------------------
            TBD5    Minimum Packet Loss Path      [This I.D.]
                    (MPLP)
            TBD6    Maximum Under-Utilized        [This I.D.]
                    Path (MUP)
            TBD7    Maximum Reserved              [This I.D.]
                    Under-Utilized Path (MRUP)

8.5.  New Error-Values

  IANA maintains a registry of Error-Types and Error-values for use in
  PCEP messages.  This is maintained as the "PCEP-ERROR Object Error
  Types and Values" sub-registry of the "Path Computation Element
  Protocol (PCEP) Numbers" registry.

  IANA is requested to make the following allocations -

  Two new Error-values are defined for the Error-Type "Not supported
  object" (type 4) and "Policy violation" (type 5).

      Error-Type    Meaning and error values          Reference
          4          Not supported object

                      Error-value=TBD11 Unsupported      [This I.D.]
                      network performance constraint

          5          Policy violation

                      Error-value=TBD12 Not allowed      [This I.D.]
                      network performance constraint

9.  Security Considerations

  This document defines new METRIC types, a new BU object, and new OF
  codes which does not add any new security concerns beyond those
  discussed in [RFC5440] and [RFC5541] in itself.  Some deployments may
  find the service aware information like delay and packet loss to be

Dhody, et al.          Expires December 26, 2016              [Page 22]
Internet-Draft                SERVICE-AWARE                    June 2016

  extra sensitive and thus should employ suitable PCEP security
  mechanisms like TCP-AO or [PCEPS].

10.  Manageability Considerations

10.1.  Control of Function and Policy

  The only configurable item is the support of the new constraints on a
  PCE which MAY be controlled by a policy module on individual basis.
  If the new constraint is not supported/allowed on a PCE, it MUST send
  a PCErr message accordingly.

10.2.  Information and Data Models

  [RFC7420] describes the PCEP MIB.  There are no new MIB Objects for
  this document.

10.3.  Liveness Detection and Monitoring

  The mechanisms defined in this document do not imply any new liveness
  detection and monitoring requirements in addition to those already
  listed in [RFC5440].

10.4.  Verify Correct Operations

  The mechanisms defined in this document do not imply any new
  operation verification requirements in addition to those already
  listed in [RFC5440].

10.5.  Requirements On Other Protocols

  The PCE requires the TED to be populated with network performance
  information like link latency, delay variation, packet loss, and
  utilized bandwidth.  This mechanism is described in [RFC7471] and
  [RFC7810].

10.6.  Impact On Network Operations

  The mechanisms defined in this document do not have any impact on
  network operations in addition to those already listed in [RFC5440].

11.  Acknowledgments

  We would like to thank Alia Atlas, John E Drake, David Ward, Young
  Lee, Venugopal Reddy, Reeja Paul, Sandeep Kumar Boina, Suresh Babu,
  Quintin Zhao, Chen Huaimo and Avantika for their useful comments and
  suggestions.

Dhody, et al.          Expires December 26, 2016              [Page 23]
Internet-Draft                SERVICE-AWARE                    June 2016

  Also the authors gratefully acknowledge reviews and feedback provided
  by Qin Wu, Alfred Morton and Paul Aitken during performance
  directorate review.

  Thanks to Jonathan Hardwick for shepherding this document and
  providing valuable comments.  His help in fixing the editorial and
  grammatical issues is also appreciated.

12.  References

12.1.  Normative References

  [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

  [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630,
              DOI 10.17487/RFC3630, September 2003,
              <http://www.rfc-editor.org/info/rfc3630>.

  [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, DOI 10.17487/RFC5305, October
              2008, <http://www.rfc-editor.org/info/rfc5305>.

  [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <http://www.rfc-editor.org/info/rfc5440>.

  [RFC5541]  Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
              Objective Functions in the Path Computation Element
              Communication Protocol (PCEP)", RFC 5541,
              DOI 10.17487/RFC5541, June 2009,
              <http://www.rfc-editor.org/info/rfc5541>.

  [RFC7471]  Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
              Previdi, "OSPF Traffic Engineering (TE) Metric
              Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
              <http://www.rfc-editor.org/info/rfc7471>.

  [RFC7810]  Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and
              Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions",
              RFC 7810, DOI 10.17487/RFC7810, May 2016,
              <http://www.rfc-editor.org/info/rfc7810>.

Dhody, et al.          Expires December 26, 2016              [Page 24]
Internet-Draft                SERVICE-AWARE                    June 2016

  [STATEFUL-PCE]
              Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
              Extensions for Stateful PCE", draft-ietf-pce-stateful-
              pce-14 (work in progress), March 2016.

12.2.  Informative References

  [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <http://www.rfc-editor.org/info/rfc4655>.

  [RFC5316]  Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
              Support of Inter-Autonomous System (AS) MPLS and GMPLS
              Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
              December 2008, <http://www.rfc-editor.org/info/rfc5316>.

  [RFC5392]  Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
              Support of Inter-Autonomous System (AS) MPLS and GMPLS
              Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392,
              January 2009, <http://www.rfc-editor.org/info/rfc5392>.

  [RFC5441]  Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
              "A Backward-Recursive PCE-Based Computation (BRPC)
              Procedure to Compute Shortest Constrained Inter-Domain
              Traffic Engineering Label Switched Paths", RFC 5441,
              DOI 10.17487/RFC5441, April 2009,
              <http://www.rfc-editor.org/info/rfc5441>.

  [RFC5623]  Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
              "Framework for PCE-Based Inter-Layer MPLS and GMPLS
              Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623,
              September 2009, <http://www.rfc-editor.org/info/rfc5623>.

  [RFC6049]  Morton, A. and E. Stephan, "Spatial Composition of
              Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011,
              <http://www.rfc-editor.org/info/rfc6049>.

  [RFC6374]  Frost, D. and S. Bryant, &from Unknown