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]) 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]>
*Sent:* Thursday, December 4, 2025 3:09 AM
*To:* [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; Jorge Cano <[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> Sent: 01 December 2025 18: 15 To: draft-gould-regext-balance@ ietf. org <draft-gould-regext-balance@ ietf. org>; regext-chairs@ ietf. org <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]>
*Sent:* 01 December 2025 18:15
*To:* [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-gould-regext-balance/__;!!Hj18uoVe_Lnx!uxuzeerzd1LT7rYoQYPvzScvaylRwEQ2OKrB7aRHL4ufx21umhG6_js3UULadhIoGT9jBovnvf9Ag7tR8WS7dc3r5ZObPHng$>

Please reply to this message keeping [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://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp78/__;!!Hj18uoVe_Lnx!uxuzeerzd1LT7rYoQYPvzScvaylRwEQ2OKrB7aRHL4ufx21umhG6_js3UULadhIoGT9jBovnvf9Ag7tR8WS7dc3r5Xd7Z_tL$> [2] https://datatracker.ietf.org/doc/bcp79/ <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp79/__;!!Hj18uoVe_Lnx!uxuzeerzd1LT7rYoQYPvzScvaylRwEQ2OKrB7aRHL4ufx21umhG6_js3UULadhIoGT9jBovnvf9Ag7tR8WS7dc3r5epWYYiK$> [3] https://datatracker.ietf.org/doc/rfc6701/ <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc6701/__;!!Hj18uoVe_Lnx!uxuzeerzd1LT7rYoQYPvzScvaylRwEQ2OKrB7aRHL4ufx21umhG6_js3UULadhIoGT9jBovnvf9Ag7tR8WS7dc3r5cOwlBZX$>



_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]

_______________________________________________
regext mailing list [email protected]
To unsubscribe send an email [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
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to