headers
Daryl Malas | 5 Jul 2007 20:35

Re: NITS review for draft-ietf-speermint-terminology-07

Alexander,

Thank you...I will update draft.

--Daryl

On Thu, 2007-06-28 at 12:43 +0200, Alexander Mayrhofer wrote:
> Hi,
> 
> I've done a NITS review on the draft - my comments are as follows:
> 
> - the automatic idnits checker reports a few problems - most notably, the
> draft does not seem to contain any proper page breaks (confirmed here while
> printing the draft).
> 
> - The document contains a lot of acronyms that are never expanded/refered -
> I've seen NAPTR (section 1), SRV (section 3.3), TLS (section 3.3), DSCP
> (section 3.3), UAS/UAC (section 3.7), BGP (section 4.1), RTCP/RTCP-XR
> (section 5). In most cases, an informative reference would also be good.
> 
> - I'm slightly confused by section 3.8 vs. 3.9 - i think the difference
> between those definitions would become much clearer if we would change "...
> that provides transport ..." to "... that provides application level
> transport ..." in section 3.9 - otherwise it's really hard to distinguish
> those two definitions. (SP = "my ISP", SSP = "my voip provider" if i got it
> right?)
> 
> - Section 4.2 mandates Layer 5 peering to be "secure call signaling". Does
> that mean that plain RFC3261/RFC3263 SIP signaling over UDP/TCP does not
> qualify? Same applies to section 4.2.2
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jean-Francois Mule | 5 Jul 2007 23:43
Favicon

comments on draft-ietf-speermint-voip-consolidated-usecases-02


Find below some comments on
draft-ietf-speermint-voip-consolidated-usecases-02.

--- editorial
- Given this is a use case document, is "Intended status: Standards
Track" correct? The charter says Informational.
- terminology draft-07 alignment:
The use case I-D still has too many definitions and some terms used in
the description of the use cases (like session manager) are not in the
terminology draft-07. This section could be reduced by introducing the
conventions used for logical entities that are in the originating (O-),
terminating (T-) or transit (t-) domains.

--- technical
- The use case examples dedicate quite a bit of time & text to describe
what all the variants are within one SSP/user group domain: does the
originating or terminating "domain" have SBE, SDE, SM, LS, etc.?

I am not sure I understand where this leads us in terms of requirements
on the interconnect points. 
Each user group or service provider mging a domain can do whatever they
want and add as many layers of indirect signaling/media as they wish. I
thought that elements "at the boundary" of the networks were the ones
where we wanted speermint to focus on. 
==> what are the differences between (4) in figure 2, (5) in figure 3,
and (5) in figure 4 -- just to focus on signaling?
==> if there are differences, why do they matter for best current
practices?
Beyond the labels of the boxes being different, at this stage, the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet | 6 Jul 2007 00:15
Picon
Favicon

I-D ACTION:draft-ietf-speermint-consolidated-presence-im-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.

	Title		: Presence & Instant Messaging Peering Use Cases
	Author(s)	: A. Houri, et al.
	Filename	: draft-ietf-speermint-consolidated-presence-im-usecases-02.txt
	Pages		: 9
	Date		: 2007-7-5
	
The document describes several use cases of peering of non-VoIP
   services between two or more Service Providers (SP).  These Service
   Providers create a peering relationship between themselves thus
   enabling their users to collaborate with users on the other Service
   Provider network.  The target of the document is to drive
   requirements for peering between domains that provide the non-VoIP
   based collaboration services and presence and Instant Messaging (IM)
   in particular.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-consolidated-presence-im-usecases-02.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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jean-Francois Mule | 6 Jul 2007 12:25
Favicon

speermint terminology draft07: on-demand and static

Draft 07 says:
---
4.2.1. Direct Peering 

   Direct peering describes those cases in which two service providers 
   interconnect without using an intervening layer 5 network.
...
and then

4.2.4. On-demand Peering 

   Service providers are said to peer on-demand when they are able to 
   exchange traffic without any pre-association prior to the origination

   of a real-time transaction (like a SIP message) between the domains. 
   Any information that needs to be exchanged between domains in support

   of peering can be learned through a dynamic protocol mechanism.

4.2.5. Static Peering 

   Service providers are said to peer statically when pre-association 
   between providers is required for the initiation of any real-time 
   transactions (like a SIP message).
-----

First, I read this as the debate we had on static vs. dynamic policy is
now moving into the basic definitions of peering. I view this ("this"
being static vs. on-demand association) as separate from the type of
peering and distinct for the 3 basic definitions we had (direct,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daryl Malas | 6 Jul 2007 15:43

Re: speermint terminology draft07: on-demand and static

So, I updated 4.2.4 and 4.2.5 with the caveat that both of these are
applicable to direct, indirect, assisted.  I was hoping this would
clarify these from being considered an "either/or" situation to a
"and/also" situation.

I can remove them entirely if we want to go back down that road, but I
think it is clearer now.  I just submitted a revision last night, so
take a look at -08 and let me know what you think.

Thanks...--Daryl

On Fri, 2007-07-06 at 04:25 -0600, Jean-Francois Mule wrote:
> Draft 07 says:
> ---
> 4.2.1. Direct Peering 
> 
>    Direct peering describes those cases in which two service providers 
>    interconnect without using an intervening layer 5 network.
> ...
> and then
> 
> 4.2.4. On-demand Peering 
> 
>    Service providers are said to peer on-demand when they are able to 
>    exchange traffic without any pre-association prior to the origination
> 
>    of a real-time transaction (like a SIP message) between the domains. 
>    Any information that needs to be exchanged between domains in support
> 
>    of peering can be learned through a dynamic protocol mechanism.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet | 6 Jul 2007 20:15
Picon
Favicon

I-D ACTION:draft-ietf-speermint-terminology-08.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		: SPEERMINT Terminology
	Author(s)	: D. Malas, D. Meyer
	Filename	: draft-ietf-speermint-terminology-08.txt
	Pages		: 12
	Date		: 2007-7-6
	
This document defines the terminology that is to be used in 
   describing Session PEERing for Multimedia INTerconnect (SPEERMINT).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-08.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-terminology-08.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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daryl Malas | 6 Jul 2007 22:03

Release Notes: draft-ietf-speermint-terminology-08

The following updates were made in -08:

- I expanded as many acronyms as I could find.  I also put references in
for almost all of them too.

- I updated section 3.9 and made a clarification in 3.8 to provide an
ISP as an example SP.

- I removed "secure" from section 4.2 and 4.2.2

- I added clarification to "static" and "on-demand" that either can be
used for "direct/indirect/assisted" peering types

- I changed the case of "Codec"

- I changed "SIP" to "SSP" and other "SP" references to "SSP" in section
5.

- Also, there should be page breaks now.

- I also tweaked a couple of other things as minor nits.
Permalink | Reply | 2 comments |
headers
Daryl Malas | 6 Jul 2007 22:07

Re: Release Notes: draft-ietf-speermint-terminology-08

Also, FYI...a -09 version will likely be rolling off very soon, so if
you have comments, please send them to me ASAP!

Thanks...--Daryl

On Fri, 2007-07-06 at 14:03 -0600, Daryl Malas wrote:
> The following updates were made in -08:
> 
> - I expanded as many acronyms as I could find.  I also put references in
> for almost all of them too.
> 
> - I updated section 3.9 and made a clarification in 3.8 to provide an
> ISP as an example SP.
> 
> - I removed "secure" from section 4.2 and 4.2.2
> 
> - I added clarification to "static" and "on-demand" that either can be
> used for "direct/indirect/assisted" peering types
> 
> - I changed the case of "Codec"
> 
> - I changed "SIP" to "SSP" and other "SP" references to "SSP" in section
> 5.
> 
> - Also, there should be page breaks now.
> 
> - I also tweaked a couple of other things as minor nits.
> 
> 
> _______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daryl Malas | 7 Jul 2007 00:29

Terminology Draft vs. VoIP Usecases Draft Terminology

Adam et. al. (Authors of
"draft-ietf-speermint-voip-consolidated-usecases"),

Okay, I read through the terminology of the "voip-consolidated-usecases"
draft, and here is my analysis:

Remove the following term definitions from your draft, because they
are already covered in the terminology draft:

Direct Peering
Indirect Peering
Assisted Peering
Federations (Note...you have Federations in your terminology section
twice!)
Voice Service Provider (Now SSP in Terminology draft)
Signaling Border Element
Data Path Border Element
Peering Service Provider - The function of this is included in the SIP
Service Provider definition.
Direct PSP - I think this is also covered by existing definitions
Assisting PSP - Same as Direct PSP comment.

There are 3 (1 definite, 2 questionable) terms, which should be added to
the next rev. of the terminology draft:

Location Server
Session Manager - Although I'm not quite sure I understand exactly
what this does.
User Endpoint - Again, I'm not sure what this is, because this should
be a UAC, UAS, or UA in my opinion.  These are well defined in RFC 3261
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Schwartz | 9 Jul 2007 12:10

FW: Terminology Draft vs. VoIP Usecases Draft Terminology


Hi Daryl

I know it's probably too late for this to make it in but I just have a
few comments. You define "Assisted Peering" as employing a central SIP
proxy - therefore forcing a hub-and-spoke model for this category. I see
it differently. I see assisted as "assisting" in call setup but not
necessarily having to be in the actual call path. 

As discussed in previous emails on this thread "Assisted" should be
orthogonal to both direct and indirect and if indeed a centralized SIP
proxy is deployed than this is an instantiation of both assisted and
indirect peering.

I would word 4.2.1 - 4.2.3 as follows...

4.2.1. Direct Peering 

   Direct peering describes those cases in which two service providers 
   interconnect without using an intervening layer 5 network. 

4.2.2. Indirect Peering 

   Indirect, or transit, peering refers to the establishment of a either
   a signaling and media path or signaling path alone via one (or more)

   referral or transit network(s). Transit network may be used for
technical     
   reasons (e.g. signaling interoperability or media transcoding) or non
(Continue reading)

Permalink | Reply | 4 comments |

Gmane