Thanks, Joel. That addresses all of my concerns. On Aug 11, 2010, at 8:06 PM, "Joel M. Halpern" <j...@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-...@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
