Subject: [Speermint] draft-ietf-speermint-voip-consolidated-usecases-05.txt

From: "Uzelac, Adam" <[email-masked]>
Date: Fri, 22 Feb 2008 14:37:19 -0500

For general consumption in prep for Philly.  See y'all in the city of
brotherly love!  Feedback welcomed.

Changes:
- resync with the latest term draft.
- clarifications based on feedback from the last meeting - like
collapse/removal of assisted peering use cases into direct/indirect
models.

http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolidat
ed-usecases-05.txt

I am working on version 6, mostly weeding out nits, and will issue after
the WG session.  Thanks in advance for your feedback!!

Adam Uzelac
Director, Converged Network Arch and Planning
Global Crossing
585-563-4359
_______________________________________________
Speermint mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/speermint

---

From: "Daryl Malas" <[email-masked]>
Date: Mon, 25 Feb 2008 16:37:56 -0700

"VoIP consolidated use cases" author's,

First, let me say, I think the draft is off to a good start.  I would
like to suggest some things, I believe will allow the draft to provide
better clarity and more depth for a reader to understand the reasons and
situations relating to VoIP peering.

Here are a few encompassing comments and general nits of the document:

- I recommend looking through RFC 3285 before the next revision of the
draft.  There are a number of Word template issues, which can be
resolved fairly easy.

- The references need to be updated.

- Finally, as I review the use cases, I am looking for the following
basic structure within each use case: Goal, Summary, Actors,
Preconditions, Triggers, Basic course of events, Alternative paths (if
applicable), and any Policy considerations.

--------------------------------

More detailed comments:

Section 4 - "Each grouping can further sub-divided to Direct Peering and
Indirect Peering [15]."  Should it be, "Each grouping can be further
sub-divided to Direct and Indirect Peering [15]"?

"Each use-case has to specify how a few core operations which are to be
performed by its members."  I would like to suggest re-wording to, "Each
use case must specify a basic set of required operations to be performed
by each member when peering."

Section 5.1 - I would expect this intro paragraph to describe the goal
of static peering.  For example, "Static peering  is used in cases, when
two peers want a consistent and "hardened" approach to peering.  In this
scenario, all of the variables are very well defined and known by each
peer....."

Section 5.1.1 - Who are the actors (e.g. Enterprise A wants to peer with
Enterprise B, SSP A wants to peer with SSP B, SSP A is providing static
peering for Enterprise A, B, and C, etc.)?  What are the preconditions
required for this use case to be successful (e.g. each peer must
exchange their allowable set of codecs, authentication method, no
RFC1918 addresses, etc.)?  What are the triggers (i.e. what causes SSPA
to think it can send it to a peer?)

The sentence beginning, "Two SSP negotiate and agree..." seems to begin
the course of events, but you have other events numbered below.  This is
confusing.  I would suggest moving these into the numbered events below.

Each of the events listed, such provide an example of what is occurring
with each.  The current ones are too high level of value in deriving
requirements.  For example:

1. UAC initiates a call via SIP INVITE to O-Proxy

(Snippets frm RFC 3665)	
   INVITE sip:[email-masked] SIP/2.0
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   Max-Forwards: 70
   From: Alice <sip:[email-masked]>;tag=9fxced76sl
   To: +13031112222 <sip:[email-masked]>
   Contact: <sip:[email-masked];transport=tcp>
   
2. O-Proxy queries for SED information from a routing database (ENUM?? -
LUF)

(The result of the ENUM query is...)

$ORIGIN 2.2.2.2.1.1.1.3.0.3.1.denver.example.com
   NAPTR 10 100 "u" "E2U+SIP" "!^.*$
             !sip:\\[email-masked]!".

3. Routing database entity replies with SED to called party (NAPTR -
LRF)

sbe1-denver.sspa.example.com.
      order pref flgs service  regx    replacement
   IN NAPTR 100  50   "s"   "SIP+D2U" ""
_sip._udp.sbe1-denver.sspa.example.com

4. O-Proxy sends a DNS SRV query for
_sip._udp.sbe1-denver.sspa.example.com which results in:

   $ORIGIN _sip._udp.sbe1-denver.sspa.example.com.
    (Some content not included for clarity purposes.)
   IN SRV  0  1   5060   sbe1-denver.sspa.example.com

   ;; ANSWER SECTION
   sbe1-denver.sspa.example.com   A   192.0.2.17
   sbe2-denver.sspa.example.com   A   192.0.2.18

5.  Call sent to terminating domain proxy.

INVITE sip:[email-masked] SIP/2.0
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   Max-Forwards: 70
   From: Alice <sip:[email-masked]>;tag=9fxced76sl
   To: +13031112222 <sip:[email-masked]>
   Contact: <sip:[email-masked];transport=tcp>

6.  T-Proxy determines called party location by querying the ENUM server

$ORIGIN 2.2.2.2.1.1.1.3.0.3.1.denver.example.com
   NAPTR 10 100 "u" "E2U+SIP" "!^.*$
             !sip:\\[email-masked]!".

....and so on.  I think this detail will provide clarity for the
requirements and for readers to understand the necessary steps to
successfully peer.  I think this should be done for each of the use
cases.

Section 5.1.1 - These appear to be optional (or additional potential)
pre-conditions, which could occur relative to this use case.  If this is
case, I would suggest calling them Optional Pre-conditions and not
Options and Nuances.

---------------------------------

I think making similar, relative changes to each of the use case
sections will get the very close to a finished product.

--Daryl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Uzelac, Adam
Sent: Friday, February 22, 2008 12:37 PM
To: [email-masked]
Subject: [Speermint]
draft-ietf-speermint-voip-consolidated-usecases-05.txt

Changes:

Adam Uzelac
Director, Converged Network Arch and Planning Global Crossing
585-563-4359
_______________________________________________
Speermint mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/speermint
_______________________________________________
Speermint mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/speermint

---

From: "Uzelac, Adam" <[email-masked]>
Date: Tue, 26 Feb 2008 10:02:15 -0500

Daryl,

Excellent comments and thanks for the feedback.  We have version 6
queued up and are in the process of updating.  Regarding some of your
comments, starting with the "(Snippets frm RFC 3665)" - you state: 

> ...I think this detail will provide clarity for 
> the requirements and for readers to understand the necessary 
> steps to successfully peer.  I think this should be done for 
> each of the use cases.

I read that you are requesting more detail in the use cases, but I feel
it isn't necessary to get the pertinent points across.  Initially, and I
believe to a certain extent still, one goal of capturing current use
cases (what is "occurring in the wild today), is to capture
requirements.  At the same time, I think that a goal in capturing the
VoIP use cases at present is to identify the "ugliness", like
limited-to-no transparency of SIP/VoIP Peering as it exists today.
Also, with the advent of B2BUAs as the SBE/DBEs in the call flows, there
would be numerous iterations of SIP Header manipulation/mangling that is
done for various business, regulatory and other reasons.  It could be a
very slippery slope to start digging into the details, and would also
balloon the draft greatly.

To summarize, I am on the fence with this one.  Others have thoughts?
Will the details help clarify, or narrow the discussion too much?

-Adam

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Daryl Malas
> Sent: Monday, February 25, 2008 11:38 PM
> To: Uzelac, Adam; [email-masked]
> Subject: Re: 
> [Speermint]draft-ietf-speermint-voip-consolidated-usecases-05.txt
> 
> First, let me say, I think the draft is off to a good start.  
> I would like to suggest some things, I believe will allow the 
> draft to provide better clarity and more depth for a reader 
> to understand the reasons and situations relating to VoIP peering.
> 
> - I recommend looking through RFC 3285 before the next 
> revision of the draft.  There are a number of Word template 
> issues, which can be resolved fairly easy.
> 
> - Finally, as I review the use cases, I am looking for the 
> following basic structure within each use case: Goal, 
> Summary, Actors, Preconditions, Triggers, Basic course of 
> events, Alternative paths (if applicable), and any Policy 
> considerations.
> 
> Section 4 - "Each grouping can further sub-divided to Direct 
> Peering and Indirect Peering [15]."  Should it be, "Each 
> grouping can be further sub-divided to Direct and Indirect 
> Peering [15]"?
> 
> "Each use-case has to specify how a few core operations which 
> are to be performed by its members."  I would like to suggest 
> re-wording to, "Each use case must specify a basic set of 
> required operations to be performed by each member when peering."
> 
> Section 5.1 - I would expect this intro paragraph to describe 
> the goal of static peering.  For example, "Static peering  is 
> used in cases, when two peers want a consistent and 
> "hardened" approach to peering.  In this scenario, all of the 
> variables are very well defined and known by each peer....."
> 
> Section 5.1.1 - Who are the actors (e.g. Enterprise A wants 
> to peer with Enterprise B, SSP A wants to peer with SSP B, 
> SSP A is providing static peering for Enterprise A, B, and C, 
> etc.)?  What are the preconditions required for this use case 
> to be successful (e.g. each peer must exchange their 
> allowable set of codecs, authentication method, no
> RFC1918 addresses, etc.)?  What are the triggers (i.e. what 
> causes SSPA to think it can send it to a peer?)
> 
> The sentence beginning, "Two SSP negotiate and agree..." 
> seems to begin the course of events, but you have other 
> events numbered below.  This is confusing.  I would suggest 
> moving these into the numbered events below.
> 
> Each of the events listed, such provide an example of what is 
> occurring with each.  The current ones are too high level of 
> value in deriving requirements.  For example:
> 
>    Via: SIP/2.0/TCP 
> client.atlanta.example.com:5060;branch=z9hG4bK74bf9
>    Max-Forwards: 70
>    Via: SIP/2.0/TCP 
> client.atlanta.example.com:5060;branch=z9hG4bK74bf9
>    Max-Forwards: 70
> ....and so on.  I think this detail will provide clarity for 
> the requirements and for readers to understand the necessary 
> steps to successfully peer.  I think this should be done for 
> each of the use cases.
> 
> Section 5.1.1 - These appear to be optional (or additional 
> potential) pre-conditions, which could occur relative to this 
> use case.  If this is case, I would suggest calling them 
> Optional Pre-conditions and not Options and Nuances.
> 
> I think making similar, relative changes to each of the use 
> case sections will get the very close to a finished product.
> 
> --Daryl
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Uzelac, Adam
> For general consumption in prep for Philly.  See y'all in the 
> city of brotherly love!  Feedback welcomed.
> 
> Changes:
> - clarifications based on feedback from the last meeting - 
> like collapse/removal of assisted peering use cases into 
> direct/indirect models.
> 
> I am working on version 6, mostly weeding out nits, and will 
> issue after the WG session.  Thanks in advance for your feedback!!
> 
> Adam Uzelac

---

From: "Daryl Malas" <[email-masked]>
Date: Tue, 26 Feb 2008 08:36:39 -0700

Adam,

I am not suggesting a detailed signaling example of every possible
scenario, but I am suggesting a relative example of the scenario
described within the use case.  For example, static peering can use ENUM
or a redirect server.  I am suggesting a detailed view of the ENUM
process within the peering use case, to help the reader understand the
complexities of manipulating the signaling from the UAC to the UAS.  As
you probably already know, this draft is not intended to define the
solution, but rather describe the things that need to happen.  How it
should or must happen is up to later drafts.  This is not as simple as
it seems, and requires more than just a "oh by the way...".  Then, after
the use case, you suggest other possible conditions.  You can say, "The
described course of events is an example, and here are some other
possibilities, and here are a few things, which must be considered with
these other possibilities."

Also, you describe the necessity to identify the "ugliness".  This is my
point, wrt providing detail.  I see a fluffy high level overview in the
draft, not much ugliness.

By the way, I went through a similar situation recently...it's an easy
problem to talk about, until you start diving down into a step-by-step
analysis of what needs to happen and what needs to change for it to be
successful.  I think this is some of what Otmar has been trying to say
for awhile.  The final solution may require other protocol work, but I
do not get a sense of this possibility yet based on the use cases.

Thanks...

--Daryl 

-----Original Message-----
From: Uzelac, Adam [mailto:[email-masked]] 
Sent: Tuesday, February 26, 2008 8:02 AM
To: Daryl Malas; [email-masked]
Subject: RE:

Daryl,

Excellent comments and thanks for the feedback.  We have version 6
queued up and are in the process of updating.  Regarding some of your
comments, starting with the "(Snippets frm RFC 3665)" - you state: 

> ...I think this detail will provide clarity for the requirements and 
> for readers to understand the necessary steps to successfully peer.  I

> think this should be done for each of the use cases.

-Adam

> I would like to suggest some things, I believe will allow the draft to

> provide better clarity and more depth for a reader to understand the 
> reasons and situations relating to VoIP peering.
> 

> Section 4 - "Each grouping can further sub-divided to Direct Peering 
> and Indirect Peering [15]."  Should it be, "Each grouping can be 
> further sub-divided to Direct and Indirect Peering [15]"?
> 
> "Each use-case has to specify how a few core operations which are to 
> be performed by its members."  I would like to suggest re-wording to, 
> "Each use case must specify a basic set of required operations to be 
> performed by each member when peering."
> 

> of static peering.  For example, "Static peering  is used in cases, 
> when two peers want a consistent and "hardened" approach to peering.  
> In this scenario, all of the variables are very well defined and known

> by each peer....."
> 
> Section 5.1.1 - Who are the actors (e.g. Enterprise A wants to peer 
> with Enterprise B, SSP A wants to peer with SSP B, SSP A is providing 
> static peering for Enterprise A, B, and C, etc.)?  What are the 
> preconditions required for this use case to be successful (e.g. each 
> peer must exchange their allowable set of codecs, authentication 
> method, no
> RFC1918 addresses, etc.)?  What are the triggers (i.e. what causes 
> SSPA to think it can send it to a peer?)
> 
> seems to begin the course of events, but you have other events 
> numbered below.  This is confusing.  I would suggest moving these into

> the numbered events below.
> 
> occurring with each.  The current ones are too high level of value in 
> deriving requirements.  For example:
> 
> 2. O-Proxy queries for SED information from a routing database (ENUM??

> -
> potential) pre-conditions, which could occur relative to this use 
> case.  If this is case, I would suggest calling them Optional 
> Pre-conditions and not Options and Nuances.
> 
> I am working on version 6, mostly weeding out nits, and will issue 
> after the WG session.  Thanks in advance for your feedback!!
> 
> Adam Uzelac

---

From: "Daryl Malas" <[email-masked]>
Date: Tue, 26 Feb 2008 08:43:07 -0700

One more thing...the detailed view should only describe known processes.
Other steps, should include what needs to happen regardless of an
existing process.  For example, SSPA must somehow get their subscriber
information into the LUF (as we know...to be potentially handled by
PEPPERMINT).  This is work, which can be identified by the use cases and
then a solution defined SPEERMINT or in other groups as necessary.

--Daryl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Daryl Malas
Sent: Tuesday, February 26, 2008 8:37 AM
To: Uzelac, Adam; [email-masked]
Subject: Re:
[Speermint]draft-ietf-speermint-voip-consolidated-usecases-05.txt

Adam,

Thanks...

--Daryl 

-----Original Message-----
From: Uzelac, Adam [mailto:[email-masked]]
Sent: Tuesday, February 26, 2008 8:02 AM
To: Daryl Malas; [email-masked]
Subject: RE:

Daryl,

-Adam

---

From: "Michael Hammer (mhammer)" <[email-masked]>
Date: Tue, 26 Feb 2008 13:10:10 -0500

Adam,

Only the idea I expressed before that since the main gist of this is
call routing, 
the main SIP header that should be mangled is the Route header.

Mike

> Sent: Tuesday, February 26, 2008 10:02 AM
> Excellent comments and thanks for the feedback.  We have 
> version 6 queued up and are in the process of updating.  
> Regarding some of your comments, starting with the "(Snippets 
> frm RFC 3665)" - you state: 
> 
> I read that you are requesting more detail in the use cases, 
> but I feel it isn't necessary to get the pertinent points 
> across.  Initially, and I believe to a certain extent still, 
> one goal of capturing current use cases (what is "occurring 
> in the wild today), is to capture requirements.  At the same 
> time, I think that a goal in capturing the VoIP use cases at 
> present is to identify the "ugliness", like limited-to-no 
> transparency of SIP/VoIP Peering as it exists today.
> Also, with the advent of B2BUAs as the SBE/DBEs in the call 
> flows, there would be numerous iterations of SIP Header 
> manipulation/mangling that is done for various business, 
> regulatory and other reasons.  It could be a very slippery 
> slope to start digging into the details, and would also 
> revision of the 
> following