Subject: [Speermint] I-D ACTION:draft-ietf-speermint-architecture-00.txt

From: [email-masked]
Date: Wed, 09 Aug 2006 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		: SPEERMINT Peering Architecture
	Author(s)	: R. Penno
	Filename	: draft-ietf-speermint-architecture-00.txt
	Pages		: 19
	Date		: 2006-8-9
	
This document defines a SPEERMINT peering reference architecture, its 
functional components and peering interface functions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-architecture-00.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-architecture-00.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-architecture-00.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: "Stastny Richard" <[email-masked]>
Date: Thu, 10 Aug 2006 12:00:55 +0200

Folks,

I have some serious problems with this draft:

Here only the major issues:

1. Figure 1 on page 4

Figure 1 shows the Public Internet and a Service Provider
Private Network. It also shows a Layer 3 peering point
(obviously a NAT/SBC), which is out of scope.

The remainder of the document is basically only talking about
peering via the public Internet and also on page 3 there is
no Interconnection between public and private networks.

So why not dump the private part completely if there is no
use case describing the interworking?

1a: In figure 1 there is also a distinction between SPs and
enterprises, which is not used later in the document

2. Section 3 Procedures on page 5 is listing 8 procedures
which have only a slight mapping the 4 functions mentioned
in section 4.

3. Section 4 Functions general

IMO the scope of the functions still needs some work,
as also elaborated later. Especially the LF is a bit getting
ahead of itself by developing end-users IP address and port
in front of PF and SF.

4. Location function

4a. Section 5.1.1 is out of scope, but may be useful
for information.

What is missing in section 5.1.1 is the analysis and treatment
of non-E.164 numbers (emergency numbers and others)

4b Section 5.1.2 to 5.1.4

ENUM is basically out of scope in spearmint, but could
be useful for information.

IMO opinion the User ENUM Lookup is only optional (also
on the calling user side). A SP may only query User ENUM
if the end-user wants it.

5.1.3 should be called Infrastructure ENUM. What is missing here
is the optional querying of private ENUM

4c. Section 5.1.5

This is where Speermint starts, either receiving a SIP URI
direct or via ENUM. 

IMO it is now to early to start talking about RFC3263, because
We first need to look-up the policy for this SIP URI. 

5. You first need to use the PF to detect if you may peer and under what
conditions. 

e.g. if you exchange the next hop attributes such as location
of the proxies ...

Although, I always thought this is done with the SRV records,
(one also may do simple load balancing with SRV records)

BTW, I am not sure what maximum allowed bandwidth has to do
here

IMO the prime goal of the policy function is to detect if you may
send an INVITE to the target SP or not.

6. TLS

In the PF only the detection of the certificate is handled,
the establishment of the TLS connection belongs already to the SF

These are my major issues

Richard Stastny

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, August 09, 2006 9:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Speermint] I-D
ACTION:draft-ietf-speermint-architecture-00.txt
> [email-masked] with the word unsubscribe in the body of
the
> message.
> 	"FILE
/internet-drafts/draft-ietf-speermint-architecture-00.txt".