RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (2)

RFC 5595, "The Datagram Congestion Control Protocol (DCCP) Service Codes", September 2009

Source of RFC: dccp (tsv)

Errata ID: 3815

Status: Verified
Type: Technical

Reported By: Gorry Fairhurst
Date Reported: 2013-11-29
Verifier Name: Martin Stiemerling
Date Verified: 2015-12-16

Section 2.2 says:

All standards assigned Service Codes, including
all values assigned by IANA, are required to use a value that may be
represented using a subset of the ASCII character set.

It should say:

Requests for a Service Code in the IANA Considerations section of a
Standards-Track specification are to be assigned from the
Specifications-Required portion of the Service Code registry.
These assignments are required to use a value that may be
represented using a subset of the ASCII character set (see section 5).

Notes:

RFC 5595 did not clearly specify the intended update to RFC 4340. An update is also required to section 10.3.1 to be consistent.

Errata ID: 3816

Status: Verified
Type: Technical

Reported By: Gorry Fairhurst
Date Reported: 2013-11-29
Verifier Name: Martin Stiemerling
Date Verified: 2015-12-16

Section 5 says:

This document does not update the IANA allocation procedures for the
DCCP Port Number and DCCP Service Codes Registries as defined in RFC
4340.

It should say:

This document does not update the IANA allocation procedures for the
DCCP Port Number Registry as defined in RFC 4340. Section 2.2 of
this document updated the IANA allocation procedures for the DCCP
Service Codes Registry by requiring Service Code assignments
by a Standards-Track specification to be assigned from the
Specifications-Required portion of the Service Code registry.

Notes:

RFC 5595 did not clearly specify the intended update to RFC 4340. An update is also
required to section 10.3.1 to be consistent in RFC 6335.

Status: Held for Document Update (1)

RFC 5595, "The Datagram Congestion Control Protocol (DCCP) Service Codes", September 2009

Source of RFC: dccp (tsv)

Errata ID: 1891

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2009-09-22
Held for Document Update by: Lars Eggert
Date Held: 2011-03-01

Section 2.7, pg.10 says:

OLD:
 o  It preserves the 4 lowest bits of the final bytes of the Service
    Code, which allows many common series of Service Codes to be
    mapped to a set of adjacent port numbers, e.g., Foo1, and Foo2;
    Fooa and Foob would be assigned adjacent ports.

It should say:

NEW:
 o  It preserves the 3 lowest bits of the final bytes of the Service
                     ^^
    Code, which allows many common series of Service Codes to be
    mapped to a set of adjacent port numbers, e.g., Foo1, and Foo2;
    Fooa and Foob would be assigned adjacent ports.

Notes:

Simply trying the full example shows that the statement is not
entirely correct. The quoted formula reveals that only the least
significant *3* bits are left unchanged (due to the '<<3'
operation on sc[2]). It turns out that ranges of *8* contiguous
SC values are mapped to contiguous 8 port numbers but, depending
on the two least significant bits of sc[2], groups of 4 adjacent
ranges are shuffled around. More complicated patterns arise for
the next higher level of 4-clusters of range-groups, etc.
Thus, the situation is not hopeless for the indicated purpose,
but much more complicated than indicated in the RFC text.

I leave it as an exercise to the interested reader to figure
out the details for the size of range she is interested in.

A future revision of the RFC however should fix the text.

Report New Errata