Subject: [issue63] Editorial nits from LC review

From: David Putzolu <[email-masked]>
Date: Mon, 14 Nov 2005 16:23:55 +0000

New submission from David Putzolu <[email-masked]>:

Abstract:
* s/ForCES protocol is a message exchange protocol that is used
for/ForCES protocol is used for/

1. Introduction:
* s/aims to define an architectural framework/defines an architecture
framework/
* s/the term "ForCES protocol" refers only/"ForCES protocol" and
"protocol"
  as used in this document refers/
* s/The ForCES protocol is defined to have a common header/The ForCES
  Protocol defines a common header

2. Definitions
* s/(see below) to determine which FE to use./(see below) to determine 
  which FE(s) to use.
* LFB Metadata - same comment, functionally but not implementation
  accurate.
* The definition of ForCES Protocol Transport Mapping Layer has the
  phrase "how to achieve and implement reliability, multicast, ordering,
  etc."  Need to be very careful here as it is not in the ForCES 
  charter to create a new transport protocol.  Consider language such
  as "how to fulfill ForCES transport requirements using the
capabilities
  of the identified underlying transport protocols and mediums"
(although
  this language is ugly, hopefully someone can come up with something
  better).

3.1 Protocol Framework
* "The protocol element configuration is out of scope of the ForCE
protocol" - Do you mean CEM and FEM configuration here? Not clear.

3.1.2 The TML Layer
* s/layer is essentially responsible for transport of/layer transports/

3.3.1.1.3. Transactional protocol
* There is an editorial note here that needs to be addressed. This feels
  borderline technical

3.3.1.1.5 continue-execute-on-failure
* The first sentence appears to be a fragment. Same comment applies to
  3.3.1.1.6.

3.3.1.1.6 execute-until-failure
* There is an editorial note here that borders on technical.

3.3.3 FE Object and FE protocol LFBs
* "speacilized"

3.3.4 Scaling by Concurrency
* The section title is confusing. How about just "Scalability"?
* s/mythical/hypothetical/

4. TML Requirements
* Shouldn't #3 also include preventing the link(s) to the CE being
  overwhelmed by traffic from FEs?
* Is #8 really a separate requirement from #7?
* s/priotity/priority/

5. Message encapsulation
* While it is probably safely assumed, I would like to see it explicitly
  called out that all fields are in network byte order.

5.1 Common Header
* s/donot/do not/
* s/Fe/FE/
* s/inidcate/indicate/

5.2. Type Length Value(TLV) Structuring
* Is the length in units of octets or in 32-bit words?

5.2.2. Scope of the T in TLV
* The sentence that starts with "This means that wherever" is confusing,
  can it be reworded?

6.1.1. Protocol BNF
* Reference is made to *0, but *0 appears to be illegal in this grammar?
* Isn't + more frequently used than 1* to indicate 1 or more
repetitions?
  I am not a BNF expert however.

6.1.1.1. Discussion on Grammar
* s/optionaly/optionally/

6.1.1.1.6. Operation TLV
* s/deleteing/deleting/

6.1.1.1.7. Result TLV
* Permission denied has no context. When might it be returned and why?

6.1.1.1.8. Data TLV
* Padding is mentioned. What is the padding, 0s or some other value?

6.2.1. FE Protocol LFB
* For clarity fully define the value. I.e. 0x0001
* The writable FE protocol attribute of ForCES protocol should call 
  out that the only legal values are those that are returned in the
  ForCES protocol version capability.
* s/associatin/association/

6.5.2. Config Response Message
* s/TThe/The/

8. High Availability Support
* Should the bottom All Msgs arrow in figure 33 have bidirectional
arrows?
  Same comment for figure 34.

Appendix C. ForCES Protocol LFB schema
* Has this been run through an XML validation tool?

Appendix F. changes between -03, -04, and -05
* Should there be RFC editor instructions to remove this section
  Upon publication?
* Same comment applies to Appendix G, H, I

Author's addresses appears twice

----------
category: Editorial
draft: draft-ietf-forces-protocol
messages: 362
nosy: dputzolu
priority: May fix
status: Text proposed
title: Editorial nits from LC review

___________________________________________________
Forces issue tracker <[email-masked]>
<http://www.mip4.org/issues/tracker/forces/issue63>
___________________________________________________