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

From: Brandner Rudolf <[email-masked]>
Date: Wed, 27 Feb 2002 19:57:18 +0100

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.

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.

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.

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?

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.

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.

Rudi

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

---

From: Richard Shockey <[email-masked]>
Date: Wed, 27 Feb 2002 14:35:15 -0500

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

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

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

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