Subject: [e2md] Issues slides , please comment

From: Dean Willis <[email-masked]>
Date: Mon, 22 Mar 2010 23:37:54 -0700

I have roughed out some open issues slides for the e2md bof. I believe list discussion has generated a reasonable proposal for each. Please review ASAP.

Thanks 

http://www.ietf.org/proceedings/10mar/slides/e2md-3.pdf
 
-- 
Dean Willis

---

From: Jim Reid <[email-masked]>
Date: Tue, 23 Mar 2010 10:39:47 +0000

On 23 Mar 2010, at 06:37, Dean Willis wrote:

> I have roughed out some open issues slides for the e2md bof. I  
> believe list discussion has generated a reasonable proposal for  
> each. Please review ASAP.

Dean, the slides look fine to me. Thanks.

I'd quibble about the DNS payload concerns though. Just about every  
DNS implementation does EDNS0 these days. [It's needed for DNSSEC as  
well as being generally useful.] So there shouldn't be an issue here  
on DNS response size: just mandate EDNS0 with a minimum buffer size of  
2KB or whatever. One thing to remember about EDNS0 is a lot of CPE  
middleware boxes are broken and drop or mangle these packets. Ray can  
give you chapter and verse about that.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 23 Mar 2010 07:44:37 -0700

> I have roughed out some open issues slides for the e2md bof. I believe list discussion has generated a reasonable proposal for each. Please review ASAP.

Folks,

The security-related bullets look reasonable, but my guess is that they are 
missing what's needed.

So, for example, saying 'encryption' always sounds plausible when referencing 
security, but it probably does not apply, here.

Encryption means privacy, but I suspect that privacy (against wire-tapping) is 
not a major concern for this use.

It is more likely that the necessary security function will be authorization -- 
hence, authentication and access control are the relevant mechanisms.

Perhaps all such cases are satisfied by using a DNS that is on a 
controlled-access net.  If not, then adding these mechanisms is non-trivial and 
probably worth pursuing generically, rather than waiting for a specific use case.

I say that because the nature of the data that has been discussed on the list 
sounded like the type that will lead to a need for authorization and because 
Internet-scale authorization is a challenge.  (I believe it's never been done.)

If it is ever a requirement to provide it, it needs to be explored now.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Dean Willis <[email-masked]>
Date: Tue, 23 Mar 2010 11:56:05 -0500

Dave CROCKER wrote:

> It is more likely that the necessary security function will be
> authorization -- hence, authentication and access control are the
> relevant mechanisms.

True, although IF the data is encrypted, then "authorization for access"
means "possession of the key".

As you noted, I don't think we're worried about wire-tapping. I'm more
worried about the fact that anybody who can query the DNS can see the
records it contains, and if those records reveal information that should
have remained private, then we have a problem.

> controlled-access net.  If not, then adding these mechanisms is
> non-trivial and probably worth pursuing generically, rather than waiting
> for a specific use case.

Indeed. That is the biggest question facing the proposed working group.
It's also related to the question of whether or not, in a given
installation, some information MUST be access-controlled while other
information MUST be access-open. If we have to do both at the same time,
then we either have to have two independent installations, or we need to
have an authentication/authorization model in the protocol.

This feeds back directly on the proposed charter, which has text around AAA.

> I say that because the nature of the data that has been discussed on the
> list sounded like the type that will lead to a need for authorization
> and because Internet-scale authorization is a challenge.  (I believe
> it's never been done.)

This raises an excellent question of scaling.

For a given installation, one might envision that some of the records
need to be readable Internet-wide, while some other records might need
to be restricted to a smaller audience. Is this smaller audience so much
smaller that it makes the auth problem easier?

For example, let's consider the fictitious and horribly contrived case
of a domain that wishes to put client credit card numbers into the DNS
associated with that client's phone number (and yes, I agree this is a
bad idea), and also wants to put an non-confidential published link to
each client's web site into the DNS. Anybody looking at the DNS might
want to find the client's web site, but only people in the domain's
financial services department need access to the credit card number.

This seems to reduce the scaling problem for auth: if the credit card
number is encrypted, then the key distribution problem is limited to the
manageable task of giving the key to the financial services people. Or
if we instead encode an HTTPS reference to the data in the NAPTR, the
problem of managing credentials for accessing it is similarly restricted.

So, is our problem really "internet scale authentication", or is it more
 on the scale of "the sort of routine authentication that
Google/Schwab/Yahoo/UBS etc. do tens of billions of times every day?"

> If it is ever a requirement to provide it, it needs to be explored now.

Agreed.

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 23 Mar 2010 13:00:39 -0400

Dave IMHO 75% of the use cases for E2MD will be in controlled access
networks. That is certainly they way it works today in commercial ENUM
deployments outside of e164.arpa. Clearly there are issues where some data
is applicable in the public tree and those use cases can be handled by some
redirection to HTTP or other transport protocols if necessary. 

IMHO most of this security discussion is a Red Herring that the ENUM
community settled years ago. LNP data has highly restricted access for
instance,  but its routinely used in private ENUM trees and the Internet
hasn't crashed as a result.

We need to offer tools people want to use and leave policy issues to the
appropriate NRA.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave
CROCKER
Sent: Tuesday, March 23, 2010 10:45 AM
To: Dean Willis
Cc: [email-masked]
Subject: Re: [e2md] Issues slides , please comment

On 3/22/2010 11:37 PM, Dean Willis wrote:
> I have roughed out some open issues slides for the e2md bof. I believe
list discussion has generated a reasonable proposal for each. Please review
ASAP.

Folks,

So, for example, saying 'encryption' always sounds plausible when
referencing 
security, but it probably does not apply, here.

Encryption means privacy, but I suspect that privacy (against wire-tapping)
is 
not a major concern for this use.

It is more likely that the necessary security function will be authorization
-- 
hence, authentication and access control are the relevant mechanisms.

Perhaps all such cases are satisfied by using a DNS that is on a 
controlled-access net.  If not, then adding these mechanisms is non-trivial
and 
probably worth pursuing generically, rather than waiting for a specific use
case.

list 

Internet-scale authorization is a challenge.  (I believe it's never been
done.)

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
e2md mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/e2md

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 23 Mar 2010 13:07:17 -0400

+1 this is a non issue. Also the discussion of whether DNS is appropriate
here ..you are not discussing the dual nature of how people are thinking of
actually using E2MD.

I must say I know there is only an hour here a but as the ENUM co-chair I
could but this BOF in some context but I'm not being permitted to present.

I support the WG proposal but this is not a good way to begin.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim
Reid
Sent: Tuesday, March 23, 2010 6:40 AM
To: Dean Willis
Cc: [email-masked]
Subject: Re: [e2md] Issues slides , please comment

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 23 Mar 2010 13:14:15 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dave CROCKER
> authorization --

If you don't have the key to decrypt, you can't access the (cleartext) data and you're not authorized to do so.  

> probably worth pursuing generically, rather than waiting for a specific

Yes, I think a generic way would be better - then all drafts can just point to that.
 
> Internet-scale authorization is a challenge.  (I believe it's never been

I think in practice this isn't really Internet-scale.  It's really more likely to be in private DNS servers - but certainly it may be in publicly accessible/reachable DNS servers but still only need to be viewable/usable by a small subset of clients, and that's where I think we do need to specify something to cover.

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 23 Mar 2010 13:15:12 -0400

RS> This again is policy. We don't need to define AA ourselves only provide
the recommendation that if there are restrictions on a particular class of
data then you should use FOO if it is not a closed access network.

This entire discussion is putting the cart before the horse this is a
discussion best left to the WG.

Agreed.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 23 Mar 2010 13:15:42 -0400

We won't get away with hand-waving it I think.  We'll need a solution to get past IESG, no?

> Richard Shockey
> Sent: Tuesday, March 23, 2010 1:01 PM
> To: [email-masked]; 'Dean Willis'
> Cc: [email-masked]
> Dave
> authorization

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 23 Mar 2010 10:16:53 -0700

> means "possession of the key".

Encryption requires a consumer-specific key.  Each receiver of the data will 
need to get it tailored to their own key.  This isn't a big deal with the TLS 
session-time approach, because TLS generates the recipient-specific key in real 
time.  But it's not an 'authorization' capability.  For this, the receiver-side 
key needs to be tied to their identity, in an X.509-cert style.  Again, that's a 
big deal, with very little field experience in open Internet communities, I believe.

However...

On 3/23/2010 10:00 AM, Richard Shockey wrote:
 > networks.

I hope you noted that I noted that alternative and made everything that followed 
contingent on needing open Internet, not private Internet.

 > community settled years ago.

How did it settle the matter for the other 25% that you did not cover?

 > We need to offer tools people want to use and leave policy issues to the

A design approach which relies on restricted use in a private network /IS/ a 
policy issue.  There's nothing wrong with making it, but it needs to be 
understood for its considerable effect.

If authorization and privacy are deemed out of scope, then that's what the 
slides should say.  I posted my note based on some comments I had heard ealier 
and based on the content of the draft slides.

All of this suggests that the topic is not nearly as 'settled' as your note 
implies.  My own post sought to press for settling it.  Having a working group 
consensus that says that all security-related issues are handled out of band 
certainly has precedent, although it needs careful justification to the IESG. 
But restricting use to private networks does sound as if it handles the matter, 
especially when the new use is based on existing practise.

But don't dismiss the question, just because you know the answer.

Make sure everyone else, including the IESG, knows and agrees with the answer.

d/

-- 

   Dave Crocker

---

From: [email-masked]
Date: Tue, 23 Mar 2010 09:22:47 -0800

Of the three documented use cases (i.e. the ones for which drafts exist), 
only Richard's existing CNAM draft from ENUM contains "personal" 
information.

As far as I can see these data privacy issues were _not_ concerns when 
this draft was going through the ENUM group.

Ray

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 23 Mar 2010 13:26:57 -0400

> Sent: Tuesday, March 23, 2010 12:56 PM
> 

That just moves the problem around, doesn't it?  Let's say we said "use HTTPS redirection".  So my PC resolves the E2MD entry, gets redirected to an HTTPS server.  This proves nothing about my PC's authorization to get what the HTTPS server provides - so the HTTPS server has to challenge my PC or do something to verify my PC is what it claims to be, and is authorized to access data foobar.  This requires my PC to have some shared secret with the HTTPS server.  Well, that's all we needed to exist to begin with for E2MD: a shared secret.  It's just that the shared secret is a key, not a user/password.  ISTM the big advantage for a http method would be you get per-user auth, and thus per-user revoke too, but the downside is we'd need to spec exactly how it works if we expect automated machines to be able to use it (which for me is the use-case for E2MD: machines).

-hadriel

---

From: "Nieminen Klaus" <[email-masked]>
Date: Tue, 23 Mar 2010 19:31:41 +0200

Hi folks,
 
At least in Finland it's a regulatory requirement that operators cooperate to maintain a free service that describes to which operator the number belongs to. So at least we have it already available in the Internet:
http://www.siirretytnumerot.fi/ <https://ressu.ficora.fi/exchweb/bin/redir.asp?URL=http://www.siirretytnumerot.fi/>  (sry available only in Finnish)
 
regards,
 
- Klaus

________________________________

Lähettäjä: [email-masked] puolesta: Richard Shockey
Lähetetty: ti 23.3.2010 19:00
Vastaanottaja: [email-masked]; 'Dean Willis'
Kopio: [email-masked]
Aihe: Re: [e2md] Issues slides , please comment

-----Original Message-----

Folks,

d/
--

   Dave Crocker

---

From: Dean Willis <[email-masked]>
Date: Tue, 23 Mar 2010 12:38:10 -0500

> We won't get away with hand-waving it I think.  We'll need a solution to get past IESG, no?

We ABSOLUTELY MUST agree to the scope of the problem that the working
group is solving, and we have to show evidence that the problem is
solvable by the WG, but we don't need to have a solution to the problem.

This gives us a couple of options:

1) We have an all-or-nothing solution; if you have sensitive data in
your tree, you MUST limit access to that entire tree as per the most
sensitive data in the tree.

2) We have a problem where selective access controls are required for
some subset of the tree, and where the scope of the selective access is
relatively small and manageable by several obvious techniques, which the
WG will evaluate and make recommendations on.

3) We have a problem where selective access controls are required for
some subset of the tree, and the scope of that selective access is very
large, effectively requiring something that looks like a general
solution to the "Internet-scale authentication problem".

I propose that we're closest to #2; we can't quite say "Just use a
private DNS if you have sensitive data", but the access-control problem
is not huge and can be handled using conventional web techniques.

--
dean

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 23 Mar 2010 13:41:02 -0400

That is a discussion for the WG not the BOF .. the issue will center on how
the IANA registry is designed and what the recommendations contained in that
registry are for a particular data object. In the open DNS either encryption
or indirection MAY be warranted in closed network environments it MAY not.

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, March 23, 2010 1:16 PM
To: Richard Shockey; [email-masked]; 'Dean Willis'
Cc: [email-masked]
Subject: RE: [e2md] Issues slides , please comment

We won't get away with hand-waving it I think.  We'll need a solution to get
past IESG, no?

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 23 Mar 2010 13:42:58 -0400

I have a use-case which requires it.  I was writing up a draft for it this morning, but maybe I should just explain it in email to see if it's something you guys would puke all over or not, so I don't waste my time on a draft. :)  You may decide this isn't a valid use-case for E2MD, or DNS to begin with.

So here goes:
Right now, 3 vendors (including my employer) have implemented a DDDS mechanism for storing SIP user credentials.  By "SIP user credentials" I mean the information needed to authenticate a SIP request through an MD5 digest-challenge, namely the hash of user:realm:password, as defined in RFC 3261 and 2617 as "H(A1)".  The general purpose of this is it allows any SIP server which can access the DNS entry for this, to successfully authenticate a SIP Request claiming to come from that E.164.  In our case in particular, we use it to challenge SIP REGISTER and INVITE requests at the edge of the SIP domain, as they come in from SIP UA's.  For example, we get a REGISTER, challenge it, and on the challenge-response we look up the claimed E.164-based AoR and verify its challenge-response used the value in the DNS entry for the hash calculation.

We store them in the clear right now, because the deployments which use them (claim) to have tight control over access to the DNS servers which have 'em.  Obviously that's a tenuous position, and this is highly sensitive data.  We'd like an option to have the entry data encrypted, using a key which all authorized SIP servers have.

-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 23, 2010 1:23 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [e2md] Issues slides , please comment

Of the three documented use cases (i.e. the ones for which drafts exist), only Richard's existing CNAM draft from ENUM contains "personal" information.

As far as I can see these data privacy issues were _not_ concerns when this draft was going through the ENUM group.

Ray

---

From: Dean Willis <[email-masked]>
Date: Tue, 23 Mar 2010 12:51:42 -0500

> or indirection MAY be warranted in closed network environments it MAY not.

But before we can have a WG, we have to know the scope of the WG. That
means saying, in advance, exactly which problems the WG is going to solve.

So for example, deciding in advance whether we are or are not going to
solve the open-DNS-with-sensitive-data problem is something we MUST DO.
We MUST NOT defer that decision to the WG, because without an answer to
that question, the WG will not be formed.

--
dean

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 23 Mar 2010 14:00:13 -0400

And that certainly represents one of the other 25% of the use cases.  

I don’t know what the specific application is in Finland but in the US ..it
is the service that Law Enforcement uses to find the underlying operator for
a TN in order to know where to put the alligator clips. J

IMHO the largest economic impact of E2MD is TCAP/SS7-C7 avoidance in closed
SIP transit networks where PSTN interconnection data is needed.  I want to
see that application preserved and not encumbered with irrelevant and
encumbering requirements that would unquestionably be appropriate and
necessary for use in the open DNS.  

Privacy and Security requirements are clearly driven by the type data
exposed bound to network ( and its security)  the data resides in.

From: Nieminen Klaus [mailto:[email-masked]] 
Sent: Tuesday, March 23, 2010 1:32 PM
To: Richard Shockey; [email-masked]; Dean Willis
Cc: [email-masked]
Subject: VS: [e2md] Issues slides , please comment

Hi folks,

At least in Finland it's a regulatory requirement that operators cooperate
to maintain a free service that describes to which operator the number
belongs to. So at least we have it already available in the Internet:

http://www.siirretytnumerot.fi/
<https://ressu.ficora.fi/exchweb/bin/redir.asp?URL=http://www.siirretytnumer
ot.fi/>  (sry available only in Finnish)

regards,

- Klaus

  _____  

-----Original Message-----

Folks,

d/
--

   Dave Crocker

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 23 Mar 2010 14:07:42 -0400

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Tuesday, March 23, 2010 1:52 PM
To: Richard Shockey
Cc: 'Hadriel Kaplan'; [email-masked]; [email-masked]
Subject: Re: [e2md] Issues slides , please comment

RS> I never suggested we should not address the OPEN DNS with sensitive data
issue. Only that issue is something the WG should do not the BOF. 

I do insist that the CLOSED DNS network issues not be ignored, excluded or
encumbered with useless requirements that have not been needed in the field
up to this time. There is a huge body of experience here that is being
discounted.

--
dean

---

From: Bernie Hoeneisen <[email-masked]>
Date: Tue, 23 Mar 2010 19:15:42 +0100 (CET)

On Tue, 23 Mar 2010, Richard Shockey wrote:

> I don’t know what the specific application is in Finland but in the US

Well, there is slightly more than 25 % outside the U.S... ;-)

However, as a conclusion we can declare, the (Global) Service Provider 
Identifier, has multiple Use Cases in different environments. Thus, the 
creation of an E2MD service for this is prooven to be useful by multiple 
sources.

cheers,
  Bernie

> ..it is the service that Law Enforcement uses to find the underlying 
> operator for a TN in order to know where to put the alligator clips. J
> 
>  
> 
> IMHO the largest economic impact of E2MD is TCAP/SS7-C7 avoidance in closed SIP transit
> networks where PSTN interconnection data is needed.  I want to see that application preserved
> and not encumbered with irrelevant and encumbering requirements that would unquestionably be
> appropriate and necessary for use in the open DNS. 
> 
>  
> 
> Privacy and Security requirements are clearly driven by the type data exposed bound to network
> ( and its security)  the data resides in.
> 
>  
> 
> At least in Finland it's a regulatory requirement that operators cooperate to maintain a free
> service that describes to which operator the number belongs to. So at least we have it already
> available in the Internet:
> 
> http://www.siirretytnumerot.fi/ (sry available only in Finnish)
> 
>  
> 
> regards,
> 
>  
> 
> - Klaus
> 
>  
> 
> 
> ______________________________________________________________________________________________
> 
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 23 Mar 2010 13:24:49 -0500

> up to this time. There is a huge body of experience here that is being

Ok, that sounds like we're coming to a consensus on the proposed WG
scope. This may require a modification to the draft charter to allow for it.

--
Dean

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 23 Mar 2010 11:27:28 -0700

> up to this time. There is a huge body of experience here that is being

There is the question of discussing fine-grained details, versus the question of 
basic problems and usage scope.  The latter needs to be done /before/ 
chartering, so that the chartering is substantive and useful, such as giving the 
working group meaningful focus.

One possibility is that the entire task of the working group is:

    The new wg will extend the set of responses that can be produced for an
    ENUM query [cite ENUM RFCs].

This inherits all of the settled ENUM OA&M and security decisions and merely 
specifies some additional RRs that might show up in a query.

That's a perfectly fine charter semantic and scope, IMO, if it satisfies the 
needs of the effort.

My impression is that it doesn't.  There appears to be interest in discussing 
transfer mechanisms (DNS vs. other) and security issues  (especially 
authorization or not).

Such a discussion could reasonably start with the null hypothesis:

    All transfer and security issues for the new effort are the same as have
    been resolved for ENUM [cite RFCs].

This places the onus for changing scope or functions of the new effort on those 
claiming something different is needed.

But this is a charter-time requirement, not a wg-time requirement.

I don't mean that the transfer or security issues need to be settled, but that 
their basic requirement needs to be agreed to, so that the charter specifies the 
gist of what is need (that is different from ENUM).  Otherwise, it will not be 
clear and settled as to the problems that are going to be worked on.

Absent any of this, the charter needs to make an assertion of which aspects of 
ENUM provide the foundation for the new group (and what parts it doesn't).

The charter already cites ENUM as the foundation.  However it doesn't cite it 
with respect to specifying constraints and assumptions for the new effort.

d/
-- 

   Dave Crocker

---

From: "Nieminen Klaus" <[email-masked]>
Date: Tue, 23 Mar 2010 20:31:30 +0200

> I don't know what the specific application is in Finland but in the US ..it is the service that 
> Law Enforcement uses to find the underlying operator for a TN in order to know where to 
> put the alligator clips. J

The requirement was imposed to enable users to know the call tariff before making the call. Anyway I think that the reason is not really important. My point is that I don't see any real problems in publishing that information.

- Klaus

---

From: Dean Willis <[email-masked]>
Date: Tue, 23 Mar 2010 15:16:48 -0500

Nieminen Klaus wrote:
> ..it is the service that
> The requirement was imposed to enable users to know the call tariff
> before making the call. Anyway I think that the reason is not really
> important. My point is that I don't see any real problems in publishing
> that information.
> 

Well, service providers who make their living selling access to the US'
number-porting database might feel differently. Or they might not,
depending on how they see their business model evolving.

--
dean

---

From: [email-masked]
Date: Tue, 23 Mar 2010 12:21:05 -0800

> depending on how they see their business model evolving.

That's true, but their business models are none of IETF's business.

However devising a standard means of describing that information is.

Ray

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 23 Mar 2010 16:35:19 -0400

> up to this time. There is a huge body of experience here that is being

There is the question of discussing fine-grained details, versus the
question of 
basic problems and usage scope.  The latter needs to be done /before/ 
chartering, so that the chartering is substantive and useful, such as giving
the 
working group meaningful focus.

needs of the effort.

RS> Needless to say I would have been perfectly happy with this scope, with
some extensions, caveats and registry considerations on the use of PII and
NRA related data in public DNS trees and leave it to the WG to sort it out
the mechanisms.

****************

My impression is that it doesn't.  There appears to be interest in
discussing 
transfer mechanisms (DNS vs. other) and security issues  (especially 
authorization or not).

This places the onus for changing scope or functions of the new effort on
those 
claiming something different is needed.

I don't mean that the transfer or security issues need to be settled, but
that 
their basic requirement needs to be agreed to, so that the charter specifies
the 
gist of what is need (that is different from ENUM).  Otherwise, it will not
be 
clear and settled as to the problems that are going to be worked on.

Absent any of this, the charter needs to make an assertion of which aspects
of 
ENUM provide the foundation for the new group (and what parts it doesn't).

The charter already cites ENUM as the foundation.  However it doesn't cite
it 
with respect to specifying constraints and assumptions for the new effort.

RS>  We know what the problem is ..data about phone numbers that cannot be
expressed as a URI. Wasn't that clear?

d/
-- 

   Dave Crocker

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 23 Mar 2010 16:41:46 -0400

I think the comment was in context of "would anyone ever want to keep the data private"?  To which the answer is probably, "yes".
(although LNP routing/queries requires more than just knowing the spid, obviously)
-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 23, 2010 4:21 PM
To: Dean Willis
Cc: [email-masked]
Subject: Re: [e2md] Issues slides , please comment

Ray

---

From: [email-masked]
Date: Tue, 23 Mar 2010 12:43:28 -0800

Rich wrote:

> Needless to say I would have been perfectly happy with this scope, with

+1

> We know what the problem is ..data about phone numbers that cannot be

and another +1

Ray

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 23 Mar 2010 13:45:55 -0700

On 3/23/2010 1:35 PM, Richard Shockey wrote:
> it with respect to specifying constraints and assumptions for the new
> effort.
>

Oh yes, it definitely raises and resolves all relevant questions.  That's why 
this thread is not happening.

Richard, although the charter makes a statement about the kind of data responses 
it seeks to enable, it does not define scope, mechanism or security issues, 
although each of those is of fundamental importance to the effort.

That's what prompted this thread.  And that's why this thread is appropriate to 
have been raised.

d/

-- 

   Dave Crocker