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

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

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"
 

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