Subject: [sipcore] Establishing a "Priority" header field registry

From: Adam Roach <[email-masked]>
Date: Tue, 06 Nov 2012 10:53:41 -0500

[as an individual]

The document draft-ietf-ecrit-psap-callback has identified a desire to 
add a new value to the "Priority" header field for SIP. While RFC 3261 
clearly intended the values in this header field to be extensible, it 
did not define a registry of such values.

To address this oversight, I have put together a small draft that 
defines such a registry and populates it with the values defined by RFC 
3261. Because this is a correction to the core SIP specification, it is 
my belief that it falls within the charter of the SIPCORE working group.

The only real open issue, in my opinion, is the IANA registration policy 
that should apply to new "Priority" header field values. To avoid 
blocking any work in ECRIT, we need to move this work (or something 
equivalent) forward very quickly. If you have any interest in the topic, 
please review and comment with some urgency.

http://www.ietf.org/id/draft-roach-sipcore-priority-00.txt

[The following request is being made in my WG chair role]
As this is a SIPCORE matter, please discuss it on the SIPCORE list 
rather than the ECRIT list.

Thanks!

/a

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Nov 2012 16:04:36 +0000

Hi,

I support this work. 

My only question on the draft is whether there should be a registration template, which is used when registering a value.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 6. marraskuuta 2012 17:54
To: [email-masked]; [email-masked]
Subject: [sipcore] Establishing a "Priority" header field registry

[as an individual]

The document draft-ietf-ecrit-psap-callback has identified a desire to add a new value to the "Priority" header field for SIP. While RFC 3261 clearly intended the values in this header field to be extensible, it did not define a registry of such values.

To address this oversight, I have put together a small draft that defines such a registry and populates it with the values defined by RFC 3261. Because this is a correction to the core SIP specification, it is my belief that it falls within the charter of the SIPCORE working group.

The only real open issue, in my opinion, is the IANA registration policy that should apply to new "Priority" header field values. To avoid blocking any work in ECRIT, we need to move this work (or something
equivalent) forward very quickly. If you have any interest in the topic, please review and comment with some urgency.

[The following request is being made in my WG chair role] As this is a SIPCORE matter, please discuss it on the SIPCORE list rather than the ECRIT list.

Thanks!

/a
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 6 Nov 2012 13:22:19 -0500

I support this work.  I agree with Christer about a registration template.  While it is obvious what is requested, I think it's better to have it.

I am happy with "IETF Review" as the management policy.

Brian

On Nov 6, 2012, at 10:53 AM, Adam Roach <[email-masked]> wrote:

> The only real open issue, in my opinion, is the IANA registration policy that should apply to new "Priority" header field values. To avoid blocking any work in ECRIT, we need to move this work (or something equivalent) forward very quickly. If you have any interest in the topic, please review and comment with some urgency.
> 
> As this is a SIPCORE matter, please discuss it on the SIPCORE list rather than the ECRIT list.
> 
> Thanks!
> 
> /a

---

From: Dan York <[email-masked]>
Date: Tue, 6 Nov 2012 13:47:36 -0500

+1 to Brian and Christer's comments and I support this work.    This seems a straightforward thing to do .

Dan

-- 
Dan York  [email-masked]
http://www.danyork.me/   skype:danyork
Phone: +1-802-735-1624
Twitter - http://twitter.com/danyork

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 6 Nov 2012 19:50:38 +0100

> +1 to Brian and Christer's comments and I support this work.    This seems a straightforward thing to do .
Agree with this.

/O
>>> As this is a SIPCORE matter, please discuss it on the SIPCORE list rather than the ECRIT list.

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 6 Nov 2012 20:33:29 +0100

I have reviewed the document and saw no issues with the current contents. It performs a useful function and should be proceeded with.

As the document stands, I still see no reason why the document should update RFC 3261. It makes no normative changes within the scope of RFC 3261, which is to define the protocol between two entities.

Part of this discussion may relate to whether one sees the creation and entry of material into IANA registries as being a normative action or not. I don't. To me they are just the housekeeping that has to be done.

As regards the template (which other mails have suggested), we possibly do not need one.

Part of this down to the level of review that is required; in the document this is set as IETF review. At this level, an RFC has to exist and go through IETF community review. There will be enough people around in this process to ensure that all the information that people need to see outside the IANA table actually exists. Conversely where we are allocating values on expert review, a template could be essential if only to ensure the expert doing the review has enough information available to perform the review; that information may well exceed the information that needs to appear in the template itself.

Note that I did have a discussion with IANA on both these issues, and it would be wrong to say an opinion was expressed, Michelle seemed to be in alignment with these points.

Regards

Keith

> Sent: 06 November 2012 15:54

---

From: "Roy, Radhika R CIV (US)" <[email-masked]>
Date: Tue, 6 Nov 2012 20:12:36 +0000

Folks:

I have another point to explain:

                        +------------+-----------+
                        | Priority   | Reference |
                        +------------+-----------+
                        | non-urgent | RFC 3261  |
                        | normal     | RFC 3261  |
                        | urgent     | RFC 3261  |
                        | emergency  | RFC 3261  |
                        +------------+-----------+

The definition of each value needs to be provided.

It is not clear how one label will differ with all others. 

Also, come confusions arise with respect when priority labels are applied
related to call, media, and others.

RFCs 4411 and 4412, 5478, 6433, 6061, 5031, and 3689 need to be seen for
some guidance before explaining the labels so that terminologies and
definitions do not overlap or contradict.

BR/Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of DRAGE, Keith (Keith)
Sent: Tuesday, November 06, 2012 2:33 PM
To: [email-masked]
Subject: Re: [sipcore] Establishing a "Priority" header field registry

I have reviewed the document and saw no issues with the current contents. It
performs a useful function and should be proceeded with.

As the document stands, I still see no reason why the document should update
RFC 3261. It makes no normative changes within the scope of RFC 3261, which
is to define the protocol between two entities.

Part of this discussion may relate to whether one sees the creation and
entry of material into IANA registries as being a normative action or not. I
don't. To me they are just the housekeeping that has to be done.

As regards the template (which other mails have suggested), we possibly do
not need one.

Part of this down to the level of review that is required; in the document
this is set as IETF review. At this level, an RFC has to exist and go
through IETF community review. There will be enough people around in this
process to ensure that all the information that people need to see outside
the IANA table actually exists. Conversely where we are allocating values on
expert review, a template could be essential if only to ensure the expert
doing the review has enough information available to perform the review;
that information may well exceed the information that needs to appear in the
template itself.

Note that I did have a discussion with IANA on both these issues, and it
would be wrong to say an opinion was expressed, Michelle seemed to be in
alignment with these points.

Regards

Keith

> defines such a registry and populates it with the values defined by 
> RFC 3261. Because this is a correction to the core SIP specification, 
> it is my belief that it falls within the charter of the SIPCORE working
group.
> 
> The only real open issue, in my opinion, is the IANA registration 
> policy that should apply to new "Priority" header field values. To 
> avoid blocking any work in ECRIT, we need to move this work (or 
> something
> equivalent) forward very quickly. If you have any interest in the 
> topic, please review and comment with some urgency.
> 
> [The following request is being made in my WG chair role] As this is a 
> SIPCORE matter, please discuss it on the SIPCORE list rather than the 
> ECRIT list.
> 
> Thanks!
> 
> /a

---

From: Adam Roach <[email-masked]>
Date: Tue, 06 Nov 2012 15:50:17 -0500

[as an individual]

> I have another point to explain:

I would argue that that's what the "Reference" column is for. The 
technical description of what a priority means may be somewhat 
complicated or include some subtle points that would require more text 
than would be appropriate for a registry.

> It is not clear how one label will differ with all others.

And that's why you need to look at RFC 3261. It explains the difference. 
In particular, read section 20.26.

> related to call, media, and others.

Priority... labels... media? What?

> definitions do not overlap or contradict.

Aha! I think I see the confusion. You've mixed up "Priority" (RFC 3261, 
section 20.26) with "Resource-Priority" (RFC 4412).

Please carefully read RFC 3261 section 20.26 and reconsider your 
comments. Thanks.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Nov 2012 19:25:59 -0500

> Part of this discussion may relate to whether one sees the creation and entry of material into IANA registries as being a normative action or not. I don't. To me they are just the housekeeping that…

I had a discussion with Keith on this and we fundamentally disagree on 
the point of whether introducing a new registry for an element defined 
in an existing document (in this case 3261) constitutes a revision. I 
believe it does.

Previously, when there was no registry, 3261 was authoritative regarding 
what values are valid for the header. If a new draft wanted to add a new 
value without there being a registry, then that new draft would itself 
be an update to 3261.

The draft that defines the registry changes the authoritative source for 
valid values for the field. Subsequently, new drafts that want to define 
new values only need update the registry, and don't constitute updates 
to 3261.

The record that the draft introducing the registry updates 3261 is the 
link that preserves tracability.

Consider a newbie who is analyzing a message log. In that log he finds 
"Priority:psap-callback". He wonders what that means. Where does he go 
to find out?

1) he probably starts by looking in 3261 as his authoritative source for 
sip. He looks at the description of the Priority header and finds that 
"psap-callback" isn't there. So where does he look next?

2) I assert the next thing he should do is looked at the header of 3261, 
at "Obsoleted by" and "Updated by" references. In this case he will 
unfortunately have to examine a number of "Updated by" RFCs. Ideally he 
will find a reference to Adam's draft (then RFC) that introduces the 
registry.

3) Given the registry reference, he can then go to IANA, look in the 
registry for the Priority header, and find the reference to the RFC 
defining "psap-callback".

Without that sort of tracability he will need to have done a *lot* of 
RFC reading, or know to troll the IANA registry for things that sound 
relevant.

IMO we should endeavor to always maintain such tracability. Sadly we 
haven't always done so in the past. For instance, RFC 3968 established 
the Header Field Parameter Registry, but it does not indicate that it 
updates 3261, and so 3261 doesn't show that it is updated by 3968.

(Instead 3968 indicates that it updates 3427, which also doesn't update 
3261.)

	Thanks,
	Paul

(I guess I'm speaking as an individual here rather than a chair of 
sipcore, because this is about my interpretation of proper process, not 
anything that ought to be specific to sipcore.)

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Nov 2012 19:28:53 -0500

Aside from my disagreement regarding updating 3261 I agree with Keith below.

	Thanks,
	Paul

On 11/6/12 2:33 PM, DRAGE, Keith (Keith) wrote:
>> Of Adam Roach

---

From: James Polk <[email-masked]>
Date: Tue, 06 Nov 2012 22:05:20 -0600

I support this work

James

At 12:22 PM 11/6/2012, Rosen, Brian wrote:
>I support this work.  I agree with Christer about a registration 
>template.  While it is obvious what is requested, I think it's 
>better to have it.
>
> > The document draft-ietf-ecrit-psap-callback has identified a 
> desire to add a new value to the "Priority" header field for SIP. 
> While RFC 3261 clearly intended the values in this header field to 
> be extensible, it did not define a registry of such values.
> >
> RFC 3261. Because this is a correction to the core SIP 
> specification, it is my belief that it falls within the charter of 
> the SIPCORE working group.
> >
> something equivalent) forward very quickly. If you have any 
> interest in the topic, please review and comment with some urgency.
> >
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 7 Nov 2012 09:07:50 -0500

I also support this work
Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. NOTE: Regardless of content, this e-mail shall not operate to 
bind CSC to any order or other contract unless pursuant to explicit 
written agreement or government initiative expressly permitting the use of 
e-mail for such purpose.

From:   James Polk <[email-masked]>
To:     "Rosen, Brian" <[email-masked]>, "[email-masked]" 
<[email-masked]>
Cc:     "[email-masked]" <[email-masked]>
Date:   11/06/2012 11:05 PM
Subject:        Re: [Ecrit] [sipcore] Establishing a "Priority" header 
field registry
Sent by:        [email-masked]

I support this work

James

---

From: Robert Sparks <[email-masked]>
Date: Wed, 07 Nov 2012 10:16:15 -0500

In this particular case, I think using UPDATES is the right thing to do.

As Adam has noted, RFC3261 left _how_ to exercise this particular 
extension point less well-defined than it did for most. In clearing up 
the ambiguity that left, this document is changing the (what had to be 
implicitly inferred) consensus on what needs to be done to add a 
recognized value for this header field. (We would be using UPDATES if 
there had been a registry defined for this in RFC3261 and we were 
changing its registration policy).

RjS

---

From: Ben Campbell <[email-masked]>
Date: Wed, 7 Nov 2012 18:03:53 -0500

On Nov 6, 2012, at 7:25 PM, Paul Kyzivat <[email-masked]> wrote:

> 
> I had a discussion with Keith on this and we fundamentally disagree on the point of whether introducing a new registry for an element defined in an existing document (in this case 3261) constitutes a revision. I believe it does.
> 
> Previously, when there was no registry, 3261 was authoritative regarding what values are valid for the header. If a new draft wanted to add a new value without there being a registry, then that new draft would itself be an update to 3261.
> 
> The draft that defines the registry changes the authoritative source for valid values for the field. Subsequently, new drafts that want to define new values only need update the registry, and don't constitute updates to 3261.

+1. 

Additionally, I think the creation or change of a registration policy is definitely a normative update.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 8 Nov 2012 00:08:09 +0100

The creation of a registration policy certainly does not create an update and none of the people I have talked to have come to that conclusion either.

The change of a registration policy, maybe, but in this case I actually dispute that there is an implied registration policy in RFC 3261. All RFC 3261 defines is an extension mechanism.

Regards

Keith

> Of Ben Campbell
> Sent: 07 November 2012 23:04
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [sipcore] Establishing a "Priority" header field registry -
> Update 3261?
> 
> 
> the point of whether introducing a new registry for an element defined in
> an existing document (in this case 3261) constitutes a revision. I believe
> it does.
> >
> value without there being a registry, then that new draft would itself be
> an update to 3261.
> >
> new values only need update the registry, and don't constitute updates to
> 3261.
> 
> +1.
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 7 Nov 2012 18:09:40 -0500

> The change of a registration policy, maybe, but in this case I actually dispute that there is an implied registration policy in RFC 3261. All RFC 3261 defines is an extension mechanism.

How is going from no policy to having a policy _not_ a change?

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 8 Nov 2012 00:11:11 +0100

You follow that argument through to its logical conclusion and every new RFC updates the previous 6000.

Keith

> From: Ben Campbell [mailto:[email-masked]]
> Sent: 07 November 2012 23:10
> To: DRAGE, Keith (Keith)
> Cc: Paul Kyzivat; [email-masked]
> > The creation of a registration policy certainly does not create an
> update and none of the people I have talked to have come to that
> conclusion either.
> >
> > The change of a registration policy, maybe, but in this case I actually
> dispute that there is an implied registration policy in RFC 3261. All RFC
> 3261 defines is an extension mechanism.
>

---

From: "Roy, Radhika R CIV (US)" <[email-masked]>
Date: Wed, 7 Nov 2012 15:07:05 +0000

Hi, Adam:

You are right that you are referring to RFC 3261 semantics that also refer
to RFC 2976.

It is the SIP call level priority, that is, how a given call will be handled
with relative to other calls.

The issues that I have been trying to relate are the following:

1. Other RFCs that I referred also deal with call level priority including
emergency calls.

2. A SIP call also contain media: Audio, Video, and/or Data.

3. Other RFCs also deal with resources priority that include media.

Did anyone ever try to relate all these priority semantics from the SIP call
to the media level knowing the semantics of all priority headers?

BR/Radhika

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Tuesday, November 06, 2012 3:50 PM
To: Roy, Radhika R CIV (US)
Cc: [email-masked]
Subject: Re: [sipcore] Establishing a "Priority" header field registry

[as an individual]

> I have another point to explain:

I would argue that that's what the "Reference" column is for. The technical
description of what a priority means may be somewhat complicated or include
some subtle points that would require more text than would be appropriate
for a registry.

> Also, come confusions arise with respect when priority labels are 
> applied related to call, media, and others.

> RFCs 4411 and 4412, 5478, 6433, 6061, 5031, and 3689 need to be seen 
> for some guidance before explaining the labels so that terminologies 
> and definitions do not overlap or contradict.

Please carefully read RFC 3261 section 20.26 and reconsider your comments.
Thanks.

/a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 8 Nov 2012 01:46:19 +0100

The Priority header field is rendered to the user or recipient application, and in my view has no impact on the SIP processing directly.

The Resource-Priority header field can impact usage of signaling resources themselves, media resources and access resources. It does not necessarily impact all of these, and which it impacts is defined by the namespaces used, and how those namespaces are implemented in individual operators domains.

Regards

Keith

> Of Roy, Radhika R CIV (US)
> Sent: 07 November 2012 15:07
> To: Adam Roach
> Cc: [email-masked]
> technical

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 7 Nov 2012 20:05:48 -0500

I agree.  the SIP Priority header is only used by the destination user or 
application.  It does not affect on SIP processing.

That is why we needed to develop SIP Resource- Priority.

The distinction between "Priority" and "Resource-Priority" is described in 
Section 1 (Introduction) of RFC 4412.

Janet

From:   "DRAGE, Keith (Keith)" <[email-masked]>
To:     "Roy, Radhika R CIV (US)" <[email-masked]>, Adam Roach 
<[email-masked]>
Cc:     "[email-masked]" <[email-masked]>
Date:   11/07/2012 07:46 PM
Subject:        Re: [sipcore] Establishing a "Priority" header field 
registry
Sent by:        [email-masked]

The Priority header field is rendered to the user or recipient 
application, and in my view has no impact on the SIP processing directly.

The Resource-Priority header field can impact usage of signaling resources 
themselves, media resources and access resources. It does not necessarily 
impact all of these, and which it impacts is defined by the namespaces 
used, and how those namespaces are implemented in individual operators 
domains.

Regards

Keith

> Please carefully read RFC 3261 section 20.26 and reconsider your 
comments.

---

From: James Polk <[email-masked]>
Date: Wed, 07 Nov 2012 21:22:09 -0600

The SIP Priority header has zero impact on message processing, it's 
all for what the sending user believes is the importance of that call 
to the destination user; nothing more. This is why RFC 4412 was 
written - to have an impact, when used and supported, on message processing.

James

At 06:46 PM 11/7/2012, DRAGE, Keith (Keith) wrote:
>The Resource-Priority header field can impact usage of signaling 
>resources themselves, media resources and access resources. It does 
>not necessarily impact all of these, and which it impacts is defined 
>by the namespaces used, and how those namespaces are implemented in 
>individual operators domains.
>
>Regards
>
>Keith
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 12 Nov 2012 20:35:08 -0600

[as a participant]

> The Priority header field is rendered to the user or recipient application, and in my view has no impact on the SIP processing directly.

For a long time, I was under that same impression until I (as part of 
this effort) went back and carefully re-read RFC 3261 section 20.26. The 
interesting statement that disabused me of this notion is: " For 
example, [the Priority header field] may be factored into decisions 
about call routing..."

Now, I do think it's a stretch to believe that this can be parlayed into 
how a call is handled relative to other calls, as Radhika was claiming. 
But there is no blanket prohibition against using Priority in routing 
elements.

/a