3GPP SIP URI Inter-Operator Traffic Leg Parameter
draft-holmberg-dispatch-iotl-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-05-15
|
06 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-05-01
|
06 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-04-28
|
06 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2015-03-20
|
06 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2015-03-20
|
06 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2015-03-19
|
06 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2015-03-19
|
06 | (System) | IANA Action state changed to In Progress |
2015-03-18
|
06 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-03-18
|
06 | (System) | RFC Editor state changed to EDIT |
2015-03-18
|
06 | (System) | Announcement was received by RFC Editor |
2015-03-18
|
06 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-03-18
|
06 | Amy Vezza | IESG has approved the document |
2015-03-18
|
06 | Amy Vezza | Closed "Approve" ballot |
2015-03-18
|
06 | Amy Vezza | Ballot approval text was generated |
2015-03-18
|
06 | Amy Vezza | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2015-03-18
|
06 | Amy Vezza | Ballot writeup was changed |
2015-02-19
|
06 | Christer Holmberg | New version available: draft-holmberg-dispatch-iotl-06.txt |
2015-02-12
|
05 | Stephen Farrell | [Ballot comment] Thanks for handling my (pretty vague:-) discuss --- OLD Comments below, I didn't check if changes resulted or not, happy to chat about … [Ballot comment] Thanks for handling my (pretty vague:-) discuss --- OLD Comments below, I didn't check if changes resulted or not, happy to chat about it if you want. - As usual, I dislike that we're making special assumptions about 3gpp networks. I think any stuff like this is liable to leak over so saying "just 3gpp" should not be a get out of jail card. - section 3 does not actually define any uses for the iotl parameter but simply repeats page 4 as far as I can see. - 5.1, last para: I don't get how the "must not" there doesn't apply here and say that this entire idea is busted - can you explain? - section 7: the 2119 terms here are bogus. |
2015-02-12
|
05 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2015-02-12
|
05 | Christer Holmberg | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-02-12
|
05 | Christer Holmberg | New version available: draft-holmberg-dispatch-iotl-05.txt |
2015-02-05
|
04 | Cindy Morgan | IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation |
2015-02-05
|
04 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-02-05
|
04 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-02-05
|
04 | Jari Arkko | [Ballot comment] There has been a discussion of changes with respect to a Gen-ART review by Robert Sparks. It would be good to ensure that … [Ballot comment] There has been a discussion of changes with respect to a Gen-ART review by Robert Sparks. It would be good to ensure that this discussion is finished and the necessary changes are folded in, before the draft is approved. |
2015-02-05
|
04 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-02-05
|
04 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2015-02-05
|
04 | Stephen Farrell | [Ballot discuss] I'm not really seeing what it is these are used for, so I'm not sure if the security considerations here are good enough … [Ballot discuss] I'm not really seeing what it is these are used for, so I'm not sure if the security considerations here are good enough or not. If these values are used for security sensitive purposes then I suspect more needs to be said. For example, I think what you ought be saying in the security considerations is what can go wrong if the various parties involved misbehave and not simply asserting that some of the parties need to trust one another. (Esp since we've seen recent cases where operator network devices were successfully attacked and used to futher attack the network given that information was being sent about in a very "trusting" fashion.) So, apologies that this discuss is a bit vague for now, but can you explain what it is that these values are used for? |
2015-02-05
|
04 | Stephen Farrell | [Ballot comment] - As usual, I dislike that we're making special assumptions about 3gpp networks. I think any stuff like this is liable to leak … [Ballot comment] - As usual, I dislike that we're making special assumptions about 3gpp networks. I think any stuff like this is liable to leak over so saying "just 3gpp" should not be a get out of jail card. - section 3 does not actually define any uses for the iotl parameter but simply repeats page 4 as far as I can see. - 5.1, last para: I don't get how the "must not" there doesn't apply here and say that this entire idea is busted - can you explain? - section 7: the 2119 terms here are bogus. |
2015-02-05
|
04 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2015-02-04
|
04 | Barry Leiba | [Ballot comment] In Sections 5.2 and 6.2, you always show the parameter values in specific case, such as "homeA-homeB", though they're case-insensitive, and could just … [Ballot comment] In Sections 5.2 and 6.2, you always show the parameter values in specific case, such as "homeA-homeB", though they're case-insensitive, and could just as well be presented as "homea-homeb" or "HOMEA-HOMEB". I wonder whether it's worth reminding readers of that with a sentence in Section 6.2, just to avoid bad implementations. Or is that simply a well-enough-known thing in SIP that it's not worth bothering? And the error in the ABNF that Spencer points out does matter, and needs to be fixed. I have every confidence that it will be. |
2015-02-04
|
04 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-02-04
|
04 | Spencer Dawkins | [Ballot comment] I didn't figure out that the values were an enumerated set until Section 5/page 7. That's not horrible, but I'd think it would … [Ballot comment] I didn't figure out that the values were an enumerated set until Section 5/page 7. That's not horrible, but I'd think it would be easier for first-time readers if you said something like This draft defines the following iotl values: o "homeA-homeB" o "homeB-visitedB" o "visitedA-homeA" o "homeA-visitedA" o "visitedA-homeB" early in the document. Not a big deal, just a suggestion. Note that I'm a Yes. (While typing this, I noticed that " visitedA-homeB" had a leading space in the ABNF. I'm not wizard enough to know whether that matters, so I thought I'd ask before AUTH48 ...) |
2015-02-04
|
04 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2015-02-04
|
04 | Alissa Cooper | [Ballot comment] This text appears in both Sections 1 and 2, but only needs to be stated once: "The SIP URI 'iotl' parameter defined in … [Ballot comment] This text appears in both Sections 1 and 2, but only needs to be stated once: "The SIP URI 'iotl' parameter defined in this document has known uses in 3GPP networks. Usage in other networks is also possible." In Section 7: s/The information/The information in the iotl parameter/ |
2015-02-04
|
04 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2015-02-04
|
04 | Cindy Morgan | Changed consensus to Yes from Unknown |
2015-02-04
|
04 | Richard Barnes | Notification list changed to gsalguei@cisco.com, r.jesske@telekom.de, md3135@att.com, draft-holmberg-dispatch-iotl.all@tools.ietf.org, christer.holmberg@ericsson.com, jan.holm@ericsson.com from gsalguei@cisco.com, r.jesske@telekom.de, md3135@att.com, draft-holmberg-dispatch-iotl.all@ietf.org, christer.holmberg@ericsson.com … Notification list changed to gsalguei@cisco.com, r.jesske@telekom.de, md3135@att.com, draft-holmberg-dispatch-iotl.all@tools.ietf.org, christer.holmberg@ericsson.com, jan.holm@ericsson.com from gsalguei@cisco.com, r.jesske@telekom.de, md3135@att.com, draft-holmberg-dispatch-iotl.all@ietf.org, christer.holmberg@ericsson.com, jan.holm@ericsson.com |
2015-02-04
|
04 | Benoît Claise | [Ballot comment] While reading through the draft I wondered a few times: "but what does iotl stand for?" Maybe I'm stupid, maybe I simply didn't … [Ballot comment] While reading through the draft I wondered a few times: "but what does iotl stand for?" Maybe I'm stupid, maybe I simply didn't pay enough attention to the document title, or maybe I should stop reading drafts late at night, but a simple reference to "Inter Operator Traffic Leg", next to iotl, somewhere in the intro would have helped me. Thanks Richard for showing me the light :-) |
2015-02-04
|
04 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-02-04
|
04 | Kathleen Moriarty | [Ballot comment] Thanks for your work on this draft, I just have one question: Should this draft have a reference to either the framework or … [Ballot comment] Thanks for your work on this draft, I just have one question: Should this draft have a reference to either the framework or a base SIP RFC that describes security and privacy considerations? |
2015-02-04
|
04 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-02-03
|
04 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2015-02-03
|
04 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2015-02-03
|
04 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2015-02-02
|
04 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2015-02-02
|
04 | Richard Barnes | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2015-02-02
|
04 | Richard Barnes | Placed on agenda for telechat - 2015-02-05 |
2015-02-02
|
04 | Richard Barnes | Ballot has been issued |
2015-02-02
|
04 | Richard Barnes | [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes |
2015-02-02
|
04 | Richard Barnes | Created "Approve" ballot |
2015-02-02
|
04 | Richard Barnes | Ballot writeup was changed |
2015-01-15
|
04 | Robert Sparks | Request for Last Call review by GENART Completed: Ready. Reviewer: Robert Sparks. |
2015-01-15
|
04 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Paul Hoffman. |
2015-01-08
|
04 | Christer Holmberg | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-01-08
|
04 | Christer Holmberg | New version available: draft-holmberg-dispatch-iotl-04.txt |
2015-01-08
|
03 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2014-12-29
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2014-12-29
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2014-12-28
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Nevil Brownlee. |
2014-12-23
|
03 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2014-12-23
|
03 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-holmberg-dispatch-iotl version -03. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions … IESG/Authors/WG Chairs: IANA has reviewed draft-holmberg-dispatch-iotl version -03. 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 understands that, upon approval of this document, there is a single action which needs to be completed. In the SIP/SIPS URI Parameters subregistry of the Session Initiation Protocol (SIP) Parameters registry located at: https://www.iana.org/assignments/sip-parameters/ a single, new URI parameter is to be registered as follows: Parameter Name: iotl Predefined Values: Yes Reference: [ RFC-to-be ] IANA understands that this is the only action 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. |
2014-12-18
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Paul Hoffman |
2014-12-18
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Paul Hoffman |
2014-12-16
|
03 | Christer Holmberg | New version available: draft-holmberg-dispatch-iotl-03.txt |
2014-12-15
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Nevil Brownlee |
2014-12-15
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Nevil Brownlee |
2014-12-11
|
02 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2014-12-11
|
02 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Sender: Subject: Last Call: (3rd-Generation Partnership Project (3GPP) SIP URI … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Sender: Subject: Last Call: (3rd-Generation Partnership Project (3GPP) SIP URI Inter Operator Traffic Leg parameter) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - '3rd-Generation Partnership Project (3GPP) SIP URI Inter Operator Traffic Leg parameter' 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-08. 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 In 3rd-Generation Partnership Project (3GPP) networks, the signalling path between a calling user and a called user can be partioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to different operators, and will have its own characteristics that can be different from other traffic legs in the same call. The directionality in traffic legs relates to a SIP request creating a dialogue and stand-alone SIP request. A traffic leg might be associated with multiple SIP dialogs, e.g. in case a B2BUA which modifies the SIP dialog identifier is located within the traffic leg. This document defines a new SIP URI parameter, 'iotl', which can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs). The 'iotl' parameter is defined in order to fulfil requirements from the 3GPP. The file can be obtained via http://datatracker.ietf.org/doc/draft-holmberg-dispatch-iotl/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-holmberg-dispatch-iotl/ballot/ No IPR declarations have been submitted directly on this I-D. |
2014-12-11
|
02 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2014-12-11
|
02 | Richard Barnes | Last call was requested |
2014-12-11
|
02 | Richard Barnes | Ballot approval text was generated |
2014-12-11
|
02 | Richard Barnes | IESG state changed to Last Call Requested from Publication Requested |
2014-12-11
|
02 | Richard Barnes | Ballot writeup was changed |
2014-12-11
|
02 | Richard Barnes | Ballot writeup was generated |
2014-12-11
|
02 | Richard Barnes | Last call announcement was generated |
2014-10-24
|
02 | Cindy Morgan | Intended Status changed to Proposed Standard |
2014-10-24
|
02 | Cindy Morgan | IESG process started in state Publication Requested |
2014-10-24
|
02 | Cindy Morgan | PROTO questionnaire for: draft-holmberg-dispatch-iotl-02 To be Published as: Proposed Standard Prepared by: Gonzalo Salgueiro (gsalguei@cisco.com) on 23 October 2014 (1) What type … PROTO questionnaire for: draft-holmberg-dispatch-iotl-02 To be Published as: Proposed Standard Prepared by: Gonzalo Salgueiro (gsalguei@cisco.com) on 23 October 2014 (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? This document is requested to be published as a Proposed Standards. This is the proper type of RFC as it makes normative statements in defining a new SIP URI parameter. This RFC type is indicated on the title page. (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: In 3rd-Generation Partnership Project (3GPP) networks, the signaling path between a calling user and a called user can be partitioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to different operators, and will have its own characteristics that can be different from other traffic legs in the same call. The directionality in traffic legs relates to a SIP request creating a dialogue and stand-alone SIP request. A traffic leg might be associated with multiple SIP dialogs, e.g. in case a B2BUA which modifies the SIP dialog identifier is located within the traffic leg. This document defines a new SIP URI parameter, 'iotl', which can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs). Working Group Summary: Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document? The document was considered in the DISPATCH WG. It was agreed to scope the document to 3GPP environments, and due to that publish the document as AD sponsored. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The document has been adopted by 3GPP, and a number of vendors within the 3GPP community have indicated plans to implement the specification. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Gonzalo Salgueiro (INSIPID WG co-chair) is the Document Shepherd. Richard Barnes is 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. Document shepherd considers this document ready for IESG review and has reviewed idnits output and IANA Considerations sections. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? There are no concerns about the depth or breadth of the reviews. (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. No. (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 interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are no specific concerns or issues. (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 they are not aware of any IPR disclosures related to the document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been submitted on draft-holmberg-dispatch-iotl. (9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? There is strong consensus and interest behind this document within the 3GPP community. (10) 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 publicly available.) Nobody has threatened an appeal or otherwise indicated 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 passes idnits 2.13.00 (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Specialized formal review procedures for this document not applicable. (13) Have all references within this document been identified as either normative or informative? Yes, all references within the document have been identified as normative. (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? No, all normative references within the document have been published as RFCs. (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. No, there are no downward normative references. (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 interested community considers it unnecessary. No, the publication of the document will not change the status of any existing RFCs. (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 shepherd has reviewed the IANA considerations section and has confirmed that the registration is correct. (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. This document defines no new IANA registries. (19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. The text version of the document was created using the XML2RFC tool, and was verified using the IDNITS tool. Spell checking was performed using Microsoft Word. |
2014-10-24
|
02 | Cindy Morgan | Stream changed to IETF from None |
2014-10-23
|
02 | Gonzalo Salgueiro | Changed document writeup |
2014-10-23
|
02 | Gonzalo Salgueiro | Changed document writeup |
2014-10-23
|
02 | Gonzalo Salgueiro | Changed document writeup |
2014-09-21
|
02 | Richard Barnes | Document shepherd changed to Gonzalo Salgueiro |
2014-08-21
|
02 | Christer Holmberg | New version available: draft-holmberg-dispatch-iotl-02.txt |
2014-06-13
|
01 | Christer Holmberg | New version available: draft-holmberg-dispatch-iotl-01.txt |
2014-04-28
|
00 | Christer Holmberg | New version available: draft-holmberg-dispatch-iotl-00.txt |