Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Fri, 11 Aug 2000 09:44:19 -0500

I believe the core ENUM specification is now receiving the significant
community review it deserves as the community begins to understand this
rather complex protocol. (ENUM is depenent upon DNS and NAPTR, both complex
entities in their own rights.) 

There are open questions about a few known design choices.   It is
unfortuate that this discussion has begun in earnest only after the
submission to the IESG for last call.  However, late as it may be, I believe
we must still address the questions concerning the design choices, and if
necessary, make changes to the specification. 

While changes may be introduced after proposed standard, our history
suggests that substantial changes can only be made if the origional protocol
is a failure and has seen little use.  If limited sucess is achieved, then
we are stuck with patching deficiencies in a backward compatable manner,
usually by adding otherwise unnecessary complexity and resulting
interoperability difficulty.  

ENUM is a "core" application protocol that is expected to be used by many
important new applications.  It certianly is one that "materially affects
the core Internet protocols or that specifies behavior that may have
significant operational impact on the Internet".  By this observation, I do
not suggest that we need to wait for implementation experience, but it is
certianly worth putting forth a well understood proposal.  How the protocol
is extended is an especially important thing to understand and document
before implementations are deployed that preclude anticipated extensions.

Greg V.

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]]
Sent: Thursday, August 10, 2000 10:32 PM
To: Hong Liu
Cc: Manfredi, Albert E; [email-masked]'; [email-masked];
[email-masked]
Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt

At 15.38 -0400 00-08-10, Hong Liu wrote:
>(2) The second proposal by me is to treat all numbers, be it E.164 
>or others, as a
>sequence of digits. The service will be differentiate from the 'rs' 
>field of the
>NAPTR record. In this case, we will have E2U for E.164, IMSI2U for 
>E.212, GTT2U
>for E.214,... etc.

Two things:

(1) I am not saying you should not do this (aswell). What myself and 
Michael says is that it is unnessecary to remove the ability to 
distinguish in the regexp between numbering plans

(2) This I-D is for _proposed_ standard, next step is draft standard.

The distinction between them is as follows (see RFC 2026):

Proposed Standard:

    A Proposed Standard specification is generally stable, has resolved
    known design choices, is believed to be well-understood, has received
    significant community review, and appears to enjoy enough community
    interest to be considered valuable.  However, further experience
    might result in a change or even retraction of the specification
    before it advances.

    Usually, neither implementation nor operational experience is
    required for the designation of a specification as a Proposed
    Standard.  However, such experience is highly desirable, and will
    usually represent a strong argument in favor of a Proposed Standard
    designation.

    The IESG may require implementation and/or operational experience
    prior to granting Proposed Standard status to a specification that
    "materially affects the core Internet protocols or that specifies
    behavior that may have significant operational impact on the
    Internet".

    A Proposed Standard should have no known technical omissions with
    respect to the requirements placed upon it.  However, the IESG may
    waive this requirement in order to allow a specification to advance
    to the Proposed Standard state when it is considered to be useful and
    necessary (and timely) even with known technical omissions.

    Implementors should treat Proposed Standards as immature
    specifications.  It is desirable to implement them in order to gain
    experience and to validate, test, and clarify the specification.
    However, since the content of Proposed Standards may be changed if
    problems are found or better solutions are identified, deploying
    implementations of such standards into a disruption-sensitive
    environment is not recommended.

Draft Standard:

    A specification from which at least two independent and interoperable
    implementations from different code bases have been developed, and
    for which sufficient successful operational experience has been
    obtained, may be elevated to the "Draft Standard" level.  For the
    purposes of this section, "interoperable" means to be functionally
    equivalent or interchangeable components of the system or process in
    which they are used.  If patented or otherwise controlled technology
    is required for implementation, the separate implementations must
    also have resulted from separate exercise of the licensing process.
    Elevation to Draft Standard is a major advance in status, indicating
    a strong belief that the specification is mature and will be useful.

    The requirement for at least two independent and interoperable
    implementations applies to all of the options and features of the
    specification.  In cases in which one or more options or features
    have not been demonstrated in at least two interoperable
    implementations, the specification may advance to the Draft Standard
    level only if those options or features are removed.

    The Working Group chair is responsible for documenting the specific
    implementations which qualify the specification for Draft or Internet
    Standard status along with documentation about testing of the
    interoperation of these implementations.  The documentation must
    include information about the support of each of the individual
    options and features.  This documentation should be submitted to the
    Area Director with the protocol action request. (see Section 6)

    A Draft Standard must be well-understood and known to be quite
    stable, both in its semantics and as a basis for developing an
    implementation.  A Draft Standard may still require additional or
    more widespread field experience, since it is possible for
    implementations based on Draft Standard specifications to demonstrate
    unforeseen behavior when subjected to large-scale use in production
    environments.

    A Draft Standard is normally considered to be a final specification,
    and changes are likely to be made only to solve specific problems
    encountered.  In most circumstances, it is reasonable for vendors to
    deploy implementations of Draft Standards into a disruption sensitive
    environment.

So, if I am wrong, we can "fix" this when we have more experience, 
when someone have written something about (I see these documents 
missing):

   - Use of LDAP as second step in E.164 resolution on the internet
     after the ENUM resolution (among others, VPIM people want this)
   - Use of ENUM-like services when having a closed numbering plan
   - Use of ENUM-like services with "sub-addressing" (or whatever it
     is called)
   - Use of ENUM in various countries (like USA and Sweden) where
     different schemes of number portability is in use already
   - The DDDS documents ready

I would not be surprised if we need to change things before going to 
"draft" standard, and maybe we even have to restart at "proposed".

I think this whole debate is premature, and that we today need the 
I-D as RFC so people can implement this stuff, so we get the 
experience we need to produce the next round of documents in the IETF 
(not necessary in the ENUM wg). As it is today, this spec is only an 
I-D which is a living target, can not be referenced, and because of 
that it is hard for for example the VPIM people to really start 
working on what they have knowledge about.

     Patrik

_______________________________________________
enum mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/enum

---

From: Hong Liu <[email-masked]>
Date: Fri, 11 Aug 2000 11:49:48 -0400

Greg,

I share the some concerns as described in your email. Please see my additional
comments in between lines below.

Cheers,

--Hong

> entities in their own rights.)

The paradox we are facing today in the ENUM WG is that we are refering to NAPTR,
which is also undergoing some changes recently. Personally, I think the DDDS
documents explain the concepts and algorithm much better than the new NAPTR
document. But I guess we are racing against time...

> necessary, make changes to the specification.

Agree. In the spirit of moving forward, if we are going to advance the document
to RFC, then we need to clearly document what the open issues are, and _not_
make any design choice on any of these issues. For example, leaving the '+' in
the algorithm is clearly biased towards the prefix+digit proposal, which has not
been carefully thought out.

While the discussions on this topic leads to a bigger problem for extensibility,
it was pronounced as "premature". If it is premature, then the '+' is not needed
because:
(1) The major argument for keeping it is to have a way to tell an E.164 number
from a non-E164 number. This argument is no longer valid if we are to delay the
consideration of using ENUM for non-E164 numbering plans.
(2) Taking '+' out will not affect in any way the operations of ENUM for E.164
to URI mapping.
(3) Removing '+' requires little modification of the existing document, which
can then pass on to RFC status.
(4) It also leaves the door open for future considerations on service
differentiation when the proposal(s) for doing so becomes mature.

> interoperability difficulty.

Totally agree.

> before implementations are deployed that preclude anticipated extensions.

Yes. Extensibility is critical for ENUM mechanisms to be widely deployed in an
interoperable manner.