Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core
draft-ietf-opes-ocp-core-05

[Note]: 'RFC Editor NOTE:
(in 3.1)
OLD: data = size ":" OCTET                ; n == size NEW: data = size ":" *OCTET      ; exactly size octets
' added by Amy Vezza

[Note]: 'RFC Editor NOTE:
(in 3.1)
OLD:

data = size ":" OCTET                 ; n == size

NEW:

data = size ":" *OCTET      ; exactly size octets
' added by Ted Hardie

[Ballot comment]
data = size ":" OCTET                ; n == size

is an ABNF syntax error.  I don't think there's a way to represent what you want using the ABNF syntax.

You could do

data = size ":" *OCTET      ; exactly size octets

so that the ABNF parses, and is more permissive than the grammar actually wants, and then the comment describes the further limitation that it must be exactly size octets.

[Ballot comment]
data = size ":" OCTET                ; n == size

is an ABNF syntax error.  I don't think there's a way to represent what you want using the ABNF syntax.

[Ballot discuss]
This opening for future feature extension is too big:

  OCP extensions MAY change any normative requirement documented in
  this specification, including OCP message format, except for the
  following rule: OCP extensions MUST require that changes to normative
  parts of OCP Core are negotiated prior to taking effect.

The syntax and processing of NO/NR have normative requirement, so "any" is
not really all inclusive.  And many of the MUSTs are about the negotiation process.
If the negotiation process is modified, deadlocks/liveness issues arise.

Perhaps clearer language is  "An OCP extension specification MAY change
normative features and requirements documented in this specification, including
OCP message formats.  It SHOULD provide discussion of the requirement for
this change specific to the extension, and it MUST require that changes to
normative parts of OCP Core are negotiated prior to taking effect.  Any proposed
changes in the negotiation protocol itself MUST be part of a revision of OCP."

[Ballot discuss]
This opening for future feature extension is too big:

  OCP extensions MAY change any normative requirement documented in
  this specification, including OCP message format, except for the
  following rule: OCP extensions MUST require that changes to normative
  parts of OCP Core are negotiated prior to taking effect.

The syntax and processing of NO/NR have normative requirement, so "any" is
not really all inclusive.  And many of the MUSTs are about the negotiation process.
If the negotiation process is modified, deadlocks/liveness issues arise.

Perhaps clearer language is  "An OCP extension specification MAY change
normative features and requirements documented in this specification, including
OCP message formats.  It SHOULD provide discussion of the requirement for
this change specific to the extension, and it MUST require that changes to
normative parts of OCP Core are negotiated prior to taking effect.  Any proposed
changes in the negotiation protocol itself MUST be part of a revision of OCP."

Is the silent model for failure of

[Ballot discuss]
I'm very concerned that this protocol is underspecified.  The scope allowed for vendor extensions seems to be quite large.  (In that vein, I would think that there should be an IANA registry for message names, plus a 2434-type statement on how new names are added to that registry.)

The specific cause for my DISCUSS, though, is encryption:  it isn't clear to me how it is turned on, given the asynchronous nature of these messages.  At some point, both sides have to stop sending OCP messages and start, say, a TLS negotiation, after which both can resume their chatter.  Suppose the following dialog takes place (this is adapted from the text on p. 22):

  P: NO ({"32:ocp://example/encryption/strongA"},
      {"32:ocp://example/encryption/strongB"})
      Offer-Pending: true
      ;
  S: NR
      Offer-Pending: true
      ;
  S: NO ({"32:ocp://example/encryption/strongA"},
      {"32:ocp://example/encryption/strongB"})
      Offer-Pending: true
      ;

If I understand things correctly, at this point both sides want to give more offers.  When does the TLS negotiation happen?