Subject: [Gen-art] Gen-ART Last Call Review of draft-ietf-forces-protocol-15

From: "Eric Gray" <[email-masked]>
Date: Mon, 8 Sep 2008 16:07:52 -0500

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-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 08 Sep 2008 21:36:09 -0400

Hi Eric,

Your work is much appreciated. We will review your comments
and get back to you.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 09 Sep 2008 13:38:14 -0400

Eric,
Thanks again for the review.
Please refer to below for response.

> Comments/Questions:

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 TML layer takes care of that. So the section on the TML worries
about transport desires.

> how this specification also specifies requirements).

Indeed. Fixing the abstract should remove this confusion.

> "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).

> as pre-association and post-association.  Please clarify.

Thanks for catching that it should read "post-association"

We should relabel figure 4 appropriately to be phases not states.

It is in scope but not the interaction prior to that; We are going to
fix the text as per your suggestion below.

> scope, but this is really, really, not clear.

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.

> "table Table 2" (speaking of indicating "multiplicity")?

Good point. Will fix.

Will fix.

Will fix.

Will fix.

Again, much thanks.

cheers,
jamal

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 10 Sep 2008 14:53:31 -0500

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-masked]] 
> Sent: Tuesday, September 09, 2008 1:38 PM
> To: Eric Gray
> Cc: Avri Doria; Hormuzd M Khosravi; Robert Haas; Weiming 
> Wang; [email-masked]; Ross Callon
> Subject: Re: Gen-ART Last Call Review of draft-ietf-forces-protocol-15
> Importance: High
> 
> Eric,

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 10 Sep 2008 16:54:27 -0400

Thanks Eric,

We are in the process of making the proposed/agreed changes.

There are a few other changes based on feedback provided to us by Elwyn
while he was reviewing the model document;
[the major (document-affecting aka diff-noticeable) one was to provide
consistency in naming of TLVs - in some cases they were referred to as
"mumble TLV" and in others as "mumble-TLV". For consistency they are now
in the format mumble-TLV].

Would you prefer we publish a new version or would you like to see
an interim version first?

cheers,
jamal

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 10 Sep 2008 15:59:15 -0500

Up to you.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Wednesday, September 10, 2008 4:54 PM
> To: Eric Gray
> Subject: RE: Gen-ART Last Call Review of draft-ietf-forces-protocol-15
> Importance: High
> 
> Thanks Eric,
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 16 Sep 2008 09:34:52 -0400

Eric,

We made a new release:
http://www.ietf.org/internet-drafts/draft-ietf-forces-protocol-16.txt

cheers,
jamal