Hi Esteemed co-chair and co-author of 3761, folks,
  Re. "large objections to 3761bis ..."

I already mentioned this, but there has been no comment on (or off)  
list, so I repeat it.
It IS important, so I'd appreciate some response. I think we NEED to  
change section 2.
The current version is incorrect for anything but terminal rules.

For the rationale, see my original post on 2nd May:
   <http://www.ietf.org/mail-archive/web/enum/current/msg06879.html>

Since that point, I have polished the proposed text, so here's what I  
think is a sensible
and necessary replacement -- the changes are to the current section  
2.2 and 2.4 intro.
The 2.4 sub-sections have just been re-numbered and I've also zapped a  
couple of typos.

I suggest that this could be rolled into the next version along with  
any other changes
reflecting LC or IESG comments (there is always another version in  
that phase, I know it :).

Comments please?

all the best,
   Lawrence

---------------------------------------------------------------------------
2.1.  Application Unique String
   The Application Unique String (AUS) is a fully qualified E.164 number
   minus any non-digit characters except for the '+' character which
   appears at the beginning of the number.  The '+' is kept to provide a
   well understood anchor for the AUS in order to distinguish it from
   other telephone numbers that are not part of the E.164 namespace.

   For example, the E.164 number could start out as "+44-116-496-0348".
   To ensure that no syntactic sugar is allowed into the AUS, all non-
   digits except for '+' are removed, yielding "+441164960348".

2.2.  First Well Known Rule
   The First Well Known Rule converts an Application Unique String (AUS)
   into an initial key into the the Application's Rules Database. For
   ENUM, the rules database is the DNS, so this key is a domain name.

   In order to convert the AUS to a unique key in this database the
   string is converted into a domain name according to this algorithm:

      1.  Remove all characters with the exception of the digits.  For
         example, given the E.164 number "+44-20-7946-0148", this step
         would simply remove the leading '+', producing "442079460148".
      2.  Reverse the order of the digits.  Example: "841064970244"
      3.  Put dots ('.') between each digit.  Example:
         "4.4.2.0.7.9.4.6.0.1.4.8"
      4.  Append the string ".e164.arpa." to the end.  Example:
         8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.

   The E.164 namespace and this Application's database are organized in
   such a way that it is possible to go directly from the name to the
   smallest granularity of the namespace directly from the name itself,
   so no further processing is required to generate the initial key.

   This domain name is used to request NAPTR records. Each of these
   records may contain the end result or, if its flags field is empty,
   produces a new key in the form of a domain name that is used to
   request further NAPTR records from the DNS.

2.3.  Expected Output
   The output of the last DDDS loop is a Uniform Resource Identifier in
   its absolute form according to the 'absoluteURI' production in the
   Collected ABNF found in RFC 3986[RFC3986].

2.4.  Valid Databases
   At present only one DDDS Database is specified for this Application.
   "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS
   Database" [RFC3403] specifies a DDDS Database that uses the NAPTR DNS
   resource record to contain the rewrite rules.  The Keys for this
   database are encoded as domain names.

   The character set used to encode the substitution expression is
   UTF-8.  The allowed input characters are all those characters that
   are allowed anywhere in an E.164 number.  The characters allowed to
   be in a Key are those that are currently defined for DNS domain
   names.

2.4.1.  Optional Name Server Additional Section Processing
   Some nameserver implementations attempt to be intelligent about items
   that are inserted into the additional information section of a given
   DNS response.  For example, BIND will attempt to determine if it is
   authoritative for a domain whenever it encodes one into a packet.  If
   it is, then it will insert any A records it finds for that domain
   into the additional information section of the answer until the
   packet reaches the maximum length allowed.  It is therefore
   potentially useful for a client to check for this additional
   information.

   It is also easy to contemplate an ENUM enhanced nameserver that
   understands the actual contents of the NAPTR records it is serving
   and inserts more appropriate information into the additional
   information section of the response.  Thus, DNS servers MAY interpret
   Flag values and use that information to include appropriate resource
   records in the Additional Information portion of the DNS packet.
   Clients are encouraged to check for additional information but are
   not required to do so.  See the Additional Information Processing
   section of RFC 3403 [RFC3403], Section 4.2 for more information on
   NAPTR records and the Additional Information section of a DNS
   response packet.

2.4.2.  Flags
   This Database contains a field that contains flags that signal when
   the DDDS algorithm has finished.  At this time only one flag, "U", is
   defined.  This means that this Rule is the last one and that the
   output of the Rule is a URI [RFC3986].  See RFC 3404 [RFC3404].

   If a client encounters a record with an unknown flag, it MUST ignore
   it and move to the next Rule.  This test takes precedence over any
   ordering since flags can control the interpretation placed on fields.

   A novel flag might change the interpretation of the regexp and/or
   replacement fields such that it is impossible to determine if a
   record matched a given target.

   If this flag is not present then this rule is non-terminal.  If a
   Rule is non-terminal then clients MUST use the Key produced by this
   Rewrite Rule as the new Key in the DDDS loop (i.e., causing the
   client to query for new NAPTR records at the domain name that is the
   result of this Rule).

2.4.3.  Services Parameters
   Service Parameters for this Application take the following form and
   are found in the Service field of the NAPTR record that holds a
   terminal rule. Where the NAPTR holds a non-terminal Rule, the
   Services field SHOULD be empty, and clients SHOULD ignore its
   content.

      service-field = "E2U" 1*(servicespec)
      servicespec   = "+" enumservice
      enumservice   = type 0*(subtypespec)
      subtypespec   = ":" subtype
      type          = 1*32(ALPHA / DIGIT / "-")
      subtype       = 1*32(ALPHA / DIGIT / "-")

   In other words, a non-optional "E2U" (used to denote ENUM only
   Rewrite Rules in order to mitigate record collisions) followed by one
   or more Enumservices which indicate the class of functionality a
   given end point offers.  Each Enumservice is indicated by an initial
   '+' character.

2.4.3.1.  ENUM Services
   Enumservices may be specified and registered via the process defined
   in "Guide and Template for IANA Registrations of Enumservices"
   [SV_GUIDE].  This registration process is not open to any Enumservice
   that has '-' as the second character in its type string.

   In particular, this registration process is not open to Enumservice
   types starting with the facet "X-". This "X-" facet is reserved for
   experimental or trial use, and any such Enumservices cannot be
   registered using the normal process.

   Finally, any Enumservice type that starts with the facet "P-" is
   intended for use exclusively on private networks. As such, NAPTRs
   containing Enumservice types starting "P-" should not be seen on the
   global Internet. Even if an ENUM client recognizes and can engage in
   the Enumservice, it may be incapable of resolving the URI generated
   by the containing NAPTR. These Enumservices WILL NOT be registered.

   Such Enumservices MUST NOT be provisioned in any system that provides
   answers to DNS queries for NAPTR resource record sets from entities
   outside the private network context in which these Enumservices are
   intended for use.

   Unless an ENUM client is sure that it is connected to the private
   network for which these NAPTRs are provisioned and intended, it MUST
   discard any NAPTR with an Enumservice type that starts with the "P-"
   facet.

2.4.3.2.  Compound NAPTRs and Implicit ORDER/REFERENCE Values
   It is possible to have more than one Enumservice associated with a
   single NAPTR.  These Enumservices share the same Regexp field and so
   generate the same URI.  Such a "compound" NAPTR could well be used to
   indicate a mobile phone that supports both "voice:tel" and "sms:tel"
   Enumservices.  The Services field in that case would be
   "E2U+voice:tel+sms:tel".

   A compound NAPTR can be treated as a set of NAPTRs that each hold a
   single Enumservice.  These reconstructed NAPTRs share the same ORDER
   and PREFERENCE/PRIORITY field values but should be treated as if each
   had a logically different priority.  ENUM clients SHOULD process the
   Enumservices within a compound NAPTR in a left-to-right sequence.
   ENUM provisioning systems SHOULD assume that such a processing order
   will be used and provision the Enumservices within a compound NAPTR
   accordingly.

---------------------------------------------------------------------------