Subject: [Enum] Revised #2 IETF 53 Agenda

From: Richard Shockey <[email-masked]>
Date: Sun, 10 Mar 2002 18:05:10 -0500

I want to solicit opinions one last time on the issues surrounding the 
documents we have on the plate.

The core issues to discuss come down to the revision of 2916 and issues 
surrounding service field registration IMHO and some recent discussion on 
call flows etc.

I'd like Doug Ranalli to kick off the general issues on service 
registration since his draft first identified the core issues involved and 
then go to specifics on SIP, possible presence granularity and then 
TEL.  Doug  ...OK with you?

I'm of the opinion that we should first discuss the core 2916 revision 
goals and status then get into the heart of the matter.

I want you folks to fill in the Issues lists for these drafts that we need 
to discuss. I've highlighted possible questions but these are just opinions 
based on the discussions from the list in the past couple of weeks? Your 
input is needed NOW!!! The agenda must be submitted before the 13th.

We will need to decide in MN what drafts, other than the obvious revision 
of 2916, should be put on our revised agenda.

#######################################

IETF 53 ENUM WG Draft Agenda

Chair(s):
Patrik Faltstrom <[email-masked]>
Richard Shockey <[email-masked]>

Transport Area Advisor:
Scott Bradner <[email-masked]>

Mailing Lists:
General Discussion:[email-masked]
To Subscribe: [email-masked]
In Body: subscribe
Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/

AGENDA BASHING (5 min)

Scribe Introduction … Jay Hilton  < applause >
 .
NEW CHARTER REVIEW - Chair’s (5 Min)

http://www.ietf.org/html.charters/enum-charter.html

Revised Milestones

CORE DOCUMENT REVIEW  (45 min ??)

2916bis Update -  The E.164 to URI DDDS Application
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-00.txt

Issues:
Review of Goals and Objectives for Revision
Status of DDDS
Requirements for Service Registration ..Privacy?  Applicability Statement?

SERVICE FIELD DOCUMENTS  ( 1 Hour ??)

ENUM Service Descriptions
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-walter-ranalli-enum-service-01.txt

Issues:
What is the goal of this level of granularity in service registrations?

The Use of ENUM by SIP
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-01.txt

Issues:

??? Jon ??
Processing of 2 SIP service fields in one ENUM registration?

ENUM Service Resolution
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zmolek-enum-pointer-00.txt

Issues:
Well what is this draft meant to do?
Direction on Presence only Service Field
Is presence different from SIP ??

The ENUM TEL enumservice
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-brandner-enum-tel-00.txt

Issues:
Why?  Is this just for call forwarding or is there carrier specific issues 
in this ... aka LNP?

OTHER DOCUMENTS

Extensible Provisioning Protocol and E.164 (10 min +)
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-e164-02.txt

Issues:

Is this the direction the WG wants to go?
Possible transport options?
Tier 1 and or Tier 2 usages?
Relation to PROVREG

ENUM Call Flows (10 min)
draft-lind-enum-callflows-03.txt

Issues:

This document has been around a while but let us clarify what direction 
this is taking.
What is the goal and purpose of the document?
Is this an accurate picture of possible scenerios?
Should Call Flows descriptions be application specific and included in 
service registration documentation?

DOCUMENTS OF NOTE [ NOT ON AGENDA ]

US ENUM Forum Overview
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-freilich-overview-enum-forum-00.txt

History and Context of ENUM Operational Decisions
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-iab-itu-enum-notes-00.txt

Number Portability in the PSTN  Status to Last Call ?
draft-ietf-enum-e164-gstn-np-03.txt

OPEN DISCUSSION

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 10 Mar 2002 23:16:58 -0500

I look forward to Jay's scribbles.

> Requirements for Service Registration ..Privacy?  Applicability Statement?

I'd like to see how the SR maps to:
	o purpose of the data collection (intended use right, not bulk sale or
		incorporation in reverse directories or link to out-of-band
		data, etc.,
	o access (write right) of the originator (subscriber or registrant,
		the end user0| to the collected data,
	o retention policy of the data collector (delete by date or condition),
	o recipient(s) of the collected data
With a hint or two I might be able to contribute to this bit of the req doc.

Comments by email please.
Eric

---

From: Richard Shockey <[email-masked]>
Date: Sun, 10 Mar 2002 22:24:48 -0500

>                 incorporation in reverse directories or link to out-of-band

Ok makes sense..these are general issues..but see below.

>         o recipient(s) of the collected data

what is national specific and what is general (global) presuming that each 
nation state is responsible and sovereign is for its portion of the E.164 
plan as is currently in force.. how are these segmented in the requirements 
if at all?

I did ask Patrik and Mike to require a Privacy Statement as part of the 
Service Registration documentation requirement.

Could you possibly draft a ENUM Privacy Considerations ID ?  What are the 
issues US, EC, Asia-PAC etc.  This is well within scope..  what is 
specifically missing here?

>With a hint or two I might be able to contribute to this bit of the req doc.

Hints are given...:-)

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 11 Mar 2002 08:01:28 +0100

> specifically missing here?

In the IETF we don't write about what is the specific status in various
countries.

We describe _how_ and _where_ various buttons can be pressed in the
protocol so integrity of data, risk of falsification, protection
mechanisms, privacy issues are handled according to whatever policy the
user might have.

We don't describe the policy though.

A small difference, but important.

I.e. something like this, saying we have five rules (this must be simple):

  - ENUM is an opt-in mechanism
  - What is stored in DNS is accessible for anyone
  - Trolling of DNS makes it possible for post-processing
  - Integrity protection is made with DNSSEC
  - Secure authenticated storage is made with LDAP

In the case of ENUM, DNS is used, and whatever is stored in DNS is visible
for anyone. It only have lookup mechanism for phone number to other URI's
and not the other way around. Trolling of the DNS, but can be done, might
make it possible for parties to do post-processing of the data. Integrity
of the data can be made possible with DNSSEC, the day it is deployed, which
is the current strategy IETF has for such issues with the DNS. Sensistive
data which is to be protected from access by non-authorized access is to be
stored in an external database which support authentication, and we
recommend LDAP according to the enumservice specification FOOBAR (which is
not yet written).

    paf

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 11 Mar 2002 12:57:31 -0500

A phrase I coined in the 5th and 4th floors of an office building full of
mechanism-free (undistracted by technology) policy-wonks in the capital of
some country or another is "jurisdictionalization" (abv. j19n).

If there is a requirement for (jurisdictionally) scoped properties of data
access or store, something not true in general, but probable in systems in
which store is in the form of a "global lookup repository [with perimeter
integrity and loose, converging consistency]", and access is not specified
in the context of a secure model, e.g., open access ...

Then there is a requirement for at least looking for mechanism(s) that
support scoped properties of data.

To be less theoretical, the US operates under under an opt-out regime,
conditional access (legal status), and limited crypto. While each is
unfortunate, a problem is to specify fewer distinct mechanisms than
jurisdictions, possibly as few as one, that meet this and other instances
of policy.

Now I mentioned {access,purpose,retention,recipient} because that set of
tags has managed to retain utility after three years of active scrutiny 
in the EU,OECD,FTC policy frameworks, for "interoperable" (or mutually
comprehensible) policy language, giving rise to at least one attempt to
create a mechanism in a problem domain to provide j19n scoped privacy
properties to data collection and publication systems.

This suggests the problem is tractible, in theory at least. (Patrik's
signature belongs here, as a quotation). Who's problem is this? It may
be ours, then again, I don't know of a single US-based for-profit entity
that is engaged in privacy as an added-value [1].

> issues US ...

[putting on Indian Hat] The US issue is institutionalized theft, any data
placed "in common" is converted into property by pirates, er, providers,
and repurposed to bulk resource for telemarketers. Thanks for the straight
line.

I agree with Patrik. FOOBAR needs to be written, and WHOIS vigorously
depricated (oddly enough, I've a draft on that very subject).

Now to cup #2 of coffee. Enjoy Minneapolis. There are two fine casinos
in the area with better food than the glass maze. Patronize Indians, and
don't forget to tip!

Eric

[1] Before spending a year layer nine considerations for dns at a nameless
beltway dbRON, I spent a year on layer nine considerations for the document
object model via http, aka data protection as an economic value, at a US
company fetchingly named "Engage". Share price of which is now reduced by
three orders of magnitude.