Session Peering Provisioning Framework (SPPF)
RFC 7877

Approval announcement
Draft of message to be sent after approval:

From: The IESG <>
To: IETF-Announce <>
Cc: RFC Editor <>,
    drinks mailing list <>,
    drinks chair <>
Subject: Protocol Action: 'Session Peering Provisioning Framework (SPPF)' to Proposed Standard (draft-ietf-drinks-spp-framework-12.txt)

The IESG has approved the following document:
- 'Session Peering Provisioning Framework (SPPF)'
  (draft-ietf-drinks-spp-framework-12.txt) as Proposed Standard

This document is the product of the Data for Reachability of
Inter/tra-NetworK SIP Working Group.

The IESG contact persons are Barry Leiba, Ben Campbell and Alissa Cooper.

A URL of this Internet Draft is:

Technical Summary:

  This document specifies the data model and the overall structure for
  a framework to provision session establishment data into Session Data
  Registries and SIP Service Provider data stores. The framework is
  called the Session Peering Provisioning Framework (SPPF). The
  provisioned data is typically used by network elements
  for session

Working Group Summary:

  Given the small size of the working group, particularly towards the 
  end of the document creation process, most of the active WG 
  participants were also part of the Design Team. All issues were 
  discussed extensively in the Design Team to achieve strong consensus. 
  Since the design team represented a vast majority of the active WG 
  participants, the shepherd believes that there is strong concensus by 
  the WG behind the documents.

  During the design process a complete restructuring of the set of 
  documents was performed, in order for the protocol to become transfer-
  agnostic. Specifically, this was in consideration of an additional
  future REST-based transport specification.

Document Quality:

  A prototype-level implementation was performed by WG participants, 
  involving programmers who were not involved in the protocol 
  specification. Lessons learned from that implementation were fed back 
  into the protocol specification. Furthermore, the Design Team that 
  created the documents included several potential implementers with 
  concrete plans to use the protocol in their networks.

  The design team was in substantive favour of using SOAP as transfer 
  protocol, since this is what target networks currently use for 
  provisioning. However, due to concerns brought to the attention of the 
  group from within as well as outside the working group, significant 
  efforts were undertaken to segregate core („framework“) definitions 
  from the actual transport definition, and hence allow ing for the 
  future definitions of other transport protocols.

  Alexander Mayrhofer serves as the Document Shepherd, and Ben Campbell serves as the responsible AD.

RFC Editor Note

Please update the title of section 4:
       4.  Transport Substrate Protocol Requirements
       4.  Substrate Protocol Requirements