IETF 71 Philadelphia - ENUM IANA Registration of Enumservices: Guide, Template and IANA Considerations draft-ietf-enum-enumservices-guide-08 B. Hoeneisen A. Mayrhofer J. Livingood IETF71, March 2008, Philadelphia, PA, USA

IETF 71 Philadelphia - ENUM Document Relation Experiences 3761bis Enumservices X-services RFC3761 clarifies ? obsoletes updates (obosoletes a section) time

IETF 71 Philadelphia - ENUM Changes since Vancouver: A lot! Completely new role Abstract version 06: This document provides a guide to and template for the creation of new IANA registrations of ENUM (E.164 Number Mapping) services. It is also to be used for updates of existing IANA registrations. Abstract version 08: This document specifies a revision of the IANA registry for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservices and its Registration Documents. 3761bis not contains the registry spec anymore

IETF 71 Philadelphia - ENUM Relation to 3761bis draft-ietf-enum-enumservices-guide-08 –Defines IANA registry (Fields, Template) –Specifies process for Enumservice registration –Enumservice design guide (Classification) draft-ietf-enum-3761bis-02 –ENUM specification (DDDS Application) –Core Syntax definition of Enumservices

IETF 71 Philadelphia - ENUM Most important changes New Registration Process –Expert Review + Specification Required All Registration specs moved over from 3761bis –IANA registry specification –IANA registration template Refined definitions in the cookbook –Classification Guidance improved

IETF 71 Philadelphia - ENUM New Registration Process As agreed in Vancouver Old: Standards Track / BCP RFC required New: Expert Review + Specification required –Based on rfc2434bis process, plus flowchart for feedback collection –The steeper path still valid, of course

IETF 71 Philadelphia - ENUM Registry Definition Template Fields: –Enumservice Name –Enumservice Class –Enumservice Type –Enumservice Subtype –URI Scheme(s) –Functional Specification –Security Considerations –Intended Usage –Registration Document –Author(s) –Further Information

IETF 71 Philadelphia - ENUM Classification recap Different recommendations for type/subtype depending on classification Protocol Enumservice Class Application Enumservice Class –Common (eg. ) –Subset (eg. voice) –Ancilliary (further processing eg. pstn) Data/Format Enumservice Class –Eg. (vcard) Intended Class is part of the Registration Template

IETF 71 Philadelphia - ENUM Cookbook: URI scheme / Subtype relation Old (-07): –Base URI scheme and secure variant can share (empty) subtype New (-08): –Where there are a number of different URI Schemes associated with this protocol, the Registration MAY use the empty Subtype for all URI schemes that it specifies as mandatory to implement. For each URI scheme that is not mandatory to implement a distinct Subtype string MUST be used.

IETF 71 Philadelphia - ENUM Issue: Intended Usage One of COMMON, LIMITED USE, OBSOLETE –All current Enumservices are COMMON –Semantics are undefined Remove it from Registration? Requirements for similar fields? –Registration status: Active / Deprecated –Other (LIMITED USE useful?)

IETF 71 Philadelphia - ENUM Issue: Enumservice name Is not used in the protocol itself –But is required in registration template –Shows up in IANA registry Potentially displayed in User Interfaces? –Bumpersticker Potential Issues –Spaces / Punctuation? –or even … Character Set and Encoding? Options: –Leave it underspecified –Specify one or all of Syntax, Semantics, Charset/Encoding –Remove from Registration Template

IETF 71 Philadelphia - ENUM Issue: Publishing of Registration Documents Specification Required could be a spec written on toilet paper (theoretically) –Or an unstable document –Or from a different SDO Spec collected by IANA, but not published? –How do Implementors acquire the spec? Is this a general problem of the Specification Required process?

IETF 71 Philadelphia - ENUM Issue: Revisions of existing Enumservices Have been registered using Standards Track / BCP documents Can they be updated/obsoleted by Expert Review process? Or are we stuck with Standards Track / BCP for these services? Other Ideas?

IETF 71 Philadelphia - ENUM Questions / Discussion Bernie Hoeneisen Alex Mayrhofer Jason Livingood Issue Tracker:

IETF 71 Philadelphia - ENUM Mainstream, X-, P- Type Names X- is excluded from this registration mechanism –Current wording in enumguide-08: reserved –Current wording in rfc3761bis: unregistered, experimental P- Private –Idea: Seperate Enumservices that are used in proprietory (private?) Environments from Experimental ones. –SHOULD ignore if encountered on the internet –Registry for clash prevention? Concerns, Ideas, Discussions whether that makes sense

IETF 71 Philadelphia - ENUM Document Roadmap rfc3761bis and enumservices-guide strongly related –Cross-references –Together, they obsolete RFC3761 as a whole Options: –Publish them together? –Enumguide first? –3761bis first?