Document: draft-ietf-mpls-tp-gach-gal-05.txt Reviewer: Miguel Garcia Review Date: 20-May-2005 (2nd review post IETF-LC) IETF LC Date: 14-May-2005 IESG Telechat date: Summary: The document is ready for publication as a standards track RFC. I reviewed version -04 of this document, and I had a number of minor comments. Most of them have been solved, but still I need to comment on a few remaining minor issues. Minor issues: - Rule of 5 authors. The draft lists 6 authors, of which 2 of them are listed as Editors. While this is not an impediment for its publication, certainly it brakes the RFC Editor's rule of 5 authors. - In version 4 I had this comment: On Section 3.1, first paragraph, the text reads: The structure of ACH TLVs that MAY follow an ACH TLV Header is defined and described in the following sections. I am not sure what the text wants to say, because it mean want to say either: a) The structure of ACH TLVs MAY follow an ACH TLV Header ... b) The structure of ACH TLVs that can follow an ACH TLV Header .. If the intention is a), then this text should be written in Section 3.3, which is the section that describes the ACH TLV object. If the intention is b), then it is correctly placed, but please do use "can" instead of "MAY". The authors clarified that the intention was to express "a". Now in version 5, the text has been moved to Section 3.3, which is the correct Section. However, I still have a problem with the wording "that MAY", because I think it will cause confussion. The text is a restrictive relative clause. I don't understand how normative text MAY can be included in a restrictive relative clause, whose purpose is to restrict the set of ACH TLVs to only those who follow the ACH TLV header. I will argue that, as written, is unimplementable. So, I suspect that you are trying to say the following (please review carefully): "ACH TLVs MAY follow an ACH TLV header. The structure of ACH TLVs that follow an ACH TLV Header is defined and described in this section." In the above paragraph, the first sentence express the optionality of ACH TLVs to follow or not an ACH TLV header. The second sentence says that the rest of the section is devoted only to the subset of those ACH TLVs that follow an ACH TLV header. Nothing is said about ACH TLVs that do not follow an ACH TLV header. - New issue: there is a note at the end of Section 4.2.1.1. Unfortunately, the note contains a normative statement (MUST). Normative statements are incompatible with the definition of a note, which merely adds some additional explanation to the text. I would suggest move the sentence of the note that contains the normative statement outside the note, in which case there might be a need for some introductory text. - Typo in Section 4.2.1.2: s/MPLSsection/MPLS section =================================================== Document: draft-ietf-mpls-tp-gach-gal-04.txt Reviewer: Miguel Garcia Review Date: 12-May-2005 IETF LC End Date: 14-May-2005 IESG Telechat date: (if known) Summary: The document is technically ready for publication as a standards track RFC, but there is such a number of minor issues that a new revision is recommended. Major issues: Minor issues: - Rule of 5. The document lists 6 authors, but the RFC Editor has a guideline for not exceeding the number of 5 authors. Please read Section 2.12 of http://www.rfc-editor.org/rfc-editor/instructions2authors.txt - You have an unnumbered section called Requirements Language (in between the Abstract and the Table of Contents). I think this does not follow the guidelines of the RFC Editor. See the previously mentioned document, now in Section 4, where you can see that the Abstract is followed by the Table of Contents, not by "Requirements Language". Usually the paragraph that refers to RFC 2119 is placed within the "Terminology" section. - Same comment for Section 1.1, Contributing authors, which according to the structure, it should instead go to the end of the document, before the Security Considerations. - And same comment for Acknowledgments, which should go in between Contributors and Security Considerations. - On Sections 1 and 4.1 the IP address 127/8 should be written as 127.0.0.0/8. - On Section 3.1, first paragraph, the text reads: The structure of ACH TLVs that MAY follow an ACH TLV Header is defined and described in the following sections. I am not sure what the text wants to say, because it mean want to say either: a) The structure of ACH TLVs MAY follow an ACH TLV Header ... b) The structure of ACH TLVs that can follow an ACH TLV Header .. If the intention is a), then this text should be written in Section 3.3, which is the section that describes the ACH TLV object. If the intention is b), then it is correctly placed, but please do use "can" instead of "MAY". - On Section 4, 1st paragraph, last sentence: "this document suggests the value 13", I think this should only be a note in the IANA Section, so it should be deleted from here. - On Section 4.2.1.1, last paragraph starts: "The G-ACh message, the ACH or the GAL SHOULD NOT be modified towards the targeted destination". My recommendation is to make the sentence in active voice, there, it is easier to see which node has the requirement. So, I suggest something around these lines: "LSRs (or whatever node) SHOULD NOT modify...." And this brings me to another comment... I don't have a clear explanation for exceptions to the "SHOULD NOT". Therefore, I believe it should be a "MUST NOT". This comment also applies to the last paragraph of Section 4.2.1.2. - On Section 4.2.1.2, the last paragraph on page 13 starts with: "To send a G-ACh message on a control channel..." That is a horrible long and complicated sentence, which has normative text. So, please, split the long one into smaller parts, isolating the normative aspects from the introduction and motivation, so that it can be clearly understood which entity MAY do what. - On the last paragraph of Section 5, replace the "it" in "it MAY increment" with the real actor, presumably "An LER, LSR, or PE". - Section 8. The suggestion to IANA should be a note that with time, gets deleted by the RFC Editor before publication of the RFC. - I noticed that IANA has reviewed the document and has some questions and comments, so I guess the authors will address them as well.