IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field
RFC 6878

Note: This ballot was opened for revision 00 and is now closed.

(Adrian Farrel) Yes

(Robert Sparks) Yes

(Sean Turner) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Stephen Farrell) No Objection

(Brian Haberman) No Objection

(Russ Housley) (was Discuss) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2013-01-08)
No email
send info
I support Russ's DISCUSS, but it's trivial to fix and discussion has already converged on that.

The shepherd writeup says this:

    The policy for adding new values to the registry was intentionally 
    chosen to be IETF Review. We do not anticipate many additions, and 
    feel this level of review will ensure that any such additions are 
    well considered.

I have discussed this with Robert, and am happy to clear my DISCUSS on it (having had the discussion) and move it to a non-blocking comment.  Our discussion made it clear that there have been problems with attempts to use this header field, that scrutiny of the usage proposals is important, and that a single expert isn't appropriate because conversation within the SIP community is often important in teasing out issue with proposals.

That said, if you can find a way to put a paragraph explaining that into the document, as an explanation to and a warning to those who might want to mint new values for this header field, I think it would be useful.  I don't think it should take much, though I understand that there are political land mines that you'll want to step around as you do it.

And remember that this is non-blocking, so if you really can't see a good way to say it I'm not going to insist further.

(Martin Stiemerling) No Objection

(Pete Resnick) Abstain

Comment (2013-01-08)
No email
send info
I chatted with Robert about these two items, so I don't feel the need to DISCUSS them with the rest of the IESG. And I'm not willing to stand in the way of publishing this document on these two points alone. But I do want to make it clear that I'd much prefer if the following two things were changed.

- This is simply a procedural document, not a protocol document. It should be BCP. It can still update 3261 as a BCP.

- I agree with Barry that a paragraph explaining that IETF Review is necessary because of potential interoperability problems (i.e., the fact that SIP implementations would need upgrading if they would have to understand bogusness that will go into this field if people can register willy-nilly) would be a good addition and prevent people refer to this as a precedent in the future.