Session Peering Provisioning Framework (SPPF)
RFC 7877

Note: This ballot was opened for revision 09 and is now closed.

(Richard Barnes) Yes

(Ben Campbell) Yes

Comment (2015-08-07 for -11)
No email
send info
Hi, I've looked over the framework doc, and think it's almost ready to be approved. A have a few minor comments and questions first. 

-- 3.2, last paragraph:

That new "MUST NOT" is not appropriate.  The actual normative requirement was in the previous paragraph, and this paragraph is an example. I suggest "... is a valid UTC time, but not acceptable for use in SPPF messages".

(I know Pete suggested that, and normally I would not think to argue with him on 2119 matters. But in this case I think the change was an error.)

-- section 4, and subsequent:

Is there a real need to keep using the word “transport”, even in quotes? 
I suggest changing the first sentence as follows, and then change all other mentions of "transport" to "substrate". (Except when referring to actual transport layer protocols)

   This section provides requirements for substrate protocols suitable
   as "transports" for SPPF.
   This section provides requirements for substrate protocols suitable
   to carry SPPF.

-- 8, 2nd paragraph: "XML specifications and _examples_ ... MUST be interpreted..."

Does this imply that the examples are normative?

Also I'm not sure what you mean by "interpreted in the character case presented"

-- 9.7:

Jari and Peter had a comment on this section, where I think the MiTM terminology is getting in the way. I _think_ you are talking about a potentially compromised known intermediary that can see/modify data. I think he is talking about a MiTM attack on the protected substrate between the client and that intermediary, or that intermediary and a server. While MiTM is a fuzzy term, enough people think of it as an attack on crypto that it might be better to use a different term here. (e.g. "Compromised or Malicious Intermediary")

*** nits ***

-- 4.1, '... in the IPv4 headers, of "Next Header" ... '


-- 4.1, 2nd paragraph:

s/that agree with/that support/  ; (or "that comply with")

-- 4.3
s/ensuring a response to be sent/ensuring a response is sent/

(Jari Arkko) No Objection

Comment (2015-02-03 for -09)
No email
send info
I would be interested in hearing an answer at least with regards to the
following items raised in Peter Yee's Gen-ART review. In both cases I
too was left wondering what the text actually meant.

Section 7.2: Is the "Delete" operation meant to be atomic?  Should that be
specified in that section?

Section 9.7: this section discusses how the "transport protocol" provides
connection protection services and then says that therefore a
man-in-the-middle attack is possible.  If that's the case, then the
"transport protocol" is not (adequately) providing connection protection.
And without connection protection, a man-in-the-middle attack would of
course be possible, so saying that because there is connection protection, a
man-in-the-middle attack is therefore possible seems misleading.

(Alia Atlas) No Objection

(Alissa Cooper) (was Discuss) No Objection

Comment (2015-04-20 for -10)
No email
send info
Thanks for addressing my DISCUSS and COMMENT!

(Spencer Dawkins) No Objection

Comment (2015-02-05 for -09)
No email
send info
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, "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
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].

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2015-02-05 for -09)
No email
send info
- Figure 2: What is "rant" here? I don't see that
explained. I guess registrant but had to wait for 5.1
to see that.

- 6.2, p20, para 1: s/Identity/Identifier/ here?

- 9.5: That's a surprise and I bet isn't met by any
reasonable protocol.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Barry Leiba) (was Discuss) No Objection

Comment (2015-03-24 for -09)
No email
send info
Former DISCUSS points, which are now left in "I trust the authors and AD to do the right thing" state:

-- Section 2 --

   This document reuses terms from [RFC3261], [RFC5486], use cases and
   requirements documented in [RFC6461] and the ENUM Validation
   Architecture [RFC4725].

These are all listed as informative references.  If this terminology is required in order to understand the terms used in this document, those references (3261 and 5486) need to be normative.  Left to judgment to decide.

-- Section 4.11 --

   At the time of this writing, a choice of transport protocol has been
   provided in SPP Protocol over SOAP document.

This would be a good place for a reference to that draft.  I think the reference is important, as you've made it MTI; I think it's a normative one.  I don't think "At the time of this writing" is necessary, though if you really like it I don't object.  It's also missing a "the" and some quotes, as thus:

   One choice of transport protocol has been provided in the document
   "SPP Protocol over SOAP" [reference].

About OrgIdType, I don't think the document makes it clear what this is, and why new ones would be registered in the first place.  Why would we ever need an OrgIdType Namespace other than "iana-en"?  Maybe add a sentence or two about that?

The rest of these have already been reviewed and accepted by the authors; thanks for taking the time to consider them:

-- Section 1 --

   1.  A resolution system returns a Look-Up Function (LUF) that
       comprises the target domain to assist in call routing (as
       described in [RFC5486]).

I don't know that it means for a LUF to "comprise the target domain"; perhaps its a meaning of "comprise" with which I'm unfamiliar.  (Similarly for bullet 2.)

Also, where in 5486 is this described?  Is it Section 4.3.3?  It'd be helpful to include that.

-- Section 2 --

   In addition, this document specifies the following additional terms:

You can get rid of "In addition," (my preference) or "additional"; you don't need both.  (I would also use "defines" rather than "specifies".)

   Server:   In the context of SPPF, this is an application that
      receives a provisioning request and responds accordingly.  It is
      sometimes referred to as a Registry.

   Registry:   The Registry operates a master database of Session
      Establishment Data for one or more Registrants.

The latter sentence in the first definition seems to say that "Server" and "Registry" are synonymous.  How does it, then, make sense to have separate definitions that are different?  And if they're not synonymous, perhaps it's unwise to sometimes refer to a Server as a Registry.

In the definition of Registrant:

      Within the confines of a Registry, a Registrant is uniquely
      identified by a well-known ID.

What is a "well-known ID"?  What is well known about it?  I ask because the term isn't otherwise used in this document.

-- Section 4 subsections --
These subsections are inconsistent in how they refer to the transport protocol (and see Martin's comments about that).  Some of those differences don't matter, but I think some do, and I think we'd be better off making the terminology consistent.
4.1, 4.2, 4.10: "a transport protocol for SPPF"
4.3: "a protocol suitable for SPPF" [is the word "suitable" significant here?]
4.4: "the SPPF transport protocol"
4.6: "the transport protocol" [doesn't mention SPPF]
4.7: "a DRINKS transport protocol" [DRINKS, as opposed to SPPF?]
4.8: "a suitable transport protocol for SPPF"
4.9: "a transport protocol suitable for SPPF"

You're in a maze of little twisting passages, all different.
I suggest picking one phrasing and using it in all nine subsections.

-- Section 5.2 --

   "Name" attributes that are used as components of object key types
   MUST be treated case insensitive, more specifically, comparison
   operations MUST use the toCasefold() function, as specified in
   Section 3.13 of [Unicode6.1].

It's a small point, but I think it would be better to lead with the more specific requirement, which makes the other unnecessary except by way of explanation:

   "Name" attributes that are used as components of object key types
   MUST be compared using the toCasefold() function, as specified in
   Section 3.13 of [Unicode6.1].  That function performs case-insensitive

(Ted Lemon) No Objection

(Kathleen Moriarty) (was Discuss) No Objection

Comment (2015-02-05 for -09)
No email
send info
Thanks for addressing the SecDir review from 2 years ago.  I see that you have added text to 9.1 to say integrity protection and confidentiality protections are to be supported by the transport protocol.  This and the other considerations look good.

In section 8, would it be appropriate to require that the XML is well formed and validated to prevent application and security issues?  I think a simple statement to that effect would be helpful in this document.  Barry says this isn't needed for apps and is assumed.  This surfaced as a possible concern for me as a result of it being in the INCH/MILE schema related drafts, so it may have been an apps request at the time or could have been that the WGs were aware of a possible issue since they involve incident responders.  In case there is an issue, I put a question out to someone that can help, but suspect it may be a result of additional processing requirements that we had on the schema in addition to general conformance that could result in an issue.  I didn't see any that are out of the ordinary in the subsequent draft, so this may not be needed.  Hopefully I'll have a response later, but would say there is nothing to do unless that comes in with a reason good enough.

Text in subsequent documents that tells you how to handle non-conformance to the schema or other issues that might result in a validation problem (if restrictions for this go beyond XML conformance) would be needed of that were the case, not here.  This was a request for a simple statement, that may not be needed.

(Pete Resnick) No Objection

Comment (2015-02-16 for -09)
No email
send info
3.2: s/is not approved for use/MUST NOT be used

3.3: s/MUST/need to
     s/SHOULD/is expected to

4.1/4.2: s/MUST/will (These are both definitional, not requirements; how could you possibly do otherwise?)


   Refer to the Security Considerations section for further guidance.
Please use an xref in here in order to refer to the section number. There are several of these named references throughout the document. Please fix also 5.2.2, 6.1 (two occurrences), 6.3 (two occurrences), 6.4, 6.5 (two occurrences), 6.6 (two occurrences), 7.1, 7.2, 7.4 (two occurrences), 7.5 (two occurrences), 7.6, 9.1 (two occurrences)

4.11: As written, this needs a (normative) reference to -spp-protocol-over-soap. You can't have a MUST requirement without a normative reference.

5.1: I think it's really awful practice to include protocol requirements and syntax definitions inside IANA Considerations. IANA Considerations are for *IANA*, not for the implementer and not for the folks entering items in the registry. I strongly suggest moving the syntax requirements and the ABNF from 11.2 into 5.1 and simply reverse the pointer so that 11.2 points to 5.1.

5.2: (I'm still trying to figure out how to non-normatively define something. :-) ) Can name attributes really be non-ASCII? Aren't these all protocol elements, not user-interface items? I am icked-out by having to use toCasefold, and having to have a reference to specific Unicode version.

5.2.1/5.2.2/5.3: I always find this construction bizzarre: "Any conforming specification MUST define...". They're all MUSTs (save a few MAYs in 5.3), and those MUSTs seem pretty unnecessary. For 5.3, you should simply make the opening paragraph:

   The following table contains the list of response types that a
   transport protocol specification needs to provide. An SPPF server
   MUST implement all of the following at minimum.

And then strike "Any conforming specification MUST define a response to indicate that" from all of the entries. Move the MAY bits out of the table, as those aren't part of the description of each of those response types. It'll shorten things up significantly.


   o  The value for Attribute Value MUST be the value of the data
      element to which the preceding Attribute Name refers.

   o  Response type "Attribute value invalid" MUST be used whenever an
      element value does not adhere to data validation rules.

What other choice could an implementation make? In other words, if I were to violate the first MUST, what do you think I'm going to put in to the attribute value that I need to be instructed that I MUST NOT do?


   hostName: Root-relative host name of the name server.

The additional term "root-relative" confused me. Are you somehow trying to say that these names MUST NOT have a terminating "." (i.e., they must be relative domain names)? If that's the point, then you should probably say that. Otherwise, I would strike "root-relative". An absolute name (with a terminating ".") should be OK in this context, yes?


   Where human-readable languages are used in the
   protocol, those messages SHOULD be tagged according to [RFC5646]...

I think you mean that human-readable *messages* that might be displayed to the user are to get language tags, but I don't see anywhere in the spec where you produce human-readable messages. Can you point me to an example. If so, you should probably say:

   Where human-readable messages that are presented to an end user are
   used in the protocol, those messages SHOULD be tagged with their
   language according to [RFC5646]...


   If tags are absent, the language of the message defaults to "en"

That seems like a bad plan. If all of the characters are out of the Arabic script, I'm pretty darn sure that an implicit default language tag of "en" is unlikely to be helpful to an implementation. I would strike that sentence.

11.2: See comment on section 5.1 above.

(Martin Stiemerling) No Objection

Comment (2015-02-05 for -09)
No email
send info
I have a number of comments and one big near DISCUSS point:

The definition of your meaning of " transport protocols" is stated just in Section 4.11 and you mean for instance SOAP. However, SOAP is not a transport protocol in the sense as the rest of the world AFAIK is using the term transport protocol. A transport protocol is a layer 4 protocol and not something that is running on top. 

Can you please change your terminology?
Otherwise, all my points below become a DISCUSS, as your requirements basically rule out transport protocols to run over. 

- Section "4.4.  Authentication"

   authenticated SPP Client is a Registrar.  Therefore, the SPPF
   transport protocol MUST provide means for an SPPF server to
   authenticate an SPPF Client.

This MUST requirement basically lets you without any transport protocol choice left. None to me known transport protocol is supporting the authentication between client and server. Unless you will wait for TCPINC. 

Perhaps you mean this: 
"Therefore, SPPF MUST leverage appropriate mechanisms provided by underlying protocol layers for an SPPF server to  authenticate an SPPF Client". 

This will allow to use TLS which is not a transport protocol, but running on top of it. In case you have a different defintion of transport protocol, it would be good to state this.

- Section "4.6.  Confidentiality and Integrity"
   Therefore, the transport protocol MUST provide means for
   data integrity protection.

Similar discuss to the point above: None of the IETF transport protocols is providing means for data integrity protection. So you won't ge too far.

- Section "4.9.  Request and Response Correlation":

Same as the ones before: 
   A transport protocol suitable for SPPF MUST allow responses to be
   correlated with requests.

TCP, UDP and SCTP will not offer this. 

In Section "4.2.  Request and Response Model"

   Therefore, a transport protocol for SPPF MUST follow the request-
   response model by allowing a response to be sent to the request

The last part is worded a bit strange: "allowing a response to be sent..". How about saying "my ensuring a response to be sent to the..."?

In Section "4.3.  Connection Lifetime":

What is in a quantity short and long-lived? This sentence does not make any sense, unless it is state what a short time period for such a protocol and what a long time period is. 

In Section "Near Real Time"
I am not sure how good or bad one can determine if any protocol is reacting in near real-time. And what is realtime anyhow? Measured in nano seconds, milliseconds, etc?