An Extension to the Session Initiation Protocol (SIP) for Request History Information
draft-ietf-sipcore-rfc4244bis-12
Yes
(Richard Barnes)
(Robert Sparks)
No Objection
(Adrian Farrel)
(Barry Leiba)
(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Martin Stiemerling)
(Sean Turner)
(Stewart Bryant)
Note: This ballot was opened for revision 09 and is now closed.
Richard Barnes Former IESG member
Yes
Yes
(for -11)
Unknown
Robert Sparks Former IESG member
Yes
Yes
(2013-03-08 for -11)
Unknown
Spencer Dawkins Former IESG member
(was Discuss)
Yes
Yes
(2013-10-04 for -11)
Unknown
Thanks to my fellow ADs for helping me clear my Discuss Discuss. I had one minor comment, which is a comment because I think I understand the text. Please let me know if I don't understand the text. In 6. User Agent Handling of the History-Info Header Field A back-to-back user agent (B2BUA) MAY follow the behavior of a SIP intermediary as an alternative to following the behavior of a user agent server (UAS) per Section 6.2 and a UAC per Section 6.1. In behaving as an intermediary, a B2BUA carries forward hi-entries received in requests at the UAS to requests being forwarded by the UAC, as well as carrying forward hi-entries in responses received at the UAC to the responses forwarded by the UAS, subject to privacy considerations per Section 10.1. I'm not seeing that the section title matches the contents - something like "Back-to-back User Agent Handling of the History-Info Header Field" would be closer. Given the current title, I'd expect this section to describe what's common between 6.1 and 6.2, but it's only saying that B2BUAs have the option of doing what's in 6.1 and 6.2. Also in this text, it would be helpful to have a reference for "behavior of a SIP intermediary", if there's an obvious candidate.
Adrian Farrel Former IESG member
No Objection
No Objection
(for -11)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -11)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2013-10-09 for -11)
Unknown
Thanks for these 2 sections, which I like very much for a bis document: 16. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 29 16.1. Backwards compatibility . . . . . . . . . . . . . . . . . 30
Brian Haberman Former IESG member
No Objection
No Objection
(for -11)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -11)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -11)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -11)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2013-10-09 for -11)
Unknown
Section 3, list item 2: The terminology is not what email folks would use. Instead, "Email relaying whereby the recipient obtains a detailed "trace of the path" of the message from originator to receiver, including the time of each relay." You could get more complicated and talk about resent events, but I think the above is fine for just an example. Section 5: The ABNF definitions for "generic-param" and "name-addr" are from [RFC3261]. Also, HCOLON, COMMA, SEMI, EQUAL, and addr-spec. Section 6: That "MAY" is not a 2119 MAY. I suggest lowercasing, or changing it to "can". 6.1, 6.2, 7, 8, 9.1, 9.2: I find the forward references using "MUST follow the procedures defined in..." a bit weird. Seems like it would have been easier to follow if all of the MUSTs were collected together in the target section. No big deal; just editorial.
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(for -11)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2013-10-30)
Unknown
Thanks for handling my discuss points. On reflection it'd be wrong to try to force the issue of whether TLS is more than a SHOULD for SIP in this document, so I've cleared. But that is something I hope that SIP/RAI folks will work on more generally. For example, its very easy to see implementers getting the added MUST in section 13 wrong, or just doing nothing about it. The bit I mean is this: If TLS is NOT used, the intermediary MUST ensure that the messages are only sent within an environment that is secured by other means or that the messages don't leave the intermediary's domain.
Stewart Bryant Former IESG member
No Objection
No Objection
(for -11)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(2013-10-09 for -11)
Unknown
Section 5, after the ABNF: The ABNF definitions for "generic-param" and "name-addr" are from [RFC3261]. I think addr-spec is also from RFC 3261? In section 9.3: Step 2: Add Reason header field The SIP entity adds one or more Reason header fields to the hi- targeted-to-uri in the (newly) cached hi-entry reflecting the SIP response code in the non-100 response, per the procedures of Section 10.2. But in 10.2: A Reason header field is added to the "headers" component in an hi- targeted-to-uri when the hi-entry is added to the cache based upon the receipt of a non-100 or non-2xx SIP response, as described in Section 9.3. Section 9.3 seems to miss excluding non-200 responses, unless I misunderstood it. I think that 9.3 and 10.2 should be mutually consistent. Otherwise, looks good to my SIP-innocent eyes. :)