IETF conflict review for draft-boucadair-connectivity-provisioning-profile
conflict-review-boucadair-connectivity-provisioning-profile-01

The following approval message was sent
From: The IESG
To: "Nevil Brownlee" , draft-boucadair-connectivity-provisioning-profile@tools.ietf.org
Cc: The IESG , , 
Subject: Results of IETF-conflict review for draft-boucadair-connectivity-provisioning-profile-05

The IESG has completed a review of
draft-boucadair-connectivity-provisioning-profile-05 consistent with
RFC5742.


The IESG has no problem with the publication of 'IP Connectivity
Provisioning Profile (CPP)'
as an
Informational RFC.


The IESG has concluded that there is no conflict between this document
and IETF work.


The IESG would also like the RFC-Editor to review the comments in the
datatracker related to this document and determine whether or not they
merit incorporation into the document. Comments may exist in both the
ballot and the history log.

The IESG review is documented at:
http://datatracker.ietf.org/doc/conflict-review-boucadair-connectivity-provisioning-profile/

A URL of the reviewed Internet Draft is:
http://datatracker.ietf.org/doc/draft-boucadair-connectivity-provisioning-profile/

The process for such documents is described at
http://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
I am curious if there is any concerns with a potential relationship in the OAM side of the IETF.  This document reads like the start of a data model (i.e., YANG).

[Ballot comment]

Comments for the ISE and authors from Stewart Bryant, who was kind enough to review the draft:

This is a useful and well written document and could be published
as is. However I do have some comments that you may wish to consider.

In terms of connectivity you have characterized an IP unicast service,
but in the general case there is multicast and there are a variety
of LAN and pseudowire connectivity services that require a
connectivity provisioning profile. There is considerable overlap
between the IP and non-IP profiles, so you may wish to extend the
work here to cover that case, or you could reasonably leave it for the
future. If you omit non-IP services you might wish to amend the
title accordingly. The various multipoint service needs a specialist
review and I suspect will increase the complexity of the profile.
Again you might wish to reflect a limited scope in the title
and introductory material.


This is fine as an independent stream document, but I wonder
if it (or a development of this text) needs to be considered for
publication in one of the OPS WGs or as input to I2RS.

In terms of the various performance parameters delay, loss,
availability it occurs to me that you need to be specifying
a mask rather than point parameters. Now the state of the
art in technical metrics may not be sufficiently developed
buy I would be surprised if contracts were no written in those
terms.

===
Minor typo:
  The CPP reference architectures are depicted in
  Figure 3Figure 4Figure 5.

===

  These nodes should be unambiguously identified (e.g., using a unique
  Service_identifier).  For each Customer Node, a border link or a node
  that belongs to the domain that connects the Customer Nodes should be
  identified.

Is the above sufficient? I can imagine that you will need to consider
other parameters such as VLANs, MAC addresses etc.

===

3.4.  Availability Guarantees

  o  Enable IP Fast Reroute features (e.g., [RFC5286]).

It occurs to me that there are no well developed metrics for FRR in the IETF
an perhaps there need to be for these types a specification.

===
In view of recent global events, at some stage this work will need to be
extended to consider privacy requirements and geographic routing restrictions.

===

3.9.  Flow Identification

This is a section that could certainly do with some privacy considerations.

===

3.10.  Routing & Forwarding

I would expect that the profile needed to contain some indication
of how reachability/topology information was exchanged between the
provider network and the client network.

In a pure OTT network this is not needed, but where the provider
network is providing an IP service BGP is a consideration.

===

3.13.  Notifications

Does NETCONF/YANG need to be called up?

===

6.  Security Considerations

You probably need to consider privacy in this section.
===

Two typos in the following
  "CPP documents should be protected againts illegitame modifications"


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