I have been selected as the General Area Review Team (Gen-ART) Last Call reviewer for this draft (for background on Gen-ART, see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-forces-protocol-15.txt Reviewer: Eric Gray Review Date: 8 September 2008 IETF LC End Date: 8 September 2008 IESG Telechat date: (if known) Summary: This draft is not ready to be published as a Proposed Standard RFC. The draft is generally very well written, but there are some areas in which it is confusing. Comments/Questions: ================== The latter half of the abstract is confusing and ambiguous. After stating that this draft addresses requirements defined in RFC 3654, it says "the specification also ..." - from the context, it seems that this should say "this specification also ...", to clarify that you're not still talking about RFC 3654. Further, there is still more awkwardness toward the end - where it appears that the document defines some requirements of the protocol. What does that mean - i.e. - is this a protocol specification, requirements specification or both? ____________________________________________________________________ The 4th paragraph in section 2 claims that the specification does not define transport mechanisms; presumably we should say something about transport. For example: is it assumed to be reliable, or is it left open as to whether or not the protocol will need to include a means to ensure delivery occurs? However, it appears that the sentence is simply misleading, given that what it claims the specification does not do is very similar to what the TML, described starting in section 4, actually does do. While this document does not explicitly define TML details, it has quite a lot to say about what a TML needs to do (which is - I guess - what the abstract is getting at when talking about how this specification also specifies requirements). This entire (4th) paragraph would be less confusing if a brief statement to the same effect were included in the 2nd paragraph after it (discussing section 4) and this paragraph was removed. Alternatively, this paragraph could be moved relatively intact to live between the 2nd and 3rd paragraph after where it is now. You may want to replace "transport mechanism for protocol messages" with "mechanisms of the TML" - as this paragraph then becomes the "glue" between the descriptions of section 4 and section 5. ____________________________________________________________________ Section 4.2 (1st paragraph) talks about 2 phases: pre-association and association. This is in comparison with other places where they are identified as pre-association and post-association. Please clarify. ____________________________________________________________________ The last paragraph on page 16 and the first 2 paragraphs on page 17 talk about states (OperEnable, OperDisable, AdminEnable) that are not shown in figure 4 (FE state machine). Either Figure 4 is not really the state machine (likely, since it shows phases, not states), or the "states" described in subsequent paragraphs are actually only inputs to the state machine. This needs to be tightened up. If the figure represent phases, it should be so labeled, and the box on the right should be re- named "post association phase." If the figure is - in fact - a state machine, the other "states" need to be disambiguated. ____________________________________________________________________ There is a considerable amount of opacity (lack of clarity) in the status of pre-association as in or out of scope. First, the 1st paragraph at the top of page 13 says that FEM and CEM are touched on (although out of scope) because they are "integral" to the pre- association phase. That makes sense, because pre-association is a ForCES protocol phase. Also, quite a lot of the document appears to address various aspects of the pre-assocation phase. Then, to my complete surprise, I read this statement after figure 6: "Because the pre-association phase is out of scope, these details are not discussed any further in this specification." After that, I am at a loss as to how to proceed. Which is it, in scope, or out of scope? I think what is meant is that the specific interactions of CEM and FEM that are part of the pre-association phase are out of scope, but this is really, really, not clear. ____________________________________________________________________ It seems a bit strange to have the IANA Considerations in an appendix. Has this been okay'd by the ADs? I ask only because I can think of no reason why it should not be a part of the main standard document, especially since it is likely to be viewed as normative text and may be missed in an appendix. NITs: ==== In section 1.2, is it really necessary to have "table Table 1" and "table Table 2" (speaking of indicating "multiplicity")? ____________________________________________________________________ In the 3rd paragraph of section 2, "Block(LFB)" needs a space. ____________________________________________________________________ Last paragraph on page 12, there are 3 Fp reference points - emphasis on the plural. ____________________________________________________________________ 1st paragraph under figure 4, I can't parse the sentence: "An unassociated FE MAY continue sending packets when it is capable high availability." I think you mean: "An unassociated FE MAY continue sending packets when it has a high availability capability." ____________________________________________________________________ _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
