1 / 11

Domain Registry Version 2 (DREG2)

Domain Registry Version 2 (DREG2). Andrew Newton 8 November 2005 IETF 64 CRISP Working Group Vancouver, BC, Canada. Why Version 2. DREG was the first IRIS registry type created. Since then: AREG and EREG have gone through the standardization process CREDREG and RREG proposed

atencio
Download Presentation

Domain Registry Version 2 (DREG2)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Domain Registry Version 2 (DREG2) Andrew Newton 8 November 2005 IETF 64 CRISP Working Group Vancouver, BC, Canada

  2. Why Version 2 • DREG was the first IRIS registry type created. • Since then: • AREG and EREG have gone through the standardization process • CREDREG and RREG proposed • So we’ve learned a bit more about how we want these data models to look and feel. • Interest from new players • Data model needs to expand to meet their needs. • Changing realities of the domain name industry

  3. Timeline • Apologies for no actual draft. • I’ve been distracted with other matters recently. • But the schema and example are available: • http://svn.verisignlabs.com/main/iris/xml-files/trunk/dreg/ • None of this is rocket science. • There is probably only one controversial issue. • We should be able to complete this before the next IETF.

  4. Organizations • New <organization> result. • Contains pointers to contacts. • Has new <tradeName> element. • Pointers in <domain> will be able to point to either <organization> or <contact> results. • New ‘org-handle’ entity class. • New <findOrganizationsByContact> search. • Just like <findDomainsByContact> except that it looks for <organizations> • Structurally, this shares the ‘baseOrganizationType’ definition. • Shared with <registrationAuthority> • So this result now has optional contact entity references and address elements.

  5. Clarification on IDNs • <findDomainsByIDN> was NOT intended to return ALL variants. • That list could be very, very big. • The intent was to return the variants that are in the registration system. • Calculation of the variants can be done client-side if the client knows the registration rules upon which the registry/registrar operate. • New <listRegistrationRules> query. • New <registrationRule> result. • Specifies well known identifiers for registration rules. • Does not actually invent rule semantics. • New ‘registration-rule’ entity class. • This mechanism is actually generic and not just specific to IDNs.

  6. Partial Match • Expanded to do • <beginsWith> • <contains> • <endsWith>

  7. New Status Values and Structure • Revamped to be more meaningful to EPP based operations. Domain created by registrar. <status> <createactor="registrar"> <appliedDate>2004-01-20T12:00:00Z</appliedDate> <ticket>123-ABC</ticket> </create> <updatedisposition="prohibited" actor="registrar"> <appliedDate>2004-01-20T12:05:00Z</appliedDate> <ticket>456-ABC</ticket> </update> </status> Registrar prohibits updates five minutes later.

  8. Status Values By Result • <host>, <contact>, and <organization> have <status> too <domain> active, inactive, dispute, renew, addPeriod, renewPeriod, autoRenewPeriod, transferPeriod, redemptionPeriod, restore, reserved, create, delete, update, transfer, other <host> linked, reserved, create, delete, update, transfer, other <contact> linked, reserved, create, delete, update, transfer, other <organization> linked, reserved, create, delete, update, transfer, other

  9. Smaller Changes • Added “Registration Service Provider” • Per William Leibzon • On <domain> • <lastModificationDateTime> • <signatureLife> • For DNSSEC. • Multiple <registrant> references. • On <host> • <lastLamenessCheckDateTime>

  10. The Controversy: <IDNeMail> • Removed from <contact> • IESG pushback on this in EREG • It is a non-standard protocol address. • Any new I18N email address standard will likely have to be backwards compatible with non-I18N email addresses. • So, we can still use <email>. • Display issues should be handled by the client, just like with IDN. • The reason there is an <idn> field is due to the lossy nature of IDN transformation and variants in the registration system. • But this isn’t an email address registration system, so this issue does not apply to email addresses.

  11. Thank You You can send questions to list at <crisp@ietf.org> Or privately to me at <andy@hxr.us> Schema and examples are available at http://svn.verisignlabs.com/main/iris/xml-files/trunk/dreg/

More Related