ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field
RFC 8606

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

Alvaro Retana No Objection

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-03-20)
No email
send info
Thank you for addressing my Discuss point (via RFC Editor note)!

Martin Vigoureux No Objection

Warren Kumari No Objection

Comment (2019-03-05 for -06)
No email
send info
Thanks to Linda for the OpsDir review - I found it helpful.

(Adam Roach; former steering group member) (was Discuss) Yes

Yes (2019-03-19)
No email
send info
Thanks for addressing my discuss and comments.

(Ben Campbell; former steering group member) Yes

Yes ( for -05)
No email
send info

(Alexey Melnikov; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Eric Rescorla; former steering group member) No Objection

No Objection (2019-03-06 for -06)
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 steering group member) No Objection

No Objection ( for -06)
No email
send info

(Mirja K├╝hlewind; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection (2019-02-28 for -06)
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 steering group member) No Objection

No Objection (2019-03-05 for -06)
* 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 steering group member) No Objection

No Objection ( for -06)
No email
send info