Re: [Speermint] Partial review ofdraft-ietf-speermint-consolidated-usecases-08

["Lee, Yiu" <Yiu_Lee at Cable.Comcast.com>]

Alex and John,

Thanks for taking the time to review the draft. The comments are great. Adam and I will address your comments and target to release a new version next week.

Thanks,
Yiu



----- Original Message -----
From: speermint-bounces at ietf.org <speermint-bounces at ietf.org>
To: speermint at ietf.org <speermint at ietf.org>
Sent: Tue Jun 24 16:10:58 2008
Subject: [Speermint] Partial review ofdraft-ietf-speermint-consolidated-usecases-08

This is not a full review, because of lack of time. Also I will not
re-iterate the many points that Alexander Mayrhofer has already raised:
http://www.ietf.org/mail-archive/web/speermint/current/msg02396.html

In general, I think the document assumes too much prior knowledge from
the reader.

1. Figure 1 is not self-explanatory. Even if all the acronyms are
defined (as Alexander requested), what is the relationship between the
three domains (are they all peers of each other)? What is the meaning of
the lines connecting some of the inner boxes together, and what is to
the meaning when inner boxes are not interconnected (as within the
middle domain)? In particular there is no line between O-SBE and O-LRF,
yet the first example shows O-SBE querying O-LRF. Indeed there is a line
between those two entities in figure 2. What is the meaning of "LUF/LRF
Provider Domain Indirect SSP Domain" - should there be an "and" or an
"or" here?

2. "Each use-case must specify a
   basic set of required operations to be performed by each member when
   peering."
Is this supposed to be saying that this document specifies a basic set
of required operations....for each use case? If so, then these are hard
to find in the different use cases later in the document. For example, I
cannot find anywhere later in the document that mentions "peer
discovery" or "location determination" or "next hop determination"....

3. " Peer Discovery - Peer discovery via a Look-Up Function (LUF) to
      determine the administrative domain of the target.

   o  Location Determination - A location determination process serves
      to create the Session Establishment Data (SED).  Examples: Public
      User-ENUM, public Infrastructure ENUM, private ENUM tree, SIP
      Redirect, DUNDi."
The LUF determines the domain of the target, and therefore the various
ENUM possibilities seems to be part of "Peer Discovery", not "Location
Determination".

4. " Next Hop Determination - A next hop determination based on the SED
      is then completed. "
I thought once you had the SED you had already determined the next hop,
i.e., information on the next hop is part of the SED.

5. "If Location Routing Function (LRF) query did
      not return an URI of the form sip:user at IP-address"
There is no previous mention of an LRF query.

6. "federation private DNS" and "split-DNS" - do we have references for
these?

7. "P2P SIP". I am not sure this needs to be mentioned, particularly as
we don't have anything we can reference yet.

8. "For instance, the receiving side
      border elements need to determine whether the INVITE it just
      received really came from a member of the federation,"
This is the first time federation is assumed. The involvement of a
federation should be explained at an early stage.

9. "The peers may exchange interconnection parameters
   such as DSCP policies, subscriber SIP-URI and proxy location prior to
   establishing the interconnection."
How can the "subscriber SIP-URI" be known in advance of a particular
call set-up?

10. Figure 2 lacks the DBE functions in figure 1.

11. "So, O-Proxy queries LUF for SED information from a routing
        database."
I thought the LUF just identifies the domain, and a further LRF query is
needed to get the SED.

12. "O-Proxy examines the SED and discover the domain is external."
Again I didn't think an ENUM look-up (in the previous step) gave us the
SED.

13. The draft seems to talk about LUF and LRF, and also about DNS
(NAPTR, A records, etc.) LUF and LRF are shown in the figures, DNS is
not. It is not always clear how DNS relates to LUF/LRF, i.e., is DNS a
means of realising LUF and/or LRF?

14. "$ORIGIN 3.3.3.3.2.2.2.7.1.9.1.example.com
          NAPTR 10 100 "u" "E2U+SIP"
           "!^.*!sip:\1 at t-sbe.example.net!""
Isn't it more likely that it will yield example.net, rather than
t-sbe.example.net? Then an SRV look-up might yield t-sbe.example.net. So
routing from O-Proxy to O-SBE would contain:
INVITE sip:+19172223333 at example.net SIP/2.0
Route: sip:o-sbe1.example.com;lr
O-SBE would then use RFC 3263 to find the server in example.net.

15. "INVITE sip:+19172223333 at i-sbe1.example.org;user=phone SIP/2.0"
Isn't this more likely to be of the form:
INVITE sip:+19172223333 at example.net;user=phone SIP/2.0
Route: sip:i-sbe1.example.org;lr
In other words, the terminating domain is kept in the Request-URI, with
loose routing to get you to the intermediate domain.

John
_______________________________________________
Speermint mailing list
Speermint at ietf.org
https://www.ietf.org/mailman/listinfo/speermint
_______________________________________________
Speermint mailing list
Speermint at ietf.org
https://www.ietf.org/mailman/listinfo/speermint