Personal Assertion Token (PASSporT) Extension for Diverted Calls
draft-ietf-stir-passport-divert-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-02-12
|
09 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-10-26
|
09 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-09-28
|
09 | (System) | Removed unintended duplicate opsdir lc review |
2020-09-28
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-09-28
|
09 | (System) | RFC Editor state changed to RFC-EDITOR from IANA |
2020-09-28
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-09-28
|
09 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-07-31
|
09 | (System) | RFC Editor state changed to IANA from EDIT |
2020-07-28
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-07-24
|
09 | (System) | RFC Editor state changed to EDIT |
2020-07-24
|
09 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-07-24
|
09 | (System) | Announcement was received by RFC Editor |
2020-07-24
|
09 | (System) | IANA Action state changed to In Progress |
2020-07-24
|
09 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-07-24
|
09 | Cindy Morgan | IESG has approved the document |
2020-07-24
|
09 | Cindy Morgan | Closed "Approve" ballot |
2020-07-24
|
09 | Cindy Morgan | Ballot approval text was generated |
2020-07-24
|
09 | Murray Kucherawy | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-07-23
|
09 | Roman Danyliw | [Ballot comment] Thank you for addressing my DISCUSS and COMMENT items. |
2020-07-23
|
09 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2020-07-17
|
09 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my Discuss (and Comment) points! |
2020-07-17
|
09 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2020-07-15
|
09 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK from Issues identified |
2020-07-15
|
09 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-07-13
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-07-13
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2020-07-13
|
09 | Jon Peterson | New version available: draft-ietf-stir-passport-divert-09.txt |
2020-07-13
|
09 | (System) | New version approved |
2020-07-13
|
09 | (System) | Request for posting confirmation emailed to previous authors: Jon Peterson |
2020-07-13
|
09 | Jon Peterson | Uploaded new revision |
2020-04-09
|
08 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-04-08
|
08 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2020-04-08
|
08 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-04-08
|
08 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2020-04-08
|
08 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-04-07
|
08 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2020-04-07
|
08 | Benjamin Kaduk | [Ballot discuss] I support Roman's Discuss. Isn't there a straightforward translation of the "div" procedures to the nested "div-o" chain? Why would that not be … [Ballot discuss] I support Roman's Discuss. Isn't there a straightforward translation of the "div" procedures to the nested "div-o" chain? Why would that not be applicable? I had two other points for discussion: (1) IANA seems unhappy (the expert review identified issues). What's the plan to address them? (2) The following text from the Security Considerations seems inconsistent to me: However, including this information about forwarding is at the discretion of the retargeting entity, so if there is a requirement to keep the original called number confidential, no PASSporT should be created for that retargeting - the only consequence will be that downstream entities will be unable to correlate an incoming call with the original PASSporT without access to some prior knowledge of the policies that could have caused the retargeting. I don't understand this -- if the idea is to keep the original called number confidential, wouldn't this necessitate *not giving the original PASSporT to the called entity*, since the original PASSporT includes the original call destination? Without the original PASSporT at all, of course it can't be correlated to an incoming call... (Even in the OOB case, would the post-retargeting called entity even be able to retrieve/decrypt the original PASSporT?) Is this intended to only apply to some non-SIP case? |
2020-04-07
|
08 | Benjamin Kaduk | [Ballot comment] While it looks like the main change in the -08 is intended to address the secdir reviewer's comment, it would be nice to … [Ballot comment] While it looks like the main change in the -08 is intended to address the secdir reviewer's comment, it would be nice to respond to the review and mention the new text. Do we need to say something about whitespace being added to examples for readability? Section 1 Is there an intended mnemonic for the "opt" element? ("Original passport"?) Do "div-o" PASSporTs necessarily carry both "div" and "opt", or is "opt" intended to be able to stand alone in a "div-o" PASSporT? Section 3 canonical form of the "dest" identifiier is not changed during nit: s/identifiier/identifier/ A "div" PASSporT claims set is populated with elements drawn from the PASSporT(s) received for a call by the retargeting entity: at a high When would there be multiple received PASSporTs that all are input to the same "div" PASSporT? Also, the later discussion that indicates only a small number of claims/extensions are copied from the original PASSporT (and that "iat" might change!) suggests that perhaps the "is populated with" language could be tweaked. level, the original identifier for the called party in the "dest" object will become the "div" claim in the new PASSporT. If the This "will become" language seems a bit problematic when combined with the definition in Section 8 of an "hi" element within the "div" claim, which is not part of the "original identifier for the called party". The combined full form PASSporT (with a signature covered by the ES256 keys given in Appendix A) would look as follows: eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0IiwieDV1Ij \ oiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuI \ jpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMTMifSwiaWF \ 0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.xBHWipDEE \ J8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxmChHhVIiMT \ SqIlk3yCNkg (The decoded claims set is sorted, though the previous display-form example was in a different order.) Section 4 This section specifies SIP-specific usage for the "div" PASSporT type and its handling in the SIP Identity header field "ppt" parameter value. Other protocols using PASSporT may define behavior specific to their use of the "div" claim. Is the last line supposed to be "claim" or "PASSporT type"? Section 4.1 The retargeting entity SHOULD act as a verification service and validate the existing Identity header field value(s) in the request before proceeding; in some high-volume environments, it may instead put that burden of validating the chain entirely on the terminating verification service. As the authentication service will be adding a Is this intended to be the only allowed exception to the SHOULD? (Can we phrase it as a MUST instead, e.g., "except when it is know that the terminating verification service will do so, the retargeting entity MUST act as a verification service"?) PASSporT. Note that this effectively creates multiple chains of "div" PASSporTs in a single request, which complicates the procedures that need to be performed at verification services. [ponders whether there should be more security considerations about these added complications] not for "div" PASSporTs with earlier targets. Ordinarily, the current target will be readily identifiable, as it will be in the last "div" PASSporT in each chain, and in SIP cases it will correspond to the Request-URI received by the retargeting entity. Moreover, the current target will be an identifier that the retargeting entity possess a credential to sign for, which may not be true for earlier targets. Ultimately, on each retargeting, the number of PASSporTs added to a request will be equal to the number of non-"div" PASSporTs that do not share the same "orig" and "dest" object values. We seem to be providing two or three descriptions of the number of new "div" PASSporTs to be created, and it's hard to have full confidence that all are guaranteed to produce identical results. Is it possible to clarify a single definitive procedure? Section 4.2 In order to validate a SIP request using the "div" PASSporT type, a verification service needs to inspect all of the valid Identity header field values associated with a request, as an Identity header field value containing "div" necessarily refers to an earlier PASSporT already in the message. [...] (refers to one or more earlier PASSporT, no?) Deployments that change the original To header field value to conceal the original destination of the call from the ultimate recipient should note that the original destination of a call may be preserved in the innermost PASSporT. [...] Should this also be noted in the security considerations? Section 5 This specification defines a "div-o" PASSporT type that uses the "div" claim element in conjunction with the opt (Section 6) PASSporT claim element. As is the case with "div" PASSporT type, a "div-o" nit: any reason why we refer to "div" as a "claim element" but "opt" (with no quotes!) as a "PASSporT claim element"? Section 6 The presence of an original PASSporT claims set element, designated as "opt", signifies that a PASSporT encapsulates another entire PASSporT within it, typically a PASSporT that was transformed in some way to create the current PASSporT. Relying parties may need to consult the encapsulated PASSporT in order to validate the identity of a caller. "opt" as defined in this specification may be used by future PASSporT extensions as well as in conjunction with "div-o". All the more reason for this document to specify the "div-o" usage's validation procedures! Section 7 an impractical number of combinations. But in very complex call routing scenarios, attestation of source identity would only add limited value anyway. I'm not sure what point this last sentence is trying to make. "Yes this is complicated, but no one would do it anyway"? That doesn't really support the case for retargeting over redirecting... STIR-aware SIP intermediaries that redirect requests MAY therefore convey one or more PASSporTs in the backwards direction within Identity header fields. These redirecting entities will act as authentication services for "div" as described in Section 4.1. This document consequently updates [RFC8224] to permit carrying Identity header fields in SIP 300-class responses. It is left to the originating user agent to determine which Identity header fields should be copied from the 3xx into any new requests resulting from the redirection, if any: use of these Identity header fields by entities receiving a 3xx response is OPTIONAL. Is the idea that making this use optional obviates any need for a negotiation mechanism where the originating user agent indicates support for receiving PASSporTs in the 300-class response? Section 10.1.2 Claim Description: Encapsulated JSON token Is it an encapsulated "JSON token" or "PASSporT [JSON Web Token]"? Section 11 However, as there may be unforeseen circumstances where the revelation of service logic to the called party poses a privacy risk, implementers and users of this or similar diversion-tracking techniques should understand the trade-off. Don't the 300-class redirections also involve some revelation of information to the calling party? I think that could be worth mentioning (though it's not specific to the PASSporT case). Furthermore, it is a general privacy risk of identity mechanisms overall that they do not interface well with anonymization services; the interaction of STIR with anonymization services is detailed in [RFC8224] Section 11. Any forwarding services that acts as an anonymizing proxy may not be able to provide a secure chain of retargeting due to the obfuscation of the originating identity. Isn't there also a risk that an anonymizing proxy might not know to remove all the (information contained in the) PASSporTs, thus inadvertently leaking identity information? Section 12 risk arises at the discretion of the retargeting domain: simply using 3xx response redirections rather than retargeting (with supply a "div" per Section 7) mitigates the potential impact. Under unusual nit: grammar is weird around "with supply a 'div'" Appendix A Thanks for including the keys needed to validate the examples! (Alas, I don't have a JWT or JOSE library handy, so I didn't do so...) |
2020-04-07
|
08 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2020-04-07
|
08 | Roman Danyliw | [Ballot discuss] Section 5. The text notes that procedures for the authentication and verification service for the “div-o” claim will be “left to future work”. … [Ballot discuss] Section 5. The text notes that procedures for the authentication and verification service for the “div-o” claim will be “left to future work”. Can the rational for this deferral be explained. Creating an interoperable solution without this guidance seem challenging as it would be crucial guidance on processing this newly introduced claim. |
2020-04-07
|
08 | Roman Danyliw | [Ballot comment] Please respond to Phillip Hallam-Baker SECDIR review (thanks Phillip!) ** Section 4.1. Per “Provided that these PASSporTs share the same "orig" and "dest" … [Ballot comment] Please respond to Phillip Hallam-Baker SECDIR review (thanks Phillip!) ** Section 4.1. Per “Provided that these PASSporTs share the same "orig" and "dest" values, the retargeting entity's authentication service SHOULD generate only one "div" PASSporT”, why not MUST here? What’s the corner case? ** Section 4.2. Per “However, note that in some use cases, including certain ways that blind transfer is implemented, it is possible that an established call will be retargeted long after it has originally been placed, and verification services may want to allow a longer window for the freshness of the innermost PASSporT if the call is transferred from a trusted party.”, are there any recommendations or bounds that can be placed on the duration of this “longer window of freshness”? ** Editorial Nit: -- Section 3. Typo. s/identifiier/identifier/ |
2020-04-07
|
08 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2020-04-07
|
08 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-04-07
|
08 | Warren Kumari | [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from No Record |
2020-04-07
|
08 | Warren Kumari | [Ballot comment] Thanks to Linda Dunbar for the OpsDir review. |
2020-04-07
|
08 | Warren Kumari | Ballot comment text updated for Warren Kumari |
2020-04-06
|
08 | Barry Leiba | [Ballot comment] Thanks for a well-written document, Jon. |
2020-04-06
|
08 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-04-06
|
08 | Alissa Cooper | [Ballot comment] Please respond to the Gen-ART review. |
2020-04-06
|
08 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-04-06
|
08 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2020-04-03
|
08 | Erik Kline | [Ballot comment] [nits] S3 * Reference to 8224 section 8 might consider pointing all the way to 8.3 (vis. RFC 8225 section 5.2.1.1), perhaps? … [Ballot comment] [nits] S3 * Reference to 8224 section 8 might consider pointing all the way to 8.3 (vis. RFC 8225 section 5.2.1.1), perhaps? S4.1 * s/possess a credential/possesses a credential/ (I think) S4.2 * Perhaps start a new paragraph at "A verification service parses..."? * Does "blind transfer" have a reference to describe it? It probably doesn't need one for the intended audience...I was just curious. |
2020-04-03
|
08 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2020-04-01
|
08 | Martin Duke | [Ballot comment] Though dense, this was readable by someone with no background in the subject. Only one nit: in section 3, s/identifier/identifier. |
2020-04-01
|
08 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2020-03-30
|
08 | Amy Vezza | Placed on agenda for telechat - 2020-04-09 |
2020-03-28
|
08 | Murray Kucherawy | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2020-03-28
|
08 | Murray Kucherawy | Ballot has been issued |
2020-03-28
|
08 | Murray Kucherawy | [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy |
2020-03-28
|
08 | Murray Kucherawy | Created "Approve" ballot |
2020-03-28
|
08 | Murray Kucherawy | IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup::AD Followup |
2020-03-28
|
08 | Murray Kucherawy | Ballot writeup was changed |
2020-03-28
|
08 | Murray Kucherawy | Ballot writeup was changed |
2020-03-25
|
08 | Amy Vezza | Shepherding AD changed to Murray Kucherawy |
2020-03-09
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-03-09
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2020-03-09
|
08 | Jon Peterson | New version available: draft-ietf-stir-passport-divert-08.txt |
2020-03-09
|
08 | (System) | New version approved |
2020-03-09
|
08 | (System) | Request for posting confirmation emailed to previous authors: Jon Peterson |
2020-03-09
|
08 | Jon Peterson | Uploaded new revision |
2020-01-09
|
07 | Pete Resnick | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Pete Resnick. Sent review to list. |
2019-12-09
|
07 | Adam Roach | Waiting for author follow-up to last-call directorate reviews. |
2019-12-09
|
07 | Adam Roach | IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup |
2019-12-03
|
07 | Amanda Baber | PASSporT registrations approved. JWT Claims experts would like the issues described in jwt-reg-review mailing list review resolved before registration. |
2019-12-03
|
07 | Amanda Baber | IANA Experts State changed to Issues identified |
2019-12-02
|
07 | Linda Dunbar | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Linda Dunbar. Sent review to list. |
2019-12-02
|
07 | Linda Dunbar | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Linda Dunbar. Sent review to list. |
2019-12-02
|
07 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-11-30
|
07 | Phillip Hallam-Baker | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Phillip Hallam-Baker. Sent review to list. |
2019-11-30
|
07 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2019-11-30
|
07 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-stir-passport-divert-07. 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-stir-passport-divert-07. 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 two actions which we must complete. First, in the JSON Web Token Claims registry on the JSON Web Token (JWT) registry page located at https://www.iana.org/assignments/jwt/ two new claims are to be registered: Claim Name: div Claim Description: New Target of a Call Change Controller: IESG Reference: [ RFC-to-be ] Claim Name: opt Claim Description: Encapsulated JSON token Change Controller: IESG Reference: [ RFC-to-be ] As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have sent a reminder to the designated experts that a review request is pending on the jwt-reg-review@ietf.org mailing list. This review must be completed before the document's IANA state can be changed to "IANA OK." Second, in the Personal Assertion Token (PASSporT) Extensions registry on the Personal Assertion Token (PASSporT) registry page located at https://www.iana.org/assignments/passport/ two new extensions will be registered: ppt value: div Reference: [ RFC-to-be, Section 3] ppt value: div-o Reference: [ RFC-to-be, Section 5] As this section of the document also requests registrations in an Expert Review or Specification Required registry, we have initiated the required expert review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." 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, Amanda Baber Lead IANA Services Specialist |
2019-11-20
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
2019-11-20
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
2019-11-20
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2019-11-20
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2019-11-20
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Linda Dunbar |
2019-11-20
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Linda Dunbar |
2019-11-18
|
07 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2019-11-18
|
07 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-12-02): From: The IESG To: IETF-Announce CC: adam@nostrum.com, Russ Housley , housley@vigilsec.com, draft-ietf-stir-passport-divert@ietf.org, … The following Last Call announcement was sent out (ends 2019-12-02): From: The IESG To: IETF-Announce CC: adam@nostrum.com, Russ Housley , housley@vigilsec.com, draft-ietf-stir-passport-divert@ietf.org, stir@ietf.org, stir-chairs@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (PASSporT Extension for Diverted Calls) to Proposed Standard The IESG has received a request from the Secure Telephone Identity Revisited WG (stir) to consider the following document: - 'PASSporT Extension for Diverted 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 last-call@ietf.org mailing lists by 2019-12-02. 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 PASSporT is specified in RFC 8225 to convey cryptographically-signed information about the people involved in personal communications. This document extends PASSporT to include an indication that a call has been diverted from its original destination to a new one. This information can greatly improve the decisions made by verification services in call forwarding scenarios. Also specified here is an encapsulation mechanism for nesting a PASSporT within another PASSporT that assists relying parties in some diversion scenarios. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-stir-passport-divert/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-stir-passport-divert/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-11-18
|
07 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2019-11-18
|
07 | Adam Roach | Last call was requested |
2019-11-18
|
07 | Adam Roach | Last call announcement was generated |
2019-11-18
|
07 | Adam Roach | Ballot approval text was generated |
2019-11-18
|
07 | Adam Roach | Ballot writeup was generated |
2019-11-18
|
07 | Adam Roach | This version is ready for IETF last call. |
2019-11-18
|
07 | Adam Roach | IESG state changed to Last Call Requested from Publication Requested::AD Followup |
2019-11-04
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-11-04
|
07 | Jon Peterson | New version available: draft-ietf-stir-passport-divert-07.txt |
2019-11-04
|
07 | (System) | New version approved |
2019-11-04
|
07 | (System) | Request for posting confirmation emailed to previous authors: Jon Peterson |
2019-11-04
|
07 | Jon Peterson | Uploaded new revision |
2019-10-14
|
06 | Adam Roach | See AD review at https://mailarchive.ietf.org/arch/msg/stir/Vx13C0G6XR9Nbrgg-4aX0BgQ-zs |
2019-10-14
|
06 | Adam Roach | IESG state changed to Publication Requested::Revised I-D Needed from Publication Requested |
2019-07-12
|
06 | Russ Housley | Added to session: IETF-105: stir Mon-1000 |
2019-07-12
|
06 | Russ Housley | (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? … (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? Standards track RFC is requested. Yes, this appears on the title page of the Internet-Draft. (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 This document extends the STIR PASSporT specification to allow the inclusion of cryptographically-signed assertions to indicate that a call has been diverted from its original destination to a new one. Working Group Summary The STIR WG reached consensus, and there is strong support for publication of this document. Document Quality Several people have expressed interest in implementing this specification. Personnel Russ Housley is the Document Shepherd. Adam Roach is the Responsible Area Director. (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 did a complete review of -05, and all items of concern were corrected. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns at all. (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. The JWT claim registration was requested on 12 April 2019: https://mailarchive.ietf.org/arch/msg/jwt-reg-review/1r37p6v5mOBJlmvhu0bndbZQEOo No additional review is needed. (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. No concerns at all. (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 author has confirmed that he is unaware of any IPR disclosures that need to be submitted. (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 submitted against this document. (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 STIR WG reached consensus, and there is strong support for publication of this document. (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 threatened to appeal or expressed discontent. (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 raises two warnings. The first warning is about the use of [RFCThis] in the IANA Considerations section. This will be resolved by IANA and the RFC Editor as part of publication. The second warning is about the 'Updates:' line on the title page. It should say: Updates: 8224 (if approved) That is, the "RFC" should not be included. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No additional formal review is needed for this document. (13) Have all references within this document been identified as either normative or informative? Yes, informative and normative references appear is separate sections in the document. (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? The [RFCThis] reference will progress at roughly the same time. (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 downrefs. (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. No, publication of this document will not change the status of any other documents. (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 appear to be complete. (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. No new IANA registries are created. Some entries are added to existing 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. None is needed for this document. |
2019-07-12
|
06 | Russ Housley | Responsible AD changed to Adam Roach |
2019-07-12
|
06 | Russ Housley | IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead |
2019-07-12
|
06 | Russ Housley | IESG state changed to Publication Requested from I-D Exists |
2019-07-12
|
06 | Russ Housley | IESG process started in state Publication Requested |
2019-07-12
|
06 | Russ Housley | (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? … (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? Standards track RFC is requested. Yes, this appears on the title page of the Internet-Draft. (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 This document extends the STIR PASSporT specification to allow the inclusion of cryptographically-signed assertions to indicate that a call has been diverted from its original destination to a new one. Working Group Summary The STIR WG reached consensus, and there is strong support for publication of this document. Document Quality Several people have expressed interest in implementing this specification. Personnel Russ Housley is the Document Shepherd. Adam Roach is the Responsible Area Director. (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 did a complete review of -05, and all items of concern were corrected. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns at all. (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. The JWT claim registration was requested on 12 April 2019: https://mailarchive.ietf.org/arch/msg/jwt-reg-review/1r37p6v5mOBJlmvhu0bndbZQEOo No additional review is needed. (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. No concerns at all. (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 author has confirmed that he is unaware of any IPR disclosures that need to be submitted. (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 submitted against this document. (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 STIR WG reached consensus, and there is strong support for publication of this document. (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 threatened to appeal or expressed discontent. (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 raises two warnings. The first warning is about the use of [RFCThis] in the IANA Considerations section. This will be resolved by IANA and the RFC Editor as part of publication. The second warning is about the 'Updates:' line on the title page. It should say: Updates: 8224 (if approved) That is, the "RFC" should not be included. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No additional formal review is needed for this document. (13) Have all references within this document been identified as either normative or informative? Yes, informative and normative references appear is separate sections in the document. (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? The [RFCThis] reference will progress at roughly the same time. (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 downrefs. (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. No, publication of this document will not change the status of any other documents. (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 appear to be complete. (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. No new IANA registries are created. Some entries are added to existing 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. None is needed for this document. |
2019-07-12
|
06 | Russ Housley | Notification list changed to Russ Housley <housley@vigilsec.com> |
2019-07-12
|
06 | Russ Housley | Document shepherd changed to Russ Housley |
2019-07-12
|
06 | Russ Housley | Tag Revised I-D Needed - Issue raised by WG cleared. |
2019-07-12
|
06 | Russ Housley | Changed consensus to Yes from Unknown |
2019-07-12
|
06 | Russ Housley | Intended Status changed to Proposed Standard from None |
2019-07-08
|
06 | Jon Peterson | New version available: draft-ietf-stir-passport-divert-06.txt |
2019-07-08
|
06 | (System) | New version approved |
2019-07-08
|
06 | (System) | Request for posting confirmation emailed to previous authors: Jon Peterson |
2019-07-08
|
06 | Jon Peterson | Uploaded new revision |
2019-07-02
|
05 | Robert Sparks | Tag Revised I-D Needed - Issue raised by WG set. |
2019-07-02
|
05 | Robert Sparks | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2019-03-31
|
05 | Russ Housley | Second WG Last Call for this document since significant changes were made. |
2019-03-31
|
05 | Russ Housley | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2019-03-31
|
05 | Russ Housley | IETF WG state changed to In WG Last Call from WG Document |
2019-03-26
|
05 | Robert Sparks | Added to session: IETF-104: stir Fri-0900 |
2019-02-19
|
05 | Jon Peterson | New version available: draft-ietf-stir-passport-divert-05.txt |
2019-02-19
|
05 | (System) | New version approved |
2019-02-19
|
05 | (System) | Request for posting confirmation emailed to previous authors: Jon Peterson |
2019-02-19
|
05 | Jon Peterson | Uploaded new revision |
2019-01-30
|
04 | Robert Sparks | Tag Revised I-D Needed - Issue raised by WGLC set. |
2019-01-30
|
04 | Robert Sparks | IETF WG state changed to WG Document from In WG Last Call |
2018-11-06
|
04 | Robert Sparks | IETF WG state changed to In WG Last Call from WG Document |
2018-10-22
|
04 | Jon Peterson | New version available: draft-ietf-stir-passport-divert-04.txt |
2018-10-22
|
04 | (System) | New version approved |
2018-10-22
|
04 | (System) | Request for posting confirmation emailed to previous authors: Jon Peterson |
2018-10-22
|
04 | Jon Peterson | Uploaded new revision |
2018-07-02
|
03 | Jon Peterson | New version available: draft-ietf-stir-passport-divert-03.txt |
2018-07-02
|
03 | (System) | New version approved |
2018-07-02
|
03 | (System) | Request for posting confirmation emailed to previous authors: Jon Peterson , stir-chairs@ietf.org |
2018-07-02
|
03 | Jon Peterson | Uploaded new revision |
2018-06-27
|
02 | Russ Housley | Added to session: IETF-102: stir Wed-1520 |
2018-03-09
|
02 | Russ Housley | Added to session: IETF-101: stir Thu-0930 |
2018-03-05
|
02 | Jon Peterson | New version available: draft-ietf-stir-passport-divert-02.txt |
2018-03-05
|
02 | (System) | New version approved |
2018-03-05
|
02 | (System) | Request for posting confirmation emailed to previous authors: Jon Peterson |
2018-03-05
|
02 | Jon Peterson | Uploaded new revision |
2017-10-30
|
01 | Jon Peterson | New version available: draft-ietf-stir-passport-divert-01.txt |
2017-10-30
|
01 | (System) | New version approved |
2017-10-30
|
01 | (System) | Request for posting confirmation emailed to previous authors: Jon Peterson |
2017-10-30
|
01 | Jon Peterson | Uploaded new revision |
2017-07-16
|
00 | Robert Sparks | Added to session: IETF-99: stir Wed-1330 |
2017-07-05
|
00 | Robert Sparks | This document now replaces draft-peterson-passport-divert instead of None |
2017-07-03
|
00 | Jon Peterson | New version available: draft-ietf-stir-passport-divert-00.txt |
2017-07-03
|
00 | (System) | New version approved |
2017-07-03
|
00 | Jon Peterson | Request for posting confirmation emailed to submitter and authors: Jon Peterson |
2017-07-03
|
00 | Jon Peterson | Uploaded new revision |