[drinks] Spencer Dawkins' No Objection on draft-ietf-drinks-spp-framework-09: (with COMMENT)

["Spencer Dawkins" <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-drinks-spp-framework-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

When Martin and I chatted about this draft, he was leaning toward a
Discuss on the use of the phrase "transport protocol" in this draft. I
would have supported that, but wanted to offer two other data points (in
the great tradition of TSV, we argue with people even when we agree with
them).

We are seeing above-layer-four protocols referred to as "transport
protocols" in many places. A much-previous IESG used the word "substrate"
in http://tools.ietf.org/html/bcp56, "On the use of HTTP as a Substrate".
If you wanted to switch terms to "substrate", I'd be fine with that, but
I'm not sure that's a commonly understood term of art these days.

So, a concrete suggestion - you get all the way through Section 4 before
you uncloak this text:

4.11.  Mandatory Transport

   At the time of this writing, a choice of transport protocol has been
   provided in SPP Protocol over SOAP document.  To encourage
   interoperability, the SPPF server MUST provide support for this
   transport protocol.  With time, it is possible that other transport
   layer choices may surface that agree with the requirements discussed
   above.
   
Perhaps you could move this to the front of the line early in Section 4,
and add a few words like this:

   None of the existing transport protocols carried directly over IP,
   appearing as "Protocol" in IPv4 headers or "Next Header" in IPv6
   headers, meet the requirements for a "transport" listed in this
section.
   
One other quibble about basic terminology. I apologize for spending the
last three days talking about IRRs at NANOG 63, but I'd think "Registry"
with no qualifier meant something like an IRR in common usage. Would it
be possible for you to characterize "registries" with an adjective on
first use, in Section 1? I'm not asking for a wholesale terminology swap,
of course.

1.  Introduction

   Service providers and enterprises use routing databases known as
   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].