Subject: [Speermint] I-D Action:draft-ietf-speermint-architecture-07.txt

From: [email-masked]
Date: Mon, 3 Nov 2008 16:30:01 -0800 (PST)

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)       : S. Khan
	Filename        : draft-ietf-speermint-architecture-07.txt
	Pages           : 21
	Date            : 2008-11-03

This document defines the SPEERMINT peering architecture, its 
functional components and peering interface functions. It also 

 describes the steps taken to establish a session between two peering 
domains in the context of the functions defined.

Conventions used in this document 

The key words "must", "must NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"should", "should NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC-2119[1]

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-architecture-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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://www.ietf.org/mailman/listinfo/speermint

---

From: "Daryl Malas" <[email-masked]>
Date: Mon, 10 Nov 2008 15:52:56 -0700

Reinaldo et al.,

Here are some comments regarding the architecture draft:

- Section 2 - There is still a reference to the "location function",
which has been further defined into the LUF and LRF.

- I am not sure I still understand the value of the speermint network
context diagram.  This seems to be a rather rudimentary concept
associated with this draft.  Does the working group think this provides
value?

- Section 3 - nit in the first sentence - "...for call..." should be
"...for a call..."; "establish" should be "established". 

The procedures in this section seem to be rather ambiguous in my mind.
I think it would be helpful to incorporate more use of the functions
with these procedures.  For example, is procedure 1 "analysis of the
target address" related to the LUF (See related comment on Section
5.1.1.1)?  If so, I would reform procedure 1 to be "The resolution of
the target address via the LUF" or similar.  To me, procedures 2 and 3
are the same, unless you are trying to say that 1 takes place inside the
SSPs network on a local proxy; 2 is really the LUF (if so, I would
re-word this to be clearer); 3 is the LRF (if so, re-word to be
clearer).  Overall, I think this section could be clearer to help the
reader understand how they relate directly to the architectural
functions.

These procedures should provide greater clarity into the LUF/LRF
discussions taking place in DRINKS.

- I noticed throughout the document that functions, such as LUF/LRF, are
described simply as the definition in the terminology draft and not
expanded upon in relationship to the architecture.  For example, where
can these functions reside?  Are they always at the federation level?
If so, where are they in the federation?  Does every peer have the
LUF/LRF, or is it a server among all?  These are just some questions
that came to mind as I read these.

- Section 5.1.1.1 - This section implies that internal, private routing
does not require the use of the LUF.  I would disagree with this
assertion.  A federation ENUM server will potentially include AoR's for
all peering SSPs.  An originating SSP may query the ENUM server and
receive a SIP URI that contains a local FQDN, which it routes to a local
proxy.  I think this determination can take place in a single LUF step.

- Section 5.1.1 - This section does not mention the ability to use a SIP
redirect server as an option.  Should Section 5.1.3 be part of 5.1.1?

- Section 5.1.3 - nit: seems to have an "and" out of place in the 3rd
paragraph; and, is the 4th paragraph missing a "." at the end?

Is realistic to think an SBE may include an SF?  The SF is a capability
of SIP processing elements such as a SIP proxy, SBE, and user agent.

"The optional termination and re-initiation of calls are performed by
the signaling path border element (SBE)." - I think an application
server or UA could also perform a termination and re-initiation, such as
a hosted 'transfer', 'hold', and 'call forward' (using REFER); if I am
understanding this section correctly.

- Section 5.1.2.2 -"the initiating peer may apply local policy to decide
whether forwarding requests to the target domain is acceptable"  -- This
seems to be out of place in a section call SIP DNS Resolution.  Also, I
think it should probably just be called DNS Resolution.

"in the global DNS" -- Could this also be a federation, enterprise, and
SSP DNS?

- Section 5.1.3.1 - nit: this section seems to have a numbering issue
with "Establishing a Trusted..."?  Has this section been updated based
on the recent requirements and "saverio" draft regarding security?

- Section 5.2.1 - The Location Function no longer exists.  Also, this
section does not talk about the terminating SSP performing any type of
LRF.  I think LRF can occur in a Indirect SSP and at the terminating
SSP. 

- Section 5.2.1.1 - I think this section is really to be covered by work
in DRINKS.  For the sake of Speermint, I think this step is understood.
(Same for Section 5.2.1.2).

- What is the difference between a Terminating SSP and a Target SSP
(Section 5.2 and 5.3)?

Also, these sections have 'TLS' thrown in, while Section 5.1.3 has a
more extensive section (5.1.3.1.) on security.

- Section 5.2.2 - I would expect an introduction to this concept
relevant to the peering reference architecture, and it's role.

- Section 5.4 - This section is just a copy of the term from the
terminology draft.  Is there no considerations around this function
relevant to the architecture?

- Section 8 - It still says "TODO:  Address RFC-3552 BCP items."  This
was in the previous version, as well.

Regards,

Daryl

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Monday, November 03, 2008 5:30 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Speermint] I-D 
> Action:draft-ietf-speermint-architecture-07.txt
> 
> This draft is a work item of the Session PEERing for 
> Multimedia INTerconnect Working Group of the IETF.
> 
> 
>  describes the steps taken to establish a session between two 
> peering domains in the context of the functions defined.
>  
>