Shepherd writeup
rfc8921-22

draft-boucadair-connectivity-provisioning-protocol has been submitted to
the ISE for publication as an Informational RFC on the Independent
Submissions Stream.

As can be seen from the version number, this document has been worked on
quite a lot since the first version was posted in 2013. Many of the
revisions were "keep-alive" postings, but a lot of work was also done
over the years.

The document specifies a protocol that can be used between a customer
and a network provider to discuss the available connectivity services
and to request provision of those services.

The document references several pieces of related work, particularly
RFC 8309 and various YANG models for the delivery of services.

Along the way, this document was reviewed for the ISE by Luis Contreras
and by an expert from the OPS Area who requested to remain anonymous.
The ISE also provided reviews - the details of all shown below.

The concern previously raised by the IESG about protocol specifications
that use BCP14 language being mistaken by readers for IETF 
specifications is addressed as previously suggested by an AD with the
inclusion of the following text:

   Note that this document is not on the IETF standards track.  However,
   a conformant implementation is supposed to adhere to the specified
   behavior for security and interoperability reasons.  This document
   uses BCP 14 to describe that necessary behavior.



== Luis Contreras ==

Section 1

It would be convenient to add a reference for all the solutions mentioned
here (by now, only few of them have a reference)

--

Section 5 final paragraph

A numbered bullet would be convenient also for this paragraph

--

Section 6 bullet 1

It would be probably convenient to say that it is open the way in which
the client associates with the servers (static configuration, discovery,
etc).

--

Section 7 para 4

Probably good to reformulate; suggestion -> "… assume that the Customer
is the only one that can call for an agreement."

--

Section 7 final para

New versions are considered/expected? If not, probably it is better to
reformulate; suggestion: "Means of how a client retrieves a list of
active/agreed offers are not defined".

--

Section 8.1

What could be the dynamic means? Can you provide an example?

--

Section 8.1  CPNP_PORT

What is the intended port? Should it be standardized / assigned by IANA?

--

Figure 5

Where would it be here the interface with the CPNP client?

--

Section 8.2 bullet 2

"The CPNP methods which can be automatically
 handled by the server or they are subject to one or several
 validation administrative checks can be configured on the server."

I don't understand this sentence.

--

8.3

It could be required to have an identifier for both client and provider
in order to handle the transactions in a unique manner. A client can
maintain parallel sessions simultaneously with different providers, and
vice versa.

--

8.3

Who stores these session entries? Is it the same information kept /
maintained in both client and server?

--

8.3

s/5-uplet/5-tuple/

--

8.3 Transaction-ID

The transaction ID should be common.

Better refer to 8.4. Section 9.1.3 can be removed and integrated in 8.4
if some text has to be maintained.

--

8.5

It should be clarified the relationship among these timers and the
timers in sections 9.1.x.

--

8.5

Should be understood that this TIMER applies to both client and servers?

--

8.6 ACCEPT

This could happen if there are not resources available. This will depend
on the time passed between the offer and the provision.

--

8.6 ACK

This is also sent after a PROCESSING operation

--

Figure 6

These PROCESSING messages are not accompanied by ACK messages from the
client. Is that correct?

--

8.8

Maybe this can be reformulated by saying that is deployment specific and
providing this as a potential example.

--

8.9

This can produce a loop. A given client can negotiate with Provider A
and Provider B. In case Provider B required from resources in Provider
A, then in case of some failure in Provider A the client could be in
troubles. Thus it would be required to indicate Provider B that it
cannot use resources from Provider A (for instance by leveraging on the
AS Number in provider's description as per 9.1.10.2)

--

8.10

Add billing

--

Figure 8

I miss from here the ACTIVE state and the Update message.

Should not be a WAIT state for representing something between CANCELLED
and Created??

--

8.10.2 AcceptAck

This implies that an ACK is sent but also received.

--

Figure 9 AcceptAck

The procedure covers the negotiation but not the provisioning itself.
After provisioning it would be necessary to confirm that the request is
ready for service. Is that out of scope?

--

Figure 9

The UPDATE operation is missing.

--

Figure 9

The right part of the figure should be the same as in Fig. 8. However
between ChildCreated and ChildPQOSent there is no AwaitingProcessing.

--

Figure 9

It would be good to distinguish the direction of the operations
considered (C->S or S->C) since sometimes is operations in both
directions are considered explicitly while some other operations are not
considered nor detailed.

--

Section 9

s/favorite/preferred/ ?

--

9.1.2

This is because it has been initiated by the client, right? If so, maybe
it is good to clarify. In case it is not included, is it set to 0,
nothing is sent, ...?

--

9.1.3

This section does not provide meaningful information, better to remove
to avoid go and back between sections.

--

9.1.5

It is not clear the purpose of this parameter from the description.

--

9.1.6

What are the timing units? Min, s, ms, , ...?

--

9.1.7

It is not the same as RESPONSE_TIMER but only for OFFER? Is it not
redundant?

--

9.1.7

Then OFFER_TIME makes sense when OFFER_TIME > RESPONSE_TIME, right? If
OFFER_TIME < RESPONSE_TIME, it can be ignored, or simply not set as
attribute, right?

--

9.1.9.1 <Customer Node>

This implies that the Client has full visibility of the provider's
network, except of this refers only to Client's information. But in that
case, how the provider infers what should be connected?

--

9.1.10.3

It is not clear the purpose of these options with respect the operations
in 9.2.

--

9.1.10.3 <Negotiation Options>

What could be the options to consider?

--

9.2

Afterwards, for the messages there is reference to METHOD CODE. Better
to provide a uniform terminology.

--

9.2.1 <METHOD_CODE>

What is the intended value? Is it the same of the list in 9.2? Maybe
good to indicate that fact.

--

9.2.1 order identifier

What is this? Is it the CUSTOMER_AGREEMENT_IDENTIFIER?

--

9.2.1 PQOSent

... in the client side.

--

9.2.2 VERSION

What is this version? Version of CPNP protocol? If so, what is the
intended version for this specification? This comment applies to all the
messages in 9.2.

--

9.2.2

In all these interactions, is it incremented the Sequence_Number?

--

Figure 11 MoreTime

What is the interpretation of this time? Is it incremental to the
original one, does it represent an absolute value?

--

9.2.5

This could be a possible way of DoS attack.

--

9.2.6 bullet 3

This will be the Agreed CPD in 8.7, right?

--

9.2.6 bullet 4

Also in the case of WITHDRAW message.

--

9.2.7

Why the PROVIDER_AGREEMENT_ID is not included here? In the DECLINE
message it is included.

--

9.2.7

This could be a possible way of DoS attack.

--

9.2.8

This could be a possible way of DoS attack.

--

9.2.9 <REQUESTED_CONNECTIVITY_PROVISIONING_DOCUMENT>

Should be added the AGREED_CPD?

--

9.2.9

In the DECLINE the Transaction ID is used to identify the Order, but
here it is not the case. Does it actually make sense?

--

9.2.9

This could be a possible way of DoS attack.

--

9.2.9 FAIL

But, is this done without performing the update? Then, how it can be
related with the already existing service?

--

9.2.9 OFFER message

Then, the OFFER is only sent if the Update service can be done? This
implies that the Update is not negotiated at all.

--

9.2.10 bullets 2 and 3

This is the first time that something s said about Authorization or
Authentication. Either Authorization or Authentication should happen for
the client before being able to request services.

--

9.2.10 bullet 5

Maybe this could be reformulated: "... there are not enough resources,
e.g. capacity".

--

9.2.10 bullet 6

What does it mean?

--

10.2

Are not validated neither the CANCEL nor FAIL messages? Because of the
implications of those messages, it could be good to validate also them.

--

10.2 ACCEPT

Linked to PROCESSING in Fig. 9.

--

10.2 UPDATE

This state is not in Fig. 9.

--

10.2 WITHDRAW

Same as before.

--

11.1.1 "(corrected)"

With the error messages are they are now, there is no way of
understanding what has failed

--

11.1.1 "ACCEPT message"

How many retransmissions?

--

11.1.2

Cannot represent this a security issue? Would it not be better to ignore
it after some number of retransmissions?

--

11.2.1

That is, despite the FAIL indication the server can yet send an offer,
that will be discarded if it is not OK for the Client. However, to be
consistent, the Client should send a DECLINE instead.

--

11.2.1 "Offer Sent"

In Fig. 9 is "OfferProposed"

Are these states similar to the ones in Fig. 8 and 9? It could be
convenient to represent them also here, being the same or not, to make
it more easy for the reader.

--

11.2.1  CANCEL

Should it be WITHDRAW, right? If not, it has to be mentioned that
CANCLE / DECLINE happen before of the completion of the order.

--

11.2.2

It would be convenient to indicate what code is it.

--

11.2.2

What is the intention of sending one empty CPD? Maybe the protocol can
be alleviated by not sending anything.

--

11.2.3

Transaction ID also?

--

11.3

For retransmitted messages, the sequence number is incremented? What
happens if two messages arrive with the same sequence number?

Are the sequence numbers different

Sequence number is in the registry?

--

11.4

"no additional feedback" Does it mean that the ACK messages are not
retransmitted?

"In addition, if the partner receives a re-sent last incoming packet,
 the partner can also send out the answer to the incoming packet with
 a limited frequency.  If no answer was generated at the moment, the
 partner needs to generate a PROCESSING message as the answer."
What does this mean?

--

12.2

s/&/and/

== Anonymous ==

My feeling the protocol is overdesigned or over engineered to address
the problem space.

CPP defined in RFC7297 is a useful profile and can be used to document
various different sevice parameters assocaiated connectivity service and
put them into different category.

CPNP protocol defined in this document provides service parameter
negotiation method. If my understanding is correct, the essence of CPNP
is application layer policy control protocol, which is similar to COPS
(defined in RFC2748) and other policy related protocol.

I am not convinced why the existing protocols are not sufficient to
support service parameter negotation, e.g., NETCONF provides capability
negotation mechanism, YANG-Push Notification Capabilities draft provides
a mechanism to advertise various capability. NETCONF+ customer facing
service model(e.g.,L3SM) can also be used to negotiate various different
service parameters.COPS can also be extended to support various
different service parameters negotation.

In addition, NETCONF provides complete transaction semantics and support
Three-phase transaction. Why not leverage exsiting protocol to do this?

I didn't see this document list NETCONF or RESTCONF as existing
technology which is, in my opinion, unfair,:-).

In addition, section 11.4 proposed define Message-Retransmission
mechanism at new protocol level, I am wondering which transport protocol
is used by CPNP protocol for reliable exchange of messages? If it is
TCP, why not reuse TCP retransmission mechanism?

== ISE Initial Review ==

Has it been implemented? What is the purpose of publication? Some
comments about this in the Introduction would be valuable.

---

7297 should be a normative reference

--

Section 1

   It is out of the scope of this
   document to elaborate on the differences between CPNP and the
   aforementioned proposals.

That is fair enough, but it does raise the question of why you feel the
need for another protocol in this space. Can you add something about
that?  For example: "Careful examintion of these other proposals
revealed in each case certain deficiencies that were easier to address
through the creation of a new protocol than through modificaitons to the
existing protocols."

---

I am somewhat sceptical of including "cost" in this work. I first
noticed this in section 3 where you have "request for quotation" and
then in 9.1.10.3 where you give the ability to request cost and respond
with the cost.

But 9.1.10.3 seemed very uninformative, and I ownder whether the whole
issue of cost and business models for services is just too complicated
to be parameterised. I'd note that TMF have been trying to achieve this
for around 30 years and have not made any meaningful progress.

---

Does 8.10 need to talk about persistence of state?

Since you are not session oriented, one might assume that state persists
indefinitely, but two things:

- When a message is unresponded (or not followed up). I know 8.5 talks
  about timers, but it is unclear what is subject to timers. Can a
  customer think about an offer without breaking the protocol? If the
  customer issues requests to a number of service providers, it may
  need to get all of the responses before it chooses.

- When a computer (customer or service provider side) restarts, what
  happens to state that was in progress? Do we assume that the timers
  handle all of this? Probabaly would work OK, but must recall that
  either side might wake up to receive a message relating to a
  transaction it knows nothing about. Is that Nonce failure in 9.1.5?

== ISE Final Review ==

The IESG has been pushing back on Independent Stream documents to make
completely clear that, where they are protocol specifications, they do
not appear to imply that they are IETF protocol specifications just
because they show up in an RFC.

On the whole, I don't think there is anything to worry about with your
document, but one way we have recently handled this would be to add a
paragraph to the end of section 2 as:

OLD
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119][RFC8174] when, and only when, they appear in all
   capitals, as shown here.
NEW
   Note that this document is not on the IETF standards track.  However,
   a conformant implementation is supposed to adhere to the specified
   behavior for security and interoperability reasons.  This text uses
   BCP 14 to describe that necessary behavior.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119][RFC8174] when, and only when, they appear in all
   capitals, as shown here.

---

I would have been happier if you had made mention of RFC 8299 and RFC
8466 just by way of contrast and reference to relevant IETF work.

You do reference draft-ietf-opsawg-l3sm-l3nm, and that's good. What
about the corresponding draft-barguil-opsawg-l2sm-l2nm?

Not essential to make any changes for this, but think about it.

---

Section 8.2 mentions the "Network Provisioning Manager", but there is no
real discussion of this external component. Do you have a reference you
can point to?

---

Section 8.8 made me wonder about whether the Client is made aware of the
fact that the Server is has contacted (Server A) is using resources from
another network (via Server B). Are there regulatory as well as
contractual reasons why this might be important?

---

Section 2 is the only place that makes any mention of contracts. I think
it is probably important to say whether you expect CPNP to form part of
contractual agreements or not. If so, then there are some important
security concerns.

---

9.1.10.1

   <Customer Description> ::= [<NAME>] [<Contact Information>]
   <Contact Information> ::=  [<EMAIL_ADDRESS>] [<POSTAL_ADDRESS>]
                              [<TELEPHONE_NUMBER> ...]

This seems to allow <Customer Description> and <Contact Information> to
be empty. Is that the intention?

Similarly <Provider Description> and <Negotiation Options> in subsequent
section.

It's OK if that is the intention.

---

The tables in 10.1 and 10.2 would look better if the text was left-
justified so that the spaces are compressed.

---

There are two mentions of timestamps for logging. Do you need to talk
about formats and bases for them, or is it OK that they will be in local
form?
Back