Patrick, > There is in general possible confusion as there is overlap between the domain > name business and the digital certificate issuance business at least for two > reasons: many certificates are DV so they directly depend on domain names and > multiple domain name registries and registrars are also Certificate > Authorities.
I don't believe there is any overlap or confusion when it comes to the EPP interface between the registrar an registry. The reference to "CSR" is simply an example of a "Role"-based value for the <changePoll:who> element, which includes the expanded name Customer Support Representative for clarity. There is no normative language related to the use of the acronym "CSR", so an implementation can choose how best to represent the corresponding "Role"-based value. — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 12/11/18, 1:35 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: On Mon, Dec 10, 2018, at 11:48, Gould, James wrote: > Section 2.3 > > "CSR" could expand to either "Customer Support Representative" or > "Certificate Signing Request" for some people. I don't know if there's > better name to suggest. > > JG - I believe the reference to "CSR" as "Customer Support > Representative" is pretty standard in the domain name industry with no > confusion to a "CSR" in the digital certificate industry. I kind of disagree but it is a minor point and I believe that the context provides enough disambiguitation. There is in general possible confusion as there is overlap between the domain name business and the digital certificate issuance business at least for two reasons: many certificates are DV so they directly depend on domain names and multiple domain name registries and registrars are also Certificate Authorities. However I really do not see also what we gain by the acronym we could as well put Customer Service Representative or Support Agent or Customer Care or whatever, in full, instead of an acronym there, so that the example is complete. > Section 2.4 > > I don't know if it's worth saying anything that would remind recipients of > their (non-?)obligation to accept time values that correspond to leap > seconds, but IIRC we've seen cases in the past of software that chokes when > presented with leap-second timestamps. > > JG - This is standard boilerplate text in the EPP RFCs (RFC 5731 - > 5733) that include timestamps, and I'm not aware of any EPP software > issues associated with leap-second timestamps that warrants a reminder > in this EPP draft. I agree with James, for better or worse, no other EPP documents go into such territories as leap-second and this specification is no more "time" oriented than the others so it makes no specific sense to start here talking about leap seconds. -- Patrick Mevzek _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
