Subject: RE: [Enum] Robert and Douglas' Protocols and Services draft...

From: Chip Sharp <[email-masked]>
Date: Wed, 31 Oct 2001 13:39:11 -0500

See Section 1.2.4 (first paragraph) and Section 6.4.3 of 
http://www.ietf.org/rfc/rfc3160.txt

Chip

At 01:24 PM 10/31/2001, Judith Oppenheimer wrote:
>What exactly is meant by "an IANA registry for both the protocols and
>services"?
>
>---------------------------------------------------------------------------
>----------
>Judith Oppenheimer
>http://JudithOppenheimer.com
>http://ICBTollFreeNews.com
>212 684-7210, 1 800 The Expert
>---------------------------------------------------------------------------
>----------
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Robert H. Walter
> > Sent: Wednesday, October 31, 2001 12:46 PM
> > To: [email-masked]
> > Cc: Michael Mealling
> > Subject: QRE: [Enum] Robert and Douglas' Protocols and
> > Services draft...
> >
> >
> > Hi Michael,
> >
> > Thank you for the feedback... Your suggestion of defining an IANA
> > registry for both the protocols and services is excellent and we
> > will incorporate this into the next revision of the draft.
> >
> > You raise an interesting point regarding the use of SIP with IM.
> > Will the SIP extension(s) proposed in the SIMPLE working group I-D
> > "SIP Extensions for Instant Messaging" (draft-ietf-simple-im-01.txt)
> > be absorbed into SIP or will a new extended SIP protocol (e.g. simple)
> > be born?  If the latter is the case, I agree that it makes sense to
> > specify SIMPLE as a resolution protocol.
> >
> > Regards,
> >
> > Bob
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > > Michael Mealling
> > > Sent: Wednesday, October 31, 2001 8:43 AM
> > > To: [email-masked]
> > > Subject: [Enum] Robert and Douglas' Protocols and Services draft...
> > >
> > >
> > > Hi,
> > >   Being one of the people who pointed out the need for
> > something like this
> > > I think this is the exact right way of solving this
> > problem. Good job
> > > guys! I would make two small additions to the document:
> > >
> > > 1) Define an IANA registry for both the protocols and the
> > services. You've
> > >    got the start of a template there, just add a field for
> > the documents that
> > >    define the service and/or protocol and then add an IANA
> > Considerations
> > >    section.
> > >
> > > 2) I think you should specify the protocols in terms of
> > ENUM usage and not
> > >    leave them 'nakedly' defined. In the URI Resolution
> > application it wasn't
> > >    possible to say "just use the http protocol" because
> > there were so many
> > >    different ways of doing the URI resolution services. So
> > we created
> > >    'profiles' of different protocols that narrowed the
> > protocol down enough
> > >    to make it interoperable for the specific Service you
> > were attempting to do.
> > >    I think you're going to have to do that here simply
> > because there's
> > >    probably about a 100 different ways to do IM like
> > functions with SIP.
> > >    For example: in the case of IM and SIP the actual
> > protocol used would be
> > >    SIMPLE and not SIP itself, right?  Does that make sense?
> > >
> > > -MM
> > >
> > > --
> > >
> > --------------------------------------------------------------
> > ------------------
> > > Michael Mealling     |      Vote Libertarian!       | urn:pin:1
> > > [email-masked]      |                              |
>http://www.neonym.net
> >
> > _______________________________________________
> > enum mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/enum
>
>_______________________________________________
>enum mailing list
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/enum
>
>
>_______________________________________________
>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: Richard Shockey <[email-masked]>
Date: Thu, 01 Nov 2001 10:12:10 -0500

>
> > 3. Specific applications need to have specific documents defining the
> > protocol service fields and behaviors appropriate to those applications.
> > (SIP - VPIM) and make the specific request to the IANA for inclusion. I
> > have wanted to avoid this WG take on those tasks since it clearly more
> > appropriate for SIPPING or other WG's define those documents.
>
>Right. This group just creates the registry and then specifies what
>an item going into that registry has to specify in order to 'qualify'.
>(See the IANA Considerations document on what kind of policies to
>implement here: First Come First Served, IETF Concensus, etc).

yes thank you ... this is very very important. We need  a clear statement 
on what 'qualifies' for inclusion into the registry this is at the heart of 
part of the problem I see looming ...

> > 4. That said  the Walter/Ranalli drafts point out there are ambiguities in
> > the role of various protocols such SMTP for voice mail vs SMTP for email
> > that may need to be clarified and documented separately. but .....but
> >
> > I'd like to understand more about the problem statement that requires such
> > a proliferation of service definitions in Walter/Ranalli since inherent in
> > draft is desire to finely granulate the capabilities of end points in ways
> > that I'm not sure NAPTR records were meant for.  This begins to look a lot
> > like RESCAP or some protocol to resolve capabilities of endpoints and that
> > has been a problem in the IETF for a LONG LONG time and I'm not sure we
> > want to go there.
> >
> > I just want to make sure we handle the process correctly and I'm open to
> > suggestions on what is the best work plan.
>
>The solution set in the URI Resolution was essentially to define the
>'protocol' part as not really a 'on the wire' protocol but instead
>a profile of another for a specific purpose. Each 'profile' would have
>to specify which Services it did and how. In ENUM's case there could
>very well be two ways of doing SIP+VPIM. If two people decided that
>both had good ways of doing it they would both write up a spec and
>then register with the IANA. They both have to write up how they
>handle each given Service. But at that point its a market decision about
>which 'profile' gets used...

I'd be delighted to hear your views on that ... but correct me if I'm not 
reading your message correctly ..your view is that registering a variety of 
profiles is a "good thing" and the market then decides which ones it wishes 
to use?

but my worry is still what level of granularity in the profile should be 
permissible since I'm hoping that we do not use NAPTR records a substitute 
for RESCAP.

I'm suggesting that taken to extreme this could cause confusion for client 
applications developers using NAPTR records since in the case of 8 
different profiles for SMTP which would they use?

NOTE TO THE LIST:

Many of you may not be familiar with the RESCAP and the problem statement 
that it was intended to address.

It has been a well known problem in the IETF for many many years now that 
it might be useful to identify the capabilities of endpoints in advance of 
creating a session. The problem is particularly acute in MIME attachments 
to SMTP. The Applications Area AD's Patrik and Ned and even Keith Moore 
before Ned have been trying to interest the Apps community in moving 
forward with a solution.

The problem has been there is not a sufficiently committed group of folks 
ready to work the problem consistently and consequently it has languished.

FYI from a old proposed charter.....

Description of Working Group:

Abstract:

A variety of resource identifiers have been widely deployed on the
Internet as a means of identifying various resources, services, and
destinations. However, a means of attaching a set of attributes or
characteristics to a given resource identifier and subsequently
assessing those attributes or characteristics has not been specified
and deployed.

A particularly important resolution service of this general type is one
which, when given a mail address identifying a particular mail
recipient, will return a series of attributes describing the
capabilities of that recipient. This differs from a directory service
in that no searching or other advanced query operations are involved.

The primary purpose of this service is to distribute information about
resources or services to the global Internet; as such, it is not
intended for dissemination of private information.  However, the group
will also consider whether there is a need for the query protocol to
include authentication, and thus permit administrators to restrict the
capabilities that are returned according to a locally specified
security policy.

The first task of this working group will be to define a general
resolution protocol that will translate resource identifiers to a list
of attributes. At a minimum the service must be capable of returning
mail recipient capabilities as described above, but ideally the service
should also handle more general capability and characteristics
discovery.

The second task of this working group will be to define an
administrative model and update protocol that can be used to set up and
maintain the information the resolution protocol accesses.  This
protocol will obviously require strong authentication. The working
group will also consider whether privacy services are necessary for the
update protocol, and include such services in the protocol if it finds
that they are necessary.

The service resulting from the combination of these two protocols must
meet the following requirements:

(0) The resolution protocol must be highly scalable, as the intent is to
     deploy it very widely.

(1) Resolution protocol and server overhead must be very low, as some
     applications will make very heavy use of it.

(2) Identifiers input to the resolution service must be formatted as
     Uniform Resource Identifiers (URIs) containing one or more DNS
     domains.  Note that mail addresses can be presented as mailto: URIs
     to meet this requirement.

(3) Facilities to support inheritance within the attribute store will be
     essential, as the number of identifiers may be very
     large. Specifically, mechanisms must be provided by which
     administrators can set default values for members of their
     administrative domains.

(4) Existing protocols will be profiled for use as part of this service
     whenever possible rather than developing new protocols. In
     particular:

     (a) The DNS must be used as the first step in the resolution
         service, This is because all the URIs under consideration here
         contain a DNS domain and the DNS is already properly delegated.

     (b) Existing DNS record types such as SRV and NAPTR will be used if
         feasible, to ease deployment.

     (c) A lightweight resolution protocol may be defined by this working
         group if no existing protocol proves to be suitable.

     (d) An existing administrative model and maintenance protocol will
         be used if feasible. Possible candidates for this include ACAP
         and LDAPv3.

The means to register and extend the set of attributes must be
specified.  However, specification of actual attributes needed by
various applications of this service is outside of the scope of this
working group.

This group will collaborate with the ENUM working group to determine
the degree to which it is appropriate for the two efforts to share
technology or protocols when solving their respective problems.

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 571.434.5651 Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Michael Mealling <[email-masked]>
Date: Thu, 1 Nov 2001 10:31:52 -0500

> profiles is a "good thing" and the market then decides which ones it wishes 

Yes and no. The registry and process should be open. But that doesn't
mean this (or subsequent) groups just create the registry and then do nothing.
There should be a concerted effort by those on this list to make sure that
the items put into the registry are standardized, quality specs so there
can be interoperability. But at the same time you should let others
do the same thing. Hopefully the outcome is that we do a better job.

> permissible since I'm hoping that we do not use NAPTR records a substitute 

Correct. Any service/protocol tuple should only point to the entry point.
My rule of thumb has always been: what is absolutely minimally required
in order to start an on-the-wire protocol session where those finer
grain features can be negotiated.

> different profiles for SMTP which would they use?

I think what you're after is a registration process that uses the
"IETF Concensus" process instead of a "First Come First Served" process
in order to make sure that service and protocols don't overlap to the point
where its impossible to decide on which to use without sticking
feature negotiation into the NAPTR record?

> <RESCAP stuff snipped for brevity>

I've always though that RESCAP is a real fundamental requirement for
ENUM to really scale beyond a single service. IMHO, the DDDS using 
NAPTR and RESCAP combination creates a very robust and scalable directory
service that gives things like ENUM a ready made directory that can
be easily deployed.

Being the co-chair of RESCAP I'm biased. But if those here could
take a look at the two current documents:

http://search.ietf.org/internet-drafts/draft-moore-rescap-rc-01.txt
http://search.ietf.org/internet-drafts/draft-moore-rescap-blob-00.txt

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

---

From: Dave Crocker <[email-masked]>
Date: Thu, 01 Nov 2001 08:05:22 -0800

At 10:12 AM 11/1/2001 -0500, Richard Shockey wrote:
>reading your message correctly ..your view is that registering a variety 
>of profiles is a "good thing" and the market then decides which ones it 
>wishes to use?
>

Richard, et al,

The reference to Rescap is usefully concrete and your concern highlights 
the potential for undisciplined excesses.  (And those are so much worse 
than disciplined excesses...)

Perhaps the key question is whether ENUM is for a single, specific purpose, 
such as routing telephone calls, or whether it is intended as a generalized 
mechanism for associating a range of information to a telephone number.

My own assumption is that it should be for the latter, since I think the 
market will insist on this.  However if the standards effort is only for 
telephone routing, our work is essentially done and Michael's interest is 
out of scope.  Again, my own opinion is that we should indeed deal with he 
broader scope.

That leaves us with two concerns.  One is the potential for excesses that 
you raise.  The other is that we might exceed our technical mandate and 
enter into policy making.  A limiting force against the excesses is the 
standards process itself.  Unless there is a broad consensus for a 
particular profile of ENUM parameters, they won't become a standard.  The 
broad consensus should demonstrate broad need.

To help keep these efforts constrained and to help curb the potential for 
policy-making, perhaps we should insist that each proposed profile must 
state clearly what technical function it is in aid of and how the proposed 
profile satisfies the requirement.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: Michael Mealling <[email-masked]>
Date: Thu, 1 Nov 2001 11:31:36 -0500

On Thu, Nov 01, 2001 at 08:05:22AM -0800, Dave Crocker wrote:
> or whether it is intended as a generalized 

This was my intent as well. I don't think this group needs to actually
do the work of specifying the profile. It does need to discuss and
specify what an ENUM Protocol and Service are and create the process
of registering them. But I think it should stop there or at the most do 1 and
only 1 to illustrate the process. You're statement:

1) "each proposed profile must state clearly what technical function it is 
in aid of and how the proposed profile satisfies the requirement"

in with my interpretation of Richard's concern about granularity

2) "two or more profile should not be so similar that an application can't
decide on which to use without additional information in the NAPTR record
pointing to them."

It sounds like we're getting some idea of requirements that a protocol
profile needs to evaluate before it can be 'accepted' by the IESG...

-MM

---

From: "Douglas Ranalli" <[email-masked]>
Date: Thu, 1 Nov 2001 12:27:07 -0500

Michael, Dave, Richard, et al...

Michael Mealling wrote:

> of registering them...

Michael has done a nice job articulating that we need a well defined
structure for specifying and advancing the list of "approved" ENUM
resolution protocols and services.  Bob and I will work over the next few
days to incorporate this feedback into an updated version of the draft.  The
next version will provide a proposed baseline set of considerations for IANA
to follow in the management and registration of ENUM resolution protocols
and services.

Doug

Douglas Ranalli
Founder & Chief Strategy Officer
NetNumber, Inc.
650 Suffolks Street, Suite 307
Lowell, MA  01854
1-978-848-2830
[email-masked]
www.netnumber.com