Subject: [Speermint] Comments on Requirements Draft rev.04

From: "Daryl Malas" <[email-masked]>
Date: Mon, 10 Mar 2008 08:23:17 -0600

Jean-Francois,

I have some comments regarding the requirements:

Requirement #2:
      "Protocol mechanisms should exist for a SIP Service Provider (SSP)
      to communicate the egress SBEs of its service domain."

[DM] IMO, this looks more like a provisioning parameter for the SSP.
Why would a SSP communicate this information?  Wouldn't this information
be pertinent to the SSP itself?  For example, I do not care what SBEs my
peer chooses to use to egress traffic.  Now, that being said, I might
want to know what IP addresses the peer "might" originate their traffic
to me from, but in the "SIP world" this is not a reality.  The only
purpose of this, I can think of, is for me to implement ACL's for
allowing traffic only from a specific set of peer addresses.  At best,
this implementation choice would be a MAY and not a requirement.

Requirement #3: (see comment on Req #2)

"Some SSPs may have some restrictions on the type of media traffic
   their SIP entities acting as SBEs are capable of establishing.  In
   order to avoid a failed attempt to establish a session, a mechanism
   may be provided to allow SSPs to indicate if some restrictions exist
   on the type of media traffic: ingress and egress SBE points may be
   peer-dependent, and/or media-dependent."

[DM] This seems more like a "policy" requirement on codecs or service
types, yet there is no mention of policy in the requirement.

Requirement #4:

"The mechanisms recommended for the declaration or advertisement of
      SBE and DBE entities must allow for peer and media variability."

[DM] In your example, it appears you are intending to mean "...allow for
peer, media, and service-type variability."

[DM] "...media-dependent SBEs" = DBE?

[DM] "Lookup Function (LUF) or Location Routing Function (LRF)"  I
suggest change "or" to "and/or".

Requirement #5:
      "The mechanisms recommended for the lookup and location routing
      service must be capable or returning both a target URI destination
      and a SIP Route."

[DM] What is a "SIP Route"?  I do not think this is defined anywhere.

Requirement #7:
      "The protocols used for session peering must accommodate the use
of
      different types of URIs.  URIs with the same domain-part should
      share the same set of peering policies, thus the domain of the SIP
      URI may be used as the primary key to any information regarding
      the reachability of that SIP URI."

[DM] Should we specify only one set of policies can be configured per
domain?  I think the policies may vary based on SBEs and DBEs.  For
example, I may have different policies for high volume SBE's.

Requirement #15:
   "The protocols used for the LUF and LRF must allow the look-up and
SED
   data to be exchanged securely (authentication and encryption services
   should be provided)."

[DM] "...the look-up and SED data..."  Is this simply stating the
look-up and response?  Also, if the LUF/LRF is located within an IPVPN,
does it matter if the exchange is further encrypted?  I do not think
this should be a requirement in all cases, but should be recommended.
For example, in SIP, RFC 3261 does not require the use of TLS, but
rather the support of TLS.

--Daryl

---------------------
Daryl Malas
CableLabs
[email-masked]
tel:+1-303-661-3302

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

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 12 Mar 2008 07:10:25 -0600

Daryl,

   Thank you for the comments.  See inline.

Jean-François

> -----Original Message-----
> From: [email-masked] [mailto:speermint-
> [email-masked]] On Behalf Of Daryl Malas
> Sent: Monday, March 10, 2008 8:23 AM
> To: Jean-Francois Mule; [email-masked]
> Subject: [Speermint] Comments on Requirements Draft rev.04
> 
> Jean-Francois,
> 
> be pertinent to the SSP itself?

It is relevant for capacity planning, traffic engineering, and call admission control.  See my response to John.
I flagged this as an open issue for discussion at the meeting.

> For example, I do not care what
> SBEs my
> peer chooses to use to egress traffic.  

Take this example:
2 SSPs agree to do L5 peering in multiple locations, including NYC and Paris. SSPa does not want to carry the cost of transporting media from Paris to NYC for SSPb and requires that calls from subscribers of SSPb originated in Paris to subscribers of SSPa in NYC be carried on SSPb's network all the way to NYC and then be egressed in NYC to SSPa. SSPa requires a list of SBEs from SSPb at the various POPs to restrict CAC based on originating or egress SBE.

SSPa cares.
The thing to realize is that there is no requirement to use such mechanisms and some providers may just accept SIP traffic from any egress points of their peers.  Some may need a way to know where the traffic will originate to size transit links appropriately, do some CAC in absence of widely implemented authentication services.

> Now, that being said, I might
> to me from, but in the "SIP world" this is not a reality.  
I do not understand "SIP world" - it is not in the terminology document :)
I thought we agreed in speermint on SSPs (which include enterprises, groups of users, service providers that serve subscribers).  
Does anyone believe that enterprise IT folks, when they manage SIP trunks or set-up site-to-site sip calls, they do not ask for egress SBEs of their peers?  The point here is to have a mechanism to discover and advertize these.

> The only

MAY use - sure.
A "MAY use" implies there should be a mechanism to do this for SSPs that want this.  Or folks can keep using trouble tickets and email notices.

> types, yet there is no mention of policy in the requirement.

See Penn's comments.  
This is not policy-related but expressing the need to have a protocol mechanism to allow some SSPs that want this to say:
	- peerA: use this SBE
	- peerB: use that SBE
	- peer A: use this SBE for voice traffic, this SBE for IM because it supports additional methods

> peer, media, and service-type variability."
Yes.  This relates to one of John's comment.
Edited the text to add "service-type".
Thanks.

> [DM] "...media-dependent SBEs" = DBE?
No, the text intends to mean SBEs that are media-dependent or media-specific.  Should I update the text? If so, can you propose how?
	
> suggest change "or" to "and/or".
Ok.

> [DM] What is a "SIP Route"?  I do not think this is defined
A SIP Route is defined in RFC 3261 by a SIP Route header.
http://tools.ietf.org/html/draft-rosenberg-sip-route-construct-02
And:
http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-siptrunk-00.txt

  Usage of the Route header field allows for complete separation of the
   intended target of the request (present in the Request-URI) from the
   intermediate logic that is to be applied to the request before
   arriving at that target (identified by the topmost Route URI).

Changed "a SIP Route" to "a value for the SIP Route header" is that makes it more readable.

> example, I may have different policies for high volume SBE's.

I thought we had wg consensus to declare policies out of scope, so I would not put requirements based on policies (hence the move of the text to appendix A and the clarifications in section 3.4 which based on John's comments is also moved to the appendix).

> look-up and response? 
Ok, changed SED to response.

 Also, if the LUF/LRF is located within an
> IPVPN,
> does it matter if the exchange is further encrypted?  I do not
Lower layers - out of our scope.  I don't think it matters.

> think

Requirement #15 now says
   The protocols selected for the LUF and LRF must allow the look-up and response
   to be exchanged securely (authentication and encryption services
   should be provided).

I think this should address your comment and clear the confusion.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Mar 2008 11:40:47 -0400

> 	- peer A: use this SBE for voice traffic, this SBE for IM because it supports additional methods

I don't understand the last point. It implies that all the media to be 
used during a dialog be known at dialog establishment time. Given the 
ability to add media at any time during the dialog this is not a 
realistic requirement.

Or do you propose to eliminate the option to renegotiate media? This is 
a major feature to deprecate.

	Paul