Subject: RFC 4728 errata

From: Alfred Hönes <[email-masked]>
Date: Fri, 20 Apr 2007 21:05:12 +0200 (MESZ)

Hello,
I've studied the recently published RFC 4728 (DSR) authored by you.

In general, this seems to be a very clear and technically complete
description, and well edited -- irrespective of the sheer size of
the text.

Notwithstanding that, I have found a few textual issues in that RFC.

The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

(1)  Section 4.1

In the 4th paragraph on page 28 (this is the first bullet below
the non-indented text starting "Any suitable data structure ..."),
the RFC says:

   -  In DSR, the route returned in each Route Reply that is received by
      the initiator of a Route Discovery (or that is learned from the
|     header of overhead packets, as described in Section 8.1.4)
      represents a complete path (a sequence of links) leading to the
      destination node.  [...]

In this case, I'm quite sure it was inteded to not talk about
"overhead" packets, but (promiscuously) "overheard" packets!
Hence, the RFC should say:

   -  In DSR, the route returned in each Route Reply that is received by
      the initiator of a Route Discovery (or that is learned from the
|     header of overheard packets, as described in Section 8.1.4)
      represents a complete path (a sequence of links) leading to the
      destination node.  [...]

(2)  Section 6.4

On page 44, the explanation for "Opt Data Len" says:

         [...]
         When the Opt Data Len is greater than that required for
         the fixed portion of the Route Error plus the necessary
|        Type-Specific Information as indicated by the Option Type
         value in the option, the remaining octets are interpreted as
         extensions.  [...]

As can be seen from the context, the "Type-Specific Information" is
dependent on the "Error Type" field value, not the "Option Type"
field value.
Hence, the RFC should say:

         [...]
         When the Opt Data Len is greater than that required for
         the fixed portion of the Route Error plus the necessary
|        Type-Specific Information as indicated by the Error Type
         value in the option, the remaining octets are interpreted as
         extensions.  [...]

(3)  Section 6.5

Almost everywhere in Sections 6 and 7, the RFC is very explicit
in specifying the value of length fields, giving fixed values
or a formula, if necessary.
There are two exceptions, in Section 6.5 and 6.6 (see below).

The explanation in Section 6.5, on page 47, says:

      Opt Data Len

         8-bit unsigned integer.  Length of the option, in octets,
         excluding the Option Type and Opt Data Len fields.

This is generally true.  But in this case, special care is needed.
I strongly recommend to expand on this text, saying:

      Opt Data Len

         8-bit unsigned integer.  Length of the option, in octets,
         excluding the Option Type and Opt Data Len fields. In the
         basic form of this Option, this field has the value 2.
         (See Section 7.4.1 for an extended version of this Option.)

Note: Section 7.4.1 gives all the details you'll ever want,
      so just placing the pointer here is most efficient!

(4)  Section 6.6

As indicated in item (3) above, a similar lack of precision
can be found in Section 6.6, near the bottom of page 47.
The RFC says:

      Opt Data Len

         8-bit unsigned integer.  Length of the option, in octets,
         excluding the Option Type and Opt Data Len fields.

It should better say:

      Opt Data Len

         8-bit unsigned integer.  Length of the option, in octets,
         excluding the Option Type and Opt Data Len fields.  In this
         case, the value of this field is always 10.

(5)  Section 7.1 -- mismatch in terminology

There's a small terminological inconsistency in this Section.

The Flow State Header diagram on page 52 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |  Next Header  |F|  Hop Count  |        Flow Identifier        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Deviating from the term used there (and in the remainder of the text),
the explanation at the end of the section (still on page 52) says:

                   vvvvvv
|     Flow Identification

         The flow ID for this flow, as described in Section 3.5.1.

It should say:
                   vv
|     Flow Identifier

         The flow ID for this flow, as described in Section 3.5.1.

(6)  Section 8.2.1 -- missing article

The second-to-last paragraph of section 8.2.1, on page 66, says:
                                                        v
|  The behavior of a node processing a packet containing DSR Options
   header with both a DSR Source Route option and a Route Request option
   is unspecified.  [...]

It should better say:
                                                        vvv
|  The behavior of a node processing a packet containing a DSR Options
   header with both a DSR Source Route option and a Route Request option
   is unspecified.  [...]

(7)  Section 8.6.2

The procedure specified in Section 8.6.2 is a bit misleading in its
last step; if followed literally, it will mess up the packet in the
case that there is any Hop-by-Hop Options header present after the
IP header.

The procedure is (on page 88):

   -  Insert a DSR Flow State header after the IP header and any Hop-
      by-Hop Options header that may already be in the packet, but
      before any other header that may be present.

   -  Set the Next Header field of the DSR Flow State header to the Next
      Header field of the previous header (either an IP header or a
      Hop-by-Hop Options header).

   -  Set the Flow (F) bit in the DSR Flow State header to 1.

|  -  Set the Protocol field of the IP header to the protocol number
      assigned for DSR (48).
                                    ^^
The last step should say instead:
                                    vvvvvvvv
|  -  Set the Protocol field of the previous header to the protocol
      number assigned for DSR (48).

Note: I have reused wording from the second step because
that's exactly where the new header gets 'plugged in'..

Please comment.

IMHO, all these items seem to be appropriate for an Errata Note;
in particular, items (1), (2), (5) and (7) SHOULD be addressed.

Preferrably, you should submit an Author's Errata Note to the
RFC Editor's RFC Errata web pages, making freely use of the
material supplied above.  But if you like, I can formally
submit an Errata Note on my own, with your consent.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Dave Maltz <[email-masked]>
Date: Fri, 20 Apr 2007 14:00:41 -0700

Alfred,

Thank you very much for your careful read of the DSR RFC!

Going through your points one by one, here's my thoughts on them.

1) - agreed
2) - I need to go check
3) - agreed
4) disagree.  I'd prefer the original wording.
5) - agreed
6) - agreed
7) - agreed

Dave, Yih-Chun - any preference on the path forward?  Shall we submit an Author's Errata as Alfred suggests?

-dam

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, April 20, 2007 12:05 PM
> To: [email-masked]; Dave Maltz; [email-masked]
> Cc: [email-masked]
> Subject: RFC 4728 errata
>
> Hello,
>   Alfred HÎnes.