Subject: Re: [CCAMP] Gen-ART review of draft-ietf-ccamp-confirm-data-channel-status-08.txt

From: Dan Li <[email-masked]>
Date: Mon, 14 Dec 2009 10:44:43 +0800

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-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
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-masked]>
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