I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
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"?
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf