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

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Thu, 28 Feb 2002 22:26:31 -0700

Follow-up comments inline...

>> 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.
>> 
>
> I do not get A. B. C. Would you please clarify what you mean by 
> 'ENUM-registered' or non-registered.

ENUM-registered endpoints are those in the termination path for an E.164
number whose service capabilities are properly exposed in service field
tags in NAPTR records. Since the PSTN today wouldn't prevent other
endpoints in that termination path with capabilities not listed, or
substitutions of a "non-registered" endpoint (such as in the call
forward case), there is always some potential for mismatch between the
termination path for an E.164 number and the list of services
registered. I had perhaps oversimplified things a  bit by referring to
the endpoints as registered rather than their services.

>> 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.
>
> 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.

To answer or not answer is the most basic, but I can also us an SRS to
answer or expose based on context (which may include authenticated
identity where such a system is available, particularly if both parties
are inside a closed system like an enterprise system), and I could even
lie (in the case of those pesky telemarketers or creditors) or expose a
bot-like IM service that mimics a human just enough to waste their time
or discourage further discussion. 

With respect to exposure to hacks via service profiling, the SRS only
solves this problem if the end user chooses a sufficiently narrow filter
that gives little or no information to an unidentified requestor. But it
does give the ENUM registrant a great deal more control, particularly
with respect to allowing for "blacklisting" of known malicious
requestors or request patterns, which ENUM is not prepared to do
otherwise.

<snip>

> 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.

I think these are valid concerns. My hope is to find enough interest to
get a standalone presence service and protocol defined that isn't tied
to any one message or media signaling protocol. The main design
constraints would be a clean query structure, a lean protocol, and tight
integration with an identity system that would be usable for real time
communications and transactions.

<snip>

>> 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. 
>
> Agreed, we should not pick winners. BTW: it would be good to know, who
are the runners?

While many proprietary systems exist today, I won't attempt to suggest
an alternative to SIP/SIMPLE at the moment. Actually, my hope is to
craft a better general-purpose presence system from scratch.
Alternatively, adding some extensions to SIP presence might also work
(though there may be some obstacles of religion in that approach, as it
seems unlikely to me that I will ever see an h.323 URI exposed via SIP
presence, for instance).

We'll it's snowing hard here in Denver tonight and I need to get up
early to take advantage of the fresh powder (not to mention the fresh
perspective a day of snowboarding invariably provides). So I'm going to
call it a night...

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

            [email-masked] 
              +1 720 444 4001 

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

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 1 Mar 2002 12:50:10 +0000

Hi Andrew, Folks,
  Again, sorry for the in-line comments::

>the endpoints as registered rather than their services.

To which LwC sez:
You mean ENUM/DNS registrants, I think.

Re. the comment on end points - I assume that you mean the combination
of the (enumservice and its associated URI) within a NAPTR, yes?

Also - Dead right, there is a potential for mismatch - that's one
of the reasons why I'm hostile to E2VIDEO.G.263 and its ilk. It's
an admin "challenge".

>requestors or request patterns, which ENUM is not prepared to do

To which LwC sez:
ENUM isn't really prepared to do this at all.
What you're suggesting is what happens AFTER we drop out of ENUM.

These are all possible using a suitable authenticated (and maybe
encrypted) exchange - however, this subsequent exchange is going to take
time. I'm not sure that this is always going to be acceptable when fired
out from the core network, in the middle of call setup (as per 3GPP).
Post-dial delay is going to get long.

>communications and transactions.

To which LwC groans:
Whoa! Having endured the extended joy of IMPP, I (and I suspect Patrik)
may be a tad unhappy at the thought or reliving that experience.

>seems unlikely to me that I will ever see an h.323 URI exposed via SIP

To which LwC blinks and moves on:
Again, I worry greatly about the "from scratch". Not group 3 again, or
is this the first stirrings of group 4, of just forbidden planet, or ...?

I agree with Rudi - until we know what this system is intended to be,
it's hard to do anything but trade assumptions. I'm being dumb here,
but I would be most interested your ideas on what exactly is missing
from SIMPLE or SIP for which you need extensions to cover?

Also, you use the reserved term "presence", and I'm not quite sure that
this is quite correct here - in SIP terms the AoR is static and is
returned via an ENUM query. The current contact address may be updated
depending on the connectivity of a destination client's equipments but
that is a hidden back-end process. I guess that this back-end process
could be classified as "presence", if you look at it cross-eyed enough
(Maybe after snowbarding into a tree ?).
However, from ENUM, it's a static value; plain vanilla SIP is acting
as the SRS.

Re. h232: and SIP or SIMPLE, I don't see why not. The new, expanded,
Typhon may well be interested.

>perspective a day of snowboarding invariably provides). So I'm going to

Some people have all the luck - we just have clouds and rain and ...

all the best, Lawrence
-- 
[email-masked]: +44 1794 833666::<my opinions>: