Subject: [drinks] WGLC comments on draft-ietf-drinks-spp-framework-02

From: Alexander Mayrhofer <[email-masked]>
Date: Sat, 22 Sep 2012 00:19:38 +0000

Hi,

here are my comments on the framework document. Most of them are nits or issues around references, duplicate text, etc. Luckily, i haven't found any substantial issues. All my comments are tagged with "AM>>", any other text is from the original draft to provide context:

thanks,

Alex

---- snip ----

Abstract

   This document specifies the data model and the overall structure for
   a framework to provision session establishment data into Session Data

AM>> we use capitalized "Session Establishment Data" in the introduction
AM>> section - stick to it here as well? The other terminology is
AM>> capitalized as well..

[...]

1.  Introduction

   Service providers and enterprises use registries to make session
   routing decisions for Voice over IP, SMS and MMS traffic exchanges.
   This document is narrowly focused on the provisioning framework for
   these registries.  This framework prescribes a way for an entity to
   provision session-related data into a registry.  The data being
   provisioned can be optionally shared with other participating peering
   entities.  The requirements and use cases driving this framework have
   been documented in [RFC6461].  The reader is expected to be familiar
   with the terminology defined in the previously mentioned document.

AM>> would remove the last sentence - general expectation from RFC readers?

[...]

   Please note that the role of the "client" and the "server" only

AM>> Would remove the "please note"

[...]

   A "terminating" SIP Service Provider (SSP) provisions SED into the
   registry to be selectively shared with other peer SSPs.

AM>> move the above paragraph up, between the Figure and the "The data
AM>> provisioned"? Would reflect the logical order: 1) provision 2) use
AM>> 3) redistribute.

   Subsequently, a registry may distribute the provisioned data into
   local data repositories used for look-up queries (identifier -> URI)
   or for lookup and location resolution (identifier -> URI -> ingress

AM>> Is there a difference between "look-up" and "lookup"? I vaguely
AM>> remember some dicussion long time ago?

[...]

   A key requirement for the SPPF is to be able to accommodate two basic
   deployment scenarios:

   1.  A resolution system returns a Look-Up Function (LUF) that
       comprises the target domain to assist in call routing (as
       described in [RFC5486]).  In this case, the querying entity may
       use other means to perform the Location Routing Function (LRF)

AM>> Strictly speaking, a system can not return a "Function" itself. Change
AM>> that to "returns a Look-Up Function (LUF) response.."?

Cartwright, et al.      Expires January 17, 2013                [Page 5]

Internet-Draft         draft-drinks-spp-framework              July 2012

       which in turn helps determine the actual location of the
       Signaling Function in that domain.

   2.  A resolution system returns a Location Routing Function (LRF)
       that comprises the location (address) of the signaling function
       in the target domain (as described in [RFC5486]).

AM>> same as above.. can't return "function" itself.

   In terms of framework design, SPPF is agnostic to the transport
   protocol.  This document includes the specification of the data model
   and identifies, but does not specify, the means to enable protocol
   operations within a request and response structure.  That aspect of
   the specification has been delegated to the "protocol" specification
   for the framework.  To encourage interoperability, the framework
   supports extensibility aspects.

AM>> Depends whether "interopability" means "interopability between
AM>> various implementions of SPPF", or "interopability between SPPF
AM>> and other systems". The second is true, the first probably not.

   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.

AM>> There should be a reference to the SOAP document at this point.

[...]

2.  Terminology

[...]

   Client:   An application that supports an SPPF client; it is
      sometimes referred to as a "registry client".

AM>> I'm slightly confused... "Client" is the software, "SPPF client"
AM>> is an entity, such as an organization? Has been some time since
AM>> we discussed this, i guess.

[...]

   Registrant:   In this document we extend the definition of a
      Registrant based on [RFC4725].  The Registrant is the end-user,

AM>> I understand from previous dicussions with the RFC authors that
AM>> "we" is to be avoided in RFCs. Change that to "the definition ..
AM>> .. is extended".

[...]

   Registrar:   In this document we extend the definition of a Registrar
      from [RFC4725].  A Registrar is an entity that performs
      provisioning operations on behalf of a Registrant by interacting
      with the Registry via SPPF operations.  In other words the
      Registrar is the SPPF Client.  The Registrar and Registrant roles
      are logically separate to allow, but not require, a single
      Registrar to perform provisioning operations on behalf of more
      than one Registrant.

AM>> As above... avoid "we"..

[...]

3.1.  Framework Data Model

   The data model illustrated and described in Figure 2 defines the
   logical objects and the relationships between these objects that the
   SPPF protocol supports.  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.

AM>> "Clients" instead of "clients", same for "Registrars" and "Registry"
AM>> to identify it's meant to be terminology as defined above.
AM>> However, given my point above, not sure it applies to "SPPF clients"?

       +-------------+                        +-----------------+
       | all object  |                        |Egress Route:    |
       | types       |                   0..n | rant,           |
       +-------------+                     +--| egrRteName,     |
             |0..n                        /   | pref,           |
             |                           /    | regxRewriteRule,|
             |2                         /     | ingrSedGrp,     |

AM>> I think the "2" above warrants some explaination - Short
AM>> sentence that each object has a rant/rar attribute, and that's
AM>> where that "2" comes from?

   +----------------------+            /      | svcs            |
   |Organization:         |           /       +-----------------+
   | orgId                |          /
   +----------------------+         /
          |0..n                    /
          |                       /
          |A SED Group is        /
          |associated with      /
          |zero or more        /              +---[abstract]----+
          |Peering            /               | SED Record:     |
          |Organizations     /                |  rant,          |
          |                 /                 |  sedName,       |0..n
          |0..n            /                  |  sedFunction,   |------|
   +--------+--------------+0..n          0..n|  isInSvc,       |      |
   |SED Group:             |------------------|  ttl            |      |
   |  rant,                |                  +-----------------+      |

[...]

(section 3.1)

   o  SED Group:
      A SED Group contains a set of SED Record references, a set of
      Destination Group references, and a set of peering organization
      identifiers.  This is used to establish a three part relationships
      between a set of Public Identifiers, the session establishment
      information (SED) shared across these Public Identifiers, and the
      list of peering organizations whose query responses from the
      resolution system may include the session establishment
      information contained in a given SED group.  In addition, the
      sourceIdent element within a SED Group, in concert with the set of
      peering organization identifiers, enables fine-grained source
      based routing.  For further details about the SED Group and source
      based routing, refer to the definitions and descriptions of the
      SED Group operations found later in this document.

AM>> Reference to actual section, instead of "found later".

   o  SED Record:
      A SED Record contains the data that a resolution system returns in
      response to a successful query for a Public Identifier.  SED
      Records are generally associated with a SED Group when the SED
      within is not specific to a Public Identifier.
      To support the use cases defined in [RFC6461], SPPF framework

AM>> "SPPF framework" has a redundant "framework". Occurs a few more
AM>> times in the document.

[...]

   o  Egress Route:
      In a high-availability environment, the originating SSP likely has
      more than one egress paths to the ingress SBE of the target SSP.

AM>> "SBE" is never expanded in the document.

[...]

3.2.  Time Value

   Some request and response messages in SPPF framework include time
   value(s) defined as type xs:dateTime, a built-in W3C XML Schema
   Datatype.  Use of unqualified local time value is discouraged as it
   can lead to interoperability issues.  The value of time attribute
   MUST BE expressed in Coordinated Universal Time (UTC) format without
   the timezone digits.

AM>> The "BE" does not need to be capitalized.

[...]

4.4.  Authentication

   All SPPF objects are associated with a registrant identifier.  SPPF
   Clients provisions SPPF objects on behalf of registrants.  An
   authenticated SPP Client is a registrar.  Therefore, the SPPF
   transport protocol MUST provide means for an SPPF server to
   authenticate an SPPF Client.

AM>> Uppercase "registrant" and "registrar"? We also have "SPPF Clients"
AM>> as well as "SPP Client" in the paragraph.. intended?

[..]

4.5.  Authorization

   After successful authentication of the SPPF client as a registrar the
   registry performs authorization checks to determine if the registrar
   is authorized to act on behalf of the Registrant whose identifier is
   included in the SPPF request.  Refer to the Security Considerations
   section for further guidance.

AM>> Uppercasing of "registrar", "registry"..? Same is true for many
AM>> other subsequent spots in the draft.

[...]

5.1.  Basic Object Type and Organization Identifiers

   This section introduces the basic object type that most first class
   objects derive from.

AM>> Looking at the paragraph below, the paragraph above (or at least the
AM>> second part) seems redundant and contradictory ("most" vs. "all")

   All first class objects extend the basic object type BasicObjType
   that contains the identifier of the registrant organization that owns
   this object, the identifier of the registrar organization that
   created this object, the date and time that the object was created by
   the server, and the date and time that the object was last modified.

AM>> We should add element names to the date/time descriptions above,
AM>> otherwise the relation between text and elements is not clear.

[...]

   The identifiers used for registrants (rant), registrars (rar), and
   peering organizations (peeringOrg) are instances of OrgIdType.  The
   OrgIdType is defined as a string and all OrgIdType instances SHOULD
   follow the textual convention: "namespace:value" (for example "iana-
   en:32473").  See the IANA Consideration section for more details.

AM>> peeringOrg does not occur in BasicObjType. This might be confusing,
AM>> move that definition further down?

[...]

(Section 5.2.1)

   A Public Identity object MUST use attributes of PubIdKeyType for its
   unique identification .  Refer the "Framework Data Model Objects"
   section of this document for a description of Public Identity object.

AM>> Add proper reference to section..

5.3.  Response Message Types

[...]

   |                     | way to indicate the Attribute Name and the  |
   |                     | Attribute Value that identifies the object. |
   +---------------------+---------------------------------------------+

                          Table 1: Response Types

AM>> The "Any conforming specification MUST... " is identical for all
AM>> response types, and there's no exception. Therefore, this could
AM>> be stated once in front of the table as well instead..

[...]

6.1.  Destination Group

   As described in the introductory sections, a Destination Group
   represents a set of Public Identifiers with common session
   establishment information.  The transport protocol MUST support the
   ability to Create, Modify, Get, and Delete Destination Groups (refer
   the "Framework Operations" section of this document for a generic
   description of various operations).

AM>> Proper reference would be good.

[...]

   o    base: All first class objects extend BasicObjType that contains
        the ID of the registrant organization that owns this object,
        registrar organization that provisioned this object on behalf of
        the registrant, the date and time that the object was created by
        the server, and the date and time that the object was last
        modified.  If the client passed in either the created date or
        the modification date, the server will ignore them.  The server
        sets these two date/time values.

AM>> The description of the "base" attribute seems a duplicate of the
AM>> definition in section 5.1 - really needed here? The definition
AM>> about ignoring create / modification details should be moved up?
AM>> This applies to many more objects as well..

[page 22]

   o    ext: Point of extensibility described in a previous section of
        this document.

AM>> concrete reference would be better.

6.2.  Public Identifier

[...]

   SPPF identifies three types of Public Identifiers: telephone numbers
   (TN), routing numbers (RN), and URI type of Public Identifiers (like
   an email address).  SPPF provides structures to manage a single TN, a
   contiguous range of TNs, and a TN prefix.  The transport protocol
   MUST support the ability to Create, Modify, Get, and Delete Public
   Identifiers (refer the "Framework Operations" section of this
   document for a generic description of various operations).

AM>> (Think i had a similar comment long time ago): I don't think "email"
AM>> is a good example for a URI type PI, because email is not a session
AM>> establishment protocol. "sip" would be more appropriate, imho.

   A Public Identity object MUST be uniquely identified by attributes as
   defined in the description of "PubIdKeyType" in the section "Derived
   Object Key Types" of this document.

AM>> concrete reference, eg "in Section 5.2.2 of this document".

   The abstract XML schema type definition PubIDType is a generalization
   for the concrete Public Identifier schema types.  PubIDType element
   'dgName' represents the name of the destination group that a given
   Public Identifier MAY be a member of.  The PubIDType object structure
   is defined as follows:

AM>> I don't think the RFC2119 "MAY" is appropriate here. Should be lowercased

[...]

   A routing number is provisioned using the RNType, an extension of
   PubIDType.  SSPs that possess the number portability data may be able

AM>> Typo: "possess"

[...]

   RNType has the following attributes:

   o    rn: Routing Number used as the search key.

   o    corInfo: Optional <corInfo> element of type CORInfoType.

AM>> The "corInfo" definition does not provide more information than
AM>> the schema snippet. Briefly mention its function instead
AM>> (Same is true for remaining corInfo elements descriptions below)

[...]

6.3.  SED Group

   As described in the introductory sections, a SED Group represents a

AM>> concrete reference

[...]

   o    sedFunction: As described in [RFC6461], SED or Session
        Establishment Data falls primarily into one of two categories or
        functions, LUF and LRF.  To remove any ambiguity as to the
        function a SED record is intended to provide, this optional
        element allows the provisioning party to make his or her
        intentions explicit.

AM>> would add the actual values in parantheses behind the functions:
AM>> LUF ("lookup") etc ...

[...]

   As described above, SED records are based on an abstract type:
   SedRecType.  The concrete types that use SedRecType as an extension
   base are NAPTRType, NSType, and URIType.  The definitions of these
   types are included below.  The NAPTRType object is comprised of the
   data elements necessary for a NAPTR that contains routing information
   for a SED Group.  The NSType object is comprised of the data elements
   necessary for a DNS name server that points to another DNS server
   that contains the desired routing information.  The NSType is
   relevant only when the resolution protocol is ENUM.  The URIType
   object is comprised of the data elements necessary to house a URI.

AM>> Informative references to NAPTR and ENUM specifications?

[...]

7.2.  Delete Operation

[...]

   o    Destination Groups: When a destination group is deleted all
        public identifiers within that destination group must also be
        automatically deleted by the SPPF implementation as part of
        fulfilling the deletion request.  And any references between
        that destination group and any SED group must be automatically
        removed by the SPPF implementation as part of fulfilling the
        deletion request.

AM>> Deletion of a large DG can trigger deletion of millions of numbers..
AM>> Alternatively, we could just remove the references in the PIs?
AM>> This has probably been discussed before?

[...]

11.  IANA Considerations

   This document uses URNs to describe XML namespaces and XML schemas
   conforming to a registry mechanism described in [RFC3688].

   Two URI assignments are requested.

AM>> I think that "Two XML namespace URI assignments" would be more
AM>> precise, because the sentence above could be interpreted as
AM>> requests for URI schemes..