Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture
draft-ietf-speermint-architecture-19
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
19 | (System) | post-migration administrative database adjustment to the No Objection position for Jari Arkko |
2012-08-22
|
19 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
2011-02-23
|
19 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-02-22
|
19 | (System) | IANA Action state changed to No IC from In Progress |
2011-02-22
|
19 | (System) | IANA Action state changed to In Progress |
2011-02-22
|
19 | Amy Vezza | IESG state changed to Approved-announcement sent |
2011-02-22
|
19 | Amy Vezza | IESG has approved the document |
2011-02-22
|
19 | Amy Vezza | Closed "Approve" ballot |
2011-02-22
|
19 | Amy Vezza | Approval announcement text regenerated |
2011-02-22
|
19 | Amy Vezza | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup. |
2011-02-21
|
19 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss |
2011-02-20
|
19 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss |
2011-02-18
|
19 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss |
2011-02-18
|
19 | (System) | New version available: draft-ietf-speermint-architecture-19.txt |
2011-02-17
|
19 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-02-17
|
18 | (System) | New version available: draft-ietf-speermint-architecture-18.txt |
2011-02-07
|
19 | Sam Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Lt. Mundy. |
2011-02-03
|
19 | Cindy Morgan | Removed from agenda for telechat |
2011-02-03
|
19 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation. |
2011-02-03
|
19 | Russ Housley | [Ballot comment] Please consider the comments from the Gen-ART Review by Avshalom Houri on 2-FEB-2011: Line 357: o An SBE can … [Ballot comment] Please consider the comments from the Gen-ART Review by Avshalom Houri on 2-FEB-2011: Line 357: o An SBE can contain a SF function. -> o An SBE can contain an SF function. Line 421: Function (LUF) to determine a target address, and then is resolves -> Function (LUF) to determine a target address, and then it resolves Line 466: resolving these URIs to URIs for specific protocols such a SIP or -> resolving these URIs to URIs for specific protocols such as SIP or Line 485: particular order and, importantly, not all of them may be used. -> particular order and, importantly, not all of them have to be used. Line 537: SIP proxy. Optionally, a SF may perform additional functions such as -> SIP proxy. Optionally, an SF may perform additional functions such as Line 540: encryption. The SF of a SBE can also process SDP payloads for media -> encryption. The SF of an SBE can also process SDP payloads for media Line 582: The section defines uses of TLS between two SSPs [RFC5246] [RFC5746] -> The section defines the usage of TLS between two SSPs [RFC5246] [RFC5746] |
2011-02-03
|
19 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2011-02-03
|
19 | Tim Polk | [Ballot comment] In section 4, fourth bullet, first sub-bullet, are the communications between the SF and LUF/LRF within the same SBE, or are with the … [Ballot comment] In section 4, fourth bullet, first sub-bullet, are the communications between the SF and LUF/LRF within the same SBE, or are with the LUF/SRF in the other SBE? (I presume SF - SF communications are between SBEs...) Same question for sub-bullets 2 and 3. |
2011-02-03
|
19 | Tim Polk | [Ballot discuss] The security considerations section probably needs to be expanded. (1) The current text talks about "peering providers" but it would be better to … [Ballot discuss] The security considerations section probably needs to be expanded. (1) The current text talks about "peering providers" but it would be better to explain the requirements in terms of the SBE and DBE, or their components. (2) the parameters for use of IPsec may need to be described further. (See Jari's discuss, and RFC 5406) |
2011-02-03
|
19 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded |
2011-02-03
|
19 | Jari Arkko | [Ballot discuss] Section 5.1.3.2. says: In certain deployments the use of IPSec between the signaling functions of the originating and terminating domains can … [Ballot discuss] Section 5.1.3.2. says: In certain deployments the use of IPSec between the signaling functions of the originating and terminating domains can be used as a security mechanism instead of TLS. However, we generally try to avoid general guidance "just use IPsec" and where IPsec usage is recommended for a particular application there should be more specific explanation of how this is done. When such specific explanation is provided it is easier to see if IPsec actually can be used in this particular case and what complications may be involved. For instance, when media flows come from end user devices directly and not from an SBC, capturing all traffic within an IPsec tunnel may be difficult. And the proliferation of many protocols in the real-time communication space makes it hard to capture all traffic even if it comes from the domain itself: SIP, UDP/TCP, H.323, RTP, RTSP, TLS, DTLS, ... |
2011-02-03
|
19 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded |
2011-02-03
|
19 | Sean Turner | [Ballot comment] - In Section 4, the term "Session Border Controller" is not defined in RFC5486 or this document - it seems like a definition … [Ballot comment] - In Section 4, the term "Session Border Controller" is not defined in RFC5486 or this document - it seems like a definition should be included. - In Section 4, the first three bullet points would have "function function" if the acronyms were spelled out - this might be okay but some people view it as incorrect. - In the fourth bullet of Section 4, it's not clear what "can communicate" means - is this a restrictive statement, does it mean that only the left-most function can initiate an exchange or something else altogether. It seems like a clarification is in order. - In Section 5.1.2.2, the term "carrier-of-record" is used. The term is not defined or used elsewhere and seems to be important to the proper functioning of the procedure. A clarification would seem to be in order. - In Section 5.1.3.2, IPSec is mentioned in the originating procedures. There is no corresponding mention in the target procedures section which seems to be an omission that should be corrected. - In Section 9, I'm not following the following senetence: In order to maintain a consistent approach, unique and specialized security requirements common for the majority of peering relationships, should be standardized within the IETF. Are you trying to say: The IETF should standardize unique and specialized security requirements common for the majority of peering relationships? |
2011-02-03
|
19 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
2011-02-03
|
19 | Dan Romascanu | [Ballot discuss] The OPS-DIR review by Bert Wijnen raised the following issue: 'There might be some operational aspects in the sense that sometimes secure/encrypted connections … [Ballot discuss] The OPS-DIR review by Bert Wijnen raised the following issue: 'There might be some operational aspects in the sense that sometimes secure/encrypted connections are needed and other times it may be OK to use unencrypted connections if they are inside the same secure building. So is there not something for an operator to configure in such cases?' I would like to know what is the answer before I approved this document. |
2011-02-03
|
19 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded |
2011-02-03
|
19 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded |
2011-02-02
|
19 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Record from No Objection |
2011-02-02
|
19 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded |
2011-02-02
|
19 | Adrian Farrel | [Ballot comment] You will need to remove the citation from the Abstract. --- You will find it worth your while to shake up your ADs … [Ballot comment] You will need to remove the citation from the Abstract. --- You will find it worth your while to shake up your ADs to find out why [I-D.ietf-speermint-requirements] is stuck. --- There is a minor alignment problem with the lines indicating the edges of the networks in Figure 1. --- Section 3 The originating or indirect SSP would likely perform steps 1-4, the target SSP would likely perform steps 4, and either one is likely to perform step 5. I found this a little vague. Who else could perform these steps? --- 4. Relationships Between Functions/Elements I didn't like this section :-( You have functions and functional elements with the same name. And you appear to also have implementation components with overlapping names. All in all, you appear to be observing that functions are performed by functional elements, and that functional elements can be implemented in different places according to implementation choices. --- 5.1.2.2. Routing Table There is nothing wrong with the text in this section, but it does not mention the "routing table" at all, and that seems odd. |
2011-02-02
|
19 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
2011-02-02
|
19 | Russ Housley | [Ballot comment] Please consider the comments from the Gen-ART Review by Avshalom Houri on 2-FEB-2011: Line 357: o An SBE can … [Ballot comment] Please consider the comments from the Gen-ART Review by Avshalom Houri on 2-FEB-2011: Line 357: o An SBE can contain a SF function. -> o An SBE can contain an SF function. Line 421: Function (LUF) to determine a target address, and then is resolves -> Function (LUF) to determine a target address, and then it resolves Line 466: resolving these URIs to URIs for specific protocols such a SIP or -> resolving these URIs to URIs for specific protocols such as SIP or Line 485: particular order and, importantly, not all of them may be used. -> particular order and, importantly, not all of them have to be used. Line 537: SIP proxy. Optionally, a SF may perform additional functions such as -> SIP proxy. Optionally, an SF may perform additional functions such as Line 540: encryption. The SF of a SBE can also process SDP payloads for media -> encryption. The SF of an SBE can also process SDP payloads for media Line 582: The section defines uses of TLS between two SSPs [RFC5246] [RFC5746] -> The section defines the usage of TLS between two SSPs [RFC5246] [RFC5746] |
2011-02-02
|
19 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
2011-02-02
|
19 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-31
|
19 | Robert Sparks | [Ballot comment] Deep in section 2 (on page 5) the document notes "An SSP may also be referred to as an Internet Telephony Service Provider … [Ballot comment] Deep in section 2 (on page 5) the document notes "An SSP may also be referred to as an Internet Telephony Service Provider (ITSP). While the terms ITSP and SSP are frequently used interchangeably, this document and other subsequent SIP peering-related documents should use the term SSP". Please consider moving, or copying that to the first paragraph of the introduction. |
2011-01-31
|
19 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-26
|
19 | David Harrington | Closed request for Last Call review by TSVDIR with state 'No Response' |
2011-01-25
|
19 | Gonzalo Camarillo | Placed on agenda for telechat - 2011-02-03 |
2011-01-25
|
19 | Gonzalo Camarillo | [Ballot Position Update] New position, Yes, has been recorded for Gonzalo Camarillo |
2011-01-25
|
19 | Gonzalo Camarillo | Ballot has been issued |
2011-01-25
|
19 | Gonzalo Camarillo | Created "Approve" ballot |
2011-01-25
|
19 | Gonzalo Camarillo | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
2011-01-25
|
19 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-01-24
|
19 | Amanda Baber | We understand that this document does not require any IANA actions. |
2011-01-19
|
19 | David Harrington | Request for Last Call review by TSVDIR is assigned to Haibin Song |
2011-01-19
|
19 | David Harrington | Request for Last Call review by TSVDIR is assigned to Haibin Song |
2011-01-18
|
19 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Lt. Mundy |
2011-01-18
|
19 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Lt. Mundy |
2011-01-11
|
19 | Cindy Morgan | Last call sent |
2011-01-11
|
19 | Cindy Morgan | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Session PEERing for Multimedia INTerconnect Architecture) to Informational RFC The IESG has received a request from the Session PEERing for Multimedia INTerconnect WG (speermint) to consider the following document: - 'Session PEERing for Multimedia INTerconnect Architecture' as an Informational RFC 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 2011-01-25. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-speermint-architecture/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-speermint-architecture/ |
2011-01-11
|
19 | Gonzalo Camarillo | Last Call was requested |
2011-01-11
|
19 | Gonzalo Camarillo | State changed to Last Call Requested from Publication Requested::AD Followup. |
2011-01-11
|
19 | Gonzalo Camarillo | Last Call text changed |
2011-01-11
|
19 | (System) | Ballot writeup text was added |
2011-01-11
|
19 | (System) | Last call text was added |
2011-01-11
|
19 | (System) | Ballot approval text was added |
2010-12-20
|
19 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-12-20
|
17 | (System) | New version available: draft-ietf-speermint-architecture-17.txt |
2010-11-17
|
19 | Gonzalo Camarillo | State changed to Publication Requested::Revised ID Needed from Publication Requested. |
2010-11-08
|
19 | Amy Vezza | [Note]: 'Document Shepherd: Jason Livingood (Jason_Livingood@cable.comcast.com)' added by Amy Vezza |
2010-11-08
|
19 | Amy Vezza | Draft Name: draft-ietf-speermint-architecture-16 Draft File Location: https://datatracker.ietf.org/doc/draft-ietf-speermint-architecture/ Proposed Status: Informational RFC ================================================================ WG Name: speermint WG Area: RAI WG Co-Chairs: Jason Livingood & Daryl Malas … Draft Name: draft-ietf-speermint-architecture-16 Draft File Location: https://datatracker.ietf.org/doc/draft-ietf-speermint-architecture/ Proposed Status: Informational RFC ================================================================ WG Name: speermint WG Area: RAI WG Co-Chairs: Jason Livingood & Daryl Malas Document Shepherd: Jason Livingood Shepherding AD: Gonzallo Camarillo ================================================================ Document Shepherd Write-Up: 1A. Who is the Document Shepherd for this document? --Jason Livingood 1B. Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? --Yes 2A. Has the document had adequate review both from key WG members and from key non-WG members? --Yes 2B. Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? --No 3 - Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? --No 4A. Does the Document Shepherd have any specific concerns or issues 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. --No 4B. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. --No 5 - 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? --Strong consensus, no outstanding objections. Any objections raised have been resolved. 6 - Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) --No 7A. Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. --Yes 7B. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? --Yes 7C. If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. --Intended status is Informational RFC 8A. Has the document split its references into normative and informative? --Yes 8B. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? --No 8C. If such normative references exist, what is the strategy for their completion? --N/A 8D. Are there normative references that are downward references, as described in [RFC3967]? --No 8E. If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. --N/A 9A. Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? --Yes 9B. If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? --N/A 9C. Are the IANA registries clearly identified? --N/A 9D. If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? --N/A 9E. Does it suggest a reasonable name for the new registry? See [RFC2434]. --N/A 9F. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? --N/A 10 - Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? --Yes, N/A in this document. ================================================================ Document Announcement Write-Up: 1 - Technical Summary This document defines a peering architecture for the SIP between two or more service provider domains. 2 - Working Group Summary There is consensus in the WG to publish this document. A Working Group Last Call has been issued, and we have achieved consensus and resolved all concerns. All changes suggested by the WG have been made to this draft. A NITS review has also been performed and those changes made as well. 3 - Document Quality Good quality - no issues 4 - Personnel Document Shepherd: Jason Livingood Responsible AD: Gonzallo Camarillo IANA Experts Required: No |
2010-11-08
|
19 | Amy Vezza | Draft Added by Amy Vezza in state Publication Requested |
2010-11-08
|
16 | (System) | New version available: draft-ietf-speermint-architecture-16.txt |
2010-11-08
|
15 | (System) | New version available: draft-ietf-speermint-architecture-15.txt |
2010-11-08
|
14 | (System) | New version available: draft-ietf-speermint-architecture-14.txt |
2010-10-25
|
13 | (System) | New version available: draft-ietf-speermint-architecture-13.txt |
2010-10-22
|
12 | (System) | New version available: draft-ietf-speermint-architecture-12.txt |
2010-08-30
|
11 | (System) | New version available: draft-ietf-speermint-architecture-11.txt |
2010-03-09
|
10 | (System) | New version available: draft-ietf-speermint-architecture-10.txt |
2009-11-11
|
09 | (System) | New version available: draft-ietf-speermint-architecture-09.txt |
2009-03-02
|
08 | (System) | New version available: draft-ietf-speermint-architecture-08.txt |
2008-11-04
|
07 | (System) | New version available: draft-ietf-speermint-architecture-07.txt |
2008-05-02
|
06 | (System) | New version available: draft-ietf-speermint-architecture-06.txt |
2008-02-25
|
05 | (System) | New version available: draft-ietf-speermint-architecture-05.txt |
2007-08-13
|
04 | (System) | New version available: draft-ietf-speermint-architecture-04.txt |
2007-04-24
|
03 | (System) | New version available: draft-ietf-speermint-architecture-03.txt |
2006-10-20
|
02 | (System) | New version available: draft-ietf-speermint-architecture-02.txt |
2006-09-20
|
01 | (System) | New version available: draft-ietf-speermint-architecture-01.txt |
2006-08-09
|
00 | (System) | New version available: draft-ietf-speermint-architecture-00.txt |