OPS-DIR review of draft-ietf-speermint-requirements

[Bernard Aboba <[e-mail]>]

I reviewed the document draft-ietf-speermint-requirements-07.txt in general
and for its operational impact.

Operations directorate reviews are solicited primarily to help the area
directors improve their efficiency, particularly when preparing for IESG
telechats, and allowing them to focus on documents requiring their attention
and spend less time on the trouble-free ones.

Improving the documents is important, but clearly a secondary purpose.
A third purpose is to broaden the OpsDir reviewers' exposure to work going
on in other parts of the IETF.

Reviews from OpsDir members do not in and of themselves cause the IESG to
raise issue with a document. The reviews may, however, convince individual
IESG members to raise concern over a particular document requiring further
discussion. The reviews, particularly those conducted in last call and
earlier, may also help the document editors improve their documents.

--

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.

2. Does it contain nits?

Yes.  See below.

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.

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".

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.

6. Does the solution preclude future activity?

As a requirements document, the goal is to guide future activity.

7. Is the solution sufficiently configurable?

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.

8. Can performance be measured?

Performance metrics are discussed in Appendix A.1.

9. Does the solution scale well?

Given that the document focuses on requirements, the scalability of the (as yet to be determined) solution is out of scope.

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].

------------------------------------------------
idnits 2.11.11

tmp/draft-ietf-speermint-requirements-07.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** It looks like you're using RFC 3978 boilerplate.  You should update this
     to the boilerplate described in the IETF Trust License Policy document
     (see http://trustee.ietf.org/license-info), which is required from
     December 16, 2008.  Version 1.34 of xml2rfc can be used to produce
     documents with boilerplate according to the mentioned Trust License
     Policy document.

  -- Found old boilerplate from RFC 3978 Section 5.1 on line 15.

     The obsolete RFC 3978 Section 5.1 text:
     "By submitting this Internet-Draft, each author represents that any
      applicable patent or other IPR claims of which he or she is aware
      have been or will be disclosed, and any of which he or she becomes
      aware will be disclosed, in accordance with Section 6 of BCP 79."

  -- Found old boilerplate from RFC 3978 Section 5.5 updated by RFC 4748 on
     line 971.

     The obsolete RFC 3978 Section 5.5 updated by RFC 4748 text:
     "This document and the information contained herein are provided on an
      "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
      IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
      WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
      WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
      ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
      FOR A PARTICULAR PURPOSE."

  -- Found old boilerplate from RFC 3979 Section 5 paragraph 1 on line 982.

     The obsolete RFC 3979 Section 5 paragraph 1 text:
     "The IETF takes no position regarding the validity or scope of any
      Intellectual Property Rights or other rights that might be claimed
      to pertain to the implementation or use of the technology described
      in this document or the extent to which any license under such
      rights might or might not be available; nor does it represent that
      it has made any independent effort to identify any such rights.
      Information on the procedures with respect to rights in RFC
      documents can be found in BCP 78 and BCP 79."

  -- Found old boilerplate from RFC 3979 Section 5 paragraph 2 on line 989.

     The obsolete RFC 3979 Section 5 paragraph 2 text:
     "Copies of IPR disclosures made to the IETF Secretariat and any
      assurances of licenses to be made available, or the result of an
      attempt made to obtain a general license or permission for the use
      of such proprietary rights by implementers or users of this
      specification can be obtained from the IETF on-line IPR repository
      at http://www.ietf.org/ipr."

 -- Found old boilerplate from RFC 3979 Section 5 paragraph 3 on line 995.

     The obsolete RFC 3979 Section 5 paragraph 3 text:
     "The IETF invites any interested party to bring to its attention any
      copyrights, patents or patent applications, or other proprietary
      rights that may cover technology that may be required to implement
      this standard.  Please address the information to the IETF at
      [e-mail]."


  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust Copyright Line does not match the
     current year

  == The document seems to lack a disclaimer for pre-RFC5378 work, but was
     first submitted before 10 November 2008.  Should you add the disclaimer?
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.).

     trust-12-feb-2009 Section 6.c.iii text:
     "This document may contain material from IETF Documents or IETF
      Contributions published or made publicly available before November
      10, 2008.  The person(s) controlling the copyright in some of this
      material may not have granted the IETF Trust the right to allow
      modifications of such material outside the IETF Standards Process.
      Without obtaining an adequate license from the person(s)
      controlling the copyright in such materials, this document may not
      be modified outside the IETF Standards Process, and derivative
      works of it may not be created outside the IETF Standards Process,
      except to format it for publication as an RFC or to translate it
      into languages other than English."


Checking references for intended status: Informational
----------------------------------------------------------------------------

  == Outdated reference: A later version (-07) exists of
     draft-ietf-avt-dtls-srtp-05

  == Outdated reference: A later version (-03) exists of
     draft-ietf-pmol-sip-perf-metrics-01

  == Outdated reference: A later version (-13) exists of
     draft-ietf-sip-connect-reuse-11

  == Outdated reference: A later version (-07) exists of
     draft-ietf-sip-dtls-srtp-framework-04

  == Outdated reference: draft-ietf-sip-hitchhikers-guide has been published
     as RFC 5411

  == Outdated reference: A later version (-08) exists of
     draft-ietf-speermint-architecture-06

  == Outdated reference:
     draft-ietf-speermint-consolidated-presence-im-usecases has been published
     as RFC 5344

  == Outdated reference: draft-ietf-speermint-terminology has been published
     as RFC 5486

  == Outdated reference: A later version (-12) exists of
     draft-ietf-speermint-voip-consolidated-usecases-10

  == Outdated reference: A later version (-05) exists of
     draft-niccolini-speermint-voipthreats-04

  -- Obsolete informational reference (is this intentional?): RFC 3603
     (Obsoleted by RFC 5503)


     Summary: 1 error (**), 12 warnings (==), 6 comments (--).

-----------------------------------------------------------------------------
Date: Tue, 30 Jun 2009 09:57:49 +0800
From: [e-mail]
Subject: Operations Directorate Review
To: [e-mail]
CC: [e-mail]; [e-mail]

Hello Aboba,
As a member of the Operations Directorate you are being asked to review the
following IESG work item for it's operational impact.

IETF Last Call:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-07.txt

Please provide comments and review to the Ops-dir mailing list
([e-mail]) within the next two weeks, and include the authors of the
draft as well.


Thank you,
Tina
http://tinatsou.weebly.com/contact.html