Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpoint centric LCP without giving away the store

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 07:38:14 -0400

Well, there is no place yet.  We'd have to make one.  
Let's first get consensus if that's the approach we want, and then we can
discuss the best way to do it.

It would affect the LCP and -conveyance directly or indirectly, although
there are many ways to carry it from endpoint to the VSP.  

Brian

> -----Original Message-----
> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2007 4:12 AM
> To: Brian Rosen; Hannes Tschofenig
> Cc: [email-masked]; Rosen, Brian; [email-masked]
> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
> doendpoint centric LCP without giving away the store
> 
> Hi Brian
> 
> "The country code is returned with the reference" - was that your
> suggestion...? I might not have all the thread.
> 
> I'm fine with that model - do we have conveyance support for this
> information though? In SIP, where does the country code go? Does the
> client construct a bare bones PIDF-LO?
> 
> Cheers,
> Martin
> 
> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Wednesday, 18 April 2007 6:03 AM
> To: 'Hannes Tschofenig'
> Cc: [email-masked]; Rosen, Brian; [email-masked]
> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
> doendpoint centric LCP without giving away the store
> 
> No, I don't.
> 
> I assume that the LoST server the VSP consults to validate contains the
> same
> URIs that the LoST server used by the access network LIS to determine
> the
> URI.  The endpoint passes a URI to its VSP and claims it's a bona fide
> PSAP
> URI from LoST.  As long as that URI is in the LoST server (directly or
> via a
> referral) that the VSP uses, validation is possible.
> 
> If the attacker can insert bogus data into the global LoST database,
> then we
> couldn't detect it, but that is not threat here.
> 
> The access network and the endpoint can collude all they want, but
> unless
> the LoST server the VSP uses has bad data, it can determine if the PSAP
> URI
> is a genuine PSAP URI.
> 
> No relationship between the VSP and the access network is needed.
> 
> Brian
> 
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:[email-masked]]
> > Sent: Tuesday, April 17, 2007 2:20 AM
> > To: Brian Rosen
> > Cc: Rosen, Brian; [email-masked]; [email-masked]
> > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
> do
> > endpoint centric LCP without giving away the store
> >
> > Hence, it suffers from the same problems as the solution I proposed
> > unless you assume a relationship between the VSP and the ISP/ASP.
> > Do you?
> >
> > Ciao
> > Hannes
> >
> >
> > Brian Rosen wrote:
> > > Back from a weekend of no Internet access and lots of email to
> process:
> > >
> > > The country code is returned from the L7 LCP query when an LbyR is
> > returned.
> > >
> > > The validation is done by the VSP when an emergency call is placed.
> > >
> > > Brian
> > >
> > >
> > >> -----Original Message-----
> > >> From: Hannes Tschofenig [mailto:[email-masked]]
> > >> Sent: Saturday, April 14, 2007 12:02 PM
> > >> To: Rosen, Brian
> > >> Cc: [email-masked]; [email-masked]
> > >> Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do
> > >> endpoint centric LCP without giving away the store
> > >>
> > >> Hi Brian,
> > >>
> > >> ~snip~
> > >>
> > >>> Perhaps we include in the LoST return a country code for a query
> with
> > a
> > >>> geo.  We add a new operation to LoST that takes a service, a
> country
> > >>> code and a PSAP URI and returns yes/no validation ("Yes, that URI
> is a
> > >>> valid URI for that service in that country").
> > >>>
> > >>>
> > >> Please describe when the country code is returned and to whom.
> > >> Who triggers the validation step?
> > >>
> > >> Ciao
> > >> Hannes
> > >>
> > >>
> > >> _______________________________________________
> > >> Geopriv mailing list
> > >> [email-masked]
> > >> https://www1.ietf.org/mailman/listinfo/geopriv
> > >>
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 
> --------------------------------------------------------------------------
> ----------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> --------------------------------------------------------------------------
> ----------------------
> [mf2]

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 08:23:13 -0400

PIDF-LO contains a country code, as does the DHCP civic format and  
thus LLDP-MED. Thus, I'm confused by your statement below.

Henning

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 18 Apr 2007 14:25:33 +0200

I don't see the impact either. 

Particularly with this solution approach nothing needs to be done. 
This is more a deployment consideration. 

> -----Ursprüngliche Nachricht-----
> Von: Henning Schulzrinne [mailto:[email-masked]] 
> Gesendet: Mittwoch, 18. April 2007 14:23
> An: Brian Rosen
> Cc: GEOPRIV; Brian Rosen; ECRIT
> Betreff: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on 
> how todoendpoint centric LCP without giving away the store
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 09:01:06 -0400

Is it appropriate to require an LCP and -conveyance to carry two locations:
for example, a reference and a PIDF containing just a country code?  Would
it be more expedient to define a URI parameter that could be added to the
reference?

Either works, and clearly the former is less work.

What would you rather see:

  INVITE sip:[email-masked] SIP/2.0
...
   Geolocation: <sips:[email-masked]; countrycode=us>
     ;inserted-by=endpoint

or

  INVITE sip:[email-masked] SIP/2.0
...
   Geolocation: <sips:[email-masked]>
     ;inserted-by=endpoint
   Geolocation: <cid:[email-masked]>
     ;inserted-by=endpoint
   Supported: geolocation
   Accept: application/sdp, application/pidf+xml
...
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1

   Content-Type: application/sdp

   ...SDP here

   --boundary1

   Content-Type: application/pkcs7-mime;
      smime-type=enveloped-data; name=smime.p7m
   Content-ID: [email-masked]

$  Content-Type: application/pidf+xml
$
$  <?xml version="1.0" encoding="UTF-8"?>
$     <presence xmlns="urn:ietf:params:xml:ns:pidf"
$         xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
$         xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
$         xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
$         entity="pres:[email-masked]">
$       <tuple id="sg89ae">
$        <timestamp>2007-03-20T14:00:00Z</timestamp>
$        <status>
$         <gp:geopriv>
$           <gp:location-info>
$             <cl:civilAddress>
$               <cl:country>US</cl:country>
$             <cl:civilAddress>
$           </gp:location-info>
$           <gp:usage-rules>
$             <gp:retransmission-allowed>no</gp:retransmission-allowed>
$             <gp:retention-expiry>2007-03-24T18:00:00Z</gp:retention-
$                           expiry>
$             <gp:method>DHCP</gp:method>
$             <gp:provided-by>www.cisco.com</gp:provided-by>
$           </gp:usage-rules>
$         </gp:geopriv>
$        </status>
$       </tuple>
$      </presence>
   --boundary1--

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2007 8:23 AM
> To: Brian Rosen

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 09:08:42 -0400

I think two locations (of different resolution, whether they both be  
V or R, or some combination) is much cleaner and extends to other  
models, such as partial location. We don't want to encode state and  
community name in a URL parameter, for example.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 09:28:49 -0400

Let's keep our eye on the goal, which was to allow validation of a PSAP URI
by a downstream routing element.  You suggested that we may not need it at
all.  We aren't providing two locations at different resolutions, we're
providing a hint to minimize the reverse search space.

While having a community name could further reduce the search space, it's
not clear to me it helps enough to be worth it.  Our simplest solution in
this direction is to not send the country code, and just allow a reverse
search in the LoST database ("flooding").

Having a community name is NOT sufficient to choose a PSAP in every case,
and every case has to work.  If the boundary is irregular, which it is in
some circumstances, you would need street name and house number to know
which PSAP.  That would not be acceptable to an access network who is not
willing to provide location to a VSP (or any other entity except a PSAP).  I
hope we're clear on that point.  So, returning coarse location as an LbyVand
using that in a LoST query is NOT an acceptable alternative to returning an
LbyR that is not dereferenceable by the VSP.

Brian

> Sent: Wednesday, April 18, 2007 9:09 AM
> To: Brian Rosen
> Cc: GEOPRIV; ECRIT

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Apr 2007 15:37:03 +0200

Hi Brian,

> providing a hint to minimize the reverse search space.
PSAP URI validation is not needed when the VSP provides a flat rate 
based charging scheme (since doing fraud with individual calls will not 
be possible).
There might, however, be other things to consider (e.g., QoS 
reservations for preferential treatment etc.) that play a role here.

> search in the LoST database ("flooding").

The brute force version to solve the problem is not "simple" either. If 
a PSAP does not flood its URI then it will get blocked = bad thing.

> LbyR that is not dereferenceable by the VSP.
It is true that the routing based on country level works only if you either
* use an ESRP for the entire country (whereby this ESRP subsequently can 
do more detailed routing based on the location information it obtains 
from the ISP/ASP)
OR
* there is  only a single PSAP  per country.

Ciao
Hannes

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 18 Apr 2007 09:41:06 -0400

> 
> Let's keep our eye on the goal, which was to allow validation 
> of a PSAP URI by a downstream routing element.

Did we decide that the access provider operating an ESRP is not an option?

(facilitates hiding of all location info from the UA)

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 09:52:27 -0400

Okay Hannes, I get that, but:

Are we, or are we not agreeing that SOME VSPs need to validate a proffered
PSAP URI?  Your comment indicates reasons other than charging that may
prompt VSPs to attempt validation.  I assume you are not arguing we don't
need the capability.

I agree that "flooding" would be a requirement.  The actual requirement is
for a reverse lookup.  Flooding is how you meet the requirement.

Are we, or are we not agreeing that we can't force ESRP per country or
single PSAP per country?  If we agree that irregular boundaries per ESRP are
possible, then coarse location is insufficient for a LoST query and we need
some other solution.

Brian

> Sent: Wednesday, April 18, 2007 9:37 AM
> To: Brian Rosen
> Cc: 'Henning Schulzrinne'; 'GEOPRIV'; 'ECRIT'

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 09:55:40 -0400

I think FORCING an access provider to deploy an ESRP when they don't agree
to give location to endpoints or arbitrary VSPs is not an option.

I also think having the access network as an active element in the call
chain is very unattractive, especially when proxy routing has the VSP also
in the call chain.

I'm okay with allowing it.  I think the PSAPs would have an opinion on its
use.

Brian

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2007 9:41 AM
> To: 'Brian Rosen'
> Cc: 'ECRIT'
> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how
> todoendpoint centric LCP without giving away the store
> 
> 
> 
> >

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 10:57:03 -0400

My concern is that we're engineering in the dark. Currently, we have  
exactly one carrier that has provided a semblance of design  
requirements. My translation of these requirements is "I don't want  
to build new infrastructure (since nobody is going to pay me for  
it)". However, all the proposals so far involve significant new  
infrastructure, while increasing complexity in the end system.

The complexity I'm concerned about is not so much protocol  
complexity, although that's an issue, but rather having a multitude  
of code paths that an end system has to try. Each of these has to be  
tested and debugged; our experience with that in other SIP features  
has not been good. The complexity takes the form of lots of decisions  
of the

"If this configuration option is set, but the other one is not, and  
that request returns a foo rather than a bar, do this, but otherwise  
wait for 30 seconds and try something else"

kind. Many of these will never be exercised - until a customer takes  
the device to place where it hasn't been before. This is why I'm  
insisting on having a very simple logic so that a device always does  
the same thing, even if the environment changes. (Requirements for  
data synchronization and coordination is another common source of  
failures.)

The ESRP solution again has this drawback, as it needs to be  
discovered. It can't be discovered via LoST, since it would only be  
used for a specific access provider, not universally. Thus, you now  
need to have an explicit configuration option for ESRP, adding  
another diamond to the flow chart.  You then have to answer questions  
such as: Should I use the ESRP even if I have additional location  
information? Is the ESRP only available to subscribers? (This could  
happen for a WiFi device using a DT-provided DSL access, but with  
built-in GPS.) Is the ESRP serving all emergency services, or is the  
gas leak service on a different one or not reachable at all?

The same is true for LbyR that are only resolvable by the PSAP. The  
UA can't know that, so it means having to branch on failure - yet  
another test case that's unlikely to be exercised by developers if  
this mode of operation only occurs in a few access networks.

Thus, I'm advocating a solution that follows the simple logic flow  
for what we hope to be the common case, i.e., where end systems  
obtain location:

- get location, even if incomplete; if an LbyR, it has to resolve to  
something useful, even if authorized users (PSAPs) get more detailed  
information

- get a URL from any LoST server, using that exact information,  
operated by any number of organizations

- send the request

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 11:09:04 -0400

> possible, then coarse location is insufficient for a LoST query and  

That's not true. It just means that coarse location can't be used  
everywhere. That's a very different statement. I'd rather have 5% of  
the population get their street address than have to add complexity  
to 100% of the UAs, with additional failure modes.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 11:24:45 -0400

I understand your point of view, and I'm sympathetic to it.

I just don't see how to do it simpler and meet the constraints.  You insist
that we prove there is a requirement to not reveal location to endpoints
and/or VSPs.  I'll work on that, but please, I really, truly think it's a
significant barrier to deployment of the entire mechanism.  I think Martin
is right about how it will evolve, but I've heard the problem from quite a
few people now.  Enough so that I've given up fighting it.  I don't like it,
but it's a piece of reality to me now.

You always have to run the LCP first.  I think if it returns the LoST
results, stop, otherwise query LoST is indeed a complication, but a simple
one.  If we can get flooding to work so VSP validation of PSAP URI takes no
client effort, maybe that's what we should do.  Fixing LoST so it can take
what it gets from the LCP and work is another viable path, although I don't
see how to do it cleanly yet.  Richard and Andy are trying, but it doesn't
work for me yet.  If it does, that's a complication, but acceptable to me.

I do think we could help ourselves by listing the requirements here:

1. An LbyR may not be dereferenceable by the endpoint, yet it must be able
to get LoST results
2. A PSAP URI may not be valid (because of theft of service), and a VSP must
be able to validate it. The VSP may not be able to dereference the LbyR
either
3. We cannot assume ESRP per country/state/city; boundaries may be irregular
4. We cannot assume the access network or the VSP can control which LoST
server is used

Others?

Brian

> Sent: Wednesday, April 18, 2007 10:57 AM
> To: Brian Rosen
> Cc: 'Marc Linsner'; 'ECRIT'
> Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 11:33:20 -0400

I'm not sure I understand what you are saying.

I'll agree that coarse location may work some times.  I wouldn't care to
speculate how often it does or doesn't.  I don't think it matters.  It
doesn't sometimes.  Does that mean we should misroute in those cases where
you only get coarse location, and you have an irregular boundary that
"misses"?  I suspect that would not fly with the access networks that have
the hiding problem.  You are giving them an unacceptable choice: give up
accurate location to the endpoint or be responsible for misroute.  That may
meet your notion of endpoint simplicity, but it won't be deployed I think.

You also seem to be willing to accept that the client will have two
locations to deal with: coarse LbyV and fine LbyR.  Not a complication I
would want to have to deal with given my alternative.

Brian

> Sent: Wednesday, April 18, 2007 11:09 AM
> To: Brian Rosen
> Cc: 'Hannes Tschofenig'; 'GEOPRIV'; 'ECRIT'

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 11:50:25 -0400

> results, stop, otherwise query LoST is indeed a complication, but a  

Like others, I disagree with the assumption of combining LCP and LoST  
results.

> 1. An LbyR may not be dereferenceable by the endpoint, yet it must  

No, this yields another failure mode, since the UA can't know that an  
LbyR is meant only for somebody else. An LbyR provided to the UA MUST  
always return some information, even if an authenticated user gets  
more and even if that public information is only a country code.

> be able to validate it. The VSP may not be able to dereference the  

That's a separate discussion. I think it would be helpful to keep it  
separate, as the location hiding stuff is messy enough as is. A VSP  
would need this with or without location hiding. I agree with the  
second sentence, but it is not connected to the problem in the first  
part of the sentence.

> 3. We cannot assume ESRP per country/state/city; boundaries may be  

However, for some deployment cases, this is viable. For example, for  
DT, this might actually be a good solution, since it would allow them  
to build a cheap location infrastructure that simply returns the city  
of the DSLAM, given that this alignment seems to exist in the country  
they provide service to. This requires no interaction with the OSS  
(which seems to be the cause of the infrastructure expense), as the  
user identifier in RADIUS contains that information already.

> 4. We cannot assume the access network or the VSP can control which  

Agreed.

> Others?

5. User agents cannot require additional configuration to discover  
which particular environment (hiding or no hiding) they find  
themselves in. UAs should not have to deduce the desired behavior by  
having other operations, such as LbyR resolutions, fail, as failures  
can take a long time.

6. User agents need to be able to determine PSAP/ESRP URLs prior to  
the call.

7. UAs need to be able to discover at least their country code so  
that they can obtain the dial string ahead of the emergency call via  
LoST.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 12:55:34 -0400

> speculate how often it does or doesn't.  I don't think it matters.  It

This seems to be very country-specific. Thus, in some countries, this  
will be quite viable, in others, less so.

For DT, for example, you could have a very simple architecture:

-  Use normal LCP, returning Gemeinde (city/town), Bundesstaat  
(state) and country (DE). This is sufficient for determining the PSAP  
and requires zero interaction with the OSS.

- Return an LbyR that is similar to what is used today as an  
identifier (phone number?), which resolves to the rough information  
above.

> "misses"?  I suspect that would not fly with the access networks  

Definitely not. It would be the responsibility of the ISP to deliver  
location information of sufficient granularity to prevent misroutes.  
In some small number of corner cases (typically, the one boundary  
street between PSAP regions), this would mean delivering a street  
address or a geo region. This is easy for the ISP to determine - they  
just query LoST and get the coverage regions.

If you don't want to do this, just return the *geo* boundary of the  
PSAP to the customer as location information via LCP, just like you'd  
return an imprecise mapping from a wireless system, as a polygon. By  
our mapping rules, LoST computes the centroid (trivial) and returns  
the PSAP URL. I think this is somewhat similar to what Andy is  
proposing, but requires no new effort.

This reveals zero additional information to the client, beyond the  
coverage region of the PSAP, but the UA behavior is exactly the same  
as in the no-hiding case.

> meet your notion of endpoint simplicity, but it won't be deployed I  

I don't see this as the alternative. All I require is that ISP give  
up a tiny fraction of its location information in some corner cases.  
In most communities, all of the customers will only get city-level or  
county-level information, which corresponds to what their phone  
number already tells them.

I think this is a fair bargain. I'd like to hear good reasons from  
real carriers as to why this is not acceptable. Shadow boxing,  
without talking to real customers, seems likely to lead us to design  
something that doesn't actually help. (Just as I believe that the  
whole architecture proposed doesn't actually address the don't-spend- 
money objective of DT.)

> would want to have to deal with given my alternative.

Not really. I advocate returning a single LbyR, which resolves to  
minimal information sufficient for routing for the general public  
and, with PSAP authentication, to precise location information for  
dispatch.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 14:02:07 -0400

I can live with this way out of the mess.

I rather like the idea of returning the PSAP service boundary polygon on the
endpoint's (or VSP's) dereference.  The latter (as well as coarse location
when it works) also fixes the validation problem; the VSP dereferences, gets
the polygon, queries LoST with it, and gets the PSAP URI. 

I agree that in lots of cases, a very coarse location return from the LbyR
is sufficient, and access networks ought to be able to take advantage of it
when it happens.

I guess we need to hear from carriers.  I think you already raised the point
that in most cases, an IP address yields city level location, albeit VPNs
often obscure that.

And while you brought it up, I do think a very nice user part of a location
reference is a hashed telephone number.  Most of the DSL networks, for
example, do have telephone numbers which actually are easy to turn into
service address in the existing databases.  I'd prefer it be hashed so that
we don't reveal extra user information.  I particularly think that idea will
be quite useful in dealing with legacy wireline systems, which already
associate TN with location.  Adding a (hash of) TN with a provisioned LIS
domain on a Geolocation header in, or near a PSTN to SIP gateway would be a
very painless way to get location from a legacy wireline system into a next
generation emergency call system.

Brian

> Sent: Wednesday, April 18, 2007 12:56 PM
> To: Brian Rosen

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 18 Apr 2007 14:37:48 -0400

Brian said: 
> And while you brought it up, I do think a very nice user part of a
location reference is a hashed telephone number.  Most of the DSL
networks, for example, do have telephone numbers which actually are easy
to turn into service address in the existing databases.  I'd prefer it
be hashed so that we don't reveal extra user information.  I
particularly think that idea will be quite useful in dealing with legacy
wireline systems, which already associate TN with location.  Adding a
(hash of) TN with a provisioned LIS domain on a Geolocation header in,
or near a PSTN to SIP gateway would be a very painless way to get
location from a legacy wireline system into a next generation emergency
call system. <

Actually, given requirements for "naked" DSL, without an underlying POTS
phone number, we're moving to "Circuit ID". 
Barbara

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 14:48:57 -0400

That's fine, hash the circuit ID and make that the user part of the location
reference.

Of course, this is NOT a requirement; it's just one way to make the
implementation simpler.  It's totally within the access provider's domain,
and only it cares what the URI looks like, thus it's not subject to
standardization except insofar as it might optimize intra-carrier system
purchases (e.g. if there was an agreement on how to do it, the OSS guys and
the LIS guys may be able to make their sub-systems interoperate).

Brian

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2007 2:38 PM
> To: Brian Rosen; Henning Schulzrinne
> Cc: GEOPRIV; ECRIT
> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged material. Any review, retransmission, dissemination or other
> use of, or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient is prohibited. If
> you received this in error, please contact the sender and delete the
> material from all computers. GA621

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 15:01:07 -0400

Just out of curiosity, what does a circuit ID look like? Is that the  
NAS identifier used in RADIUS or where is it visible?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 25 Apr 2007 09:37:27 +0100

> NAS identifier used in RADIUS or where is it visible?

In the UK it's not currently standardised, though we're looking at it. I
would *expect* it to end up something like BT-EA12345678 or 001-EA12345678
where the first part identifies the circuit owner (either a short name or a
CUPID) and the second half is decided by the provider; BT appear to use
a two letter region code followed by an 8 digit number).

>> phone number, we're moving to "Circuit ID".

That's not the only scenario - the UK is looking at an arrangement whereby
one telco (Openreach, part of BT) provides the circuit and another telco
provides the call server and thus the number; Openreach and BT will have no
visibility of the number - if any - allocated to the line.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 25 Apr 2007 11:28:19 -0400

Circuit IDs have nothing to do with RADIUS, that I'm aware of.
"Circuit ID" format is defined by whatever system an access company uses
to manage its inventory of circuits. The most common such system in the
US is TIRKS(R), which is now developed by Telcordia. It was initially
developed by AT&T Bell Labs in the late 1970's. Fortunately, it has
managed to evolve a bit since then. Most of the baby Bells continue to
use it, I think.
There's a really short Wikipedia description of TIRKS at
http://en.wikipedia.org/wiki/TIRKS
In short, a Circuit ID uniquely identifies a circuit within an access
provider's operations systems. Many different types of circuits exist
(POTS, T1, DS3, SONET, etc.). Different types use different formats.
Barbara

-----Original Message-----
From: Clive D.W. Feather [mailto:[email-masked]] 
Sent: Wednesday, April 25, 2007 4:37 AM
To: Henning Schulzrinne
Cc: Stark, Barbara; GEOPRIV; ECRIT
Subject: Re: [Ecrit] Circuit ID

In the UK it's not currently standardised, though we're looking at it. I
would *expect* it to end up something like BT-EA12345678 or
001-EA12345678 where the first part identifies the circuit owner (either
a short name or a
CUPID) and the second half is decided by the provider; BT appear to use
a two letter region code followed by an 8 digit number).

>> Actually, given requirements for "naked" DSL, without an underlying 
>> POTS phone number, we're moving to "Circuit ID".

That's not the only scenario - the UK is looking at an arrangement
whereby one telco (Openreach, part of BT) provides the circuit and
another telco provides the call server and thus the number; Openreach
and BT will have no visibility of the number - if any - allocated to the
line.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495
6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051
9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973
377646
THUS plc            |                            |

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 26 Apr 2007 11:20:15 -0400

It turns out I was wrong about the Circuit ID and RADIUS. I just can't
seem to keep up with the architecture changes going on.
Yes, in newer equipment, the Access Node (DSLAM) adds the Circuit ID to
both DHCP and PPP protocols. This is copied into the message sent to
RADIUS.
Barbara 

-----Original Message-----
From: Clive D.W. Feather [mailto:[email-masked]]
Sent: Wednesday, April 25, 2007 4:37 AM
To: Henning Schulzrinne
Cc: Stark, Barbara; GEOPRIV; ECRIT
Subject: Re: [Ecrit] Circuit ID

*****

material from all computers. GA623