Subject: [drinks] Comments to the WGLC on SPPF document

From: David Schwartz <[email-masked]>
Date: Fri, 21 Sep 2012 16:55:10 +0200

Almost ALL of these comments are typo/style and general "nit" comments.

Note that for ease of change tracking I added ">> text <<" to indicate the need for removal of some text and "<<  text >>" to indicate the need to add some text.

*************************************************************************************************************************************

Abstract

old:
"The provisioned data is typically used by network elements for session >>peering<<"

new:
"The provisioned data is typically used by network elements for session <<establishment>>"

1. Introduction

old:
"Service providers and enterprises use registries to make session
routing decisions for Voice over IP, SMS and MMS traffic exchanges…"

new:
"Service providers and enterprises use <<routing databases know as>> registries to make session
routing decisions for Voice over IP, SMS and MMS traffic exchanges…"

old:
"Three types of provisioning flows have been described in the use case
document: client to registry >>provisioning<<, registry to local data
repository and registry to registry."

new:
"Three types of provisioning flows have been described in the use case
document: client to registry, registry to local data
repository and registry to registry."

old:
"This document addresses client
to registry aspect to fulfill the need to provision Session
Establishment Data (SED)."

new:
"This document addresses the client
to registry <<flow>> enabling the provisioning of Session
Establishment Data (SED)."

old:
"The data provisioned for session establishment is typically used by
various downstream SIP signaling systems to route a call to the next
hop associated with the called domain.  These systems typically use a
local data store ("Local Data Repository") as their source of session
routing information."

new:
"The data provisioned for session establishment is <<known as Session Establishment Data or SED and is>> typically used by various downstream SIP signaling systems to route a call to the next
hop associated with the called domain."

old:
"Subsequently, a registry may distribute the provisioned data into
local data repositories, used for lookup queries (identifier -> URI)
or for lookup and location resolution (identifier -> URI -> ingress
SBE of terminating SSP).  In some cases, the registry may
additionally offer a central query resolution service (not shown in
the above figure)."

new:
"Subsequently, a registry may distribute the provisioned data into
local data repositories <<or may additionally offer a central query
resolution service (not shown in the above figure) for query purposes.>>"

old:
"Transport requirements are provided in this document to help with the
selection of the optimum transport mechanism.  The SPP Protocol over
SOAP document identifies a protocol for SPPF that uses SOAP/HTTP as
the transport mechanism."

new:
"Transport requirements are provided in this document to help with the
selection of the optimum transport mechanism."
/* this second sentence creates a dependency on the SOAP document so imho it should be removed */

old
"Section 5 describes the base framework data structures, the
        generic response types that MUST be supported by a conforming
        "protocol" specification, and the basic object type most first
        class objects extend from;"
new:
"Section 5 describes the base framework data structures, the
        generic response types that MUST be supported by a conforming
        <<transport>> "protocol" specification, and the basic object type most first
        class objects extend from;"

old:
"   o    Section 6 detailed description of the data model object
        specifications;"

new:
"   o    Section 6 <<provides a>> detailed description of the data model object
        specifications;

<<   o    Section 7 describes the operations that are supported by the data model

     o    Sections 9 - 11 discuss security, internationalization and IANA considerations >>"

2. Terminology

old:
"SPDP: Session Peering Distribution Protocol, the protocol used to
      distribute data to Local Data Repository (see arrow labeled "2."
      in Figure 1 of [RFC6461])."

new:
/* remove as this is not really discussed anywhere in the document */

old:
"Client:   An application that >>supports an SPPF client<<; it is
      sometimes referred to as a "registry client"."
new:
"Client:   <<In the context of SPPF, this is>>
      an application that <<initiates a provisioning request>>; it is
      sometimes referred to as a "registry client".

Server:   <<In the context of SPPF, this is>>
      an application that receives a provisioning request and responds
      accordingly. The server typically operates a master database of
      Session Establishment Data (SED) for one or more Registrants. In
      the context of SPPF, the provisioning server is referred to as
      a Registry.

Registry: a provisioning server."

3. Framework High Level Design

old:
"The data model is defined along with all the objects manipulated
by >>the protocol<< and their relationships."

new:
"The data model is defined along with all the objects manipulated
by <<a conforming tranport>> protocol and their relationships."

3.1. Framework Data Model

old:
"The data model illustrated and described in Figure 2 defines the
logical objects and the relationships between these objects >>that the
SPPF protocol supports<<."

new:
"The data model illustrated and described in Figure 2 defines the
logical objects and the relationships between these objects supported
by SPPF."

old:
"SPPF defines >>the<< protocol operations through
which an SPPF client populates a registry with these logical objects.
Various clients belonging to different registrars may >>use the
protocol for populating the registry's data<<."

new:
"SPPF defines protocol operations through
which an SPPF client populates a registry with these logical objects.
Various clients belonging to different registrars may provision data
into the registry using a conforming transport protocol implementing
these operations."

old:
in figure, the Public Identifier has an element called "sedRecRef" - this needs to be removed

new:
the TN element needs to have this element

5.1.  Basic Object Type and Organization Identifiers

old:
"The identifiers used for registrants (rant), registrars (rar), and
peering organizations (peeringOrg) are instances of OrgIdType."

new:
The identifiers used for registrants (rant) and registrars (rar) are instances of OrgIdType.
/* no need to introduce peeringOrg over here - it just serves to confuse. Move the peeringOrg
   comment to where its mentioned */

5.2.  Various Object Key Types

old:
">>In addition,<< an object's unique identity is required to Delete or Get
the details of an object."

new:
"<<Note that>> an object's unique identity is required to Delete or Get
the details of an object."

old:
\""Name" attributes that are used as components of object key types
MUST be treated case insensitive."

new:
\""Name" attributes that are used as components of object key types
MUST be treated <<as>> case insensitive."

5.2.2.  Derived Object Key Types

old:
"and defined in there own abstract key types.  Because these object
key types are abstract, these MUST be specified in a concrete form in
any conforming SPPF "protocol" specification."

new:
"and defined in there own abstract key types.  Because these object
key types are abstract, these MUST be specified in a concrete form in
any SPPF conforming <<transport>> protocol specification."

old:
The >>.<<PubIdKeyType is used in Delete and Get operations on a
Public Identifier object.

new:
The PubIdKeyType is used in Delete and Get operations on a
Public Identifier object.

5.3.  Response Message Types

old:
"This section contains the listing of response types that MUST be
defined by the conforming "protocol" specification and implemented by
a conforming SPPF server."

new:
"This section contains the listing of response types that MUST be
defined by the <<SPPF conforming transport>> protocol" specification and implemented by
a conforming SPPF server."

6.  Framework Data Model Objects

old:
"However, the specification of the data structures necessary to
support each command is delegated to >>the "protocol"<< specification."

New:
"However, the specification of the data structures necessary to
support each command is delegated to <<an SPPF conforming transport protocol>> specification."

6.2. Public Identifier

old:
/* No XML describing CORInfoType in the TNTYpe description  - yet elements of this type are discussed in descriptive text */

new:
add before the "NumberValType"

   " <complexType name="CORInfoType">
     <sequence>
      <element name="corClaim" type="boolean" default="true"/>
      <element name="cor" type="boolean" default="false" minOccurs="0"/>
      <element name="corDate" type="dateTime" minOccurs="0"/>
     </sequence>
    </complexType>"

Old:
"RNType has the following attributes:
…
   o    corInfo: Optional <corInfo> element of type CORInfoType."

New:
"RNType has the following attributes:
…
   o    corInfo: corInfo is an optional parameter of type CORInfoType
        that allows the registrant organization to set forth a claim to
        be the carrier-of-record (see [RFC5067])."

Old:
"TNRType has the following attributes:
…
   o    corInfo: Optional <corInfo> element of type CORInfoType."

New:
"TNRType has the following attributes:
…
   o    corInfo: corInfo is an optional parameter of type CORInfoType
        that allows the registrant organization to set forth a claim to
        be the carrier-of-record (see [RFC5067])."

Old:
"TNPType has the following attributes:
…
   o    corInfo: Optional <corInfo> element of type CORInfoType."

New:
"TNPType has the following attributes:
…
   o    corInfo: corInfo is an optional parameter of type CORInfoType
        that allows the registrant organization to set forth a claim to
        be the carrier-of-record (see [RFC5067])."

Old:
/* in the definition of URIPubIdType there is an "ext" element whereas in all other pubIDs there isn't - why? */

New:
remove…
   "<element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>"

6.2. SED Group

Old:
"As described in the introductory sections, a SED Group represents a
combined grouping of Destination Groups containing a set of Public
Identifiers >>with common Session Establishment Data(SED)<<, The common
Session Establishment Data Records, and the list of peer
organizations that have access to these public identifiers using the
associated SED information."

New:
/* too verbose */
"As described in the introductory sections, a SED Group represents a
combined grouping of Destination Groups (containing a set of Public
Identifiers), The common Session Establishment
Data Records, and the list of peer organizations that have access to this
gouging (public identifiers using the associated SED information.)"

Old:
/* in the definition of SedGrpType there is an "ext" element - why? */

New:
remove…
   "<element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>"

Old:
/* no mention of peeringOrg type */

New:
"Note that the identifier used for peering organization (peeringOrg) is an instance of OrgIdType."

6.4. SED Record

Old:
"The data provisioned in a registry can be leveraged for many purposes
and queried using various protocols including SIP, ENUM and others.
As such, the resolution data represented by the >>SedRecords<< must be in
a form suitable for transport using one of these protocols.

New:
"The data provisioned in a registry can be leveraged for many purposes
and queried using various protocols including SIP, ENUM and others.
As such, the resolution data represented by the <<SED records>> must be in
a form suitable for transport using one of these protocols.

6.4. SED Record

Old:
"In a high-availability environment, the originating SSP likely has
more than one egress path>>s<< to the ingress SBE of the target SSP."

New:
"In a high-availability environment, the originating SSP likely has
more than one egress path to the ingress SBE of the target SSP."

Old:
"A Egress Route object MUST be uniquely identified by attributes as
defined in the description of "ObjKeyType" in the section "Generic
Object Key Type" of this document."

New:
"A<<n>> Egress Route object MUST be uniquely identified by attributes as
defined in the description of "ObjKeyType" in the section "Generic
Object Key Type" of this document."

7. Framework Operations

7.1/2/3/4/5/6
Old:
"Any conforming "protocol" specification MUST provide…"

New:
"Any conforming <<transport protocol>> specification MUST provide…"

9.3.1 DoS Issues Inherited from Transport Mechanism

Old:
"The typical deployment scenario for SPPF is to have servers in a
managed facility, and therefor techniques such as Network Ingress
Filtering ([RFC2609]) are generally applicable."

New:
"The typical deployment scenario for SPPF is to have servers in a
managed facility, and therefor<<e>> techniques such as Network Ingress
Filtering ([RFC2609]) are generally applicable."

13 Acknowledgments
/* Jeremy Barkan participated in many discussions and should be acknowledged */

---

From: "Bhatia, Vikas" <[email-masked]>
Date: Wed, 26 Sep 2012 10:02:13 -0400

Most part it seems fine. Some of my comments...Please see inline.

Thanks,
Vikas

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Schwartz
Sent: Friday, September 21, 2012 10:55 AM
To: [email-masked] WG
Subject: [drinks] Comments to the WGLC on SPPF document

Abstract

old:

new:

1. Introduction

old:
"Service providers and enterprises use registries to make session
routing decisions for Voice over IP, SMS and MMS traffic exchanges..."

new:
"Service providers and enterprises use <<routing databases know as>> registries to make session
routing decisions for Voice over IP, SMS and MMS traffic exchanges..."
[VB:] "routing databases" ..is  "SED databases" a better term?..in line with your subsequent definition of SPPF server "The server typically operates a master database of
      Session Establishment Data (SED)"

old:

new:

old:

new:

old:

new:

old:

new:

old:

new:
"Transport requirements are provided in this document to help with the
selection of the optimum transport mechanism."
/* this second sentence creates a dependency on the SOAP document so imho it should be removed */
[VB:] I tend to agree and mentioned this in the past as well. imo, we should not have any references to the SOAP document in Framework document.

old

old:

new:

2. Terminology

old:

new:

old:

old:

new:
"The data model is defined along with all the objects manipulated
by <<a conforming tranport>> protocol and their relationships."
[VB:] typo on "transport" ..

old:

new:

old:

new:

old:

new:

old:

new:

old:

new:

old:

new:

old:

new:

old:

new:

old:

new:

old:

New:

6.2. Public Identifier

old:

new:

Old:
...

New:
...

Old:
...

New:
...

Old:
...

New:
...

Old:

New:
remove...

6.2. SED Group

Old:

New:
/* too verbose */

[VB:] gouging -> grouping?

Old:

New:
remove...
   "<element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>"
[VB:] the same reason I believe as for all other objects in SPPF, like "BasicObjType", "EgrRteType"..Extensibility of these schema elements to provide supplemental information to the server...( even though these were added much before I came onboard ...)

Old:

New:

6.4. SED Record

Old:

New:

6.4. SED Record

Old:

New:

Old:

New:

7. Framework Operations

7.1/2/3/4/5/6
Old:
"Any conforming "protocol" specification MUST provide..."

New:
"Any conforming <<transport protocol>> specification MUST provide..."

Old:

New:

13 Acknowledgments

________________________________
This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.