Re: [Gen-art] Gen-ART Telechat Review of draft-ietf-forces-implementatio

Thanks, Joel. That addresses all of my concerns.

On Aug 11, 2010, at 8:06 PM, "Joel M. Halpern" <jmh(_at_)joelhalpern(_dot_)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(_at_)ietf(_dot_)org
> > https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf