Subject: Re: [Speermint] [wg-business] WGLC for draft-ietf-speermint-terminology-12

From: Daryl Malas <[email-masked]>
Date: Thu, 25 Oct 2007 17:08:16 -0600

Otmar, I apologize for taking so long to respond to your comments.
Thank you for taking the time to review and provide feedback.  Comments
in-line...

(FYI...I'm updating the draft right now.)

On Tue, 2007-09-18 at 17:48 +0200, Otmar Lendl wrote:
> On 2007/09/18 14:09, "Livingood, Jason" <[email-masked]> wrote:
> > Just a reminder that WGLC on this draft closes tomorrow.  If you have
> > any comments, please post them to this list.
> 
> Ok, I'll bite (sorry for the last minute input).
> 
> >
> >2.  SPEERMINT Context 
> >
> >   while the horizontal lines indicate working group scope. While the 
> >   SPEERMINT working group is not limited (or coupled in any way) to the 
> >   use of E.164 numbers, in the case shown here an E.164 number [5] is 
> >   used as a key in an E.164 to Uniform Resource Identifier (URI) 
> >   mapping (ENUM [4]). That URI is in turn used to retrieve a Naming 
> >   Authority Pointer (NAPTR) record [3], which is in turn resolved into 
> >   a SIP URI.  Call routing is based on the resulting SIP URI. 
> 
> This is an incorrect description of ENUM.
> 
> The E.164 number is turned into a FQDN, and based on that FQDN the DNS
> is queried for NAPTR records. I recommend changing the last sentences to
> 
> "The result of this step (which involves looking up NAPTR records
> in the DNS) is a SIP URI, on which the subsequent call routing is based."
> 
I agree.

> >   Note that 
> >   the call routing step does not depend on the presence of an E.164 
> >   number. Indeed, the resulting SIP URI may no longer even contain any 
> >   numbers of any type. In particular, the SIP URI can be advertised in 
> >   various other ways, such as on a web page. 
> >
> 
> Correct.
> 
> I have issues with this diagram: The basic idea is good and helpful, but
> it isn't clear what piece of data is actually handed off between the
> layers.
> 
> >           E.164 number <--- Peer Discovery  
> 
> I don't understand what "Peer Discovery" is doing here. IMHO that's
> definitly a part of the speermint WG's work and thus should not
> appear in the ENUM section of the diagram.
> 
Keep in mind, the breakout is not chronological to the steps to complete
a call with a peer.  It appears to me your comments are generally around
a view of this diagram depicting a chronological view of events.

> >                | 
> >                | <--- ENUM lookup of NAPTR in Domain Name System (DNS) 
> >                | 
> >                | 
> >                | ENUM Working Group Scope 
> >           =====+==================================================== 
> >                | SPEERMINT Working Group Scope 
> >           Lookup 
> >           Discovery <--- Session Establishment Data (SED)                    
> >           SIP URI 
> 
> According to the SED definition below, SED is definitly not
> the input into the speermint WG scope; instead I see it as
> the result of this step:
> 
I disagree with some of this.  Although, I could agree the "SIP URI" is
not part of the scope of SPEERMINT, it is derived of information
attained through steps defined in SPEERMINT.

Lookup = Look-up Function
Discovery = Location Function
SIP URI = Derived information from these prior to functions

> >                | 
> >                | <--- Federation Detection, Policy 
> >                |      Lookup, and Service Location 
> 
> 
> >                | 
> >                | 
> >           Hostname <--- Addressing and session establishment 
> >                | 
> 
> 
> >                | SPEERMINT Working Group Scope 
> >           =====+==================================================== 
> >                | Out of scope for the SPEERMINT Working Group 
> >                | 
> >                | <--- Lookup of A and AAAA in DNS 
> >                | 
> >           IP address 
> >                | 
> >                | <--- Routing protocols, ARP [14] etc. 
> >                | 
> >           MAC-address 
> >
> >                  Figure 1: Session Interconnect Context 
> 
> 
> What about:
> 
>            INPUT: E.164 number
>                 | 
>                 | ENUM lookup of NAPTR in Domain Name System (DNS) 
>                 | 
>                 | ENUM Working Group Scope 
>            =====+=== INPUT/OUTPUT: SIP URI/AoR ======================== 
>                 | SPEERMINT Working Group Scope 
>                 | 
>                 | Federation Detection, Peer Discovery, Policy Lookup.
>                 | 
>                 | -> Determination which SSP to hand to call to
>                 | 
>                 | Service Location lookup to derive details of the
>                 | peering: Addressing and session establishment.
>                 | 
>                 | SPEERMINT Working Group Scope 
>            =====+=== I/O: Session Establishment Data (SED)  ========== 
>                 | Out of scope for the SPEERMINT Working Group 
>                 | 
>                 | Lookup of SRV/A and AAAA in DNS (RFC 3263)
>                 | 
>                 | SIP message generation.         (RFC 3261)
>                 | IP Routing
>                 | 
> 
> >   Note that in Figure 1, Session Establishment Data (SED), is the data 
> >   used to route a call to the called domain's ingress point (see 
> >   Section 3.3 for additional detail). 
> >
> 
> >   As illustrated in Figure 1, the ENUM Working Group is primarily 
> >   concerned with the acquisition of SED while the SPEERMINT Working 
> >   Group is focused on the use of such SED in routing session signaling 
> >   requests. Importantly, the SED can be derived from ENUM (i.e., an 
> >   E.164 DNS entry) or via any other mechanism available to theuser. 
> 
> Again: this does not match the definition of SED. Proposed change:
> 
> 
>    As illustrated in Figure 1, the ENUM Working Group is primarily
>    concerned with the acquisition of SIP URI while the SPEERMINT Working
>    Group is focused on determing the Session Establishment Data (SED)
>    needed to the send a SIP message to a suitable next hop (on the SIP
>    layer). The ENUM step (the translation from E.164 number to SIP
>    URI) is optional if the user entered a SIP AoR directly as his call
>    target.
I'm okay with most of this....I would like to suggest this change to the
first sentence: "...to send a SIP message to a suitable SSP's (See
Section 3.9 below) SIP proxy or SBE (See Section 3.1 below).  The ENUM
step..."

> 
> >   Finally, note that the term "call" is being used here in the most 
> >   general sense, i.e., call routing and session routing are used 
> >   interchangeably. 
> >
> >3. General Definitions 
> >
> >
> >3.3. Session Establishment Data 
> >
> >   Session Establishment Data, or SED, is the data used to route a call 
> >   to the called domain's ingress point. A domain's ingress point can be 
> >   thought of as the location pointed to by the SRV record [1] that 
> >   resulted from the resolution of the SED (i.e., a SIP URI). 
> 
> brr.
> 
> What about
> 
>                                          A domain's ingress point is
>    the SBE which will accept incoming calls from the originating SSP.
>    
How about: "A domain's ingress point is the proxy or SBE which will
accept incoming calls from the originating SSP."
> > 
> >   More specifically, the SED is the set of parameters that the outgoing 
> >   SBEs need to complete the call, and may include: 
> >
> >     . A destination SIP URI 
> >
> >     . A SIP proxy to send the INVITE to, including 
> >
> >          o  Fully Qualified Domain Name (FQDN) 
> >
> >          o  Port 
> >
> >          o  Transport Protocol (UDP/TCP/TLS [9/10/11]) 
> >
> >     . Security Parameters, including 
> >
> >          o  TLS certificate to use 
> >
> >          o  TLS certificate to expect 
> >
> >          o  TLS certificate verification setting 
> >
> >     . Optional resource control parameters such as 
> >
> >          o  Limits on the total number of calls to a peer 
> >
> >          o  Limits on SIP transactions/second 
> >
> >          o  Limits on the total amount of bandwidth used on a peering 
> >             link 
> >
> >          o  In addition, lower layer parameters (such as Differentiated 
> >             Services Code Point (DSCP) [8] markings on SIP and/or media 
> >             packets) might also be included. 
> 
> Perhaps one need to point out that the SED which carrier A uses to talk
> to carrier B does not need to be equal to the SED that carrier C uses
> when talking to B.
I agree, but I do not think it is necessary.  There is no mention in the
draft of exclusivity.  Is this necessary?  I do not believe it is.  I
think this is understood.

> 
> >
> >3.4. Call Routing 
> >
> >   Call routing is the set of processes, rules, and SED used to route a 
> >   call to its proper (SIP) destination.  More generally, call routing 
> >   can be thought of as the set of processes, rules and SED which are 
> >   used to route a real-time session to its termination point. 
> 
> Please strike SED from this paragraph.
As I described earlier, I think the Look-up and Location functions are
part of deriving SED for peering.

> 
> >
> >4.2.1. Direct Peering 
> >4.2.2. Indirect Peering 
> >4.2.3. Assisted Peering 
> >4.2.4. On-demand Peering 
> >4.2.5. Static Peering 
> 
> These definition are good. Perhaps add a paragraph like this:
> 
>    The concepts direct/indirect, assisted/not-assisted, and on-demand/statis
>    are orthogonal to each other. All eight combinations are possible.
The orthogonal representation is stated in the last sentence of both
4.2.4 and 4.2.5.  Let me know if you think it should still be added
separately.
> 
> >
> >4.3. Functions 
> >
> >   The following are terms associated with the functions required for 
> >   peering. 
> >
> >4.3.1. Look-Up Function 
> >
> >   The Look-Up Function (LUF) provides a mechanism for querying an 
> >   internal and/or external database, which maintains a list of SIP user 
> >   names and associated peering domains. 
> 
> "user names"?
[email-masked] ...could be "user part"
> 
> This reeks of number-based lookups via the back-door of encoding
> them in the username part of SIP URIs. I don't like this.
> 
> >4.3.2. Location Function 
> >
> >   The Location Function (LF) develops call routing data (CRD) by 
> >   discovering the Signaling Function (SF), and SF's reachable host (IP 
> >   Address and port). 
> 
> Didn't we replace CRD with SED?
Yes...oversight, thanks...will replace.
> 
> >4.3.3. Signaling Function 
> >
> >   The SF performs routing of SIP messages, to optionally perform 
> >   termination and re-initiation of the call, and to assist in the 
> >   discovery/exchange of parameters to be used by the Media Function 
> >   (MF). 
> >
> >4.3.4. Media Function 
> >
> >   The MF performs media related functions such as media transcoding and 
> >   media security implementation between two SSPs. 
> 
> IMHO these two are obsolete. Isn't SF replaced by SDE and MF by DBE?
I don't think so...it was my understanding they are in addition to SBE
and DBE.  Hence, my comments about proxy and SBE earlier.  Are we saying
an SBE is a proxy...I think of it more like a B2BUA.
> 
> >5. Federations 
> >     Finally, note that a SSP can be a member of 
> >
> >          o  No federation (e.g., the SSP has only bilateral peering 
> >             agreements) 
> 
> I still think that  bilateral peerings are special cases of federations
> (i.e. one with exactly two members), but I don't insist on that.
I thought we agreed a federation must contain more than 2 SSP's.  I
suggest we update the following sentence:

"A federation is a group of SSPs which agree..." to "A federation is a
group of three or more SSPs which agree..."
Thoughts?
> 
> HTH,
> 
> /ol
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint

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