ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field
draft-ietf-sipcore-reason-q850-loc-07
Yes
(Ben Campbell)
No Objection
(Alexey Melnikov)
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Ignas Bagdonas)
(Martin Vigoureux)
(Mirja Kühlewind)
(Terry Manderson)
Note: This ballot was opened for revision 05 and is now closed.
Warren Kumari
No Objection
Comment
(2019-03-05 for -06)
Not sent
Thanks to Linda for the OpsDir review - I found it helpful.
Adam Roach Former IESG member
(was Discuss)
Yes
Yes
(2019-03-19)
Sent for earlier
Thanks for addressing my discuss and comments.
Ben Campbell Former IESG member
Yes
Yes
(for -05)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -06)
Not sent
Alissa Cooper Former IESG member
No Objection
No Objection
(for -06)
Not sent
Alvaro Retana Former IESG member
No Objection
No Objection
(for -06)
Not sent
Benjamin Kaduk Former IESG member
(was Discuss)
No Objection
No Objection
(2019-03-20)
Sent for earlier
Thank you for addressing my Discuss point (via RFC Editor note)!
Deborah Brungard Former IESG member
No Objection
No Objection
(for -06)
Not sent
Eric Rescorla Former IESG member
No Objection
No Objection
(2019-03-06 for -06)
Sent
Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3825 COMMENTS > > The SIP Reason header field is defined for carrying ISDN User Part > (ISUP) cause values as well as SIP response codes. Some services in > SIP networks may need to know the ISUP location where the call was > released in the PSTN network to correctly interpret the reason of > release. This document will update RFC3326. "release" appears to be a technical PSTN term. Please provide a citation the way that 3226 does.
Ignas Bagdonas Former IESG member
No Objection
No Objection
(for -06)
Not sent
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -06)
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -06)
Not sent
Spencer Dawkins Former IESG member
No Objection
No Objection
(2019-02-28 for -06)
Sent
I don't know if this will ever matter, but I wasn't getting "release location" out of the title and most of the text, that just says "location". Perhaps that could be clearer?
Suresh Krishnan Former IESG member
No Objection
No Objection
(2019-03-05 for -06)
Sent
* I was trying to read up on the Q.850 spec and I found out there was a much newer version (20 years newer) that has superseded the referenced version. Is there a particular reason to refer to the 1998 spec instead of the 2018 spec? * I have a hard time seeing why this document needs to define names for the spare codepoints (LOC-6,8,9,11). Either they won't be used (in which case we do not need to define them) or they will be defined in a future revision of Q.850 (in which case they will most likely get a different name).
Terry Manderson Former IESG member
No Objection
No Objection
(for -06)
Not sent