Subject: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Nov 2012 15:49:28 -0500

PLEASE RESPOND TO THIS MESSAGE

This is a request to the sipcore wg to adopt the new individual draft 
draft-roach-sipcore-priority-00, and a start of WGLC on that document, 
to end on Sunday, November 25, 2012. (This is a trivial doc to review, 
but people may be slow getting back to work after the meeting and there 
is a holiday coming in the US, so I'm giving more time than I otherwise 
would.)

The reason for this is that the ecrit wg wants to define a new value for 
the Priority header field. RFC 3261 defines that header field and an 
initial set of values. It also mentions the possibility of extension. 
But it failed to establish an IANA registry for that purpose, and didn't 
otherwise define a process for extension.

The intro to *this* document explains its purpose:

    This document defines a new IANA registry to keep track of the values
    defined for the Session Initiation Protocol (SIP) "Priority" header
    field.  This header field was defined in [RFC3261], section 20.26.
    It was clearly specified in a way that allows for the creation of new
    values beyond those originally specified; however, no registry has
    been established for it.

Once that is done, ecrit will be able to make their extension in accord 
with the registration procedures that have been defined. The 
registration policy is "IETF Review", so discussion of the merits of 
that new value can be discussed as part of the review of *that* 
document: draft-ietf-ecrit-psap-callback.

REQUESTED ACTIONS:

- indicate (ASAP) willingness, or not, for the sipcore wg to work on
   this problem, and adopt this draft as the basis for that work.

- provide any comments you have on this document before the end of
   the WGLC period (Friday, November 25.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Nov 2012 21:52:41 +0000

Hi,

I support the adoption.

As I have indicated before, I think there should be some kind of template for the registration.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] on behalf of Paul Kyzivat [[email-masked]]
Sent: Monday, 12 November 2012 10:49 PM
To: SIPCORE; [email-masked]
Subject: [sipcore] Proposal: Call for adoption & WGLC:  draft-roach-sipcore-priority-00

REQUESTED ACTIONS:

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Nov 2012 17:33:13 -0500

> As I have indicated before, I think there should be some kind of template for the registration.

I guess that means you aren't ready to approve it.
Can you suggest some text?

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 12 Nov 2012 23:46:47 +0100

It might also be appropriate to answer the points I made in response, rather than just repeating the demand.

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: 12 November 2012 22:33
> To: Christer Holmberg
> Cc: SIPCORE; [email-masked]
> Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-
> sipcore-priority-00
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Nov 2012 22:54:15 +0000

Hi,

> I guess that means you aren't ready to approve it.

What do you mean by approve? I assumed that adopting the draft would mean that it becomes draft-ietf-sipcore-priority. I think we can do that even if the template text yet does not exist.

Of course, before we finalize WGLC and send the draft to IESG, we would need to have the template text.

> Can you suggest some text?

I'll try to come up with something.

Regards,

Christer

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 12 Nov 2012 17:02:23 -0800

Can something be said about the difference between "non-urgent" 
and "normal"?   I sort of get the feeling that non-urgent is 
intended to have a lower priority than "normal" (just based on
the ordering), but that is not clear.  Just saying "have the
priority in the listed order" would help.

-d

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Monday, November 12, 2012 12:49 PM

---

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

[as an individual]

I would *really* like to keep protocol semantics out of the IANA 
registry. The referenced RFC (3261 in this case) is supposed to define 
the semantics for the Priority values.

In particular, there isn't any clear indication in RFC 3261 that 
Priority is supposed to be a strictly ordered set. If we want to go down 
the path of redefining semantics for parts of RFC 3261, then we're 
looking at a much, much larger effort than I envisioned for this document.

All I'm intending to do here is set up an IANA registry.

/a

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 12 Nov 2012 21:33:26 -0500 (EST)

> From: "Dan Wing" <[email-masked]>
> 

I support adopting draft-roach-sipcore-priority as a WG item.

It would be nice if there was an English word meaning "anti-urgent",
but there doesn't seem to be one.  And "non-urgent" is fixed is RFC
3261.

Do the initial registry entries define the meaning of the initial
values?  I notice that RFC 3261 doesn't provide meanings, even though
it is given as the reference.

Dale

---

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

> It might also be appropriate to answer the points I made in response, rather than just repeating the demand.

Are you meaning to indicate the question of whether this document 
updates 3261? That seems to be the only point of contention you've 
raised, and I've heard scant support for your position on that topic.

By way of contrast, Paul, Ben, Robert and I -- the only others who have 
engaged on this rather esoteric bit of IETF arcana -- have all stated 
what *I* believe are lucid and defensible reasons that this draft is 
required to update 3261. I'm certainly willing to consider the 
conversation to be ongoing, if there are new points to be made. 
Otherwise, this is clearly a non-technical matter of opinion about which 
people seem to have already reached their own conclusions, and the 
preponderance of the expressed opinion seems to put you in a minority 
class of size one.

/a

---

From: Laura Liess <[email-masked]>
Date: Tue, 13 Nov 2012 09:53:53 +0100

I support addopting the draft as a WG item.

Regargs
Laura

2012/11/12 Christer Holmberg <[email-masked]>

> What do you mean by approve? I assumed that adopting the draft would mean
> that it becomes draft-ietf-sipcore-priority. I think we can do that even if
> the template text yet does not exist.
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 13 Nov 2012 10:34:33 +0100

> priority in the listed order" would help.
Adam's draft seems to only be focused on adding the missing registry,
not trying to change the text in RFC 3261. I agree that RFC 3261 
lacks a specification of the values, except for emergency:

"It is RECOMMENDED
   that the value of "emergency" only be used when life, limb, or
   property are in imminent danger.  Otherwise, there are no semantics
   defined for this header field."

You know more about IETF procedures, but should we mix the two?
- Adding definitions of the values and the missing registry.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 13 Nov 2012 10:35:28 +0100

13 nov 2012 kl. 03:04 skrev Adam Roach <[email-masked]>:

> [as an individual]
> 
> I would *really* like to keep protocol semantics out of the IANA registry. The referenced RFC (3261 in this case) is supposed to define the semantics for the Priority values.
> 
> In particular, there isn't any clear indication in RFC 3261 that Priority is supposed to be a strictly ordered set. If we want to go down the path of redefining semantics for parts of RFC 3261, then we're looking at a much, much larger effort than I envisioned for this document.
> 
And that answered my previous mail... Should read all mail before starting to answer ;-)

I do support wg adoption of this draft.

/O

---

From: Ben Campbell <[email-masked]>
Date: Tue, 13 Nov 2012 09:26:48 -0600

I support adoption. I will provide WGLC comments separately.

On Nov 12, 2012, at 2:49 PM, Paul Kyzivat <[email-masked]> wrote:

> This is a request to the sipcore wg to adopt the new individual draft draft-roach-sipcore-priority-00, and a start of WGLC on that document, to end on Sunday, November 25, 2012. (This is a trivial doc to review, but people may be slow getting back to work after the meeting and there is a holiday coming in the US, so I'm giving more time than I otherwise would.)
> 
> The reason for this is that the ecrit wg wants to define a new value for the Priority header field. RFC 3261 defines that header field and an initial set of values. It also mentions the possibility of extension. But it failed to establish an IANA registry for that purpose, and didn't otherwise define a process for extension.
> 
> Once that is done, ecrit will be able to make their extension in accord with the registration procedures that have been defined. The registration policy is "IETF Review", so discussion of the merits of that new value can be discussed as part of the review of *that* document: draft-ietf-ecrit-psap-callback.
> 
> REQUESTED ACTIONS:
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 13 Nov 2012 17:03:11 +0100

The action of putting something in an IANA registry defines nothing.

If you want to assign meaning to a value, it is the RFC text itself that does that.

Keith

> Of Dale R. Worley
> Sent: 13 November 2012 02:33
> To: Dan Wing
> Cc: [email-masked]; [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 13 Nov 2012 08:12:25 -0800

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2012 8:03 AM
> To: Dale R. Worley; Dan Wing
> Subject: RE: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-
> sipcore-priority-00
> 

RFC3261 made two mistakes:  (a) it provided no meanings for the four terms,
and (b) it neglected to create a registry.  I find it valuable to fix 
both (a) and (b), but draft-roach-sipcore-priority only fixes (b).

-d

> > Behalf Of Dale R. Worley
> > > intended to have a lower priority than "normal" (just based on the
> > > ordering), but that is not clear.  Just saying "have the priority in
> > > the listed order" would help.
> >

---

From: James Polk <[email-masked]>
Date: Tue, 13 Nov 2012 13:32:33 -0600

>both (a) and (b), but draft-roach-sipcore-priority only fixes (b).

I have to agree with Dan here. In the proposed registry within this 
ID, it gives 4 terms and lists RFC 3261 as the reference, but it 
doesn't define what any of those terms are (which is bad). 
"psap-callback" should have a definitive definition within its ID to 
describe what it is used for. Lacking the ability to update RFC 3261 
(anytime) soon, I would prefer an option-tag style new registry in 
which the term/string definition is within the registry, such as this:

Registry:
Name            Description                                 Reference
-----------     ------------------------------------------  ---------
non-urgent      This Priority header-value means ...        [RFCxxxx]

normal          This Priority header-value means ...        [RFCxxxx]

urgent          This Priority header-value means ...        [RFCxxxx]

emergency       This Priority header-value means ...        [RFCxxxx]

note: where RFCxxxx is Adam's document, because it provides the 
meaning of the terms, which are more important than which doc picked 
the undefined terms (which is what RFC 3261 did).

 From this, I am suggesting this ID's section 2 be changed to the 
above (in case that wasn't obvious). I know this is making a bigger 
deal out of a little used header, but RFC 3261 didn't do what it was 
supposed to do here, and this is a good make-up.

then we just have to agree on the definitions that RFC 3261 didn't 
discuss. I know this will add a bunch of time (like 2 whole weeks) to 
reach consensus, but then psap-callback would fit nicely into this registry.

James

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 13 Nov 2012 20:42:03 +0100

Whatever you write in the registry has no impact on the semantics, and writing this stuff in the registry carries the wrong message as to the source of the definition. The normative source of the semantics is the RFC text.

Dan understood this, but you are disagreeing with Dan by asking for it to appear in the registry.

Keith

> From: James Polk [mailto:[email-masked]]
> Sent: 13 November 2012 19:33
> To: Dan Wing; DRAGE, Keith (Keith); 'Dale R. Worley'
> > > If you want to assign meaning to a value, it is the RFC text itself
> that
> > > does that.
> >

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 13 Nov 2012 20:50:19 +0100

I'm referring to these comments I made on the template proposal on 6th November which I copy here:

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

Keith

> From: Adam Roach [mailto:[email-masked]]
> Sent: 13 November 2012 02:58
> To: DRAGE, Keith (Keith)
> Cc: Paul Kyzivat; Christer Holmberg; SIPCORE; [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Nov 2012 16:27:07 -0500

(as individual)

> both (a) and (b), but draft-roach-sipcore-priority only fixes (b).

The question is how to do these things.

- we could decide to fix (b) and not (a)

- this draft could be enhanced to do both

- this draft could be left as is, and an errata filed against
   3261 regarding (a)

- we could leave this draft as is and submit another draft
   to fix (a).

Ecrit *needs* a way to add a new value, so they need (b) *soon*.
AFAIK nobody is currently suffering for lack of a fix for (a).

If we could do (a) *quickly* then doing them both in the same draft 
would be attractive. I just fear that we might end up squabbling for a 
long time of this mundane thing. If so, then I think the errata approach 
for (a) is more attractive.

	Thanks,
	Paul

---

From: "Roy, Radhika R CIV (US)" <[email-masked]>
Date: Wed, 14 Nov 2012 12:44:41 +0000

Hi, Paul:

It is not true. We are suffering for not fixing (a) because of
incompatibility in implementations from the SIP application layer to the
IP/MPLS network (RSVP, DiffServ DSCP code points) layer along with dealings
of emergency (E911) calls. 

We have to see all RFCs as I mentioned to an email to Adam that our
explanations and semantics of RFC 3261 must be consistent with respect to
other RFCs as well: 

"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 Paul Kyzivat
Sent: Tuesday, November 13, 2012 4:27 PM
To: [email-masked]
Subject: Re: [sipcore] Proposal: Call for adoption & WGLC:
draft-roach-sipcore-priority-00

(as individual)
....
nobody is currently suffering for lack of a fix for (a).
....
	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Nov 2012 11:05:22 -0500

Roy,

> definitions do not overlap or contradict."

IMO what you are talking about is different from (a).

What (a) is about is the meaning of each individual priority value - 
they way that they differ from one another. I'm not aware of any reports 
of problems due to this lack, though there certainly could be some. (I 
was of the opinion that Priority:emergency was suitable for use in the 
psap-callback case, but others hypothesized that this would cause 
confusion. This is why we are preparing for the definition of a new 
value. But that is the *only* case I have heard of where the meaning of 
the Priority values has come up.)

What you are talking about is the difference between Priority and 
Resource-Priority. Resource-Priority and all the things built around it 
are *extensions* to SIP. If you find it difficult to distinguish the 
responsibilities of the extensions from those of the core, then I would 
consider that an inadequacy of the extension, not of the core.

Perhaps the ECRIT docs need to document further what the role is for the 
Resource-Priority header in emergency calls. But that is separate from 
*this* draft.

	Thanks,
	Paul (as co-chair)

---

From: Adam Roach <[email-masked]>
Date: Wed, 14 Nov 2012 13:56:51 -0600

I don't think you're being ignored; I'm waiting to hear from other 
participants about whether we need a registration template. I really 
don't have a strong opinion on the topic.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Nov 2012 22:32:44 +0000

Hi,

If others don't think a template is needed, I will not argue for it. The important thing is that the process for defining and registering new values is clear to the readers.

Regards,

Christer

________________________________________
From: Adam Roach [[email-masked]]
Sent: Wednesday, 14 November 2012 9:56 PM
To: DRAGE, Keith (Keith)
Cc: Paul Kyzivat; Christer Holmberg; SIPCORE; [email-masked]
Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00

/a

---

From: Ben Campbell <[email-masked]>
Date: Thu, 15 Nov 2012 16:35:16 -0600

> I support adoption. I will provide WGLC comments separately.

And here's that promised followup:

I think the draft is pretty much ready to go as is. I've already stated my position on updating 3261, and I have no opinion on the template question.

I concur with Adam that this draft should not attempt to fix the meaning of any existing values. If it's important to do so, I think that should be a separate effort.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Nov 2012 22:41:45 +0000

>I concur with Adam that this draft should not attempt to fix the meaning of any existing values. If it's important to do so, I think that should be a separate effort.

+ 1

Regards,

Christer

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 19 Nov 2012 11:04:05 +0200

So, what's the status of the document? 
When does it become a WG item (given the support it has received)?
When will the WGLC be started?

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Nov 2012 11:18:49 -0500

> When will the WGLC be started?

I called a simultaneous request for approval to adopt and WGLC.
It is to be completed Sunday Nov 25.

There have been a number of comments. (Thanks to those who have commented.)

I have seen no objections to adoption, so I expect that to happen as 
soon as the period is over.

We will have to look at the comments to see what changes, if any, need 
to be made to the draft. Depending on the extent of those we may or may 
not need another review. But based on what I have seen I doubt we will 
need a lot of time after Nov 25 to finalize it.

	Thanks,
	Paul (as co-chair)

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Nov 2012 17:03:47 -0500

The WGLC and adoption deadline has now passed for 
draft-roach-sipcore-priority-00. Nine people (other than chairs and 
authors) made meaningful comments.

I conclude there is consensus to adopt this draft as a wg document.

Regarding WGLC, two notable issues were raised, and I don't yet see a 
clear consensus on those issues:

- should there be a registration template?
   Christer advocates this, Keith opposes, Adam finds it unnecessary.

- should this document also spell out the semantics of all the priority
   values defined in 3261? (Currently it only defines "emergency".)
   Dan, James, and Roy in favor, Adam and I prefer not to do it *in this
   document*.

So, I will ask Adam to submit a wg draft version of this document, 
otherwise unchanged.

While he is doing that, I would like to get a broader consensus on the 
issues above. I'll post a separate question on each of those, to keep 
the discussions separate.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Nov 2012 17:21:40 -0500

We are in the process of adopting draft-roach-sipcore-priority-00 as a 
wg document. We already ran a WGLC on it in anticipation of the adoption.

One issue raised during the WGLC was whether the document should include 
some sort of IANA registration template. Christer proposed this, and 
Keith opposed it.

Christer failed to specify what he wanted to see in this template. The 
existing document specifies what the registry should contain: A 
"priority" name and a document reference. "IETF Review" is required for 
adding new values, which ensures that there will be an RFC to reference. 
So presumably the template would include at least these two values.

Please indicate if you think the draft is ok as-is, or should be revised 
to include a registration template.

If you favor a template, please indicate what you think it should contain.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Nov 2012 17:41:08 -0500

One issue raised during the WGLC was whether the document should spell 
out the semantics of all the priority values defined in 3261. (Currently 
3261 only defines "emergency".) Dan, James, and Roy were in favor, Adam 
and I prefered not to do it *in this document*.

I think everyone agrees that 3261 is lacking in this regard, and it 
would be good to have these defined. The question is whether to do that 
in *this* document. The answer to that depends on a number of factors:
- the urgency of getting the iana registry established, so that ecrit
   won't be blocked in defining a new value for their work.
- how much pain is lack of semantics for these values causing right now?
- how long would it take to to agree on definitions of the semantics?
- acceptability of alternatives to this document for defining the
   semantics.

Please indicate your preference on this issue:

- NO: do not add semantic definitions to this draft.
   (That means they will be done some other way or not at all)

- YES: this document should be delayed while semantic defintions
   of existing priority values are added to it.

If you vote NO, feel free to indicate what mechanism you would like have 
used to define the semantics. (E.g. errata / another draft.)

	Thanks,
	Paul

---

From: Andrew Allen <[email-masked]>
Date: Thu, 29 Nov 2012 01:38:07 +0000

NO - that's feature creep that takes something that's already been discussed and on which there is consensus and adds a boatload more discussion that will likely be a long discussion (see how much discussion we have had just on whether to use a new or existing value for PSAP callback) and delay the IANA registration of the new value.

I know it is Christmas season but let's not create a snowball that grows and grows as it rolls along!

If there are people willing to do the additional work of defining and discussing the semantics of these values then that can be a follow on draft.

Andrew

----- Original Message -----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Wednesday, November 28, 2012 04:41 PM Central Standard Time
To: [email-masked] <[email-masked]>
Subject: [sipcore] consensus call: draft-roach-sipcore-priority-00: define semantics of values?

	Thanks,
	Paul

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Nov 2012 07:33:07 +0000

Hi Paul,

>We are in the process of adopting draft-roach-sipcore-priority-00 as a wg document. We already ran a WGLC on it in anticipation of the adoption.
>
>One issue raised during the WGLC was whether the document should include some sort of IANA registration template. Christer proposed this, and Keith opposed it.
>
>Christer failed to specify what he wanted to see in this template. The existing document specifies what the registry should contain: A "priority" name and a document 
>reference. "IETF Review" is required for adding new values, which ensures that there will be an RFC to reference. 
>Please indicate if you think the draft is ok as-is, or should be revised to include a registration template.
>

What do you mean by "Christer failed to specify"? 

13th November I DID send text proposal to the list for the registration template. It contained Description, Reference and Contact. See copy at the end of this reply.

However, 15th November I indicated on the list that, if nobody else think a template is needed, I'll step down :)

The important thing is that it is clear to a person who want to register a value WHAT information to provide, and WHERE to send it.

Regards,

Christer

-------------------

x. Priority Header Field Value Registration Template

   Registration requests for Priority header field values
   requires submitting an Internet-Draft to the IESG.

   | Instructions are preceded by '|'.  All fields are mandatory.

   Priority header field value:

   Description:

   | The description should be no longer than 4 lines. More
   | detailed information can be provided in the specification
   | that defines the header field value.

   Priority header field value specification reference:

   | The reference to the speicification the defines the 
   | header field value.

   Contact:

   | Name(s) & email address(es) of person(s) to
   | contact for further information."

-------------------

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Nov 2012 07:39:11 +0000

NO.

(We can have a separate discussion whether we want to, as part of another draft/errata, want to define the semantics for existing value(s), but let's not that stop the progress of the registry work.)

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 29. marraskuuta 2012 0:41
To: [email-masked]
Subject: [sipcore] consensus call: draft-roach-sipcore-priority-00: define semantics of values?

One issue raised during the WGLC was whether the document should spell out the semantics of all the priority values defined in 3261. (Currently
3261 only defines "emergency".) Dan, James, and Roy were in favor, Adam and I prefered not to do it *in this document*.

I think everyone agrees that 3261 is lacking in this regard, and it would be good to have these defined. The question is whether to do that in *this* document. The answer to that depends on a number of factors:

If you vote NO, feel free to indicate what mechanism you would like have used to define the semantics. (E.g. errata / another draft.)

	Thanks,
	Paul

On 11/28/12 5:03 PM, Paul Kyzivat wrote:
>> draft-roach-sipcore-priority-00, and a start of WGLC on that 
>> document, to end on Sunday, November 25, 2012. (This is a trivial doc 
>> to review, but people may be slow getting back to work after the 
>> meeting and there is a holiday coming in the US, so I'm giving more 
>> time than I otherwise
>> would.)
>>
>> The reason for this is that the ecrit wg wants to define a new value 
>> for the Priority header field. RFC 3261 defines that header field and 
>> an initial set of values. It also mentions the possibility of extension.
>> But it failed to establish an IANA registry for that purpose, and 
>> didn't otherwise define a process for extension.
>>
>> Once that is done, ecrit will be able to make their extension in 
>> accord with the registration procedures that have been defined. The

---

From: Michael Procter <[email-masked]>
Date: Thu, 29 Nov 2012 10:27:26 +0000

NO

I'm happy to defer defining the semantics of 'urgent', 'non-urgent'
and 'normal' until not having the semantics defined causes
interoperability problems.  Given the limited impact the priority
header can have on a session, I suspect that the natural meanings of
the tokens are adequate for the time being.

Michael

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 29 Nov 2012 12:43:59 +0100

Regarding 1), noone has yet responded as to why we need a template for a document where registration requires IETF work. The template is in my view there to ensure all the information that is needed is available for expert review. The document management of an internet draft means that if information is needed for review the next revision can provide it. We only need a template if someone decides a different registration policy is needed.

Regarding 2), I think defining more precise semantics of the existing values is too late in the game. Fine for new values, and in many ways, this is why we have a new value for the callback proposed elsewhere. So do not add these.

Keith

> Sent: 28 November 2012 22:04
> To: [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Nov 2012 11:50:34 +0000

Hi,

>Regarding 1), noone has yet responded as to why we need a template for a document where registration requires IETF work. The template 
>is in my view there to ensure all the information that is needed is available for expert review. The document management of an internet 
>draft means that if information is needed for review the next revision can provide it. We only need a template if someone decides a different 
>registration policy is needed.

Fair enough. I hereby withdraw my request for a template :)

Regards,

Christer

> > This is a request to the sipcore wg to adopt the new individual 
> > draft draft-roach-sipcore-priority-00, and a start of WGLC on that 
> > document, to end on Sunday, November 25, 2012. (This is a trivial 
> > doc to review, but people may be slow getting back to work after the 
> > for the Priority header field. RFC 3261 defines that header field 
> > and an initial set of values. It also mentions the possibility of extension.
> >     It was clearly specified in a way that allows for the creation 
> > of
> new

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 29 Nov 2012 14:20:58 +0200

I fear you guys read a bit too much into the term "template". 

IANA typically wants to know what information a request for adding a new
value into an existing registry should contain. This is called the
template. As mentioned, here the required info is pretty obvious: a
label and a reference to a document that contains the semantic. If you
want to make it 100% clear add a sentence: "Registration requests to
IANA must include a label (value for the priority header field) and a
reference to a document that explains the semantic of that label." 

What is, however, missing from the IANA consideration is an indication
whether you envision entries to be updated, deleted, or deprecated. I
would write "Updating, deleting, or deprecating of entries in the
registry is not envisioned." 

Ciao
Hannes

> Behalf Of ext Christer Holmberg
> Sent: Thursday, November 29, 2012 1:51 PM
> To: DRAGE, Keith (Keith); Paul Kyzivat; [email-masked]
> Subject: Re: [sipcore] Proposal: Call for adoption& WGLC: draft-roach-
> sipcore-priority-00
> 
> Hi,
> 
> >Regarding 1), noone has yet responded as to why we need a template
for
> a document where registration requires IETF work. The template
> >is in my view there to ensure all the information that is needed is
> available for expert review. The document management of an internet
> >draft means that if information is needed for review the next
revision
> can provide it. We only need a template if someone decides a different

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Nov 2012 11:41:15 -0500

> 13th November I DID send text proposal to the list for the registration template. It contained Description, Reference and Contact. See copy at the end of this reply.

Oh, sorry. I must have looked at the wrong message.

> The important thing is that it is clear to a person who want to register a value WHAT information to provide, and WHERE to send it.

What's necessary is to supply the info that is in the IANA registry. As 
currently proposed, that is only the name of the value and a reference 
to the RFC that defines it.

There is no need to send it anywhere, because it calls for IETF Review, 
which requires an RFC, and the IETF RFC process deals with IANA 
considerations.

It is really hard to write an RFC that defines a new Priority value 
without specifying the name of that value. I think people will remember 
to do this even without a template. :-)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Nov 2012 19:15:12 +0000

Hi,

> to do this even without a template. :-)

I'll take your word for it :)

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 30 Nov 2012 03:25:00 +0100

If you look at some IANA tables, you will see a link to template, where the template contains more information than the IANA registry.

My assumption has been that this is to allow the gathering of extra information beyond the bare table, where an expert is designated to review the entry to ensure it makes sense. This of course depends on the guidance given to the expert who is performing the expert review from the original RFC that established the registry. If the expert is just expected to make sure all the table entries are present then you probably don't need one. If the expert is required to investigate in a more technical sense, then they need more information. 

Additionally RFC 3265 and its successor have a template for documenting event packages for example, which carries much more information than is needed for the IANA registry.

Keith

> From: Tschofenig, Hannes (NSN - FI/Espoo)
> [mailto:[email-masked]]
> Sent: 29 November 2012 12:21
> To: ext Christer Holmberg; DRAGE, Keith (Keith); Paul Kyzivat;
> [email-masked]
> Subject: RE: [sipcore] Proposal: Call for adoption& WGLC: draft-roach-
> sipcore-priority-00
>