Subject: [e2md] RFC 5507 & RFC 5395

From: Bernie Hoeneisen <[email-masked]>
Date: Sun, 16 May 2010 14:35:19 +0200 (CEST)

Hi E2MD list

The following RFC helps us to better understand to objections against E2MD 
expressed by the DNS folks:

   http://tools.ietf.org/html/rfc5507

Further information can also be found in:

   http://tools.ietf.org/html/rfc5395

To address the various objections I recommend everyone to read at least 
the former (RFC 5507), as it explains quite some arguments grey-beards and 
others have expressed before and during the BoF.

cheers,
  Bernie

---

From: Jim Reid <[email-masked]>
Date: Mon, 17 May 2010 12:44:30 +0100

On 16 May 2010, at 13:35, Bernie Hoeneisen wrote:

> To address the various objections I recommend everyone to read at  
> least the former (RFC 5507), as it explains quite some arguments  
> grey-beards and others have expressed before and during the BoF.

Bernie, while these links are useful they don't really help us make  
progress. In the context of the discussion on this list RFC5507 pretty  
much says there are two choices open to us: a new RRtype or a new  
subtype of an existing RRtype (=> NAPTR). If it's the latter, careful  
attention to the size of the returned RRset is necessary. This is not  
news.

So we're still running around in circles. Without clear use cases and/ 
or requirements, it's not possible to decide which of the two  
approaches above makes more sense. I am frustrated and disappointed  
that this information is still to be presented here (other than in  
vague anecdotal terms). It's pointless to continue a technical  
discussion unless there is an generally accepted problem statement.

With that in mind, I make the following suggestion. Could whoever is  
in charge of this BOF ask those who have use cases and requirements to  
submit them and set a deadline for that input? If nothing is  
forthcoming, then there isn't a problem to work on and we can all go  
home. And if we get that info, there would at least be a basis for a  
problem statement that could then be analysed and perhaps worked on.

---

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 17 May 2010 15:19:36 +0200 (CEST)

Hi Jim

On Mon, 17 May 2010, Jim Reid wrote:

> With that in mind, I make the following suggestion. Could whoever is in 
> charge of this BOF ask those who have use cases and requirements to submit 
> them and set a deadline for that input? If nothing is forthcoming, then there 
> isn't a problem to work on and we can all go home. And if we get that info, 
> there would at least be a basis for a problem statement that could then be 
> analysed and perhaps worked on.

About Problem statement:

Last week I sent out an email with Subject: "Action Required: Your version 
of the Problem statement needed", which pretty much covers this. As I have 
only seen a few answers, I maybe could send a reminder.

About Requirements:

A call for requirements sime weeks ago resulted in the following:
   http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList
   (AFAICR only Jay and Dean have been contributing so far.)

About Use Cases:

BTW: Long before the BoF I also publically asked for Use Cases, which 
is still the basis for the Use Cases we are discussing here. Details see 
E2MD archives.

Wiki page under construction:
   http://trac.tools.ietf.org/bof/e2md/trac/wiki/UseCases

Wiki:

Here the list of links to the Wiki pages:

- Main E2MD Wiki Page:
   http://trac.tools.ietf.org/bof/e2md/trac/wiki

- Requirements:
   http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList

- Use Cases (under construction)
   http://trac.tools.ietf.org/bof/e2md/trac/wiki/UseCases

- Objections (Ticketing System)
   http://trac.tools.ietf.org/bof/e2md/trac/report/10

I would wish the Wiki was more of a collaborative happening as opposed to 
one person doing all the work...

cheers,
  Bernie

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Mon, 17 May 2010 10:22:38 -0400

So I went through the RFCs which seemed to say, "You probably should use a new RR type if you're going to get too much data and it's not as bad getting new RRs as you think."

Naïve question: if we said we wanted a WG based on the assumption that we'll define new RR type(s) as needed would that settle the naysayers' hash?

I'll be happy to send some text for G-SPID separately

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernie Hoeneisen
Sent: Monday, May 17, 2010 9:20 AM
To: Jim Reid
Cc: E.164 To MetaData BOF discussion list
Subject: [e2md] Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395)

Hi Jim

About Problem statement:

About Requirements:

About Use Cases:

Wiki:

- Main E2MD Wiki Page:

- Requirements:

cheers,
  Bernie

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

---

From: Ray Bellis <[email-masked]>
Date: Mon, 17 May 2010 15:09:13 +0000

On 17/05/2010 15:22, "PFAUTZ, PENN L (ATTCORP)" <[email-masked]> wrote:

> So I went through the RFCs which seemed to say, "You probably should use a new
> RR type if you're going to get too much data and it's not as bad getting new
> RRs as you think."
> 
> Naïve question: if we said we wanted a WG based on the assumption that we'll
> define new RR type(s) as needed would that settle the naysayers' hash?

It might, but it then doesn't meet some of the technical requirements for
some of the use cases.

For 'Send-N' and 'unused', in particular, NAPTR fits because these answers
are given back instead of "communication end points" in response to the
usual DDDS algorithm query.

A new RR type for those would be self-defeating.

Ray

---

From: Dean Willis <[email-masked]>
Date: Mon, 17 May 2010 10:12:21 -0500

PFAUTZ, PENN L (ATTCORP) wrote:
> So I went through the RFCs which seemed to say, "You probably should
> use a new RR type if you're going to get too much data and it's not
> as bad getting new RRs as you think."
> 
> Naïve question: if we said we wanted a WG based on the assumption
> that we'll define new RR type(s) as needed would that settle the
> naysayers' hash?

I believe it would settle some of their hash. Not all of it, of course;
if we propose an RR-type for putting a caller-ID photo jpg into the DNS,
they're still going to get upset and say "no". And preserving their
ability to say "no" on a per-case basis is something they really want.

However, if we agree to, for each use case, consider whether we should
re-use an existing RR type or define a new RR-type, and that we will
also make a similar determination about whether to put the data itself
into the DNS or put a pointer to the data into the DNS, then I think
we're going to get a lot less pushback than our current proposal "enjoys".

I had a side discussion with Jim about his experience in getting new
RR-types approved, and to summarize, my impression was that it was kind
of random. Some RR-types were unexpectedly easy, others unexpectedly
difficult.

--
Dean

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Mon, 17 May 2010 13:31:46 -0400

Ray:
I see your point. It also appears that send-n and unused would never by themselves raise response size issues since I wouldn't expect to see a send-n RR in or an unused RR for a domain name that would have other NAPTR records in its RR set. So let me bump the naïve question up a level:

Please sirs, may we have an e2md WG that will analyze proposed use cases guided by RFC 5507 & RFC 5395 and propose appropriate implementations?

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

-----Original Message-----
From: Ray Bellis [mailto:[email-masked]] 
Sent: Monday, May 17, 2010 11:09 AM
To: PFAUTZ, PENN L (ATTCORP); E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395)

Ray

---

From: Jim Reid <[email-masked]>
Date: Mon, 17 May 2010 19:36:25 +0100

> of random. Some RR-types were unexpectedly easy, others unexpectedly

The problems were with what I consider were some interfering busy- 
bodies who seemed to meddle for the sake of it. In fairness, this was  
the first time the 5395 process had been used. So some teething  
problems from well-intentioned but probably misinformed bystanders  
were perhaps to be expected. Oh well.

One of them decided he knew better than me what the requirements were  
for the problem I needed the new RR for. He didn't appear to  
understand he didn't have a say on the allocation of a new type code  
or a veto over the template I submitted either. Others mistakenly felt  
that the suggested name for one of the new RRtypes had some bearing on  
zone semantics. [I doubt they'd read the documentation.] Anyone who  
wants to know the details can buy me beer or consult the dnsext  
archives from late 2008.

There were no difficulties with the expert reviews of the templates.  
Or with the reviewers. They were helpful and did their job of  
allocating the new type codes with the minimum of fuss. Which is how  
the 5935 process is supposed to work.

It's meant to be simple and straightforward to get new RR type codes  
assigned -- no RFC required! -- as long as the new RR does not mess  
with zone cut semantics or entail changes to additional section  
processing. This is perhaps the most important thing to bear in mind  
if a new RRtype turns out to be the path this BOF will follow.

---

From: Dean Willis <[email-masked]>
Date: Mon, 17 May 2010 16:37:57 -0500

> Please sirs, may we have an e2md WG that will analyze proposed use cases guided by RFC 5507 & RFC 5395 and propose appropriate implementations?

That probably would work. I think all we need to do is agree to analyze
the problem(s) and solve each appropriately while respecting the
"rules", rather than insisting on one-size-fits-all hack/slash on ENUM
to define a framework for adding arbitrary metadata into NAPTR records.

--
Dean

---

From: Ray Bellis <[email-masked]>
Date: Tue, 18 May 2010 08:46:16 +0000

> if a new RRtype turns out to be the path this BOF will follow.

And this indeed is another reason why Send-N doesn't use a new RR.

It _could_ have been designed to be a new RR which is returned automagically
in the additional section whenever the original DDDS query returned no NAPTR
records (RCODE = 0, ANSWERS = 0).

However that would require "additional section processing", and adding new
logic to DNS implementations to cope with that is a very high bar to
overcome.

Ray

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Tue, 18 May 2010 11:30:39 -0400

Ouch.  I think what Dean might have meant to say was...

"That probably would work.  I think all we need to do is agree to analyze the problem(s) and solve each appropriately, while respecting the concerns and motives of all parties.  We should not assume and force pre-conceived solutions or solution constraints that, after thoroughly analyzing the problem(s) and the solution(s), are inappropriate or unfounded."

Dean, if that's not what you meant to say, please accept my apologies.
:-)

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Monday, May 17, 2010 5:38 PM
To: PFAUTZ, PENN L (ATTCORP)
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395)

--
Dean

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: "Richard Shockey" <[email-masked]>
Date: Tue, 18 May 2010 18:10:41 -0400

On Mon, 2010-05-17 at 13:31 -0400, PFAUTZ, PENN L (ATTCORP) wrote:

> Please sirs, may we have an e2md WG that will analyze proposed use cases
guided by RFC 5507 & RFC 5395 and propose appropriate implementations?

"rules", 

RS> What rules are that Dean?

rather than insisting on one-size-fits-all hack/slash on ENUM
to define a framework for adding arbitrary metadata into NAPTR records.

RS> We will have to separate the requirements for what are clearly closed
private implementations 3761 for E2MD vs those that may use the single root
DNS.  The requirements, certainly the security and privacy issues are very
different. 

--
Dean

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Wed, 19 May 2010 11:03:47 -0400

As promised some words for the Global SP ID use case:

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.

[fire away!]

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bernie Hoeneisen
Sent: Monday, May 17, 2010 9:20 AM
To: Jim Reid
Cc: E.164 To MetaData BOF discussion list
Subject: [e2md] Problem statement, Requirements and Use Cases (was RFC
5507 & RFC 5395)

Hi Jim

> With that in mind, I make the following suggestion. Could whoever is
in 

About Problem statement:

Last week I sent out an email with Subject: "Action Required: Your
version 
of the Problem statement needed", which pretty much covers this. As I
have 
only seen a few answers, I maybe could send a reminder.

About Requirements:

About Use Cases:

E2MD archives.

Wiki:

- Main E2MD Wiki Page:

- Requirements:

I would wish the Wiki was more of a collaborative happening as opposed
to 
one person doing all the work...

cheers,
  Bernie

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 19 May 2010 11:51:53 -0400

> 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

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Wed, 19 May 2010 12:45:10 -0400

Tony:
This is an area that will need more discussion which I hope will ensue,
if not necessarily under e2md then in the IETF, ITU, i3 and national
SDOs. At least some bodies are looking for a single integer (SPN), e.g.
the value under the OID 1.3.6.1.4 arc, for AT&T 74. There have also been
some requests to support hierarchy subtending an SPN. 

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

-----Original Message-----
From: Tony Rutkowski [mailto:[email-masked]] 
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

Hi Penn,

best,
tony

---

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

> some requests to support hierarchy subtending an SPN.

Agreed.

Another international carrier identifier choice is
ITU-ICCs pursuant to the M.1400 standard.  However,
their six alphanumeric character structure doesn't
scale, and the uptake has been minimal.

Almost every country has one or more national
identifiers for carriers, but those differ structurally
and are not global by definition.

Then there is the new NeuStar proposal for a five digit
number issued by either the ITU equivalent of IANA (the
TSB) or by national telephone managers like NeuStar.
However, these don't scale, would have significant
regulatory burdens and costs, and seem unlikely to be
accepted as a new global SPID.

OIDs on the other hand were created in the 1980s as a
universal, simple, extensible identifier for all
entities, explicitly including service providers.  They
are hierarchical and can be recursively resolved.  They
are widely used as SPIDs.  The assignment identity
proofing and maintenance leaves something to be
improved, but this is being addressed with the use of
X.509 or EVcerts or other assurance overlays.

Anyhow, those seem like the SPID alternatives.

--tony

---

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

Hi Penn,

best,
tony

---

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

Applying Penn's general phraseology to Rich's CNAM, one might say the high-level CNAM problem statement is...

Use RFC 3761 technology to provide a standardized query/response protocol for the Calling Name information of E.164 numbers in either public or access controlled environments.

But to keep Dean happy, ( :-) just teasing Dean), here's a more generic way of stating this...

Using technologies that coherently integrate with existing, IP based, call establishment technology stacks and call flows, provide a standardized query/response protocol for the Calling Name information of E.164 numbers in either public or access controlled environments.

Rich can probably offer a more thorough problem statement.  But the more detailed requirements are already documented elsewhere.

Ken

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

[fire away!]

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

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

Hi Jim

in

About Problem statement:

About Requirements:

About Use Cases:

E2MD archives.

Wiki:

- Main E2MD Wiki Page:

- Requirements:

cheers,
  Bernie

---

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: "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-----
Tony Rutkowski

> 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: Tony Rutkowski <[email-masked]>
Date: Wed, 19 May 2010 16:10:46 -0400

On 5/19/2010 3:44 PM, Sumanth Channabasappa wrote:
> 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?
>    

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: Sumanth Channabasappa <[email-masked]>
Date: Wed, 19 May 2010 13:44:44 -0600

- 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

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: "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

---

From: Bernie Hoeneisen <[email-masked]>
Date: Wed, 26 May 2010 21:08:01 +0200 (CEST)

Hi E2MD:ers

IMHO something along the lines of what Penn and Dean proposed "agree 
to analyze the problem(s) and solve each appropriately" (see below) 
is a viable strategy to get a E2MD WG approved. This implies a lot of 
wordsmithing to a charter...

We'd need to make a careful selection of initial use cases to be assessed 
in that WG. Furthermore we need a sophisticated strategy to drop certain 
use cases (from the initial list) during the WG forming BoF, if those are 
causing too much harm to the WG approval process. And we need 
Internet-Drafts describing the Use Cases before the WG forming BoF takes 
place.

My questions to all of you:

a) Do you also see this as a viable strategy?

b) Which timeframe do your believe is sensible (Maastricht or Beijing?)

c) Who is willing to actively assist the work on an agreeable charter?

d) Who is willing to write Internet-Drafts describing certain Use Cases?

We'll discuss this as part of tomorrow's conference call. However, 
some initial discussion on this list is most helpful to keep this 
discussion during the call as short as possible. Besides this, your 
opinion will be understood better if it is stated in written.

In case you do not agree with this strategy, please indicate to the list, 
how you believe we should go on with this matter!

cheers,
  Bernie

--

http://ucom.ch/
Tech Consulting for Internet Standardization

On Mon, 17 May 2010, Dean Willis wrote:

>> Please sirs, may we have an e2md WG that will analyze proposed use 
>> cases guided by RFC 5507 & RFC 5395 and propose appropriate 
>> implementations?
>
>

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 27 May 2010 11:57:47 -0700

(a few minutes before the call...)

> a) Do you also see this as a viable strategy?

On review the Use Cases file, I think it has 'useful' content but really does 
not provide 'use cases'.

I think of "uses cases" as starting with a description of a problem or activity 
that one wants to accomplish.  The current document seems to start with 
particular features to add.  Most of these do have a subordinate entry that 
cites a usage, but it's in passing, rather than as a focus.

To take an example from the current file, I'd expect a Use Case to say:

    Assist in better call routing

It would have a statement about the current call routing limitations or problems 
and discuss the kinds of things that would make call routing better.  For 
example, perhaps an organization has multiple VOIP gateways to the open 
Internet.  How does an inbound caller know which to route through.  (I'm 
fantasizing here; I've no idea if this is a real issue of concern to you folk.)

Only after all that might the use case start citing possible solution paths, 
such as parameters that need to be added to an (existing) ENUM record.

> c) Who is willing to actively assist the work on an agreeable charter?

yes.  i enjoy charter bashing and believe that a well-draft charter sets the, 
ummm, course for the working group.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net