Subject: RE: [Speermint] Comments on Requirements Draft

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 17 Jul 2006 10:40:25 -0400

A couple nuances inline... 

> -----Original Message-----
> From: Uzelac, Adam [mailto:[email-masked]] 
> Sent: Friday, July 14, 2006 4:48 PM
> To: Jean-Francois Mule
> Cc: [email-masked]
> Subject: [Speermint] Comments on Requirements Draft
> 
> Jean-Francois,
> 
> Here's some feedback on the Requirements document - though 
> this is a good start, as you pointed out in your presentation 
> at the WG session, there's work that needs to be done to hone 
> in on the requirements.  You asked the WG in your 
> presentation slot if the requirements should stay as one 
> document or split into different documents.  I can't recall 
> what was ultimately decided or if this wasn't addressed at 
> all. I believe it important that we only have one document.  
> 
> I will start with 'General Requirements' for now.
> 
> ======================
> 
> 2.1.  Unified solution for session peering policies - 
> 
> We might consider replacing the word "Unified" with 
> "Flexible".  The text in this section points out that polices 
> SHOULD be extensible and flexible, but I am not sure that 
> means Unified.  Also, in the quick references to the 
> different models ("closed, open, etc) the context and 
> definition of policies changes wildly.
> 
> 2.2.  Domain Based
> 
> I think we should rename this section as well to Domain-based Context.
> The point, as I read it, is that the domain is the first and 
> most basic construct in forming peering.  Ultimately it's the 
> interconnection of 2 or more domains that defines peering.  
> Call routing is to or from the domain.  The text states, 
> "...call routing should rely on URIs."  Beyond this point 
> though, there is some "squirreliness" when stating that "We 
> assume that all SIP URIs with the same domain-part share the 
> same set of peering polices".  I think that's an assumption 
> that we can not safely, nor logically make.  I suggest that 
> we point out that a intra-domain is out of scope, and 
> inter-domain is what we are trying to define.

Are we really trying to say that if one contacts a policy server serving
that domain name, we can get access to a *set* of peering policies?  Not
all policies in the set may be applicable, depending on who is asking
and which element in the domain is targeted.

There may be some ambiguity between mappings of domain elements to
ingress proxies operated and associated with certain policies.

> 2.3.  No blocked calls
> 
> As I understand the intention of this requirement, it's 
> basically about reachability - meaning - Do I know that 
> something is out there willing to peer with me before I 
> attempt to connect? The text reads...
> 
>    An originating service provider must be able to determine whether a
>    SIP URI is open for direct interconnection without 
> actually sending a
>    SIP INVITE.  This is important as unsuccessful call attempts are
>    highly undesirable since they can introduce high delays due to
>    timeouts and can act as an unintended denial of service attack.
>    (e.g., by repeated TLS handshakes).
> 
> I propose that change the section heading to "Universal Reachability".
> I was going to suggest "Global", but I don't want to offend 
> our little green martian friends.  ;) 

I think there could be blocked calls for those that do not adhere to the
policies governing the peering.  Would this better be phrased as:  High
Probability of Call Completion for Policy-Conforming Peers

We could also throw in that conformance is enhanced because the policy
is easily discoverable, but that is getting a bit wordy.

> 2.5.  Independence of lower layers
> 
> *NIT* - "...on what technologies are used route the call.."  
> Need to add a "to" in between "used" and "route".
> A couple thoughts - I agree with the intent of the section 
> but think that it's mis-labeled.  The section heading should 
> be something like "Access and Security Agnostic" or something 
> like that.  We shouldn't the lower layer (Ethernet or POS), 
> and there are references to upper layers as well (TLS).  

Agree.  There is a dependence in some respects.  
Could you say:  Accommodate flexible use of diverse supporting lower
layers?

> 2.6.  Administrative and technical policies
> 
> This section I think it's going to be very difficult to build 
> consensus on within the WG.  Mostly due to our having to find 
> some common ground on what should be WG mandate versus Local 
> Policy.  I believe that we should have a requirement on core 
> set of policies to consider exchanging, but after the 
> suggestion to exchange information, SPEERMINT scope ends.

It may be best to have some meta-categories of things that a well-formed
policy should cover.
Example:

Policies should address authentication,
Policies should address minimal signaling mechanisms,
Policies should address minimal codec sets,
... whatever.

In effect it is all local policy, but what is needed to be covered to be
complete and sufficient.

Mike

> 2.7.  Minimal additional cost on call initiation
> 
> I think that this should be changed to "Minimal transaction 
> cost".  The text pertains to discovery of peering next-hop, 
> connection to next-hop and potentially bearer (if determined 
> within scope).
> 
> 2.8.  Look beyond SIP
> 
> I am struggling with this one a bit.  I believe this should 
> removed altogether.  If we should consider a requirement 
> beyond SIP, then we should re-charter as "PEERMINT"  ;)
> 
> ======================
> 
> That's all I have for now.
> 
> Adam
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 

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