Subject: [Speermint] RE: Comments on Requirements Draft

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 14 Sep 2006 15:29:42 -0600

Adam,

   Thank you for your comments. I incorporated most of them in the
updated ID. See inline for details.

Jean-Francois.

> -----Original Message-----
> From: Uzelac, Adam [mailto:[email-masked]]
> Sent: Friday, July 14, 2006 2:48 PM
> To: Jean-Francois Mule
> Cc: [email-masked]
> Subject: 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.

Yes, our goal was to get something out to generate discussions and we
have had some good debates. Now, the hope is to get more focus on actual
requirements and per Jason's note, the interim wg meeting should help.

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

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

Changed the title:
s/Unified/Flexible

We should consider collapsing this whole section into something like
generic requirements and a list of bullet points. Remember this was
taken as-is from the initial req. draft.

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

I see the point but this is more a terminology point. Inter/Intra-domain
is not defined in draft-04 of our terminology draft and I'd prefer not
starting spreading this in the requirements doc.
Also, while intra-domain is not our focus, nothing precludes a VSP from
managing intra-domain peering using sub-domains and applying the same
speermint rules (it still is not our focus but why bother excluding
this?).

> 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.  ;)
Renamed to "URI Reachability".

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

I fixed the grammar but left the section as-is (I'm not convinced this
paragraph needs to stay in the document long term).

> 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.
Not sure I get your point, this section is saying: VSPs can do whatever
to accept/reject calls based on 'policies' and speermint should
accommodate all or any policy. 
Can you propose some rewording?

> 2.7.  Minimal additional cost on call initiation
> 
> I think that this should be changed to "Minimal transaction cost".
This proposed edit may be changing the meaning I think as some folks
will read that we now imply a per transaction cost.
Left it unchanged.

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

Agreed, removed given the ID title "minimum set of req for voip
interconnect".

> 
> ======================
> 
> That's all I have for now.
> 
> Adam

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