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

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 8 Nov 2007 16:22:39 -0500

Title           : SPEERMINT Terminology
	Author(s)       : D. Malas, D. Meyer
	Filename        : draft-ietf-speermint-terminology-13.txt
	Pages           : 13
	Date            : 2007-11-08
	
This document defines the terminology that is to be used in describing
Session PEERing for Multimedia INTerconnect (SPEERMINT).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-13.
txt
========================================================================
=================
The intent of the last call is to solicit comments before submitting the
ID to the IESG.

The purpose of a working group Last Call is in the style of "speak now
or forever hold your peace" in case there are fundamental objections
which have not gotten previous or adequate discussion, or minor errors
which need correction.

Working group last call will extend for 2 weeks from today, 8 November
2007, until 22 November 2007.  Please note that this is the second WGLC
on this document.

Please post any comments in reply to the list, as well as to the
editor(s) of this draft.

Regards,

Jason & Dave

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

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

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 16 Nov 2007 15:42:55 +0000

I still think the concept of SED is confusing. On the one hand it says:
"   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 the user."
This clearly says that SED is input to the SPEERMINT process and can be
provided by the ENUM process. As far as I know, the ENUM process will
only provide a SIP URI.

On the other hand, it states:
"   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 call initiations to a peer 

          o  Limits on SIP transactions/second "

This is clearly in conflict, since it is a lot more than just the SIP
URI and also appears to include a lot of data that is output from,
rather than input to, the SPEERMINT process.
 
John

> -----Original Message-----
> From: Livingood, Jason [mailto:[email-masked]] 
> Sent: 08 November 2007 21:23
> To: [email-masked]
> Subject: [Speermint] [wg-business] WGLC for 
> draft-ietf-speermint-terminology-13
> 
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 21 Nov 2007 09:58:27 -0500

It is easy to identify problems in any document.  ;-)  We're open to any
suggestion on how to resolve this by you.  Please make a proposal to the
list.

Thanks
Jason 

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Friday, November 16, 2007 10:43 AM
> To: Livingood, Jason; [email-masked]; Malas, Daryl; Dave Meyer
> Subject: RE: [Speermint] [wg-business] WGLC 
> fordraft-ietf-speermint-terminology-13
> 
> This clearly says that SED is input to the SPEERMINT process 
> and can be provided by the ENUM process. As far as I know, 
> the ENUM process will only provide a SIP URI.
> 
> This is clearly in conflict, since it is a lot more than just 
> the SIP URI and also appears to include a lot of data that is 
> output from, rather than input to, the SPEERMINT process.
>  
> John
> 
> 
> > The intent of the last call is to solicit comments before 
> submitting 
> > the ID to the IESG.
> > 
> > 2007, until 22 November 2007.  Please note that this is the second 
> > WGLC on this document.
> >

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 21 Nov 2007 21:07:49 +0000

Jason,

Thanks for the invitation. I will not make a text proposal at present,
but a general proposal how to solve it.

Basically, I think it would make more sense if SED were the data you
ended up with at the end of the SPEERMINT process.

I think  the following existing statement: 
"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)."
Would then be correct, but the position of SED in figure 1 would be
wrong, because it looks like it is intended to be input data to the
look-up. Also in figure 1, I think the processes of federation
detection, policy look-up and service location are all things that help
to construct the SED. So figure 1 would need some rework. However, to me
the conventions used in figure 1 are unclear, so I don't know how it
should be represented. But basically it should show the following
things:
 - the input to the SPEERMINT process is the SIP URI;
 - the process itself comprises look-up to achieve federation detection,
policy and service location;
 - the output from the SPEERMINT process is the SED.

I think the following existing statement is wrong:
"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 the user. 
   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."
Because this treats SED as input, not as output from the process.

I think the following existing statement:
"More specifically, the SED is the set of parameters that the outgoing 
   SBEs need to complete the call, and may include:"
and the bullets that follow it are correct, because they seem to
describe the output from the process.

I haven't cross-checked whether this would align with usage of SED in
other documents.

John

> Sent: 21 November 2007 14:58
> To: Elwell, John; [email-masked]; Malas, Daryl; Dave Meyer

---

From: "Michael Hammer (mhammer)" <[email-masked]>
Date: Sun, 25 Nov 2007 12:36:28 -0500

Part of the problem here may be trying to keep a clear separation
between the work of ENUM and SPEERMINT.  

The ENUM group defines a mechanism that can be used in many ways.  Input
an E.164 and output some value.  That value could be another E.164 or a
SIP URI.  Even when a SIP URI, the result could be pointing to another
registry, some database of a federation or carrier, or an ingress GW to
deliver the call to.  So the ENUM (or resulting DNS) mechanisms may need
to be invoked recursively before it is time to send the SIP INVITE to
the ingress GW of the terminating SP. 

The SPEERMINT group is attempting to define the overall process within
which the ENUM gets used, leading to a point at which the SIP, SIPPING,
BLISS, MMUSIC, and AVT groups' work takes over, such as the handling of
the SIP messages and the specification of RTP delivery point in the SDP.

We originally tried to describe this as a series of peeling the onion
and discovering successively more granular information and ending with a
high success rate for delivering the call from a given originating
carrier (possibly through a transit carrier) to the terminating carrier
without the "can't get there from here" problem due to lack of full-mesh
interconnection arrangements between SP.

So, SPEERMINT may need to define requirements for the ENUM group to
define more than one output type for SPEERMINT to use.

Mike

> Sent: Wednesday, November 21, 2007 4:08 PM
> Subject: RE: [Speermint] [wg-business] 
> WGLCfordraft-ietf-speermint-terminology-13
> 
> Jason,
> 
> Thanks for the invitation. I will not make a text proposal at 
> present, but a general proposal how to solve it.
> 
> Basically, I think it would make more sense if SED were the 
> data you ended up with at the end of the SPEERMINT process.
> 
> Would then be correct, but the position of SED in figure 1 
> would be wrong, because it looks like it is intended to be 
> input data to the look-up. Also in figure 1, I think the 
> processes of federation detection, policy look-up and service 
> location are all things that help to construct the SED. So 
> figure 1 would need some rework. However, to me the 
> conventions used in figure 1 are unclear, so I don't know how 
> it should be represented. But basically it should show the following
> things:
>  - the process itself comprises look-up to achieve federation 
> detection, policy and service location;
> and the bullets that follow it are correct, because they seem 
> to describe the output from the process.
> 
> I haven't cross-checked whether this would align with usage 
> of SED in other documents.
> 
> John
> 
> > It is easy to identify problems in any document.  ;-)  
> We're open to 
> > any suggestion on how to resolve this by you.  Please make 
> a proposal 
> > to the list.
> > 
> > Thanks
> > Jason
> > 
> > > This clearly says that SED is input to the SPEERMINT 
> process and can 
> > > be provided by the ENUM process. As far as I know, the 
> ENUM process 
> > > will only provide a SIP URI.
> > > 
> > > This is clearly in conflict, since it is a lot more than just the 
> > > SIP URI and also appears to include a lot of data that is output 
> > > from, rather than input to, the SPEERMINT process.
> > >  
> > > John
> > > 
> > > 
> > > > From: Livingood, Jason 
> [mailto:[email-masked]]

---

From: Otmar Lendl <[email-masked]>
Date: Sun, 25 Nov 2007 21:15:50 +0100

> define more than one output type for SPEERMINT to use.

As your correctly say, ENUM does not need to return a SIP AoR.

On the other hand, _if_ we assume (and I do) that the speermint peering
process MUST also work with URI-based calls (where the user never dialed
a telephone number, but directly a SIP URI like sip:[email-masked]
instead), then pushing more work (peering discovery / routing /
source-dependent ingress points / ...) into the ENUM step is foolish as
we need to replicate the same mechanisms on the domain level for these
cases.

/ol
-- 
/ Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /

---

From: "James McEachern" <[email-masked]>
Date: Mon, 26 Nov 2007 10:55:20 -0500

John, Jason,
I like John's proposal for how to solve the SED ambiguity, but have not
seen a proposal for specific text yet.  At the risk of duplicating
effort, I will propose some concrete changes to the Terminology draft
that may achieve the intended effect.

1. Section 2, the final paragraph currently says:

Suggest this be changed to:
"As illustrated in Figure 1, the ENUM Working Group is primarily
concerned with identifying a SIP URI that corresponds to a given E.164
number, while the SPEERMINT Working Group is concerned with using that
SIP URI to acquire the SED and on the use of such SED in routing session
signaling requests.  Importantly, the SIP URI can be derived from ENUM
(i.e., an E.164 DNS entry) or via any other mechanism available to the
user."

2. Section 3.3, the first paragraph says:
"Session Establishment Data, or SED, is the data used to route a call 
   to the next hop associated with the called domain's ingress point. A 
   domain's ingress point can be thought of as the location derived from
the NAPTR/SRV/A record [1] that resulted from the resolution of the 
   SED (i.e., a SIP Address of Record (AoR))."

I suggest modifying this paragraph to read:

"Session Establishment Data, or SED, is the data used to route a call 
   to the next hop associated with the called domain's ingress point. A 
   domain's ingress point can be thought of as the location derived from
the NAPTR/SRV/A record [1] that resulted from the resolution of the 
   SIP URI."

3. Section 3.3 also includes a list of parameters that the SBE needs to
complete the call.  The section then provides a bullet list of
parameters that the SED "may include".  Although much of our work seems
to be around identifying an ingress SBE, there is no mention of this in
the list.  I suggest modifying the current second bullets as follows:

Current bullet:

Change to:
     . A SIP proxy or Ingress SBE to send the INVITE to, including

I believe these changes would expand the definition of SED, and better
align with the use of the term in the rest of this draft, and in other
SPEERMINT drafts.

BTW, I believe changes to figure 1 will also be required, but I'll
suggest those in another post.

Jim McEachern

  > Subject: RE: [Speermint] [wg-business] WGLC fordraft-ietf-speermint-
  > terminology-13
  > 
  > Jason,
  > 
present,
  >  - the process itself comprises look-up to achieve federation
detection,

---

From: "James McEachern" <[email-masked]>
Date: Mon, 26 Nov 2007 11:37:23 -0500

Jason,
I realize this is after the deadline, but I went over all the drafts
again this weekend, and couldn't help but notice the inconsistencies.
(It is definitely getting better, but not quite there yet...)

I know you probably don't want to revisit figure 1, but in its current
form it seems to me that it is most definitely wrong.  For example, this
figure shows that the "Lookup of SRV/A and AAAA in DNS" is out of scope
for SPEERMINT.  This would suggest that your excellent draft on the "Use
of DNS and NAPTR Records for SPEERMINT" is entirely out of scope for
SPEERMINT.  This seems just plain wrong to me.  
After re-reading all the drafts this weekend, it seems to me that we are
really talking about something that is better described by the following
diagram:

           E.164 number  
                | 
                | <--- ENUM lookup of NAPTR in Domain Name System (DNS) 
                |
           Lookup 
           Discovery 
           SIP URI 
                | 
                | ENUM Working Group Scope 
           =====+==================================================== 
                | SPEERMINT Working Group Scope 
                |                                             \
                | <--- Federation Detection, Policy           | 
                |      Lookup, and Service Location           |
                |                                             | Session
                |
|Establishment
           Hostname <--- Addressing and session establishment \ Data 
                |                                             /(SED)

                |                                             |
                | <--- Lookup of SRV/A and AAAA in DNS        |
                |                                             |
                |                                             |
           IP address                                         |
                |                                             /
                | SPEERMINT Working Group Scope 
           =====+==================================================== 
                | Out of scope for the SPEERMINT Working Group 
                |
                | <--- Routing protocols, ARP [14] etc. 
                | 
           MAC-address 

                  Figure 1: Session Peering Context

If this isn't the scope, then there are many other pieces that do not
really make sense.

Finally, and again I apologize for the lateness of this comment, the
definition of Service Provider in section 3.8 suggests that the term
"Service Provider" when used without the preceding "SIP" means an entity
that only provides layer 3 functionality.  This definition conflicts
with usage later in this and other documents.  (e.g. section 4.2 states:
"Layer 5 (Session) peering refers to interconnection of two service
providers...".)  We either need to add "SIP" before "service provider"
(in several places) or modify the definition slightly.  

Perhaps change the existing text:
"A Service Provider (or SP) is defined to be an entity that provides
layer 3 (IP) transport of SIP signaling and media packets."

Change to:
"A Service Provider (or SP) is defined to be an entity that provides
layer 3 (IP) transport of SIP signaling and media packets, and may also
provide layer 5 processing of SIP signaling and media packets."  

If that change doesn't work for people, then there are a number of other
places where I believe we need to add the work "SIP" in front of
"service provider" or we are talking about layer 5 functions being
performed by an entity that is only supposed to work at layer 3.

Jim McEachern

  > Sent: Thursday, November 08, 2007 4:23 PM
  > To: [email-masked]
  > Subject: [Speermint] [wg-business] WGLC for draft-ietf-speermint-
  > terminology-13
  > 
WGLC

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 26 Nov 2007 16:25:57 +0000

Jim,

Your proposal sounds good.

John 

> From: James McEachern [mailto:[email-masked]] 
> Sent: 26 November 2007 15:55
> To: Elwell, John; Livingood, Jason; [email-masked]

---

From: Daryl Malas <[email-masked]>
Date: Mon, 26 Nov 2007 11:04:37 -0700

Jim,

I will update the draft today and submit a new revision.  Thanks for
your comments and feedback.

--Daryl

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 26 Nov 2007 21:40:05 +0100

> SPEERMINT.  This seems just plain wrong to me.  

Good catch.

As I see it, the NAPTR/SRV/A lookup step (RFC3263, or the NAPTR
speermint draft) is the solution to the speermint problem in a
world where any SSP agrees to do ad-hoc peering with any other SSP
over the public Internet. The other extreme would be just static,
manually configured peerings. Both is too limiting for the real world.

It's the middle ground (SSPs with complex and diverse peering
strategies) which is not covered by existing mechanisms. Here is IMHO
the true calling of speermint: provide a framework which allows all
SSPs to use a common routing architecture which supports whatever
their peering strategy is and will be. 

This provides the room for incremental changes in peering strategies:
SSPs can slowly converge to a fully open peering setup. At the pace
they are comfortable with. Not just all-or-nothing decisions.
>From my perspective, such an approach is much likelier to result in 
widespread peering than a RFC3263 purity contest.

/ol

---

From: Daryl Malas <[email-masked]>
Date: Mon, 26 Nov 2007 15:33:02 -0700

FYI..due to the cutoff date, and the fact I cannot submit a new rev
until 12/3; feel free to provide comments up to 12/2.

Thanks...--Daryl

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 27 Nov 2007 08:22:52 +0000

> Sent: 26 November 2007 16:37
> To: Livingood, Jason; [email-masked]
> | Session
[JRE] This change doesn't work for me. I think we need to go for your
other proposal (inserting "SIP" in appropriate places).

John

---

From: "James McEachern" <[email-masked]>
Date: Wed, 28 Nov 2007 00:53:23 -0500

Comments inline.

John Elwell wrote:

--- snip ----
  
  > other proposal (inserting "SIP" in appropriate places).
[jmce]  I've gone through most of the drafts to identify where we would
need to make changes by inserting "SIP".  I've found over 20 instances
already, along with a dozen or so that simply say "provider" - and hence
presumably need to add "SIP Service".  Before I document all of these
instances, I just want to ensure that the group wants to go this route,
rather than the simpler choice of changing the definition.

Let me know.

Jim

---

From: Daryl Malas <[email-masked]>
Date: Wed, 28 Nov 2007 16:45:25 -0700

I think I am actually more of a fan of the "add SIP" to "service
provider" in Section 4.2 (and, throughout the document as necessary) for
this reference.  Then, it will directly relate back to the definition of
a SSP in Section 3.9.

--Daryl

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 29 Nov 2007 14:22:44 -0500

Actually, please email the ID editor with the new -14 version and email
the file to the list.  I would like folks to come to the meeting next
week with this new version in case it comes up for discussion.

Regards
Jason 

> From: Daryl Malas [mailto:[email-masked]] 
> Sent: Monday, November 26, 2007 5:33 PM
> To: James McEachern
> Cc: [email-masked]; Livingood, Jason
> Subject: RE: [Speermint] [wg-business] WGLCfor 
> FYI..due to the cutoff date, and the fact I cannot submit a 
> new rev until 12/3; feel free to provide comments up to 12/2.
> 
> Thanks...--Daryl
> 
> > > I know you probably don't want to revisit figure 1, but in its 
> > > current form it seems to me that it is most definitely 
> wrong.  For 
> > > example, this figure shows that the "Lookup of SRV/A and AAAA in 
> > > DNS" is out of scope for SPEERMINT.  This would suggest that your 
> > > excellent draft on the "Use of DNS and NAPTR Records for 
> SPEERMINT" 
> > > is entirely out of scope for SPEERMINT.  This seems just 
> plain wrong to me.
> > > After re-reading all the drafts this weekend, it seems to 
> me that we 
> > > are really talking about something that is better 
> described by the 
> > > following
> > > diagram:
> > > 
> > >            E.164 number  
> > >                 | 
>     /(SED)
> > > If this isn't the scope, then there are many other pieces that do 
> > > not really make sense.
> > > 
> > > "Service Provider" when used without the preceding "SIP" means an 
> > > entity that only provides layer 3 functionality.  This definition 
> > > conflicts with usage later in this and other documents.  
> (e.g. section 4.2 states:
> > > layer 3 (IP) transport of SIP signaling and media 
> packets, and may 
> > > also provide layer 5 processing of SIP signaling and 
> media packets."
> > > 
> > > If that change doesn't work for people, then there are a 
> number of 
> > > other places where I believe we need to add the work 
> "SIP" in front 
> > > of "service provider" or we are talking about layer 5 functions 
> > > being performed by an entity that is only supposed to 
> work at layer 3.
> > > 
> > > Jim McEachern
> > > 
> > > submitting the
> > >   > which have not gotten previous or adequate 
> discussion, or minor 
> > > errors
> > >   > which need correction.
> > >   >