[apps-discuss] Apps Directorate Review of draft-ietf-tcpm-experimental-options-02

Eliot Lear <lear@cisco.com> Thu, 15 November 2012 18:55 UTC

Message-ID: <50A53A9A.3040302@cisco.com>
Date: Thu, 15 Nov 2012 19:55:22 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: draft-ietf-tcpm-experimental-options.all@tools.ietf.org, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Content-Type: multipart/alternative; boundary="------------050102000802010603010604"
Cc: Wesley Eddy <wes@mti-systems.com>
Subject: [apps-discuss] Apps Directorate Review of draft-ietf-tcpm-experimental-options-02
Precedence: list

Dear Joe,

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).


Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-tcpm-experimental-options-02
Title: Shared Use of Experimental TCP Options
Reviewer: Eliot Lear
Review Date: 15 Nov. 2012
IETF Last Call Date: none.
IESG Telechat Date: none.

This document is not yet ready for publication, and requires
consideration of several major issues.  As an apps directorate reviewer,
I can say that since many if not most applications sit atop TCP, the
impact of experimental options can be quite serious.

Major Issues

I would want to know that the working group seriously considered a fixed
length for the magic field. In general, I'm uncomfortable with the
SHOULD for the size of the field, and would be more comfortable with a MUST.

More importantly this draft raises a concern about options that are
meant to be EXPERIMENTAL, but somehow the experiments got out of the
lab.  I'd like to understand how often this has actually been a
problem.  IMHO I don't understand why we would think that implementers
would follow the advice given in this draft if they didn't bother
attempting registering allocation with IANA (Section 1, Page 3).  This
section, needs to more clearly state the problem meant to be addressed.

If this draft is to move ahead, a specific PRN algorithm should be
recommended for selection of the magic number so as to avoid
collisions.  The SAAG folk can help here.

Similarly 3.2 argues against the whole concept.  Let's not try to
address backward compatibility of use of this feature with experiments
in this document, other than to say that this mechanism isn't intended
for use with a uniquely assigned option.

Minor Issues

The ASCII art in Section 3 should give field lengths.

I really don't know what to make of Section 3.1.  The SHOULD there tells
me to do something if my implementation is not robust, but then if I do
it, it is robust, right?  Clearer advise should be given.  Like perhaps
the following: if an implementation receives a response that does not
follow the the experiemental design, it MUST cease sending the option in
question and interpreting any such results, and SHOULD terminate the TCP
connection and try again.  Perhaps hosts participating in the experiment
should cache failures and log them?

Eliot

[apps-discuss] Apps Directorate Review of draft-i… Eliot Lear
Re: [apps-discuss] Apps Directorate Review of dra… Joe Touch
Re: [apps-discuss] Apps Directorate Review of dra… Eliot Lear
Re: [apps-discuss] Apps Directorate Review of dra… Joe Touch