Miguel, Thanks for the detailed comments and especially recommending changes.
I agree with all your recommendations and will implement these shortly. Regards, Mark Watson On 9/21/09 1:04 AM, "Miguel A. Garcia" <[email protected]> wrote: 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-rmt-pi-alc-revised-08.txt Reviewer: Miguel Garcia <[email protected]> Review Date: 2009-09-21 IETF LC End Date: 2009-09-22 Summary: The document is almost ready for publication as a standards track RFC. There are a few minor issues and nits that should be polished before publication. Major issues: none Minor issues: - According to idnits, the document makes a downref normative reference to RFC 3738, which is an experimental RFC. According to RFC 3967, I believe this downref is needed and appropriate. According to the process described in RFC 4897 Section 4, a caution annotation should be added to this I-D: o A note is included in the reference text that indicates that the reference is to a target document of a lower maturity level, that some caution should be used since it may be less stable than the document from which it is being referenced, and, optionally, explaining why the downward reference is appropriate. So, the action goes to the authors to add a note indicating that RFC 3738 is an experimental RFC and some caution should be used since it may be less stable than this document. This note should go right after the first paragraph in Section 2.2, when RFC 3738 is mentioned first. - The text, towards the end of Section 1.3, reads: To ameliorate these concerns, it is RECOMMENDED that the RP be as close to the sender as possible. I think this text does not make sense with RFC 2119 wording. This is a deployment recommendation, for which the protocol designer has no action to improve or control. There is nothing that can be tested in an interoperability test. So, I think there is no point in having RFC 2119 strength in this sentence (I am assuming that the target reader is the protocol implementor, not the deployment manager). I think the text should change to illustrate that this is a recommendation for a different audience, and should not use RFC 2119 wording. - Section 2.4 says: The Session Description that a receiver is REQUIRED to obtain before joining an ALC session MUST contain the following information: First, I have a problem with the "REQUIRED". This normative text is written in a dependent clause, so, it is kind of hiding behind the main sentence. Second, I am not sure if there is a justification for the REQUIRED and MUST in this sentence. I understand these terms, according to RFC 2119, as an imperative for the protocol to work. However, in your I-D, the text is describing a need more than a requirement for the protocol implementor. I would understand that an implementation MUST send some data, or MUST parse some data upon reception, but the "MUST aquire" sound a bit strange, because it does not put a requirement on the protocol implementation. Also, notice that the document leaves the session description aspects outside the scope of the I-d (to reinforce my sentiment). So, my recommendation is that this first sentence merely says: Before a receiver can join an ALC session, the receiver needs to obtain a session description that contains the following information: - Section 4.3, second paragraph. The text reads: A sender using ALC MUST make available the required Session Description as described in Section 2.4. I think this text is unimplementable and un-testable (at least the "MUST), especially considering that Section 2.4 says that session description aspects are outside the scope of the document. I think the MUST should be replaced by a "should" (yes, in lowercase). - Similarly, in Section 4.4, second paragraph, the text reads: To be able to participate in a session, a receiver MUST obtain the REQUIRED Session Description as listed in Section 2.4. How receivers obtain a Session Description is outside the scope of this document. As discussed later, the "MUST" should be replaced by a "needs", and the "REQUIRED" should be replaced by a "required". - Similary, in Section 4.4, third paragraph, the text reads: As described in Section 2.3, a receiver MUST obtain the required FEC Object Transmission Information for each object for which the receiver receives and processes packets. I think the "MUST" should be replaced by a "needs". Nits/editorial comments: - Expand acronyms at first occurrence. This includes: "SSM", "MSDP". - The Introduction section should be descriptive and not normative in nature. So, I would not expect to find any normative strength words (RFC 2119) anywhere in Section 1. However, at the end of Section 1.3, there is a "RECOMMENDED". If the text persists (see my previous comment in which I recommend to use a non-RFC 2119 wording), perhaps should be moved outside Section 1. - Section 1.3, second paragraph, 8th line: s/may also uses/may also use - An informative reference to MSDP protocol would be nice (Section 1.3). - Section 2, 4th paragraph. A figure that illustrates the wording would be nice. - Section 4.1, 1st paragraph. The text reads: The Congestion Control Information field in the LCT header contains the REQUIRED Congestion Control Information that is described in the multiple rate congestion control building block used. I think the term "REQUIRED" is merely and adjective and, consequently, not subject to RFC 2119 wording. I think it should be written in lower case. - Section 5.1.2.2, s/protocol implementation ./protocol implementation. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
