Eric, Thanks again for the review. Please refer to below for response. On Mon, 2008-08-09 at 16:07 -0500, Eric Gray wrote:
> 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? Yes, the text is a little confusing. How does this sound for the last sentence: "Besides the ForCES protocol, this specification also defines the requirements for theTransport Mapping Layer (TML)." > ____________________________________________________________________ > > 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? The TML layer takes care of that. So the section on the TML worries about transport desires. > 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). Indeed. Fixing the abstract should remove this confusion. > 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. How about we just totaly remove the offending paragraph - doing that doesnt take away from the intended message (given a fix in the abstract). > > 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. Thanks for catching that it should read "post-association" > ____________________________________________________________________ > 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. We should relabel figure 4 appropriately to be phases not states. > ____________________________________________________________________ > > 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? It is in scope but not the interaction prior to that; We are going to fix the text as per your suggestion below. > 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. > It is not uncommon to have IANA considerations in an appendix. If you think it would be of significance, then we will make the change and move it out of the appendix. > > NITs: > ==== > > In section 1.2, is it really necessary to have "table Table 1" and > "table Table 2" (speaking of indicating "multiplicity")? Good point. Will fix. > ____________________________________________________________________ > > In the 3rd paragraph of section 2, "Block(LFB)" needs a space. Will fix. > ____________________________________________________________________ > > Last paragraph on page 12, there are 3 Fp reference points - > emphasis on the plural. Will fix. > ____________________________________________________________________ > > 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." Will fix. Again, much thanks. cheers, jamal _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
