[cabfpub] Ballot 218: Remove validation methods #1 and #5

[Ryan Sleevi]

I'm not sure that's a good approach - namely, "making reasonable
improvements to #1" is, I think, a question of whether there are _other_
cases beyond the one identified (in which WHOIS is not available).

Thus, I think framing it as 'reasonable improvements' may be implying there
are other valid cases for #1, which I don't think has been provided. If we
framed it as "If we remove #1, are there any other valid cases beyond the
no-WHOIS TLDs that may be impacted"?

For concrete examples, I don't think the .no case is a good one :)

On Mon, Jan 8, 2018 at 11:29 AM, Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

>
>
> I think you and Ryan are on the right track.
>
>
>
> I’ve expressed before an interest in explicitly allowing RDAP in addition
> to WHOIS (I don’t support the idea of making the requirement more generic
> because security analysis is much more difficult for generic requirements).
>
>
>
> It wouldn’t be a bad thing if at the same time we added explicit
> requirements around the acceptable ways to directly contact a domain
> registrar.  Like Rich, I want to see the details so I can determine whether
> the requirements make sense.
>
>
>
> I was asked on Thursday to split 218 into two ballots, since it seems #1
> will take a little more work than #5.  #5 seems uncontroversial, but I keep
> getting requests for a longer timeline (possibly phased, with strong
> requirements to eliminate the egregious problems early) for #1.
>
>
>
> Should we have two ballots so we can eliminate #5 early, while making
> reasonable improvements to #1?
>
>
>
> BTW, for those who have asked, the ballot 217 “you have the time you need”
> discussion requirements was the reason I wasn’t overly concerned about when
> I posted the ballot.
>
>
>
> -Tim
>
>
>
> I wonder, then, if it would resolve your concerns about the removal of
> 3.2.2.4.1 to update the Domain Contact method - the issues I highlighted on
> variability notwithstanding. That is, it sounds like we're in agreement
> that 3.2.2.4.1, as worded, is entirely ambiguous as to the level of
> assurance provided. The methods of contacting in 3.2.2.4.2/.3 are
> acceptable, the only question is how we determine the information. We allow
> WHOIS, for example, but as worded, it would preclude RDAP or other forms,
> and would preclude the cases (such as .gov) in which direct registry
> contact is required.
>
>
>
> Domain Contact: The Domain Name Registrant, technical contact, or
> administrative contract (or the equivalent under a ccTLD) as provided by
> the Domain Registrar or, for TLDs in which the Registry provides
> information, the Registry. Acceptable methods of determination include the
> WHOIS record of the Base Domain Name, within a DNS SOA record [Note: This
> includes the hierarchal tree walking, by virtue of 3.2.2.4's recursion], or
> through direct contact with the applicable Domain Name Registrar or Domain
> Name Registry.
>
>
>
> This can then be separately expanded to RDAP, or be moved more formally in
> to a section within 3.2 as to acceptable methods for the determination of
> the Domain Contact (e.g. moving the normative requirements for validation
> outside of the definition).
>
>
>
> That seems like it would resolve the issues, right?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180108/608eb61f/attachment-0003.html>