Document: draft-ietf-rddp-mpa-06.txt Reviewer: Gray, Eric [Eric.Gray@marconi.com] Review Date: Thursday 9/28/2006 6:21 PM IETF LC Date: 29 September 2006 Summary: This document is nearly ready for publishing as a Proposed Standard RFC. I have a few comments/questions below and there are minor NITs and exceptions in format. Thank you for producing such a well-written draft! Comments: -------- Are all probabilistic approaches for generalized framing characterized as described in the second paragraph of section 2.1, or does this apply only to probabilistic approaches considered by the authors? If it is conceivable that a probabilistic approach might be characterized other than as described - or that an example of a deterministic approach with these same characteristics might be found - then this paragraph may be a bit too vague and striving to be too general. The authors are probably more expert in this area than I am, but I get the sense that the second paragraph could use another look. Is HDLC a probabilistic approach as a generalized framing mechanism, for example? __________________________________________________________ What is the purpose of the note in Figure 1 (i.e. - "* These may be fully ...")? Presumably it's a requirement that they be logically separate layers if - in fact - it is posible to implement them either separately or "optimized together." Since we are interested in interoperability, rather than options available to implementers, this really doesn't add value and may be confusing. I say this because my immediate reaction, on seeing this note, is that there is no particular reason why the same thing couldn't be said about the whole stack. But there's a reason why we don't say that. The bullet (numbered 5) on page 10 appears to layout what you're trying to say with this note, but is clearer (in part because it says "RFC compliant TCP wire behavior is observed at both the sender and receiver" making clear what the interoperability requirement is). I recommend leaving the note out. There is quite a lot of text on MPA/TCP optimization on pages 10 and 11, which might be useful to implementers, but might also be much more than you need to include in a standard. You may want to consider either paring a lot of this down or moving most of it to an appendix. I did see that you have already included a lot of text on optimization in Appendix A, so you may feel that it is not possible to remove much more. My question is: how much do you need to say about potential optimization in the main standards text in order to ensure that a non- optimized version will be compatible with an optimized version - developed independently? I suspect the answer is "not much, and most of that is all about how to ensure the an optimized version looks and behaves externally as if it were non-optimized." __________________________________________________________ In the 4th paragraph of section 3, the following sentence appears: "Since FPDU Alignment is generally desired by the receiver, DDP must cooperate with MPA to ensure FPDUs' lengths do not exceed the EMSS under normal conditions." Should the phrase "DDP must" be "DDP MUST" (as this occurs in normative text), "DDP SHOULD" (because "FPDU Alignment is generally desired by the receiver") or is this entire sentence basically descriptive text set into a normative section? __________________________________________________________ On page 12, there is some discussion of the value determined as the maximum MULPDU length. It seems to me that some optional IP header "options" are variable in length (IP Authentication header, for example). It may be better to give the range as "between 128 octets and MAX-MULPDU-LEN, where MAX-MULPDU-LEN is computed as ... and MUST NOT - under any circumstances exceed XXX." "..." would be replaced by a reference to a method you describe "below" and XXX would be replaced with a likely number you may settle on (such as 64768). ___________________________________________________________ The Security Considerations section is tremendously detailed and interesting reading. Is there any expected impact on the size of MULPDU possible as a result of use of IPSec? I suspect this may not be important as it may be very unlikely that really large MULPDUs will occur in practice - but I do not know... ============================================================ NITs: ---- Author names are not indented as usual (not sure if this is an issue as far as the RFC editor is concerned). No definition is included in the Glossary for the acronyms (or signal names) "LLP" (used once on page 39), FIN (several places) and RST (once on page 40). I am not sure if FIN and RST are an issue as these are well-known terms for presumed TCP-aware readers. No definition is included in the Glossary for the acronym CRC (used extensively throughout the document). The term is more than adequately described in several places in the ID, but is also used several times prior to any of these occurs. It might even help to reduce the amount of redundancy if the various forms of CRC mentioned in this document were defined in the glossary. I'm torn as to whether this is a NIT or a comment, so I put it in as a NIT.