Re: [Gen-art] Gen-ART Telechat Review of draft-ietf-forces-implementation-report-02
Ben Campbell <ben@estacado.net> Thu, 12 August 2010 01:29 UTC
Return-Path: <ben@estacado.net>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC7C3A6990; Wed, 11 Aug 2010 18:29:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fP0PRbEHHWKk; Wed, 11 Aug 2010 18:29:09 -0700 (PDT)
Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 7F6393A67DB; Wed, 11 Aug 2010 18:29:08 -0700 (PDT)
Received: from [10.0.1.6] (adsl-68-94-27-240.dsl.rcsntx.swbell.net [68.94.27.240]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o7C1TXwD077661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Aug 2010 20:29:39 -0500 (CDT) (envelope-from ben@estacado.net)
References: <6621BABD-E2F7-4164-8A3E-4FED6FCD30D5@estacado.net> <4C63492F.9020902@joelhalpern.com>
Message-Id: <B9D7B102-FACF-401A-AFBD-2DD535CC87E0@estacado.net>
From: Ben Campbell <ben@estacado.net>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
In-Reply-To: <4C63492F.9020902@joelhalpern.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Mailer: iPad Mail (7B405)
Mime-Version: 1.0 (iPad Mail 7B405)
Subject: Re: [Gen-art] Gen-ART Telechat Review of draft-ietf-forces-implementation-report-02
Date: Wed, 11 Aug 2010 20:29:26 -0500
Cc: "draft-ietf-forces-implementation-report.all@tools.ietf.org" <draft-ietf-forces-implementation-report.all@tools.ietf.org>, General Area Review Team <gen-art@ietf.org>, IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Aug 2010 01:29:10 -0000
Thanks, Joel. That addresses all of my concerns. On Aug 11, 2010, at 8:06 PM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote: > With regard to the major issue, in response to other comments, the offending sentence (which is, as Ben observes, wrong, has been removed. More precisely, there is now a note to the RFC Editor to remvoe the sentence. If we need to revise the document for other reasons, we will remove it ourselves. The document is being publsiehd as informational, and the underlying documents were just published as PS. We are NOT trying to move them to Draft Standard. We need to actually build stuff with it first. (But yes, the sentence claims that we meet the requirements for DS, and we don't.) > > The normative statement in 2.3 is as you guessed, a repetition for context from other places. The capitalization is because that is how it appears there. I believe that is also why we have the 2119 language reference. I am inclined to leave that to the RFC Editor Production house to decide what the right way to handle it is. > > If we were trying to be ready for Draft Standard, the IPSec omission would be a singificant obstacle. At this stage it is merely information for anyone who is trying to build implementations. I would really like to see an IPSec implementation, as per the RFC. > And yes, this omission is what the section 9 comment is about. > > The 1.2 odd text about "This document" is a copy and paste issue. We should have copied one fewer lines. (the document author was trying to copy the complete definition. I will add this to the RFC Editor comments. I will leave other grammatical and acronym expansion issues to them, unless we need to revise the document for some substantive changes. > > Yours, > Joel > > > Ben Campbell wrote: >> 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"? >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art