Re: Gen-ART Review of draft-ietf-speermint-voip-consolidated-usecases-13

Hi Spencer,

Thanks very much for the detailed comments, we will address them after
IETF-75. We will also wait for the AD¹s direction before posting a new
version.

Thanks,
Yiu


On 7/24/09 2:51 PM, "Spencer Dawkins" <spencer(_at_)wonderhamster(_dot_)org> 
wrote:

> I have been selected as the General Area Review Team (Gen-ART) reviewer for
> this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please wait for direction from your document shepherd or AD before posting a
> new version of the draft.
>
> Document: draft-ietf-speermint-voip-consolidated-usecases-13
> (Note: The IETF Last Call was issued for version 12 - since version 13 was
> available, I reviewed it instead)
>
> Reviewer: Spencer Dawkins
> IETF LC End Date: 2009-07-08
> Review Date: 2009-07-23 (late!)
> IESG Telechat date: (not known)
>
> Summary: This draft is almost ready for publication as an Informational RFC.
> I identified some minor questions (listed below). The ones I'd really like
> for Russ to think about are in Section 7 (Security Considerations).
>
> I also made suggestions to improve clarity, but these should not slow the
> document approval process down, unless Russ thinks some o of them are
> important.
>
> 1.  Introduction
>
>    Only use cases related to VoIP are considered in this document.
>    Other real-time SIP communications use cases, like Instant Messaging
>    (IM) and presence are out of scope for this document.  In describing
>    use cases, the intent is descriptive, not prescriptive.
>
> Spencer (clarity): I would suggest "These use cases are descriptive, not
> prescriptive" for the last sentence in this paragraph.
>
>    The use cases contained in this document attempts to be as
>    comprehensive as possible, but should not be considered the exclusive
>    set of use cases.
>
> 3.  Reference Architecture
>
>    Originating SSP (O-SSP) is the SSP originating a request.
>
> Spencer (clarity): at this point in the document, it's not clear whether a
> "request" is a SIP request or a request to discover a peer, determine a next
> hop, etc. Could you add an adjective (probably either "SIP request" or
> something like "peering request")?
>
>    Terminating SSP (T-SSP) is the SSP terminating the request
>    originating from O-SSP.  Assisting LUF and LRF Provider offers LUF
>    and LRF services to O-SSP.  Indirect SSP (I-SSP) is the SSP providing
>    indirect peering service(s) to O-SSP to connect to T-SSP.
>
>    Note that in Figure 1 - some elements defined are optional in many
>    use cases.
>
> Spencer (clarity): I would suggest "some elements included in Figure 1 are
> optional".
>
> 4.  Contexts of Use Cases
>
>    o  Next Hop Routing Determination - Resolving the SED information is
>       necessary to route the request to the T-SSP.  The LRF is used for
>       this determination.  The O-SSP may also use the standard procedure
>
> Spencer (minor): is this "The O-SSP may also use" or "Alternatively, the
> O-SSP may use"? The text says "in addition to", but I'm thinking you mean
> "instead of".
>
>       defined in [RFC3263] to discover the next hop address.
>
>    o  Call setup - SSPs that are interconnecting to one another may also
>       define specifics on what SIP features need to be used when
>
> Spencer (minor): are these SIP features? I'm thinking something more like
> "what unique interconnection parameters of this SIP peering arrangement must
> to be used", but you guys would be better at rephrasing, if you agree with
> the comment. For example, I'm not thinking port numbers are "SIP
> features"...
>
>       contacting the next hop in order to a) reach the next hop at all
>       and b) to prove that the sender is a legitimate peering partner.
>
>       Examples: hard-code transport (TCP/UDP/TLS), non-standard port
>       number, specific source IP address (e.g. in a private Layer-3
>       network), which TLS client certificate [RFC4366] to use, and other
>       authentication schemes.
>
>    o  Call reception - This step serves to ensure that the type of
>       relationship (static or on-demand, indirect or direct) is
>       understood and acceptable.  For example, the receiving SBE needs
>       to determine whether the INVITE it received really came from a
>       trusted member possibly via an access control list entry.
>
> Spencer (clarity): I think the sentence would be clearer if it ended "came
> from a trusted member."
>
> 5.  Use Cases
>
>    Please note there are intra-domain message flows within the use cases
>    to serve as supporting background information.  Only inter-domain
>    communications are germane to Speermint.
>
> Spencer (minor): I understand what you're saying, but as an RFC, this
> document will outlive the SPEERMINT working group. Perhaps "germane to this
> document"?
>
> 5.2.  Static Direct Peering Use Case
>
>    This is the simplest form of a peering use case.  Two SSPs negotiate
>    and agree to establish a SIP peering relationship.  The peer
>    connection is statically configured and is direct between the
>    connected SSPs.  The peers may exchange interconnection parameters
>
> Spencer (clarity): I would suggest "and the peer SSPs are directly
> connected".
>
>    such as DSCP [RFC2474] policies, the maximum number of requests per
>    second and proxy location prior to establishing the interconnection.
>    Typically, the T-SSP only accepts traffic originating directly from
>    the trusted peer.
>
>         Note that UAC inserted its Fully Qualified Domain Name (FQDN) in
>         the VIA and CONTACT headers.  This example assumes that UAC has
>         its own FQDN.  In the deployment where UAC does not have its own
>         FQDN, UAC may insert an IP address into the headers.
>
> Spencer (clarity): I would suggest c/its Fully/its own Fully/ in the first
> sentence, and dropping the second.
>
>    2.   UAC only knows UAS's TN but not UAS's domain.  It appends its
>
> Spencer (clarity): I would suggest "UAC knows UAS's TN, but does not know
> UAS's domain". Similar text appears in other use cases below.
>
>         own domain to generate the SIP URI in Request-URI and TO header.
>         O-Proxy checks the Request-URI and discovers that the Request-
>         URI contains user parameter "user=phone".  This parameter
>         signifies that the Request-URI is a phone number.  So O-Proxy
>         will extract the TN from the Request-URI and query LUF for SED
>         information from a routing database.  In this example, the LUF
>         is an ENUM [RFC3761] database.  The ENUM entry looks similar to
>         this:
>
>    7.   O-SBE sends the INVITE to T-SBE.  O-SBE is the egress point to
>         the O-SSP domain, so it should ensure subsequent mid-dialog
>         requests traverse via itself.  If O-SBE chooses to act as a
>         Back-to-Back User Agent (B2BUA) [RFC3261], it will terminate the
>
> Spencer (clarity): Your terminology is correct, but this sentence uses
> "terminate" to mean something different from what "terminate" means in the
> rest of the document. You just say "generate a new INVITE request in step 10
> below - perhaps s/terminate the call and//? This sentence also appears in
> other use cases later in the document.
>
>         call and generate a new INVITE request.  If O-SBE chooses to act
>         as a proxy, it should record-route to stay in the call path.  In
>         this example, O-SBE is a B2BUA.
>
>    12.  RTP is established between the UAC and UAS.  Note that the media
>         passes through O-DBE and T-DBE.
>
> Spencer (clarity): Is this "In this example, the media passes through O-DBE
> and T-DBE"? The text sounds like this always happens. The text in 5.3 is
> clearer that this is optional.
>
> 5.2.2.  Options and Nuances
>
>    In Figure 2 O-SSP and T-SSP peer via SBEs.  Normally, the operator
>    will deploy the SBE at the edge of its administrative domain.  The
>    signaling traffic will pass between two networks through the SBEs.
>    The operator has many reasons to deploy a SBE.  For example, either
>    proxy and UA may use [RFC1918] addresses that are not routable in the
>
> Spencer (clarity): is this "either operator's proxies and/or UAs may use
> [RFC1918] addresses that are not routable in the other operator's network"?
> I'm confused by "either proxy and UA", at any rate.
>
>    target network.  The SBE can perform a NAT function.  Also, the SBE
>    eases the operation cost for deploying or removing Layer-5 network
>    elements.  Consider the deployment architecture where multiple
>    proxies connect to a single SBE.  An operator can add or remove a
>    proxy without coordinating with the peer operator.  The peer operator
>    "sees" only the SBE.  As long as the SBE is maintained in the path,
>    the peer operator does not need to be notified.
>
>    SBE deployment is a decision within an administrative domain.  Either
>    one or both administrative domains can decide to deploy SBE(s).  To
>    the peer network, most important is to identify the next-hop address.
>
> Spencer (clarity): suggest for this sentence "This decision does not affect
> the peer network's ability ability to identify the next-hop address"
>
>    Whether the next-hop is a proxy or SBE, the peer network will not see
>    any difference.
>
> 5.3.  Static Direct Peering Use Case - Assisting LUF and LRF
>
>    The call flow looks almost identical to Static Direct Peering Use
>    Case except Step 2,4,5 and 6 which happen in LUF/LRF provider
>
> Spencer (clarity): suggest "except that Steps 2, 4, 5 and 6 involve the
> LUF/LRF provider" - and I'm not sure "remotely" is needed with this change.
>
>    remotely instead of happening in O-SSP domain.
>
> 5.3.1.  Administrative Characteristics
>
>    The LUF/LRF provider provides the LUF and LRF services for the O-SSP.
>    As such, LUF/LRF provider, O-SSP and T-SSP form a trusted
>
> Spencer (clarity): I'd suggest s/As such/Taken together/
>
>    administrative domain.  To reach T-SSP, O-SSP must still require pre-
>    arranged agreements for the peer relationship with T-SSP.  The
>    Layer-5 policy is maintained in the O-SSP and T-SSP domains, and the
>    LUF/LRF provider may not be aware of any Layer-5 policy between the
>    O-SSP and T-SSP.
>
>    A LUF/LRF provider can serve multiple administrative domains.  The
>    LUF/LRF provider typically does not share SED from one administrative
>    domain to another administrative domain without appropriate
>    permission granted.
>
> Spencer (clarity): I'd suggest s/ granted//
>
> 5.3.2.  Options and Nuances
>
>    The LRF/LRF provider can use multiple methods to provide SED to
>    O-SSP.  The most commonly used are an ENUM and a SIP Redirect.  The
>
> Spencer (clarity): is this "an ENUM lookup and a SIP Redirect"?
>
>    O-SSP should negotiate with the LUF/LRF provider which query method
>    it will use prior to sending request to LUF/LRF provider.
>
>    The T-SSP needs to populate its users' AORs and SED to the LUF/LRF
>    provider.  Currently, this procedure is non-standardized and labor
>
> Spencer (clarity): is this "The LUF/LRF provider must be populated with the
> T-SSP's users' AORs and SED"?
>
>    intensive.  A more detailed description of this problem has been
>    documented in the work in progress [I-D.ietf-drinks-cons-rqts].
>
> 5.4.  Static Indirect Peering Use Case - Assisting LUF and LRF
>
>    The difference between a Static Direct Use Case and a Static Indirect
>    Use Case lies within the Layer-5 relationship of which O-SSP and
>    T-SSP maintain.  In the Indirect use case, the O-SSP and T-SSP do not
>
> Spencer (clarity): I'd suggest s/of which O-SSP and T-SSP
> maintain/maintained by the O-SSP and T-SSP/
>
>    have direct Layer-5 connectivity.  They require one or multiple
>    Indirect Domains to assist routing the SIP messages and possibly the
>    associated media.
>
>    In this use case, the O-SSP and T-SSP want to form a peer
>    relationship.  For some reason, the O-SSP and T-SSP do not have
>    direct Layer-5 connectivity.  The reasons may vary, for example
>    business demands and/or domain policy controls.  Due to this indirect
>    relationship the signaling will traverse from O-SSP to one or
>
> Spencer (clarity): I'd suggest s/to/through/ (to reflect "traverse")
>
>    multiple I-SSP(s) to reach T-SSP.
>
>    In addition, O-SSP decides to use a LUF/LRF provider.  This LUF/LRF
>
> Spencer (clarity): I'd suggest s/decides to use/is using/
>
>    provider stores the T-SSP's SED pre-populated by T-SSP.  One
>    important motivation to use the LUF/LRF provider is that T-SSP only
>    needs to populate its SED once to the provider.  Any O-SSP who wants
>
> Spencer (clarity): I'd suggest "Using a LUF/LRF provider allows the T-SSP to
> populate its SED once, while any O-SSP who wants ..."
>
>    to query T-SSP's SED can use this LUF/LRF provider.  Current practice
>    has shown that it is rather difficult for the T-SSP to populate its
>    SED to every O-SSP who likes to reach the T-SSP's subscribers.  This
>
> Spencer (clarity): I'd suggest s/likes to/must/
>
>    is especially true in the Enterprise environment.
>
>         Note that the response shows the next-hop is the SBE in Indirect
>         SSP.
>
> Spencer (nit): I'd suggest s/Indirect SSP/I-SSP/
>
> 5.4.1.  Administrative characteristics
>
>    In this use case. there are two levels of trust relationship.  First
>    trust relationship is between the O-SSP and LUF/LRF provider.  The
>    O-SSP trusts the LUF/LRF to provide the T-SSP's SED.  Second trust
>    relationship is between O-SSP and I-SSP.  The O-SSP trusts the I-SSP
>    to provide Layer-5 connectivity to assist the O-SSP to reach T-SSP.
>    The O-SSP and I-SSP have a pre-arranged agreement for policy.  Note
>    that Figure 4 shows a single provider to provide both LUF/LRF and
>    I-SSP, O-SSP can choose two different providers.
>
> Spencer (clarity): suggest s/I-SSP, O-SSP/I-SSP, but O-SSP/
>
> 5.5.  Static Indirect Peering Use Case
>
>    This use case O-SSP uses its internal LUF/LRF.  One of the reasons of
>
> Spencer (clarity): suggest "In this use case, O-SSP uses its internal
> LUF/LRF".
>
>    using internal LUF/LRF is to control the routing database.  By
>    controlling the database, O-SSP can apply different routing rules and
>    policies to different T-SSPs.  For example, O-SSP can use I-SSP1 and
>    Policy-1 to reach T-SSP1, and use I-SSP2 and Policy-2 to reach
>    T-SSP2.  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 IETF DRINKS working group.
>
> Spencer (minor): again, this document as an RFC will outlive both working
> groups...
>
> 5.5.1.  Administrative characteristics
>
>    T-SSP <---> I-SSP = Relationship T-I
>
>    In the T-I relationship, typical policies, features or functions
>    observed consist of codec "scrubbing", anonymizing, and transcoding.
>    I-SSP must record-route and stay in the signaling path.  T-SSP will
>    not accept message directly sent from O-SSP.
>
> Spencer (nit): suggest s/message directly sent/messages sent directly/
>
> 5.5.2.  Options and Nuances
>
>    In Figure 5, we show I-DBE.  Using I-DBE is optional.  One scenario
>    the I-DBE can be used is when the O-SSP and T-SSP do not have a
>
> Spencer (clarity): Suggest s/One scenario the I-DBE can be used/For example,
> the I-DBE might be used/
>
>    common codec.  To involve I-DBE, I-SSP should know the list of codec
>
> Spencer (nit): s/codec/codecs/
>
>    supported by O-SSP and T-SSP.  When I-SBE receives the INVITE
>    request, it will make a decision to invoke the I-DBE.  Another
>    scenario an I-DBE can be used is if O-SSP uses SRTP [RFC3711] for
>
> Spencer (clarity): suggest "An I-DBE might also be used if"
>
>    media and T-SSP does not support SRTP.
>
> 5.6.  On-demand Peering Use Cases
>
>    On-demand Peering [RFC5486] describes two SSPs form the peering
>
> Spencer (clarity): suggest a/describes two/describes how two/
>
>    relationship without a pre-arranged agreement.
>
>    The basis of this use case is built on the fact that there is no pre-
>    established relationship between the O-SSP and T-SSP.  The O-SSP and
>    T-SSP does not share any information prior to the dialog initiation
>    request.  When the O-Proxy invokes the LUF and LRF on the Request-
>    URI, the terminating user information must be publicly available.
>    Besides, when the O-Proxy routes the request to the T-Proxy, the
>
> Spencer (clarity): suggest s/Besides, when/When/
>
>    T-Proxy must accept the request without any pre-arranged agreement
>    with O-SSP.
>
> 5.6.1.  Administrative characteristics
>
>    The On-demand Direct Peering Use Case is typically implemented in a
>    scenario where the T-SSP allows any O-SSP to reach its serving
>    subscribers.  T-SSP administrative domain does not require any pre-
>    arranged agreement to accept the call.  The T-SSP makes its
>    subscribers information available in public.  This model mimics the
>
> Spencer (clarity): is this "publicly available"?
>
>    Internet email model.  Sender does not need an pre-arranged agreement
>    to send email to the receiver.
>
> 5.6.2.  Options and Nuances
>
>    Similar to the Static Direct Peering Use Case, the O-SSP and T-SSP
>    can decide to deploy SBE.  Since T-SSP is open to the public, T-SSP
>    is considered to be in higher security risk than static model because
>    there is no trusted relationship between O-SSP and T-SSP.  T-SSP
>    should protect itself from any attack launch by untrusted O-SSP.
>
> Spencer (clarity): suggest s/launch/launched/
>
> 7.  Security Considerations
>
>    This document introduces no new security consideration.  However, it
>
> Spencer (minor): I'm not sure what "new" refers to here - is this "beyond
> RFC 3263", or "beyond ENUM", or ... ?
>
>    is important to note that session interconnect, as described in this
>    document, has a wide variety of security issues that should be
>    considered in documents addressing both protocol and use case
>    analyzes.  [I-D.niccolini-speermint-voipthreats] discuss the
>
> Spencer (minor): couldn't parse "use case analyzes" in this sentence.
>
> Spencer (minor): I'm wondering if the last sentence in this paragraph is
> enough ("look at the other draft")?
>
>    different security threats related to VoIP peering.
>
> 8.  IANA Considerations
>
>    This document creates no new requirements on IANA namespaces
>    [RFC5226].
>
> Spencer (clarity): we often include "Note to RFC Editor: please delete this
> section before publication" for null IANA sections, as Russ commented on one
> of MY recent drafts :-)

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf