Good Morning, Thanks Karl. Interesting, we had a very similar discussion as we were drafting this document. I believe we had some text describing this but we couldn’t get the language worked out so we pulled it. The intent is that whatever contacts are sent by the client they would be processed by the sever as a whole. We will look to add clarity to the document.
Agreed, there will be some scenarios that this draft will not be able to resolve completely. Thanks Roger From: Karl Heinz Wolf [mailto:khwo...@gmail.com] Sent: Thursday, August 24, 2017 3:02 AM To: Roger D Carney <rcar...@godaddy.com> Cc: regext@ietf.org Subject: Re: [regext] REGEXT Interim Meeting On Wed, Aug 23, 2017 at 10:52 PM, Roger D Carney <rcar...@godaddy.com<mailto:rcar...@godaddy.com>> wrote: We moved the discussion onto Validate and Jody provided an overview of the problem space and the proposed solution. There was a general agreement that this proposal sounds good and seems like a logical business issue to resolve. There was some discussion on the possible need to be able to refine this “validate” down to the exact domain name. The draft does allow for this though it was not in the original goals. Jim and Antoin talked about this whole “validate” concept possibly being larger and may need to examined in totality (e.g. with allocation token and verification code). Do they belong together or stay separate, should there be a “higher” framework that pulls together the idea of validation/verification? What might also be necessary to consider for validation: there are geoTLDs that do not require a certain contact type to be out of their region, but rather the policy says that either the registrant or the tech-c or the admin-c have to be out of that region. The draft allows to state multiple contact types in one check command, but currently the text does not say if these contacts are validated separately or if all these contacts are considered to be then linked to the same domain. Another situation that seems not be discussed in this meeting is community TLDs with policies that do out of band validation and accept several different proofs that you belong to that community. So it is not as simple as the VATID example in the draft. Hence, I’m not sure if the key value mechanism could easily cover such scenarios. Thanks, Karl
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
