[CPWG] GNSO-TPR PDP: Proposal from Registry Operator to adjust the TAC TTL (Recommendation 13..1)

[Chokri Ben Romdhane]

Dear Steinar,
I  totally support @Rick proposal , we don't need to wait for 14 days since
technically registry are able to achieve the transfer operation in less
time and all that they have to do  is to reinforce their security mechanism
,with the hope that this security reinforcement will not impact the
transfer cost!, moreover I wonder why we are maintaining this minimal
period of  5 days, if the transfer can be done in less days!

Friendly Regrads
Chokri

Le mar. 7 févr. 2023 à 09:49, Steinar Grøtterød via CPWG <cpwg at icann.org> a
écrit :

> Dear CPWG members,
>
>
>
> At the GNSO-TPR meeting on Jam 31, 2023, the working group discussed the
> Recommendation 13.1. This recommendation covers the Time To Live (TTL) for
> the Transfer Authorization Code (TAC).
>
>
>
> The primary intention for Rec. 13.1 is to prevent a “long live TAC” (a
> maximum of 14 calendar days).
>
>
>
> Rick Wilhelm from PIR voiced a proposal to make it possible for a Registry
> Operator to set a shorter TTL for the TAC. Rick has posted the following to
> the GNSO-TPR mailing list:
>
>
>
> However, I think that most Ry operators will stick to the standard TTL
> because the Ry is incented to have most transfers proceed easily with the
> standard 14-day TTL.  Like the gaining registrar, the registry has a
> revenue-generating transaction from a normal transfer.
>
> But certain geos or high-security TLDs that may want to require transfers
> to occur more quickly, with a shorter window for TAC validity.
>
> Using the existing text as a base… and making minimal changes:
>
> 13.1. The default standard duration of TAC validity is 14 calendar days.
> The Registry MAY have a policy that establishes a duration of TAC validity
> that is less than 14 days but must be greater than or equal to 5 calendar
> days.  The TAC MUST be valid for the duration of TAC validity from the time
> it is set at the Registry, enforced by the Registry
>
> Choosing to rewrite 13.1 to have the same effect, we would get:
>
> 13.1. The maximum and default standard duration of TAC validity is 14
> calendar days.  The Registry MAY have a policy that establishes a shorter
> duration that is no less than 5 calendar days. The duration of TAC validity
> is enforced by the Registry, beginning when the TAC is set at the registry
>
> OR we could split this 13.1 into two parts… one of which talks about the
> Ry duration and the other which talks about enforcement.  (This might be
> considered editorial.)
>
> Regardless… any of these would require agreement that the Registry
> Operator has the flexibility to set a registry-wide policy about a TAC TTL
> for that TLD.
>
> I think that this is both important for Registry flexibility and equitable
> because the Registry is responsible for enforcing the TTL (so it should
> have some ability to control it).
>
>
>
> As a GNSO-TPR working group representative for At-Large, I would like the
> CPWG view of a Registry Operator MAY define a shorter TTL for the TAC.
>
>
>
> If possible, I would recommend having a discussion on this at the upcoming
> CPWG meeting.
>
>
>
> Regards,
>
>
>
> Steinar Grøtterød
> _______________________________________________
> CPWG mailing list
> CPWG at icann.org
> https://mm.icann.org/mailman/listinfo/cpwg
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/cpwg/attachments/20230207/1eabbca7/attachment.html>