Subject: RE: [Gen-art] Gen-ART LC Review of draft-ietf-rddp-mpa-06.txt

From: "Gray, Eric" <[email-masked]>
Date: Fri, 13 Oct 2006 14:09:13 -0400

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-masked]] 
--> Sent: Thursday, September 28, 2006 7:21 PM
--> To: Stephen Bailey; Paul R Culley; Uri Elzur; Renato J 
--> Recio; John Carrier
--> Cc: Lars Eggert; [email-masked]
--> 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
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/gen-art
--> 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art