IETF conflict review for draft-dold-payto
conflict-review-dold-payto-00
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-04-27
|
00 | Amy Vezza | The following approval message was sent From: The IESG To: rfc-ise@rfc-editor.org, Adrian Farrel , draft-dold-payto@ietf.org Cc: IETF-Announce , … The following approval message was sent From: The IESG To: rfc-ise@rfc-editor.org, Adrian Farrel , draft-dold-payto@ietf.org Cc: IETF-Announce , The IESG , iana@iana.org Subject: Results of IETF-conflict review for draft-dold-payto-12 The IESG has completed a review of draft-dold-payto-12 consistent with RFC5742. The IESG has no problem with the publication of 'The 'payto' URI scheme for payments' as an Informational RFC. The IESG has concluded that there is no conflict between this document and IETF work. The IESG would also like the Independent Submissions Editor to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: https://datatracker.ietf.org/doc/conflict-review-dold-payto/ A URL of the reviewed Internet Draft is: https://datatracker.ietf.org/doc/draft-dold-payto/ The process for such documents is described at https://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary |
2020-04-27
|
00 | Amy Vezza | IESG has approved the conflict review response |
2020-04-27
|
00 | Amy Vezza | Closed "Approve" ballot |
2020-04-27
|
00 | Amy Vezza | Conflict Review State changed to Approved No Problem - announcement sent from Approved No Problem - announcement to be sent |
2020-04-24
|
00 | Cindy Morgan | Conflict Review State changed to Approved No Problem - announcement to be sent from IESG Evaluation |
2020-04-24
|
00 | Benjamin Kaduk | [Ballot comment] Section 2 What's the intended relationship between the "opts" and the generic URI query component? It feels surprising to see it written this … [Ballot comment] Section 2 What's the intended relationship between the "opts" and the generic URI query component? It feels surprising to see it written this way, as opposed to separate ABNF for the separate components to parallel RFC 3986. Section 3 bank's banking application) to choose which account to pay with. An application SHOULD allow dereferencing a payto URI even if the payment target type of that URI is not registered in the "Payment Target Types" sub-registry. Details of the payment MUST be taken from the path and options given in the URI. The user SHOULD be This text could perhaps be more clear about whether dereferencing payto URIs with payment target type unknown to the application (vs. merely unregistered) is advisable. Since the (e.g.) path semantics are dependent on the payment target type, it seems pretty risky to try to dereference an unknown type. Section 4 INVALID (authority missing): payto:iban/12345 I don't see how this is "authority missing"; it fails to match earlier because the initial prefix is not "payto://" (it has no solidus). Section 5 In an IETF-stream document, BCP 18 would require some internationalization story for the "message" and "instructions". (As an ISE document, this is not bound by the BCP, of course.) The discussion in Section 6 would not suffice for this purpose. Section 11.2 https://www.npci.org.in/documents/UPILinkingSpecificationsVersion10draft.pdf is failing to load for me. |
2020-04-24
|
00 | Benjamin Kaduk | Ballot comment text updated for Benjamin Kaduk |
2020-04-24
|
00 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2020-04-23
|
00 | Erik Kline | [Ballot comment] [ section 5 ] * How should an application know how large an instruction field to use? What happens to the transaction … [Ballot comment] [ section 5 ] * How should an application know how large an instruction field to use? What happens to the transaction if the instruction field would be subject to lossy conversion? [ section 7.1 ] * "the routing number and the account number": is it slightly more clear to say "the routing number followed by the account number"? Same consideration in 7.3: "BIC and IBAN" -> "BIC followed by IBAN" |
2020-04-23
|
00 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2020-04-23
|
00 | Benjamin Kaduk | [Ballot comment] Section 2 What's the intended relationship between the "opts" and the generic URI query component? It feels surprising to see it written this … [Ballot comment] Section 2 What's the intended relationship between the "opts" and the generic URI query component? It feels surprising to see it written this way, as opposed to separate ABNF for the separate components to parallel RFC 3986. Section 3 bank's banking application) to choose which account to pay with. An application SHOULD allow dereferencing a payto URI even if the payment target type of that URI is not registered in the "Payment Target Types" sub-registry. Details of the payment MUST be taken from the path and options given in the URI. The user SHOULD be This text could perhaps be more clear about whether dereferencing payto URIs with payment target type unknown to the application (vs. merely unregistered) is advisable. Since the (e.g.) path semantics are dependent on the payment target type, it seems pretty risky to try to dereference an unknown type. Section 4 INVALID (authority missing): payto:iban/12345 I don't see how this is "authority missing"; it fails to match earlier because the initial prefix is not "paytoo://" (it has no solidus). Section 5 In an IETF-stream document, BCP 18 would require some internationalization story for the "message" and "instructions". (As an ISE document, this is not bound by the BCP, of course.) The discussion in Section 6 would not suffice for this purpose. Section 11.2 https://www.npci.org.in/documents/UPILinkingSpecificationsVersion10draft.pdf is failing to load for me. |
2020-04-23
|
00 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2020-04-23
|
00 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2020-04-23
|
00 | Alissa Cooper | [Ballot comment] I agree with Barry. |
2020-04-23
|
00 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-04-23
|
00 | Éric Vyncke | [Ballot comment] I second Barry's remark about the described use of IANA registry. -éric |
2020-04-23
|
00 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-04-23
|
00 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2020-04-22
|
00 | Roman Danyliw | [Ballot comment] Section 8. The text helpfully discusses how interactive applications need to handle the URL with caution. I might have added additional text that … [Ballot comment] Section 8. The text helpfully discusses how interactive applications need to handle the URL with caution. I might have added additional text that the target application processing the URI would handle the associated authentication/authorization issues required to process the transaction. Section 8. With regard to authentication/authorization issues, I would wonder about the issues of non-interactive application handling Section 8. The text also helpfully notes that “Unless a payto URI is received over a trusted, authenticated channel, user might not be able to identify the target of a payment”. I might also note that the transport security services used to process transaction encoded in the URI are handled by the application and out of scope. |
2020-04-22
|
00 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2020-04-22
|
00 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2020-04-22
|
00 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-04-21
|
00 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-04-06
|
00 | Amy Vezza | Placed on agenda for telechat - 2020-04-24 |
2020-04-04
|
00 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2020-04-04
|
00 | Barry Leiba | [Ballot comment] With respect to Section 10 in the document: Neither IANA nor participants in the IETF will have any necessary expertise to evaluate registration … [Ballot comment] With respect to Section 10 in the document: Neither IANA nor participants in the IETF will have any necessary expertise to evaluate registration requests in the sort of registry described, and no one will be well served by the creation of such a registry at IANA. It would be far better to have a registration process be described in this document involving experts from the industry as reviewers and maintenance of the registrations by an industry organization, rather than by IANA. I strongly urge the authors to set this up now and to document it in the "payto" document, rather than suggesting that IANA might be asked to create some sort of registry later. |
2020-04-04
|
00 | Barry Leiba | Ballot comment text updated for Barry Leiba |
2020-04-04
|
00 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2020-04-04
|
00 | Barry Leiba | Created "Approve" ballot |
2020-04-04
|
00 | Barry Leiba | Conflict Review State changed to IESG Evaluation from AD Review |
2020-04-04
|
00 | Barry Leiba | New version available: conflict-review-dold-payto-00.txt |
2020-03-26
|
00 | Alissa Cooper | Conflict Review State changed to AD Review from Needs Shepherd |
2020-03-26
|
00 | Alissa Cooper | Shepherding AD changed to Barry Leiba |
2020-02-03
|
00 | Alissa Cooper | Removed from agenda for telechat |
2020-01-27
|
00 | Cindy Morgan | Placed on agenda for telechat - 2020-02-06 |
2020-01-26
|
00 | Adrian Farrel | IETF conflict review requested |