headers
Jeff Williams | 1 Jul 2004 05:05
Picon

Re: IETF, ENUM and NGN

Marian and all,

Marian Durkovic wrote:

> > AFAICT nobody is suggesting Infrastructure and User ENUM would use the
> > same tree. The constraints and data models for these things are
> > completely different. However some people seem to think that if these
> > two flavours of ENUM use the same domain name, this means they both
> > have to use the same tree with one model for ownership, administration
> > and delegation. That doesn't necessarily follow. What some operator
> > does with its private, internal-use-only version of e164.arpa and how
> > they populate and manage that is nobody else's concern, apart from the
> > usual regulatory issues like universal service obligations, fair
> > competition and so on.
>
> Yes it is - as soon, as you start getting complaints from cutomers of
> this operator like "why did you put into the e164.arpa. records
> which routed me to such expensive path?"
>
> I'd be quite interested what will be your reaction, if someone makes
> a "private" tree overlaying the .UK TLD with any sort of (possibly invalid)
> data.
>
> Generally, using the same domain name for completely different purposes is
> IMHO _very_ bad idea.

 Agreed. However it doesn't matter which or how many domains are used
in the public internet/DNS, exposing any user specific private data is
not necessary for operation, and endangers the user or users.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Williams | 1 Jul 2004 05:11
Picon

Re: IETF, ENUM and NGN

John and all,

  Of course your right, John.  However what we are all seeing here
is a distinct difference in agenda's and philosophy regarding the need
for users should have the right to use ENUM in the public DNS
and still have an opt-out or opt-in of their personal and private
data such as their name, ENUM number, address, and direct
contact phone number.

John Curran wrote:

> At 10:05 AM +0100 6/30/04, Jim Reid wrote:
> >AFAICT nobody is suggesting Infrastructure and User ENUM would use the
> >same tree. The constraints and data models for these things are
> >completely different. However some people seem to think that if these
> >two flavours of ENUM use the same domain name, this means they both
> >have to use the same tree with one model for ownership, administration
> >and delegation. That doesn't necessarily follow. What some operator
> >does with its private, internal-use-only version of e164.arpa and how
> >they populate and manage that is nobody else's concern, apart from the
> >usual regulatory issues like universal service obligations, fair
> >competition and so on.
> >
> >What matters is the operators agree on a domain name for
> >Infrastructure ENUM. This might as well be e164.arpa since (a) it's
> >vendor neutral; (b) already an agreed IETF standard; (c) not
> >controlled by any nation. It's hard to see how any other choice of
> >domain name could be better (technically or politically).
>
> Hmm...  If some operators really and truly intend to run a data tree
(Continue reading)

Permalink | Reply | 4 comments |
headers
Clive D.W. Feather | 1 Jul 2004 11:53

Re: ENUM Privacy (was RE: User ENUM vs Operator ENUM)

Stastny Richard said:
>> Richard, *please* fix your mail software. It is very annoying to get
>> needless base-64 encodings of UTF-8 that's actually just ASCII text.
>> Even more irritating is finding a mail tool to translate that encoding
>> back to ASCII so that your words of wisdom can be read. Grrr!

> On the other hand, I consider UTF-8 as a valid standard and seemingly
> most normal mail SW is able to understand it. Even the IETF archive
> has been updated to decipher it.

Your mail is arriving here in quoted-printable, not base64. I don't know
why he's complaining.

And both Mutt and Turnpike seem to be able to handle your emails with no
difficulty whatsoever; in fact, I had to make an effort to find out what
all the fuss was about.

--

-- 
Clive D.W. Feather  | Work:  <clive <at> demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive <at> davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |
Permalink | Reply | 501 comments |
headers
Clive D.W. Feather | 1 Jul 2004 12:00

Libel from Jim Reid

I have just received the message:

     ----- The following addresses had permanent fatal errors -----
  <jim <at> rfc1035.com>
      (reason: 550 5.0.0 Mail from spammers is refused - get lost.)

     ----- Transcript of session follows -----
  ... while talking to gromit.rfc1035.com.:
  >>> MAIL From:<clive <at> demon.net>
  <<< 550 5.0.0 Mail from spammers is refused - get lost.
  554 5.0.0 <jim <at> rfc1035.com>... Service unavailable

I am not and never have been a spammer, and I consider this libel
unacceptable. I am a subscriber to this list in good standing, and see no
reason why I should be treated like this.

--

-- 
Clive D.W. Feather  | Work:  <clive <at> demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive <at> davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |
Permalink | Reply | 1 comment |
headers
Conroy, Lawrence (SMTP | 1 Jul 2004 12:07
Picon

Re: Fwd: [Sipping] RFC 3824 on Using E.164 numbers with the Session Initiation Protocol (SIP)

Hi Richard, folks,

I quote from RFC3824 of June 2004:
    Note that the ENUM specification has undergone a revision shortly
    before the publication of this document, driven by the update of the
    NAPTR system described in RFC 2915 [12] to the Dynamic Delegation
    Discovery System (DDDS) family of specifications (including RFC
    3403).  This document therefore provides some guidance for handling
    records designed for the original RFC 2916 [16].

Super.
We try to convince people to use 340x/3761, and this RFC talks only 
about the old/obsolete stuff.

It's not like RFC3761 was issued in great haste or had late changes to 
the syntax or concept or anything (nor did RFC3764). As for the update 
from 2915 to 340x, that was hardly recent.

Coordination must be a great thing.

all the best,
   Lawrence

On 30 Jun 2004, at 00:39, Richard Shockey wrote:
> <FYI on 3824>
>> To: ietf-announce <at> ietf.org
>> From: rfc-editor <at> rfc-editor.org
>> Date: Tue, 29 Jun 2004 16:24:46 -0700
>> Cc: sipping <at> ietf.org, rfc-editor <at> rfc-editor.org
>> Subject: [Sipping] RFC 3824 on Using E.164 numbers with the Session
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Hammer | 1 Jul 2004 16:38
Picon
Favicon

Re: IETF, ENUM and NGN

At 08:11 PM 6/30/2004 -0700, Jeff Williams wrote:
>of their personal and private
>data such as their name, ENUM number, address, and direct
>contact phone number.

Jeff,

While other elements might be private data, the E.164 number is not.  The 
E.164 number MUST be visible to enable universal routing of calls to at 
least some node that can reach the terminal assigned that E.164 number.

The privacy issue is about what OTHER data gets associated with the E.164 
number, that is SPECIFIC to an INDIVIDUAL.  Please get this straight in 
your mind.

Mike
Permalink | Reply | 3 comments |
headers
Stastny Richard | 1 Jul 2004 18:43
Picon

Re: Fwd: [Sipping] RFC 3824 on Using E.164 numbers with theSession Initiation Protocol (SIP)

Be careful:
Quod licet Jovi, non licet bovi
Richard

	-----Ursprüngliche Nachricht----- 
	Von: Conroy, Lawrence (SMTP) [mailto:lwc <at> roke.co.uk] 
	Gesendet: Do 01.07.2004 12:07 
	An: Richard Shockey 
	Cc: enum <at> ietf.org 
	Betreff: Re: [Enum] Fwd: [Sipping] RFC 3824 on Using E.164 numbers with theSession Initiation Protocol (SIP)
	
	

	Hi Richard, folks,
	
	I quote from RFC3824 of June 2004:
	    Note that the ENUM specification has undergone a revision shortly
	    before the publication of this document, driven by the update of the
	    NAPTR system described in RFC 2915 [12] to the Dynamic Delegation
	    Discovery System (DDDS) family of specifications (including RFC
	    3403).  This document therefore provides some guidance for handling
	    records designed for the original RFC 2916 [16].
	
	Super.
	We try to convince people to use 340x/3761, and this RFC talks only
	about the old/obsolete stuff.
	
	It's not like RFC3761 was issued in great haste or had late changes to
	the syntax or concept or anything (nor did RFC3764). As for the update
	from 2915 to 340x, that was hardly recent.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Williams | 1 Jul 2004 20:29
Picon
Favicon
Gravatar

ldaps and E2U


One of the URI mappings mentioned in the ENUM RFC is from E.164 to an ldaps 
URI ; that is ldap (i.e. X.500 in drag) over SSL.

Can anyone point me to a E2U client implementation that has an initial DNS 
lookup then cooperate with ldap(s) (preferably resolved using PRDMD-oriented 
ActiveDirectory implementation from Microsoft)?

Alternatively , has anyone tried to put ENUM NAPTRs in the DNS schema of the 
active directory, so the directory can act as the responder for E2U queries- 
and thus benefit from well-understood management domain practices and 
knowledge distribution techniques for private domain access points?
Permalink | Reply | 2 comments |
headers
Adrian Georgescu | 1 Jul 2004 21:49
Favicon
Gravatar

Re: ldaps and E2U

What would be the role of Active Directory with regards to ENUM? Could 
you detail on this?

On Jul 1, 2004, at 8:29 PM, Peter Williams wrote:

>
> One of the URI mappings mentioned in the ENUM RFC is from E.164 to an 
> ldaps URI ; that is ldap (i.e. X.500 in drag) over SSL.
>
> Can anyone point me to a E2U client implementation that has an initial 
> DNS lookup then cooperate with ldap(s) (preferably resolved using 
> PRDMD-oriented ActiveDirectory implementation from Microsoft)?
>
> Alternatively , has anyone tried to put ENUM NAPTRs in the DNS schema 
> of the active directory, so the directory can act as the responder for 
> E2U queries- and thus benefit from well-understood management domain 
> practices and knowledge distribution techniques for private domain 
> access points?
>
>
>
> _______________________________________________
> enum mailing list
> enum <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
Permalink | Reply | 1 comment |
headers
Richard Shockey | 1 Jul 2004 23:13
Picon

Re: ldaps and E2U

At 03:49 PM 7/1/2004, Adrian Georgescu wrote:

>What would be the role of Active Directory with regards to ENUM? Could you 
>detail on this?

I would guess this is a TN to SIP AOR directory application for IP-PBX's. 
Use the corporate wide AD to manage SIP AOR's ..but you would have to get 
the IP-PBX's all to point to AD for resolution and the chances of that 
happening is about the same as getting them to add ENUM resolvers.

Ask your Cisco rep when are they going to add a ENUM resolver into Call 
Manager ? ..oh sorry..

>>Alternatively , has anyone tried to put ENUM NAPTRs in the DNS schema of 
>>the active directory, so the directory can act as the responder for E2U 
>>queries-

you would not put NAPTR in AD only the relevant SIP AOR.

>>and thus benefit from well-understood management domain practices and 
>>knowledge distribution techniques for private domain access points?

The concepts of "well-understood management practices" and Microsoft Active 
Directory strike me mutually exclusive.

The answer to the question BTW is no ..it has not been done.

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane