Resumo

  • O candidato deve informar quais RSPs prestariam serviços críticos de registro se a candidatura avançasse para delegação.
  • Durante a contratação, a ICANN solicita separadamente ao RSP indicado que reconheça os planos de apoiar o candidato e o gTLD ou os gTLDs pertinentes.
  • Depois do envio, o candidato pode indicar ou trocar RSPs pelo processo de alteração da candidatura (Application Change Request).

Este artigo usa dois registros para explicar os dois eventos respaldados pelo Applicant Guidebook. O primeiro mostra o provedor que o candidato pretende usar. Para o segundo, durante a fase de contratação, a ICANN solicita ao RSP que confirme seus planos de apoiar o candidato e os gTLDs correspondentes. O modelo de dois registros é uma análise da BTW, não um requisito da ICANN.

O nome registrado pelo candidato documenta sua intenção, mas não documenta sozinho a confirmação posterior do RSP. Além disso, a seleção pode mudar depois do envio. Por isso, data, escopo e motivo de cada mudança devem ser preservados, sem tratar a primeira indicação como prova contratual definitiva.

Isso não comprova aceitação ou recusa do provedor, celebração do contrato, resultado da avaliação ou delegação. Demonstra apenas que a indicação do candidato e a confirmação solicitada ao RSP respondem a perguntas diferentes.

Análise

O controle mais claro mantém uma cadeia de dois documentos. O registro da candidatura mostra RSPs e serviços pretendidos; o registro de contratação acompanha a confirmação solicitada ao provedor sobre seus planos de suporte. Se houver troca, essa separação identifica a escolha substituída e o provedor ao qual a ICANN solicitaria depois uma confirmação. Essa cadeia é uma recomendação de governança da BTW, não uma obrigação documental imposta pela ICANN.

Sources