Subject: [Speermint] new version of draft-ietf-speermint-requirements

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 19 Nov 2007 07:03:00 -0700

Until the announcement is sent to the list by the submission tool,
the new version of the requirements draft is available at:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-03
.txt

   This update is a minor revision, mostly a refresh of the ID to
address the comments received as follows:

1/ Comments at IETF and via email from John Elwell:
	+ mis-use of RFC2119 verbs
	+ requirements should not be put on service providers
	+ no need for SSPs to declare/advertize SDE

2/ Feedback from various participants, chairs and Jon Peterson: 
This ID is a speermint requirement document and its main intent is now
to translate the use cases that have been expressed by the wg
(consolidated use case draft plus IM use cases) into a set of
requirements to must be met by protocol mechanisms to enable the use
cases we have.
    => Section 3 has been reworked per the above, showing what text and
use case brings what requirement.  I lacked time to do more analysis and
improve the writing but this should give the orientation.  

Comments welcome.

Jean-Francois.

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 20 Nov 2007 18:30:32 +0100

Well, I took a print-out of -02 on a plane for a review, and before
I managed to type my comments, you release -03. Oh well.

Anyway:

> requirements to must be met by protocol mechanisms to enable the use

This is very positive change of direction. The "this document lists
requirements on SSPs" idea has always been a source of misunderstanding
and confusion. 

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).

Here are some based on my notes plus looking at the diff:

>       SPEERMINT Requirements for SIP-based VoIP Interconnection
>                draft-ietf-speermint-requirements-03.txt

>1.  Introduction
>
>   Peering at the session layer can be achieved on a bilateral basis
>   (direct peering with SIP sessions established directly between two
>   SSPs), or on an indirect basis via an intermediary (indirect peering
>   via a third-party SSP that has a trust relationship with the SSPs),
>   or on a multilateral basis (assisted peering using a federation model
>   between SSPs) - see the terminology document for more details.

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-transit"
and "SSP-transit -- SSP-T".

In other words, is this an example of two indirect peering relationships
or is this just one indirect peering involving three SSPs?

(I don't particularily care one way or the other, I just strive 
for consistency.)

>3.2.  Session Peering Points
>
>      Requirement #1: protocol mechanisms must exist for SSPs to
>      communicate the egress and ingress points of its service domain.
>      The session peering points may be advertized to session peers
>      using static mechanisms or they may be dynamically advertized.
>
>      Notes on solution space: there seems to be general agreement that
>      [RFC3263] provides a solution for dynamic advertisements in most
>      cases of Direct, Indirect and Assistent peering use cases.  There
>      continues to be discussion on how to best use this to advertize
>      peer-dependent SBEs (see below).

Regarding ingress points, this is certainly true for direct peerings.
I don't see how the current RFCs ever announce any egress elements.

>      Requirement #3: the mechanisms recommended for the declaration and
>      advertisement of SBE and SDE entities must allow for peer and
>      media variability.

Good point.

>      Notes on solution space: for advertising peer-dependent SBEs (peer
>      variability), the solution space based on is under specified and
>      there are no know best current practices.  

Yes, this is where RFC3263 in the public DNS is not sufficient.

>      Requirement #4: the mechanisms recommended for the location
>      service must be capable or returning both a target URI destination
>      and a SIP Route.
>
>      Notes on solution space: solutions exist if the protocol used
>      between the SM and the LS is SIP; if ENUM is used, the author of
>      this document does not know of any solution today.

Once again a valid point.  I'm just not 100% sure whether we should nail
down the solution to the SM-LS interface or whether we should be more
open here. (e.g. allow for other ways how the information is learned
by the SM.)

>      Requirement #5: the mechanisms recommended for locating a peer's
>      SBE must be able to convey how a peer should initiate secure
>      session establishment.

Ack.

>
>3.3.  Session Establishment Data (SED)
>
>   The Session Establishment Data (SED) is defined as the data used to
>   route a call or SIP session to the called domain's ingress point
>   ([I-D.ietf-speermint-terminology]).  Given that SED is the set of
>   parameters that the Session Managers and outgoing SBEs need to
>   complete the session establishment, some information is shared
>   between SSPs.  The following paragraphs capture some general
>   requirements on the SED data.

I like the "SIP Route" you mentioned in Req.#5, and perhaps you
should reference it here again, as the next SIP hop information
and the request URI to use are the central components of the SED.

>3.3.1.  User Identities and SIP URIs
>
>      Requirement #6: 

Ack.

>      Requirement #7: 

Ack.

>3.3.2.  URI Reachability
>
>   Based on a well-known URI type (for e.g. sip, pres, or im URIs), it
>   must be possible to determine whether the SSP domain servicing the
>   URI allows for session peering, and if it does, it should be possible
>   to locate and retrieve the domain's policy and SBE entities.

Shouldn't that be "allows direct session peering ..."?

Plus a second sentence like "if the SSP domain servicing the URI can
be reached via an indirect peering involving a transit SSP, the identity
and the ingress elements of this tranit SSP need to be learned".

>   For example, an originating service provider must be able to
>   determine whether a SIP URI is open for direct interconnection
>   without requiring an SBE to initiate a SIP request.  

Hm? How can there be a direct interconnection without a SIP request?
Shouldn't that be "without requiring a pre-established SIP connection"?

>
>      Requirement #8: the mechanisms for session peering must allow an
>      SBE to locate its peer SBE given a SSP hostname or domain name.

Ack.

>      Notes on the solution space: generally well understood in IETF.
>      Open questions exist in how dynamic should the mechanism be to be
>      able to retrieve the domain's policy for secure signaling between
>      SBEs, peer-dependent/media-dependent policies.

Well, it's well understood for direct peering. It's completely undefined
for indirect and assisted peering.

>4.5.2.  Signaling Security and TLS Considerations
>
>      5.  SIP and SBE servers involved in the session establishment over
>      TLS must verify and validate the client certificates: the client
>      certificate must contain a DNS or URI choice type in the
>      subjectAltName which corresponds to the domain asserted in the
>      host portion of the URI contained in the From header.  It is also
>      recommended that VSPs/ASPs convey the domain identity in the
>      certificates using both a canonical name of the SIP server(s) and
>      the SIP URI for the domain as described in section 4 of
>      [I-D.gurbani-sip-domain-certs].  

I'm not up-to-date familiar with the SIP / TLS standards, I just want
to make sure that customer-owned domains in SIP URIs do not cause
troubles here.

-------------------------

This draft is a huge step forward for speermint.

/ol
-- 
/ Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /