Service Provider => SIP Service Provider

OK by me if we want to change service provider to SIP service provider,
or SSP in all of our documents.  In addition to the Terminology Draft,
here is a listing of the other WG drafts where 'service provider' should
be changed to 'SIP service provider' or 'SSP' for consistency.

draft-ietf-speermint-srv-naptr-use-02.txt
Abstract:   "The objective of this document is to specify the Best
Current 
   Practice (BCP) adopted by a service provider... " => SIP service
provider

Section 3: "SIP systems are represented by user agents (UA).  The
diagram below shows the case of direct peering where a user agent (UA1),
hosted by a service provider SP1, initiates a SIP session to a User
Agent (UA2), hosted by service provider SP2."
'service provider SP1' => 'SIP service provider SP1'
'service provider SP2' => 'SIP service provider SP2'

draft-ietf-speermint-architecture-04
Introduction:  First paragraph mentions 'IP Service provider...'  =>
SIP?
Second paragraph:  'This architecture allows the interconnection of two
service providers ...'  => 'SIP service providers'

Section 2, in the bulleted list, the second, third fifth and sixth
bullets all have 'Service Provider' which should be changed to 'SIP
Service Provider'

Figure 1 has two instances of 'Service Provider' which should be changed
to 'SIP Service Provider'.

RE: Service Provider => SIP Service Provider

James,

   The use of SIP service provider terminology has been discussed many
times before and some wg drafts have used it since before IETF#69.  We
can't keep revisiting those basic terms - let's stick with this one.

   Thanks for checking the inconsistencies in other wg drafts. Let me
know if you see any issues with the use of 'service provider' in the
requirements draft - I'll fix it.

Jean-Francois.

> -----Original Message-----
> From: James McEachern [mailto:jmce@...]
> Sent: Saturday, December 01, 2007 4:42 PM
> To: Daryl Malas
> Cc: speermint@...; Livingood, Jason
> Subject: [Speermint] Service Provider => SIP Service Provider
> 
> OK by me if we want to change service provider to SIP service
provider,
> or SSP in all of our documents. 

> In addition to the Terminology Draft,
> here is a listing of the other WG drafts where 'service provider'
> should
> be changed to 'SIP service provider' or 'SSP' for consistency.

[snip] 

won't be in speermint due to BA / Heathrow airport issues

   My apologies in advance but I won't be able to join the IETF wg
meetings today, including speermint.  
We are about a dozen folks from IETF stuck in London. We missed the
connecting flight from Heathrow to Vancouver yesterday due to bad
weather conditions in London.

Re: the requirement draft, I would appreciate if folks could send any
comments they have to the list.  Feel free to talk to Jason, and Dave
about this ID.  I will hopefully be in Vancouver from Monday night until
Sat morning - feel free to catch me.

My plan is to put out a revision of the requirements draft just after
the IETF, by January 15 => comments are welcome.

Jean-Francois

RE: new version of draft-ietf-speermint-requirements

Otmar,

  Thx for the comments. More inline.

Jean-Francois.

> -----Original Message-----
> From: Otmar Lendl [mailto:lendl@...] On Behalf Of Otmar Lendl
> Sent: Tuesday, November 20, 2007 10:31 AM
> To: Jean-Francois Mule
> Cc: speermint@...
> Subject: Re: [Speermint] new version of draft-ietf-speermint-
> requirements
> 
[snip]

> The document is much clearer and more consistent this way (e.g. in -02
> the IM sections already listed requirements on protocol features
> whereas the rest of the document described considerations for SSPs).

Ok, credits to A. Houri, E. Aoki and S. Parameswar on this one as noted
in the ID.

> As with the terminology draft, I'm a bit worried whether we're really
> clear and consistent regarding the term "indirect peering". As I read
> this paragraph, in the case of the scenario SSP-O -- SSP-transit --
> SSP-T
> this language suggests that "SSP-O" and "SSP-T" are doing "indirect
> peering" with each other. Daryl's mails seem to indicate that he
> intended that term to be used for the relationship "SSP-O -- SSP-

RE: Comments on Requirements-03

John,

  Thx for the comments.  See inline.

Jean-Francois.

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@...]
> Sent: Wednesday, November 21, 2007 10:45 AM
> To: speermint@...; Jean-Francois Mule
> Subject: Comments on Requirements-03
> 
> Jean-Francois,
> 
> I am now a lot happier about the way the requirements in section 3 are
> formulated (in terms of "protocol mechanisms must...". Thanks.
> 
> I haven't done a complete review, but I happened to notice the
> following:
> 
> 1. "Requirement #1: protocol mechanisms must exist for SSPs to
>       communicate the egress and ingress points of its service
> domain."
> Why do ingress points need to be advertised?
> 

Putting NAPTR+SRV records in SSP domain name a la  RFC 3263 is a way of
advertising ingress points.  There are lower layer considerations and
traffic engineering considerations for which you would want to know in
advance which ingress points to use for a given peer.

Comment on requirements draft and BCPs for SPEERMINT security issues

Dear Jean-Francois and all,

I have one comment:
crrently the requirements draft defines requirements,
but for security issues maybe a BCP draft is needed to help
operators to configure their network.

We made already some study about this in the VoIP security threats.
The question is (I will also raise it today in the AOB slot):

does the group want to have a security BCP draft based on the VoIP
security threats?
If yes I will submit one after IETF, otherwise I will just stop
maintaning the draft.

Please have your comments ready today for the WG slot or post them
on the list.

Cheers,
Saverio

============================================================
Dr. Saverio Niccolini
Senior Researcher
NEC Laboratories Europe, Network Research Division	
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-118
Fax:     +49 (0)6221 4342-155
e-mail:  saverio.niccolini@... <-- !!! NEW ADDRESS !!!
============================================================

I-D ACTION:draft-ietf-speermint-voip-consolidated-usecases-04.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.

	Title		: VoIP SIP Peering Use Cases
	Author(s)	: A. Uzelac, et al.
	Filename	: draft-ietf-speermint-voip-consolidated-usecases-04.txt
	Pages		: 23
	Date		: 2007-12-3
	
This document will capture VoIP use case for SIP Peering.  It is a 
        consolidation of Speermint use cases drafts. This document depicts 
        many common VoIP peering use cases. These use cases are categorized 
        into three types: Direct, Indirect and Assisted. They are not the 
        exhaust set of use cases but the most common use cases deployed in 
        production today. This document captures them to provide a reference.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@... 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-04.txt".

Some quick comments on Use Cases 04

Hi.

First a general comment. I still see confusion between assisted and  
indirect popping up in various passages. Here is a high level diagram  
(sorry its not ascii art) of the way I understand it and perhaps this  
can be used in discussions today to close this issue.

Note that the assisting peer and indirect peer can be (hence the box  
around the two) provided by the same third party (but this has never  
been a requirement)

The point is that the Assisting peer really is just there for the  
full resolution of SED. Once this is done the actual signaling and  
possibly media are handed over to the indirect peer (if needed)

Now for some specific comments...

On page 4 - Location server - this definition fits more for a "lookup  
Server". Lookup resolves an "owner", Location resolves a SED.

On Page 4 - I still see many "?" in the text - probably needs to be  
quotation marks?

In the definition of 4.1 (page 6) The LUF should be defined as a  
mapping of identifiers (ususally e.164 numbers - NOT necessarily a  
SIP username) and associated responsible domain

Some quick comments on Use Cases 04 - sorry but I seem to have some issues with my email today :(

(This got cut off from my previous email...)

Note that the assisting peer and indirect peer can be (hence the box  
around the two) provided by the same third party (but this has never  
been a requirement)

The point is that the Assisting peer really is just there for the  
full resolution of SED. Once this is done the actual signaling and  
possibly media are handed over to the indirect peer (if needed)

Now for some specific comments...

On page 4 - Location server - this definition fits more for a "lookup  
Server". Lookup resolves an "owner", Location resolves a SED.

On Page 4 - I still see many "?" in the text - probably needs to be  
quotation marks?

In the definition of 4.1 (page 6) The LUF should be defined as a  
mapping of identifiers (ususally e.164 numbers - NOT necessarily a  
SIP username) and associated responsible domain

In the definition of 4.2 - isn't the result of this query just the SED?

5.1.1 (page 8) - Between step 2 and 3 missing the location function  
where lookup information is converted to SED information

5.1.2 (Page 10) the text for step 2 is correct ("This look-up  
traverses the administrative boundary between the originating and the  
assisting domain") but the diagram shows this as the "transit domain"

Comment on requirements-03

During this afternoon's SPEERMINT session, open issues were posted
concerning a couple of comments that I made some weeks ago. Just to
clarify those comments:

It states in 3.1:
"advertisement and management of ingress and egress
   for session signaling and media".
This issue of advertising is then elaborated further in the document.

I can understand the need to advertise the ingress for signalling - that
is a fundamental part of peering. 

Why does an SSP need to advertise its signalling egress?

Why does an SSP need to advertise its media ingress and egress (other
than what it indicates in SDP offer/answer)?

John