Subject: [Speermint] Comments on draft-ietf-speermint-voip-consolidated-usecases-08

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 27 Jun 2008 03:18:18 -0600

Hi Adam and Yiu Lee,

   Here are some comments based on the draft-08 revision.

Jean-François

1. Technical comments

- page 5, Next Hop Determination:
  s/IP-address/hostname
Hopefully, the result of a query to the Location Routing Function is a sip uri with either a hostname or domain name, not an IP address.  If some folks prefer to use IP, it's their problem but the document must use hostnames (the DNS resolver on the originating host should do the domain/hostname->IP add resolution).

- page 5: "[RFC3263] in a federation private DNS."
This is just an example but it is contrary to the conclusion we had with Patrick Falstrom in the beginning of the wg terminology document.  The issue is "private DNS" in this sentence: it tends to leak the "private" boundaries and is difficult to manage to avoid conflicts.  You can achieve the same results by registering domain names to have them in the public DNS, yet the resolution of the DNS name give you DNS records that are only meaningful in the federation (e.g. IP address not publicly routable).
s/[RFC3263] in a federation private DNS/[RFC3263] in a private federation (where DNS names may be registered but the accessibility of the DNS responses may be restricted to federation members)

-  p18, 5.1.4. Static Indirect Peering Use Case:
This section should be updated to keep the text in scope of speermint, clear from any considerations around provisioning or IP/telephony routing considerations. Specifically, in this paragraph:
"The challenge for O-SSP is to decide which I-SSP should be
 used to reach T-SSP.  O-SSP could manually enter I-SSP information in
 the routing database.  However, when O-SSP peers to multiple I-SSP,
 O-SSP may have multiple routes to reach the same T-SSP.  If we
 further consider that an I-SSP may use another I-SSP to reach T-SSP,
 the permutation can grow exponentially.  This is similar to the IP
 routing problem eventually solved by BGP [RFC4271].  TRIP [RFC3219]
 is a candidate to solve this problem.  However, market has yet to
 deploy TRIP in large scale."

New proposed text:
"The O-SSP determines the appropriate I-SSP intermediary to reach the terminating peer based on the routing database linked with its LUF/LRF.  Note that there could be multiple I-SSPs and multiple SIP routes to reach the same T-SSP; this is out of scope of speermint and has become a focus in the drinks working group."

Or something like that.  In other words, I am not sure it helps the reader to throw protocol names like BGP or TRIP and then spell doubts on the deployability of a protocol in large scale.

- p19, section 5.1.4.1. Administrative characteristics
This section does not bring much to speermint and is all about building walled gardens for SIP and media.  This is certainly a valid use case based on some SSP deployments but I fail to see what is different in this use case on message flows (4,5,6, and 7) compared to the direct peering case.  Is the difference in the responses in (2)?  

- p22, Central SIP Proxy Federations
This whole section should be removed.  I got serious issues with this section and its content.
It's title says it all: it is about SIP proxy and out of scope of speermint.  The first 2 paragraphs are pure 'federation' marketing and do imply that a firewall is the single solution to solving the SIP identity and building an on-demand trust relationship with an unknown peer.  Hopefully there is much more than that.

2. Editorial comments
As you get the doc ready for publication, you may want to consider the following:
- page 3, section 1, and page 13, 5.1.2.2.:
   is it necessary to keep references to early drafts that have not progressed and are using different terminology?  I don't think we want to carry the original speermint problem statement draft in an RFC.
- page 3, section 2:  consider referencing the terminology draft here, something like:
  "This document also reuses the terminology defined in [I-D.ietf-speermint-terminology]."
- s/operator/SIP Service Provider (globally)

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

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 27 Jun 2008 13:54:00 +0200

>    Here are some comments based on the draft-08 revision.

Jean-Francois,

Your comments question the technical soundness of some the scenarios 
described in this document. That's a valid point, if this were a document 
which describes how speermint envisions peerings to happen in the future.

As I see the purpose of this document (see Abstract), it is just supposed 
to just document what's out there, including warts, kludges and stupidities.

Thus: whatever conclusions we reached with paf (concerning private DNS) 
doesn't affect what's deployed right now and that's what this document is 
about.

So if I'm not mistaken about the purpose of this document, then we don't 
need reviews saying "this is a stupid way to peer", but "nobody is doing
it this way today."

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //
_______________________________________________
Speermint mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/speermint

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 27 Jun 2008 06:19:14 -0600

Otmar wrote:

> -----Original Message-----
> From: Otmar Lendl [mailto:[email-masked]]
> Sent: Friday, June 27, 2008 5:54 AM
> To: Jean-Francois Mule
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Speermint] Comments on draft-ietf-speermint-voip-
> consolidated-usecases-08
> 
I read the abstract and got that part fine.  So I would be ok as long as it is worded as such in the text.
What concerns me is this:
In abstract: 
	"This document captures them to provide a reference."
	=> what kind of reference?

Then in the intro:
     "These use cases will assist in identifying requirements and future works for VoIP Peering using SIP."
 	=> that is where I get concerns.

On the one hand, the document says: this is what's deployed today in abstract.  On the other hand, the next paragraphs say: this is going to be used to derive requirements. If we are all ok documenting what's in use today, including kludges, then let's not say that this is a reference for requirements.

> doesn't affect what's deployed right now and that's what this
> document is about.

It does not hurt to then put the right context around such examples and say that while this is deployed, it is preferable to do <this>, where <this> is something more sound.

> So if I'm not mistaken about the purpose of this document, then we
  Well, as I stated above, you and I have followed the work of working group to some extent and yet, we both read different things.  Think about this document being an RFC, and being read by folks trying to figure out how they could do session peering.  This is where we got to be careful.

> don't
> need reviews saying "this is a stupid way to peer", but "nobody is
> doing it this way today."

Your quotes implied I said this.  I may not recall what I said already but I did not word it that way and folks who have done this that way probably aren't stupid.

Jean-François

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 27 Jun 2008 15:50:04 +0100

Otmar, 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Otmar Lendl
> Sent: 27 June 2008 12:54
> To: Jean-Francois Mule
> Cc: [email-masked]
> Subject: Re: [Speermint] Comments 
> ondraft-ietf-speermint-voip-consolidated-usecases-08
> 
[JRE] Your are correct - that is what the abstract says. But thinking
about it, is this really what SPEERMINT wants to publish as an RFC?
Normally a use cases RFC (or a use cases section in an RFC) describes
use cases that need to be catered for in a solution. Based on these use
cases and other factors, requirements can be derived. A use cases RFC
does not normally describe in detail how such use cases are already
realised (if indeed they are already realised), but just outlines of
what should happen from a user perspective.

If SPEERMINT really is just trying to document existing practice in this
draft, I would no necessarily object, but we may need to find a more
appropriate title, e.g., current practices.

John

---

From: "Yiu L. Lee" <[email-masked]>
Date: Fri, 27 Jun 2008 11:34:41 -0400

Hi Jean-Francois,

I got a comment. See in-line.

Thanks.

On 6/27/08 8:19 AM, "Jean-Francois Mule" <[email-masked]> wrote:

> On the one hand, the document says: this is what's deployed today in abstract.
> On the other hand, the next paragraphs say: this is going to be used to derive
> requirements. If we are all ok documenting what's in use today, including
> kludges, then let's not say that this is a reference for requirements.
> 
> [YL] We want to capture what we have today (current practices) in the market
> for references. IMHO, what we capture here is to tell what is happening today.
> We are not defining the requirements because this will be done by requirement
> draft. We hope that by showing what we have today can help to identify the
> requirements. I believe that we didn¹t say this is a reference for
> requirements. We said ³These use cases will assist in identifying requirements
> and future words for VoIP Peering using SIP².  Do you think we should re-word
> this sentence to make it more clear? Do you have any good suggestion?
> 
> It does not hurt to then put the right context around such examples and say
> that while this is deployed, it is preferable to do <this>, where <this> is
> something more sound.
> 
> [YL] Ok, let¹s work on this in the next draft.
> 
> 
>   Well, as I stated above, you and I have followed the work of working group
> to some extent and yet, we both read different things.  Think about this
> document being an RFC, and being read by folks trying to figure out how they
> could do session peering.  This is where we got to be careful.
> 
>> > don't
> Your quotes implied I said this.  I may not recall what I said already but I
> did not word it that way and folks who have done this that way probably aren't
> stupid.
> 
> Jean-François
>> >
>> > /ol
>> > --