Subject: [cuss] IANA Policy for New Packages in UUI Mechanism Draft (was RE: I-D Action: draft-ietf-cuss-sip-uui-08.txt)

From: James Rafferty <[email-masked]>
Date: Tue, 8 Jan 2013 14:00:27 -0500

In the AD review of the current UUI mechanism draft (draft-ietf-cuss-sip-uui-08.txt), one question which came up (as per below) was on the IANA policy which should be specified within the draft for cases where users want to register a new UUI package.   Over the past year, there's been some limited discussion on this on the list.  

In RFC 5226 (IANA Considerations Section in RFCs), there are a variety of choices which are possible for an IANA policy, including "Private use", "
Expert Review",  "Specification Required", "RFC Required", "Standards Action" and several others.    

The policy which is currently shown for the -08 version of the draft is described as: "New uui-packages
 MUST follow the "RFC Required" guideline as defined in [RFC5226] and shall be registered as a result of a standards track RFC."  In his comment below, Gonzalo correctly points out that a more concise description in RFC 5226 which corresponds to requiring a standards track RFC approved by the IESG is "Standards Action".     

To date, the only package on target to be registered with IANA is the "ISDN Package," which is targeted as a standards track RFC.   If we continue along the current path, the next UUI mechanism draft will use the "Standards Action" terminology as the IANA Policy for adding a new package.   

So the question Alan Johnston and I want to pose to the list is whether there are any objections to proceeding with the current direction of "Standards Action" as the policy for establishing new UUI packages in the IANA registry in the UUI mechanism draft.   

If you have opinions on this matter, please send them to the list. 

Thanks, 

James    
-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Monday, January 07, 2013 6:53 AM
To: James Rafferty
Cc: [email-masked]
Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-08.txt

Hi James,

the IANA policy to be used is an important issue and, thus, needs to be discussed in the WG. For your comments, it seems the "Standards Action"
policy in RFC 5226 is what you are after. In any case, regardless of the policy you finally choose, please engage the group so that we can move this draft forward.

With respect to the other comment, I agree removing the word "only"
would make the sentence clearer.

Thanks,

Gonzalo

On 28/12/2012 5:15 PM, James Rafferty wrote:
> Gonzalo,
> 
> Please see my comments below:  
> 
> James
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Gonzalo Camarillo
> Sent: Monday, December 03, 2012 3:37 AM
> To: [email-masked]
> Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-08.txt
> 
> Authors,
> 
> thanks for addressing my comments. I still have a couple of quick questions.
> 
> The new draft uses RFC Required as its IANA policy. I have not seen any discussions on the mailing list about this. Has the WG considered the Specification Required policy as well? Given that the draft gives guidelines on what is appropriate to register and what is not, having a policy that involves some type of technical review (e.g., by an expert) would seem a natural choice. What were the reasons considered when making this decision?
> 
> JR - There was a brief exchange between Keith Drage and Alan Johnston on this topic around Sept. 19, 2011 on the CUSS list, but I didn't see any immediate further discussion.   See the emails with Subject:    Registration requirements for new parameter values in the User-to-User header field.   There were several items to be clarified at that time around what kind of content needed to be specified for new UUI applications as a result of October list discussions and an interim meeting.   The result was additional IANA verbiage being added within the -03 version of the document in Section 6.4 - 6.5  stating that a Standards Track RFC was required for registering new values for the content and encoding parameters of the UUI header.    
> 
> I had a comment on the first sentence of Section 4.1 that does not seem to have been addressed. What is the meaning of "only" in this sentence?
> 
>>    The User-to-User (UUI) header field can be present in INVITE requests
>>    and responses only and in BYE requests and responses.
> 
> JR - The use of "only" here now looks superfluous, since the sentence goes on to discuss another context where the UUI header can be used; it probably would be clearer if "only" is deleted.   
> 
> Thanks,
> 
> Gonzalo
> 
> 
> On 02/12/2012 1:44 AM, [email-masked] wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>  This draft is a work item of the Call Control UUI Service for SIP Working Group of the IETF.
>>
>> 	Title           : A Mechanism for Transporting User to User Call Control Information in SIP
>> 	Author(s)       : Alan Johnston
>>                           James Rafferty
>> 	Filename        : draft-ietf-cuss-sip-uui-08.txt
>> 	Pages           : 18
>> 	Date            : 2012-12-01
>>
>> Abstract:
>>    There is a class of applications which benefit from using SIP to
>>    exchange User to User Information (UUI) data during session
>>    establishment.  This information, known as call control UUI data, is
>>    a small piece of data inserted by an application initiating the
>>    session, and utilized by an application accepting the session.  The
>>    rules which apply for a specific application are defined by a UUI
>>    package.  This UUI data is opaque to SIP and its function is
>>    unrelated to any basic SIP function.  This document defines a new SIP
>>    header field, User-to-User, to transport UUI data, along with an
>>    extension mechanism.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-08
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-cuss-sip-uui-08
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> cuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/cuss
>>
>>
> 
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Jan 2013 14:43:30 -0500

Early on I registered a concern about the policy, but eventually I gave 
up on it. But let me try again.

One of the major uses of UUI is for call centers. They are likely to 
connect a caller to an IVR in order to get info about the caller. Once 
they have learned enough about what the caller wants, they transfer the 
call to an agent. When doing so they want to convey info learned about 
the caller, so it can be used by a computer to provide the agent with info.

Traditionally this was handled using "ITU-T DSS1 User-user information 
element [Q931], [Q957.1] and ITU-T Q.763 User-to-user information 
parameter [Q763] data". That uses one octet as a "protocol 
discriminator" and 128 octets of data. How this is used is all 
proprietary and ad hoc. A receiver of this data must just "know" what 
format the data will take. CUSS addresses backwards compatibility with 
this via the package "isdn-uui" registered by draft-ietf-cuss-sip-uui-isdn.

IMO the intent of the UUI "purpose" and "content" parameters was to 
improve on the legacy situation, by allowing a sender to identify more 
about the data. This way a receiver can determine if it knows how to 
interpret what it has received.

But for that to work in practice, it must be feasible for those who 
define the data to define the formats. For call center stuff, the data 
to be transmitted, and the format for representing it is likely to be 
defined by either:
- the vendor of a particular IVR system or call center application,
- OR, an individual enterprise that is deploying an IVR/call center.

Neither of these is very likely to find it practical to publish an RFC.

- A sw vendor could probably manage to register via a FCFS policy.

- An individual enterprise probably won't find it acceptable to
   register *anything*.

My personal feeling is that there probably ought to be several 
mechanisms, such as there are for feature tags.

I went along with the current approach because I wasn't getting buy-in 
for anything else, and I figure that we can *start* with a restrictive 
policy and then relax it later. In the short term I gather everyone 
intends to stick with legacy compatibility and use what is defined in 
draft-ietf-cuss-sip-uui-isdn.

	Thanks,
	Paul