A Session Initiation Protocol (SIP) Response Code for Rejected Calls
draft-ietf-sipcore-rejected-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-12-03
|
09 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-11-08
|
09 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-09-06
|
09 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-08-05
|
09 | Sheng Jiang | Assignment of request for Telechat review by OPSDIR to Sheng Jiang was rejected |
2019-07-24
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-07-23
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2019-07-18
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-07-17
|
09 | (System) | RFC Editor state changed to EDIT |
2019-07-17
|
09 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-07-17
|
09 | (System) | Announcement was received by RFC Editor |
2019-07-16
|
09 | (System) | IANA Action state changed to In Progress |
2019-07-16
|
09 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-07-16
|
09 | Cindy Morgan | IESG has approved the document |
2019-07-16
|
09 | Cindy Morgan | Closed "Approve" ballot |
2019-07-16
|
09 | Cindy Morgan | Ballot approval text was generated |
2019-07-16
|
09 | Adam Roach | This version addresses all the IESG comments and is ready for publication. |
2019-07-16
|
09 | Adam Roach | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2019-07-02
|
09 | Nancy Cam-Winget | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Nancy Cam-Winget. Sent review to list. |
2019-06-28
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-06-28
|
09 | Eric Burger | New version available: draft-ietf-sipcore-rejected-09.txt |
2019-06-28
|
09 | (System) | New version approved |
2019-06-28
|
09 | (System) | Request for posting confirmation emailed to previous authors: Eric Burger , Bhavik Nagda |
2019-06-28
|
09 | Eric Burger | Uploaded new revision |
2019-06-13
|
08 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2019-06-13
|
08 | Alexey Melnikov | [Ballot comment] Thank you for a well written document. I have one nit I would like to discuss: 4.1. Full Exchange Given an INVITE … [Ballot comment] Thank you for a well written document. I have one nit I would like to discuss: 4.1. Full Exchange Given an INVITE (shamelessly taken from [SHAKEN]): INVITE sip:+12155550113@tel.one.example.net SIP/2.0 Max-Forwards: 69 Contact: To: From: "Alice" ;tag=614bdb40 Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI P-Asserted-Identity: "Alice", CSeq: 2 INVITE Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, MESSAGE, OPTIONS Content-Type: application/sdp Date: Tue, 16 Aug 2016 19:23:38 GMT Feature-Caps: *;+sip.608 Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1I This is not syntactically valid. Either you need a space in front of the above line, or maybe it would be better if you change the above 2 lines to read: Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1I If the base64 encoded value is one line with no line breaks, you should consider pointing this out. joiaHR0cDovL2NlcnQtYXV0aC5wb2Muc3lzLmNvbWNhc3QubmV0L2V4YW1wbGUuY2VydC J9eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MTIxMyJ9LCJpYXQiOiI xNDcxMzc1NDE4Iiwib3JpZyI6eyJ0biI64oCdKzEyMTU1NTUxMjEyIn0sIm9yaWdpZCI6 IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9._28kAwRWnheXyA6n Y4MvmK5JKHZH9hSYkWI4g75mnq9Tj2lW4WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtC A;info=;alg=ES256 Content-Length: 153 |
2019-06-13
|
08 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-06-13
|
08 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2019-06-13
|
08 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-06-12
|
08 | Barry Leiba | [Ballot comment] Thanks for this document. I have only some editorial comments: — Section 1 — Here and in other sections you use “As such,” … [Ballot comment] Thanks for this document. I have only some editorial comments: — Section 1 — Here and in other sections you use “As such,” several times and always in a way that seems quite odd. I suggest removing it (or maybe sometimes replacing it with “therefore” or “thus”). Some call blocking services may return responses such as 604 There needs to be a hyphen in “call-blocking”. However, other network elements might also interpret this to mean the user truly does not exist and might result in the user not being able to receive calls from anyone, even if wanted. The “and” is wrong because the things it conjoins aren’t parallel. Change “exist and” to “exist, which” to fix that. I would also say, “even if the calls are wanted,” to make that clearer. Another value of the 607 rejection is presuming the proxy forwards the response code to the User Agent Client (UAC), the calling UAC or intervening proxies will also learn the user is not interested in receiving calls from that sender. I found that odd and hard to understand until I realized that there’s a comma missing before “presuming”. But I think a better fix is to change “presuming” to “that if”. downstream from the intermediary might interpret the 607 as coming from a user (human) that has marked the call as unwanted We customarily refer to a human as “who”, rather than “that”. Integrity protecting the jCard with a cryptographic signature Hyphenate “integrity-protecting”. — Section 3 — For clarity, this section uses the term 'intermediary' I don’t understand why the term adds clarity. Whyso? the user's UAS (colloquially, but not necessarily, their phone). I don’t thunk you mean “colloquially” here. Maybe “commonly” or “usually”? — Section 3.4 — life is good as the UAC will receive You need a comma after “good”. — Section 6 — remediation for this is for devices that insert a sip.608 feature capability only transmit media to what is highly likely to be the Either change “is for” to “is that” or insert “to” before “only”. media in response to a STIR [RFC8224]-signed INVITE It seems really weird to have a citation in the middle of the hyphenated compound “STIR-signed”. Given that you cite “STIR [RFC8224]” in the previous paragraph, I would just remove the citation here. Presumably if the target did not request the media, the check will fail. Why “presumably”? Is the statement true or not? (If the word stays, it needs a comma after it.) |
2019-06-12
|
08 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2019-06-12
|
08 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-06-12
|
08 | Warren Kumari | [Ballot comment] I generally approach SIP documents with a sense of foreboding — they are often long, expect a large amount of knowledge outside my … [Ballot comment] I generally approach SIP documents with a sense of foreboding — they are often long, expect a large amount of knowledge outside my area of expertise, and require lots of reference chasing — but this was a really good read. It describes the problem well, it lays out the protocol clearly, and contains enough humor / snark to make reading it actually enjoyable. Nits: "Another value of the 607 rejection is presuming the proxy forwards the response code to the User Agent Client (UAC), the calling UAC or intervening proxies will also learn the user is not interested in receiving calls from that sender." I found this sentence really hard to parse -- I think adding a comma after "is" fixes it. "An algorithm can be vulnerable to an algorithm subject to the base rate fallacy [BaseRate] rejecting the call." Unparsable -- duplication? Perhaps just " An algorithm can be vulnerable to the base rate fallacy [BaseRate] rejecting the call."? |
2019-06-12
|
08 | Warren Kumari | [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari |
2019-06-12
|
08 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-06-12
|
08 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-06-12
|
08 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-06-11
|
08 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2019-06-11
|
08 | Roman Danyliw | [Ballot comment] (1) Per Section 6 (Security Considerations), the risks of TEL URIs in the jCard given a malicious intermediary is helpful. I’d recommend adding … [Ballot comment] (1) Per Section 6 (Security Considerations), the risks of TEL URIs in the jCard given a malicious intermediary is helpful. I’d recommend adding language around comparable risks with the url in the jcard (e.g., that this url could point to malicious content) (2) Per Section 1, Nit. [RFC7340] is referred to a technology. However, specific draft is a requirements document. |
2019-06-11
|
08 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2019-06-11
|
08 | Benjamin Kaduk | [Ballot comment] Do we want to give any references/examples for "some jurisdictions" or "many jurisdictions"? Section 1 … [Ballot comment] Do we want to give any references/examples for "some jurisdictions" or "many jurisdictions"? Section 1 An algorithm can be vulnerable to an algorithm subject to the base rate fallacy [BaseRate] rejecting the call. [...] nit: It sounds like these are different algorithms, so that "One algorithm can be vulnerable to a separate algorithm, subject to the base rate fallacy, erroneously rejecting the call" would be more clear. Section 3.1 If there is a Call-Info header field, it MUST have the 'purpose' parameter of 'jwscard'. The value of the Call-Info header field MUST refer to a valid JSON Web Signature (JWS [RFC7515]) encoding of a jCard [RFC7095] object. Do we need to say anything about what entity('s key) generates the signature and/or what affects signature algorithm selection (e.g., a forward reference to Sections 3.2.x)? Section 3.2.2 The payload contains two JSON values. The first JSON Web Token (JWT) claim that MUST be present is the iat (issued at) claim [RFC7519]. The "iat" MUST be set to the date and time of the issuance of the 608 response. This mandatory component protects the response from replay attacks. nit(?): Perhaps this protection is only "outside the scope of a narrow window of time corresponding to the allowed RTT and any permitted time skew", per Section 3.3. Call originators (at the UAC) can use the information returned by the jCard to contact the intermediary that rejected the call to appeal the intermediary's blocking of the call attempt. What the intermediary does if the blocked caller contacts the intermediary is outside the scope of this document. It seems like it is permissible for the intermediary to reject this new call as well; can we get into some sort of recursion-like situation? Section 3.5 However, if the INVITE only indicated a real-time text codec and the network element can render the information in the requested media format, the network element MUST send the information in a text format, not an audio format. This usage of 2119 language seems odd to me, like it's calling out a single special case for normative treatment but ignoring the general case. Section 4.1 As such, implementations MUST NOT insert line breaks into the base64url encodings of the JOSE header or JWT. This also means UACs MUST be prepared to receive arbitrarily long octet streams from the URI referenced by the Call-Info SIP header. These (especially the MUST NOT) seem to just be restating requirements from elsewhere and would not ordinarily need normative language to do so. Section 6 Another risk is for an attacker to flood a proxy that supports the sip.608 feature with INVITE requests that lack the sip.608 feature capability to direct the SDP to a victim's device. [...] This sentence is pretty long/convoluted and could probably be reworded for clarity. Yet another risk is a malicious intermediary that generates a malicious 608 response with a jCard referring to a malicious agent. For example, the recipient of a 608 may receive a TEL URI in the vCard. When the recipient calls that address, the malicious agent could ask for personally identifying information. However, instead of using that information to verify the recipient's identity, they are phishing the information for nefarious ends. As such, we strongly recommend the recipient validates to whom they are communicating with if asking to adjudicate an erroneously rejected call attempt. Since we may also be concerned about intermediate nodes modifying contact information, we can address both issues with a single solution. The remediation is to require the intermediary to sign the jCard. [...] The signature is not a panacea -- the recipient needs to verify that the signature comes from a trustworthy (in some sense) entity, and that the person they contact based on the jCard is the same entity or affiliated with the entity that generated the signature. I think this is not quite the same thing as the SHAKEN/SHAKEN-like mechanisms for validating that the signing entity matches the called entity that are mentioned in the subsequent text. However, if the intermediary does go that route, the intermediary MUST use a non-deterministic reference mechanism and be prepared to return dummy responses so that attackers attempting to glean call metadata by guessing calls will not get any actionable information from the HTTPS GET. Thanks for mentioning this side channel! I'd suggest to clarify that the dummy responses are in response to URIs that might be (but are not) URIs that would be found in the "url" field of the jCard. (Assuming I'm understanding the attack correctly, of course.) |
2019-06-11
|
08 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2019-06-11
|
08 | Alissa Cooper | [Ballot comment] Please respond to the Gen-ART review. = Section 3 = I'm wondering about the case where I have an AI-driven assistant on my … [Ballot comment] Please respond to the Gen-ART review. = Section 3 = I'm wondering about the case where I have an AI-driven assistant on my client that listens for me to say "Please take me off your call list" and blocks all future calls from that caller. It seems like the 608 use case would apply (for the case of false positive voice recognition), but since the definition here limits the intermediary to an entity "in the network," this scenario is out of scope. Should it be? = Section 3.5 = "It is important to note the network element should be mindful of the media type requested by the UAC as it formulates the announcement. For example, it would make sense for an INVITE that only indicated audio codecs in the Session Description Protocol (SDP) [RFC4566] to result in an audio announcement. However, if the INVITE only indicated a real-time text codec and the network element can render the information in the requested media format, the network element MUST send the information in a text format, not an audio format." I think the normative guidance here could be crisper, e.g., replacing the first sentence with "The network element SHOULD use a media format for its announcement for which the caller indicates support, if possible." I also don't understand why the second example uses normative MUST but the first example doesn't use normative language at all. = Section 4.1 = Using "bitbucket" in the examples seems like it sends the wrong message about the utility of the contact address. |
2019-06-11
|
08 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-06-11
|
08 | Adam Roach | [Ballot comment] See also the coments posted by Brian Campbell at https://mailarchive.ietf.org/arch/msg/jwt-reg-review/k7z9wnZ0Ee7a65TiWxueJLFfFgg |
2019-06-11
|
08 | Adam Roach | Ballot comment text updated for Adam Roach |
2019-06-10
|
08 | Éric Vyncke | [Ballot comment] Thank you all for the work put into this document. I have 2 comments below == COMMENTS == -- Section 1 -- The … [Ballot comment] Thank you all for the work put into this document. I have 2 comments below == COMMENTS == -- Section 1 -- The last paragraph of the introduction describes an attack that should probably be better located in the security section. -- Section 4.1 -- In the example, I wonder whether the IPv6 syntax of "Via: SIP/2.0/UDP [2001:db8::177:60012];branch=z9hG4bK-524287-1" is correct. I would have expected "Via: SIP/2.0/UDP [2001:db8::17]:760012;branch=z9hG4bK-524287-1" but I am not a SIP expert. |
2019-06-10
|
08 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2019-06-07
|
08 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Sheng Jiang |
2019-06-07
|
08 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Sheng Jiang |
2019-06-07
|
08 | Joe Clarke | Assignment of request for Telechat review by OPSDIR to Joe Clarke was rejected |
2019-06-07
|
08 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Joe Clarke |
2019-06-07
|
08 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Joe Clarke |
2019-06-05
|
08 | Mirja Kühlewind | [Ballot comment] 1) A couple of remarks on this sentence in Sec 3.1: “If an intermediary issues a 608 code and there are not indicators … [Ballot comment] 1) A couple of remarks on this sentence in Sec 3.1: “If an intermediary issues a 608 code and there are not indicators the calling party will use the contents of the Call-Info header field for malicious purposes (see Section 6), the intermediary MUST include a Call-Info header field in the response.” a) -> s/not/no/ b) Maybe also add a “that” as it would make this long easier to read: “If an intermediary issues a 608 code and there are no indicators that the calling party will use the contents of the Call-Info header field for malicious purposes (see Section 6), … c) After having read Section 6, I find this MUST rather strong. I was expecting more “concrete” instructions. I understand why you want to have a MUST here, but section 6 reads very much like a SHOULD. 2) Editorial: In this sentence in 3.4 I also think a “that” would help: “The degenerate case is the intermediary is the only element that understands the semantics of the 608 response code.“ 3) One more purely editorial comment: Short title is “Status Reject”, however, to be closer to the long title I would rather recommend something like “SIP Response Code for Rejected Calls”. |
2019-06-05
|
08 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-06-04
|
08 | Cindy Morgan | Placed on agenda for telechat - 2019-06-13 |
2019-06-04
|
08 | Adam Roach | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-06-04
|
08 | Adam Roach | Ballot has been issued |
2019-06-04
|
08 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2019-06-04
|
08 | Adam Roach | Created "Approve" ballot |
2019-06-04
|
08 | Adam Roach | Ballot writeup was changed |
2019-06-04
|
08 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2019-06-04
|
08 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-sipcore-rejected-08. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-sipcore-rejected-08. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete. First, in the Response Codes registry on the Session Initiation Protocol (SIP) Parameters registry page located at: https://www.iana.org/assignments/sip-parameters/ a single, new SIP Response Code is to be registered as follows: Response Code: 608 Description: Rejected Reference: [ RFC-to-be ] Second, in the SIP Feature-Capability Indicator Registration Tree also on the Session Initiation Protocol (SIP) Parameters registry page located at: https://www.iana.org/assignments/sip-parameters/ a single, new registration will be made as follows: Name: sip.608 Description: This feature capability indicator, when included in a Feature-Caps header field of an INVITE request, indicates that the entity associated with the indicator will be responsible for indicating to the caller any information contained in the 608 SIP response code, specifically the value referenced by the Call-Info header. Reference: [ RFC-to-be ] Third, in the JSON Web Token Claims registry on the JSON Web Token (JWT) registry page located at: https://www.iana.org/assignments/jwt/ a single, new registration is to be made as follows: Claim Name: jcard Claim Description: jCard data Change Controller: IESG Reference: [ RFC-to-be ], [RFC7095] As this document requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the JSON Web Token Claims have asked that you send a review request to the mailing list jwt-reg-review@ietf.org. Expert review will need to be completed before your document can be approved for publication as an RFC. Fourth, in the Header Field Parameters and Parameter Values registry also on the Session Initiation Protocol (SIP) Parameters registry page located at: https://www.iana.org/assignments/sip-parameters/ the existing registration for: Header Field: Call-Info Parameter Name: purpose is to be changed to the following: Header Field: Call-Info Parameter Name: purpose Predefined Values: yes Reference: [RFC3261][RFC5367][RFC6910][RFC6993][RFC7082][RFC7852][ RFC-to-be ] The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-06-04
|
08 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-06-03
|
08 | Ines Robles | Request for Last Call review by GENART Completed: Ready. Reviewer: Ines Robles. Sent review to list. |
2019-05-23
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Nancy Cam-Winget |
2019-05-23
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Nancy Cam-Winget |
2019-05-21
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ines Robles |
2019-05-21
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ines Robles |
2019-05-21
|
08 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2019-05-21
|
08 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-06-04): From: The IESG To: IETF-Announce CC: Jean Mahoney , adam@nostrum.com, sipcore-chairs@ietf.org, sipcore@ietf.org, … The following Last Call announcement was sent out (ends 2019-06-04): From: The IESG To: IETF-Announce CC: Jean Mahoney , adam@nostrum.com, sipcore-chairs@ietf.org, sipcore@ietf.org, draft-ietf-sipcore-rejected@ietf.org, mahoney@nostrum.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (A Session Initiation Protocol (SIP) Response Code for Rejected Calls) to Proposed Standard The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'A Session Initiation Protocol (SIP) Response Code for Rejected Calls' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-06-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the 608 (Rejected) SIP response code. This response code enables calling parties to learn that an intermediary rejected their call attempt. No one will deliver, and thus no one will answer, the call. As a 6xx code, the caller will be aware that future attempts to contact the same User Agent Server will likely fail. The initial use case driving the need for the 608 response code is when the intermediary is an analytics engine. In this case, the rejection is by a machine or other process. This contrasts with the 607 (Unwanted) SIP response code, which a human at the target User Agent Server indicated the user did not want the call. In some jurisdictions this distinction is important. This document also defines the use of the Call-Info header field in 608 responses to enable rejected callers to contact entities that blocked their calls in error. This provides a remediation mechanism for legal callers that find their calls blocked. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-05-21
|
08 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2019-05-21
|
08 | Adam Roach | Last call was requested |
2019-05-21
|
08 | Adam Roach | Ballot approval text was generated |
2019-05-21
|
08 | Adam Roach | Ballot writeup was generated |
2019-05-21
|
08 | Adam Roach | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2019-05-21
|
08 | Adam Roach | Last call announcement was generated |
2019-05-21
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-05-21
|
08 | Eric Burger | New version available: draft-ietf-sipcore-rejected-08.txt |
2019-05-21
|
08 | (System) | New version approved |
2019-05-21
|
08 | (System) | Request for posting confirmation emailed to previous authors: Eric Burger , Bhavik Nagda |
2019-05-21
|
08 | Eric Burger | Uploaded new revision |
2019-05-08
|
07 | Adam Roach | Minimally, the document needs an update to fix some confusion about retrieving JSON versus JWS at the jCard URL. There may also need to be … Minimally, the document needs an update to fix some confusion about retrieving JSON versus JWS at the jCard URL. There may also need to be some updates to clarify the security model, depending on the outcome of ongoing conversations with the author. |
2019-05-08
|
07 | Adam Roach | IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested::AD Followup |
2019-04-23
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-04-23
|
07 | Eric Burger | New version available: draft-ietf-sipcore-rejected-07.txt |
2019-04-23
|
07 | (System) | New version approved |
2019-04-23
|
07 | (System) | Request for posting confirmation emailed to previous authors: Eric Burger , Bhavik Nagda |
2019-04-23
|
07 | Eric Burger | Uploaded new revision |
2019-04-22
|
06 | Adam Roach | See AD Review at https://mailarchive.ietf.org/arch/msg/sipcore/86w0ExaPcD6mVyw23k03msUtHII |
2019-04-22
|
06 | Adam Roach | IESG state changed to Publication Requested::Revised I-D Needed from Publication Requested |
2019-04-08
|
06 | Jean Mahoney | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard, which is indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document defines the 608 (Rejected) SIP response code, which informs a calling party that an intermediary has rejected their call attempt. This document also extends the Call-Info header field so that the caller may contact the blocking party if the rejection was in error. The 608 response code addresses the use case of call rejection by a call analytics engine or other automated process. This contrasts with the 607 (Unwanted) SIP response code, which is sent by a SIP user agent when a human indicates that the call was not wanted [RFC8197]. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The document is of interest to the STIR (Secure Telephone Identity Revisited) WG, but discussions were (mostly) kept to the SIPCORE mailing list since the document covers a SIP extension. Sometimes cross-posting was not successful and some discussions occurred only on the STIR mailing list. All feedback that was discussed on the STIR mailing list was incorporated into the document, however. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? One of the authors (Bhavik Nagda) implemented this solution in Kamailio, which is an open source SIP server. The implementation can be found at https://github.com/nagdab/608_implementation. There are also governmental agencies that are interested in the 608 response code feature. Reviewers and their contributions have been called out in the Acknowledgements section. Tolga Asveren provided substantial feedback on interoperability and security considerations. Personnel Who is the Document Shepherd? Jean Mahoney Who is the Responsible Area Director? Adam Roach (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd checked that all feedback provided on both the STIR and SIPCORE lists was incorporated or otherwise addressed in document updates. This document is ready to be forwarded to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document shepherd is satisfied with the breadth and depth of reviews performed by the working group. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. None required. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The Document Shepherd has no specific concerns or issues with the draft. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. The authors confirmed that they have no IPR to declare on this draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been filed. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The draft was adopted by the working group with lots of +1s. It received thorough feedback from a handful of WG participants in both STIR and SIPCORE. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No one has indicated any discontent with the draft. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. idnits 2.15.01 was run, and no issues were found. The Shepherd checked the draft against https://www.ietf.org/standards/ids/checklist/. No issues were found with the draft. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Documents that specify new JSON Web Token claims must pass through an Expert Review system [RFC7519]. The document shepherd sent email to jwt-reg-review@ietf.org (https://mailarchive.ietf.org/arch/msg/jwt-reg-review/MBwhnKNwQLzWZt0d4tsT2W7Lvwc). In their roles as Designated Experts, Mike Jones and Brian Campbell approved the registration request. The updates made to the SIP Parameters IANA registries by this document fall under the registration procedures of either "RFC Required" or "IETF Review" [RFC5226], so the typical review process for a standards-track document is sufficient. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? All normative references are to published RFCs. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are no downward normative references. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document does not change the status of any published RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA Considerations section clearly identifies the appropriate sub-registries within the "Session Initiation Protocols" registry, and describes the new rows to add to those subregistries. The IANA Considerations section clearly identifies the "JSON Web Token Claims" sub-registry within the "JSON Web Token (JWT)" registry, and describes the new row to add to the subregistry. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. This document does not define any new IANA registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There is no formal language defined in this document. |
2019-04-08
|
06 | Jean Mahoney | Responsible AD changed to Adam Roach |
2019-04-08
|
06 | Jean Mahoney | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2019-04-08
|
06 | Jean Mahoney | IESG state changed to Publication Requested from I-D Exists |
2019-04-08
|
06 | Jean Mahoney | IESG process started in state Publication Requested |
2019-04-08
|
06 | Jean Mahoney | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard, which is indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document defines the 608 (Rejected) SIP response code, which informs a calling party that an intermediary has rejected their call attempt. This document also extends the Call-Info header field so that the caller may contact the blocking party if the rejection was in error. The 608 response code addresses the use case of call rejection by a call analytics engine or other automated process. This contrasts with the 607 (Unwanted) SIP response code, which is sent by a SIP user agent when a human indicates that the call was not wanted [RFC8197]. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The document is of interest to the STIR (Secure Telephone Identity Revisited) WG, but discussions were (mostly) kept to the SIPCORE mailing list since the document covers a SIP extension. Sometimes cross-posting was not successful and some discussions occurred only on the STIR mailing list. All feedback that was discussed on the STIR mailing list was incorporated into the document, however. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? One of the authors (Bhavik Nagda) implemented this solution in Kamailio, which is an open source SIP server. The implementation can be found at https://github.com/nagdab/608_implementation. There are also governmental agencies that are interested in the 608 response code feature. Reviewers and their contributions have been called out in the Acknowledgements section. Tolga Asveren provided substantial feedback on interoperability and security considerations. Personnel Who is the Document Shepherd? Jean Mahoney Who is the Responsible Area Director? Adam Roach (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd checked that all feedback provided on both the STIR and SIPCORE lists was incorporated or otherwise addressed in document updates. This document is ready to be forwarded to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document shepherd is satisfied with the breadth and depth of reviews performed by the working group. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. None required. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The Document Shepherd has no specific concerns or issues with the draft. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. The authors confirmed that they have no IPR to declare on this draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been filed. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The draft was adopted by the working group with lots of +1s. It received thorough feedback from a handful of WG participants in both STIR and SIPCORE. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No one has indicated any discontent with the draft. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. idnits 2.15.01 was run, and no issues were found. The Shepherd checked the draft against https://www.ietf.org/standards/ids/checklist/. No issues were found with the draft. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Documents that specify new JSON Web Token claims must pass through an Expert Review system [RFC7519]. The document shepherd sent email to jwt-reg-review@ietf.org (https://mailarchive.ietf.org/arch/msg/jwt-reg-review/MBwhnKNwQLzWZt0d4tsT2W7Lvwc). In their roles as Designated Experts, Mike Jones and Brian Campbell approved the registration request. The updates made to the SIP Parameters IANA registries by this document fall under the registration procedures of either "RFC Required" or "IETF Review" [RFC5226], so the typical review process for a standards-track document is sufficient. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? All normative references are to published RFCs. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are no downward normative references. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document does not change the status of any published RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA Considerations section clearly identifies the appropriate sub-registries within the "Session Initiation Protocols" registry, and describes the new rows to add to those subregistries. The IANA Considerations section clearly identifies the "JSON Web Token Claims" sub-registry within the "JSON Web Token (JWT)" registry, and describes the new row to add to the subregistry. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. This document does not define any new IANA registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There is no formal language defined in this document. |
2019-04-07
|
06 | Eric Burger | New version available: draft-ietf-sipcore-rejected-06.txt |
2019-04-07
|
06 | (System) | New version approved |
2019-04-07
|
06 | (System) | Request for posting confirmation emailed to previous authors: Eric Burger , Bhavik Nagda |
2019-04-07
|
06 | Eric Burger | Uploaded new revision |
2019-03-31
|
05 | Eric Burger | New version available: draft-ietf-sipcore-rejected-05.txt |
2019-03-31
|
05 | (System) | New version approved |
2019-03-31
|
05 | (System) | Request for posting confirmation emailed to previous authors: Eric Burger , Bhavik Nagda |
2019-03-31
|
05 | Eric Burger | Uploaded new revision |
2019-03-27
|
04 | Eric Burger | New version available: draft-ietf-sipcore-rejected-04.txt |
2019-03-27
|
04 | (System) | New version approved |
2019-03-27
|
04 | (System) | Request for posting confirmation emailed to previous authors: Eric Burger , Bhavik Nagda |
2019-03-27
|
04 | Eric Burger | Uploaded new revision |
2019-02-28
|
03 | Jean Mahoney | Changed consensus to Yes from Unknown |
2019-02-28
|
03 | Jean Mahoney | Intended Status changed to Proposed Standard from None |
2019-02-27
|
03 | Jean Mahoney | Notification list changed to Jean Mahoney <mahoney@nostrum.com> |
2019-02-27
|
03 | Jean Mahoney | Document shepherd changed to Jean Mahoney |
2019-02-03
|
03 | Eric Burger | New version available: draft-ietf-sipcore-rejected-03.txt |
2019-02-03
|
03 | (System) | New version approved |
2019-02-03
|
03 | (System) | Request for posting confirmation emailed to previous authors: Eric Burger , sipcore-chairs@ietf.org |
2019-02-03
|
03 | Eric Burger | Uploaded new revision |
2018-12-28
|
02 | Eric Burger | New version available: draft-ietf-sipcore-rejected-02.txt |
2018-12-28
|
02 | (System) | New version approved |
2018-12-28
|
02 | (System) | Request for posting confirmation emailed to previous authors: Eric Burger |
2018-12-28
|
02 | Eric Burger | Uploaded new revision |
2018-11-25
|
01 | Eric Burger | New version available: draft-ietf-sipcore-rejected-01.txt |
2018-11-25
|
01 | (System) | New version approved |
2018-11-25
|
01 | (System) | Request for posting confirmation emailed to previous authors: Eric Burger |
2018-11-25
|
01 | Eric Burger | Uploaded new revision |
2018-08-21
|
00 | Jean Mahoney | This document now replaces draft-burger-sipcore-rejected instead of None |
2018-08-21
|
00 | Eric Burger | New version available: draft-ietf-sipcore-rejected-00.txt |
2018-08-21
|
00 | (System) | WG -00 approved |
2018-08-21
|
00 | Eric Burger | Set submitter to ""Eric W. Burger" ", replaces to draft-burger-sipcore-rejected and sent approval email to group chairs: sipcore-chairs@ietf.org |
2018-08-21
|
00 | Eric Burger | Uploaded new revision |