Subject: Re: [drinks] [e2md] Problem statement, Requirements and Use Cases

From: "Cartwright, Kenneth" <[email-masked]>
Date: Wed, 19 May 2010 14:39:26 -0400

As Penn wisely points out, this can be discussed in detail in the appropriate forum at the appropriate time, however, ....

The ITUs OID looks like a good option.  It seems to meet the following requirements/advantages:

1) It already exists; no need to invent and debate a new scheme, approach, documentation set, etc.
2) It is hierarchical; organizations can optionally create sub-OIDs (or sub trees) under their main OID if they need to.
3) The sub-identifiers under the main identifier can be opaque; they need not have a known, or the same known, meaning to all parties that may use/see them
4) There is an existing urn that _might_ be useful "urn:oid"
5) If the set of existing OIDs already allocated under one of the existing OID trees (e.g. 1.3.6.1.4) are not appropriate then it seems that an organization (e.g. IANA) can be formally delegated the responsibility of dolling out (similar to the way that it doles out Enterprise Numbers) the OIDs under a new OID tree.  IOW, the OID tree it centrally managed, but the management of sub-trees can be delegated.
6) They are cleanly parseable by a computer or a human; their form is standardized and well structured.

A disadvantage, however, is that ITU OIDs can theoretically be fairly long (in contrast to the 4 characters that comprise a north american OCN or SPID, or the handful of digits that comprise the IANA Enterprise Number).  But it is not clear to me whether in practice, given our use case, if they will ever be as long as they can theoretically be.  The spec for our usage would just need to address this point.

http://www.itu.int/ITU-T/asn1/uuid.html
http://www.oid-info.com/#oid

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Rutkowski
Sent: Wednesday, May 19, 2010 11:52 AM
To: PFAUTZ, PENN L (ATTCORP)
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Problem statement, Requirements and Use Cases

On 5/19/2010 11:03 AM, PFAUTZ, PENN L (ATTCORP) wrote:
> Use RFC 3761 technology provide for the Carrier of Record for an E.164
> number (as defined in RFC 5067) to publish the mapping of
> that E.164 to a globally defined identifier, specifically an IANA
> Enterprise Number as defined in RFC 2578.
>

Hi Penn,

Good choice.  However, the text needs tweaking to read:

   Use RFC 3761 technology to provide for the Carrier of
   Record for an E.164 number (as defined in RFC 5067) to
   publish the mapping of that E.164 number using an assigned
   Carrier of Record Object Identifier (OID)) such as an IANA
   Enterprise Number as defined in RFC 2578.  Ref. Rec.
   ITU-T Recs. X.660 and X.680.

The changes clarify what identifier is being specified and
includes reference to the authoritative OID standard.  It
also allows for the possibility of using other assigned OIDs
for a Carrier of Record.  Although more than 35,000 Enterprise
Numbers have been registered with IANA, there are many
carriers who have OIDs that were registered with national
authorities for Carrier of Record purposes.  As long as there
is a valid, globally unique OID, some flexibility should exist.

For example, ATT has the OID 1.3.6.1.4.74 from IANA's
OID block, but it also has 0.7.7223 that it uses for some
services in Argentina.

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

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 19 May 2010 15:32:28 -0400

Hi Ken,

Just to clarify.
> 5) If the set of existing OIDs already allocated under one of the existing OID trees (e.g. 1.3.6.1.4) are not appropriate then it seems that an organization (e.g. IANA) can be formally delegated th…

This has recently been done for some other namespaces, e.g,
for object tags (2.27), telebiometrics (2.42), cybersecurity
(2.48), and alerting (2.29).  You can peruse the tree at
http://www.oid-info.com/cgi-bin/display?tree=2

The flip side is that a lot of carriers and enterprises exist
in the arcs 0.3 and 1.3.6.1.4 and there are a couple decades
of extensive OID uses, e.g., for SNMP and PKI certs, and
any structured ontology for a new arc would likely include
at least a geographic layer using a 3 number country code
which gets pretty close to the existing Enterprise Number
number count.

> A disadvantage, however, is that ITU OIDs can theoretically be fairly long (in contrast to the 4 characters that comprise a north american OCN or SPID, or the handful of digits that comprise the IANA Enterprise Number).  But it is not clear to me whether in

What is called an OCN in the North America is known as
an ITU Carrier Code worldwide, and created pursuant to ITU-T Rec.
M.1400.  It's a six character alphanumeric code.  See Annex E.
https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-M.1400-200607-I!!PDF-E&type=items

Another advantage of OIDs includes their widespread
inclusion in X.509 digital certificates.

--tony

---

From: Sumanth Channabasappa <[email-masked]>
Date: Wed, 19 May 2010 13:44:44 -0600

When we speak about OIDs here, we are speaking of OIDs formed via the IANA Enterprise Numbers, correct (1.3.6.1.4...)? If so, do we need an extra string for all enterprises (1.3...) or can we just use the enterprise number? And if we want a hierarchy, it can always be constructed underneath the IANA Enterprise number, no?

- S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cartwright, Kenneth
Sent: Wednesday, May 19, 2010 12:39 PM
To: [email-masked]; PFAUTZ, PENN L (ATTCORP)
Cc: [email-masked]; E.164 To MetaData BOF discussion list
Subject: Re: [drinks] [e2md] Problem statement, Requirements and Use Cases

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Rutkowski
Sent: Wednesday, May 19, 2010 11:52 AM
To: PFAUTZ, PENN L (ATTCORP)
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Problem statement, Requirements and Use Cases

On 5/19/2010 11:03 AM, PFAUTZ, PENN L (ATTCORP) wrote:
> number (as defined in RFC 5067) to publish the mapping of that E.164 
> to a globally defined identifier, specifically an IANA Enterprise 
> Number as defined in RFC 2578.
>

Hi Penn,

The changes clarify what identifier is being specified and includes reference to the authoritative OID standard.  It also allows for the possibility of using other assigned OIDs for a Carrier of Record.  Although more than 35,000 Enterprise Numbers have been registered with IANA, there are many carriers who have OIDs that were registered with national authorities for Carrier of Record purposes.  As long as there is a valid, globally unique OID, some flexibility should exist.

For example, ATT has the OID 1.3.6.1.4.74 from IANA's OID block, but it also has 0.7.7223 that it uses for some services in Argentina.

best,
tony

This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

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

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Wed, 19 May 2010 15:53:44 -0400

Aye, that's the question! I know of at least a couple of bodies looking
for SPN that would just like to use the terminal element - not the rest
of the OID string. Whether that ultimately makes sense or the overhead
of using the whole thing proves in I don't know.
One could even imagine different local conventions.  

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

-----Original Message-----
From: Sumanth Channabasappa [mailto:[email-masked]] 
Sent: Wednesday, May 19, 2010 3:45 PM
To: Cartwright, Kenneth; [email-masked]; PFAUTZ, PENN L
(ATTCORP)
Cc: [email-masked]; E.164 To MetaData BOF discussion list
Subject: RE: [e2md] Problem statement, Requirements and Use Cases

When we speak about OIDs here, we are speaking of OIDs formed via the
IANA Enterprise Numbers, correct (1.3.6.1.4...)? If so, do we need an
extra string for all enterprises (1.3...) or can we just use the
enterprise number? And if we want a hierarchy, it can always be
constructed underneath the IANA Enterprise number, no?

- S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Cartwright, Kenneth
Sent: Wednesday, May 19, 2010 12:39 PM
To: [email-masked]; PFAUTZ, PENN L (ATTCORP)
Cc: [email-masked]; E.164 To MetaData BOF discussion list
Subject: Re: [drinks] [e2md] Problem statement, Requirements and Use
Cases

As Penn wisely points out, this can be discussed in detail in the
appropriate forum at the appropriate time, however, ....

The ITUs OID looks like a good option.  It seems to meet the following
requirements/advantages:

1) It already exists; no need to invent and debate a new scheme,
approach, documentation set, etc.
2) It is hierarchical; organizations can optionally create sub-OIDs (or
sub trees) under their main OID if they need to.
3) The sub-identifiers under the main identifier can be opaque; they
need not have a known, or the same known, meaning to all parties that
may use/see them
4) There is an existing urn that _might_ be useful "urn:oid"
5) If the set of existing OIDs already allocated under one of the
existing OID trees (e.g. 1.3.6.1.4) are not appropriate then it seems
that an organization (e.g. IANA) can be formally delegated the
responsibility of dolling out (similar to the way that it doles out
Enterprise Numbers) the OIDs under a new OID tree.  IOW, the OID tree it
centrally managed, but the management of sub-trees can be delegated.
6) They are cleanly parseable by a computer or a human; their form is
standardized and well structured.

A disadvantage, however, is that ITU OIDs can theoretically be fairly
long (in contrast to the 4 characters that comprise a north american OCN
or SPID, or the handful of digits that comprise the IANA Enterprise
Number).  But it is not clear to me whether in practice, given our use
case, if they will ever be as long as they can theoretically be.  The
spec for our usage would just need to address this point.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tony Rutkowski

Hi Penn,

The changes clarify what identifier is being specified and includes
reference to the authoritative OID standard.  It also allows for the
possibility of using other assigned OIDs for a Carrier of Record.
Although more than 35,000 Enterprise Numbers have been registered with
IANA, there are many carriers who have OIDs that were registered with
national authorities for Carrier of Record purposes.  As long as there
is a valid, globally unique OID, some flexibility should exist.

For example, ATT has the OID 1.3.6.1.4.74 from IANA's OID block, but it
also has 0.7.7223 that it uses for some services in Argentina.

best,
tony

This e-mail message is for the sole use of the intended recipient(s)and
may contain confidential and privileged information of Transaction
Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply e-mail and destroy all copies of the original message.

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 19 May 2010 16:10:46 -0400

> When we speak about OIDs here, we are speaking of OIDs formed via the IANA Enterprise Numbers, correct (1.3.6.1.4...)? If so, do we need an extra string for all enterprises (1.3...) or can we just…

You could do this.  However, you lose the ability to have other
SPID OID constructs, including those with localizations.
Different countries and carriers have chosen different
OID arcs they are using.  Like it or not, E.164 numbers
are under the control of sovereign States and provider
assignees, and they might just want to specify and
control their own namespaces for Carriers of Record.

It seems wise to provide that latitude for any spec
you are devising.

--tony

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 19 May 2010 21:15:18 -0400

Well .. as far as I'm concerned the discussion of what is the namespace is
charming but ultimately another discussion. What is important is the
definition of the use case and why opaque carrier identification
methodologies is important (vs edge URI identification) and I'd like to call
for volunteers to help me or someone to write this up as a ID.  There is no
possible doubt that this is important to the global telecommunications
industry and IMHO is principally utilized principally in
private-carrier-infrastructure ENUM instantiations. 

Not to say that, by some for form of indirection, this could live in
e164.arpa but either way it makes sense. It's the right thing to do and the
timing is right now.

-----Original Message-----
Sumanth Channabasappa
To: Cartwright, Kenneth; [email-masked]; PFAUTZ, PENN L (ATTCORP)

When we speak about OIDs here, we are speaking of OIDs formed via the IANA
Enterprise Numbers, correct (1.3.6.1.4...)? If so, do we need an extra
string for all enterprises (1.3...) or can we just use the enterprise
number? And if we want a hierarchy, it can always be constructed underneath
the IANA Enterprise number, no?

- S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cartwright, Kenneth

1) It already exists; no need to invent and debate a new scheme, approach,
documentation set, etc.
2) It is hierarchical; organizations can optionally create sub-OIDs (or sub
trees) under their main OID if they need to.
3) The sub-identifiers under the main identifier can be opaque; they need
not have a known, or the same known, meaning to all parties that may use/see
them
4) There is an existing urn that _might_ be useful "urn:oid"
5) If the set of existing OIDs already allocated under one of the existing
OID trees (e.g. 1.3.6.1.4) are not appropriate then it seems that an
organization (e.g. IANA) can be formally delegated the responsibility of
dolling out (similar to the way that it doles out Enterprise Numbers) the
OIDs under a new OID tree.  IOW, the OID tree it centrally managed, but the
management of sub-trees can be delegated.
6) They are cleanly parseable by a computer or a human; their form is
standardized and well structured.

A disadvantage, however, is that ITU OIDs can theoretically be fairly long
(in contrast to the 4 characters that comprise a north american OCN or SPID,
or the handful of digits that comprise the IANA Enterprise Number).  But it
is not clear to me whether in practice, given our use case, if they will
ever be as long as they can theoretically be.  The spec for our usage would
just need to address this point.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony
Rutkowski

Hi Penn,

The changes clarify what identifier is being specified and includes
reference to the authoritative OID standard.  It also allows for the
possibility of using other assigned OIDs for a Carrier of Record.  Although
more than 35,000 Enterprise Numbers have been registered with IANA, there
are many carriers who have OIDs that were registered with national
authorities for Carrier of Record purposes.  As long as there is a valid,
globally unique OID, some flexibility should exist.

For example, ATT has the OID 1.3.6.1.4.74 from IANA's OID block, but it also
has 0.7.7223 that it uses for some services in Argentina.

best,
tony

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network
Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If
you are not the intended recipient, please contact the sender by reply
e-mail and destroy all copies of the original message.

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Thu, 20 May 2010 10:14:49 -0400

Rich, fwiw, I can contribute to this effort.

Ken

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

- S

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

Ken

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

Hi Penn,

best,
tony