All, In the Tuesday (31 Jan) meeting, we had a discussion about Rec 13. Two topics: * Explicitly preventing a TAC having a lifetime longer than 14 days * Allowing the Registry Operator the explicit freedom to have a policy that has the standard TAC lifetime for that Registry to be less than 14 days. For context, here is a link to the Rec 13 doc https://docs.google.com/document/d/1Wq4dHcIFR5XogoutSh0klkCyhZFUlS1z7cl2ilv9... First, explicitly preventing a TAC from having a lifetime longer than 14 days. At present, the draft in Sarah has made a suggestion (at the bottom of the googledoc) to insert “no more than” in the draft of 13.1. 13.1 The TAC MUST be valid for 14 calendar days from the time it is set at the Registry, enforced by the Registry There was another suggestion made and subsequently rejected in the meeting. This was to add “must not exceed” (The TAC must not exceed…”) but that was rejected because it doesn’t require the TAC to be 14 days. This edit solves the first point above, but (based on my reading) it prevents the Registry Operator from having a policy which has a standard TAC lifetime that is less than 14 days. So… moving on to the second point: As mentioned in the call 13.1 allows the Sponsoring Registrar to unilaterally set a TAC to null before 14 days “by agreement of the Registrar of Record and the RNH” (i.e. the RNH wants to cancel the transfer). I am suggesting that the Registry Operator have the flexibility to have a policy that has its TACs be shorter than 14 days (for all TACs). There was commentary on the call objecting to this flexibility because it would be “nonstandard”. Regarding this concern, I’ve inserted a minimum into the text below. 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). Thanks Rick