Subject: [BEHAVE] BEHAVE WG errata review

From: Dave Thaler <[email-masked]>
Date: Thu, 19 Jan 2012 20:10:44 +0000

Below is my review of the 6 Behave errata currently in the reported state.
Note that changing the state of errata is something only the IESG can do.
The WG just makes recommendations.

| RFC5780 |      2939 | 2011-08-17     | John Selbie     | behave   | Technical | 

Verified.  But not worth opening the doc for in my opinion.
The doc contradicts itself, one place saying that OTHER-ADDRESS has the
same value as CHANGED-ADDRESS did, and the other place giving a new
value, which matches the IANA registry.  The statement explaining why it 
has the same value (which it doesn't) should be removed.

Propose to move to "Hold for Document update" per guideline 
"Things that are clearly wrong but could not cause an implementation
or deployment problem should be Hold for Document Update."

| RFC5389 |      2972 | 2011-09-16     | Jack Bates      | behave   | Editorial |

Verified.  But not worth opening the doc for since as the reporter states,
the intent is already quite clear.  This is trivial where the lines in the bit
diagram don't line up (the fields shown are 17 and 15 bits instead of
16 and 16, where the text says 16).

Propose to move to "Hold for Document update" per guideline 
"Things that are clearly wrong but could not cause an implementation
or deployment problem should be Hold for Document Update."

| RFC6147 |      2975 | 2011-09-18     | Libor Polcak    | behave   | Technical | 

Verified.  But not worth opening the doc for since the intent is already
clear in my view. The sentence preceding the quoted one mentions 
"::ffff:0:0/96" and then the quoted sentence says "::ffff/96" when it 
means the former.   This is similar to treating "192.168.0.0/16" and
"192.168/16" as synonymous, but the "::" makes it more confusing.

Propose to move to "Hold for Document update" per guideline 
"Things that are clearly wrong but could not cause an implementation
or deployment problem should be Hold for Document Update."

| RFC6145 |      3060 | 2011-12-23     | Gandhar Gokhale | behave   | Technical | 

I believe the filer is correct.  The RFC does not contain the right statement with
respect to handling of IPv6 extension headers.   It says they're skipped when 
filling in the payload but it doesn't say they're skipped when filling in the
length field.

Propose to move to "Approved" per guideline "Only errors that could cause 
implementation or deployment problems or significant confusion should be
Approved."

However, since the filer proposes what the "corrected" behavior is, I believe
we need WG consensus to approve that statement.

| RFC6145 |      3059 | 2011-12-23     | Gandhar Gokhale | behave   | Technical | 

I believe the filer is correct.  Although the intent might be clear from Section 4:
" As with [RFC2765], the translating function specified in this
   document does not translate any IPv4 options, and it does not
   translate IPv6 extension headers except the Fragment Header."

Although the Length portion of the omitted paragraph is actually covered by
errata ID 3060 above (and we don't need 2 technical errata for the same thing)
the omitted paragraph does contain a statement about how to fill in the 
Protocol field when IPv6 extension headers were present, which is nowhere 
else in the doc and might not be obvious to an implementer from the 
section 4 text.

As such, propose to move to "Approved" per guideline "Only errors that 
could cause implementation or deployment problems or significant confusion
should be Approved."

| RFC6145 |      3061 | 2011-12-23     | Gandhar Gokhale | behave   | Technical |

The filer proposes to add a SHOULD to drop a fragment that couldn't be 
reassembled at the destination (and proposes language that isn't tight, 
since it doesn't say what the alternative to the SHOULD is, so I would not
want to move it to Approved).

I think this falls into the guideline
"Changes that modify the working of a protocol to something that might
be different from the intended consensus when the document was approved
should be either Hold for Document Update or Rejected. Deciding between
these two depends on judgment. Changes that are clearly modifications to
the intended consensus, or involve large textual changes, should be 
Rejected. In unclear situations, small changes can be Hold for Document 
Update."

Hence propose "Hold for Document Update".

-Dave