Skip to main content

Session Peering Provisioning Framework (SPPF)
draft-ietf-drinks-spp-framework-12

Revision differences

Document history

Date Rev. By Action
2016-06-27
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2016-05-26
12 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2016-05-05
12 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2016-04-04
12 (System) RFC Editor state changed to EDIT from MISSREF
2015-10-14
12 (System) Notify list changed from drinks-chairs@ietf.org, alexander.mayrhofer@enum.at to (None)
2015-09-17
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2015-09-16
12 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2015-09-11
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2015-09-04
12 (System) IANA Action state changed to In Progress
2015-09-03
12 (System) RFC Editor state changed to MISSREF
2015-09-03
12 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-09-03
12 (System) Announcement was received by RFC Editor
2015-09-03
12 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2015-09-03
12 Cindy Morgan IESG has approved the document
2015-09-03
12 Cindy Morgan Closed "Approve" ballot
2015-09-03
12 Cindy Morgan Ballot approval text was generated
2015-09-03
12 Cindy Morgan Ballot writeup was changed
2015-09-03
12 Ben Campbell Ballot writeup was changed
2015-09-03
12 Ben Campbell Ballot approval text was generated
2015-08-12
12 Alexander Mayrhofer New version available: draft-ietf-drinks-spp-framework-12.txt
2015-08-07
11 Ben Campbell
[Ballot comment]
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 …
[Ballot comment]
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)

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

-- 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" ... '

s/of/or

-- 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/
2015-08-07
11 Ben Campbell [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell
2015-07-22
11 Alexander Mayrhofer New version available: draft-ietf-drinks-spp-framework-11.txt
2015-04-20
10 Alissa Cooper [Ballot comment]
Thanks for addressing my DISCUSS and COMMENT!
2015-04-20
10 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss
2015-03-25
10 Alexander Mayrhofer IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2015-03-25
10 Alexander Mayrhofer New version available: draft-ietf-drinks-spp-framework-10.txt
2015-03-25
09 Cindy Morgan Shepherding AD changed to Ben Campbell
2015-03-24
09 Barry Leiba
[Ballot comment]
Former DISCUSS points, which are now left in "I trust the authors and AD to do the right thing" state:

-- Section 2 …
[Ballot comment]
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:

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

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:

NEW
  "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
  comparisons.
END
2015-03-24
09 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2015-03-19
09 Richard Barnes IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation - Defer::AD Followup
2015-03-01
09 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2015-02-19
09 Cindy Morgan IESG state changed to IESG Evaluation - Defer::AD Followup from IESG Evaluation - Defer
2015-02-19
09 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2015-02-18
09 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2015-02-18
09 Barry Leiba
[Ballot discuss]
-- Section 2 --

  This document reuses terms from [RFC3261], [RFC5486], use cases and
  requirements documented in …
[Ballot discuss]
-- 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 you use terminology defined elsewhere, those references (3261 and 5486) need to be normative (they're required in order to understand the terms used in this doument).

-- 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:

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

-- Section 11.2 --

Why does the policy need to be RFC Required?  Why not Expert Review?  For that matter, why not FCFS?  You can either point me at mailing list archives where this was discussed, or explain the necessity in response to this comment.

While we're talking 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"?  Shouldn't the document say something about that?
2015-02-18
09 Barry Leiba
[Ballot comment]
-- Section 1 --

  1.  A resolution system returns a Look-Up Function (LUF) that
      comprises the target domain to …
[Ballot comment]
-- 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:

NEW
  "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
  comparisons.
END

-- Section 11.2 --
The ABNF allows an OrgIdType Namespace identifier to end with "-"; is that intentional?
2015-02-18
09 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2015-02-18
09 Peter Yee Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Peter Yee.
2015-02-17
09 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2015-02-17
09 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2015-02-16
09 Pete Resnick
[Ballot comment]
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, …
[Ballot comment]
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?)

4.5:

  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.

5.3:

  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?

6.4:

  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?

10:

OLD
  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:

NEW
  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]...

Also:

  If tags are absent, the language of the message defaults to "en"
  (English).

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.
2015-02-16
09 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2015-02-12
09 Jean Mahoney Request for Telechat review by GENART is assigned to Peter Yee
2015-02-12
09 Jean Mahoney Request for Telechat review by GENART is assigned to Peter Yee
2015-02-05
09 Pearl Liang IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2015-02-05
09 Barry Leiba Telechat date has been changed to 2015-02-19 from 2015-02-05
2015-02-05
09 Barry Leiba IESG state changed to IESG Evaluation - Defer from IESG Evaluation
2015-02-05
09 Spencer Dawkins
[Ballot comment]
When Martin and I chatted about this draft, he was leaning toward a Discuss on the use of the phrase "transport protocol" in …
[Ballot 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].
2015-02-05
09 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2015-02-05
09 Kathleen Moriarty
[Ballot comment]
Thanks for addressing the SecDir review from 2 years ago.  I see that you have added text to 9.1 to say integrity protection …
[Ballot comment]
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.
http://www.ietf.org/mail-archive/web/secdir/current/msg03495.html

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.
2015-02-05
09 Kathleen Moriarty [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss
2015-02-05
09 Richard Barnes Notification list changed to drinks@ietf.org, drinks-chairs@ietf.org, alexander.mayrhofer@enum.at, draft-ietf-drinks-spp-framework.all@tools.ietf.org from drinks@ietf.org, drinks-chairs@ietf.org, alexander.mayrhofer@enum.at, draft-ietf-drinks-spp-framework.all@ietf.org
2015-02-05
09 Stephen Farrell
[Ballot comment]

- Figure 2: What is "rant" here? I don't see that
explained. I guess registrant but had to wait for 5.1
to see …
[Ballot comment]

- 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.
2015-02-05
09 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2015-02-05
09 Martin Stiemerling
[Ballot comment]
I have a number of comments and one big near DISCUSS point:

The definition of your meaning of " transport protocols" is stated …
[Ballot comment]
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
  initiator.

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?
2015-02-05
09 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2015-02-04
09 Cindy Morgan Changed consensus to Yes from Unknown
2015-02-04
09 Alissa Cooper
[Ballot discuss]
I have one point to discuss that should be easy to resolve.

= Section 6 =
A bunch of places in this section …
[Ballot discuss]
I have one point to discuss that should be easy to resolve.

= Section 6 =
A bunch of places in this section reference the Create and Modify operations, neither of which are defined in Section 7. I think these are both meant to be Add operations? Or if not, a Modify operation needs to be defined and made distinct from Add.
2015-02-04
09 Alissa Cooper
[Ballot comment]
= Section 3.3 =
What does "RFC level document" mean? RFC? Or perhaps you want to use the "permanent and readily available" standard …
[Ballot comment]
= Section 3.3 =
What does "RFC level document" mean? RFC? Or perhaps you want to use the "permanent and readily available" standard from RFC 5226?

= Section 5.2.1 =
s/SPPF object that/SPPF object/

= Section 5.2.2 =
s/Refer the "Framework Data Model Objects"/Refer to the "Framework Data Model Objects"/

= Section 6 =
s/refer the "Framework Operations"/refer to the "Framework Operations"/
2015-02-04
09 Alissa Cooper [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper
2015-02-04
09 Kathleen Moriarty
[Ballot discuss]
In section 8, would it be appropriate to require that the XML is well formed and validated to prevent application and security issues?  …
[Ballot discuss]
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.

I'd be fine with seeing 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).
2015-02-04
09 Kathleen Moriarty
[Ballot comment]
Thanks for addressing the SecDir review from 2 years ago.  I see that you have added text to 9.1 to say integrity protection …
[Ballot comment]
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.
http://www.ietf.org/mail-archive/web/secdir/current/msg03495.html
2015-02-04
09 Kathleen Moriarty [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty
2015-02-03
09 Jari Arkko
[Ballot comment]
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 …
[Ballot comment]
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.
2015-02-03
09 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-02-03
09 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2015-02-02
09 Richard Barnes Placed on agenda for telechat - 2015-02-05
2015-02-02
09 Richard Barnes IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2015-02-02
09 Richard Barnes Ballot has been issued
2015-02-02
09 Richard Barnes [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes
2015-02-02
09 Richard Barnes Created "Approve" ballot
2015-01-23
09 Peter Yee Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee.
2015-01-22
09 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2015-01-20
09 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2015-01-20
09 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-drinks-spp-framework-09.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-drinks-spp-framework-09.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has questions about the requested IANA actions made by the authors in the IANA Considerations section of this document.

On approval of this document, IANA understands that there are three actions which IANA must complete.

First, in the ns registry of the IETF XML registry located at:

http://www.iana.org/assignments/xml-registry/

a new namespace will be registered as follows:

ID: sppf:base:1
URI: urn:ietf:params:xml:ns:sppf:base:1
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

As this document requests registration in a Specification Required registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the schema registry of the IETF XML registry located at:

http://www.iana.org/assignments/xml-registry/

a new schema will be registered as follows:

ID: sppf:1
URI: urn:ietf:params:xml:ns:sppf:1
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

As this document requests registration in a Specification Required registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, a new registry is to be created called the SPPF OrgIdType Namespaces" registry. Assignments consist of the OrgIdType namespace string and a reference for that string. The new registry is to be maintained via "RFC Required" as defined in RFC 5226.

There are initial registrations in the new registry as follows:

OrgIdType namespace string Namespace Reference
-------------------------- --------- --------------
IANA Enterprise Numbers iana-en [ RFC-to-be ]

IANA QUESTION -> Where should this new registry be located? Is it a néw registry on the IANA Matrix (http://www.iana.org/protocols) or is it a subregistry of an existing registry, listed at http://www.iana.org/protocols? If it is a subregistry of an existing registry, in which registry will it be contained?

IANA understands that these three actions are the only ones required to be completed upon approval of this document.


Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2015-01-13
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Lionel Morand
2015-01-13
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Lionel Morand
2015-01-09
09 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2015-01-09
09 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2015-01-08
09 Amy Vezza IANA Review state changed to IANA - Review Needed
2015-01-08
09 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Session Peering Provisioning Framework (SPPF)) …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Session Peering Provisioning Framework (SPPF)) to Proposed Standard


The IESG has received a request from the Data for Reachability of
Inter/tra-NetworK SIP WG (drinks) to consider the following document:
- 'Session Peering Provisioning Framework (SPPF)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-01-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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
  establishment.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework/ballot/


No IPR declarations have been submitted directly on this I-D.


2015-01-08
09 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2015-01-08
09 Richard Barnes Last call was requested
2015-01-08
09 Richard Barnes Ballot approval text was generated
2015-01-08
09 Richard Barnes IESG state changed to Last Call Requested from Publication Requested
2015-01-08
09 Richard Barnes Last call announcement was generated
2015-01-08
09 Richard Barnes Last call announcement was generated
2015-01-08
09 Richard Barnes Ballot writeup was changed
2015-01-08
09 Richard Barnes Ballot writeup was generated
2014-10-23
09 Cindy Morgan

PROTO write-up for draft-ietf-spp-framework

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the …

PROTO write-up for draft-ietf-spp-framework

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
page header?

  Publication as Proposed Standard is being requested. The document
  specifies a (transport-agnostic) provisioning protocol, including a
  data and transaction model, hence the WG is in strong concensus that
  Standards Track is the proper document track.

  The requested type of RFC is included in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

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
  establishment.

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.

Personnel:
  Alexander Mayrhofer serves as the Document Shepherd, and Richard
  Barnes serves as the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd . If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The document shepherd performed a detailed NITS review on version -04,
  and an additional review on version -05. Subsequent versions only
  contained minor modifications, and the shepherd performed an
  additional automated NITS review on version -09. Additionally, the
  document was reviewed by the same person during WGLC, and many times
  before that. All issues are believed to be addressed in the latest
  version of the document.

(4) Does the document Shepherd have any concerns about the depth or  breadth of the reviews that have been performed?

  Due to the small size of the WG (particularly after splitting off the
  transport protocol definitions), reviews were mostly performed by the
  Design Team members themselves. However, during WGLC the WG chairs
  specifically engaged „outside“ reviewers in order to get „fresh eyes“
  on the document. Subsequently, their comments were addressed in
  document revisions.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

  The document contains XML Schema definitions. Even though the Schemas
  were reviewed and validated by authors / reviewers, the document could
  benefit from an additional “3rd party” validation of the Schemas.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  The document specifies an IANA Registry with just 1 (one) initial
  entry. Since additional entries are believed to be very infrequent,
  the IESG’s advice is desired whether to remove that Registry in favour
  of a „static“ definition with that single entry (and advice that
  future specifications might want to create an IANA registry
  themselves).

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

  Each author has confirmed that there are no IPR claims about the
  contents of the draft, and that they are not a ware of such claims.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR claims have been filed.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  Within the Design Team, solid consensus was sought for each issue, and
  minutes from the weekly conference calls were sent back to the WG
  mailing list. Due to the small size of the WG, active participants
  were almost exclusively also part of the Design Team. Therefore, there
  is solid WG consensus behind the document.

(10) Has anyone threatened an appeal or other wise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No appeal was threatened, nor did anybody indicate extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The document shepherd performed a detailed NITS review for version
  -05. Between -05 and the current -09 version, there were (with the
  exception of adding a formal IANA registry definition) only editorial
  changes and NITS fixes.

  An automated NITS check was performed on version -09 in order to
  confirm that all NITS have been fixed.

  The automated NITS check seems to detected one unused reference,
  however, a manual check confirms that the reference is being used in
  the text.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  Besides the basic requirements, the document does not contain any
  content that is believed to be subject to additional formal review
  criteria.

(13) Have all references within this document been identified as either
normative or informative?

  Yes, references have been split in normative an informative
  references.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  All normative references are RFC-level documents.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in  the Last Call procedure.

  There are no downrefs

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

  This document will not change the status of any existing RFC.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The document requests two URN assignments for the XML namespace, and
  the XML schema, respectively. Those are outlined in the IANA
  considerations section

  Furthermore, the document specifies a newly created IANA registry that
  is specified in detail in Section 11.2. The registry contains just a
  single initial entry.

  A reasonable name, allocation procedures and initial contents of that
  registry has been specified.

  However, feedback from the IESG is thought with regards to the
  registry specification of the „SPPF Organization Identifier“. See (6)
  above for details.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  See above. The registry specified does not use “Expert Review” as the
  allocation mechanism.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  The document shepherd has performed (besides the manual review) an
  automated NITS check with idnits 2.13.0. Issues discovered by that
  check are included in the NITS section above. Furthermore, the
  Document Shepherd has validated the XML schema using automated tools.

  Furthermore, Ning Zhang has volunteered to perform a review,
  submitting his results during the IETF LC.
2014-10-23
09 Cindy Morgan Intended Status changed to Proposed Standard
2014-10-23
09 Cindy Morgan IESG process started in state Publication Requested
2014-10-23
09 (System) Earlier history may be found in the Comment Log for /doc/draft-ietf-drinks-spprov/
2014-10-23
09 Cindy Morgan Working group state set to Submitted to IESG for Publication
2014-10-23
09 Cindy Morgan Changed document writeup
2014-10-23
09 Cindy Morgan Notification list changed to "Alexander Mayrhofer" <alexander.mayrhofer@enum.at>
2014-10-23
09 Cindy Morgan Document shepherd changed to Alexander Mayrhofer
2014-10-22
09 Alexander Mayrhofer New version available: draft-ietf-drinks-spp-framework-09.txt
2014-10-22
08 Alexander Mayrhofer New version available: draft-ietf-drinks-spp-framework-08.txt
2014-04-22
07 Syed Ali New version available: draft-ietf-drinks-spp-framework-07.txt
2013-10-21
06 David Schwartz New version available: draft-ietf-drinks-spp-framework-06.txt
2013-07-15
05 David Schwartz New version available: draft-ietf-drinks-spp-framework-05.txt
2013-02-25
04 David Schwartz New version available: draft-ietf-drinks-spp-framework-04.txt
2012-10-22
03 Syed Ali New version available: draft-ietf-drinks-spp-framework-03.txt
2012-08-21
02 Samuel Weiler Request for Early review by SECDIR Completed: Ready with Nits. Reviewer: Paul Hoffman.
2012-08-10
02 Samuel Weiler Request for Early review by SECDIR is assigned to Paul Hoffman
2012-08-10
02 Samuel Weiler Request for Early review by SECDIR is assigned to Paul Hoffman
2012-08-10
02 Samuel Weiler Assignment of request for Early review by SECDIR to Dan Harkins was rejected
2012-08-10
02 Samuel Weiler Request for Early review by SECDIR is assigned to Dan Harkins
2012-08-10
02 Samuel Weiler Request for Early review by SECDIR is assigned to Dan Harkins
2012-07-16
02 David Schwartz New version available: draft-ietf-drinks-spp-framework-02.txt
2012-03-12
01 Vikas Bhatia New version available: draft-ietf-drinks-spp-framework-01.txt
2012-01-30
00 (System) New version available: draft-ietf-drinks-spp-framework-00.txt