Subject: [drinks] IETF77 DRINKS WG meeting minutes posted.

From: "Alexander Mayrhofer" <[email-masked]>
Date: Thu, 15 Apr 2010 15:50:45 +0200

I've now posted the WG session minutes from Anaheim:

http://www.ietf.org/proceedings/10mar/minutes/drinks.txt

Thanks to Richard for taking notes - Please take a minute to review the
notes and let the chairs know if there's something missing..

thanks,

Alex

---

From: Sumanth Channabasappa <[email-masked]>
Date: Thu, 15 Apr 2010 10:49:11 -0600

Just so that I understand everything we discussed about the target domain in Anaheim - is it accurate to say that the "target domain" should refer to one of the following:
- a 3263 resolvable domain name; or,
- a URI that is either a "Global SPID" or some form of an "administrative domain".

The latter needs some work, i.e., a URI format to represent the data?

Here are my questions:
1) Is my understanding correct?
2) Should the domain name also be represented as a URI (for consistency)?

Thanks!
- S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Mayrhofer
Sent: Thursday, April 15, 2010 7:51 AM
To: [email-masked]
Subject: [drinks] IETF77 DRINKS WG meeting minutes posted.

Thanks to Richard for taking notes - Please take a minute to review the notes and let the chairs know if there's something missing..

thanks,

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

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Thu, 15 Apr 2010 18:55:43 +0200

> Just so that I understand everything we discussed about the 
> target domain in Anaheim - is it accurate to say that the 
> "target domain" should refer to one of the following:

[chair hat off]

Yes, that was how i understood the discussion - with the URI (or URN,
which is a subset of URIs) not necessarily restricted to a "Global
SPID". 

> The latter needs some work, i.e., a URI format to represent the data?

Exactly. This is sort of a "showstopper" right now, because there's no
URN space that could accomodate "Global SPIDs", for example.

> 1) Is my understanding correct?

Yes, it overlaps pretty well with my understanding.

> 2) Should the domain name also be represented as a URI (for 

There's actually a "dns" URI scheme - however, it's encapsulating the
data needed to describe a certain DNS query, rather than just the domain
itself:

http://www.rfc-editor.org/rfc/rfc4501.txt

Examples of a "dns" URI:

dns://192.168.1.1/ftp.example.org?type=A
dns:example.com?type=NAPTR

I'm not sure that's what we want to use as a "target domain" - we'd need
to make very clear what the semantics of such a URI would be..

Alex

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Thu, 15 Apr 2010 15:02:20 -0400

Sorry for the long email.

I see it in the following way.  There are three distinct requirements that have been formally and informally taped to the "targetDomain" attribute.  They are as follows:

1) The name of a host to which a 3263 SRV lookup can be sent to get a SIP ingress point.
2) The name of an "administrative domain".  Which I interpret to mean, a non-routable name that the provisioning and querying organizations can, in concert with one another, use in any way they see fit to help determine where/how to route the call.
3) The single, industry known, identifier of the carrier that is currently the carrier of record for that TN (e.g. a SPID).

Assuming that there are some organizations that really are doing 3263, I can see that all three of these requirements are valid.  However, I do not think we should attempt to identify a single data element that covers all 3 of them at the same time.  The reason for this is as follows:

a) 1 and 3 are two *different* pieces of information, not just two different naming schemes for the same piece of information.  Both of these pieces of information are valuable.  It's not an either/or proposition.  In other words, the provisioning system will be (and is) aware of the SPID of the carrier that is currently the carrier of record for a TN.  Furthermore, some/many organizations use that piece of information to make decisions on how/where/when to route a call to that TN.  But the provisioning system can *also* be aware of the name of a server to which you could do an SRV lookup to discover a SIP ingress point for that TN.  Furthermore, introducing 3263 based routing into a call routing eco-system will **not** supplant the need for industry known carrier identifiers (e.g. SPIDs).

b) 1 and 2 can be more inter-related, however.  I can see that a call routing eco-system that used 3263 would of course need to support provisioning of the host name to which the SRV lookup should be sent.  I can also see that a call routing eco-system that was not using 3263, but instead used "administrative domain" labels would of course want to provision those labels.  But in neither case here, would these names/labels be able to, from a provisioning perspective, *double* as the identifier of the carrier who is the carrier of record.

Based on this, I think we have two data elements:

1) targetDomain:  A string of characters that can either identify the host to which 3263 SRV lookups should be sent to discover the SIP ingress point for that TN, or the name of the "administrative domain" to which that TN is associated.
2) carrierIdentifier:  A string of characters that identifies the carrier of record for that TN.

My question is, however, why does the provisioning protocol need to allow a client of the provisioning API to provision in the carrierIdentifier?  Most systems that I am aware of have *internal* access to the regulatory and non-regulatory data sources that provide the SPID assignments for the TNs in a given country's number plan.  So if we need this provisioning protocol to support the provisioning of carrier of record SPIDs then we need some use cases to justify it.  I'm not necessarily apposed to it, but it is a new area of scope for the protocol.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sumanth Channabasappa
Sent: Thursday, April 15, 2010 12:49 PM
To: [email-masked]
Subject: [drinks] Target domain!

Here are my questions:

Thanks!
- S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Mayrhofer
Sent: Thursday, April 15, 2010 7:51 AM
To: [email-masked]
Subject: [drinks] IETF77 DRINKS WG meeting minutes posted.

thanks,

Alex

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: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Thu, 15 Apr 2010 15:12:53 -0400

Ken:
Actually there may be some cases where you'd want to provision SPID as
opposed to deriving from internal sources.

The i3 Forum is looking at use of SPID as an input to least cost routing
processes. There's interest in using ENUM and registries to exchange the
info but there are issues with data sourcing. So while *some* kind of
SPID might be derivable, e.g. from national numbering databases, it
might not be the universal global one that the i3 would like to use.
Mapping may be possible but it's desirable to support direct
provisioning.

It's also the case that an operator sometimes has other parties do the
administration/provisioning for them. Again, while there may be ways for
a single entity to provision that data for multiple SPIDs, it might be
best not to have to depend on that approach.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Cartwright, Kenneth
Sent: Thursday, April 15, 2010 3:02 PM
To: Sumanth Channabasappa; [email-masked]
Subject: Re: [drinks] Target domain!

I see it in the following way.  There are three distinct requirements
that have been formally and informally taped to the "targetDomain"
attribute.  They are as follows:

1) The name of a host to which a 3263 SRV lookup can be sent to get a
SIP ingress point.
2) The name of an "administrative domain".  Which I interpret to mean, a
non-routable name that the provisioning and querying organizations can,
in concert with one another, use in any way they see fit to help
determine where/how to route the call.
3) The single, industry known, identifier of the carrier that is
currently the carrier of record for that TN (e.g. a SPID).

Assuming that there are some organizations that really are doing 3263, I
can see that all three of these requirements are valid.  However, I do
not think we should attempt to identify a single data element that
covers all 3 of them at the same time.  The reason for this is as
follows:

a) 1 and 3 are two *different* pieces of information, not just two
different naming schemes for the same piece of information.  Both of
these pieces of information are valuable.  It's not an either/or
proposition.  In other words, the provisioning system will be (and is)
aware of the SPID of the carrier that is currently the carrier of record
for a TN.  Furthermore, some/many organizations use that piece of
information to make decisions on how/where/when to route a call to that
TN.  But the provisioning system can *also* be aware of the name of a
server to which you could do an SRV lookup to discover a SIP ingress
point for that TN.  Furthermore, introducing 3263 based routing into a
call routing eco-system will **not** supplant the need for industry
known carrier identifiers (e.g. SPIDs).

b) 1 and 2 can be more inter-related, however.  I can see that a call
routing eco-system that used 3263 would of course need to support
provisioning of the host name to which the SRV lookup should be sent.  I
can also see that a call routing eco-system that was not using 3263, but
instead used "administrative domain" labels would of course want to
provision those labels.  But in neither case here, would these
names/labels be able to, from a provisioning perspective, *double* as
the identifier of the carrier who is the carrier of record.

1) targetDomain:  A string of characters that can either identify the
host to which 3263 SRV lookups should be sent to discover the SIP
ingress point for that TN, or the name of the "administrative domain" to
which that TN is associated.
2) carrierIdentifier:  A string of characters that identifies the
carrier of record for that TN.

My question is, however, why does the provisioning protocol need to
allow a client of the provisioning API to provision in the
carrierIdentifier?  Most systems that I am aware of have *internal*
access to the regulatory and non-regulatory data sources that provide
the SPID assignments for the TNs in a given country's number plan.  So
if we need this provisioning protocol to support the provisioning of
carrier of record SPIDs then we need some use cases to justify it.  I'm
not necessarily apposed to it, but it is a new area of scope for the
protocol.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sumanth Channabasappa
Sent: Thursday, April 15, 2010 12:49 PM
To: [email-masked]
Subject: [drinks] Target domain!

Just so that I understand everything we discussed about the target
domain in Anaheim - is it accurate to say that the "target domain"
should refer to one of the following:
- a 3263 resolvable domain name; or,
- a URI that is either a "Global SPID" or some form of an
"administrative domain".

Here are my questions:
1) Is my understanding correct?
2) Should the domain name also be represented as a URI (for
consistency)?

Thanks!
- S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexander Mayrhofer
Sent: Thursday, April 15, 2010 7:51 AM
To: [email-masked]
Subject: [drinks] IETF77 DRINKS WG meeting minutes posted.

thanks,

Alex

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: Gonzalo Camarillo <[email-masked]>
Date: Tue, 20 Apr 2010 16:14:32 +0300

Hi,

in Anaheim, we agreed on a fairly aggressive time frame for this WG.
However, there have only been a few bursts of energy on the list since
then. Let's make sure we keep a high level of energy so that we can meet
that time frame and take full advantage of the upcoming interim meeting.

Regarding the minutes of the meeting, if the most obvious typos,
misspellings, and formatting issues could be fixed, that would be great.
Also, there were a few hums that need to be confirmed on the list.

Thanks,

Gonzalo

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Tue, 20 Apr 2010 15:26:50 -0400

Thanks for that feedback.  A clarification though ...

I'm thinking that we should center this discussion around the *role that a given data element fulfills* (e.g. industry standard authoritative carrier of record identifier, name of the host to which a 3263 SRV lookup can be sent, non DNS resolvable "administrative domain" used for subsequent opaque routing selection logic), rather than on terminology that might mean different things, to different people, under different circumstances (e.g. SPID, domainName, targetDomain).

So what I take away from your suggestion is that the data element that fills the role of the "industry standard authoritative carrier of record identifier" should be an optional, directly provisionable data element that can be associated with a public identifier.  And that data element must be allowed to be a separate data element from the one that fills the role of the "name of the host to which a 3263 SRV lookup can be sent".

But, another equally valid interpretation of your suggestion is that you are using the term SPID to mean something different; an "industry standard organization identifier that identifies the organization that exposes the route to a public identifier".  And you are saying that that must be directly provisionable.  Is this what you mean?

Ken

-----Original Message-----
From: PFAUTZ, PENN L (ATTCORP) [mailto:[email-masked]]
Sent: Thursday, April 15, 2010 3:13 PM
To: Cartwright, Kenneth; Sumanth Channabasappa; [email-masked]
Subject: RE: [drinks] Target domain!

Ken:

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

Ken

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

Here are my questions:

Thanks!
- S

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

thanks,

Alex

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Tue, 20 Apr 2010 15:29:54 -0400

Hi Alex,

Thanks for the notes.  In the notes you refer to the fact that most people hummed in favor of taking the "transport" document on as a working group item, but that there were two that hummed in opposition.  You also said that you were going to confirm on the list.  When and in what form will this confirmation on the list occur?

Thanks.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Mayrhofer
Sent: Thursday, April 15, 2010 9:51 AM
To: [email-masked]
Subject: [drinks] IETF77 DRINKS WG meeting minutes posted.

thanks,

Alex

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Wed, 21 Apr 2010 14:52:13 +0200

> Thanks for the notes.  In the notes you refer to the fact 
> that most people hummed in favor of taking the "transport" 
> document on as a working group item, but that there were two 
> that hummed in opposition.  You also said that you were going 
> to confirm on the list.  When and in what form will this 
> confirmation on the list occur?

I have just sent a request to reconfirm the HUM to the list. We'll have
to see what the responses to that request are - I have set april 30th as
a deadline - so that we have a final decision next week.

Alex

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Wed, 21 Apr 2010 17:23:25 -0400

Ken:
I agree with your first paragraph and, the use case I intend is that in
the second. I only mentioned the case where a different entity
provisions the data than the one identified in the data element as a
reason why the value of the element cannot be derived implicitly from
provisioning org IDs.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: Cartwright, Kenneth [mailto:[email-masked]] 
Sent: Tuesday, April 20, 2010 3:27 PM
To: PFAUTZ, PENN L (ATTCORP); Sumanth Channabasappa; [email-masked]
Subject: RE: [drinks] Target domain!

I'm thinking that we should center this discussion around the *role that
a given data element fulfills* (e.g. industry standard authoritative
carrier of record identifier, name of the host to which a 3263 SRV
lookup can be sent, non DNS resolvable "administrative domain" used for
subsequent opaque routing selection logic), rather than on terminology
that might mean different things, to different people, under different
circumstances (e.g. SPID, domainName, targetDomain).

So what I take away from your suggestion is that the data element that
fills the role of the "industry standard authoritative carrier of record
identifier" should be an optional, directly provisionable data element
that can be associated with a public identifier.  And that data element
must be allowed to be a separate data element from the one that fills
the role of the "name of the host to which a 3263 SRV lookup can be
sent".

But, another equally valid interpretation of your suggestion is that you
are using the term SPID to mean something different; an "industry
standard organization identifier that identifies the organization that
exposes the route to a public identifier".  And you are saying that that
must be directly provisionable.  Is this what you mean?

Ken

-----Original Message-----
From: PFAUTZ, PENN L (ATTCORP) [mailto:[email-masked]]
Sent: Thursday, April 15, 2010 3:13 PM
To: Cartwright, Kenneth; Sumanth Channabasappa; [email-masked]
Subject: RE: [drinks] Target domain!

Ken:

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

Ken

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

Here are my questions:

Thanks!
- S

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

thanks,

Alex

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Wed, 21 Apr 2010 17:55:14 -0400

Ok.  That makes sense.  So summarizing all of the inputs we've heard, we need one or more data elements that do the following for a public identifier:

1) identify the name of the host to which a 3263 SRV lookup can be sent (This must be provisionable via the protocol)
2) identify the organization that "owns" a given Route, which may be different from the organization that provisions the Route (This must be provisionable through the protocol)
3) identify an "administrative domain" that can be used for subsequent opaque routing logic (This must be provisionable through the protocol)
4) identify the authoritative carrier of record (This may not need to be provisionable through the protocol, as it is sourced from regulatory and semi-regulatory bodies out-of-band.  However, some have suggested an increase in the scope of the work to include this concept into the protocol as well.)

Ken

-----Original Message-----
From: PFAUTZ, PENN L (ATTCORP) [mailto:[email-masked]]
Sent: Wednesday, April 21, 2010 5:23 PM
To: Cartwright, Kenneth; Sumanth Channabasappa; [email-masked]
Subject: RE: [drinks] Target domain!

Ken:

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: Cartwright, Kenneth [mailto:[email-masked]]
Sent: Tuesday, April 20, 2010 3:27 PM
To: PFAUTZ, PENN L (ATTCORP); Sumanth Channabasappa; [email-masked]
Subject: RE: [drinks] Target domain!

Ken

-----Original Message-----
From: PFAUTZ, PENN L (ATTCORP) [mailto:[email-masked]]
Sent: Thursday, April 15, 2010 3:13 PM
To: Cartwright, Kenneth; Sumanth Channabasappa; [email-masked]
Subject: RE: [drinks] Target domain!

Ken:

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

Ken

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

Here are my questions:

Thanks!
- S

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

thanks,

Alex

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 22 Apr 2010 01:06:00 +0200

Hi Penn,

When you have figured out what a "Global SPID"
is, it would be useful to know.  This identifier has
been chased for the past five years in the ITU-T
and sundry other venues.  Maybe the answer is
to specify what provider identifiers are acceptable
as Global SPIDs.
--tony (in Geneva)