IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespace for Mission Critical Push To Talk Service
draft-holmberg-dispatch-mcptt-rp-namespace-05

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-holmberg-dispatch-mcptt-rp-namespace-03.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Resource-Priority Namespaces subregistry of the Session Initiation Protocol (SIP) Parameters registry located at:

https://www.iana.org/assignments/sip-parameters/

two new namespaces are to be registered as follows:

Namespace: mcpttp
Namespace Numerical Value: [ TBD-at-registration ]
Levels: 16
Algorithm: preemption
Intended code: No
New warn code: No
New resp. reference: [ RFC-to-be ]

Namespace: mcpttq
Namespace Numerical Value: [ TBD-at-registration ]
Levels: 16
Algorithm: queuing
Intended code: No
New warn code: No
New resp. reference: [ RFC-to-be ]

IANA Question --> are the sixteen priority levels described in section 3 of this document for each of the two, new namespaces to be registered in the Resource-Priority Priority-values subregistry of the Session Initiation Protocol (SIP) Parameters registry located at:

https://www.iana.org/assignments/sip-parameters/ ??

The IANA Services Operator 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.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ben@nostrum.com, draft-holmberg-dispatch-mcptt-rp-namespace@ietf.org, r.jesske@telekom.de
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IANA Registration of New Session Initiation Protocol (SIP) Resource- Priority Namespace for Mission Critical Push To Talk service) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'IANA Registration of New Session Initiation Protocol (SIP) Resource-
  Priority Namespace for Mission Critical Push To Talk service'
  as 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 2017-01-09. 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 creates an additional Session Initiation Protocol (SIP)
  Resource-Priority namespace to meet the requirements of the 3GPP
  defined Mission Critical Push To Talk, and places this namespace in
  the IANA registry.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-holmberg-dispatch-mcptt-rp-namespace/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-holmberg-dispatch-mcptt-rp-namespace/ballot/


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

This is my AD Evaluation of draft-holmberg-dispatch-mcptt-rp-namespace-02. I have some questions about how the 3GPP MCPTT priority requirements map into these namespaces. I would like those questions to be resolved prior to IETF Last Call. I also have some minor/editorial comments that can be handled whenever the next update occurs.

Major:

It's not clear to me how the priority requirements from TS 22.179 map onto the namespaces defined here. Specifically, that document describes a fairly complex priority hierarchy, where the user role, group type, call type, etc are taken into account, with the potential for dynamically rearranging the hiearchy. It also suggests that priority information is included in requests, and stays with the requests. It's not clear to me if people believe that information can be distilled down to a pair of 0-15 values inserted by a UAC, or whether a downstream element might need more granular information. Are there later stage 3GPP documents that talk about this?

Also, as this draft mentions, TS 22.179 says "at least 8 and preferably 30" priority levels are required. It's not clear to me of that's intended to be for preemption, queueing, or both. How does that map to a preemption namespace and a queueing name space, each with 16 values?

Now, the answer to all of this might be that 3GPP has more work to do, and that these namespaces will enable that work. (similar arguments are made in RFC 5478). That's not necessarily a problem, but we would need grounds to believe that these namespaces will actually support the end result. And in any case, if that is true that should probably be discussed in this draft.


Minor:

-2: Is it reasonable to say that use of this name space is undefined or not recommended outside of such a network?

Editorial:

- 1, 2nd paragraph: "... where each user has the ability to gain access to the permission to talk ..."
That wording seems unnecessarily complicated. I suggest s/... has the ability to gain access to the permission to talk ... / ... can gain permission to talk ...

- 1, 3rd paragraph: "MCPTT is primarily targeting to provide..."
s/targeting/targeted