Skip to main content

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