I have reviewed version -08 of this document and it addreses all of the comments I have made previously. I believe this document is now ready to publish as a Proposed Standard RFC.
-- Eric --> -----Original Message----- --> From: Gray, Eric [mailto:[EMAIL PROTECTED] --> Sent: Thursday, September 28, 2006 7:21 PM --> To: Stephen Bailey; Paul R Culley; Uri Elzur; Renato J --> Recio; John Carrier --> Cc: Lars Eggert; gen-art@ietf.org --> Subject: [Gen-art] Gen-ART LC Review of draft-ietf-rddp-mpa-06.txt --> --> Authors, --> --> I am the General Area Review Team (Gen-ART) Last Call --> reviewer for this draft - draft-ietf-rddp-mpa-06.txt. --> --> 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: --> -------- --> --> 'Marker PDU Aligned Framing for TCP Specification' --> <draft-ietf-rddp-mpa-06.txt> --> --> --> Reviewer: Eric Gray --> --> Review Date: 9/29/2006 --> IETF LC Date: through 9/29/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. --> --> --> --> --> _______________________________________________ --> Gen-art mailing list --> Gen-art@ietf.org --> https://www1.ietf.org/mailman/listinfo/gen-art --> _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
