Document: draft-ietf-forces-implementation-report-02 
Reviewer: Ben Campbell
Review Date: 11 Aug 2010
IESG Telechat date: 12 Aug 2010

Note: I apologize for the lateness of this review. I just came back from 
a post-IETF vacation, and failed to notice the assignment until this 
afternoon. Furthermore, I failed to review it at IETF LC due to an unrelated 
scheduling issue. I recognize that dumping this on the authors at the 
last minute will cause them inconvenience, and ask their forgiveness.

Summary: While this seems to be a well written implementation report, I'm 
not sure it supports the conclusion of progressing to draft standard. 
See the major issue below for details.

Major issues:

-- Sections 3 and 5:

Section 3 says the authors attest that the protocol, model, and 
SCTP-TML meet the requirements for draft standard.

Section 5 says all the "main" features have been implemented and tested, 
but that not all features have been implemented by all implementations. 
Further inspection of the implementation tables show that there are some 
features that have not been supported by at least two implementations. 
The section goes on to say that all implementors have stated the intent to 
implement all features.

I don't think "intent" helps much here. I assume all the non-implemented 
features are expected to stay in for draft standard, and that they are 
somehow considered "not main". Section 5 explicitly states why the authors 
believe the lack of IPSec implementations is not a problem, but does 
not explicitly address the other "not-main" features.

I think that, in order to progress to draft, this report needs to describe 
why the authors believe the other missing features need to stay in the 
draft standard, and also why their current absence is not likely to 
harm interoperability in the future. Otherwise, it seems like it would 
make sense to wait until the features have been implemented and 
tested prior to progressing to draft.

Minor issues:

-- Why does an implementation report need an RFC 2119 reference? It does not 
seem appropriate for such a report to make normative statements.

-- section 2.3:

This paragraph appears to make normative statements. I suspect it is merely 
repeating normative requirements stated in the referenced document. If so, 
that would be better stated descriptively, to avoid confusion. (See 
previous comment about 2119 language)

-- section 5, third paragraph:

I don't understand forces well enough to know if the lack of IPSec 
implementations is an issue or not. Does forces say anything about how to 
use IPSec beyond just requiring it? Is there any way of getting that wrong 
in a way that breaks interoperability?

-- section 9, 2nd paragraph:

Am I correct in assuming that when you say no security features were 
implemented, you are only talking about the missing IPSec feature as 
mentioned in section 5? If so, it might be worth restating that here, 
as "no security features were implemented" sounds rather alarming otherwise.

Nits/editorial comments:

-- section 1.2, first sentence"

Please expand on first use in body of the draft, even though you already did 
so in the abstract.

-- section 1.2, 2nd to last paragraph: "This document defines the 
specifications for this ForCES protocol."

I'm not sure I understand what you mean by "define the specifications"

-- section 2, 2nd paragraph:

What is the antecedent for "It"?