• Nenhum resultado encontrado

Workshop: Interface EPP do Registro.br

N/A
N/A
Protected

Academic year: 2021

Share "Workshop: Interface EPP do Registro.br"

Copied!
20
0
0

Texto

(1)

Workshop:

Interface EPP do Registro.br

Milena Constantino Caires

<milena@registro.br>

Eduardo Sztokbant

<eduardo@registro.br>

(2)

Agenda

● Modelo Atual x Modelo Proposto ● Protocolo EPP/Extensões

● Cobrança

(3)

Modelo Atual

● Interface de registro orientada para humanos

(Web-based)

● Estrutura hierárquica

● Relação entidade -> domínios

● 4 contatos (entidade, adm, tec, cob)

● Novos registros só podem ser efetuados pelo

contato da entidade para entidades já existentes ou pelo primeiro solicitante

(4)

Modelo Atual (2)

● O contato da entidade pode ser alterado por ele

próprio ou via procedimento administrativo

● Cobrança é efetuada por domínio

● Cancelamentos e transferências de titularidade

(5)

Motivação

● Proporcionar a automatização do

provisionamento de serviços que usam domínios como insumo básico

● Modelo misto entre o registry monolítico e o

registry-registrar tradicional (melhor dos dois mundos)

● Racionalizar e melhorar a escalabilidade do

modelo de cobrança

(6)

Modelo Proposto

● Manutenção da interface Web no mesmo modelo

de relacionamento atual

● Alteração da entidade com a inclusão de uma

nova propriedade (opcional) que é o Provedor de serviços

● A opção do Provedor será exercida

exclusivamente pelo contato da entidade via interface Web

(7)

Modelo Proposto (2)

● Entidades com Provedor de serviços designado só

poderão cadastrar novos domínios ou administrar os atuais via o Provedor

● Provedores poderão cadastrar novas entidades e

(8)

Modelo Proposto (3)

● Todo processo de cobrança para domínios destas

entidades será efetuado diretamente pelo Provedor

● Transferência de Provedor é efetuada pelo

contato da entidade somente via interface Web, sem a necessidade de intervenção do mesmo

● Cancelamento e transferência de titularidade

continuam a ser efetuados junto ao Registro.br (OOB)

(9)

Modelo Proposto x RR GTLDs

● Forte relação entre Registry x Registrant

● Operações de cancelamento e transferência de

titularidade continuam a ser efetuadas junto ao Registry

● Transferência de Provedores operada pelo

Registrant e diretamente no Registry

● Registry com dados completos

● Provedor usa registry como insumo para produto

(10)

Registry -> Registrant

● Avisos de problema DNS

● Avisos de limite para congelamento ● Operações OOB

● Cancelamento ● Transferência

(11)

Registry x Provedores

● Relação baseada em contrato para que seja

exigido o repasse das cláusulas principais do atual contrato de adesão

● Responsabilidade pela escolha do nome ● Declaração de dados

● Limite de responsabilidade do registry ● Condições de privacidade dos dados

(12)

Registry x Provedores (2)

● Interface para administração para operações

OOB

● Recovery da conta no servidor EPP ● Relatório de entidades

● Relatório de domínios prestes a expirar ● Relatório de operações pendentes

● Histórico de operações

(13)

Protocolo EPP

● Extensible Provisioning Protocol

● Protocolo na camada de aplicação em XML ● TLS para o transporte

● IETF Standards track protocol

● RFC 3730-3735

● Proposed standard 03/2004

(14)

Protocolo EPP (2)

● Framework com operações genéricas e a

definição de mapeamentos para objetos padrão

● Objetos - Domínio, Host, Contato ● Operações

● Consulta - check, info, poll, transfer*

● Alteração - create, delete*, renew, transfer*, update*

● Extensões para IDN, DNSSEC (DS) em andamento

(15)

Extensões do Protocolo

● Extensão do mapeamento de contato (rfc3733) com a

adição de ID único externo (CNPJ/CPF), Responsável, Contato e Procurador

● Extensão do mapeamento de domínio (rfc3731) para

a subordinação a entidade, suporte para ticket e o processo de liberação

(16)

Cobrança

● No cadastro de um novo domínio será feita a

cobrança da manutenção pelo próximo ano em advance

● As cobranças seguintes podem:

● Depender do comando EPP Renew ser enviado pelo

provedor OU

● Ser automática se a flag de auto-renew estiver setada

(17)

Certificação de Provedores

● Baseada exclusivamente em critérios técnicos

(não existe taxa de certificação)

● Procedimento de testes público e automático ● Provedor só precisa demonstrar que sua

implementação do cliente seja totalmente interoperável com o protocolo e as nossas extensões

(18)

DevKit

● Inicialmente somente a biblioteca cliente

desenvolvida junto com o servidor

● C++

● Licença BSD

● Release 0.8 já disponível em:

(19)

RFC

● Os seus comentários são muito importantes! ● Lista de discussão

(20)

Perguntas / Discussão

Referências

Documentos relacionados

Tratam os autos de ação civil pública promovida pelo Ministério Público Federal contra o ora recorrido, em virtude de imputação de atos de improbidade administrativa (Lei n.

A espectroscopia no infravermelho próximo (NIR - Near- Infrared spectroscopy) foi utilizada para caracterização de 44 amostras de 19 diferentes tipos de madeiras, e a

Os resultados obtidos indicam que o fator mais importante continua sendo a decisão do corpo diretivo e gerencial da empresa, mostrando que, de fato, há um processo de

Entendemos que há uma mudança de paradigma em relação ao DI clássico. O artigo 27 impõe uma obrigação de resultado, e, como já foi dito, para este dispositivo não

Este tipo de trabalho vem sendo uma tendência entre as montadoras no mercado brasileiro e mundial e, sendo assim, a CSN aplicou o seu modelo na análise de

A qualidade percebida advém, assim, da relação directa entre as expectativas que os clientes têm em relação à QS e a experiência que têm com a organização quando esta lhes

Já o nervo tibial posterior é acometido na região do canal do tarso, ou seja, na loja retromaleolar interna. Trata-se de um nervo misto e seu comprometimento, portanto,

Em virtude da carência de informações sobre o desempenho de ferramentas com geometria alisadora (wiper), o presente estudo tem como objetivo avaliar de