Resending due to wrong alias in my first email =============> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pwe3-fat-pw-06 Reviewer: Mary Barnes Review Date: 18 May 2011 IETF LC End Date: 20 May 2011 Summary: Almost ready Minor issues/suggestions: - Section 1.2 - While the 3rd paragraph notes that the TTL is described in the security section I think a bit more text might be helpful as I could not understand why the fact that the TTL in the flow LSE is never used to determine whether a packet should be discarded, introduces restrictions on the TTL value. Certainly, the relevant text is in the security section, however, it's very little text and I personally think a backward reference in the security section to an earlier section in the document is often more helpful than a forward reference. Also, it's not clear to me what that issue has to do with security - what is the security issue that is addressed by this choice of TTL? - Section 7, 3rd paragraph: What are the circumstances referenced in the 1st sentence? I assume it's referring to the method of load balancing described in this document rather than the situation described in the previous paragraph or perhaps it's both It might be more clear to include the 2nd- paragraphs as bullets so it's clear they are relating to the method of load balancing in this document and are not related. - Section 8.3, 1st paragraph, last sentence: This sentence does not make sense: An example of such a case is the of the flow label mechanism in networks using a link bundle with the all ones component [RFC4201]. There's a word missing here: "the ? of the flow label mechanism". Also, the "with all ones component" phrase was unclear. I assumed it was referring to some functionality in RFC 4201. I think it would be much clearer to say "the special bit value of all ones" since the "ones component" terminology is not used in RFC 4201. - Section 9: This section lacks clarity. In the first sentence it might be helpful to qualify "this technique" as "the technique described in this document". Also, by further application, do you mean "an additional application of this technique" or "an extension of this technique" (I've assumed the latter in my suggested rewrite below). The second sentence has a "this" that it's not clear to what it's referring - I think it's referring to the "further application of this technique". The third sentence also has a "this" that I think is referring to the "work on the generalization" which is described in the referenced draft. And this construct in the third sentence is not at all clear "…can be regarded as a complementary, but distinct, approach since similar although consideration may apply…" Is this saying that the generalization of this to MPLS described in the draft is complementary, but distinct from the technique described in this document? If so, perhaps, the following suggestion can clarify this section. An extension of this technique is to create a basis for hash diversity without having to peek below the label stack for IP traffic carried over LDP LSPs. The generalisation of this extension to MPLS has been described in [I-D.kompella-mpls-entropy-label]. This generalization can be regarded as a complementary, but distinct, approach from the technique described in this document. While similar consideration may apply to the identification of flows and the allocation of flow label values, the flow labels are imposed by different network components, and the associated signalling mechanisms are different. Nits: - There's a stray END at the end of the abstract to the far right. - Section 1, first sentence: exit -> exist - Section, 2nd para, 3rd sentence: hundred's -> hundreds
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
