OCP:%20OPES%20callout%20protocol%20draft-ietf-opes-ocp-core-02

1
OCP OPES callout protocoldraft-ietf-opes-ocp-cor
e-02

• Alex Rousskov
• (rousskov_at_measurement-factory.com)

2
Outline

• Brief OCP overview
• OCP scope, principles, transport
• Progress since last meeting
• Current and future
• Latest status, implementation efforts
• Considerations/Issues
• QA

3
What is OCP?
4
OCP Building Blocks
5

• Progress From Last Meeting

• Major protocol mechanisms revised and documented
• Several protocol bugs fixed
• Several non-essential features removed
• Numerous editorial and presentational changes
• Change log appendix has detailed progress timeline

6

• Considerations/Issues Slide 1

• Agent authentication negotiation
• Should it be documented in the Core?
• Should it be required?
• Do we need a separate OCP Security draft
• Several standard ways to do authentication
• Do it in Appendix
• But Appendix introduce IANA considerations
• Same considerations for Encryption

7

• Considerations/Issues Slide 2

• Should OCP Core contain a full adaptation
  example?
• It would have to be application-specific
• Should we solicit IETF review before going into
  last call?
• OCP Core documents application message
  identifiers (am-ids) in various contexts
• There are original and adapted am-ids
• HTTP does not use any am-ids
• Support SMTP and other protocols that may have
  multiple adapted data flows for a single
  original dataflow
• Do not know whether OCP Core has enough meat to
  accommodate SMTP and similar needs
• Keep it or not?

8

• Conclusions

• Document is stable
• Close to WGLC
• Feedback from higher authority is need
• Thanks to Sally for her input

9
QA
10
Backup
11

• OCP Transport

• Require reliable ordered delivery of messages
• Assume TCP/IP
• Do not discourage other protocols
• This lazy approach adopted from HTTP RFC 2616
• Encryption
• Supports encryption of connections via optional
  (negotiated) transport encryption mechanisms

12

• Considerations/Issues Slide 3

• Protocol Element Type Declaration Mnemonic
  (PETDM) does not allow extending message
  semantics without message renaming because
• Message name is the type name, and to extend
  semantics one must change the type
• For example, an OCP extension cannot add a new
  parameter to the message without renaming it
• Keep it or find a way to fix it?