GNSO-TPR PDP: Proposal from Registry Operator to adjust the TAC TTL (Recommendation 13..1)
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
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@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@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.
Dear Steinar and all, I also support @Rick proposal. Also, support for a minimal period of 5 (or fewer) days through the transfer can be done in fewer days. Based on relevant experience, I found that the minimum days might be required due to validating the authentication and authorization process as well as the synchronization of data objects within the Registry Operator or other concerned stakeholders. This is also true there is a business case for higher TTL for the TAC but from a security perspective especially for end users, we should support setting a shorter TTL for the TAC. Regards / Jahangir Hossain On Tue, Feb 7, 2023 at 5:13 PM Chokri Ben Romdhane via CPWG <cpwg@icann.org> wrote:
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@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@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.
_______________________________________________ CPWG mailing list CPWG@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.
Dear Jahangir and Chokri, The TAC TTL is the time the TAC is valid after being requested by the Registered Name Holder. The transfer can be executed as soon as the Registered Name Holder has a valid TAC. The recommendation is to set the Time To Live for the TAC to maximum 14 calendar days, minimum 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). Rick’s proposal is to give an opening for a Registry Operator to set a maximum TTL for the TAC less than 14 calendar days, but higher or equal 5 calendar days. Regards, Steinar Grøtterød From: Jahangir Hossain <jrjahangir@gmail.com> Date: Tuesday, 7 February 2023 at 12:39 To: Steinar Grøtterød <steinar@recito.no>, Chokri Ben Romdhane <chokribr@gmail.com> Cc: CPWG <cpwg@icann.org> Subject: Re: [CPWG] GNSO-TPR PDP: Proposal from Registry Operator to adjust the TAC TTL (Recommendation 13..1) Dear Steinar and all, I also support @Rick proposal. Also, support for a minimal period of 5 (or fewer) days through the transfer can be done in fewer days. Based on relevant experience, I found that the minimum days might be required due to validating the authentication and authorization process as well as the synchronization of data objects within the Registry Operator or other concerned stakeholders. This is also true there is a business case for higher TTL for the TAC but from a security perspective especially for end users, we should support setting a shorter TTL for the TAC. Regards / Jahangir Hossain On Tue, Feb 7, 2023 at 5:13 PM Chokri Ben Romdhane via CPWG <cpwg@icann.org<mailto:cpwg@icann.org>> wrote: 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@icann.org<mailto:cpwg@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@icann.org<mailto:CPWG@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. _______________________________________________ CPWG mailing list CPWG@icann.org<mailto:CPWG@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.
Dear Steinar, As @Jahangir has mentioned , having a TTL with 5 days really constitutes a security risk, so reducing this period will reduce these risks, it's also in the benefit of the end of users since transfer period will be reduced. Friendly regards. Chokri Le mar. 7 févr. 2023 à 13:09, Steinar Grøtterød <steinar@recito.no> a écrit :
Dear Jahangir and Chokri,
The TAC TTL is the time the TAC is valid after being requested by the Registered Name Holder. The transfer can be executed as soon as the Registered Name Holder has a valid TAC.
The recommendation is to set the Time To Live for the TAC to maximum 14 calendar days, minimum 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).
Rick’s proposal is to give an opening for a Registry Operator to set a maximum TTL for the TAC less than 14 calendar days, but higher or equal 5 calendar days.
Regards,
Steinar Grøtterød
*From: *Jahangir Hossain <jrjahangir@gmail.com> *Date: *Tuesday, 7 February 2023 at 12:39 *To: *Steinar Grøtterød <steinar@recito.no>, Chokri Ben Romdhane < chokribr@gmail.com> *Cc: *CPWG <cpwg@icann.org> *Subject: *Re: [CPWG] GNSO-TPR PDP: Proposal from Registry Operator to adjust the TAC TTL (Recommendation 13..1)
Dear Steinar and all,
I also support @Rick proposal. Also, support for a minimal period of 5 (or fewer) days through the transfer can be done in fewer days. Based on relevant experience, I found that the minimum days might be required due to validating the authentication and authorization process as well as the synchronization of data objects within the Registry Operator or other concerned stakeholders.
This is also true there is a business case for higher TTL for the TAC but from a security perspective especially for end users, we should support setting a shorter TTL for the TAC.
Regards /
Jahangir Hossain
On Tue, Feb 7, 2023 at 5:13 PM Chokri Ben Romdhane via CPWG < cpwg@icann.org> wrote:
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@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@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.
_______________________________________________ CPWG mailing list CPWG@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.
Hi Chokri, technically most transfers take no longer than 2-3 days, but we may need to think in case of domains stolen or hijacked and even 5 days is actually not enough for most folks to stop an illegal transfer. They could be on vacations or just not checking their email. Though high security TLDs want faster transfer with short window TAC validity, as this policy for all TLD's, therefore a minimum considerable days (5 working) may be reasonable. Regard's Shah On Tue, Feb 7, 2023 at 6:29 PM Chokri Ben Romdhane via CPWG <cpwg@icann.org> wrote:
Dear Steinar, As @Jahangir has mentioned , having a TTL with 5 days really constitutes a security risk, so reducing this period will reduce these risks, it's also in the benefit of the end of users since transfer period will be reduced. Friendly regards. Chokri
Le mar. 7 févr. 2023 à 13:09, Steinar Grøtterød <steinar@recito.no> a écrit :
Dear Jahangir and Chokri,
The TAC TTL is the time the TAC is valid after being requested by the Registered Name Holder. The transfer can be executed as soon as the Registered Name Holder has a valid TAC.
The recommendation is to set the Time To Live for the TAC to maximum 14 calendar days, minimum 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).
Rick’s proposal is to give an opening for a Registry Operator to set a maximum TTL for the TAC less than 14 calendar days, but higher or equal 5 calendar days.
Regards,
Steinar Grøtterød
*From: *Jahangir Hossain <jrjahangir@gmail.com> *Date: *Tuesday, 7 February 2023 at 12:39 *To: *Steinar Grøtterød <steinar@recito.no>, Chokri Ben Romdhane < chokribr@gmail.com> *Cc: *CPWG <cpwg@icann.org> *Subject: *Re: [CPWG] GNSO-TPR PDP: Proposal from Registry Operator to adjust the TAC TTL (Recommendation 13..1)
Dear Steinar and all,
I also support @Rick proposal. Also, support for a minimal period of 5 (or fewer) days through the transfer can be done in fewer days. Based on relevant experience, I found that the minimum days might be required due to validating the authentication and authorization process as well as the synchronization of data objects within the Registry Operator or other concerned stakeholders.
This is also true there is a business case for higher TTL for the TAC but from a security perspective especially for end users, we should support setting a shorter TTL for the TAC.
Regards /
Jahangir Hossain
On Tue, Feb 7, 2023 at 5:13 PM Chokri Ben Romdhane via CPWG < cpwg@icann.org> wrote:
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@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@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.
_______________________________________________ CPWG mailing list CPWG@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.
_______________________________________________ CPWG mailing list CPWG@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.
Hi Shah, Thank you for your friendly response , just note that increasing TTL periode will increase the probability of domains stolen or hijacking, also the use of email to exchange domain critical informations (including the transfer confirmation) is not recommended , a secure registry platform may be the good alternative. Friendly Regards Chokri Le mar. 7 févr. 2023 à 14:25, Shah Zahidur Rahman <shah.zahidur@gmail.com> a écrit :
Hi Chokri,
technically most transfers take no longer than 2-3 days, but we may need to think in case of domains stolen or hijacked and even 5 days is actually not enough for most folks to stop an illegal transfer. They could be on vacations or just not checking their email.
Though high security TLDs want faster transfer with short window TAC validity, as this policy for all TLD's, therefore a minimum considerable days (5 working) may be reasonable.
Regard's
Shah
On Tue, Feb 7, 2023 at 6:29 PM Chokri Ben Romdhane via CPWG < cpwg@icann.org> wrote:
Dear Steinar, As @Jahangir has mentioned , having a TTL with 5 days really constitutes a security risk, so reducing this period will reduce these risks, it's also in the benefit of the end of users since transfer period will be reduced. Friendly regards. Chokri
Le mar. 7 févr. 2023 à 13:09, Steinar Grøtterød <steinar@recito.no> a écrit :
Dear Jahangir and Chokri,
The TAC TTL is the time the TAC is valid after being requested by the Registered Name Holder. The transfer can be executed as soon as the Registered Name Holder has a valid TAC.
The recommendation is to set the Time To Live for the TAC to maximum 14 calendar days, minimum 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).
Rick’s proposal is to give an opening for a Registry Operator to set a maximum TTL for the TAC less than 14 calendar days, but higher or equal 5 calendar days.
Regards,
Steinar Grøtterød
*From: *Jahangir Hossain <jrjahangir@gmail.com> *Date: *Tuesday, 7 February 2023 at 12:39 *To: *Steinar Grøtterød <steinar@recito.no>, Chokri Ben Romdhane < chokribr@gmail.com> *Cc: *CPWG <cpwg@icann.org> *Subject: *Re: [CPWG] GNSO-TPR PDP: Proposal from Registry Operator to adjust the TAC TTL (Recommendation 13..1)
Dear Steinar and all,
I also support @Rick proposal. Also, support for a minimal period of 5 (or fewer) days through the transfer can be done in fewer days. Based on relevant experience, I found that the minimum days might be required due to validating the authentication and authorization process as well as the synchronization of data objects within the Registry Operator or other concerned stakeholders.
This is also true there is a business case for higher TTL for the TAC but from a security perspective especially for end users, we should support setting a shorter TTL for the TAC.
Regards /
Jahangir Hossain
On Tue, Feb 7, 2023 at 5:13 PM Chokri Ben Romdhane via CPWG < cpwg@icann.org> wrote:
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@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@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.
_______________________________________________ CPWG mailing list CPWG@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.
_______________________________________________ CPWG mailing list CPWG@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.
participants (4)
-
Chokri Ben Romdhane -
Jahangir Hossain -
Shah Zahidur Rahman -
Steinar Grøtterød