Thomas, Thank you for your review. I provide a response to your questions embedded below, prefixed with "JG-".
Does the model defined in the latest balance mapping support the model used in your registry services and if not do you have any suggested changes? Thanks, -- JG 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/> On 8/17/26, 7:09 AM, "Thomas Corte (TANGO support)" <[email protected] <mailto:[email protected]>> wrote: 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. Hello, On 14.08.26 21:13, Gould, James wrote: > Hi, > > Based on collaboration with Werner Staub, the co-editor, > draft-ietf-regext-balance-02 has been posted that includes changes that will > enable the balance mapping to apply to a broader set of domain name > registries and with additional description of the attributes for clarity. > ... > Please review and provide feedback. I had a look at the draft and found no major issues. I have two questions/concerns though: 1) What's the significance of the "Cash Client" vs. "Credit Client" distinction? These terms are introduced but not used anywhere. JG-The significance between the two is that a Cash Client will typically have a Credit Line (CL) value of "0.00", which means that Balance Available (BA) will be the same as the Cash Available (CB). The exception to that rule is if the Registry provides an Emergency Credit, which will temporarily be added to the Credit Line. A Credit Client will regularly have a positive Credit Line (CL) that is added to the Cash Balance (CB) to set the Balance Available (BA). We can expand on the description of the Cash Client and the Credit Client to make this clearer. 2) Section 2.5 says "The Credit Line SHOULD NOT be a negative value with the default value being "0.00".". Given that the "Execution Limit" can be positive (allowing for requiring clients to maintain a positive available/cash balance), I don't see any use cases for a negative Credit Line, so the "SHOULD NOT" should be changed to "MUST NOT" in my opinion. Consequentially, the definition of the <creditLine> element in the schema should be augmented with a restriction like <minInclusive value="0" />. JG-Good point. I can't think of a use case where the Credit Line would be negative, since the Credit Line is based on the set of credit instructions that should always be additive. I'll bring this up with Werner Stuab to see if there are any valid use cases where the Credit Line could be negative to warrant the SHOULD NOT and allowing for a negative value in the XML schema. If there is a valid use case, we'll bring it to the mailing list; otherwise, we'll make the update to the draft as recommended. Best regards, Thomas -- TANGO REGISTRY SERVICES® is a product of: Knipp Medien und Kommunikation GmbH Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: [email protected] <mailto:[email protected]> Germany _______________________________________________ regext mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
