Hi all, We appreciate Miguel's careful review for this draft! Thanks Miguel!
We have updated this draft according to the comments we have received during the IESG LC. The lastest version of this draft has been posted. http://www.ietf.org/id/draft-ietf-ccamp-confirm-data-channel-status-09.txt Please see below for detailed changes. Thanks, Co-authors ----- Original Message ----- From: Miguel A. Garcia To: [email protected] ; [email protected] ; [email protected] ; [email protected] ; [email protected] ; [email protected] ; [email protected] ; [email protected] Cc: General Area Review Team Sent: Thursday, December 10, 2009 6:33 PM Subject: Gen-ART review of draft-ietf-ccamp-confirm-data-channel-status-08.txt 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. Accepted. The proposed text is adopted. - 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. The last paragraph is moved to the end of Section 4.1.1. - 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. In Section 4.3, the focus is the Data_Link Class. The last sentence of the second pragraph is trying to tell the reader that how the Data_Link Class is constructed. So we want to keep this sentence as is. - 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. Accepted. The proposed text is adopted. - 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.... Accepted. each of the bullet points is changed to: - Initially, the SENDER constructs.... - Upon reception of a ConfirmDataChannelStatus message, the RECEIVER MUST extract... - If the RECEIVER is... - Upon reception of a ConfirmDataChannelStatusAck message, the SENDER MUST compare... - Expand acronyms at first occurrence, e.g., LSR. Accepted. The following acronyms are expanded at their first occurrence: LSR, LSP, RSVP-TE. - 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 ^^^^^^ Replaced by the following text: The mechanism defined in this document presumes a certain non-standard behavior of existing/non-document supporting nodes. To use this mechanism all nodes MUST have the extensions described in this document for compatibility. - Section 5, typo s/It's a local police decision/It's a local policy decision ^^^^^^ Accepted. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
