Re: AW: [Enum] Carrier ENUM mini-BoF Agenda

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

Stastny and all,

Stastny Richard wrote:

> Peter Williams wrote:
> > > > a: within User ENUM there exist privacy issues.
> > > >     set-up properly these issues do not exist in "Carrier ENUM",
> > > >     because either the information is not accessible or not usable
> > > >     by end-users.
> > > >     Note: all privacy issues with ENUM should thereore be discussed
> > > >     in the first half of the meeting, not in the mini-BoF on "Carrier
> > >ENUM"
> > >
> > >   Good point.
> >
> >
> > This is not appropriate, in my view. The reasoning is very flawed. There
> > is
> > a relationship between holder of the E.164 and the ENUM provider. While
> > end-users may be unable to gain access to the marketing information
> > derived
> > from the providers analyis of the transactions for a given ENUM name,
> > listing beneath e164.arpa (or elsewhere), the provider may seek to sell
> > this
> > information about the holder to value-added resellers, folk sellling
> > additional telematic services, etc etc. This is quite typical in the US,
> > and
> > is what the US privacy policy apparatus is designed to codify, and
> > disclose
> > (even if it provides little in the way of enfocement) - so subscribers are
> > at least notified of the possible arrangements that may impact their wider
> > use of telematics.
> >
> [Richard>] With setting it up properly I meant that the privacy data
> is secured from end-user access by established means. Period.
> There are now already a bunch of privacy data out in databases, more
> or less protected. The more or less is none of our business.

  Agreed to a point.  The protocol/standards track can be designed
to not allow for this to be the standard however, which is where I
believe Richard, and certainly I and our members are at.

>
>
> That companies may resell this data may happen, but in Europe
> this is not allowed without subscriber consent by the data protective
> laws. If this is different in US, go change the law, but I do
> not think IETF is the right place to do this.

  Agreed here as well to a point.  The IETF should only attempt
to set good technical standards.  However in doing so, it should
consider privacy issues from that technical standards track in
any and all proposed protocols.  With ENUM amongst others
the privacy element seems to be missing or ignored.

>
>
> If somebody within a company is breaking the law, there is no
> means by a protocol or architecture to prevent this.

Also agreed here.  But by designing ENUM to not provide for
privacy intrusion can be accomplished before the fact.

> So there is
> no reason to discuss or bemoan this in the ENUM WG or the mini-BOF
> on carrier ENUM, it is a complete waste of time.

  Disagreed here strongly!  :(

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