Subject: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt

From: Richard Shockey <[email-masked]>
Date: Fri, 22 Feb 2002 10:54:14 -0500

>To: IETF-Announce: ;
>From: [email-masked]
>Reply-to: [email-masked]
>Subject: I-D ACTION:draft-zmolek-enum-pointer-00.txt
>Date: Fri, 22 Feb 2002 06:20:26 -0500
>Sender: [email-masked]
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : ENUM Service Resolution Pointer
>         Author(s)       : A. Zmolek
>         Filename        : draft-zmolek-enum-pointer-00.txt
>         Pages           : 6
>         Date            : 21-Feb-02
>
>Current notions of service field tags in ENUM NAPTR records would
>frame the service exposure problem as a tradeoff between the privacy
>and heft involved in revealing detailed service information on the
>one hand or the arbitrary constraint of such information on the
>other. This draft suggests an alternative approach that keeps NAPTR
>record size small, places service exposure policy and presence
>capabilities in the hands of the ENUM registrant where it belongs,
>and minimizes impact to the ENUM registrar and their respective DNS
>architecture.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-zmolek-enum-pointer-00.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-zmolek-enum-pointer-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-zmolek-enum-pointer-00.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-zmolek-enum-pointer-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-zmolek-enum-pointer-00.txt>

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: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Wed, 27 Feb 2002 15:11:02 -0700

At long last, some discussion! If I understand you correctly, these seem
to be your concerns:

1. DNS resolution latency is already a concern, why make it worse by
adding a pointer?
2. Why add another layer of indirection when service resolution could
take place directly?
3. Since codec capabilities are embedded in service field tags, why
worry about negotiation?
4. Isn't it enough that SIP offers such a service resolution service for
"presence"
5. Is a specific URI scheme or architecture being proposed here?
6. Why suggest that the ENUM service provider and service resolution
service provider might be the same?

Here's my take on the answers to each:

1. DNS resolution latency obviously must be kept within the range of
human tolerance when sessions need to be established. But if there's
truly a latency problem with adding service resolution pointers to ENUM
in general, then SIP in particular would be unusable with ENUM. This
topic of resolution latency is an interesting rathole, I suppose, but
ultimately falls in the category of universal challenges to ENUM in
general.

2. Adding a layer of indirection should only be done when the
alternatives are more ugly, and I believe service resolution services
are just such a case.  Here's why:

  - The mapping of E.164 addresses to devices (or systems behind the
devices) is not one-to-one today and is increasingly one-to-many for a
given E.164 address (and many-to-many overall)
  - Not all systems and devices have or will have the same capabilities,
even indirectly
  - Associations between devices and E.164 numbers can change more
rapidly and frequently than the cache-friendly DNS system can support
(consider the case of call forwarding today mapped against the large TTL
of a DNS reply)

Strong association of detailed service capabilities with E.164 numbers
via ENUM would either: 
  A. Reduce accuracy of resulting information by giving information only
for ENUM-registered endpoints when one or more non-registered endpoints
may ultimately terminate a call to a given E.164 number.
  B. Somehow forbid non-registered endpoints from terminating a call
initiated through ENUM (bye-bye call forwarding!)
  C. Force ENUM service providers to act as a public "presence" service,
updating service-tags and capabilities in real-time.

Note that none of these options is desirable, and none tackles issues in
the sphere of privacy, public exposure of information, hacking via
service profiling, etc. So it is my assertion that for many cases a
"service resolution" level of indirection is justified here. I am
careful to note, however, that in some specific cases, no level of
indirection is needed or desired--ENUM clearly has value in both cases.

3. Just because you can embed codec capabilities in service tags doesn't
mean it's a good idea. In addition to the dynamic endpoints and
capabilities problem I discuss in #2 above, there's the issue of service
tag multiplication which gets even uglier when transcoding tags are
used. If the resolution latency issue you raise is important to you,
then I would think you would want to avoid the possibility of forcing a
TCP session setup and teardown just because your service tag list won't
fit in a UDP packet anymore. Does anything more really need to be said
here?

4. Within the world that SIP encompasses (which is admittedly a lot), I
have to say that SIP does a good job of acting as a service resolution
pointer. I am very supportive of SIP as such, but that doesn't mean I
believe that SIP-based presence is ready or willing to provide more
general, signaling-protocol agnostic presence services. Just because SIP
offers one approach to presence doesn't mean that it is useful to
exclude others, even if they are not yet mature or fully formed.
Frankly, many other presence services already exist within limited
realms and all of them would benefit from an open protocol for
interchange of that information. From the ENUM point of view, I would
assert that we shouldn't be in the business of picking winners for
presence services. Yet we should still make the bar reasonably high
before assigning a service tag to such a service.

5. If it wasn't clear in the draft, let me make it perfectly clear here:
I am not proposing a service tag or specific service. This is
intentional, and although I did include some examples, they are not
intended to form the basis of any proposal for a tag or a service. So
what am I proposing? Mainly an examination of some critical issues we
need to take into account as we consider how to deal with service tags,
codec negotiation, "presence" services, and the like. I would submit
that having a notion of "service resolution" services within the ENUM
worldview allows us to make better decisions about what is allowable in
service field tags and what belongs elsewhere. To be blunt, the
availability of "service resolution" services, SIP-based or not,
eliminates much of the previous justification for detailed and complex
service field tags and may help us move on to more important topics.

6. Suggesting that the ENUM service provider might also provide presence
services was my way of demonstrating that there's something in this for
the ENUM service provider as well. But it was *JUST A SUGGESTION*,
nothing more. For those that missed this in the draft, let me reinforce
that there need not be any connection at all between the two beyond the
service field tag and URI to point there. In fact, many large
enterprises will probably do a presence service themselves, just as they
do with their DNS services. Or they might outsource, just as they do
with their DNS services. 

In summary, service resolution latency is important, there's a good
reason for service resolution services, SIP's a reasonable (if not
complete) example of such a service, and indeed there is a difference
between providers of ENUM and service resolution services. Thanks again
for your note. I'm looking forward to more conversation on these issues,
as I think they get to the heart of the ENUM value proposition for all
parties. 

--Andy Zmolek 
    Technology & Standards Engineer 
      CTO Standards 
        Avaya Inc. 

            [email-masked] 
              +1 720 444 4001 

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]]
Sent: Wednesday, February 27, 2002 12:35 PM
To: Brandner Rudolf; [email-masked]
Cc: Zmolek, Andrew (Andrew); Conroy Lawrence
Subject: Re: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt

At 07:57 PM 2/27/2002 +0100, Brandner Rudolf wrote:

>Here some comments on draft-zmolek-enum-pointer-00:
>
>There are reasonable concerns over the length of time it takes to
resolve 
>to a specific communications service and contact address, when using
ENUM. 
>There have also been some concerns over the generality that DNS is a 
>public service and so provides data to whomever requests it.

Before we condemn the DNS do we have any statistics to back up that 
contention?  Eventually we need this in the process to documenting
taking 
2916 from Proposed to Draft Standard.

Why is this any different from a ENUM to SIP look up where first is the 
translation is TN to SIP URL and then URL to SIP SRV record?  If the 
suggestion is that this is increasing call setup times then I'd
certainly 
like to see some statistics supporting the contention.  If DNS data is
on 
multiple hops then there are certainly issues ..but these are highly 
related to network configuration not the DNS and unfortunately we have 
never discusses caching issues. I would be willing to suspect that most 
calls are to a limited defined number of endpoints ..maybe 50% of all
calls 
from a specific endpoint are to a list of no more than 50 numbers etc...

this leads me to believe that caching again mitigates those issues.

How could it be any worse than current cellular call setups?

>Use of an enum-pointer doesn't seem to address the former problem; it
adds 
>another lookup to the process, and suggests that this should not use
DNS.

I do respectfully disagree... I will trade call setup timing  for
personal 
privacy and security thank you. Which is why I actually have a problem
with 
your draft ..enum-bradner :-)

Essentially you have proposed a call forwarding service using TEL URL's
... 
my question is why?  Why would I want to expose that information in the 
global DNS vs offered as a service from either my PSTN or SIP service 
provider where 1. my personal preferences are hidden from global view
and 
2. both the PSTN and SIP are better tools dynamic updates in real time?

>It may address the latter problem, but there are two assumptions that
seem 
>to be embedded.
>First, it is *assumed* that there will be service field tags used to 
>report codec capabilities and transcoding. This is by no means a
unanimous 
>position, and concerns with such constructs as "+E2UVIDEO-G.263" or 
>"+E2UVOICE-G7.11" have been raised on the list.

I do NOT assume that except in the case of FAX where there is no 
negotiation capable in the protocol (SMTP) ... that does lead me to
think 
there is a future for RESCAP and NAPTR records for certain types of
services.

But I can be educated ... I really objected to the Ranalli draft on the 
basis that adding to much granularity to service fields places too much 
burden of the capabilities of the C/UA resolver.  The zmolek draft has 
started me to thinking there are conditions that granularity is
reasonable 
..except I would now require an Applicability / Justification Statement
in 
the IANA registration document that places a burden of proof on the 
protocol registrant that there is "no other way" to  do this...etc.

>Secondly, the idea of service resolution service proposed seems to tie
in 
>with "presence", which I take to mean with current connectivity or 
>location; there seems to be a suggestion that this is not addressed
using 
>the scheme proposed in the sipping-E.164 draft.
>As far as I understand it, the proposed sip enumservice is intended to 
>deal with the further service resolution in exactly the same way as
that 
>redirected via the enum-pointer.
>Could you please explain how the sip enumservice as described differs
from 
>a service resolution service redirected via the enum-pointer?

Or in other words why is presence itself distinct from SIP. I'd like a 
description of that myself.

>If the intent of this proposal is instead to take the service
resolution 
>service completely outside of the IP world (e.g. a URI indicating 
>connection to a PSTN-based gateway, such as existing Servcice Nodes)
then 
>this is not clear from the draft. I think the next version might
propose 
>the scheme intended - the URI held in the NAPTR should trigger some
sort 
>of association, but it is unclear what exactly the pres enumservice
involves.

You are not suggesting we go down the ENUM vs TRIP route are you ?
<sigh> :-)

>In the last sentence of the penultimate paragraph of section 5, it is 
>stated that "the ENUM registrant may choose to have presence, policy,
and 
>privacy services provided by their ENUM registrar". It seems to me that

>the ENUM registrant can take these from their 'service resolution
service 
>provider'; this need not be their ENUM registrar. As stated, this
appears 
>to be an undue limitation.

I dont see the problem here ... the ENUM registrar and the service 
resolution provider {tier 2] may or may not be the same entity.

>Rudi

---

From: Brandner Rudolf <[email-masked]>
Date: Thu, 28 Feb 2002 17:58:59 +0100

Comments inline.

> -----Ursprüngliche Nachricht-----
> Von: Richard Shockey [mailto:[email-masked]]
> Gesendet: Mittwoch, 27. Februar 2002 20:35
> An: Brandner Rudolf; [email-masked]
> Cc: [email-masked]'; Conroy Lawrence
> Betreff: Re: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt
> 
> 
> >There are reasonable concerns over the length of time it 
> takes to resolve 
> >to a specific communications service and contact address, 
> when using ENUM. 
> contention?  Eventually we need this in the process to 
> documenting taking 
> suggestion is that this is increasing call setup times then 
> I'd certainly 
> like to see some statistics supporting the contention.  If 
> DNS data is on 
> calls are to a limited defined number of endpoints ..maybe 
> 50% of all calls 

Ok. Others have commented about this on the list.

> 
> >Use of an enum-pointer doesn't seem to address the former 
> problem; it adds 
> >another lookup to the process, and suggests that this should 
> not use DNS.
> 
> I do respectfully disagree... I will trade call setup timing  
> for personal 
> privacy and security thank you. Which is why I actually have 
> a problem with 

Sorry, but I also do respectfully disagree with your disagreement here. Pointing off ENUM to something else won't make the issues disappear. Time and network traffic needed for the resolution and privacy kept will resurface there, regardless what the 'something else' might be.

> your draft ..enum-bradner :-)
Thanks for the flowers. It is very motivating that you think the draft has superior quality ;^)

> Essentially you have proposed a call forwarding service using 
> TEL URL's ... 
> provider where 1. my personal preferences are hidden from 
> global view and 

Let Lawrence comment on this one.

> 
> >It may address the latter problem, but there are two 
> assumptions that seem 
> >to be embedded.
> >report codec capabilities and transcoding. This is by no 
> means a unanimous 
> negotiation capable in the protocol (SMTP) ... that does lead 
> me to think 
> there is a future for RESCAP and NAPTR records for certain 
> types of services.
> 
> started me to thinking there are conditions that granularity 
> is reasonable 
> ..except I would now require an Applicability / Justification 
> Statement in 

This one I leave to Lawrence, too.

> 
> >Secondly, the idea of service resolution service proposed 
> seems to tie in 
> >location; there seems to be a suggestion that this is not 
> addressed using 
> >deal with the further service resolution in exactly the same 
> way as that 
> >Could you please explain how the sip enumservice as 
> described differs from 

Agreed, here I am with you.

> 
> >If the intent of this proposal is instead to take the 
> service resolution 
> >connection to a PSTN-based gateway, such as existing 
> Servcice Nodes) then 
> >this is not clear from the draft. I think the next version 
> might propose 
> >the scheme intended - the URI held in the NAPTR should 
> trigger some sort 
> >of association, but it is unclear what exactly the pres 
> enumservice involves.
> 
> You are not suggesting we go down the ENUM vs TRIP route are 
> you ? <sigh> :-)
> 

Absolutely not, that's what I'm afraid of, too

> >stated that "the ENUM registrant may choose to have 
> presence, policy, and 
> >the ENUM registrant can take these from their 'service 
> resolution service 
> >provider'; this need not be their ENUM registrar. As stated, 
> this appears 

I agree. My worry was the implication that the provider of mentioned services *is* the registrar.

---

From: Brandner Rudolf <[email-masked]>
Date: Thu, 28 Feb 2002 21:04:54 +0100

Comments inline and deleted Richard Shockey's comments as I answered (partially) to that.

> Von: Zmolek, Andrew (Andrew) [mailto:[email-masked]]
> Gesendet: Mittwoch, 27. Februar 2002 23:11
> An: Richard Shockey; Brandner Rudolf; [email-masked]
> Cc: Conroy Lawrence
> Betreff: RE: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt
> 
> 
> At long last, some discussion! If I understand you correctly, 

Yes, it seems to me, that we are making progress here, even if we do not agree on all issues (yet).

> these seem

You are absolutely right. In the case of pres: the resolution points off ENUM and we are done. Er, not quite. Actually I do not know what protocol and application is used. That makes it hard to further elaborate on this topic as it would be a discussion on assumtions.

> updating service-tags and capabilities in real-time.

I do not get A. B. C. Would you please clarify what you mean by 'ENUM-registered' or non-registered.

> indirection is needed or desired--ENUM clearly has value in 

privacy, public exposure ......

Having a "service resolution" might not help much, too. If I ask you a question, there are 2 basic answers: you just refuse to talk to me, or you talk to me. Agreed, with ENUM, I might reveal more information (which, to some extend is outlined in our draft) than with a service resolution. If the "service resolution" finally answeres my request, I think, that service profiling can be done anyway. I *think*, because I actually do not know what that "service resolution" is going to be in terms of authentication (which would be necessary if you have ACLs), integrity and privacy.

> fit in a UDP packet anymore. Does anything more really need to be said

I am with you here, I do not like long transcoding tags, either.
Regarding TCP session setup, well, the information *has* to be transmitted to the client one way or the other. If it is too long for UDP, it has to go via TCP, one way or the other. There is no cost savings here.

I am just worried, that the "service resolution" protocol might add *much* extra cost through authentication, signing the content and encryption. How much this might be I do not know, as I do not know what you have in mind as a "service resolution" protocol and application.

BTW:
With current specs, you can have about 7 NAPTRs in a packet, if you double the size of the NAPTRs, it'll get you 3 to 4 in a packet.

> before assigning a service tag to such a service.

Agreed, we should not pick winners. BTW: it would be good to know, who are the runners?

> service field tags and may help us move on to more important topics.

OK. Agreed

> do with their DNS services. Or they might outsource, just as they do

I agree. I'd be happy to read this in the next version of your draft.

> as I think they get to the heart of the ENUM value proposition for all

Perfect summary. I violently agree.