Werner, I agree that having the three variables is helpful and we can ensure alignment with RFC 8748. We certainly need to cover both credit and balance (funds). I prefer adding a definitions section, since there can be multiple examples and as an implementer, I like to see clean examples that I directly produce in the client or the server. Without changing the terms for now, in thinking about the equation with 3 variables, I believe RFC 8748 is best reflected as Available Credit (AC) = Credit Limit (CL) + Balance (B), where currently in draft-gould-regext-balance-00 a debit increases the Balance (B) but in RFC 8748 a debit decreases the Balance (B). RFC 8748 defines the Balance like a debit card and draft-gould-regext-balance defines the Balance like a credit card. Let me get an example to help, where “Old” reflects the draft-gould-regext-balance-00 equation (credit card) and “New” reflects the equation (debit card) modified to match RFC 8748 with 3 variables.
Registrar pre-pays $10,000, so the equation is: Old: AC (10,000) = CL (0) – B(-10,000) New: AC (10,000) = CL (0) + B(10,000) Now the registrar gets a $1,000 line of credit, so the equation becomes: Old: AC (11,000) = CL (1,000) – B(-10,000) New: AC (11,000) = CL (1,000) + B(10,000) Now the registrar has $11,000 of debits, so the equation becomes: Old: AC (0) = CL (1,000) – B(1,000) New: AC (0) = CL (1,000) + B(-1,000) The Credit Threshold term would be dependent on the term used for Available Credit (AC). Thanks, -- JG [cid87442*[email protected]] James Gould Fellow Engineer [email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: "Werner Staub (axone)" <[email protected]> Date: Saturday, December 6, 2025 at 12:06 PM To: James Gould <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: [regext] Re: Call for adoption: draft-gould-regext-balance-00 (Ends 2025-12-15) Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi James, Having all the three variables defined and stated is helpful in that people can cross-check to be sure they understand correctly. The relationship to RFC 8748 is helpful, but as you point out, its definition of the balance is literally the opposite (as in "the negative of") the one we are considering for the present regext-balance draft. Definitions in the abstract are hard to write. I can volunteer the following clarifications based on the example of the response to the info command on page 5: <balance:infData xmlns:balance="urn:ietf:params:xml:ns:epp:balance-0.1"> <balance:currency>USD</balance:currency> <!-- The account is kept in USD and the balance shown in this message is expressed in USD. --> <balance:creditLimit>1000.00</balance:creditLimit> <!-- The system will block certain transactions that would bring the balance to an amount exceeding USD 1000 in favor of the party operating the server. * A creditLimit shown with a negative sign would require the balance to remain in favor of the party operating the server. --> <balance:balance>800.00</balance:balance> <!-- The balance is USD 800.00 in favor of the party operating the server. * A balance shown with a negative sign would be in favor of the party operating the client. --> <balance:availableCredit>200.00</balance:availableCredit> <!-- Unless a deposit is made, the system would block certain subsequent transactions as soon as another USD 200 are consumed. * An availableCredit with a negative sign would mean that the balance has moved further in favor of the party operating the server than that party has agreed to permit. --> <balance:creditThreshold>500.00</balance:creditThreshold> <!-- When the balance is 500 or more in favor of the party operating the server, notification messages are sent to the client at regular intervals. --> </balance:infData> Writing clarifying comments into an example could be an easier-to-read (and easier-to-write) alternative to a definitions section. That being said, the word "credit" has many meanings by nature and is used in widely different meanings in both RFC 8748 and in the present draft. Instead of "Available Credit", I would propose the expression "Available Funds", especially as RFC 8748 used "credit available" as the definition of "credit limit". Instead of "Credit Treshold", I would propose the expression "Notification Threshold". Best regards, Werner On 2025-12-05 13:38, Gould, James wrote: Werner, Thank you for your support and I agree that there is the need for definitions and inclusion of the equation, which is Available Credit (AC) = Credit Limit (CL) – Balance (B). Gavin’s response is helpful with aligning the definitions with those defined in the Registry Fee extension of RFC 8748. The Registry Fee Balance is the negative of the Balance in the Balance Mapping with the equation Available Credit (AC) = Balance (B) – Credit Limit (CL), where the question is whether there is a desire to include all three variables. When the AC is zero or negative a server MAY reject certain transactions. Do you prefer having access to all three variables or the two that is included in the Registry Fee extension? I don’t believe there is any intention with implementing currency conversion, so the currency returned is the currency that the account is kept. I would like to learn more if currency conversion is a desired feature for the clients. Thanks, -- JG [cid87442*[email protected]]curren James Gould Fellow Engineer [email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://secure-web.cisco.com/17vyF89KtmPm3xkCNSU4jt4A1mJwK1FCEI35ecp7P0fM__w11dMMkfw1KEi6cu8qml_tbe28fx9R2412tar0L5k2-3GQYBFx0J5M12a1Sb542oVgtp29KoeQgDmSHfoz9dVYNRifhMg-l6zHVVvKbOAYAHX6KecDwA2_04kqoea9YStoK0epnOZZYC9Tcc0Pm_gtoCvLO30gECBjZdee47UvEUoS3aTgdpi1NlKH2eK_HCCC4Dwes423NRWTZmjpq_0QjnaSjJbZtfEGbD66MqHO4RdTcPQWvUn6vKsUcmfA/http%3A%2F%2Fverisigninc.com%2F> From: "Werner Staub (axone)" <[email protected]><mailto:[email protected]> Date: Thursday, December 4, 2025 at 3:24 PM To: "[email protected]"<mailto:[email protected]> <[email protected]><mailto:[email protected]> Cc: "[email protected]"<mailto:[email protected]> <[email protected]><mailto:[email protected]> Subject: [EXTERNAL] [regext] Re: Call for adoption: draft-gould-regext-balance-00 (Ends 2025-12-15) Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I think the draft has great merit but I would argue that a definitions sections with the underlying financial definitions should be added to the document before adopting it. Expressions like "credit", "credit limit", "balance", "available credit", "credit threshold" are not defined in the document and they are by no means clear just by virtue of definitions one could find in a dictionary. When a balance is mentioned, it should always be made clear in whose favor it is. Is a positive balance one in favor of the server? What do each of these figures mean when they have a negative sign? Can the credit limit be negative so that the client would be require to maintain a credit balance with the server? (Note that I just used the word "credit" in a totally different sense.) The equation linking "credit limit", "balance" and "available credit" should also be mentioned. Even the tag "currency" requires clarification. The draft should make clear that it is necessarily the currency in which the account is kept. If that is not made clear, some implementations may use it designate the currency in which a converted balance happens to be expressed per client configuration. Of course "conversionBalance" and "conversionCurrency" tags would be better for the latter. Best regards, Werner On 2025-12-04 16:35, Jody Kolker wrote: I support adoption also. Thanks, Jody Kolker 319-329-9805 (mobile) Please contact my direct supervisor Scott Courtney ([email protected]<mailto:[email protected]>) with any feedback. This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. ________________________________ From: Eric Skoglund <[email protected]><mailto:[email protected]> Sent: Thursday, December 4, 2025 3:09 AM To: [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; Jorge Cano <[email protected]><mailto:[email protected]> Subject: [regext] Re: Call for adoption: draft-gould-regext-balance-00 (Ends 2025-12-15) I support adoption. // Eric Skoglund From: Jorge Cano via Datatracker <noreply@ ietf. org><mailto:noreply@ ietf. org> Sent: 01 December 2025 18: 15 To: draft-gould-regext-balance@ ietf. org <draft-gould-regext-balance@ ietf. org><mailto:draft-gould-regext-balance@ ietf. org>; regext-chairs@ ietf. org <regext-chairs@ ietf. org><mailto:regext-chairs@ ietf. org>; ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd I support adoption. // Eric Skoglund ________________________________ From: Jorge Cano via Datatracker <[email protected]><mailto:[email protected]> Sent: 01 December 2025 18:15 To: [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]> Subject: [regext] Call for adoption: draft-gould-regext-balance-00 (Ends 2025-12-15) Subject: Call for adoption: draft-gould-regext-balance-00 (Ends 2025-12-15) This message starts a 2-week Call for Adoption for this document. Abstract: This document describes an Extensible Provisioning Protocol (EPP) mapping for retrieving the client balance and other financial information. File can be retrieved from: https://datatracker.ietf.org/doc/draft-gould-regext-balance/<https://secure-web.cisco.com/16e_pHDoinM1uLUp4G2RyOZpKR_g1PhVUIPkOdYwU7I3Z4WZ4RDEmfoWj6Y4bBwF2t2hcIzkGz0oPfIdP8O3X_QnHPIQLMhuq9hTEHdeIzfHz0glUihbRFm188D2D6a9yamxl_LvBZ94BWWyoP5Yuw0Y28V7vxuQf0TiA5ajJIcooV9L4aKhQqBn80RdMIp16M3yWQGEpZ3yDpFeKtSXx6HHRKXKVHh-I-PtOkOU8VZ55YK46ez4QbJWP3fc_RYf-x6d1hgHzoSotaQWYrblM6J8bIAfxqv8RYkFpMs1I6SzRqZEg-EAFFLTO0mx4mN7i/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-gould-regext-balance%2F__%3B%21%21Hj18uoVe_Lnx%21uxuzeerzd1LT7rYoQYPvzScvaylRwEQ2OKrB7aRHL4ufx21umhG6_js3UULadhIoGT9jBovnvf9Ag7tR8WS7dc3r5ZObPHng%24> Please reply to this message keeping [email protected]<mailto:[email protected]> in copy by indicating whether you support or not the adoption of this draft as a WG document. Comments to motivate your preference are highly appreciated. Authors, and WG participants in general, are reminded of the Intellectual Property Rights (IPR) disclosure obligations described in BCP 79 [2]. Appropriate IPR disclosures required for full conformance with the provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. Sanctions available for application to violators of IETF IPR Policy can be found at [3]. Thank you. [1] https://datatracker.ietf.org/doc/bcp78/<https://secure-web.cisco.com/1zLoM9qw90j7V4HlxmsrHkkgf3ao_UqLcVKHYUG2E7Dq4BSP4msor1-SstyQL3j582E_LrZsiJazQ_O5b6A4CS6dgpN5f41AyPS7bMbELEF5O4u4jD1bNF1YLoPI-al5LsngW4_vG2zTH3CfRRPaiXIYOFxksVwqqdgEo5LS31AuLnLf_D1kATJPVF5PxArHyIMuYo74Yj6Od4PhhI644P6kuHRsLqOmf86YkMskzhCen04MEFY0SaqGJOEkGfJsTCta9WUBCv58NhVFcaPIj-0HEz-g5dBtyR4SF0h_e4tvc_A6UuuAC23SpgxNIEbiB/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fbcp78%2F__%3B%21%21Hj18uoVe_Lnx%21uxuzeerzd1LT7rYoQYPvzScvaylRwEQ2OKrB7aRHL4ufx21umhG6_js3UULadhIoGT9jBovnvf9Ag7tR8WS7dc3r5Xd7Z_tL%24> [2] https://datatracker.ietf.org/doc/bcp79/<https://secure-web.cisco.com/1uJERsHYNkyNMf-YbgjXzIsKu_gh8VKkB72Thjqz-JTsIBcDP9rh6dmEwV3IuzE2YF0hZzmYhUo0-ERbX9Uczrh_u1T5A7kAiZwzn3wSNYbnvtFvnPUkWYs20ABhzC3ZxCtvzrJxv8Sb1xv-4FoKoUIW8TzOXe00xH2gt-fY-3Yj3oRY6OUXMOma346wdgQKT5bi1A3MF82JzOKZkMGVSFVWRYp7f0edOrmYBPVePjTJ0piPzUTpg_sBZK1EKlGoGGBabBAEMsX6sHwZjRolGnrsDSZ9VYe9fHzMFuRCvBdTCAcsvzkAl90O35TkDWsCm/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fbcp79%2F__%3B%21%21Hj18uoVe_Lnx%21uxuzeerzd1LT7rYoQYPvzScvaylRwEQ2OKrB7aRHL4ufx21umhG6_js3UULadhIoGT9jBovnvf9Ag7tR8WS7dc3r5epWYYiK%24> [3] https://datatracker.ietf.org/doc/rfc6701/<https://secure-web.cisco.com/1EgflcRfdRH24YSQ0q5OmeWaYyJ4iBINHSlnDi2GK-hqHU1coNfhypPzumZzbnGy0wzsn6ZQM5hbjPILl6P5_zbS-BRKpcrHypGC7lgpfumvXssRUeBDRv6UJx-cSI9GeM9Zdk77l8owZebftl88nUSt-fFQYfHDnS9pU41lZaI8p85QRWHwKImdSG9YIySHsdmLx-4VvtFv9AcB8B7prJX9QjqrvZUZqtx7eBuCTzO8uN7fof7XS8niM_wUoMo95Y158rs1ceHRPCA8DwMNy_5W9zI2kUmcjVo0Hvcyy16Lf2Shbc_Q2RXh1IhWb4ZUa/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc6701%2F__%3B%21%21Hj18uoVe_Lnx%21uxuzeerzd1LT7rYoQYPvzScvaylRwEQ2OKrB7aRHL4ufx21umhG6_js3UULadhIoGT9jBovnvf9Ag7tR8WS7dc3r5cOwlBZX%24> _______________________________________________ regext mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ regext mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> -- Werner Staub Axone Services & Développement SA 2 cours de Rive 1204 Geneva Switzerland T: +41 22 312 5656 F: +41 22 312 5601 M: +41 79 203 4075 -- Werner Staub Axone Services & Développement SA 2 cours de Rive 1204 Geneva Switzerland T: +41 22 312 5656 F: +41 22 312 5601 M: +41 79 203 4075
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
