Subject: [e2md] We need another acronym besides SPID for service provider ID

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

since there isa major collision with the ISDN acronym Service Profile
ID, aka SPID. This one tripped me up at first.

see:

http://en.wikipedia.org/wiki/SPID

--
Dean

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Tue, 23 Mar 2010 17:09:27 -0400

Two thoughts. 
1. Do we really need to worry about this? As in the trademark issues,
how likely is it that anyone will be confused given the different
contexts. In recent ATIS PTSC contributions it's been SPID and, if
anyone should be concerned, they should.
2. If it really is a problem, the i3 Forum has been using "SPN." (They
like SP number for some reason).

Cheers,

Penn Pfautz
AT&T Access Management
+1-732-420-4962

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dean Willis
Sent: Tuesday, March 23, 2010 4:54 PM
To: E.164 To MetaData BOF discussion list
Subject: [e2md] We need another acronym besides SPID for service
provider ID

see:

--
Dean
_______________________________________________
e2md mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/e2md

---

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

> anyone should be concerned, they should.

Well, it confused me. Richard said we needed a SPID, so I googled SPID
and got pointed at the ISDN reference, which I then recalled from my
ISDN days. Now, I may be a crufty old bird, but I'm not the only one in
the flock.

> like SP number for some reason).

I do like that better, actually. The Free Dictionary lists no major
collisions in telecom/network outside of Microsoft's "Service Principal
Name", which is a pretty similar functionality.

--
dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 23 Mar 2010 18:51:44 -0400

Oh great, that would be pronounced "SPiN".
Everyone calls them "SPID" in the LNP and Enum market, afaict.

-hadriel

> Sent: Tuesday, March 23, 2010 5:21 PM
> To: PFAUTZ, PENN L (ATTCORP)
> Cc: E.164 To MetaData BOF discussion list
> Subject: Re: [e2md] We need another acronym besides SPID for service
> provider ID
>

---

From: Adam Uzelac <[email-masked]>
Date: Tue, 23 Mar 2010 16:11:13 -0700

As I sit here in mmusic and just read TCAP up on the SDP Negotiation slides,
I really don't think anyone in the room starting thinking
INAP<http://en.wikipedia.org/wiki/INAP>TCAP. IMHO - I don't see the
need for anything new here.

Adam

---

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

In the US its SPID but we would also have to reserve the ITU type currently
under development as well Service Provider Network Identifier (SPN)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
Willis

Well, it confused me. Richard said we needed a SPID, so I googled SPID
and got pointed at the ISDN reference, which I then recalled from my
ISDN days. Now, I may be a crufty old bird, but I'm not the only one in
the flock. > 2. If it really is a problem, the i3 Forum has been using
"SPN." (They

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 23 Mar 2010 21:43:27 -0400

> under development as well Service Provider Network Identifier (SPN)

What ITU-T type currently under development?

The ITU-T's IdM group recommended that the IETF's
Enterprise Numbers be used for a SPID, and that
consideration be given to binding them to EVcerts.

--tony

---

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

It's my understanding that SG2 has a separate task underway that Gary
Richenaker is leading on the Global SPID. The IETF DRINKS WG received a
formal liaison from ITU-T requesting that the DRINKS protocol accommodate
such as identifier. 

It is my working assumption that E2MD should explicit accommodate this
request as well.

https://datatracker.ietf.org/liaison/518/

-----Original Message-----
From: Tony Rutkowski [mailto:[email-masked]] 
Sent: Tuesday, March 23, 2010 9:43 PM
To: Richard Shockey
Cc: 'Dean Willis'; 'PFAUTZ, PENN L (ATTCORP)'; 'E.164 To MetaData BOF
discussion list'

--tony

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 23 Mar 2010 22:09:02 -0400

Hi Richard,
> formal liaison from ITU-T requesting that the DRINKS protocol accommodate
Actually NeuStar made the proposal out of the blue.
Gary as  you know works for NeuStar.  The proposal
had many significant flaws and received no apparent
support at the meeting (or anywhere else).  Other
ITU-T Study Groups had suggested that IETF
Enterprise Numbers be used as they were the
predominant SPID in use, but needed a better
trust mechanism.  A SG2 correspondence group
was formed to further consider it, but thus
far there has been no activity.  I think you can
consider the effort dead.

--tony

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 24 Mar 2010 12:17:51 -0400

Well from our perspective either approach would work fine so long as the
appropriate IETU SG's can provide us clarity when we get around to defining
the field. Your help in this matter would be much appreciated.

-----Original Message-----
From: Tony Rutkowski [mailto:[email-masked]] 
Sent: Tuesday, March 23, 2010 10:09 PM
To: Richard Shockey
Cc: 'Dean Willis'; 'PFAUTZ, PENN L (ATTCORP)'; 'E.164 To MetaData BOF
discussion list'

Hi Richard,

--tony

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 24 Mar 2010 12:49:30 -0400

> the field. Your help in this matter would be much appreciated.

Sure.

There are three Study Groups in play.  That doesn't help
on the political front.  SG13 (Future Networks/NGNs) has
specified a SPID requirement but not come up with anything
definitive.  SG17 (Security/IdM/OIDs) has settled on provider
OIDs, including especially IANA's well known and very
significantly used implementations under the name
Enterprise Numbers.  OIDs are IMHO the logical way
to go because they have been used for this purpose
for the past 25 years for all kinds of networks/apps
which have grown dramatically in the past few years
and there are no layer 7+ problems.  At last count there
were something close to 40k of them parceled out.

Enterprise OIDs are also being bound to EVcerts to
enhance the trust, and if the OID Resolver standard
gets adopted next month, the trust would be further
enhanced via an ENUM-like query process.  So this
is all very synergistic with e2md.  You could query,
for example, the Enterprise Number to get ancillary
provider identifiers and information.

SG2 is layer 8+ territory.  The new proposed SPID
seems like a non-starter for the reasons described in
the attached slides.

Bottom line: Use enterprise OIDs

--tony

---

From: <[email-masked]>
Date: Wed, 24 Mar 2010 17:58:45 +0100

> The proposal had many significant flaws and received 
> no apparent support at the meeting. 

FWIW I don't think this is an accurate reflection of the SPN 
discussion that SG2/Q1 had at the last meeting. It was more 
a problem of people having different use cases in mind, so 
the participants were more comfortable working on requirements 
and use cases for such an identification scheme first, 
rather than defining assignment criteria point blank. 

Without prejudging the outcome of that discussion.

Regards,

Philippe Fouquart
SG2/Q1 Ass. Rapporteur

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tony Rutkowski
Sent: Wednesday, March 24, 2010 3:09 AM
To: Richard Shockey
Cc: 'E.164 To MetaData BOF discussion list'
Subject: Re: [e2md] We need another acronym besides SPID forservice
provider ID

Hi Richard,
> Richenaker is leading on the Global SPID. The IETF DRINKS WG received 
> a formal liaison from ITU-T requesting that the DRINKS protocol 
> accommodate such as identifier.
>    
Actually NeuStar made the proposal out of the blue.
Gary as  you know works for NeuStar.  The proposal had many significant
flaws and received no apparent support at the meeting (or anywhere
else).  Other ITU-T Study Groups had suggested that IETF Enterprise
Numbers be used as they were the predominant SPID in use, but needed a
better trust mechanism.  A SG2 correspondence group was formed to
further consider it, but thus far there has been no activity.  I think
you can consider the effort dead.

--tony

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 24 Mar 2010 14:10:01 -0400

As I Mentioned to Tony earlier the sooner we have clarity from the ITU on
this issue the better. This class of data is under VERY VERY active
discussions in the IETF not just in E2MD but also in DRINKS where a
discussion of how to provision this class of data was under active
discussion this morning. IMHO there is very very strong interest in
deploying some form of SPN.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, March 24, 2010 12:59 PM
To: [email-masked]
Subject: Re: [e2md] We need another acronym besides SPID forservice provider
ID

Regards,

Philippe Fouquart
SG2/Q1 Ass. Rapporteur

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

Hi Richard,

--tony

*********************************
This message and any attachments (the "message") are confidential and
intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed
or falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender.
********************************

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 24 Mar 2010 14:22:32 -0400

> deploying some form of SPN.

Given the large number of VoIP, SNMP, PKI and other
standards that use Enterprise IDs today - 40,000 of them
worldwide -  can't one argue it has been deployed?!

It seems the industry and standards bodies have
collectively decided this with their feet.  What
number do you have to reach to declare deployment? :-)

Even if hypothetically some study group in ITU-T or
or somewhere else decided on using some new SPN,
how many years would that take, and who would use it?

--tony