Subject: [salud] Reply to Pearl Liang (IANA)

From: [email-masked] (Dale R. Worley)
Date: Fri, 25 Apr 2014 15:59:33 -0400

[as an author]

I have reformatted and somewhat revised my proposed response to IANA.
The authors generally seem to agree with my response; I want to
provide the final draft of the message to verify our agreement and
solicit any improvements you have.  If I don't hear otherwise, I will
send this on Wednesday morning.

Dale
----------------------------------------------------------------------
From: [email-masked] (Dale R. Worley)
Sender: [email-masked] (Dale R. Worley)
To: [email-masked]
Subject: [IANA #755327] Last Call: <draft-ietf-salud-alert-info-urns-12.txt> (URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)) to Proposed Standard
CC: [email-masked],
        [email-masked]
--text follows this line--
> IANA understands that, upon approval of this document, there are two
> actions which IANA must complete.

This is correct.

> First, in the Formal URN Namespaces subregistry of the Uniform
> Resource Names (URN) Namespaces registry located at:
> 
> http://www.iana.org/assignments/urn-namespaces/
> 
> a new URN will be registered as follows:
> 
> URN Namespace: alert
> Reference: [ RFC-to-be ]

This is correct.

> Second, a new registry called the Alert URN Identifiers registry is
> to be created.

This is correct.

> New URNs in the Alert URN Identifiers Registry are created through
> Standards Action as defined by RFC 5226.

The process is more complex than that; the details are in section 9.1
of the RFC:

   The policy for adding a new standard <alert-category> is 'Standards
   Action'.  The policy for adding <alert-identifiers>s or patterns of
   <alert-identifiers>s within a particular <alert-category> may differ
   for each <alert-category>and MUST be defined by the document defining
   the corresponding <alert-category>.

That is:  New "alert-categories" (items that do not contain a colon)
are created by Standards Action.  The policy for new
"alert-identifiers" (items containing a colon) is set by the
alert-category that it starts with.  All existing alert-categories
specify the policy Standards Action for adding alert-identifiers.  The
update policy for any alert-category will be stated in the RFC that
defines it, so the "Reference" column implicitly specifies the update
policy for that alert-category.

Perhaps it would help to add a column "update policy" to this
registry, which for each alert-category will contain the updating
policy for alert-identifiers in that alert-category.  (This column
would be empty for alert-identifiers.)

Or perhaps this registry should be divided into two registries, one
for alert-categories (listing an update policy for the related
alert-identifiers) and a second registry for the alert-identifiers
(without an update policy column).

What does IANA recommend for organizing this information?

> QUESTIONs: 
> Should this new registry a sub-registry of the registry
> 'Service URN Labels' located at 
> http://www.iana.org/assignments/urn-serviceid-labels?  Or is this new 
> registry 'Alert URN Identifiers' a stand-alone with a brand new URL?  
> 
> Then, if the latter, what should be the name of the master "Parameter" 
> registry?  Is Uniform Resource Names (URN)?  See iana.org/protocols for 
> a list of main registry pages and the registries they include. 

The new registry will be a new registry named "Alert URN Identifiers"
under the protocol name "Uniform Resource Names (URN)", and thus will
be alongside "URN Service Labels", not a sub-registry of it.

> IANA understands that the initial registrations in this new registry
> are to be collected from section 9.2.1 through 9.2.6 of the current
> document. IANA understands that the initial registry will look like
> this:
> 
> <alert-category>/ Reference Description
> <alert-identifier>
> --------------------------------------------------------------------------
> service [ RFC-to-be ] Specific telephony
> service used in this
> call
> service:normal [ RFC-to-be ] Normal ring/ringback
> rendering (default value)
> service:call-waiting [ RFC-to-be ] Call waiting was
> initiated at the other side
> of the call
> service:forward [ RFC-to-be ] Call has been forwarded
> service:recall:callback [ RFC-to-be ] Recall due to callback
> service:recall:hold [ RFC-to-be ] Recall due to call hold
> service:recall:transfer [ RFC-to-be ] Recall due to transfer
> source [ RFC-to-be ] Classification
> of the other party
> to the call
> source:unclassified [ RFC-to-be ] Unclassified ring/ringback
> rendering (default value)
> source:internal [ RFC-to-be ] User at the other side of
> the call is internal to the
> enterprise or PBX system
> source:external [ RFC-to-be ] User at the other side of
> the call is external to the
> enterprise or PBX system
> source:friend [ RFC-to-be ] User at the other side of
> the call is a friend
> source:family [ RFC-to-be ] User at the other side of
> the call is a family member
> priority [ RFC-to-be ] Priority of the
> call
> priority:normal [ RFC-to-be ] Normal ring/ringback
> rendering (default value)
> priority:low [ RFC-to-be ] Low priority call.
> priority:high [ RFC-to-be ] High priority call
> duration [ RFC-to-be ] Duration of alerting signal
> alerting signal
> duration:normal [ RFC-to-be ] Normal ring/ringback
> rendering (default value)
> duration:short [ RFC-to-be ] Shorter than normal
> duration:long [ RFC-to-be ] Longer than normal
> delay [ RFC-to-be ] Delay of rendering of alerting
> of alerting signal
> delay:none [ RFC-to-be ] Immediate alerting
> (default value)
> delay:yes [ RFC-to-be ] Delayed alerting
> locale [ RFC-to-be ] Location-specific
> alerting signals
> locale:default [ RFC-to-be ] Alerting not location
> specific
> (default value)
> locale:country:<ISO 3166-1 country code>
> [ RFC-to-be ] Alerting according to the
> conventions of the specified
> country
> 
> IANA understands that these two actions are the only ones that need
> to be completed upon approval of this document.

The list of initial registrations in your e-mail is correct (allowing
for the irregular use of line breaks in the original e-mail).  That
is, it is correct in regard to the data items to be recorded; the
proposed registry may be organized differently if IANA recommends
doing so (as discussed above).

Dale, for the authors of ietf-salud-alert-info-urns
----------------------------------------------------------------------
[EOF]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 Apr 2014 16:09:21 -0400

Dale,

My only comment is that it is probably better that we decide what we 
want the registry to look like than to let iana do it for us.

	Thanks,
	Paul

On 4/25/14 3:59 PM, Dale R. Worley wrote:
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 30 Apr 2014 18:09:59 -0400

[as an author]

> From: Paul Kyzivat <[email-masked]>

> want the registry to look like than to let iana do it for us.

I am looking at the following pages for examples:
the "Uniform Resource Names (URN)" section of http://www.iana.org/protocols
the "Service URN Labels" page,
http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels.xhtml
the "Sieve Extensions" page,
http://www.iana.org/assignments/sieve-extensions/sieve-extensions.xhtml
(because it has complicated registration procedures).

It seems to me that we want "Alert URN Identifiers" to be an item
under "Uniform Resource Names (URN)", and we want it to point to a
separate web page, as "Service URN Labels" does.

How do we want to handle the registration procedures specification?
IANA wants to know this and probably needs to know it.

Most tables give the registration procedures in the header of the
table.  E.g., 

    URN Service Labels

    Registration Procedure(s)
	Standards Action

    Reference
	[RFC5031]

But the Sieve table has a separate table that gives registration
procedures:

    Range                                 Registration Procedures
    -----                                 -----------------------
    vendor-controlled                     First Come First Served
        (name begins with "vnd.")         
    IETF-controlled (no "vnd." prefix)    Standards track or
                                          IESG-approved experimental RFC

It would be simpler if there was one combined table, but it would be
difficult to find a place to specify that alert-categories require
standards action.

Perhaps we should separate the alert-categories into a separate table:

    Alert URN Identifiers alert-categories

    Registration Procedure(s)
	Standards Action

    Reference
	[RFCxxxx]

    Name       Description               Reference     Registration Procedure(s)
					               for alert-identifiers
    ----       -----------               ---------     -------------------------
    service    Specific telephony        [RFCxxxx]     Standards Action
               service used in this call
    source     Classification of the     [RFCxxxx]     Standards Action
               other party to the call

and then

    Alert URN Identifiers alert-identifiers

    Registration Procedure(s)
	As specified in the corresponding alert-category

    Reference
	[RFCxxxx]

    Name              Description                                    Reference
					          
    ----              -----------                                    ---------
    service:normal   Normal ring/ringback rendering (default value)  [RFCxxxx]
    service:call-waiting                                             [RFCxxxx]
                     Call waiting was initiated at the other side
                     of the call
    source:unclassified	                                             [RFCxxxx]
                     Unclassified ring/ringback rendering (default
	             value)
    source:internal  User at the other side of the call is internal  [RFCxxxx]
                     to the enterprise or PBX system

What do people think?

Dale