Subject: [Speermint] I-D ACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt

From: [email-masked]
Date: Fri, 08 Jun 2007 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF.

	Title		: VoIP SIP Peering Use Cases
	Author(s)	: A. Uzelac, et al.
	Filename	: draft-ietf-speermint-voip-consolidated-usecases-02.txt
	Pages		: 23
	Date		: 2007-6-8
	
This document will capture VoIP use case for SIP Peering.  It is a 
        consolidation of Speermint use cases drafts.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-speermint-voip-consolidated-usecases-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 18 Jun 2007 14:39:24 -0400

Alex - 

According to our milestones, we're looking to complete work on this I-D
in August.  Since the underlying draft should now be fairly stable in
the run-up to IETF-69, would you please peform a NITS review of this
document?  I suspect the authors will have some minor changes to make
following IETF-69 just before they are ready for WGLC.  If we can fix
some of the NITS before IETF-69, all the better.

Thanks!
Jason 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, June 08, 2007 3:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Speermint] I-D 
> ACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Session PEERing for 
> Multimedia INTerconnect Working Group of the IETF.
> 
> 	Filename	: 
> draft-ietf-speermint-voip-consolidated-usecases-02.txt
> 	Pages		: 23
> 	Date		: 2007-6-8
> 	
> To remove yourself from the I-D Announcement list, send a 
> message to [email-masked] with the word 
> unsubscribe in the body of the message. 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 	"FILE 
> /internet-drafts/draft-ietf-speermint-voip-consolidated-usecas
> es-02.txt".
> 	
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: "Rodrig, Benny \(Benny\)" <[email-masked]>
Date: Mon, 18 Jun 2007 17:21:58 -0400

Adam, all,

I have a few comments on
draft-ietf-speermint-voip-consolidated-usecases-02.

I think the draft should state that the Originating Domain and/or the
Terminating Domain can be either a commercial service provider or an
enterprise. This statement can be added in section 3 just before 3.1.

I'd suggest also adding a couple of points regarding enterprises after
this statement, or possibly somewhere else in the draft:
One is a sentence about regulatory requirements potentially being
different in the case of enterprises. 
And the other is something like the following sentence: 'Other models
for session interconnect in the context of enterprise scenarios, such as
subscription-based models and transit models for intra-enterprise
communications, are out of scope of Speermint.'

If there is agreement that the domains can be enterprises, then a
decision is needed on the use of the term VSP. The draft can say clearly
that the term VSP in this draft refers to either a commercial VoIP
service provider or an enterprise VoIP domain. This can be added to the
definition of VSP in the terminology section. The text in section
3.1.2.2 that distinguishes between a service provider and an enterprise
should then be explicit and say something like 'commercial VoIP Service
Provider'. Also 3.1.3.2 seems to use the term VSP to mean
non-enterprise, but there the distinction doesn't seem to be needed at
all as a following sentence adds that this is also applicable to
enterprises.

Does it make sense to add to the administrative characteristics of
transit (section 3.2.1.1) something about transitive conditions, e.g. an
originating enterprise is willing to peer indirectly through Transit-PSP
only with domains that meet certain requirements such as that the
connection between the Transit-PSP and the terminating domain is
secured? 

In the indirect section it may be worth mentioning the possibility of
traversing two transit domains, e.g. if the originating and terminating
domains are enterprises that each has a relationship with a different
transit PSP.

This version of the I-D is much clearer than the previous one regarding
Transit and Assisted, but the difference between the cases may not be
clear yet. According to the definitions and to Figure 6, I'd think that
the Assisting PSP does not handle the media. But then the mention of DBE
and of media sub-function in section 3.3 seem to suggest otherwise, as
well as step 8 in section 3.3.1 that says 'O/A/T DBE'. Wouldn't this
make it a Transit domain? 

Also in section 3.3. about the Assisted case there are a couple of
sentences that refer to 'the federation'. This may be confusing.

A couple of editorial nits:
Section 3.1.3 first line - SBCs should be SBEs
Figure 4, bottom right - O-UE should be T-UE
Section 3.3.1 section title, as well as Figure 6 title, 'Assisted PSP'
better be 'Assisting PSP'

Benny

-----Original Message-----
From: Livingood, Jason [mailto:[email-masked]] 
Sent: Monday, June 18, 2007 2:39 PM
To: [email-masked]; Alexander Mayrhofer
Subject: RE: [Speermint]
I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.txt 

Alex - 

Thanks!
Jason 

> logging in, type "cd internet-drafts" and then "get 
> draft-ietf-speermint-voip-consolidated-usecases-02.txt".
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 22 Jun 2007 18:10:32 +0100

I have not seen any discussion on this since Benny posted it, but as
co-author of the enterprise peering draft I agree with these comments. I
have other comments too, including more concerns about the assisted
versus indirect issue, which I will post separately.

John 

> From: Rodrig, Benny (Benny) [mailto:[email-masked]] 
> Sent: 18 June 2007 22:22
> To: [email-masked]
> Subject: RE: [Speermint] 
> message to 
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: "David Schwartz" <[email-masked]>
Date: Mon, 25 Jun 2007 15:39:12 +0300

Hi Benny.

I see this issue coming up in many postings regarding the differences
between indirect and assisted peering so I figured I would throw in my
two cents. 

While not what I had initially put down in my use case draft, the more I
think about it the more I feel that this should be our approach.

I think we can all agree that indirect (as the name implies) refers to
either signaling or media or both traversing one or more intermediary
nodes. 

Assisted on the other hand makes no such assumption. Assisted merely
implies that some assistance is provided to the originating or
terminating party in peering. Since assistance in the form of signaling
(e.g. interoperability) or media (e.g. transcoding) is covered under the
indirect relationship, the functions I see associated with the assisted
model are:

* The lookup function (who owns the number)
    * covers any mechanism reducing the need for an endpoint 
      to hold all number ranges of all his peers (this can 
      include a centralized database accessible via ENUM or a 
      DHT containing all relevant information)

* Routing (how to get there)
    * note that this may require the assistance of an element filling
the
      Role of indirect peering

* Policy (who can see what)
    * Who gets a direct uri to other peer 
    * Who must use intermediary
    * Who gets a 404 Not found

A hub and spoke federation would thus be fulfilling the two functions at
the same time - the role of assisted for lookup and the role of indirect
for the anchoring of signaling and media.

Any thoughts?

D.

-----Original Message-----
From: Rodrig, Benny (Benny) [mailto:[email-masked]] 
Sent: Tuesday, June 19, 2007 12:22 AM
To: [email-masked]
Subject: RE: [Speermint]

Adam, all,

I have a few comments on

Benny

-----Original Message-----
From: Livingood, Jason [mailto:[email-masked]] 
Sent: Monday, June 18, 2007 2:39 PM
To: [email-masked]; Alexander Mayrhofer
Subject: RE: [Speermint]

Alex - 

Thanks!
Jason

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 25 Jun 2007 16:03:43 +0100

> From: David Schwartz [mailto:[email-masked]] 
> Sent: 25 June 2007 13:39
> To: Rodrig, Benny (Benny); [email-masked]
> Subject: RE: 
> [Speermint]I-DACTION:draft-ietf-speermint-voip-consolidated-us
> ecases-02.txt
> 
> Hi Benny.
> 
[JRE] It seems reasonable to use this term when signalling traverses one
or more intermediate nodes, whether or not media does so too. I don't
see a case where media does so without signalling.

> for the anchoring of signaling and media.
[JRE] This seems to imply to me that indirect is a subset of assisted,
i.e., with indirect, the intermediate signalling nodes are still doing
look-up, routing and policy.

John

---

From: "David Schwartz" <[email-masked]>
Date: Mon, 25 Jun 2007 18:27:03 +0300

> see a case where media does so without signalling.

Good point.

>> terminating party in peering. Since assistance in the form of 
>> signaling (e.g. interoperability) or media (e.g. transcoding) is 
>> covered under the indirect relationship, the functions I see 
>> associated with the assisted model are ...

>look-up, routing and policy.

Not necessarily. Let's not confuse the entity doing the lookup with the
entity providing the lookup as a service. Yes the intermediate elements
need to look up the information and for all we know they may look it up
at the same place that the originating peer did (and will probably get a
different answer - they are more trusted). The point is the indirect
peer does not hold this information himself and provide this as a
service (unless he is also the assisting peer).

I see all these models as service providing roles.

---

From: "Rodrig, Benny (Benny)" <[email-masked]>
Date: Mon, 25 Jun 2007 13:37:06 -0400

David,

This makes sense to me. But I think you're saying that Assisted is kind
of orthogonal to direct/indirect, and if this is the approach we take,
then the draft should not describe them simply as three cases implying
either/or. 

According to this approach Figure 5 in draft -02 is really Assisted via
Transit PSP. If you want to account for the case that the Assisting PSP
and the Transit PSP are different providers then the diagram can show
some optional separation between the upper and the lower parts of that
domain.

If there is a valid use case of Indirect/Transit which is not also
Assisted peering, then a new diagram and description are needed, which
are similar to Figure 5 but do not have the interactions (2) and (3)
between O-SM and t-SM/t-LS and instead have interactions between t-SBE
and t-SM/t-LS.

Benny

-----Original Message-----
From: David Schwartz [mailto:[email-masked]] 
Sent: Monday, June 25, 2007 11:27 AM
To: Elwell, John; Rodrig, Benny (Benny); [email-masked]
Subject: RE:
[Speermint]I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-02.
txt

Good point.

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 25 Jun 2007 19:08:49 +0100

Yes, I agree they are two orthogonal concepts. If they were described in
that way it would make sense.

John 

> Sent: 25 June 2007 18:37
> To: David Schwartz; Elwell, John; [email-masked]
> Subject: RE: 
> ecases-02.