SIP "cause" URI Parameter for Service Number Translation
Note: This ballot was opened for revision 13 and is now closed.
(Ben Campbell) (was Discuss, Yes) Yes
Version 14 removed the new registry, so I have cleared my DISCUSS. I copied my old DISCUSS point below: <old> I failed to notice that version 13 section 5.2 adds a new IANA registry with no registration policy. This is a post IETF LC change as a result of the opsdir review. I don't think that registry is needed, and prefer it to be removed. If the authors feel strongly that it is needed, then it needs a registration policy. Given the (potentially fragile) consensus about the IANA action taken by this draft prior to the addition of section 5.2, I think that this would require a repeated IETF last call. </old>
(Jari Arkko) (was Discuss) No Objection
Per RFC 3969, SIP URI parameters and their values can only be defined in standards track RFCs. So why isn't this one? ---- The issue was observed by Joel Halpern in his Gen-ART review: This document defines a new code for use in SIP, and specifies new behavior both for the code itself and for its use in history-info. I am thus confused as to how this can be an informational RFC. It looks like it either Proposed Standard or experimental. Yes, I see that RFC 4458, which this updates is Informational. But just because we did it wrong before does not make that behavior correct now. In addition to my understanding of the roles of different RFCs, I note that RFC 3969 and the IANA registry both state that this assignment must be made by a standards track RFC.
(Alia Atlas) No Objection
Deborah Brungard No Objection
Alissa Cooper No Objection
(Stephen Farrell) No Objection
(Joel Jaeggli) No Objection
(Suresh Krishnan) No Objection
(Mirja Kühlewind) No Objection
(Terry Manderson) No Objection
(Kathleen Moriarty) No Objection
Alvaro Retana No Objection
It seems to me that RFC4458 should be a Normative Reference.