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

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: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] 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

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: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] 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

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

_______________________________________________
e2md mailing list
e2md@ietf.org
https://www.ietf.org/mailman/listinfo/e2md
_______________________________________________
e2md mailing list
e2md@ietf.org
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.