Subject: [issue64] Forces Protocol Comments

From: "T. Sridhar" <[email-masked]>
Date: Mon, 14 Nov 2005 20:10:59 +0000

New submission from T. Sridhar <[email-masked]>:

Forces Protocol Draft Comments-14Nov05

1.	3.1.1. 
a.	Suggest “More details are in Section 6” as replacement for last 
sentence.
2.	3.1.2
a.	Suggest rewriting of sentence beginning with “The different TMLs could 
implement…” One suggested option “The TMLs could vary in their implementation 
based on capabilities….”. 
3.	3.1.3 – 
a.	Move period one space to the left after “…(implementation)” 
b.	Suggest removal of “lot” in sentence beginning with “RFC 3746…”
c.	Suggest changing of bullet item b to “Issuing of the ID for FE or CE”
d.	Suggest adding a colon at the end of “Example” in the last paragraph. 
4.	3.1.4 – 
a.	“looses” should be substituted by “loses”
b.	Suggest rephrasing of sentence beginning with “It should be noted that 
what needs to be done…”
5.	3.2.1
a.	In the last paragraph, it not clear what  “…appropriate CEM component” 
means in this context, since the scenario does not indicate that. 
6.	3.2.2.1
a.	Last sentence – is the FE moved to this state or is this a protocol 
state?  Is there a related protocol state machine which should be 
available/referenced in this document?
7.	3.2.2.2
a.	Last sentence  - suggest inserting of parentheses before and 
after “Section 7”
8.	3.2.2.3
a.	First paragraph – suggest “operational” instead of “operation
b.	Paragraph beginning with “For this…” – suggest “version” instead 
of “revision”. Suggest rephrasing of the sentence towards the end “it has as 
invalid and retrieve new state..” – not clear what “retrieve new state” 
implies. 
9.	3.3.1.1.2
a.	Spelling of “disallowed” – should be corrected from the 
current “dissallowed”
10.	3.3.3 
a.	Typo in spelling of “specialized”
11.	5.1
a.	Suggest that the explanation of the flag values be rephrased to “ to 
indicate that the message receiver is ….” Instead of “to indicate message 
receiver..”
b.	The last bullet on Page 27 “Any kind of response messages never expect 
further responses” – suggest these be rephrased.
12.	6.1.1.7
a.	First sentence – “probably 4 bytes but we only need 1 byte) – needs 
rephrasing and/or explanation.
13.	6.2.1 – FE Protocol LFBs
a.	Page 44 – heartbeat policy value “1 – The CE will not generate any HB 
messages..” – the second sentence seems to imply that the FE is not to 
generate HBs also to check for CE liveness. Is that the implication? 
14.	6.4.1 
a.	Page 47 – “Message Body” – substitute “consist” with “consists”
15.	8
a.	First paragraph – suggest “FE and CE” instead of “FE, CE”  and “FEM 
and CEM” instead of “FEM, CEM”.
16.	8.1
a.	3rd line – change “peer HA managements” to “peer HA management”
17.	9
a.	First bullet should state “Security mechanisms” instead of “Security 
mechanism”
b.	Same sentence – suggest “session controlled – that is, once…”

18.	Authors’ addresses section is repeated at the end of Appendix I.

----------
category: Editorial
draft: draft-ietf-forces-protocol
messages: 363
nosy: tsridhar
priority: May fix
status: Text proposed
title: Forces Protocol Comments

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

---

From: "Wang,Weiming" <[email-masked]>
Date: Sat, 19 Nov 2005 16:35:53 +0800

Hi Mr. T. Sridhar,

Thanks so much for the review. Pls just allow me give some reply to some of the
technical points here while leaving the editorial ones for Avri and some others
for Jamal :)

Thanks,
Weiming

----- Original Message -----
From: "T. Sridhar" <[email-masked]>

5. 3.2.1
a. In the last paragraph, it not clear what  ¡°¡appropriate CEM component¡±
means in this context, since the scenario does not indicate that.
[Weiming] Maybe just say " CEM component" here is of less side effect.

13. 6.2.1 ¨C FE Protocol LFBs
a. Page 44 ¨C heartbeat policy value ¡°1 ¨C The CE will not generate any HB
messages..¡± ¨C the second sentence seems to imply that the FE is not to
generate HBs also to check for CE liveness. Is that the implication?
[Weiming] Let me quote the full sentense first as:
             1 - The CE will not generate any HB messages.  This actually
            means CE does not want the FE to check the CE liveness.
There is only an imply that CE does not want the FE to check for its liveness.
There is no imply whether FE should generate HBs or not. It should be decided by
the followed "FE heartbeat policy".  This actually means in this case CE may
still be interested in FE liveness.

18. Authors¡¯ addresses section is repeated at the end of Appendix I.
[Weiming] It is the side effect of XML2RFC which automatically generate one
author list based on the first editor page, while we need another full one. We
may leave it there currently before submitting to IESG, till then we can
manually modify it.