Subject: [Speermint] Comments on Requirements Draft

From: "Uzelac, Adam" <[email-masked]>
Date: Fri, 14 Jul 2006 16:48:28 -0400

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.

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

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

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.

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

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 31 Jul 2006 14:18:01 +0200

Some additional comments from me.

> I will start with 'General Requirements' for now.

Well, the actual policies might vary a lot, but the language in which
these policies are expressed in needs to be the same.

Thus we need a *one* policy language (I think that's how "uniform"
entered this paragraph) which is flexible enough to such that
all peering models can be expressed by it.

So perhaps it should be 

2.1.  Unified session peering policies description language 

> out of scope, and inter-domain is what we are trying to define.

There are two aspects to the Domain question:

a) Domains as in "not numbers". While SIP URIs may have been derived
from E.164 numbers, the peering/routing decisions must not be based 
on telephone numbers. The scheme has to work if the end-user dialed
a SIP URI directly.

b) Is there a need to treat sip:[email-masked] in any form
differently than sip:[email-masked]? The SIP RFCs say "no".
All routing decisions are keyed by the domain only. The user-part 
is only interpreted by SIP servers serving the domain. Thus anybody
else uses just the domain to derive the next hop. I think
that's a very safe assumption.

The only thing which can mess with that assumption would be the SIP
aequivalent to number portability. I really doubt we want to
support that.

> I propose that change the section heading to "Universal Reachability".

I don't think "Universal Reachability" fits. That would indicate that
any SIP URI is reachable. This isn't what the original text says.
This requirement just states that trial-and-error on the SIP layer
is a bad idea. An originating network should find out if there is
a peering possibility before sending any SIP requests to a -- potentially
firewalled -- destination network.

> lower layer (Ethernet or POS), and there are references to upper layers

"Access Agnostic" sounds fine. Security is part of the game here and
I would not rule that out. But we shouldn't talk about how to
connect MPLS networks to ensure QoS or other Layer2/3 issues.

> exchanging, but after the suggestion to exchange information, SPEERMINT

I see Speermint as the framework under which federations can define
their own rules. As such, the framework needs to support (= provide
means of expressing them) all possible administrative and technical
policies. Speermint will fail if it tries to force all federations
to operate under the same rules. But Speermint should try to get all
federations to use the same language to define their rules.

> and potentially bearer (if determined within scope).

Fine.

> should re-charter as "PEERMINT"  ;)

This is optional. A lot of the problems we try to solve in Speermint
are bound to pop up in other contexts as well. If it's easy to 
fomulate our solution in a way that make it adaptable for other
uses as well, then why should try to do so. Maybe XMPP will need
similar mechanisms. SMTP? Who knows. 

That's why I split up my drafts into the generic one and the 
SIP specific one.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >