I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please 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-ccamp-confirm-data-channel-status-08.txt
Reviewer: Miguel Garcia <[email protected]>
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
^^^^^^
/Miguel
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
