[NCAP-Discuss] Workflow methods

[Rubens Kuhl]

> Em 30 de nov. de 2023, à(s) 13:59, Matt Larson <matt.larson at icann.org> escreveu:
> 
> 
> 
>> On Nov 29, 2023, at 1:54 PM, Casey Deccio <casey at deccio.net> wrote:
>> 
>> This is why I was suggesting a few calls ago that if the user experience is the same for (2) and (3), why don't we just skip to (3), so we also get better data?
> 
> (i.e., skipping controlled interruption and going directly to reject all)
> 
> The user experience between (2) and (3) might be the same (or essentially the same), but to channel Jeff Schmidt, there is notification value in the returned value of 127.0.53.53 for those administrators who investigate a failure, see that IP address, and do a Google search.
> 
> The other thing that controlled interruption has going for it was that we’ve already used the technique many times and it didn’t break the Internet.

FWIW, the sequences I imagined with (1) to (4) were like this:

(1) - For all TLDs

Depending on the results of (1), end here, go with (2) and end there, or go with (3).

(3) For TLDs that justified that based on the results of (1)

Depending on the results of (3), go with (4) or end here. And ending could either mean “ok for delegation” or “not ok for delegation”.

(4) For TLDs that justified that based on the results of (3)

Depending on the results of (4): ending with root zone removal in case of “too risky” or not having root zone removal in case of “ok for delegation”.

I don’t see any value of doing (2) before doing (3) or (4)…


Rubens


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20231130/4d4c2b10/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20231130/4d4c2b10/signature.asc>