Subject: [speermint] comments on draft-ietf-speermint-voip-consolidated-usecases-02

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 5 Jul 2007 15:43:47 -0600

Find below some comments on
draft-ietf-speermint-voip-consolidated-usecases-02.

--- editorial
- Given this is a use case document, is "Intended status: Standards
Track" correct? The charter says Informational.
- terminology draft-07 alignment:
The use case I-D still has too many definitions and some terms used in
the description of the use cases (like session manager) are not in the
terminology draft-07. This section could be reduced by introducing the
conventions used for logical entities that are in the originating (O-),
terminating (T-) or transit (t-) domains.

--- technical
- The use case examples dedicate quite a bit of time & text to describe
what all the variants are within one SSP/user group domain: does the
originating or terminating "domain" have SBE, SDE, SM, LS, etc.?

I am not sure I understand where this leads us in terms of requirements
on the interconnect points. 
Each user group or service provider mging a domain can do whatever they
want and add as many layers of indirect signaling/media as they wish. I
thought that elements "at the boundary" of the networks were the ones
where we wanted speermint to focus on. 
==> what are the differences between (4) in figure 2, (5) in figure 3,
and (5) in figure 4 -- just to focus on signaling?
==> if there are differences, why do they matter for best current
practices?
Beyond the labels of the boxes being different, at this stage, the
justifications provided in 3.1.2.2. solely focus on the functions an SBE
(SBC?) can provide. Some of these are a) session "scrubbing": relates to
sip interop stuff which is out of scope of speermint, b) overlapping
net10 or RFC1918 address spaces which is suggesting the use case is
about SIP/SDP ALG-like mechanisms rather than endpoint functionality
like ICE, ... 
How do those use cases help identify different requirements between
scenarios at this stage? I'd be interested in understanding what
differs, what kind of SIP headers should be present/supported to allow
these use cases. This comment applies across section 3.

Thoughts or suggestions for direct peering use case:
	- take the use case in section 3.1.1. as the only case for
direct peering (the others in section 3.1 are trivial simplifications)
	- add details on special cases where SBE/DBE are typically not
necessary, when they are required, what changes in the protocol
exchanges between those elements. For e.g., why is it desirable that an
SBE be capable of "inserting' an SDE in some cases?
One case that is quite common (I think) seems to be missing: an O-SSP
has multiple O-SBEs and selection of the SBE depends on the T-SSP domain
(multiple "egress" points) or the reverse case (multiple "ingress"
points for SBEs, or SDEs).

- identification of requirements through the use case examples:
Section 3 states:
 |there are different requirements between the scenarios and 
 |this document serves to help identify the requirements 
 |for SIP Peering for VoIP.
Differences in use cases may not always imply differences in
requirements; in the next revision, it would be good to summarize what
some of those differences are at the end of each section (direct,
indirect, assisted).

- 4.2.5.: what does this section bring to the use case draft?

Jean-Francois.

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