Subject: [Enum] Re: refresh: IESG review of rfc2916bis

From: Patrik Fältström <[email-masked]>
Date: Fri, 3 Oct 2003 15:33:35 +0200

Suggested RFC-Editor notes, which if ok should make it possible to have 
2916bis become an RFC.

       paf

> Ted Hardie's Discuss comments:
>
> I went back forth as to whether these were serious nits
> or a mild discuss.  The tired lady mentioned in the nit
> related to section 2.1 was the deciding factor.  In other
> words, I think these should be fixed, but pushback is
> welcome.
>
>
> In the introduction:
>
>     "like delegation through NS records and NAPTR records, one can 
> look up
>     what services are available for a specific domain name"
>
> Would it not make more sense to say, "what services are associated 
> with a
> specific E.164 number"?  This is not general to all domain names.

Comment: I think it is ok to make this change. The reason it talks 
about domain names in the second part of this very long sentence is 
because ENUM really is a two-step process. But, of course the whole 
algorithm doesn't work if the input is an E.164 number.

[1] In the introduction:

OLD:

    Through transformation of International Public  Telecommunication
    Numbers in the international format [4], called within this document
    E.164 numbers, into DNS names and the use of existing DNS services
    like delegation through NS records and NAPTR records, one can look up
    what services are available for a specific domain name in a
    decentralized way with distributed management of the different levels
    in the lookup process.

NEW:

    Through transformation of International Public  Telecommunication
    Numbers in the international format [4], called within this document
    E.164 numbers, into DNS names and the use of existing DNS services
    like delegation through NS records and NAPTR records, one can look up
    what services are available for a specific E.164 in a
    decentralized way with distributed management of the different levels
    in the lookup process.

> For Section 1.2, the language seems less than clear.  How about:
>
>      This document describes the operation of these mechanisms in the 
> context
>      of numbers allocated according to the ITU-T recommendation E.164. 
>  The
>      same mechanisms might be used for private dialing plans.  If the
>      mechanisms are re-used, the suffix used for the private dialing 
> plan
>      MUST NOT be e164.arpa, to avoid conflict with this specification.
>      Parties to the private dialing plan will need to know the the 
> suffix
>      used by their private dialing plan for correct operation of these
>      mechanisms.  Further, the application unique string used SHOULD be
>      the full number as specified, but without the leading '+'

Comment: It is important it is explicitly stated that the mechanism 
using e164.arpa is called "ENUM". I think this is lost in the suggested 
text. I therefore suggest using the suggested text plus an addition at 
the end about use of the term "ENUM".

In section 1.2:

OLD:

    This document specifies how "ENUM" works, that is how to handle
    numbers allocated according to the ITU-T recommendation E.164. But, a
    similar mechanism can be used also for other numbers, such as private
    dialing plans.  To implement that (a) the suffix MUST be selected,
    MUST NOT be e164.arpa, MUST be known for all parties using the same
    dialing plan (b) the application unique string SHOULD be the full
    number as specified but without the leading '+'.

NEW:

    This document describes the operation of these mechanisms in the 
context
    of numbers allocated according to the ITU-T recommendation E.164.  
The
    same mechanisms might be used for private dialing plans.  If the
    mechanisms are re-used, the suffix used for the private dialing plan
    MUST NOT be e164.arpa, to avoid conflict with this specification.
    Parties to the private dialing plan will need to know the the suffix
    used by their private dialing plan for correct operation of these
    mechanisms.  Further, the application unique string used SHOULD be
    the full number as specified, but without the leading '+', and such
    private use MUST NOT be called "ENUM".

> In Section 2.1,  the draft says:
>
>
>     For example, the E.164 number could start out as "+1-770-923-9595".
>     To ensure that no syntactic sugar is allowed into the AUS, all
>     non-digits except for "+" are removed, yielding "+17709239595".
>
> I'm not sure "syntactic sugar" is clear.  Is the AUS a gas tank? :)
> Frankly, I'd suggest deleting the second paragraph, as I don't think 
> it adds
> anything, but if it's kept, I'd suggest updating it to "the E.164 
> number could
> be represented to a user as".  I'd also suggest using a known-to-be 
> invalid
> number.  A tired lady answer this number when I called it,
> and she didn't know anything about this draft.

The telephone number is changed to the one of the IETF Secretariat.

Section 2.1:

OLD:

    For example, the E.164 number could start out as "+1-770-923-9595".
    To ensure that no syntactic sugar is allowed into the AUS, all
    non-digits except for "+" are removed, yielding "+17709239595".

NEW:

    For example, the E.164 number could start out as "+1-703-620-8990".
    All non-digits except for "+" are removed, yielding "+17036208990".

> In section 2.4.2.1, the draft says:
>
>     The mapping, if any, have
>     to be made explicit in the specification for the Enumservice 
> itself.
>     A registration of a specific Type also have to specify the Subtypes
>     allowed.
>
> I think the grammar is off there.  how about:  "the mapping, if any,
> must be made explicit"?

Section 2.4.2.1:

OLD:

    Enumservice specifications contain the functional specification (i.e.
    what it can be used for), the valid protocols, and the URI schemes
    that may be returned. Note that there is no implicit mapping between
    the textual string "type" or "subtype" in the grammar for the
    Enumservice and URI schemes or protocols. The mapping, if any, have
    to be made explicit in the specification for the Enumservice itself.
    A registration of a specific Type also have to specify the Subtypes
    allowed.

NEW:

    Enumservice specifications contain the functional specification (i.e.
    what it can be used for), the valid protocols, and the URI schemes
    that may be returned. Note that there is no implicit mapping between
    the textual string "type" or "subtype" in the grammar for the
    Enumservice and URI schemes or protocols. The mapping, if any, must
    be made explicit in the specification for the Enumservice itself.
    A registration of a specific Type also have to specify the Subtypes
    allowed.

> For the IANA consideration, the work requested by the first two 
> paragraphs
> is done.  I think that it would be better to change it to note that
> the obsoleted RFC requested these, and to give a pointer to the current
> IAB/ITU-T agreement.

Comment: The 2nd paragraph is added relative to RFC 2916, and is what I 
think a proper addition. The first can be changed though.

Section 5:

OLD:

    This memo requests that the IANA delegate the E164.ARPA domain
    following instructions to be provided by the IAB.  Names within this
    zone are to be delegated to parties according to the ITU-T
    Recommendation E.164.  The names allocated should be hierarchic in
    accordance with ITU-T Recommendation E.164, and the codes should
    assigned in accordance with that Recommendation.

NEW:

    RFC 2916 (which this document replaces) requested IANA to delegate 
the
    E164.ARPA domain following instructions to be provided by the IAB. 
The
    domain was delegated according to those instructions. Names within
    this zone are to be delegated to parties according to the ITU-T
    Recommendation E.164.  The names allocated should be hierarchic in
    accordance with ITU-T Recommendation E.164, and the codes should
    assigned in accordance with that Recommendation.

> P.S.  Here is what Ted said about Section 2.5 but I believe we should 
> leave
> it as is:
>
> I'm concerned that section 2.5  might cause as much confusion as it
> prevents.  How about replacing the whole thing with "The ENUM algorithm
> always returns a single rule.  Specific applications may have
> application-specific knowledge or facilities that allow them to
> present multiple results or speed selection, but these should
> never change the operation of the algorithm."

Good idea.

Section 2.5:

OLD:

    There has been some confusion over what exactly an ENUM Resolver
    returns and what relation that has to the 'Note 1' section in RFC
    3402. On first reading it seems as though it might be possible for an
    ENUM Resolver to return two Rules. The answer to that depends on
    which of two possible definitions you use for an ENUM Resolver:

    The first type of resolver can be called an 'intelligent' resolver.
    It understands its target application very well. In that case the
    test done at the beginning of Step 4 in the algorithm is a very
    complex one. It can include call backs to the calling thread, GUI
    events, etc. Its at this point that a client can be presented with
    the idea of "multiple Rules" because its at this step that Order is
    understood relative to the other ordered records. In this case the
    ENUM Resolver still returns one Rule to the calling application but
    its smart enough internally that it can apply application specific
    knowledge to the Rule selection test.

    The other type of resolver can be called a 'dumb' or 'driven'
    resolver. It is generic in the sense that there is no internal
    application knowledge. It is run from the 'outside' by a smart
    application that changes the selection criteria that are fed to the
    ENUM Resolver before it starts its resolution task. It returns one
    Rule only and the caller has to determine if that Rule is OK or not.
    If it isn't then it re-runs the resolver with a new set of selection
    criteria. Some might consider the combination of this dumb resolver
    and the application that's driving it as some uber-ENUM-Resolver. In
    that case it can "return more than one Rule" because it can simply
    re-run the algorithm several times to collect an appropriate set of
    Rules. But that uber-ENUM-Resolver is stretching the definition of an
    ENUM Resolver to the point of being unrecognizable.

    The key point is that the Algorithm only returns one Rule.

NEW:

    There has been some confusion over what exactly an ENUM Resolver
    returns and what relation that has to the 'Note 1' section in RFC
    3402. On first reading it seems as though it might be possible for an
    ENUM Resolver to return two Rules.

    The ENUM algorithm always returns a single rule.  Specific
    applications may have application-specific knowledge or
    facilities that allow them to present multiple results or
    speed selection, but these should never change the
    operation of the algorithm.

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

---

From: Michael Mealling <[email-masked]>
Date: 03 Oct 2003 09:51:31 -0400

> Suggested RFC-Editor notes, which if ok should make it possible to have 

I've looked these over and see no problems with any of the changes from
my end. Do you want to incorporate them and submit the new version?

-MM

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 3 Oct 2003 17:00:56 +0200

> my end. Do you want to incorporate them and submit the new version?

I wrote them as RFC-Editor notes. I feel it is up to the AD whether 
they take them as RFC-Editor notes, or if they want a new version of 
the I-D.

     paf

---

From: Richard Shockey <[email-masked]>
Date: Fri, 03 Oct 2003 16:14:58 -0400

At 11:00 AM 10/3/2003, Patrik Fältström wrote:

>I wrote them as RFC-Editor notes. I feel it is up to the AD whether they 
>take them as RFC-Editor notes, or if they want a new version of the I-D.
>
>     paf
>

Was the language on what type of RFC the enumservice field registrations 
could be ammended ?..the consensus was all ENUM service fields 
registrations must be either proposed, draft, or experimental but not 
Informational.

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   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>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 3 Oct 2003 23:55:14 +0200

On 2003-okt-03, at 22:14, Richard Shockey wrote:

> Was the language on what type of RFC the enumservice field 
> registrations could be ammended ?..the consensus was all ENUM service 
> fields registrations must be either proposed, draft, or experimental 
> but not Informational.

The diff was on version -06. I don't have it in front of me now, and I 
need to go to sleep. The clock is almost midnight here in Sweden.

I will have a look tomorrow, if noone else has looked before that.

    paf

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Sun, 5 Oct 2003 21:42:00 +0100

>    All non-digits except for "+" are removed, yielding "+17036208990".

The UK has official "numbers reserved for drama" which can be used in TV
and films with a guarantee that they are syntactically correct but will
never be allocated. Would you like one of those instead?

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 5 Oct 2003 22:55:57 +0200

> never be allocated. Would you like one of those instead?

Yes please!

I checked with the Swedish regulator Friday last week if they had such 
numbers, but they didn't.

Michael, the numbers then need to change both in the text and in the 
examples.

    paf

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 6 Oct 2003 06:26:11 +0100

Patrik Fältström said:
>> The UK has official "numbers reserved for drama" which can be used in 

<http://www.oftel.gov.uk/ind_info/numbering/drama.htm>

> Yes please!

Here's some:

  +44-116-496-0348   (Leicester)
  +44-1632-960083    (random place)
  +44-20-7946-0148   (London)
  +44-7700-900454    (mobile)
  +44-808-1570-983   (free)

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 14 Oct 2003 22:28:13 +0200

>     All non-digits except for "+" are removed, yielding "+17036208990".

This change is not made.

Part from this, it is ok.

    paf