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

From: "Gray, Eric" <[email-masked]>
Date: Thu, 28 Sep 2006 19:21:15 -0400

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