Subject: Re: [issue63] Editorial nits from LC review

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 20 Jan 2006 14:38:48 +0800

I have (quite carefully) double checked the update Avri made on 06 on this
issue. I think Avri has done good job on it. Only some left nits as I list below
that need to be worked further in next 07 version.

* Page 12,  /...  reference points Fc and Fe, is ... /  here the Fe should be
Fl, I think.

* Merge the #7 and #8 of the TML requirements Section (Section 5).

* 6.2.2. Scope of the T in TLV,  The sentence that starts with "This means that
wherever" is confusing,  can it be reworded?
  I suggest to change the sentence to "This means that  wherever TLVs are in the
PDU, the same Type value refers to the same Type of TLV. "

* 7.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.
  Jamal, Please provide your thought ASAP.

* 7.1.1.1.8. Data TLV,  Padding is mentioned. What is the padding, 0s or some
other value?
   I suggest to add to the  sentence "If need be they MUST be  padded to achieve
the alignment." with the  setence "Padding used for the alignment must be zero
on transmission and must  be ignored upon reception.". The same setence also
applies to Page 32(Section 6.2) as I indicated in another emal.

After above is done in 07, this issue can be closed.

Thanks David.

Weiming

----- Original Message -----
From: "David Putzolu" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, November 15, 2005 12:23 AM
Subject: [issue63] Editorial nits from LC review

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>
___________________________________________________

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 20 Jan 2006 14:42:23 +0800

Sorry a typo as:
Ff, I think.

Weiming

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 25 Jan 2006 14:06:33 +0800

Most of the comments given by T. Sridhar have been accepted and the text has
been updated by Avri.

This issue can be closed.

Thank T. Sridhar.

Weiming