Re: [Speermint] OPS-DIR review from Bernard Aboba on draft-ietf-speermint-requirements-08

["Jean-Francois Mule" <jf.mule at cablelabs.com>]

First, thank you Bernard for the OPS-DIR review on this draft from
speermint.

I apologize for the delay in my response to you. 
You had provided these comments before the last IETF and I waited for
the IESG reviews that came in 2 weeks ago to address them.  

I will be submitting draft-08 which does address your comments (at least
most of them).  
I may release another update after the IETF in Hiroshima based on the
feedback I receive, especially to add more background on some of the
requirements (and to fully address some of your notes).

Details inline below.

Thank you,
Jean-Francois
jfm at cablelabs.com
---
On Tue Jun 30 09:38:23 PDT 2009, Bernard Aboba bernard_aboba at
hotmail.com wrote:
> Review Summary:
> Intended status: Informational
> 
> This document discusses requirements for session peering in voice,
> presence, instant messaging and multimedia.
> 
> 1. Is the document readable?
> 
> In general, the document provides a readable listing of
> requirements.  However additional background on the requirements
> could have been provided, which would make the document easier to
> understand.

Yes. I've updated the introduction to point to the reader to background
documents:
   "A number of documents have been developed to provide
    additional background information about SIP session
    peering. It is expected that the reader is familiar
    with the reference architecture described in
    <xref target="I-D.ietf-speermint-architecture"/>
    and use cases which describe how session peering
    has been or could be deployed for voice (<xref 
    target="I-D.ietf-speermint-voip-consolidated-usecases"/>)
    and instant messaging and presence 
    (<xref target="RFC5344"/>)."


I understand your comment to also mean that some background is lacking
on specific requirements.  I've updated a few, and plan to do more
editing in the next revision based on WG feedback.


> 2. Does it contain nits?
> 
> Yes.  See below.
Fixed these and a few others, thank you for catching those.


> 3. Is the document class appropriate?
> 
> Yes.
> 
> 4. Does the document consider existing solutions?
> 
> This is a requirements document, so it largely focuses on
> requirements rather than solutions.
> 
> However, there are instances where the document does not
> sufficiently discuss existing practices.
The exciting DNS practices for *SIP traffic exchanges* as discussed
inside the Speermint WG have been captured to the best of my knowledge.
When we started this work, it was not uncommon to find IP addresses in
SIP URIs (and some still do).  Sections like 3.3.1. reinforce the use of
DNS.


> For example, in Section 3.2 the document refers to limitations of
> DNS in providing different responses based on the querier:
> 
> "However, this DNS-based solution may be limited
> in cases where the DNS response varies based on who sends the
> query (peer-dependent SBEs, see below)....
> 
> Notes on solution space:
> For advertising peer-dependent SBEs (peer variability), the
> solution space based on [RFC3263] is under specified and there are
> no know best current practices.  Is DNS the right place for
> putting data that varies based on who asks?"
> 
> Content Distribution Networks (CDNs) have quite a bit of
> operational experience with use of DNS to provide
> "data that varies based on who asks".  Information on existing
> approaches is provided in RFCs 3466, 3568,
> and 3570. CDNs also have experience in use of application re-direct
> for global load balancing.  I was
> therefore somewhat surprised that this document did not discuss or
> reference work on CDNs.
> 
> While the document focuses on layer 5 peering, it does seem like it
> would be worthwhile to at least have
> some discussion of lower layer load balancing techniques such as
> anycast (e.g. RFC 4786), which when
> combined with DNS can be used to provide "data that varies based on
> who asks".

Your comment below points are insightful and they point to one aspect of
this draft, the use of RFC3263 and DNS to locate the SIP signaling
entities of your peers and how peers can give different entry points
using DNS.

I've read the references and see the benefits of pointing out those in
the notes about the solution space.  I made a few edits to capture them
in draft-08.  In particular, the new text for req#4 says:

   o  Requirement #4:
      The mechanisms recommended for the declaration or advertisement of
      SBE and DBE entities MUST allow for peer variability.

      Notes on solution space:
      A simple solution is to advertise SBE entities using DNS and
      [RFC3263] by providing different DNS names to different peers.
      This approach has some practical limitations because the SIP URIs
      containing the DNS names used to resolve the SBEs may be
      propagated by users, for example in the form of sip:user at domain.
      It is impractical to ask users to use different target URIs based
      upon their SIP service provider's desire to receive incoming
      session signaling at different ingress SBEs based upon the
      originator.  The solution described in [RFC3263] and based on DNS
      to advertise SBEs is therefore under-specified for this
      requirement.
      Other DNS mechanisms have been used extensively in other areas of
      the Internet, in particular in Content Distribution
      Internetworking to make the DNS responses vary based on the
      originator of the DNS query (see [RFC3466], [RFC3568] and
      [RFC3570]).  The applicability of such solutions needs for session
      peering needs further analysis.
      Finally, other techniques such as Anycast services ([RFC4786]) may
      be employed at lower layers than Layer 5 to provide a solution to
      this requirement.  For example, anycast nodes could be defined by
      SIP service providers to expose a common address for SBEs into
      DNS, allowing the resolution of the anycast node address to the
      appropriate peer-dependent service address based on the routing
      topology or other criteria gathered from the combined use of
      anycast and DNS techniques.

Let me know if this is a first step to address your comment.
I am not sure about putting more details on the solutions used in CDN
networks in this document given the document's intent to catalog the
solution space along with requirements.  I welcome more feedback.


> 5. Does the solution break existing technology?
> 
> This is a requirements document, so that it doesn't specify
> solutions.  However, as described above I would
> like to see a more in-depth discussion of the capabilities and
> limitations of existing technology.

Noted, I tried to improve the text in a number of places.

> 6.  [snip]
> 
> 7. Is the solution sufficiently configurable?/an
> 
> While the document focuses on requirements rather than solutions, I
> do think it would be valuable to
> discuss the potential service provider objectives in more detail.
> For example, specifying exit and
> entry points is a means, not an end.  Within the CDN space, we have
> come to understand that the "best"
> server may depend on whether the goal is to optimize latency or
> throughput.

Understood.  Draft-08 may still have places where these objectives need
to be expanded.

> 8. [snip]
> 
> 9.  [snip]
> 
> 10. Is Security Management discussed?
> 
> Section 5 discusses security requirements.   Note that since the
> publication of RFC 3263, a number of additional documents
> have been dealt with the issue of TLS session establishment.  These
> documents (such as draft-ietf-sip-sips) may be worth
> referencing in addition to RFC 3263 within Section 3.2:
> 
>       The mechanisms recommended for locating a peer's SBE MUST be
> able
>       to convey how a peer should initiate secure session
> establishment.
> 
>       Notes : some mechanisms exist.  For example, the required
> protocol
>       use of SIP over TLS may be discovered via [RFC3263].

Yes, good point.
New text says:
   It is desirable for an SSP to be able to communicate how
   authentication of a peer's SBEs will occur (see the security
   requirements for more details).

   o  Requirement #6:
      The mechanisms recommended for locating a peer's SBE MUST be able
      to convey how a peer should initiate secure session establishment.

      Notes: some mechanisms exist.  For example, the required protocol
      use of SIP over TLS may be discovered via [RFC3263] and guidelines
      concerning the use of the SIPS URI scheme in SIP have been
      documented in [I-D.ietf-sip-sips].