IETF conflict review for draft-dold-payto
conflict-review-dold-payto-00
Yes
No Objection
Murray Kucherawy
Warren Kumari
(Alvaro Retana)
(Deborah Brungard)
(Magnus Westerlund)
(Martin Vigoureux)
(Robert Wilton)
Note: This ballot was opened for revision 00 and is now closed.
Ballot question: "Is this the correct conflict review response?"
Erik Kline
No Objection
Comment
(2020-04-23)
Not sent
[ 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"
Murray Kucherawy
No Objection
Roman Danyliw
No Objection
Comment
(2020-04-22)
Sent
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.
Warren Kumari
No Objection
Éric Vyncke
No Objection
Comment
(2020-04-23)
Sent
I second Barry's remark about the described use of IANA registry. -éric
Barry Leiba Former IESG member
Yes
Yes
(2020-04-04)
Sent
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.
Alissa Cooper Former IESG member
No Objection
No Objection
(2020-04-23)
Sent
I agree with Barry.
Alvaro Retana Former IESG member
No Objection
No Objection
()
Not sent
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2020-04-24)
Sent for earlier
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.
Deborah Brungard Former IESG member
No Objection
No Objection
()
Not sent
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Not sent
Martin Vigoureux Former IESG member
No Objection
No Objection
()
Not sent
Robert Wilton Former IESG member
No Objection
No Objection
()
Not sent