Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM)

[Jeff Williams <jwkckid1 at ix.netcom.com>]

Stastny and all,

Stastny Richard wrote:

> Mike wrote:
> > Is it possible to have a domain name not in DNS that is useful?
>
> I like this one. It is the perfect answer to Jeffs:
> >The number assigned if publicly accessible or even viewable is in and of >itself a privacy intrusion that should not be allowed.
>
> Just wondering he is not calling this an abomination.

  Not an abomination but close!  >;)


>
>
> I could reword this according to Mike to:
> >A domain name assigned if publicly accessible or even viewable is in and of >itself a privacy intrusion that should not be allowed.

  Frist of all Mike didn't say/post this, I did...

>
>
> Lucky me that I have already stastny.com, but this should
> be taken away now by Jeff and his members?

 Of course not.  But you or any domain name holder should
be directing what aspects of his/her/it's registration data is
publicly accessible.

>
> Who are you or the group you are speaking on behalf of to
> allow or not allow me to have stastny.com. I consider THIS
> a severe privacy intrusion near to religious fundamentalism.

  I never said you couldn't! But it seems you for some odd
reason which I cannot pretend to reasonably understand,
feel as though you should not have stastny.com.  Go figure
on that one is all I can say.  However if you don't have
stastny.com TM'ed you may in the future find a TM
legal challenge to deal with.  That can get costly.

>
>
> May I cite here another philosopher:
> Das Böse ist der Glaube zu wissen, was das Gute sei (Rudolf Burger).
> The evil is the faith to know what the good is.

  Utter nonsense here I am afraid.

>
>
> So I come back to Lessig's? statement that if the Internet would not
> be around since fifty years (it just happened), it would be impossible
> to design and to deploy it now.

  Nothing is impossible.  Absolutes are illogical.  It is very likely
IMHO, that Lessig was being obtuse on purpose here...

>
>
> There are many reasons for the correctness of this statement, but one
> definitely would be the still ongoing privacy discussion:
> - is it allowed to connect a host directly via a public IP address
> to the Internet.
> - is it allowed to have a public visible domain.
> - is it allowed to query a webpage just to see if it is accessible
> - is it allowed to post a webpage everybody can access and is it
> allowed to read such a page. Shouldn't there be a contract set up by
> lawyers beforehand?

 Yes.

>
> - is it allowed to know an e-mail address of somebody and send an e-mail to
> - is it allowed to put a webcam in my bedroom
> - and so on and on

  It also allowed for the domain name holder to protect his/her/it's
publicly displayed registration data or not as he/she/it desires.

>
>
> Also a public white page phone book is an obscenity in itself
> It should not be allowed (BTW: in the old days there was no such thing
> in the USSR)

  Even in the US for as long as I can recall, which is several decades
now, a persons phone number could remain "Unlisted" in the white
pages.  This is still true today.  Why is it than that ENUM user numbers
assigned or otherwise MUST be so listed?  Is it because some
group of individuals wishes to track or be able to track annoys
ENUM number for whatever desires they should so choose, regardless
of whom those persons/groups may or may not represent such as
Hamas, Al-queda, Islamic gehad, ect., ect...

>
>
> IETF is a technical body, but in the last week on this list no technical
> issues whatsoever have been discussed, only political and philisophical

  Technical issues in today's world more and more often have philosophical
as unfortunately political and direct personal implications.  That's reality,
like it or not.


>
>
> See
>
> Richard
>
> > -----Original Message-----
> > From: Mike Hammer [mailto:mhammer at cisco.com]
> > Sent: Tuesday, June 22, 2004 1:30 AM
> > To: Jeff Williams; Stastny Richard
> > Cc: enum at ietf.org
> > Subject: Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM)
> >
> > Jeff,
> >
> > Just out of curiosity, how did the opt-in versus opt-out issue play out
> > with other domain names in the DNS?  Is it possible to have a domain name
> > not in DNS that is useful?
> >
> > Also, are you asserting that having an entry in User ENUM and privacy are
> > mutually exclusive?  (That it is impossible by the content of the record
> > in
> > ENUM to provide privacy?)
> >
> > An E.164 number could be viewed as a public resource that is assigned to
> > you to aid in establishing connections through the collective public
> > telephone network.  It would not make sense to allow users to take E.164
> > numbers out of circulation and thus cause everyone else's number to have
> > to
> > increase in length (any more than necessary) as a result.  I'm trying to
> > understand the model whereby you move the number to the IP domain, but
> > then
> > don't put it into ENUM to enable calls to be routed to it.  Perhaps you
> > could clarify what it means to opt-out or not opt-in?
> >
> > Not for or against anything just yet, just trying to understand exactly
> > what data you consider private versus public.
> >
> > Mike
> >
> >
> > At 09:34 PM 6/19/2004 -0700, Jeff Williams wrote:
> > >Stastny and all,
> > >
> > >Stastny Richard wrote:
> > >
> > > > Jeff Williams writes:
> > > > >And this to a very great degree is what is wrong with the standards
> > > > >track with ENUM.  Both opt-in and Opt-out should be incorporated.
> > > >
> > > > They did. The ENUM protocol as defined in IETF can be implemented
> > > > in both ways, athough NOT in the same tree, because the both options
> > > > are mutually exclusive.
> > >
> > >   You again misunderstood what I said. That may be my fault however.
> > >So I will try to be more precise.  The user should be able to have either
> > >opt-in or opt-out regardless of which tree.  And that in the current
> > >protocol is not provided for, and easily could be.
> > >
> > > >
> > > >
> > > > Let me explain: Opt-in means that at the beginning nobody is in and
> > the
> > > > end-user decides if he wants to be in to get this service. This is the
> > case
> > > > with User ENUM, which is an add-on service.
> > >
> > >   Yes I already knew this, so this exercise is not necessary...
> > >
> > > > The underlying service
> > > > is his phone service and this phone service is working regadless if
> > > > he is in ENUM or not (with the exception of ENUM-enable numbers,
> > > > which are operating only if you are in User ENUM, but nobody is
> > > > forced to use these numbers)
> > >
> > >   Again yes I also already knew this as well.  And here is one of the
> > >problem areas in the current standards track protocol.  If you do not
> > >choose as a User ENUM to use these numbers you effectively do
> > >not have ENUM capability which is a trap that is by design, and bad
> > >design at that, to pressure any user to use these numbers and therefore
> > >expose themselves to privacy violations or intrusion of various sorts
> > >unnecessarily.
> > >
> > > >
> > > >
> > > > The end-user has the additional choice how much information he
> > > > discloses: the minimum requirement is the number itself and the
> > > > operator, if he puts in e.g. sip:+43xxx at provider.net.
> > >
> > >   Yes and the minimum requirement is another area where the user
> > >is exposed to privacy intrusions as he/she need need not have to
> > >have the number disclosed or even listed or viewable in DNS
> > >records, but  still available to law enforcement agencies upon
> > >notification of the user in advance.
> > >
> > >
> > > > Additional
> > > > information between caller and callee may be exchanges via
> > > > negotiation between servers (as in SIP) or Personal User Agents
> > > > as proposed in UCI. The end-user may also decide on his discretion
> > > > to put in more information as he likes, especially a company.
> > >
> > >This I also already knew.  And the proposed UCI is a bit too loosely
> > >worded as to whom decides what the user can direct his/her
> > >"personal agent" to disclose and whether any restrictions are
> > >at the users discretion.  Hence exposing the user to potential
> > >further damage should said personal agent decide without prior
> > >consent, such disclosures...
> > >
> > > >
> > > >
> > > > Opt-out would mean that everybody is in and the end-user decides not
> > > > to be in. If a provider decides to implement the basic communication
> > > service
> > > > based on ENUM, he MUST put all users using this service in ENUM
> > >
> > >   Yes, and this I also already knew and again exposes unnecessarily the
> > >user to potential privacy intrusions of obvious and already discussed
> > >various sorts.
> > >
> > > >
> > > >
> > > > Using ENUM for a service is currently also opt-in, but for the
> > provider as
> > > > a whole with all of his numbers. There is no opt-out for the
> > individual
> > > > end-user.  This is called Infrastructure ENUM. It uses ENUM technology,
> > > > but in separate tree. It is opt-in currently because there is still
> > the
> > > PSTN around
> > > > to reach providers not in Infrastructure ENUM by default. If the PSTN
> > > ceases
> > > > to exists at some point of time, another default method need to be
> > > defined if
> > > > E.164 numbering is still around. This may be ENUM or maybe not.
> > >
> > >   Yes again exactly right, and I already knew as well as demonstrates
> > that
> > >anti-privacy bigots do not wish of users to have opt-out for reasons that
> > >are of a political and philosophical nature which may or may not be
> > shared
> > >by some of many users and also not in concert with EU's for instance,
> > >laws.
> > >
> > > >
> > > >
> > > > Up to this point of time, different trees may be used by different
> > groups
> > > > of service providers (confederation), this is already happening. A
> > service
> > > > provider may even participate in different trees at the same time.
> > > >
> > > >  These trees may either be trees only accessible by participants of
> > the
> > > > confederation (either in extranets or with access control), but not
> > > > on the public Internet, or if accessible by the public, the
> > information
> > > > is either not accessible, encrypted or useless for the normal end-user.
> > > >
> > > > There is also a difference between the information contained in
> > > > the trees.
> > > >
> > > > In User ENUM the information points to end-points,
> > > > giving one ore more URIs where the end-user has his services.
> > > > Different NAPTRs may point to different service providers.
> > > > The domain name holder is the end-user.
> > >
> > >   Right, and as the user does not own his/her domain name currently
> > >he/she is exposed to others making many privacy and security decisions
> > >for him/her depending on the service agreement the provider has or
> > >may change from time to time.
> > >
> > > >
> > > >
> > > > In Infrastructure ENUM the entry points in principle to
> > > > the destination network providing the service for this number.
> > > > The domain name holder is the service provider.
> > >
> > >   Right if and when the Domain Name holder is also the service
> > >provider which would not be the case in most instances...
> > >
> > > >
> > > >
> > > > All this together precludes User ENUM and Infrastructure
> > > > ENUM to be in the same tree (even the delegation structure
> > > > may be differnent).
> > > >
> > > > Of course User ENUM and Infrastructure ENUM may co-exist,
> > > > any user listed in one or more Infrastructure trees may also
> > > > request an entry in User ENUM. The provider may also offer
> > > > to the calling customer a service in such a way that first User
> > > > ENUM queried and then Infrastructure ENUM. This is already
> > > > implemented in some SIP servers and works. (Note: why should
> > > > the provider do this? Because the user may do this by himself also.
> > > > It is kinda carrier selection ;-)
> > > >
> > > > ETSI is currently drafting a TS 102 055 on Infrastructure ENUM
> > > > explaining all these issues.
> > >
> > >   Yes I have seen early parts of this draft..
> > >
> > > >
> > > >
> > > > BTW: there is one complication emerging at the moment:
> > > > Confederations also want Infrastructure ENUM to be used
> > > > for routing of transit calls, e.g. an provider is publishing number
> > > > ranges in a confederation tree he is serving on the PSTN with his
> > > > gateways. This is in principle feasable, but will cause serious
> > problems
> > > > in the future, especially if two confederations decide to merge there
> > > > trees. If one numbers are entered by providers which are assigned
> > > > to them, no conflicts could arise if trees are merged.
> > >
> > >   Agreed that there could be some problems in the instances where
> > >said confederations are merged for some reason or another such
> > >as a business merger or buyout.  But again they can be overcome
> > >without intruding either previous confederations users discretion
> > >regarding any privacy exposures.
> > >
> > > >
> > > >
> > > > If numbers are entered by providers not assigned to them, this
> > > > will cause policy problems and conflicts. These conflicts cannot
> > > > be resolved in ENUM, because it is not designed for it. Other
> > > > protocols like TRIP or OSP should be used for this.
> > > >
> > > > Richard:
> > > > To Jeff: You know what my problem with all privacy advocates is?
> > > >
> > > > They are trespassing my privacy by trying to limit my freedom of
> > decision,
> > > > including my human right to make idiotic decisions ;-)
> > >
> > >   Hummm?  Well I honestly don't see how such a situation is relevant
> > >or even possible.  Freedom to choose is also a part of protecting
> > >anyone's privacy.  Idiotic decisions by someone that does so for
> > >others, knowingly of that or those persons is a responsibility of
> > >great gravity sometimes.  For oneself, and only effecting oneself,
> > >idiotic decisions are of course expectable however damaging
> > >to oneself only, they may be...
> > >
> > >   Ask yourself, do you NEED access to my ENUM number?
> > >Does any network operator NEED unrestricted access to my
> > >ENUM number?  Would access of any sort or at any level
> > >to any number other individuals, regardless of supposed status
> > >or position not have the increasing potential of the domain name
> > >holders ENUM number not expose him/her to potential if not
> > >eventual definite abuses of various sorts, some being of a
> > >life threatening nature?  I believe the answer to this question
> > >to definitely be, YES.  And THAT is not expectable and
> > >preventable if the current ENUM standards track/protocol
> > >incorporates at least most of the exposures now known and
> > >have been known for some time...
> > >
> > >Regards,
> > >
> > >--
> > >Jeffrey A. Williams
> > >Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
> > >"Be precise in the use of words and expect precision from others" -
> > >     Pierre Abelard
> > >
> > >"If the probability be called P; the injury, L; and the burden, B;
> > >liability depends upon whether B is less than L multiplied by
> > >P: i.e., whether B is less than PL."
> > >United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
> > >===============================================================
> > >Updated 1/26/04
> > >CSO/DIR. Internet Network Eng. SR. Eng. Network data security
> > >IDNS. div. of Information Network Eng.  INEG. INC.
> > >E-Mail jwkckid1 at ix.netcom.com
> > >  Registered Email addr with the USPS
> > >Contact Number: 214-244-4827
> > >
> > >
> > >
> > >_______________________________________________
> > >enum mailing list
> > >enum at ietf.org
> > >https://www1.ietf.org/mailman/listinfo/enum

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1 at ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827



_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum