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

The following approval message was sent
From: The IESG
To: draft-boucadair-connectivity-provisioning-protocol@ietf.org,
    Adrian Farrel ,
    rfc-ise@rfc-editor.org
Cc: iana@iana.org,
    The IESG ,
    IETF-Announce
Subject: Results of IETF-conflict review for draft-boucadair-connectivity-provisioning-protocol-22

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

The IESG has no problem with the publication of 'Dynamic Service Negotiation'
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 Independent Submissions 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:
https://datatracker.ietf.org/doc/conflict-review-boucadair-connectivity-provisioning-protocol/

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

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

Thank you,

The IESG Secretary

[Ballot comment]
conflict review text is good; here are some minor comments on the draft itself.

Section 4

  interactions.  Since the frozen model can be seen as a special case
  of the negotiation-based model, not only 'yes/no' answers but also
  counter-proposals may be offered by the Provider in response to

nit: this doesn't seem to be a causal relationship, just independently
true facts.

Section 8.1

  CPNP is a client/server protocol that can run over any transport
  protocol.  Yet, UDP is the default transport mode secured with
  Datagram Transport Layer Security (DTLS) [RFC6347].  No permanent

It might be worth a reference to RFC 6125 and discussion of what name
type to look for in server certificate validation, even if discovery of
the server name/URI is out of scope.

Section 13

AKM is never used in the acronym form; is it necessary to note the
acronym?

Is there a cut/paste attack where order identifiers generated by
client/server can be swapped around?  Perhaps both parties should
enforce consistency of both identifiers...

  The Nonce and the Transaction ID attributes provide sufficient
  randomness and can effectively tolerate attacks raised by off-line
  adversaries, who do not have the capability of eavesdropping and

nit: I think "off-path" is more common than "off-line" for this
property.