26 Oct 2009 15:04
Re: OPS-DIR review from Bernard Aboba ondraft-ietf-speermint-requirements-08
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].
SIP-SIPS is now out as RFC 5630.
Mike
> -----Original Message-----
> From: speermint-bounces@... [mailto:speermint-bounces@...]
On
> Behalf Of Jean-Francois Mule
> Sent: Monday, October 26, 2009 7:11 AM
> To: Bernard Aboba
> Cc: speermint@...
> Subject: Re: [Speermint] OPS-DIR review from Bernard Aboba
ondraft-ietf-
> speermint-requirements-08
>
> 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@...
> ---
> 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].
> _______________________________________________
> Speermint mailing list
> Speermint@...
> https://www.ietf.org/mailman/listinfo/speermint
RSS Feed