Subject: [Enum] I-D ACTION:draft-ietf-enum-iris-ereg-01.txt

From: [email-masked]
Date: Tue, 19 Jul 2005 10:50:24 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Telephone Number Mapping Working Group of the IETF.

	Title		: An ENUM Registry Type for the Internet 
                          Registry Information Service
	Author(s)	: A. Newton
	Filename	: draft-ietf-enum-iris-ereg-01.txt
	Pages		: 52
	Date		: 2005-7-19
	
This document describes an IRIS registry schema for registered ENUM
   information.  The schema extends the necessary query and result
   operations of IRIS to provide the functional information service
   needs for syntaxes and results used by ENUM registries.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-iris-ereg-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-enum-iris-ereg-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv at ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-enum-iris-ereg-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-enum-iris-ereg-01.txt>

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Richard Shockey <[email-masked]>
Date: Tue, 19 Jul 2005 12:20:07 -0400

Andy ..what changes have you made in this version?

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Telephone Number Mapping Working Group of 
the IETF.

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Andrew Newton <[email-masked]>
Date: Tue, 19 Jul 2005 14:29:34 -0400

On Jul 19, 2005, at 12:14 PM, Richard Shockey wrote:
Andy ..what changes have you made in this version?
Most of the changes were to correct inconsistent terminology.  Things  
like changing AuthenticationAuthority to ValidationAuthority, etc..  
etc...

The biggest change is that the various types of contacts were  
normalized in the schema and are now allowed on any result that  
represents a real-world organization.

There was a request to add a search for finding ENUMs by partial E. 
164 number, but I did not include it in the draft because I did not  
understand its semantics and could not get clarification before the  
cut-off date.  I also don't consider this to be a big deal.

-andy

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 21 Jul 2005 09:07:08 -0400

> represents a real-world organization.

I've just read the document and here are some comments:

* Terminology. You use "ENUM" as a shortcut for what is usually 
  called "ENUM domain". For me, the single word "ENUM" stands for the
  overall standard (as defined in RFC3761).

  Perhaps this shortening is inevitable (just as "static IP address" is 
  often shortened to just "static IP"), but I'm uncomfortable to
  legitimize such language via official documents.

  Btw, what *is* the official explanation of the word ENUM? 
  (other than just being a word play on "electronic numbering"?)

* Domain vs. Number
  As long as there is a 1:1 mapping between domains and numbers this
  is just a question about syntax, but fuer the Austrian ENUM registry 
  we decided to use the E.164 number as the primary data object and not the
  resulting domain. 
  
  Rationale: The number is much better suited for human reading
  than ENUM domains, so we prefer to have numbers in logs, error-
  messages and protocol fields. 
  Furthermore, when expanding the registry to cover more than
  just ENUM dns (e.g. more generic number assignment, E-911, NP)
  it becomes even more natural to deal with numbers and not with
  domains.

* Domain status:

  How would you map the cases "domain marked for deletion" and
  "deleted and in grace period" to your choices?

  Does "assignedAndOnHold" mean that the delegation is active or not?

* Contact schema:

  Your contact schema seems to be rather close to the dreg contact
  from RFC 3982. What is the rationale to duplicate the definition
  vs. including the dreg schema?

  Is your contact obejct compatible to the EPP contact object?
  (I haven't checked this one.) What about reusing the schema from
  the EPP rfcs?

  [side comment: the +43 live ENUM registry uses a different contact
  schema to be compatible with the Austrian phonebook.]

* Host schema:

  Same as for contact.

* I'm not sure if I got this right: The entityName attribute of
  registrationAuthority or validationAuthority acts as the unique
  identifier of said entity in the context of that registry?

  E.g. the EPP clID [i.e. the Registrar-ID] should be put into
  that field?

* Your ValidationResult is very close to the Validation Token I
  describe in draft-lendl-enum-validation-token-00.

  It contains the same basic fields and just omits the digital
  signature and the optional owner date.

/ol
-- 
< Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer >

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 21 Jul 2005 09:49:14 -0400

On Thu, 21 Jul 2005 15:06:40 +0200

>   (other than just being a word play on "electronic numbering"?)

I've been told that it comes from the C language keyword "enum". there was a trend to call ietf-WGs to well known UNIX terms such as "cat", "malloc", "rtfm".

	jaap

---

From: Andrew Newton <[email-masked]>
Date: Fri, 22 Jul 2005 13:37:25 -0400

Otmar,
Thanks for your comments.  My response is in-line:
On Jul 21, 2005, at 9:06 AM, Otmar Lendl wrote:
* Terminology. You use "ENUM" as a shortcut for what is usually
  called "ENUM domain". For me, the single word "ENUM" stands for the
  overall standard (as defined in RFC3761).
  Perhaps this shortening is inevitable (just as "static IP  
address" is
  often shortened to just "static IP"), but I'm uncomfortable to
  legitimize such language via official documents.
This is covered in section 2.  However, I have no trouble changing  
the terminology throughout the document, especially if you think it  
provides better clarity and readability.

Good question.
  we decided to use the E.164 number as the primary data object and  
not the
  resulting domain.

  Rationale: The number is much better suited for human reading
  than ENUM domains, so we prefer to have numbers in logs, error-
  messages and protocol fields.
  Furthermore, when expanding the registry to cover more than
  just ENUM dns (e.g. more generic number assignment, E-911, NP)
  it becomes even more natural to deal with numbers and not with
  domains.
The reason for the current model is, as you stated, the 1:1 mapping  
between domain and numbers.
Splitting the two out may add extra complexity, but your rationale  
has merit.
So I guess the big question here is "Do we think this will be used  
beyond ENUM?"  If so, then I think this change is in order.

* Domain status:
  How would you map the cases "domain marked for deletion" and
  "deleted and in grace period" to your choices?
  Does "assignedAndOnHold" mean that the delegation is active or not?
Confusing, isn't it?  This uses the 3982 status values, but perhaps  
it should be refined (in both places).  The status values of  
<assigned> and <onHold> should be independent so they can be combined  
in the necessary ways.

I've known about this problem, and I don't know why I didn't fix it.
* Contact schema:
  Your contact schema seems to be rather close to the dreg contact
  from RFC 3982. What is the rationale to duplicate the definition
  vs. including the dreg schema?
  Is your contact obejct compatible to the EPP contact object?
  (I haven't checked this one.) What about reusing the schema from
  the EPP rfcs?
The rationale for making it separate is to allow this specification  
to be modified separately of DREG and EPP (not all registries that  
use EPP use IRIS and vice versa).  If you look at AREG, you'll notice  
this is true.

  [side comment: the +43 live ENUM registry uses a different contact
  schema to be compatible with the Austrian phonebook.]
If you provide the details, I can change the schema to be compatible  
if you would like.  Again, this is the reason why it is separate from  
DREG.

* Host schema:
  Same as for contact.
* I'm not sure if I got this right: The entityName attribute of
  registrationAuthority or validationAuthority acts as the unique
  identifier of said entity in the context of that registry?
  E.g. the EPP clID [i.e. the Registrar-ID] should be put into
  that field?
The entity name needs to be unique with in its entity class of the  
registry (if it is not temporary).  Otherwise, it can be what you  
want it to be.  This is so clients can properly reference the object.

* Your ValidationResult is very close to the Validation Token I
  describe in draft-lendl-enum-validation-token-00.
  It contains the same basic fields and just omits the digital
  signature and the optional owner date.
I did not include the digital signature because I was uncertain of  
its application and thought it was only relevant in authentication  
during provisioning.  But I could be convinced otherwise.

What is the owner date?  Is that the created date?
-andy
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 26 Jul 2005 11:46:22 -0400

Andrew,

> provides better clarity and readability.

I saw the explanation, but I'm not sure if the working group as a 
whole feed comfortable with that terminology.

We prefer to write "ENUM domain".
enum query /response

> between domain and numbers.  Splitting the two out may add extra
> complexity, but your rationale has merit.  So I guess the big question
> here is "Do we think this will be used beyond ENUM?"  If so, then I
> think this change is in order.

Looking at the other threads on this list shows that Carrier ENUM does
indeed have the potential to carry NP information. Once this information
is not only published via ENUM but also via SS7 IN dips it makes more
sense to use the number as the main object and not the ENUM domain.

Another question is whether this IRIS scheme could be useful for        
current E.164 related databases like                                    

* white pages
* line information databases
* the current NP database
* telco internal provisioning systems

One question to consider here as well is how this affects the dynamic
server discovery according to RFC3958.

> I've known about this problem, and I don't know why I didn't fix it.

We (the Austria ENUM registry) use independent flags. 

We have one for the DNS visibility.
One for "locked".
One for "delete pending".

> if you would like.  Again, this is the reason why it is separate from  

The main difference is that we split up the address and the name field
into its components. We separate 

commonName into firstname/lastname/title
address into streetname/streetnumber/appartment

[This is needed for E.115 compatibility.]

We have the added field "commercialregisternumber", you have "sip".
On our side, "type" is handled differently XML-wise but allows for the
same "person", "organization" and "role" classification.

As mentioned before, our main focus was compatibility with the 
Austrian phonebook and not existing Internet whois-style databases.

I'll attach our XML schema file.

The contact object in DREG is certainly inspired by what's currently
in use in gTLD and ccTLD registries. For ENUM, I recommend you also
take a closer look to what you local white pages databases use,
because those will be used for validation purposes.

After all, if some day the ENUM registry is also used as the generic
number allocation database, it will have to be compatible to a) old
carrier provisioning systems and b) the national white pages data format.
Have you checked what kind of fields they use in the US?

> during provisioning.  But I could be convinced otherwise.

You're right that the main point of the signature is during the
provisioning process. For the purposes of auditing the whole
validation scheme we consider it helpful that those signatures
can be retrieved and checked ex post.

We don't do IRIS right now. In our case the token can be
retrieved from the registry with the EPP info command.

> What is the owner date?  Is that the created date?

That should have been 'data'. Sorry. Our Token can contain a copy of a
"contact" object or some other data related to the validation 
procedure.

The idea here is that the validator checked the identity of the
owner of the number and includes those results in the token such
that the digital signature covers that information as well.
(That can be name/address in the form of a contact structure, 
but may as well be an IMSI in a GSM/3GPP context.)

We expect that some innovative solution will emerge in terms of
number assignement. e.g. other forms of chip-cards (similar to
those used in access-control applications), perhaps credit cards,
biometric information, ...

This "tokendata" XML element gives us the flexibility to add
support for such methods without changing the main XML schema of
our registry interface. Thus the registry only touches the
data within the main Token structure (containing the same
fields as your ValidationEvent) and treats the signature (after
checking) and the rest of the Token as opaque XML document.

Conceptually the contact infomation in the token is different from 
the domain owner object which the registrar sends to the registry.
The former is written by the validator and specifies the
ownership of a number whereas the later comes from the registrar
and can be used for directories like the phonebook.

For typical User ENUM and existing E.164 numbers, no registrar-defined
owner contact is needed. For ENUM-only number ranges like +43 780
the contact information in the Token acts as the definite source of
information on who owns the number. That e.g. does not need to be a full
name/address set, an email address is sufficient for us.

/ol
-- 
< Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer >
<?xml version="1.0" encoding="UTF-8"?>

  <schema targetNamespace="http://www.enum.at/rxsd/enum-contact-1.0"
          xmlns:enum-contact="http://www.enum.at/rxsd/enum-contact-1.0"
          xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
          xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
          xmlns="http://www.w3.org/2001/XMLSchema"
          elementFormDefault="qualified">

  <!--  Import common element types.  -->

    <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
            schemaLocation="eppcom-1.0.xsd"/>
    <import namespace="urn:ietf:params:xml:ns:epp-1.0"
            schemaLocation="epp-1.0.xsd"/>

    <annotation>
      <documentation>
        Extensible Provisioning Protocol v1.0
        enum.at contact provisioning schema.
      </documentation>
    </annotation>

  <!--  Child elements found in EPP commands.  -->

    <element name="create" type="enum-contact:createType"/>
    <element name="update" type="enum-contact:updateType"/>
    <element name="delete" type="enum-contact:sNameType"/>
    <element name="info"   type="enum-contact:sNameType"/> 

    <attributeGroup name="extendedAttrType">
      <attribute name="extended" type="token"/>
    </attributeGroup>

  <!--  ROID  -->

    <simpleType name="roidType">
      <restriction base="token">
        <pattern value="C\d{8}-ENUMAT"/>
      </restriction>
    </simpleType>

  <!--  Address - element-types to be added, edited etc.  -->

    <simpleType name="streetNameType">
      <restriction base="token">
        <minLength value="1"/>
        <maxLength value="128"/>
      </restriction>
    </simpleType>

    <simpleType name="shortTokenType">
      <restriction base="token">
        <minLength value="1"/>
        <maxLength value="64"/>
      </restriction>
    </simpleType>

    <complexType name="addressType">
      <sequence>
        <element name="streetname"   type="enum-contact:streetNameType"/>
        <element name="streetnumber" type="enum-contact:shortTokenType"
         minOccurs="0"/>
        <element name="apartment"    type="enum-contact:shortTokenType"
         minOccurs="0"/>
        <element name="postalcode"   type="enum-contact:shortTokenType"/>
        <element name="city"         type="enum-contact:shortTokenType"/>
        <element name="state"        type="enum-contact:shortTokenType"
         minOccurs="0"/>
        <element name="country"      type="enum-contact:shortTokenType"/>
      </sequence>
    </complexType>

  <!--  phone, fax, email + disclosure  -->

    <attributeGroup name="discloseAttrType">
      <attribute name="disclose" type="boolean" use="optional" default="1"/> 
    </attributeGroup>

    <simpleType name="phoneTokenType">
      <restriction base="token">
        <pattern value="\+?[\s\d]{5,}"/>
      </restriction>
    </simpleType>

    <complexType name="faxType">
      <simpleContent>
        <extension base="enum-contact:phoneTokenType">
          <attributeGroup ref="enum-contact:discloseAttrType"/>
        </extension>
      </simpleContent>
    </complexType>

    <complexType name="phoneType">
      <simpleContent>
        <extension base="enum-contact:phoneTokenType">
          <attributeGroup ref="enum-contact:discloseAttrType"/>
        </extension>
      </simpleContent>
    </complexType>

    <simpleType name="emailTokenType">
      <restriction base="token">
        <minLength value="4"/>
        <maxLength value="64"/>
        <pattern value=".+ at .+\..+"/>
      </restriction>
    </simpleType>

    <complexType name="emailType">
      <simpleContent>
        <extension base="enum-contact:emailTokenType">
          <attributeGroup ref="enum-contact:discloseAttrType"/>
        </extension>
      </simpleContent>
    </complexType>

  <!--  element types - to be edited, merged, removed etc.  -->

    <simpleType name="organisationType">
      <restriction base="token">
        <minLength value="1"/>
        <maxLength value="64"/>
      </restriction>
    </simpleType>

    <simpleType name="CRNType">
      <restriction base="token">
        <minLength value="1"/>
        <maxLength value="64"/>
      </restriction>
    </simpleType>

    <simpleType name="titleType">
      <restriction base="token">
        <minLength value="1"/>
        <maxLength value="64"/>
      </restriction>
    </simpleType>

    <simpleType name="firstnameType">
      <restriction base="token">
        <minLength value="1"/>
        <maxLength value="64"/>
      </restriction>
    </simpleType>

    <simpleType name="lastnameType">
      <restriction base="token">
        <minLength value="1"/>
        <maxLength value="64"/>
      </restriction>
    </simpleType>

  <!--  type organisation  -->

    <group name="organisationBaseGroup">
      <sequence>
        <element name="organisation" type="enum-contact:organisationType"/>
        <element name="commercialregisternumber" type="enum-contact:CRNType"
         minOccurs="0"/>
        <element name="address" type="enum-contact:addressType"/>
        <element name="phone"   type="enum-contact:phoneType"/>
        <element name="fax"     type="enum-contact:faxType"
         minOccurs="0"/>
        <element name="email"   type="enum-contact:emailType"/>
      </sequence>
    </group>

    <complexType name="organisationCreateType">
      <sequence>
        <group ref="enum-contact:organisationBaseGroup"/>
      </sequence>
    </complexType>

    <complexType name="organisationUpdateType">
      <sequence>
        <element name="roid" type="enum-contact:roidType"/>
        <group ref="enum-contact:organisationBaseGroup"/>
      </sequence>
    </complexType>

  <!--  type role  -->

    <group name="roleBaseGroup">
      <sequence>
        <element name="organisation" type="enum-contact:organisationType"
         minOccurs="0"/>
        <element name="commercialregisternumber" type="enum-contact:CRNType"
         minOccurs="0"/>
        <element name="title"     type="enum-contact:titleType"
         minOccurs="0"/>
        <element name="firstname" type="enum-contact:firstnameType"
         minOccurs="0"/>
        <element name="lastname"  type="enum-contact:lastnameType"/>
        <element name="address"   type="enum-contact:addressType"
         minOccurs="0"/>
        <element name="phone"     type="enum-contact:phoneType"
         minOccurs="0"/>
        <element name="fax"       type="enum-contact:faxType"
         minOccurs="0"/>
        <element name="email"     type="enum-contact:emailType"/>
      </sequence>
    </group>

    <complexType name="roleCreateType">
      <sequence>
        <group ref="enum-contact:roleBaseGroup"/>
      </sequence>
    </complexType>

    <complexType name="roleUpdateType">
      <sequence>
        <element name="roid" type="enum-contact:roidType"/>
        <group ref="enum-contact:roleBaseGroup"/>
      </sequence>
    </complexType>

  <!--  type person  -->

    <group name="personBaseGroup">
      <sequence>
        <element name="organisation" type="enum-contact:organisationType"
         minOccurs="0"/>
        <element name="commercialregisternumber" type="enum-contact:CRNType"
         minOccurs="0"/>
        <element name="title"     type="enum-contact:titleType"
         minOccurs="0"/>
        <element name="firstname" type="enum-contact:firstnameType"/>
        <element name="lastname"  type="enum-contact:lastnameType"/>
        <element name="address"   type="enum-contact:addressType"
         minOccurs="0"/>
        <element name="phone"     type="enum-contact:phoneType"
         minOccurs="0"/>
        <element name="fax"       type="enum-contact:faxType"
         minOccurs="0"/>
        <element name="email"     type="enum-contact:emailType"/>
      </sequence>
    </group>

    <complexType name="personCreateType">
      <sequence>
        <group ref="enum-contact:personBaseGroup"/>
      </sequence>
    </complexType>

    <complexType name="personUpdateType">
      <sequence>
        <element name="roid" type="enum-contact:roidType"/>
        <group ref="enum-contact:personBaseGroup"/>
      </sequence>
    </complexType>

  <!--  types for top elements  -->

    <complexType name="createType">
      <choice>
        <element name="organisation" type="enum-contact:organisationCreateType"/>
        <element name="role"         type="enum-contact:roleCreateType"/>
        <element name="person"       type="enum-contact:personCreateType"/>
      </choice>
      <attributeGroup ref="enum-contact:extendedAttrType"/>
    </complexType>

    <complexType name="updateType">
      <choice>
        <element name="organisation" type="enum-contact:organisationUpdateType"/>
        <element name="role"         type="enum-contact:roleUpdateType"/>
        <element name="person"       type="enum-contact:personUpdateType"/>
      </choice>
      <attributeGroup ref="enum-contact:extendedAttrType"/>
    </complexType>

    <complexType name="sNameType">
      <sequence>
        <element name="roid" type="enum-contact:roidType"/>
      </sequence>
      <attributeGroup ref="enum-contact:extendedAttrType"/>
    </complexType>

  <!--  Child response elements.  -->

    <element name="creData" type="enum-contact:creDataType"/>
    <element name="infData" type="enum-contact:infDataType"/>

  <!--  <create> response elements.  -->

    <complexType name="creDataType">
      <sequence>
        <element name="roid" type="enum-contact:roidType"/>
        <element name="crDate" type="dateTime"/>
      </sequence>
    </complexType>

  <!--  <info> response elements.  -->

    <complexType name="infDataType">
      <sequence>
        <choice>
          <element name="organisation" type="enum-contact:organisationUpdateType"/>
          <element name="role"         type="enum-contact:roleUpdateType"/>
          <element name="person"       type="enum-contact:personUpdateType"/>
        </choice>
        <element name="status" type="enum-contact:statusType"
         maxOccurs="6"/>
        <element name="clID"   type="eppcom:clIDType"/>
        <element name="crID"   type="eppcom:clIDType"/>
        <element name="crDate" type="dateTime"/>
        <element name="upID"   type="eppcom:clIDType"
         minOccurs="0"/>
        <element name="upDate" type="dateTime"
         minOccurs="0"/>
      </sequence>
    </complexType>

  <!--
  Status is a combination of attributes and an optional human-readable
  message that may be expressed in languages other than English.
  -->

    <complexType name="statusType">
      <simpleContent>
        <extension base="normalizedString">
          <attribute name="s" type="enum-contact:statusValueType"
           use="required"/>
          <attribute name="lang" type="language"
           default="en"/>
        </extension>
      </simpleContent>
    </complexType>

    <simpleType name="statusValueType">
      <restriction base="token">
        <enumeration value="clientDeleteProhibited"/>
        <enumeration value="clientUpdateProhibited"/>
        <enumeration value="linked"/>
        <enumeration value="ok"/>
        <enumeration value="serverDeleteProhibited"/>
        <enumeration value="serverUpdateProhibited"/>
      </restriction>
    </simpleType>

  </schema>