Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP)
draft-ietf-dccp-tfrc-rtt-option-06

[Ballot comment]
This document, which is in the Standards Track, updates RFC 5622, which is an experimental RFC. The authors may want to point out the fact that RFC 5622 is Experimental somewhere in the document.

I have cleared my discuss based on the discussion in the telechat.

[Ballot comment]
This document, which is in the Standards Track, updates RFC 5622, which is an experimental RFC. The authors may want to point out the fact that RFC 5622 is Experimental somewhere in the document.

[Ballot discuss]
This document updates RFC 5622. However, the reference to RFC 5622 was made Informative because RFC 5622 is Experimental. I believe the reference should be a Normative one because the document is actually updating RFC 5622. However, if the reference is made normative , it would be count as a downref. Let's discuss this issue in the telechat.

[Ballot discuss]
A fine document. I have no issue with its publication, but there is a small finge case, that seems to be a little hole.

3.2.1

  A value of 0 indicates the absence of a valid RTT sample.  The sender
  MUST set the value to 0 if it does not yet have an RTT estimate.   

How do you indicate a RTT estimate of less than 1 microsecond?
You should at lea st say that this document assumes that RTTs of less
than 1 microsecond will not be observed in the type of network in
which this option is run. An alternative would be to say that RTT
estimates of less than 1 microsecond MUST be reported as 1 microsecond.
You might cover this second case, by saying that estimates MUST be
rounded up to the nearest microsecond.

[Ballot comment]
The document looks technically solid to me, and to the TSVDIR reviewer (Mark Allman).  The authors can consider whether any minor editorial changes could help with some of Mark's editorial comments, at their perogative.

IANA understands that, upon approval of this document, there are two
IANA Actions which must be completed.

First, in the Option Types subregistry of the Datagram Congestion
Control Protocol (DCCP) Parameters located at:

http://www.iana.org/assignments/dccp-parameters/dccp-parameters.xml

a new option type is to be added from the 128/191 range is to be
registered as follows:

Type:  (see note above, from 128/191 range).
Description/Meaning: RTT Estimate Option
Reference: [ RFC-to-be ]

Second, in the Feature Numbers subregistry of the Datagram Congestion
Control Protocol (DCCP) Parameters located at:

http://www.iana.org/assignments/dccp-parameters/dccp-parameters.xml

a new Feature Number is to be registered as follows in the range 128/191:

Number:  (see note above, from 128/191 range)
Description/Meaning: RTT Estimate
Reference: [ RFC-to-be ]

IANA understands that these are the only actions required upon approval
of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Sender RTT Estimate Option for DCCP) to Proposed Standard


The IESG has received a request from the Datagram Congestion Control
Protocol WG (dccp) to consider the following document:
- 'Sender RTT Estimate Option for DCCP'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-03-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dccp-tfrc-rtt-option/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dccp-tfrc-rtt-option/

Sender RTT Estimate Option for DCCP
draft-ietf-dccp-tfrc-rtt-option-03


  (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?

The Document Shepherd is Pasi Sarolahti. The shepherd has read the
latest version of the document and believes this is ready for
publication.


  (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?

Earlier versions of the document have been thoroughly discussed in the
working group mailing list. Two working group participants provided
detailed reviews on an earlier version of the document before the WG
last call. The shepherd believes the document is adequately reviewed.


  (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. The document is focused on the specifics of DCCP CCID-3 / CCID-4 RTT
estimation, and the shepherd believes that there has been sufficient
expertise within the working group to evaluate the technical quality.


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

No.


  (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?

Among the traditionally small number of active DCCP participants,
there is a WG consensus for publishing the document, and no opinions
were raised against publishing it.


  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize 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?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

Yes. The intended status is Standards Track, as indicated on the first
page.


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

Yes. All normative references are final RFCs, and there are no
downward normative references.


  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations 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 the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

Yes. The document contains IANA considerations for a new DCCP option number
and a new DCCP feature number (in existing registries), that are
clearly described in a separate section, and consistently referred to in
the rest of the 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?

Yes (there are no such sections).


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

The document describes problems in the current DCCP CCID-3 and CCID-4
receiver-based algorithm for estimating round-trip time, and proposes
an enhancement to round-trip time evaluation by using a new Sender
round-trip time estimate DCCP option. With the option, it is possible
to measure RTT at the sender, and communicate the measured value to
receiver, which results in more reliable RTT samples.


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

The document is a product of the DCCP WG, receiving sufficient review along
its preparation. There were no controversies in WG Last Call, and the
WG is in agreement to publish this document.


          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 document is based on observations from a real DCCP implementation
on Linux kernel, and its authors are closely familiar with the
implementation. The document reviewers include one of the authors of
the original DCCP specification.


          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?  If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'

Document shepherd is Pasi Sarolahti .
Responsible Area Director is Lars Eggert .