TCP Friendly Rate Control (TFRC): Protocol Specification
draft-ietf-dccp-rfc3448bis-06

[Ballot comment]
I support Russ's discuss on the importance of a change summary.  Having diffed the
RFC and the ID, this appears to be a very significant revision covering many issues.
The change summary will help ensure readers find the appropriate changes.

It would be nice if the security considerations section was updated with some examples.
The document punts most security issues  to the "specific transport protocol and its
authentication mechanisms" and that is probably appropriate.  However, I would assume
that the details have been worked out for TCP since publication of 3448, and that
references to those solutions could easily be included.  That would be helpful in my opinion.

[Ballot comment]
I support Russ's discuss on the importance of a change summary.  Having diffed the
RFC and the ID, this appears to be a very significant revision covering many issues.
The change summary will help ensure readers find the appropriate changes.

It would be nice if the security considerations section was updated with some examples.
The document punts most security issues  to the "specific transport protocol and its authentication mechanisms" and that is probably appropriate.  However, I would assume
that the details have been worked out for TCP and that references to those solutions
could easily be included.  That would be helpful in my opinion.

[Ballot comment]
I support Russ's discuss on the importance of a change summary.  Having diffed the
RFC and the ID, this appears to be a very significant revision covering many issues.
The change summary will help ensure readers find the appropriate changes.

It would be nice if the security considerations section was updated with some examples.
The document punts most security issues  to the "specific transport protocol and its authentication mechanisms" and that is probably appropriate.  However, I would assume
that the details have been worked out for TCP and that references to those solutions
could easily be included.  That would be helpful in my opinion.

[Ballot comment]
I support Russ's discuss on the importance of a change summary.  Having diffed the
RFC and the ID, this appears to be a very significant revision covering many issues.
The change summary will help ensure readers find the appropriate changes.

[Ballot discuss]
I agree that the detailed change history should not be included in
  the final RFC; however, it is very helpful to include a summary of
  the changes since RFC 3448, which is obsoleted by this document once
  it is approved.  Another appendix would be a fine solution.

    (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

I have read this document and I think this is ready for publication.
The document shepherd is G. Fairhurst, DCCP WG Chair.

    (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

Yes, the document was reviewed in a WGLC 27-Feb-08 to 21-Mar-08
(extended because this covered the period surrounding an IETF meeting).

The WGLC revealed a set of issues, which have been addressed in this
revision of the draft. There were no objections to publishing this
as a standards-track replacement for RFC 3448.

    (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

No.

    (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

This is a revised version of RFC 3448. The algorithms presented are
complex. They are believed to be safe for use in the general Internet.

I am certain this is a considerable improvement in clarity than provided
in RFC 3448, although there is some scope for rewriting this in future
to improve the document, this would be a significant task. I can not
currently WG see energy to undertake this, nor is there the needed
implementation and operational experience to support this at this time.


    (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

This document had the support of the IETF DCCP WG.

    (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No.

    (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

Yes.

    (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The references have been verified.

    (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

There are no IANA actions required for this document.

    (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

Not appropriate.

    (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
              Relevant content can frequently be found in the abstract
              and/or introduction of the document.  If not, this may be
              an indication that there are deficiencies in the abstract
              or introduction.

This document is a product of the DCCP WG in the IETF Transport Area.
It specifies the TCP-Friendly Rate Control (TFRC) algorithm.  TFRC is a
congestion control mechanism for unicast flows operating in a best-
effort Internet environment.  It is reasonably fair when competing
for bandwidth with TCP flows, but has a much lower variation of
throughput over time compared with TCP, making it more suitable for
applications such as streaming media where a relatively smooth
sending rate is of importance.

If published, this document will obsolete RFC 3448 and update RFC 4342.

          Working Group Summary
              Was there anything in WG process that is worth noting?  For
              example, was there controversy about particular points or
              were there decisions where the consensus was particularly
              rough?

This document corrects and updated RFC 3448 (including addressing issues
noted in the RFC3448 Errata). It includes a set of other issues arising
from simulation of RFC 3448, implementation, and use by applications.
It also includes significant restructuring and editorial work to improve
the readability. Because of the significant changes in this revised spec,
the WG agreed this document should not be used as a request TFRC to
progress along the Standards Track.

          Document Quality
              Are there existing implementations of the protocol?  Have a
              significant number of vendors indicated their plan to
              implement the specification?  Are there any reviewers that
              merit special mention as having done a thorough review,
              e.g., one that resulted in important changes or a
              conclusion that the document had no substantive issues?  If
              there was a MIB Doctor, Media Type or other expert review,
              what was its course (briefly)?  In the case of a Media Type
              review, on what date was the request posted?

The DCCP WG has reached consensus that this document is ready for
publication, and recommends publication on the IETF Standards Track. It
was not possible to contact the full set of authors in the period
leading up to the WGLC (a separate note has been sent to the ADs).

The document specifies an algorithm, rather than a protocol.
There are currently therefore no full implementations of this new
specification. However, some parts of this have been implemented
widely (based on RFC 3448 and its updates) and several implementaters
have used this as the basis for their implementation / simulation in
the context of DCCP CCID-3 (RFC4342) . Several of these people provided
feedback (before and at WGLC) that have resulted in changes being made
to the spec. There have been no reported interoperability tests.

The WG decided that this document should also update the algorithm
specified for TFRC in RFC 4342. This topic was first raised at IETF-68.
The proposal to update RFC 4342 was confirmed at IETF-71.

  (end)