Document: draft-ietf-ccamp-confirm-data-channel-status-08.txt
Reviewer: Miguel Garcia <miguel.a.garcia@ericsson.com>
Review Date: 2009-12-10
IETF LC End Date: 2009-12-16
IESG Telechat date: 2009-12-17

Summary: The document is ready for publication as a standards track RFC.


Nits/editorial comments:

In general, I have found problems with the English language. Perhaps you 
should get some English native speaker to give a pass to the draft to 
increase the readability. Now, let me give you some small details that 
you may want to fix:

- The second paragraph of Section 4.1 acknowledges the existence of three 
types of Confirm Data Channel Status messages without naming them, 
but instead, referring to Section 7.1. In the sake of clarity of the 
content that goes in sections 4.1.1, 4.1.2, and 4.1.3, I would suggest 
to add the names of the messages to that paragraph, for example:

   Three new messages are defined to check data channel status: 
ConfirmDataChannelStatus, ConfirmDataChannelStatusAck, 
ConfirmDataChannelStatusNack, which are described in detail in the 
following sections. Message Type numbers are found in Section 7.1.

- In the last paragraph of Section 4.1, I found the text a bit 
misleading. This paragraph is describing the generalities that are 
applicable to all three types of ConfirmDataChannelStatus messages. 
However, the last paragraph reads:

   If the message is a Confirm Data Channel Status message...

Obviously this test only applies to one of the types of messages, so 
I would consider more appropriate to move this paragraph to 
Section 4.1.1, which describes the Confirm Data Channel Status message.

- Section 4.3, at the end of the second paragraph, the text discusses 
the Data Channel Status subobject, and the text reads:

   The new subobject MUST be part of Data_Link Class.

I thought this text belongs to Section 4.2, which discusses in detail the 
Data Channel Status Subobject.

- Section 5, first paragraph. The text is unparsable. It would be easier 
to read if it were written in active form and in separated sentences, 
for example:

   Adjacent nodes MAY send data channel status confirmation related 
LMP messages. Periodical timers or some other events requesting 
the confirmation of channel status for the data link may trigger 
these messages.

- Section 5, each of the bullet points: I would suggest to give a bit 
more of context to the text, by indicating when the action begins. 
For example, take the second bullet point; You can start it by saying:

  # Upon reception of a ConfirmDataChannelStatus message, the RECEIVER MUST 
extract the data channel status from the message and SHOULD compare....

- Expand acronyms at first occurrence, e.g., LSR.

- Nit in the first paragraph of Section 4.4.

s/This document's defined mechanisms/These document's defined mechanisms
                                     ^^^^^
s/To use this mechanisms/To use these mechanisms

- Section 5, typo

s/It's a local police decision/It's a local policy decision
                                            ^^^^^^