Jamal,
I have no problems with the fixes you suggest. I look
forward to taking another look at each and every one of the
120+ pages.
:-)
--
Eric Gray
Principal Engineer
Ericsson
> -----Original Message-----
> From: Jamal Hadi Salim [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 09, 2008 1:38 PM
> To: Eric Gray
> Cc: Avri Doria; Hormuzd M Khosravi; Robert Haas; Weiming
> Wang; [email protected]; Ross Callon
> Subject: Re: Gen-ART Last Call Review of draft-ietf-forces-protocol-15
> Importance: High
>
> 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
