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 |