A Session Initiation Protocol (SIP) Response Code for Rejected Calls
draft-ietf-sipcore-rejected-09

[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

[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.)

[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."?

[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.

[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.)

[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.

[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.

[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”.

(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

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.

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.

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.

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.