[Enum] Notes from Dec. 14, 2000 ENUM Mtg

["Jay R. Hilton" <[e-mail]>]

Enclosed are the notes from the December meeting of ENUM.  PLease review and
provide any comments / corrections to me at [e-mail].

Regards,

Jay Hilton

Telephone Number Mapping WG (enum) Meeting Notes

THURSDAY, December 14 at 1300-1500
==================================

CHAIR: Richard Shockey <[e-mail]>

AGENDA:

1. Agenda Bashing (5 min)
Introductions, blue sheets, etc. RS
- The agenda was approved as proposed.

2. Thanks to our former co-chair Scott Petrak
- The meeting expressed thanks to Scott Petrak for getting ENUM started and
moving on this important activity.

3. ENUM Administration in the United States - Penn Pfautz - James Yu  (20 min)
draft-pfautz-yu-enum-adm-00.txt
- Discusses both domain registration and Telephone number Administration.
- Major issues identified included:
  - Authentication of rights to the telephone number.
  - Disconnect notification.
  - Telephony service specific records.
- The Enum Hierarchy proposed in the document is:  e164.arpa (RIPE), Tier 1
(defined by the ITU Member State),
Tier 2 - Service Registrar (NAPTR Records), Tier 3 Service Registrar.

- Regarding the discussion on Authorization Rights:
  - Rights to ENUM domain is tied to number assignments in the PSTN.
  - Generally, the telephone service provider (TSP) is only party that knows if
party is authorized.
  - This is a design issue for the industry.

- Regarding the discussion on Disconnect Notify:
  - Rights to number in ENUM are lost when service on the telephone number is
disconnected.
  - Again, only the TSP knows if party is authorized.

- Regarding the discussion on "Telephony Service Specific Records"
  - Are there services for which the TSP should have the right to put records in
 ENUM?
  - How can TSP control records in Tier 2 of end user choice?
  - How might these records be distinguished?
  - Alternative is to treat the TSP like any other applications service provide.
  - Ability of the TSP to populate ENUM four the customer will facilitate
penetration.
     - Comment that the document is generic enough that it will apply outside of
 the USA as well.  For example, in
countries where they have NP, etc.
     - Comment that the document needs to be renamed to a Generic Document.  Put
 North AM specific information in
an appendix.

REFERENCE MODEL for the ENUM Admin Process: (James Yu)

- ENUM DNS Hierarchy in the U.S.
  - Showed e164.arpa and tier 1, 2, and 3 positions in the hierarchy.
  - Ref Model I (General) model shows interface points A-H.
  - James stepped through examples showing how architecture would work.

-    Ref Model II has simplified model.
-    Next Steps:
     - Enhance the model to include.
          - # Portability administrator.
          - Etc.
-    Generalize the names in the ref model to represent their roles in the ENUM
admin process.

Should this document be generalized and then forwarded for WG approval as
Informational RFCs?  Question from the
floor, suggested that we should look at the next admin model before we make this
 decision.  Also a note that this is one
model and is not a definitive statement from that the IETF supports this model.
  An Info RFC means that this is for info
and does not indicate the WG says that this how it should work.

Comment from the floor:  This WG should state how DNS should be used to support
ENUM, and may develop a Best
Current Practices (BCP) for use of DNS for ENUM.

This document will be either merged with the document that follows regarding
Admin processes for ENUM, or if this
is not possible, then it may be published as a separate Informational RFC.

4. ENUM - Tier 1 Roles-00.txt - Doug Ranalli (10-15 Min),
http://www.ietf.org/internet-drafts/draft-ranalli-peek-
walter-enum-t1roles-00.txt

Defines a set of "actors".  It further defines the roles and responsibilities
for "actors".
Logical 1st Tier of ENUM System; assumes e.164 # has been assigned to
subscriber.  Registration and translation of
e/164 name into IP-Address of authoritative Tier-2 name server.
Physical Tiers: Multiple physical tiers in the proposed IETF-ITU ENUM System.
Background:  derived from experience in operating ENUM and related services.
WG Feedback was requested in 3 areas:
     - # Provider terminology?
     - Who has valid registration rights?
     - Role of # Portability in Tier-1?

Proposes a separation of the entity that assigns E.164 # from telephone service
provider
     Tel Number Provider (TNP).
     800# example in the US.

2 entities w/registration rights
     subscriber.
     Sub Agent (Svc Provider).

Tel number Provider has disconnect rights
     TNP revokes Sub assignment.
     Dialing plan change.

Role of Number Portability in Tier 1 ENUM (NP doesn't apply)
     Subscriber doesn't change.
     TNP change only important when exercising exclusive disconnect rights.

Confirm role in Tier-1

NEXT Steps

- Next version after this meeting
- Looking for continuing input from the WG

There was discussion that WG may want these two documents to be merged?  Ranalli
 wants to advance this work and
perhaps put it in a standards track.  S. Bradner indicated that he did not think
 that we should pursue a standards track or
BCP.  This would be outside of scope of this WG.  Suggestion that an Info RFC is
 still the best way to go.  There was
then general agreement that an Info RFC is the way to go.

Therefore, it was agreed that both documents will either be merged into a single
 document or if not possible, both
published as individual Info RFCs.


5. ENUM Call Flows - Steve Lind  (15 Min),
http://www.ietf.org/internet-drafts/draft-lind-enum-callflows-01.txt

This document described basic calls using interworking, PSTN-IP and IP-PSTN.
It further discussed global services such as  - Universal International
freephone, International premium rate, shared
cost, etc.
Steve pointed out that the ITU-T Document COM2-R80 contains the number
portability work in SG2.
It was proposed that the group develop options for PSTN->IP Gateway
identification.
This would include. if no DNS records, preference to try to complete the call to
 number dialed by the end user.
It was proposed that the Freephone section should address all global svc (UIFS,
IPRS, ISCS).
It was also proposed that UIFS calls should route to a central proxy server
where, based on point-of-origin or other
customer-provided info, proxy can redirect to forward call to the proper
destination.

NEXT STEPS<  resolve outstanding issues
A revision of this work will be seen at the January 2001 SG2 meeting.
It was proposed that this draft could be a WG Draft for an Informational RFC.
Given that is the way to go forward then
the WG can expect the document to be ready for WG last call in Sept 2001.  An
Info RFC may be available shortly
after the SG2 meeting in Jan 2001.  A comment was made that the mailing list
will still go on even if the WG stops and
we can approve Last Calls on the mail list.

6. ENUM Operations - Greg Vardureuil  (20 min  + )
http://www.ietf.org/internet-drafts/draft-ietf-enum-operation-01.txt

It was agreed that the title no longer reflects the true focus of the document.
  Propose to rename to "An ENUM Service
Reference Model", because the document is not focused on Admin models, it is not
 a DNS BCP.  However, it does
define common terms and topologies and provides context for client implementers.
  Intention is NOT to define a
service.  Looking for suggestion for a new name for the document
 .
The Document does propose definitions for Tiers.  Tier 1 - 4: regulator to TNP,
TNP to svc registrar, svc registrar to
NAPTRs, URL to service-specific info respectively.  There was discussion to keep
 the proposal to 4 levels.
  - Discussion:  In this document the Tiers are a proposed transition from one
tier to another.  Need further definition of
Tiers, need to come to consensus.  Maybe we need to use another word besides
Tier in this document.  R. Shockey
suggested to collapse tier 1 and 2 in this document.  Perhaps this should be a
separate model form the previous two
documents.  After continuing discussion, it was agreed to take the discussion
off line to harmonize this these terms.

There was some potential Dname-Cname /NAPTR Interactions.  May have
unintentional interactions where 2
telephone numbers initial strings resolve to the same leaf mode.  Proposed
resolutions:
     - Profile NAPTR substitution for ENUM to limit the potential for unintended
 results
     - Profile / discourage DNAME/CNAME out of DNS for ENUM use.

It was agreed to wait to resolve this interaction until experience with ENUM
implementations is gained.  Lots of
discussion regarding the use of cname and dname.  Suggestion that these names
are not appropriate for these
discussions.  Take cname and dname out of this draft
Randy: Why do we need this?
Greg V.: Telephone renumbering is the issue.  Would like to use pointers rather
than duplicate database.
Randy:  Discussion has not supported this.
Greg stated that there is expected to be a lot of renumbering.
WG Agreement: All references to  CNAME and DNAME should be expunged (removed)
from this document.

This document also discussed Performance Issues:  It is unclear whether proposed
 ENUM hierarchy will perform as
required over the open Internet.  Discussion followed:  UDP packet loss rates
and client retry-intervals appear to take
too long.  This is a packet loss over the Internet question.  Some people have
stated that as high as 10-40% packet loss
could occur.  Some specifics statistics were quoted to the meeting.  A request
was made that this kind of data would be
helpful in our discussions.  Several comments from people that are putting up
ENUM trials suggest that people could
run test on these trials to gather data.  The WG Agreement was again to wait
until experience is available on this issue
and then revise the document if necessary.

Greg still needs additional text that was promised, but did not arrive, after
the last meeting.  Additional general editorial
clean up.

What is this document, Standard, Info RFC or BCP??  A proposal to publish this
document as an Informational RFC,
once harmonization has occurred, and additional edits completed was agreed.

7. Further Updates on IETF-ITU discussions coming out of ITU Study Group 2
meetings in Berlin. (Chair - Others) -
(10 min +)

ISCO(IAB/IETF)-ITU Agreements/or understandings (these agreements were actually
with the WP1/2 of ITU-T SG2).:
     Domain zone administration was agreed to be outside the scope of this
meeting and WP1/2.
     ITU will see to it that each Member State has authority for the inclusion
of their country code info for input to
the DNS. (ENUM is not approved for use in any national state, etc.)
     The national zone, for geographic resources, is a national matter and is,
therefore administered by the ITU
Member States to which the country code is assigned.
     all admin entities, including DNS admins, will adhere to all the applicable
 tenets of all pertinent ITU Recs,
with regard to the inclusion of the E.164 resource information in the DNS.
     The ITU, IETF and IAB will jointly cooperate fully to ensure that the
agreements and procedures to
accommodate the above understandings, and any other mutually agreed appropriate
future understandings, will be
implemented and adhered to on an ongoing basis.  The ITU may request the
consultation of the WP1/2 experts as
necessary and as prescribed in Resolution 20.

There was some discussion to clarify who the agreements / understandings were
with.  S. Bradner clarified that this was
an agreement with the ITU regarding the info they had regarding who had number
databases.

Further Clarification:  This agreement only covers e164.arpa, no other domain
names are affected.  See the liaison
statement from WP1/2.  ITU has a list of who is the authority that can speak on
numbers for the countries.

The ITU is not assuming jurisdiction over DNS.

Preview upcoming SG2 work.
http://www.ietf.org/internet-drafts/draft-itu-sg2-liason-enum-01.txt
There was not time to review this document.  Attendees are encouraged to review
the document to see the plan of
upcoming SG2 work.

8. WG next steps -

ENUM MIB? (10 min +)  Does ENUM protocol need a MIB?  No, WG agreed this is not
needed!  Chair will delete
ENUM MIB from WG charter.
The question of what the ENUM WG should do now that it has developed the ENUM
protocol.  Suggestions were:
-    Go Dormant - Recharter - Conclude

Proposal:  ENUM has done its job and developed the core protocol for ENUM.  NO
OBJECTIONS, by the WG.

Options now for the ENUM WG
A: Go to sleep, take on no new work
B:  Close the WG
After asking the question on each item, there was no clear majority for either
course of action.  S. Bradner then stated
that the ADs will take this under consideration and decide.

9. Open Discussion

Additional Reference Documents:

These have been submitted but will not be presented at the meeting.

Number Portability in the GSTN
http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-gstn-np-00.txt

Number Portability in the United States
http://www.ietf.org/internet-drafts/draft-foster-e164-gstn-npusa-00.txt

End of meeting.



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